Comment utiliser les environnements Puppet sous Linux pour mettre à jour un agent en toute sécurité

Objectif

Créez et utilisez des environnements de marionnettes pour tester une nouvelle configuration avant de mettre à jour un système de production en direct.

Système d’exploitation et versions logicielles

Système d’exploitation: N’importe quelle distribution Linux majeure, par exemple Ubuntu, Debian, CentOS
Logiciel : marionnette et marionnettiste

Exigences

Accès privilégié au serveur maître puppet et au nœud client puppet.

Conventions

# – nécessite que les commandes Linux données soient exécutées avec les privilèges root, soit directement en tant qu’utilisateur root, soit en utilisant la commande sudo
$ – commandes linux données à exécuter en tant qu’utilisateur régulier non privilégié

Introduction

La plupart des installations de Puppet commencent leur vie en tant que serveur maître exécutant une seule branche. Le maître contient tous les manifestes et autres configurations de tous les agents Puppet qui sont synchronisés avec lui. C’est un bon point de départ, mais il arrivera rapidement un moment où une mise à jour doit être poussée et qui a le potentiel de casser un serveur de production. Espérer le meilleur n’est pas la meilleure façon de procéder.

Puppet fournit les outils permettant de séparer des branches entières de configuration. C’est ce qu’on appelle des environnements. Un environnement Puppet est un moyen de fournir à un groupe isolé de nœuds d’agent leur propre configuration dédiée. Chaque environnement contient une arborescence de configuration Puppet entière et peut être considéré comme un serveur maître Puppet distinct.

Comment les environnements Puppet sont-ils utilisés ?

Le scénario typique des environnements, et c’est celui que nous explorons dans ce guide, consiste à créer un environnement de test, parallèlement à l’environnement de production, où la nouvelle configuration Puppet est créée.

Une façon de tester la nouvelle configuration dans l’environnement de test consiste à mettre à jour une copie d’un serveur de production, telle qu’un instantané de machine virtuelle. Tout problème sera observé sur la machine de test et la configuration de Puppet sera modifiée pour corriger cela. Cependant, il n’est pas toujours possible d’avoir un serveur de test pour vérifier les modifications dans l’environnement de test.

Une autre méthode, que nous allons explorer ici, consiste à exécuter l’agent Puppet manuellement sur le serveur de production, mais à l’aide de plusieurs options qui entraîneront la synchronisation de l’agent Puppet avec l’environnement de test, mais ne montreront que ce qui se serait passé sans apporter de modifications réelles. Cela mettra en évidence toutes les erreurs qui se seraient produites lors d’une mise à jour complète sans provoquer de temps d’arrêt.

Création d’environnements de marionnettes

Dans ce guide, nous allons créer une instance de Puppet très simple avec un nœud Puppet Master et un nœud d’agent Puppet. Le serveur maître Puppet sera configuré pour avoir deux environnements ; tests et développement.

Ce guide suppose que vous disposez d’un serveur maître Puppet et d’un nœud d’agent Puppet capable de se connecter au maître Puppet.

Nous allons créer deux environnements sur le maître Puppet et dans ces environnements, nous allons créer un manifeste Puppet très simple qui crée un fichier texte sur le nœud de l’agent.

L’emplacement par défaut de la configuration de Puppet change en fonction de la distribution que vous utilisez. Sur Ubuntu 18.04LTS, la version qui sera utilisée dans ce guide, l’emplacement est dans /etc/puppet. D’autres distributions (et la documentation officielle) peuvent le placer dans /etc/puppetlabs/. Cependant, une fois que vous êtes dans le répertoire de configuration principal de Puppet, tous les sous-répertoires sont les mêmes pour toutes les distributions.

Instructions

Création des répertoires d’environnement

Les environnements et leur configuration existent tous dans le répertoire /etc/puppet/code/. Sur Ubuntu 18.04, ce répertoire est vide lors de l’installation, nous devrons donc d’abord créer les deux répertoires d’environnement de niveau supérieur avec les deux commandes suivantes :

