DOF401 - Puppet en Mode Sans Maître

• DOF401 - Puppet en Mode Sans Maître
  • Contenu du Module
  • Qu'est-ce Puppet ?
  • Démarrer avec Puppet
    • Utiliser des Manifests
      • LAB #1 - Gestion des Fichiers
        • 1.1 - Modification d'un Fichier Existant sur le Serveur
        • 1.2 - Effectuer un Dry Run avec Puppet
      • LAB #2 - Gestion des Paquets
      • LAB #3 - Gestion des Services
    • Gérer du code Puppet avec Git
      • LAB #4 - Créer un Repository Local
        • 4.1 - Les Branches avec Git
      • LAB #5 - Créer un Repository Distant
      • LAB #6 - Cloner un Repository
      • LAB #7 - Appliquer des Modifications Automatiquement
      • LAB #8 - Mise en Place sur un Nœud

Puppet est :

• un logiciel libre écrit partiellement en Ruby permettant la gestion de la configuration de serveurs esclaves ( GNU/Linux, Mac OS X et Windows ),
• diffusé sous licence Apache 2.0 pour les versions récentes de Puppet.

La version libre :

• permet de gérer les déploiements système et applicatif,
• accepte les machines virtuelles de type Amazon EC2.

La version commerciale de Puppet permet aussi :

• de gérer les machines virtuelles VMware,
• d'avoir une interface graphique de gestion,
• d'automatiser et d'orchestrer les déploiements,
• d'avoir une plateforme de développement pour tous les environnements,
• de gérer individuellement les droits utilisateurs.

Puppet est un outil de gestion de la configuration de systèmes. Pour résumer le flux de travail avec Puppet, on peut dire que :

• vous spécifiez l'état de configuration voulu en éditant des fichier textes et un modèle des ressources du système,
• Puppet compare l'état actuel avec l'état voulu et procède aux modifications nécessaires.

Plus particulièrement Puppet est :

• un langage pour spécifier l'état désiré,
• un moteur qui interprète le code écrit dans ce langage et qui l'applique aux nœuds pour arriver à l'état désiré.

Par exemple :

package { 'curl':
 ensure => installed,
}

Ce manifest indique que le paquet curl doit être installé. Quand ce code est appliqué, Puppet vérifie si le paquet curl est installé dans le nœud puis :

• si c'est le cas, ne fait rien,
• sinon l'installe.

Voici un autre exemple :

user { 'trainee':
 ensure => present,
}

Dans ce cas, l'utilisateur doit être présent dans le nœud concerné, sinon Puppet va créer l'utilisateur.

La force de Puppet est qu'il est capable d'implémenter ce code quelque soit le système d'exploitation du nœud, parmi les systèmes d'exploitation compatibles :

• vous décrivez la configuration désirée en termes de ressources et d'attributs,
• Puppet crée les ressources dans les différents systèmes d'exploitation en utilisant le même manifest.

Il existe deux façons d'utiliser Puppet :

• Stand-alone Puppet ou “Sans Maître”,
  • Puppet est exécuté sur chaque nœud et n'a pas donc besoin de contacter un Maître. Cette configuration utilise Git, SFTP ou rsync pour mettre à jour les manifests sur chaque nœud,
• Architecture Agent/Maître,
  • un nœud est dédié à l'exécution de Puppet et tous les autres nœuds doivent le contacter pour connaître la configuration à appliquer.

Commencez en vous connectant à la machine virtuelle debian10 à partir d'un terminal de votre gateway :

trainee@traineeXX:~$ ssh -l trainee 10.0.2.70

Les noms d'utilisateurs et les mots de passe sont :

Démarrez maintenant votre environnement de travail Puppet :

trainee@debian10:~/puppet-beginners-guide-3$ vagrant up

Re-démarrez votre environnement Puppet :

trainee@debian10:~/puppet-beginners-guide-3$ vagrant reload

Connectez-vous à votre environnement de travail Puppet et créez le fichier file_hello.pp :

