Het puppet topic, tips en trucs

[3dmaster]

Het is me toch gelukt om het itk+mod_php te gebruiken. Vanaf apache 2.4.7 is namelijk itk een uitbreiding op prefork geworden. Dus je kunt prefork gebruiken (en dus mod_php) en daarnaast itk gebruiken. Ik heb het alleen niet met de apache module kunnen doen omdat die zelf een dependencycheck doet en denkt dat dit niet kan werken, wat dus sinds kort wel kan. De code moet dus worden geupdate.

[CyBeR]

De (huidige versie van de) code laat je wel php + itk gebruiken: https://github.com/puppet.../manifests/mod/php.pp#L17

De vraag is alleen of jij niet een oudere versie hebt.

[be3a18]

Ik ben een newbie op dit gebied (mijn collega die dit normaal doet is nog een paar dagen vrij) en ik loop tegen het volgende probleem aan:

op onze puppetcommunity server is een bijbehorend yaml bestand aangemaakt met voor zover ik weer de juiste instellingen. Ik heb een nieuwe Ubuntu 16 LTS server ingericht en probeer deze nu met puppet goed in onze omgeving te zetten. Ik krijg echter de volgende foutmelding:

root@srv77:~# puppet agent -t
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: {"message":"Server Error: Data Provider type mismatch: Got String when a hash-like object was expected to access value using 'name' from key 'facts.os.name' on node srv77.xxx.xxxxxx.nl","issue_kind":"RUNTIME_ERROR"}
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
root@srv77:~#

Ik heb de puppet agent al bijgewerkt naar de nieuwste versie. Dat helpt echter niet. De key die genoemd wordt gebruiken we volgens mij helemaal niet.

Ik heb uiteraard gegoogled en daar hebben ze het over de combinatie puppet en facter. Aan dat laatste is niks veranderd.

[CAPSLOCK2000]

Ik denk dat je ergens:

variabele: "bla"

hebt staan in plaats van

variabele: [ "bla" ]

Dus zonder de haken.

Controleer ook of je de juiste versie van Puppet gebruikt. De nieuwste is niet altijd de juiste want de compatibility tussen Puppet-versies is niet geweldig.

[CAPSLOCK2000]

Ik op zoek naar een manier om dependencies te verzamelen.
Ik denk dat iets met virtual resources en/of resources collectors moet maar weet niet helemaal wat.

Ik heb de volgende code:

code:

define myimage1 (String base='debian') {
  docker::image {
    $title:
      ...
    subscribe => Docker::Image[$base]
}

define myimage2 (String base='debian') {
  docker::image {
    $title:
      ...
    subscribe => Docker::Image[$base]
}

class debian_buster {
  docker::image { 'debian:buster': ensure => present }
}

class debian_stretch {
  docker::image { 'debian:stretch': ensure => present }
}

class myclass {
  include debian_stretch
  include debian_buster
  myimage1 {
    'mystretch1': base => 'debian:stretch';
    'mybuster1':  base => 'debian:buster';
  }
  myimage2 {
    'mystretch2': base => 'debian:stretch';
    'mybuster2':  base => 'debian:buster';
  }
}

Deze code maakt vier docker images aan, 'mystretch1', 'mybuster1, 'mystretch2', 'mybuster2' met behulp van twee defines 'myimage1' en 'myimage2'.

Het gaat me om de classes debian_buster en debian_stretch en de bijhorende include statements, daar wil ik vanaf want die zijn triviaal en repetitief.

Ik wil dus dat myimage1 ern myimage2 op een of andere manier doorgeven dat de 'debian:stretch" en 'debian:buster' docker_images worden geinstalleerd zonder dat ik het nog een keer apart moet aangeven. Misschien wel door op een of andere manier die 'subscribe' parameters te verzamelen.
Iemand een suggestie?

[ Voor 20% gewijzigd door CAPSLOCK2000 op 22-10-2020 16:05 ]

[WiebeV]

CAPSLOCK2000 schreef op donderdag 22 oktober 2020 @ 15:59:
Ik op zoek naar een manier om dependencies te verzamelen.
Ik denk dat iets met virtual resources en/of resources collectors moet maar weet niet helemaal wat.

Ik heb de volgende code:

code:

define myimage1 (String base='debian') {
  docker::image {
    $title:
      ...
    subscribe => Docker::Image[$base]
}

define myimage2 (String base='debian') {
  docker::image {
    $title:
      ...
    subscribe => Docker::Image[$base]
}

class debian_buster {
  docker::image { 'debian:buster': ensure => present }
}

class debian_stretch {
  docker::image { 'debian:stretch': ensure => present }
}

class myclass {
  include debian_stretch
  include debian_buster
  myimage1 {
    'mystretch1': base => 'debian:stretch';
    'mybuster1':  base => 'debian:buster';
  }
  myimage2 {
    'mystretch2': base => 'debian:stretch';
    'mybuster2':  base => 'debian:buster';
  }
}

Deze code maakt vier docker images aan, 'mystretch1', 'mybuster1, 'mystretch2', 'mybuster2' met behulp van twee defines 'myimage1' en 'myimage2'.

Het gaat me om de classes debian_buster en debian_stretch en de bijhorende include statements, daar wil ik vanaf want die zijn triviaal en repetitief.

Ik wil dus dat myimage1 ern myimage2 op een of andere manier doorgeven dat de 'debian:stretch" en 'debian:buster' docker_images worden geinstalleerd zonder dat ik het nog een keer apart moet aangeven. Misschien wel door op een of andere manier die 'subscribe' parameters te verzamelen.
Iemand een suggestie?

Inprincipe regelt Docker voor je dat je base image gepulled wordt toch? Ik zou er dan verder niet veel over zeggen via Puppet tenzij je hem op latest wil houden of iets dergelijks. Je zou dan bijvoorbeeld de ensure_resource functie kunnen gebruken om de base image te definiëren, hangt een beetje af van jou preciese usecase of dat de netste manier is.

[ Voor 1% gewijzigd door WiebeV op 29-10-2020 16:14 . Reden: Linkje toegevoegd naar ensure_resource documentatie ]