mkdir -p /etc/puppet/code/environments/testing
mkdir -p /etc/puppet/code/environments/development

Tout nouveau nœud d’agent se connectera automatiquement à l’environnement de développement, sauf si la variable d’environnement est définie sur une alternative dans la section [agent] du fichier puppet.conf sur le nœud d’agent.

Création de deux manifestes site.pp simples

Le fichier site.pp est le manifeste principal à partir duquel l’agent Puppet commence à créer un catalogue de l’état de la machine souhaité. Nous allons créer deux fichiers site.pp très simples dans les deux environnements qui créent le même fichier sur le nœud de l’agent. La seule différence est qu’ils mettent un texte différent dans le fichier.

Le premier fichier site.pp sera l’environnement de production à l’adresse suivante :
/etc/puppet/code/environments/development/manifests/site.pp
Ce fichier doit avoir le contenu suivant :

file {'/tmp/example.txt':
 ensure  => present,
 mode    => "0644",
 content => "From The Development Environment \n",
}

Utilisez votre éditeur de texte préféré pour créer et remplir ce fichier.

Ce manifeste garantit qu’un fichier est présent dans /tmp/example.txt et contient le texte « From The Development Environment » (le « \n » ajoute une nouvelle ligne à la fin du fichier, ce qui est une bonne pratique et empêche Puppet d’afficher un message d’avertissement lorsqu’il n’est pas présent).

Le deuxième manifeste se trouvera sous l’environnement de test à l’adresse suivante :
/etc/puppet/code/environments/testing/manifests/site.pp
Ce fichier contient les éléments suivants :

file {'/tmp/example.txt':
 ensure  => present,
 mode    => "0644",
 content => "From The Testing Environment \n",
}

C’est presque identique au fichier dans l’environnement de développement, la seule différence étant que le texte du fichier indique qu’il provient de l’environnement de test.

Évaluation de la nouvelle configuration de Puppet à partir de l’environnement de test

Par défaut, le nœud de l’agent se synchronise uniquement avec l’environnement de développement. Nous allons d’abord demander manuellement à l’agent Puppet de se synchroniser avec le serveur maître Puppet, puis de créer et d’appliquer le site.pp que nous avons créé dans l’environnement de développement.

Cela se fait avec la commande suivante :

puppet agent --environment=production --test

L’option --test permet à l’agent Puppet d’exécuter un catalogue au premier plan avec une journalisation détaillée. Toutes les mises à jour ou modifications seront appliquées au nœud.

L’option --environment=production est là pour indiquer clairement que nous synchronisons à partir de l’environnement de production. En général, cela est configuré dans la configuration principale de l’agent Puppet et n’a pas besoin d’être inclus dans la commande.

Lorsque la commande ci-dessus est exécutée, nous obtenons le résultat suivant :

  Info: Using configured environment 'production'
  Info: Retrieving pluginfacts
  Info: Retrieving plugin
  Info: Retrieving locales
  Info: Loading facts
  Info: Caching catalog for digital-2.net
  Info: Applying configuration version '1527680694'
  Notice: /Stage[main]/Main/File[/tmp/example.txt]/ensure: defined content as '{md5}59f9ce1d4aad5fd155db7ccc2478a93b'
  Notice: Applied catalog in 0.02 seconds

Ce résultat indique que le fichier /tmp/example.txt n’était pas présent et que l’agent Puppet l’a créé comme indiqué dans le manifeste site.pp. Les exécutions suivantes n’auront pas les lignes Notice : car le fichier /tmp/example.txt existe avec le contenu correct.

Maintenant que l’état du nœud d’agent correspond au manifeste de l’environnement de développement, nous pouvons tester ce qui se passerait si nous appliquions le manifeste alternatif à partir de l’environnement de test.