trainee@debian10:~/puppet-beginners-guide-3$ vagrant ssh
Welcome to Ubuntu 16.04.7 LTS (GNU/Linux 4.4.0-210-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

34 packages can be updated.
12 of these updates are security updates.
To see these additional updates run: apt list --upgradable

New release '18.04.6 LTS' available.
Run 'do-release-upgrade' to upgrade to it.


Last login: Thu Apr 29 10:16:09 2021 from 10.0.2.2
vagrant@ubuntu-xenial:~$ 

vagrant@ubuntu-xenial:~$ vi file_hello.pp
vagrant@ubuntu-xenial:~$ cat file_hello.pp 
file { '/tmp/hello.txt':
  ensure  => file,
  content => "hello, world\n",
} 

Dans ce fichier nous pouvons constater la déclaration d'une ressource de type fichier avec file. Une ressource est une configuration que vous souhaitez être gérée par Puppet par exemple, un fichier, un utilisateur, un compte ou bien un paquet. Le format de notre manifest est donc :

TYPE_RESSOURCE { TITRE:
ATTRIBUT => VALEUR,
...
}

La ressource est identifiée par un titre. Chaque ressource doit avoir un titre unique. Dans le cas d'un fichier c'est le chemin complet vers le fichier - /tmp/hello.txt.

Le reste du code est une liste d'attributs pour la ressource. Dans le cas d'un fichier les attributs disponibles pour sont, par exemple :

• le contenu,
• le propriétaire,
• le groupe,
• le mode,
• etc …

Le contenu de ce fichier est stipulé par l'attribut content qui est ici une chaîne hello, world suivie par un caractère de nouvelle ligne \n.

L'application du manifest par Puppet se résume ainsi :

• Puppet lit le manifest ainsi que la liste des ressources,
• Puppet compile les ressources en un catalogue,
• Puppet lit le catalogue et applique chaque ressource à tour de rôle.

Le nom du manifest n'est pas important, par contre l’extension doit être .pp

Appliquez ce fichier avec la commande suivante :

vagrant@ubuntu-xenial:~$ sudo puppet apply file_hello.pp 
Notice: Compiled catalog for ubuntu-xenial in environment production in 0.06 seconds
Notice: /Stage[main]/Main/File[/tmp/hello.txt]/ensure: defined content as '{md5}22c3683b094136c3398391ae71b20f04'
Notice: Applied catalog in 0.06 seconds

Vérifiez que Puppet a écrit le fichier /tmp/hello.txt :

vagrant@ubuntu-xenial:~$ cat /tmp/hello.txt
hello, world

Dans le cas où le fichier existe déjà et son contenu est différent, Puppet écrasera son contenu avec celui du manifest :

vagrant@ubuntu-xenial:~$ sudo sh -c 'echo "goodbye, world" > /tmp/hello.txt'
vagrant@ubuntu-xenial:~$ cat /tmp/hello.txt
goodbye, world
vagrant@ubuntu-xenial:~$ sudo puppet apply file_hello.pp 
Notice: Compiled catalog for ubuntu-xenial in environment production in 0.06 seconds
Notice: /Stage[main]/Main/File[/tmp/hello.txt]/content: content changed '{md5}767887814e925822027f4fe63fb69ce2' to '{md5}22c3683b094136c3398391ae71b20f04'
Notice: Applied catalog in 0.11 seconds
vagrant@ubuntu-xenial:~$ cat /tmp/hello.txt
hello, world

Il est possible de demander à Puppet, grâce à l'utilisation de l'option –noop, de nous informer des modifications qu'il aurait fait en appliquant un manifest, sans que ces modifications soient réellement effectuées :

vagrant@ubuntu-xenial:~$ sudo sh -c 'echo "goodbye, world" > /tmp/hello.txt'
vagrant@ubuntu-xenial:~$ sudo puppet apply --noop file_hello.pp 
Notice: Compiled catalog for ubuntu-xenial in environment production in 0.07 seconds
Notice: /Stage[main]/Main/File[/tmp/hello.txt]/content: current_value '{md5}767887814e925822027f4fe63fb69ce2', should be '{md5}22c3683b094136c3398391ae71b20f04' (noop)
Notice: Class[Main]: Would have triggered 'refresh' from 1 event
Notice: Stage[main]: Would have triggered 'refresh' from 1 event
Notice: Applied catalog in 0.07 seconds
vagrant@ubuntu-xenial:~$ cat /tmp/hello.txt
goodbye, world

Comme vous pouvez constater, Puppet décide si un fichier doit être modifié en fonction de la valeur du hash md5.

Pour constater les modifications que Puppet aurait effectué, utilisez l'option –show_diff :

vagrant@ubuntu-xenial:~$ sudo puppet apply --noop --show_diff file_hello.pp 
Notice: Compiled catalog for ubuntu-xenial in environment production in 0.07 seconds
Notice: /Stage[main]/Main/File[/tmp/hello.txt]/content: 
--- /tmp/hello.txt	2018-05-26 13:31:30.480333595 +0000
+++ /tmp/puppet-file20180526-27193-1pjhkk9	2018-05-26 13:36:45.039195308 +0000
@@ -1 +1 @@
-goodbye, world
+hello, world

Notice: /Stage[main]/Main/File[/tmp/hello.txt]/content: current_value '{md5}767887814e925822027f4fe63fb69ce2', should be '{md5}22c3683b094136c3398391ae71b20f04' (noop)
Notice: Class[Main]: Would have triggered 'refresh' from 1 event
Notice: Stage[main]: Would have triggered 'refresh' from 1 event
Notice: Applied catalog in 0.11 seconds

Puppet est capable de gérer les paquets grâce à la ressource package. Dans le manifest nous trouvons donc cette ressource, le nom du paquet ainsi que l'attribut ensure :

package { 'package_name':
ensure => installed,
}

Ce manifest aura comme résultat d'assurer que le package package_name soit installé en utilisant le gestionnaire des paquets du système d'exploitation.

Créez le fichier package.pp suivant :

vagrant@ubuntu-xenial:~$ sudo vi package.pp
vagrant@ubuntu-xenial:~$ cat package.pp
package { 'cowsay':
  ensure => installed,
}

Appliquez le manifest :

vagrant@ubuntu-xenial:~$ sudo puppet apply package.pp
Notice: Compiled catalog for ubuntu-xenial in environment production in 1.51 seconds
Notice: /Stage[main]/Main/Package[cowsay]/ensure: created
Notice: Applied catalog in 8.76 seconds

Le résultat de l'application de ce manifest est l'installation du paquet cowsay :

vagrant@ubuntu-xenial:~$ dpkg --get-selections | grep cowsay
cowsay						install
cowsay-off					install
vagrant@ubuntu-xenial:~$ dpkg -s cowsay
Package: cowsay
Status: install ok installed
Priority: optional
Section: games
Installed-Size: 90
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: all
Version: 3.03+dfsg1-15
Depends: libtext-charwidth-perl, perl
Recommends: cowsay-off
Suggests: filters
Description: configurable talking cow
 Cowsay (or cowthink) will turn text into happy ASCII cows, with
 speech (or thought) balloons. If you don't like cows, ASCII art is
 available to replace it with some other creatures (Tux, the BSD
 daemon, dragons, and a plethora of animals, from a turkey to
 an elephant in a snake).
Original-Maintainer: Tony Maillefaud <maltouzes@gmail.com>
Homepage: https://web.archive.org/web/20120527202447/http://www.nog.net/~tony/warez/cowsay.shtml

Pour voir la version du paquet que Puppet pense être installé, utilisez la commande puppet resource en spécifiant le paquet concerné :

vagrant@ubuntu-xenial:~$ sudo puppet resource package openssl
package { 'openssl':
  ensure   => '1.0.2g-1ubuntu4.15',
  provider => 'apt',
}
vagrant@ubuntu-xenial:~$ dpkg -s openssl
Package: openssl
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 934
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: amd64
Version: 1.0.2g-1ubuntu4.15
Depends: libc6 (>= 2.15), libssl1.0.0 (>= 1.0.2g)
Suggests: ca-certificates
Conffiles:
 /etc/ssl/openssl.cnf 7df26c55291b33344dc15e3935dabaf3
Description: Secure Sockets Layer toolkit - cryptographic utility
 This package is part of the OpenSSL project's implementation of the SSL
 and TLS cryptographic protocols for secure communication over the
 Internet.
 .
 It contains the general-purpose command line binary /usr/bin/openssl,
 useful for cryptographic operations such as:
  * creating RSA, DH, and DSA key parameters;
  * creating X.509 certificates, CSRs, and CRLs;
  * calculating message digests;
  * encrypting and decrypting with ciphers;
  * testing SSL/TLS clients and servers;
  * handling S/MIME signed or encrypted mail.
Original-Maintainer: Debian OpenSSL Team <pkg-openssl-devel@lists.alioth.debian.org>

L'utilisation de cette commande sans spécifier un paquet permet de voir la liste de tous les paquets :

vagrant@ubuntu-xenial:~$ sudo puppet resource package | more
package { 'accountsservice':
  ensure   => '0.6.40-2ubuntu11.3',
  provider => 'apt',
}
package { 'acl':
  ensure   => '2.2.52-3',
  provider => 'apt',
}
package { 'acpid':
  ensure   => '1:2.0.26-1ubuntu2',
  provider => 'apt',
}
package { 'adduser':
  ensure   => '3.113+nmu3ubuntu4',
  provider => 'apt',
}
package { 'apparmor':
  ensure   => '2.10.95-0ubuntu2.11',
  provider => 'apt',
}
package { 'apport':
  ensure   => '2.20.1-0ubuntu2.21',
  provider => 'apt',
--More--

Puppet resource a aussi un mode interactif :

vagrant@ubuntu-xenial:~$ sudo puppet resource -e package openssl

Cette commande génère un manifest pour l'état actuel de la ressource et l'ouvre dans un éditeur :

package { 'openssl':
  ensure   => '1.0.2g-1ubuntu4.15',
  provider => 'apt',
}

Si vous modifiez ce manifest, lors de l'enregistrement du fichier, Puppet appliquera les modifications.

Le manifest pour la gestion d'un service contient la ressource service. Créez le fichier suivant :

vagrant@ubuntu-xenial:~$ sudo vi service.pp
vagrant@ubuntu-xenial:~$ cat service.pp
service { 'sshd':
  ensure => running,
  enable => true,
}

Les attributs d'une ressource peuvent être consultés par la commande puppet describe :

vagrant@ubuntu-xenial:~$ sudo puppet describe service

service
=======
Manage running services.  Service support unfortunately varies
widely by platform --- some platforms have very little if any concept of a
running service, and some have a very codified and powerful concept.
Puppet's service support is usually capable of doing the right thing, but
the more information you can provide, the better behaviour you will get.
Puppet 2.7 and newer expect init scripts to have a working status command.
If this isn't the case for any of your services' init scripts, you will
need to set `hasstatus` to false and possibly specify a custom status
command in the `status` attribute. As a last resort, Puppet will attempt to
search the process table by calling whatever command is listed in the `ps`
fact. The default search pattern is the name of the service, but you can
specify it with the `pattern` attribute.
**Refresh:** `service` resources can respond to refresh events (via
`notify`, `subscribe`, or the `~>` arrow). If a `service` receives an
event from another resource, Puppet will restart the service it manages.
The actual command used to restart the service depends on the platform and
can be configured:
* If you set `hasrestart` to true, Puppet will use the init script's restart
command.
* You can provide an explicit command for restarting with the `restart`
attribute.
* If you do neither, the service's stop and start commands will be used.


Parameters
----------

- **binary**
    The path to the daemon.  This is only used for
    systems that do not support init scripts.  This binary will be
    used to start the service if no `start` parameter is
provided.

- **control**
    The control variable used to manage services (originally for HP-UX).
    Defaults to the upcased service name plus `START` replacing dots with
    underscores, for those providers that support the `controllable`
    feature.

- **enable**
    Whether a service should be enabled to start at boot.
    This property behaves differently depending on the platform;
    wherever possible, it relies on local tools to enable or disable
    a given service. Default values depend on the platform.
    Valid values are `true`, `false`, `manual`, `mask`, `delayed`. 
    Requires features enableable.

- **ensure**
    Whether a service should be running. Default values depend on the
    platform.
    Valid values are `stopped` (also called `false`), `running` (also called
    `true`). 

- **flags**
    Specify a string of flags to pass to the startup script.
    Requires features flaggable.

- **hasrestart**
    Specify that an init script has a `restart` command.  If this is
    false and you do not specify a command in the `restart` attribute,
    the init script's `stop` and `start` commands will be used.
    Valid values are `true`, `false`. 

- **hasstatus**
    Declare whether the service's init script has a functional status
    command. This attribute's default value changed in Puppet 2.7.0.
    The init script's status command must return 0 if the service is
    running and a nonzero value otherwise. Ideally, these exit codes
    should conform to [the LSB's specification][lsb-exit-codes] for init
    script status actions, but Puppet only considers the difference
    between 0 and nonzero to be relevant.
    If a service's init script does not support any kind of status command,
    you should set `hasstatus` to false and either provide a specific
    command using the `status` attribute or expect that Puppet will look for
    the service name in the process table. Be aware that 'virtual' init
    scripts (like 'network' under Red Hat systems) will respond poorly to
    refresh events from other resources if you override the default behavior
    without providing a status command.
Valid values are `true`, `false`. 

- **manifest**
    Specify a command to config a service, or a path to a manifest to do so.

- **name**
    The name of the service to run.
    This name is used to find the service; on platforms where services
    have short system names and long display names, this should be the
    short name. (To take an example from Windows, you would use "wuauserv"
    rather than "Automatic Updates.")

- **path**
    The search path for finding init scripts.  Multiple values should
    be separated by colons or provided as an array.

- **pattern**
    The pattern to search for in the process table.
    This is used for stopping services on platforms that do not
    support init scripts, and is also used for determining service
    status on those service whose init scripts do not include a status
    command.
    Defaults to the name of the service. The pattern can be a simple string
    or any legal Ruby pattern, including regular expressions (which should
    be quoted without enclosing slashes).

- **restart**
    Specify a *restart* command manually.  If left
    unspecified, the service will be stopped and then started.

- **start**
    Specify a *start* command manually.  Most service subsystems
    support a `start` command, so this will not need to be
specified.

- **status**
    Specify a *status* command manually.  This command must
    return 0 if the service is running and a nonzero value otherwise.
    Ideally, these exit codes should conform to [the LSB's
    specification][lsb-exit-codes] for init script status actions, but
    Puppet only considers the difference between 0 and nonzero to be
    relevant.
    If left unspecified, the status of the service will be determined
    automatically, usually by looking for the service in the process
    table.
    [lsb-exit-codes]:
    http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-
    generic/iniscrptact.html

- **stop**
    Specify a *stop* command manually.

- **timeout**
    Specify an optional minimum timeout (in seconds) for puppet to wait when
    syncing service properties
Requires features configurable_timeout.

Providers
---------
    base, bsd, daemontools, debian, freebsd, gentoo, init, launchd, openbsd,
    openrc, openwrt, rcng, redhat, runit, service, smf, src, systemd,
    upstart, windows

Pour consulter la liste des types de ressources, utilisez la commande suivante :

vagrant@ubuntu-xenial:~$ sudo puppet describe --list
These are the types known to puppet:
augeas          - Apply a change or an array of changes to the  ...
cron            - Installs and manages cron jobs
exec            - Executes external commands
file            - Manages files, including their content, owner ...
filebucket      - A repository for storing and retrieving file  ...
group           - Manage groups
host            - Installs and manages host entries
mount           - Manages mounted filesystems, including puttin ...
notify          - Sends an arbitrary message to the agent run-t ...
package         - Manage packages
resources       - This is a metatype that can manage other reso ...
schedule        - Define schedules for Puppet
scheduled_task  - Installs and manages Windows Scheduled Tasks
selboolean      - Manages SELinux booleans on systems with SELi ...
selmodule       - Manages loading and unloading of SELinux poli ...
service         - Manage running services
ssh_authorized_key - Manages SSH authorized keys
sshkey          - Installs and manages ssh host keys
stage           - A resource type for creating new run stages
tidy            - Remove unwanted files based on specific crite ...
user            - Manage users
whit            - Whits are internal artifacts of Puppet's curr ...
yumrepo         - The client-side description of a yum reposito ...
zfs             - Manage zfs
zone            - Manages Solaris zones
zpool           - Manage zpools

Les différents types de ressources peuvent être regroupés dans le même manifest. Créez le fichier package_file_service.pp :

vagrant@ubuntu-xenial:~$ sudo vi package_file_service.pp
vagrant@ubuntu-xenial:~$ cat package_file_service.pp
package { 'mysql-server':
  ensure => installed,
  notify => Service['mysql'],
}

file { '/etc/mysql/mysql.cnf':
  source => '/examples/files/mysql.cnf',
  notify => Service['mysql'],
}

service { 'mysql':
  ensure => running,
  enable => true,
}

Notez que dans ce manifest se trouve l'attribut notify. Cet attribut notifie le service mysql lors d'un changement de son fichier de configuration mysql.cnf. L'action par défaut de Puppet dans ce cas est de re-démarrer le service.

L'ordre de la déclaration des ressources dans ce manifest est suivi par Puppet :

• Puppet install le paquet mysql-server,
• Puppet copie le fichier /examples/files/mysql.cnf vers /etc/mysql/mysql.cnf,
• Puppet démarre le service mysql.

Cet ordre est logique. Il est évident que le manifest suivant ne donnera pas un résultat satisfaisant :

package { 'mysql-server':
  ensure => installed,
  notify => Service['mysql'],
}

service { 'mysql':
  ensure => running,
  enable => true,
}

file { '/etc/mysql/mysql.cnf':
  source => '/examples/files/mysql.cnf',
  notify => Service['mysql'],
}

L'ordre de l'application des ressources dans un manifest peut cependant être fixé en utilisant l'attribut require. Voici le même manifest avec l'utilisation de cet attribut :

package { 'mysql-server':
  ensure => installed,
}

file { '/etc/mysql/mysql.cnf':
  source  => '/examples/files/mysql.cnf',
  notify  => Service['mysql'],
  require => Package['mysql-server'],
}

service { 'mysql':
  ensure  => running,
  enable  => true,
  require => [Package['mysql-server'], File['/etc/mysql/mysql.cnf']],
}

Git est :

• un logiciel de gestion de versions décentralisé,
• un logiciel libre créé par Linus Torvalds,
• distribué selon les termes de la licence publique générale GNU version 2.

Quand le code d'un projet est modifié par un développeur, celui-ci procède à un commit pour rendre le code disponible aux autres. Un commit est un snapshot ou instantanée du repository qui est gardé pour toujours ce qui implique la possibilité de rollbacks.

Un jeu de fichiers sous Git est appelé un repository ou simplement un repo. Pour créer un repo local pour puppet, utilisez les commandes suivantes :

vagrant@ubuntu-xenial:~$ sudo mkdir puppet
vagrant@ubuntu-xenial:~$ sudo chown vagrant:vagrant puppet
vagrant@ubuntu-xenial:~$ cd puppet
vagrant@ubuntu-xenial:~/puppet$ git init
Initialized empty Git repository in /home/vagrant/.git/

Git a besoin de savoir qui vous êtes. Saisissez donc les commandes suivantes en remplaçant les coordonnées d'identification avec les vôtres :

vagrant@ubuntu-xenial:~/puppet$ git config --global user.name "ittrainingdev"
vagrant@ubuntu-xenial:~/puppet$ git config --global user.email "infos@i2tch.co.uk"

Un repo doit contenir un fichier README qui contient des informations concernant le repo. Créez donc ce fichier avec un minimum d'informations :

vagrant@ubuntu-xenial:~/puppet$ echo "Coming soon!" > README.md

Consultez le statut du repo avec la commande git status :

vagrant@ubuntu-xenial:~/puppet$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	README.md

nothing added to commit but untracked files present (use "git add" to track)

Pour informer Git de la présence du fichier README.md, il convient d'utiliser la commande git add :

vagrant@ubuntu-xenial:~/puppet$ sudo git add README.md
vagrant@ubuntu-xenial:~/puppet$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

	new file:   README.md

Notez que le fichier est maintenant sous la ligne Changes to be committed:. Procédez donc à un commit :

vagrant@ubuntu-xenial:~/puppet$ sudo git commit -m 'Add README file'
[master (root-commit) 9139685] Add README file
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Pour voir l'historique des commits, utilisez la commande git log :

vagrant@ubuntu-xenial:~/puppet$ git log
commit 913968526d9748f8d92e6eacea03ac0a6d1ac901
Author: ittrainingdev <infos@i2tch.co.uk>
Date:   Sun May 27 04:53:07 2018 +0000

    Add README file

Une Branche sous Git est une copie parallèle du code où les modifications sont indépendantes. Ces modification peuvent ensuite être fusionner avec la Branche Maître. Ceci permet :

• de connecter un nœud à une branche spécifique pour tester du code, sans l'implémenter sur tous le nœuds,
• à deux ou plusieurs développeurs de travailler d'une manière indépendante puis d'échanger des commits entre les Branches.

Vous pouvez trouver d'avantage d'informations concernant les Branches de Git à cet URL https://git-scm.com/book/fr/v1/Les-branches-avec-Git-Brancher-et-fusionner%C2%A0%3A-les-bases ainsi que l'ebook gratuit ici - https://git-scm.com/book/fr/v2.

Commencez par vous connecter à votre compte sur https://github.com. Créez ensuite un nouveau repo puppet à l'adresse https://github.com/new.

Copiez l'URL du repo, par exemple : https://github.com/ittrainingdev/puppet.git.

Vous devez maintenant pousser votre repo local vers Github. Placez-vous dans le répertoire puppet de votre machine virtuelle et saisissez la commande suivante en collant à la place de l'URL ci-dessous, l'URL que vous avez copié ci-dessus et en utilisant vos coordonnées de connexion :

vagrant@ubuntu-xenial:~/puppet$ sudo git remote add origin https://github.com/ittrainingdev/puppet.git
vagrant@ubuntu-xenial:~/puppet$ sudo git push -u origin master
Username for 'https://github.com': ittrainingdev
Password for 'https://ittrainingdev@github.com': 
Counting objects: 3, done.
Writing objects: 100% (3/3), 232 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/ittrainingdev/puppet.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

Vérifiez maintenant votre repo sur Github en visitant l'URL de votre repo. Vous devez voir le fichier README.md :

Le répertoire par défaut de stockage des manifests de Puppet est /etc/puppetlabs/code/environments/.

Placez-vous donc dans ce répertoire :

vagrant@ubuntu-xenial:~/puppet$ cd /etc/puppetlabs/code/environments/

Consultez son contenu :

vagrant@ubuntu-xenial:/etc/puppetlabs/code/environments$ ls
pbg  production

Le répertoire production contient des exemples de manifests de production installés par défaut :

agrant@ubuntu-xenial:/etc/puppetlabs/code/environments$ cd production/
vagrant@ubuntu-xenial:/etc/puppetlabs/code/environments/production$ ls
data  environment.conf  hiera.yaml  manifests  modules

Git refuse de cloner vers un répertoire non-vide. Renommez donc le répertoire production :

vagrant@ubuntu-xenial:/etc/puppetlabs/code/environments/production$ cd ..
vagrant@ubuntu-xenial:/etc/puppetlabs/code/environments$ sudo mv production production.sample

Cloner maintenant le repo sur Github vers un nouveau répertoire /etc/puppetlabs/code/environments/production :

vagrant@ubuntu-xenial:/etc/puppetlabs/code/environments$ sudo git clone https://github.com/ittrainingdev/puppet.git production
Cloning into 'production'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
Checking connectivity... done.

En production, chaque nœud doit automatiquement télécharger les modifications du code dans le repo distant puis les appliquer avec Puppet.

Pour arriver à cette fin, il convient de créer un script bash dans le répertoire /home/vagrant/puppet/files/ :

vagrant@ubuntu-xenial:/etc/puppetlabs/code/environments$ cd /home/vagrant/puppet
vagrant@ubuntu-xenial:~/puppet$ mkdir manifests files
vagrant@ubuntu-xenial:~/puppet$ vi files/run-puppet.sh
vagrant@ubuntu-xenial:~/puppet$ cat files/run-puppet.sh
#!/bin/bash
cd /etc/puppetlabs/code/environments/production && git pull
/opt/puppetlabs/bin/puppet apply manifests/

Créez ensuite le manifest run-puppet.pp dans le répertoire /home/vagrant/puppet/manifests/ :

vagrant@ubuntu-xenial:~/puppet$ vi manifests/run-puppet.pp
vagrant@ubuntu-xenial:~/puppet$ cat manifests/run-puppet.pp
# Set up regular Puppet runs
file { '/usr/local/bin/run-puppet':
  source => '/etc/puppetlabs/code/environments/production/files/run-puppet.sh',
  mode   => '0755',
}

cron { 'run-puppet':
  command => '/usr/local/bin/run-puppet',
  hour    => '*',
  minute  => '*/15',
}

Ajoutez maintenant les fichiers à Git :

vagrant@ubuntu-xenial:~/puppet$ sudo git add manifests files
vagrant@ubuntu-xenial:~/puppet$ sudo git commit -m 'Add run-puppet script and cron job'
[master 756859c] Add run-puppet script and cron job
 2 files changed, 14 insertions(+)
 create mode 100644 files/run-puppet.sh
 create mode 100644 manifests/run-puppet.pp

vagrant@ubuntu-xenial:~/puppet$ sudo git push origin master
Username for 'https://github.com': ittrainingdev
Password for 'https://ittrainingdev@github.com': 
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 688 bytes | 0 bytes/s, done.
Total 6 (delta 0), reused 0 (delta 0)
To https://github.com/ittrainingdev/puppet.git
   9139685..756859c  master -> master

Votre nœud se trouve dans le répertoire /etc/puppetlabs/code/environments/production :

vagrant@ubuntu-xenial:~/puppet$ cd /etc/puppetlabs/code/environments/production
vagrant@ubuntu-xenial:/etc/puppetlabs/code/environments/production$ ls
README.md

Commencez par faire un git pull :

vagrant@ubuntu-xenial:/etc/puppetlabs/code/environments/production$ sudo git pull
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 0), reused 6 (delta 0), pack-reused 0
Unpacking objects: 100% (6/6), done.
From https://github.com/ittrainingdev/puppet
   9139685..756859c  master     -> origin/master
Updating 9139685..756859c
Fast-forward
 files/run-puppet.sh     |  3 +++
 manifests/run-puppet.pp | 11 +++++++++++
 2 files changed, 14 insertions(+)
 create mode 100644 files/run-puppet.sh
 create mode 100644 manifests/run-puppet.pp

Vérifiez le résultat :

vagrant@ubuntu-xenial:/etc/puppetlabs/code/environments/production$ ls
files  manifests  README.md

Appliquez maintenant le mainifest sur le nœud :

vagrant@ubuntu-xenial:/etc/puppetlabs/code/environments/production$ sudo puppet apply manifests/
Notice: Compiled catalog for ubuntu-xenial in environment production in 0.20 seconds
Notice: /Stage[main]/Main/File[/usr/local/bin/run-puppet]/ensure: defined content as '{md5}dbfba978957e90ebb47e3a266b89231b'
Notice: /Stage[main]/Main/Cron[run-puppet]/ensure: created
Notice: Applied catalog in 0.22 seconds

Vérifiez que le script a été créé sur le nœud :

vagrant@ubuntu-xenial:/etc/puppetlabs/code/environments/production$ cat /usr/local/bin/run-puppet
#!/bin/bash
cd /etc/puppetlabs/code/environments/production && git pull
/opt/puppetlabs/bin/puppet apply manifests/

ainsi que le cron job :

vagrant@ubuntu-xenial:/etc/puppetlabs/code/environments/production$ sudo crontab -l
# HEADER: This file was autogenerated at 2020-02-11 10:08:47 +0000 by puppet.
# HEADER: While it can still be managed manually, it is definitely not recommended.
# HEADER: Note particularly that the comments starting with 'Puppet Name' should
# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
# Puppet Name: run-puppet
*/15 * * * * /usr/local/bin/run-puppet

Copyright © 2022 Hugh Norris.