Auparavant, les administrateurs système utilisaient des scripts shell pour exécuter leurs serveurs, et cette méthode n'avait aucune évolutivité. Modifier constamment les scripts de centaines ou de milliers de serveurs en constante évolution et de leurs configurations système est une tâche ardue.
Dans cet article sur modules et manifestes de marionnettes voyons comment nous pourrions utiliser les modules puppet pour automatiser la configuration du serveur, l'installation de programmes et la gestion du système.
Ce blog couvrira les sujets suivants:
- Introduction à la programmation de marionnettes
- Termes clés de la programmation de marionnettes
- Flux de travail du programme Puppet
- Démonstration: Automatiser l'installation d'Apache et MySQL
Introduction à la programmation de marionnettes
Fantoche est l'un des outils DevOps les plus couramment utilisés pour la gestion de la configuration. Il est utilisé pour provoquer cohérence dans l'infrastructure. Puppet peut définir l'infrastructure en tant que code, gérer plusieurs serveurs et appliquer la configuration du système, aidant ainsi à automatiser le processus de gestion de l'infrastructure.
La marionnette ason propre langage de configuration, Puppet DSL . Comme avec les autres programmes DevOps, Puppet automatise les modifications, éliminant les modifications manuelles pilotées par des scripts. Cependant, Puppet n'est pas simplement un autre langage shell, ni un pur langage de programmation, tel que PHP. Au lieu de cela, Puppet utiliseà approche déclarative basée sur un modèle à l'automatisation informatique. Cela permet à Puppet de définir l'infrastructure en tant que code et d'appliquer la configuration du système avec des programmes.
Avant de commencer la démo, examinons quelques aspects fondamentaux de la programmation de marionnettes.
comment utiliser br en html
Termes clés de la programmation de marionnettes
Manifestes
Un programme de marionnettes est appelé manifeste et a un nom de fichier avec .pp extension. Le manifeste principal par défaut de Puppet est /etc/puppet/manifests/site.pp . (Cela définitconfigurations système globales, telles que la configuration LDAP, les serveurs DNS ou d'autres configurations qui s'appliquent à chaque nœud).
Des classes
Dans ces manifestes se trouvent des blocs de code appelés Des classes d'autres modules peuvent appeler. Les classes configurent des blocs de fonctionnalités de grande ou moyenne taille, tels que tous les packages, fichiers de configuration et services nécessaires pour exécuter une application. Les classes facilitent la réutilisation du code Puppet et améliorent la lisibilité.
Ressources
Le code Puppet est constitué principalement de déclarations de ressources. UNE Ressource décrit un élément spécifique concernant l’état souhaité du système. Par exemple, cela peut inclure qu'un fichier spécifique doit exister ou qu'un package doit être installé.
Modules de marionnettes
Sauf pour le principalsite.ppmanifeste,il stocke les manifestesdans modules .
Tout notre code Puppet est organisé en modules qui sont les éléments de base de Puppet que nous pouvons réutiliser et partager. Chaque module gère une tâche spécifique dans l'infrastructure, comme l'installation et la configuration d'un logiciel.
Les modules contiennent des classes Puppet, des types définis, des tâches, des plans de tâches, des capacités, des types de ressources et des plugins, par exemple des types ou des faits personnalisés. Installer des modules dans le Puppetchemin-module. Puppet charge tout le contenu de chaque module dans le chemin du module, rendant ce code disponible pour utilisation.
Puppetlabs a des modules prédéfinis que nous pouvons utiliser instantanément en les téléchargeant depuis MarionnetteForge . Vous pouvez également créer un module de marionnettes personnalisé en fonction de vos besoins.
Flux de travail du programme Puppet
Nous utiliserons le langage déclaratif de Puppet pour décrire l'état souhaité du système dans des fichiers appelés manifestes. Les manifestes décrivent comment vous devez configurer les ressources de votre réseau et du système d'exploitation, telles que les fichiers, les packages et les services.
Puppet compile les manifestes en catalogues et il applique chaque catalogue à son nœud correspondant pour garantir que la configuration de tle nœud est correctà travers votre infrastructure.
Manifestation: Automatiser l'installation d'Apache et MySQL
Cet article sur les modules de marionnettes est pratique qui montre deux façons d'utiliser un module de marionnettes et vous apprend également à automatiser l'installation d'un serveur configuré avec ces deux modules.
Pour commencer, assurez-vous que vous disposez d'une infrastructure Puppet prête à inclure un serveur maître Puppet et 2 agents Puppet.
- Maître des marionnettes: Ubuntu 18.04
- Agent 1: Ubuntu 18.04
- Agent 2:CentOS7
Voici un aperçu de ce que nous accomplirons dans cette pratique:
Commençons donc par la pratique:
Créer un module à partir de zéro
Dans ce module marionnette, nous traiterons des tâches telles que le téléchargement du package Apache, la configuration des fichiers et la configuration des hôtes virtuels.
- Depuis Puppet Master, accédez au répertoire des modules de Puppet et créez le répertoire Apache:
cd / etc / puppet / modules sudo mkdir apache
- Depuis l'intérieur du répertoire apache, créez des sous-répertoires: manifestes, modèles, fichiers et exemples.
cd apache sudo mkdir {manifestes, modèles, fichiers, exemples} - Accédez au répertoire manifestes:
manifestes cd
- À partir de là, nous allons séparer le module en classes en fonction des objectifs de cette section de code.
init.pp -> pour télécharger le package Apache
params.pp -> pour définir des variables et des paramètres
config.pp -> pour gérer les fichiers de configuration du service Apache.
vhosts.pp -> pour définir les hôtes virtuels.
Ce module utilisera également Hiera (un système intégré de recherche de données de configuration clé-valeur, utilisé pour séparer les données du code Puppet), pour stocker des variables pour chaque nœud.
Étape 1: Téléchargement du package Apache
Créer une classe init.pp
Maintenant, nous allons créer uninit.ppdans le répertoire manifestes pour contenir le package apache.
Comme nous avons 2 OS différents (ubuntu et CentOS7) qui utilisent des noms de packages différents pour Apache, nous devrons utiliser une variable$ apachename.
/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp
classe apache {package {'apache': name => $ apachename, ensure => present,}}paquet resource permet la gestion d'un package. Ceci est utilisé pour ajouter, supprimer ou s'assurer qu'un package est présent.
Dans la plupart des cas, le Nom de la ressource (apache, ci-dessus) doit être le nom du package géré. En raison des différentes conventions de dénomination,nous appelons le nom réel du packageavec le Nom référence. Donc Nom , appelle la variable encore indéfinie$ apachename.
assurer référence garantit que le package estprésent.
Créer un fichier params.pp
Laparams.ppfichier définira les variables nécessaires. Bien que nous puissions définir ces variables dans leinit.ppfichier, car plus de variables devront être utilisées en dehors du type de ressource lui-même, en utilisant unparams.ppfichier permet de définir des variables danssiinstructions et utilisé dans plusieurs classes.
Créer unparams.ppfichier et le code suivant.
/etc/puppetlabs/code/environments/production/modules/apache/manifests/params.pp
class apache :: params {if $ :: osfamily == 'RedHat' {$ apachename = 'httpd'} elsif $ :: osfamily == 'Debian' {$ apachename = 'apache2'} else {fail ('this is not une distribution prise en charge. ')}}En dehors de l'original init.ppclasse, chaque nom de classe doit dériver deapache. Nous appelons cette classe comme apache :: params . Le nom après le double deux-points doit partager un nom avec le fichier. Unesiinstruction est utilisée pour définir les paramètres, en tirant des informations fournies par Facteur , Puppet a une installation facter dans le cadre de son installation elle-même. Ici, Facter déroulera la famille de systèmes d'exploitation (osfamille), pour discerner si c'estchapeau rougeouBasé sur Debian.
Une fois les paramètres définis, nous devons appeler le params.pp fichier et les paramètres dansinit.pp. Pour ce faire, nous devons ajouter les paramètres après le nom de la classe, mais avant le crochet ouvrant({).
Alors leinit.ppque nous avons créé plus tôt devrait ressembler à ceci:
classe apache ($ apachename = $ :: apache :: params :: apachename,) hérite de :: apache :: params {package {'apache': name => $ apachename, ensure => present,}}La chaîne de valeur $ :: apache :: params :: value demande à Puppet d'extraire les valeurs du apache modules, paramètres class, suivi du nom du paramètre. Le fragment hérite :: apache :: params permetinit.pphériter de ces valeurs.
Étape 2: Gérer les fichiers de configuration
Le fichier de configuration Apache sera différent selon que vous travaillez sur un système basé sur Red Hat ou Debian.
Vous pouvez trouver les fichiers de dépendances suivants à la fin de cette démo:httpd.conf(Chapeau rouge),apache2.conf(Debian).
- Copiez le contenu de
httpd.confetapache2.confdans des fichiers séparés et enregistrez-les dans le des dossiers annuaireà/ etc / puppetlabs / code / environnements / production / modules / apache / fichiers. - Modifiez les deux fichiers en désactiver rester en vie. Vous devrez ajouter la ligne KeepAlive Off dans le
httpd.conffichier. Si vous ne souhaitez pas modifier ce paramètre, nous devons ajouter un commentaire en haut de chaquefichier:
/etc/puppetlabs/code/environments/production/modules/apache/files/httpd.conf
#Ce fichier est géré par puppet
Ajoutez ces fichiers auinit.ppafin que Puppet connaisse l'emplacement de ces fichiers sur le serveur maître et les nœuds d'agent. Pour ce faire, nous utilisons le fichier Ressource.
/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp
file {'configuration-file': path => $ conffile, ensure => file, source => $ confsource,}Parce que nous avons les fichiers de configuration à deux emplacements différents, nous donnons à la ressource le nom générique fichier de configuration avec le fichier chemin défini comme paramètre avec lecheminattribut.
assurer garantit qu'il s'agit d'un fichier.
la source fournit l'emplacement sur le Puppet master des fichiers créés ci-dessus.
Ouvrez leparams.ppfichier.
Nous définissons le $ conffile et $ confsourcevariables dans lesidéclaration:
/etc/puppetlabs/code/environments/production/modules/apache/manifests/params.pp
if $ :: osfamily == 'RedHat' {... $ conffile = '/etc/httpd/conf/httpd.conf' $ confsource = 'puppet: ///modules/apache/httpd.conf'} elsif $: : osfamily == 'Debian' {... $ conffile = '/etc/apache2/apache2.conf' $ confsource = 'puppet: ///modules/apache/apache2.conf'} else {...Nous devons ajouter les paramètres au début de laapachedéclaration de classe dans leinit.ppfichier, similaire à l'exemple précédent.
Lorsque le fichier de configuration change, Apache doit redémarrer. Pour automatiser cela, nous pouvons utiliser la ressource de serviceen combinaison avec le notifier attribut, qui appellera la ressource à exécuter chaque fois que le fichier de configuration est modifié:
/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp
file {'configuration-file': path => $ conffile, ensure => file, source => $ confsource, notify => Service ['apache-service'],} service {'apache-service': name => $ apachename, hasrestart => true,} un service resource utilise le paramètre déjà créé qui a défini le nom Apache sur les systèmes Red Hat et Debian.
hasrestart L'attribut est utilisé pour déclencher un redémarrage du service défini.
Étape 3: Créez les fichiers d'hôte virtuel
En fonction de la distribution de votre système, les fichiers de l’hôte virtuel seront gérés différemment. Pour cette raison, nous encapsulerons le code des hôtes virtuels dans unsidéclaration, similaire à celle utilisée dans leparams.ppclasse mais contenant des ressources réelles Puppet.
- De l'intérieur duapache / manifestes /répertoire, créez et ouvrez un
vhosts.ppfichier. Ajoutez le squelette dusidéclaration:
/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp
classe apache :: vhosts {if $ :: osfamily == 'RedHat' {} elsif $ :: osfamily == 'Debian' {} else {}}L'emplacement du fichier d'hôte virtuel sur notre serveur CentOS 7 est/etc/httpd/conf.d/vhost.conf . Vous devez créer le fichier en tant que modèle sur le maître des marionnettes. Faites de même pour le fichier d'hôtes virtuels Ubuntu, qui se trouve à/etc/apache2/sites-available/example.com.conf, en remplaçantexample.comavec le nom de domaine complet du serveur.
- Accédez au modèles fichier dans le apache module, puis créez deux fichiers pour vos hôtes virtuels:
Pour les systèmes Red Hat:
/etc/puppetlabs/code/environments/production/modules/apache/templates/vhosts-rh.conf.erb
ServerAdmin ServerName ServerAlias www. DocumentRoot / var / www // public_html / ErrorLog /var/www//logs/error.log CustomLog /var/www//logs/access.log combiné
Pour les systèmes Debian:
/etc/puppet/modules/apache/templates/vhosts-deb.conf.erb
Salaire Java Developers Inde
ServerAdmin ServerName ServerAlias www. DocumentRoot / var / www / html // public_html / ErrorLog /var/www/html//logs/error.log CustomLog /var/www/html//logs/access.log combinéExiger tout accordé
Nous n'utilisons que deux variables dans ces fichiers: adminemail et nom du serveur . Nous les définirons nœud par nœud, dans lesite.ppfichier.
- Revenir au
vhosts.ppfichier. Les modèles créés peuvent désormais être référencés dans le code:
/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp
class apache :: vhosts {if $ :: osfamily == 'RedHat' {fichier {'/etc/httpd/conf.d/vhost.conf': ensure => file, content => template ('apache / vhosts-rh .conf.erb '),}} elsif $ :: osfamily ==' Debian '{fichier {' /etc/apache2/sites-available/$servername.conf ': ensure => file, content => template (' apache /vhosts-deb.conf.erb '),}} else {fail (' Ceci n'est pas une distribution prise en charge. ')}}Les deux familles de distribution appellent à lafichieret prendre le titre de l’emplacement de l’hôte virtuel sur la distribution respective. Pour Debian, cela signifie une fois de plus référencer le$ nom_serveurvaleur. Lacontenul'attribut appelle les modèles respectifs.
- Les deux fichiers d'hôte virtuel font référence à deux répertoires. Ils ne sont pas sur les systèmes par défaut. Nous pouvons les créer grâce à l'utilisation dufichierressource, chacun dans lesidéclaration. Le complet
vhosts.confle fichier doit ressembler à:
/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp
php transforme la chaîne en tableau
class apache :: vhosts {if $ :: osfamily == 'RedHat' {fichier {'/etc/httpd/conf.d/vhost.conf': ensure => file, content => template ('apache / vhosts-rh .conf.erb '),} fichier {[' / var / www / $ nom_serveur ',' / var / www / $ nom_serveur / public_html ',' / var / www / $ nom_serveur / log ',]: ensure => répertoire,}} elsif $ :: osfamily == 'Debian' {fichier {'/etc/apache2/sites-available/$servername.conf': ensure => file, content => template ('apache / vhosts-deb. conf.erb '),} fichier {[' / var / www / $ servername ',' / var / www / $ servername / public_html ',' / var / www / $ servername / logs ',]: ensure => répertoire ,}} else {fail ('Ceci n'est pas une distribution prise en charge.')}}Étape 4: Testez le module
- Accédez au
apache / manifestes /répertoire, exécutez le analyseur de marionnettes sur tous les fichiers pour s'assurer que le codage Puppet est sans erreur:
sudo / opt / puppetlabs / bin / puppet parser valider init.pp params.pp vhosts.pp
Il devrait revenir vide, sans problème.
- Accédez au exemples répertoire dans leapachemodule. Créé un
init.ppfichier et incluez les classes créées. Remplacez les valeurs de$ nom_serveuret$ adminemailavec le vôtre:
/etc/puppetlabs/code/environments/production/modules/apache/examples/init.pp
serveremail = 'webmaster@example.com' $ servername = 'puppet.example.com' inclure apache include apache :: vhosts
- Testez le module en exécutant marionnette appliquer avec le –Noop marque:
sudo / opt / puppetlabs / bin / puppet apply --noop init.pp
Il ne doit renvoyer aucune erreur et indiquer qu'il déclenchera des actualisations à partir d'événements. Pour installer et configurer Apache sur Puppet Master, réexécutez sans–Noop, si vous le souhaitez.
- Revenez au répertoire principal de Puppet, puis aumanifestedossier (ne pascelui présent dans le module Apache).
cd / etc / puppetlabs / code / environnements / production / manifestes
Créer unsite.ppfichier,et incluez le module Apache pour chaque nœud d'agent. Saisissez également les variables duadminemail et nom du serveurparamètres. Votresite.ppdevrait ressembler à ce qui suit:
/etc/puppetlabs/code/environments/production/manifests/site.pp
node 'puppet-agent-ubuntu.example.com' {$ adminemail = 'webmaster@example.com' $ servername = 'puppet.example.com' include apache include apache :: vhosts} node 'puppet-agent-centos.example .com '{$ adminemail =' webmaster@example.com '$ servername =' puppet.example.com 'include apache include apache :: vhosts}Par défaut, le service d'agent Puppet sur vos nœuds gérés vérifiera automatiquement avec le maître toutes les 30 minutes et appliquera toutes les nouvelles configurations du maître. Vous pouvez également appeler manuellement le processus de l'agent Puppet entre les exécutions automatiques de l'agent. Pour exécuter manuellement le nouveau module sur vos nœuds d'agent, connectez-vous aux nœuds et exécutez:
sudo / opt / puppetlabs / bin / agent de marionnettes -t
Maintenant que nous avons appris à créer un module à partir de zéro, apprenons à utiliser un module préexistant de la forge de marionnettes de puppetlabs.
Utilisez un module de PuppetForge
Forge de marionnettes a déjà de nombreux modules pour le serveur à exécuter. Nous pouvons les configurer tout aussi largement qu'un module que vous avez créé et pouvons gagner du temps car nous n'avons pas besoin de créer le module à partir de zéro.
Assurez-vous que vous êtes dans le / etc / puppetlabs / code / environnements / production / modules répertoire et installez le Module MySQL de Puppet Forge par PuppetLabs. Cela installera également tous les modules prérequis.
cd / etc / puppetlabs / code / environnements / production / modules
sudo / opt / puppetlabs / bin / puppet module installer puppetlabs-mysql
Utilisez Hiera pour créer des bases de données
Avant de créer les fichiers de configuration pour le module MySQL, considérez que vous ne souhaiterez peut-être pas utiliser les mêmes valeurs sur tous les nœuds d'agent. Pour fournir à Puppet les données correctes par nœud, nous utilisons Hiera. Vous utiliserez un mot de passe root différent par nœud, créant ainsi différentes bases de données MySQL.
- Aller vers
/ etc / puppetet créez le fichier de configuration de Hierahiera.yamlen généralfantocheannuaire. Vous utiliserez les valeurs par défaut de Hiera:
/etc/puppetlabs/code/environments/production/hiera.yaml
--- version: 5 hiérarchie: - nom: Chemin commun: common.yaml par défaut: data_hash: yaml_data datadir: data
- Créer le fichier
common.yaml. Il définira la valeur par défaut racine mot de passe pour MySQL:
/etc/puppetlabs/code/environments/production/common.yaml
mysql :: server :: root_password: 'mot de passe'
Nous utilisons lecommon.yamlfichierlorsqu'une variable n'est pas définie ailleurs. Cela signifie que tous les serveurs partageront le même mot de passe root MySQL. Ces mots de passe peuvent également être hachés pour augmenter la sécurité.
- Pour utiliser les paramètres par défaut du module MySQL, vous pouvez ajouter un inclure ‘:: mysql :: server’ ligne à la
site.ppfichier. Cependant, dans cet exemple, vous remplacerez certaines des valeurs par défaut du module pour créer une base de données pour chacun de vos nœuds.
Modifier lesite.ppfichier avec les valeurs suivantes:
node 'Puppetagent-ubuntu.example.com' {$ adminemail = 'webmaster@example.com' $ servername = 'hostname.example.com' include apache include apache :: vhosts include mysql :: server mysql :: db {'mydb_ $ {fqdn} ': user =>' myuser ', password =>' mypass ', dbname =>' mydb ', host => $ :: fqdn, grant => [' SELECT ',' UPDATE '], tag = > $ domain,}} node 'Puppetagent-centos.example.com' {$ adminemail = 'webmaster@example.com' $ servername = 'hostname.example.com' include apache include apache :: vhosts include mysql :: server mysql :: db {'mydb _ $ {fqdn}': user => 'myuser', password => 'mypass', dbname => 'mydb', host => $ :: fqdn, grant => ['SELECT', ' UPDATE '], tag => $ domaine,}}Automatisation de l'installation des modules Puppet du maître de marionnette à l'agent de marionnette
- Vous pouvez exécuter ces mises à jour manuellement sur chaque nœud en SSHing dans chaque nœud et en émettant la commande suivante:
sudo / opt / puppetlabs / bin / agent de marionnettes -t
- Sinon, le service d'agent Puppet sur vos nœuds gérés vérifiera automatiquement avec le maître toutes les 30 minutes et appliquera toutes les nouvelles configurations du maître.
Catalogue appliqué avec succès sur l'agent Ubuntu
Catalogue appliqué avec succès sur l'agent CentOS
Ainsi, toute l'installation obtient automatique sur les nœuds d'agent en appliquant simplement le catalogue.Les fichiers de code et les dépendances utilisés pour cette démo peuvent être trouvés Ici .
J'espère que cette démo vous a aidé à vous faire une idée claire des modules et manifestes marionnettes et de leur utilisation pour automatiser l'infrastructure informatique.Dans ce cas, votre travail devient si simple, il suffit de spécifier les configurations dans Puppet Master et les agents Puppet évalueront automatiquement le manifeste principal et appliqueront le module qui spécifie la configuration d'Apache et de MySQL. Si vous êtes coincé avec des questions, n'hésitez pas à les poster sur .
Si vous avez trouvé ceci Tutoriel sur les marionnettes pertinent, Vérifiez par Edureka, une entreprise d'apprentissage en ligne de confiance avec un réseau de plus de 250 000 apprenants satisfaits répartis dans le monde entier. Le cours de formation à la certification Edureka DevOps aide les apprenants à acquérir une expertise dans divers processus et outils DevOps tels que Puppet, Jenkins, Nagios et GIT pour automatiser plusieurs étapes dans SDLC.