Afin de tester et de ne pas valider la nouvelle configuration, nous devons exécuter la commande suivante :

puppet agent --environment=testing --test --noop

Comme vous pouvez le voir, l’option --environment a été remplacée par testing et nous avons inclus l’option supplémentaire --noop. Cette option permet à l’agent d’effectuer une exécution à blanc. Cela signifie que l’agent Puppet n’apportera aucune modification réelle au nœud de l’agent, mais produira toute la sortie comme s’il l’avait fait.

Cela nous permet d’évaluer ce qui se serait passé si la nouvelle configuration avait été appliquée au serveur. Dans ce cas, le résultat de la commande ci-dessus ressemble à :

  Info: Using configured environment 'testing'
  Info: Retrieving pluginfacts
  Info: Retrieving plugin
  Info: Retrieving locales
  Info: Loading facts
  Info: Applying configuration version '1527683748'
  Notice: /Stage[main]/Main/File[/tmp/example.txt]/content:
  --- /tmp/example.txt    2018-05-30 12:19:16.205774048 +0000
  +++ /tmp/puppet-file20180530-21610-8ipzur      2018-05-30 12:35:48.740982652 +0000
  @@ -1 +1 @@
  -From The Development Environment
  +From The Testing Environment

  Notice: /Stage[main]/Main/File[/tmp/example.txt]/content: current_value '{md5}59f9ce1d4aad5fd155db7ccc2478a93b', should be '{md5}abbb8f68df144a5673d
  62ae6c4a036ed' (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.04 seconds

Les lignes les plus intéressantes ici sont les suivantes :

  -From The Development Environment
  +From The Testing Environment

Ceux-ci indiquent avec le symbole moins ( - ) ce qui est changé et avec le symbole plus ( + ) ce qui est changé. Dans cet exemple, il s’agit du texte du fichier.

Tout ce résultat indique que la nouvelle configuration aurait été appliquée avec succès et que le contenu de /tmp/example.txt aurait été modifié. S’il s’agit de l’état souhaité du serveur de production, les modifications apportées au fichier site.pp peuvent être effectuées en toute sécurité dans l’environnement de production.

Identification d’une erreur

La nouvelle configuration de Puppet n’est pas toujours appliquée sans erreur et c’est la raison pour laquelle elle doit toujours être testée avant d’être appliquée à un système de production. Nous allons forcer une erreur dans cette situation en faisant une erreur délibérée dans le fichier de test site.pp. Nous allons essayer de définir les permissions du fichier à 0944, ce qui n’est pas une permission valide et provoquera une erreur.

Maintenant, lorsque nous exécutons :

  # puppet agent --environment=testing --test --noop

Nous verrons le résultat suivant :

  Info: Using configured environment 'testing'
  Info: Retrieving pluginfacts
  Info: Retrieving plugin
  Info: Retrieving locales
  Info: Loading facts
  Error: Failed to apply catalog: Parameter mode failed on File[/tmp/example.txt]: The file mode specification is invalid: "0944" (file: /etc/puppetcode/environments/testing/manifests/site.pp, line: 1)

La capture d’écran suivante montre cette sortie telle qu’elle serait présentée sur la ligne de commande :

Puppet indiquera toute erreur en les imprimant en rouge.

Les couleurs nous indiquent immédiatement qu’il y aurait eu une erreur lors de la tentative d’utilisation de la nouvelle configuration de Puppet à partir de l’environnement de test. Cependant, lorsque nous avons utilisé l’option --noop, aucune erreur n’a été commise sur le serveur de production.

Conclusion

Lors de l’exécution de systèmes de production gérés par Puppet, il est toujours important de tester toute nouvelle configuration avant qu’elle ne soit appliquée. L’utilisation des outils fournis par Puppet pour créer des environnements alternatifs où de nouvelles configurations peuvent être créées en toute sécurité et évaluées par rapport aux systèmes de production signifie moins d’erreurs et moins de temps d’arrêt.