Marionnette - Environnement

Dans le modèle de développement et de livraison de logiciels, il existe différents types d'environnements de test qui sont utilisés pour tester un produit ou un service particulier. En tant que pratique standard, il existe principalement trois types d'environnements: développement, test et production, chacun d'entre eux ayant sa propre configuration d'ensemble.

Puppet prend en charge la gestion de plusieurs environnements sur la même ligne que Ruby on Rails. Le facteur clé derrière la création de ces environnements est de fournir un mécanisme simple de gestion à différents niveaux d'accord SLA. Dans certains cas, la machine doit toujours être opérationnelle sans aucune tolérance et utilisation d'anciens logiciels. Où d'autres environnements sont à jour et sont utilisés à des fins de test. Ils sont utilisés pour les mises à niveau de machines plus importantes.

Puppet recommande de s'en tenir à la configuration standard de l'environnement de production, de test et de développement, cependant, ici, il offre même à l'utilisateur un effet de levier pour créer des environnements personnalisés selon les besoins.

Objectif environnemental

L'objectif principal de la configuration fractionnée par un environnement est que Puppet puisse avoir différentes sources pour les modules et les manifestes. On peut alors tester les changements de configuration dans l'environnement de test sans impacter les nœuds de production. Ces environnements peuvent également être utilisés pour déployer une infrastructure sur différentes sources de réseau.

Utilisation de l'environnement sur Puppet Master

Le but d'un environnement est de tester quel manifeste, module, modèle du fichier doit être envoyé au client. Ainsi, Puppet doit être configuré pour fournir une source spécifique à l'environnement pour ces informations.

Les environnements Puppet sont implémentés simplement en ajoutant les sections de pré-environnement au puppet.conf du serveur et en choisissant une source de configuration différente pour chaque environnement. Ces sections pré-environnement sont ensuite utilisées de préférence à la section principale.

[main] 
manifest = /usr/testing/puppet/site.pp 
modulepath = /usr/testing/puppet/modules 
[development] 
manifest = /usr/testing/puppet/development/site.pp 
modulepath = /usr/testing/puppet/development/modules

Dans le code ci-dessus, tout client de l'environnement de développement utilisera le fichier manifeste site.pp situé dans le répertoire /usr/share/puppet/development et Puppet recherchera n'importe quel module dans /usr/share/puppet/development/modules directory.

L'exécution de Puppet avec ou sans environnement serait par défaut le fichier site.pp et le répertoire spécifié dans les valeurs manifest et modulepath dans la section de configuration principale.

Il n'y a que quelques configurations qui ont du sens pour être configurées au préenvironnement, et tous ces paramètres tournent autour de la spécification des fichiers à utiliser pour compiler la configuration d'un client.

Voici les paramètres.

  • Modulepath- Dans Puppet, en tant que mode standard de base, il est préférable d'avoir un répertoire de module standard que tous les environnements partagent, puis un répertoire de pré-environnement où le module personnalisé peut être stocké. Le chemin du module est l'emplacement où Puppet recherche tous les fichiers de configuration liés à l'environnement.

  • Templatedir- Le répertoire des modèles est l'emplacement où toutes les versions des modèles associés sont enregistrées. Le module doit être préféré à ces paramètres, mais il permet d'avoir différentes versions d'un modèle donné dans chaque environnement.

  • Manifest - Ceci définit la configuration à utiliser comme script de point d'entrée.

Avec plusieurs modules, Puppets aide à obtenir la modularité des configurations. On peut utiliser plusieurs environnements dans Puppet qui fonctionne beaucoup mieux si l'on s'appuie largement sur des modules. Il est plus facile de migrer les modifications vers les environnements en encapsulant les modifications dans le module. Le serveur de fichiers utilise un chemin de module spécifique à l'environnement; si l'on fait le service de fichiers à partir de modules, au lieu de répertoires montés séparés, cet environnement sera capable d'obtenir des fichiers spécifiques à l'environnement et enfin l'environnement actuel sera également disponible dans la variable $ environment dans le fichier manifeste.

Définition de l'environnement des clients

Toutes les configurations liées à la configuration de l'environnement se font sur le fichier puppet.conf. Pour spécifier l'environnement que le client Puppet doit utiliser, on peut spécifier une valeur pour la variable de configuration d'environnement dans le fichier puppet.conf du client.

[puppetd] 
environment = Testing

La définition ci-dessus dans le fichier de configuration définit l'environnement dans lequel le fichier de configuration est dans notre cas test.

On peut également le spécifier sur la ligne de commande en utilisant -

#puppetd -–environment = testing

Alternativement, Puppet prend également en charge l'utilisation de valeurs dynamiques dans la configuration de l'environnement. Plutôt que de définir les valeurs statiques, le développeur a un effet de levier pour créer des faits personnalisés qui créent un environnement client basé sur certains autres attributs client ou une source de données externe. La meilleure façon de procéder consiste à utiliser un outil personnalisé. Ces outils sont capables de spécifier l'environnement d'un nœud et sont généralement bien meilleurs pour spécifier les informations de nœud.

Chemin de recherche de marionnettes

Puppet utilise un chemin de recherche simple pour déterminer la configuration à appliquer sur la machine cible. De la même manière, le chemin de recherche dans Puppet est très utile lorsqu'il tente de sélectionner les valeurs appropriées qui doivent être appliquées. Il existe plusieurs emplacements répertoriés ci-dessous où Puppet recherche les valeurs qui doivent être appliquées.

  • Valeur spécifiée dans la ligne de commande
  • Valeurs spécifiées dans une section spécifique à l'environnement
  • Valeurs spécifiées dans une section spécifique à l'exécutable
  • Valeurs spécifiées dans la section principale