maison › Conseil › Master of Puppets : Installation et configuration du système de gestion de configuration à distance Puppet. Master of Puppets : Installation et configuration du système de gestion de configuration à distance Puppet Installation de Puppet

Master of Puppets : Installation et configuration du système de gestion de configuration à distance Puppet. Master of Puppets : Installation et configuration du système de gestion de configuration à distance Puppet Installation de Puppet

Pour utiliser Puppet plus efficacement, vous devez comprendre comment les modules et les manifestes sont créés. Ce didacticiel vous expliquera le fonctionnement de ces composants Puppet en configurant une pile LAMP sur un serveur Ubuntu 14.04.

Exigences

Installation de Puppet (maître et agent). Plus à ce sujet -.
La possibilité de créer au moins un serveur virtuel Ubuntu 14.04 pour servir le nœud de l'agent Puppet.

Bases du code des marionnettes

Ressources

Le code Puppet est principalement constitué de ressources. Une ressource est un morceau de code qui décrit l'état du système et détermine les modifications dont il a besoin. Par exemple:

utilisateur("mitchell":
assurer => présent,
uid => "1000",
gid => "1000",
shell => "/bin/bash",
maison => "/maison/mitchell"
}

La déclaration de ressource a le format suivant :

type_ressource("nom_ressource"
attribut => valeur
...
}

Pour afficher tous les types de ressources Puppet, exécutez la commande :

ressource de marionnette --types

Vous en apprendrez davantage sur les types de ressources dans ce guide.

Manifestes

Un manifeste est un script d'orchestration. Les programmes Puppet avec une extension .pp sont appelés manifestes. Le manifeste Puppet par défaut est /etc/puppet/manifests/site.pp.

Des classes

Comme dans tout langage de programmation classique, les classes sont responsables de l’organisation et de la réutilisation de parties de l’orchestration.

Dans une définition de classe se trouve un bloc de code qui décrit le fonctionnement de la classe. Une fois que vous avez défini une classe, vous pouvez l'utiliser dans des manifestes.

La définition de classe a le format suivant :

classe exemple_classe (
...
code
...
}

Ce code définit la classe example_class. Le code Puppet sera entre accolades.

Une déclaration de classe est l'endroit dans le code où une classe particulière est appelée. Avec une déclaration de classe, Puppet traite son code.

La déclaration de classe peut être ordinaire et par type de ressource.

Une déclaration de classe normale est ajoutée au code à l'aide du mot clé include.

inclure example_class

Lorsqu'elle est déclarée comme type de ressource, la classe est déclarée au format de ressource :

classe("exemple_classe":)

Cette déclaration vous permet d'ajouter des paramètres de classe à votre code qui remplacent les valeurs par défaut des attributs de classe. Par exemple:

nœud "host2" (
classe ("apache": ) # utiliser le module apache
apache::vhost ( "example.com": # définir la ressource vhost
port => "80",
docroot => "/var/www/html"
}
}

Modules

Un module est un groupe de manifestes et d'autres fichiers organisés de manière prédéfinie qui facilite le partage et la réutilisation de parties individuelles de l'orchestration. Les modules aident à organiser le code Puppet car ils peuvent être utilisés pour séparer le code en plusieurs manifestes.

Les modules Puppet sont stockés dans le répertoire /etc/puppet/modules.

Rédaction d'un manifeste

Vous pouvez vous entraîner à écrire des manifestes, des modules et des classes Puppet en utilisant l'exemple de l'installation d'une pile LAMP sur un serveur Ubuntu (le résultat sera ).

Ainsi, pour orchestrer un serveur Ubuntu 14.04 et y installer une pile LAMP, vous avez besoin de ressources pour les actions suivantes :

installation du paquet apache2.
démarrer le service apache2.
installation du paquet Serveur MySQL, serveur mysql.
démarrer le service MySQL.
installation du paquet php5
création d'un script de test PHP, info.php.
mettre à jour l'index apt avant d'installer chaque package.

Vous trouverez ci-dessous trois exemples de code Puppet qui peuvent être utilisés pour réaliser une telle configuration de pile LAMP.

Le premier exemple vous apprendra comment écrire des manifestes de base dans un seul fichier. Le deuxième exemple vous aidera à assembler et à utiliser une classe et un module basés sur des manifestes précédemment écrits. Le troisième exemple vous montrera comment utiliser des modules publics prédéfinis pour installer une pile LAMP.

Note: Pour les tests, il est préférable d'utiliser un nouveau serveur virtuel.

Exemple 1 : Installation de LAMP avec un seul manifeste

Le manifeste Puppet peut être écrit sur le nœud de l'agent, puis exécuté à l'aide de la commande puppet apply (vous n'avez pas besoin d'une configuration maître et agent pour ce faire).

Dans cette section, vous apprendrez à rédiger des manifestes qui utiliseront ces types de déclarations de ressources :

exec : exécute des commandes.
package : installer les packages.
service : gestion des services.
fichier : gestion des fichiers.

Créer un manifeste

Créez un nouveau manifeste :

sudo vi /etc/puppet/manifests/lamp.pp

Ajoutez-y le code suivant pour déclarer les ressources requises.

# exécutez la commande "apt-get update"
exec("apt-update": # ressource exec "apt-update"
command => "/usr/bin/apt-get update" # commande que cette ressource exécutera
}
# installer le paquet apache2
paquet("apache2":
require => Exec["apt-update"], # request "apt-update" avant d'installer le package
assurer => installé,
}
# démarrer le service Apache2
service("apache2":
assurer => en cours d'exécution,
}
# installer le serveur mysql
package("serveur-mysql":
require => Exec["apt-update"], # request "apt-update" en réinstallant
assurer => installé,
}
# démarrer le service mysql
service("mysql":
assurer => en cours d'exécution,
}
# installer le paquet php5
paquet("php5":
require => Exec["apt-update"], # demande "apt-update" avant l'installation
assurer => installé,
}
# démarrer le service info.php
fichier("/var/www/html/info.php":
assurer => fichier,
contenu => "", #code phpinfo
require => Package["apache2"], # requête pour le package "apache2"
}

Appliquer un manifeste

Pour utiliser le nouveau manifeste, entrez la commande :

sudo marionnette appliquer --test

Il affichera un résultat volumineux qui affiche tous les changements dans l'état de l'environnement. S'il n'y a aucune erreur dans le résultat, vous devriez pouvoir ouvrir votre adresse IP externe ou votre nom de domaine dans votre navigateur. Un test de test apparaîtra à l'écran. Page PHP avec des informations sur la pile. Cela signifie qu'Apache et PHP fonctionnent.

La pile LAMP est maintenant installée sur le serveur à l'aide de Puppet.

Il s'agit d'un manifeste assez simple puisqu'il peut être exécuté sur un agent. Si vous n'avez pas de maître Puppet, les autres nœuds d'agent ne pourront pas utiliser ce manifeste.

Le serveur maître Puppet vérifie les changements d'état du serveur toutes les 30 minutes.

Exemple 2 : Installation d'une pile LAMP à l'aide d'un module

Essayez maintenant de créer un module simple basé sur le manifeste LAMP que vous avez écrit dans la section précédente.

Pour créer un module, créez un nouveau répertoire dans le répertoire modules (son nom doit correspondre au nom du module). Ce répertoire doit contenir un répertoire manifestes et un fichier init.pp. Le fichier init.pp spécifie la classe Puppet (son nom doit également correspondre au nom du module).

Création d'un module

Accédez au serveur maître Puppet et créez une structure de répertoires pour le module :

cd /etc/puppet/modules
sudo mkdir -p lampe/manifestes

Créez et ouvrez le fichier init.pp dans l'éditeur :

sudo vi lamp/manifests/init.pp

Insérez la classe de lampe dans le fichier :

lampe de classe (
}

Copiez le contenu du manifeste de la section 1 et collez-le dans le bloc de classe de lampe. Vous disposez désormais d’une définition de classe de lampe. D'autres manifestes pourront utiliser cette classe comme module.

Enregistrez et fermez le fichier.

Utiliser un module dans le manifeste principal

Vous pouvez maintenant configurer le manifeste principal et utiliser le module lamp pour installer la pile LAMP sur le serveur.

Sur le serveur maître Puppet, modifiez le fichier suivant :

sudo vi /etc/puppet/manifests/site.pp

Très probablement sur ce moment le fichier est vide. Ajoutez-y les lignes suivantes :

nœud par défaut ( )
nœud "lampe-1" (
}

Note: Remplacez lamp-1 par le nom d'hôte de votre agent Puppet sur lequel installer la pile.

Le bloc de nœuds vous permet de spécifier le code Puppet qui ne s'appliquera qu'à certains nœuds.

Le bloc par défaut s'applique à tous les nœuds d'agent qui n'ont pas de bloc individuel (laissez-le vide). Le bloc lamp-1 sera appliqué au nœud d’agent lamp-1.

Ajoutez la ligne suivante à ce bloc, qui utilise le module lamp :

Enregistrez et fermez le fichier.

Le nœud de l'agent Puppet pourra désormais télécharger les paramètres du serveur maître et installer la pile LAMP. Si vous souhaitez apporter des modifications maintenant, exécutez la commande sur l'agent :

agent sudo marionnette --test

Les modules constituent le moyen le plus pratique de réutiliser le code Puppet. De plus, les modules vous aident à organiser logiquement votre code.

Exemple 3 : Installation de LAMP à l'aide de modules publics

Le module MySQL est utilisé de la même manière. Ajoutez les lignes suivantes au bloc node :

classe("mysql::serveur":
root_password => "mot de passe",
}

Vous pouvez également transmettre les paramètres du module MySQL.

Ajoutez une ressource qui copiera info.php à l'emplacement souhaité. Utilisez le paramètre source. Ajoutez les lignes suivantes au bloc node :

file("info.php": # nom du fichier de ressources
chemin => "/var/www/html/info.php", # chemin cible
assurer => fichier,
require => Class["apache"], # classe Apache à utiliser
source => "puppet:///modules/apache/info.php", # emplacement où copier le fichier
}

Cette déclaration de classe utilise le paramètre source au lieu du contenu. Cette option utilise non seulement le contenu du fichier, mais le copie également.

Puppet copiera le fichier puppet:///modules/apache/info.php dans /etc/puppet/modules/apache/files/info.php.

Enregistrez et fermez le fichier.

Créez un fichier info.php.

sudo sh -c "écho""> /etc/puppet/modules/apache/files/info.php"

Le nœud de l'agent Puppet pourra désormais télécharger les paramètres du serveur maître et installer la pile LAMP. Si vous souhaitez apporter des modifications à l'environnement de l'agent dès maintenant, exécutez la commande sur ce nœud :

agent sudo marionnette --test

Cette commande téléchargera toutes les mises à jour pour le nœud actuel et installera la pile dessus. Pour vous assurer qu'Apache et PHP fonctionnent, ouvrez l'adresse IP ou le domaine du nœud dans un navigateur :

http://lamp_1_public_IP/info.php

Conclusion

Vous disposez désormais de connaissances de base sur l'utilisation des modules et des manifestes Puppet. Essayez de créer vous-même un manifeste et un module simples.

Puppet est idéal pour gérer les fichiers de configuration des applications.

Mots clés: ,
Un peu de poésie. Il semblerait que cet article devrait être le point de départ de toute la série, mais le public cible est toujours constitué d'utilisateurs plus expérimentés des produits Open Source Puppet Labs qui ne sont pas satisfaits des modules individuels mal intégrés avec Puppet Forge. Comme dans tout cas « bibliothèque contre framework », le prix à payer est de suivre la vision du monde de l’auteur de la solution intégrée.

Un peu sur le fonctionnement de Puppet

Puppet est avant tout un langage spécifique permettant de spécifier de manière déclarative l'état final du système. A titre de comparaison, le GNU Makefile est extrêmement approprié, où, en plus de la description directe des dépendances, il est possible de devenir complètement bizarre.

L'abstraction de Puppet ressemble à ceci ( briser les schémas - oubliez tout ce que vous saviez sur les termes de programmation !).

Nœud est un ensemble de configurations pour un système cible spécifique. En fait, il s’agit d’un cas particulier de classe.
Classe est un ensemble de logique déclarative incluse dans la configuration du nœud ou dans d'autres classes. La classe n'a ni instances ni méthodes, mais elle a des paramètres et des variables définis dans la logique. En fait, il s’agit plutôt d’une procédure qui peut hériter d’une autre procédure en ajoutant simplement du code et en ayant une portée de variables pas si banale.
Taper- mais cela ressemble plus à une classe classique - elle suppose des instances avec un nom et définitivement paramètres donnés, mais rien de plus. Une implémentation spécifique d'un type peut être écrite sous forme de script Puppet via Définir , qui crée des instances d'autres types, ou sous forme d'extension Ruby avec une envolée de fantaisie.
Ressource- ce sont en fait des instances nommées de types. Chaque nom de ressource est unique au sein d'un type spécifique dans la configuration du nœud (répertoire).
Variables- enfin bref, ce sont des constantes... Avant Puppet 4, les choses étaient encore pires avec leur ampleur. Désormais, c'est suffisant : pour une utilisation en dehors de l'emplacement de définition, un identifiant pleinement qualifié doit être spécifié, sauf dans le cas d'un héritage de classe.

Puppet peut être utilisé pour un déploiement local sans réseau ni infrastructure associée. Cela peut être utilisé pour créer des images de conteneurs. Il existe même tout un mouvement prônant l’abandon d’un serveur centralisé.

D'une manière idéologiquement correcte, l'infrastructure Puppet se compose d'un agent - un service privilégié sur le système cible - et d'un serveur qui distribue de précieuses instructions sous forme de répertoires de ressources déclaratifs à la demande des agents. La sécurité est mise en œuvre au niveau de l'infrastructure à clé publique privée (X.509). En termes simples, les mêmes mécanismes que dans HTTPS, mais avec sa propre autorité de certification et une vérification obligatoire certificat client.

Sous une forme simplifiée, la procédure de déploiement ressemble à ceci :

Traitement via TLS et X.509 (établissement de la connexion, mise à jour des CRL, vérification des restrictions des certificats, etc.)
L'agent reçoit des générateurs de faits du serveur avec mise en cache et tout le reste (plus précisément, tout est extrait des dossiers lib/ des modules). Il n'est pas difficile d'ajouter votre propre script Ruby pour collecter les informations qui vous intéressent.
L'agent collecte des informations sur le système cible et les envoie au serveur. Tous les faits peuvent être facilement visualisés manuellement via l'appel de faits de marionnettes. Ces faits sont disponibles sous forme de variables globales.
Le serveur compile un catalogue de ressources et l'envoie à l'agent. Derrière cela se cache toute une couche de concepts différents.
L'agent extrait tout le nécessaire du serveur et amène le système sous la forme spécifiée. L'agent lui-même ne sait pas quoi faire des ressources ; il s'appuie sur l'implémentation de fournisseurs (la traduction sémantique sera « implémenteur », et non fournisseur) de types spécifiques de ressources. Certains fournisseurs sont standards et sont inclus dans les packages Puppet, tandis que le reste est extrait des modules.

Pour profiter de tous les délices, il existe des petits pains supplémentaires sous forme de :

Module- une collection de scripts déclaratifs Puppet, d'extensions Ruby pour Puppet, de fichiers, de modèles de fichiers, de données Hiera et bien plus encore. Un terme plus correct serait « package ».
Environnement- un ensemble de scripts, modules et données Hiera. À mesure que l’infrastructure devenait plus complexe, il devenait inévitablement nécessaire de diviser la configuration au-delà de la division standard par nœuds. Fondamentalement, cela est nécessaire pour les innovations pilotes et le contrôle d'accès banal (lorsque tous les administrateurs n'ont pas accès à tous les nœuds de l'infrastructure informatique).
Hiéra- base de données hiérarchique. Cette formulation peut être très intimidante. C'est probablement pour cela qu'il a été modifié dans la documentation des versions ultérieures. En fait, il s'agit d'un mécanisme extrêmement simple et pratique pour extraire la configuration des fichiers YAML ou JSON. La hiérarchie est la possibilité de spécifier l'ordre de lecture de plusieurs fichiers de configuration - c'est-à-dire hiérarchie/priorité de ces fichiers.
- En plus de récupérer des données par appel de fonction, Puppet extrait les paramètres de classe par défaut, ce qui constitue le principal point fort.
- Bien entendu, Hiera prend en charge l'interpolation des faits et même l'appel de fonctions spéciales.
- Dans Puppet 4.3, nous avons à nouveau implémenté la même fonctionnalité pour prendre en charge non seulement la base de données globale, mais également la base de données locale pour l'environnement et le module, bien que l'auteur ait déjà trouvé plusieurs problèmes dans leur implémentation (PUP-5983, PUP-5952 et PUP -5899), qui ont été instantanément corrigés par Puppet Labs.
- Plusieurs stratégies sont prises en charge pour extraire les valeurs de tous les fichiers de la hiérarchie :
  - first - la première valeur trouvée par priorité est renvoyée
  - unique - collecte toutes les valeurs dans un tableau unidimensionnel et supprime les doublons
  - hash - combine tous les hachages YAML trouvés. Les clés en double sont sélectionnées par priorité.
  - deep est essentiellement une version récursive du hachage
- La beauté est que la stratégie d'échantillonnage peut être spécifiée à la fois lors de l'appel de la fonction lookup(), car et dans n'importe quel fichier hiérarchique via la clé spéciale lookup_options, qui est activement utilisée dans le module cfnetwork.
PuppetDB- essentiellement une couche de logique métier autour d'une base de données relationnelle (PostgreSQL), qui permet de sauvegarder des rapports sur les faits et les déploiements effectués et d'exporter des ressources pour une importation ultérieure dans des répertoires sur d'autres nœuds ou sélections via fonctions spéciales. Il existe également une interface Web sous la forme de Puppet Dashboard.
Clé à clé publique X.509- l'infrastructure de certificats déjà mentionnée, extrêmement pratique à utiliser pour d'autres services sans avoir besoin de gérer une infrastructure distincte.
MCollectif- semble être une chose utile pour le lancement de tâches événementielles sur une batterie de serveurs, mais l'auteur a une certaine méfiance dans la sécurité d'une solution particulière.
Forge de marionnettes- une plateforme ouverte de publication et de téléchargement de Modules.
quelques autres fonctionnalités sous forme de contrôles appareils externes type d'équipement Cisco et déploiement sur bare metal, mais c'est une autre histoire

Notes sur la sécurité et l'accessibilité

Vous devez comprendre que Puppet Server devient un point vulnérable de toute l'infrastructure informatique, car... détermine la configuration finale de tous les systèmes. Dans des cas particuliers, il est judicieux de procéder à une séparation : un serveur séparé pour les éléments d'infrastructure critiques avec une configuration extrêmement accès limité et mise à jour manuelle et la seconde pour tout le reste.

La disponibilité de Puppet Server détermine la capacité à gérer l'ensemble de l'infrastructure. Il est logique d'héberger Puppet Server sur une machine virtuelle dans un cloud tiers plus fiable et plus rapidement récupérable que vos propres capacités. Ou vous devez installer plusieurs serveurs.

Dans tous les cas, vous ne devez pas installer d'autres services sur le système sur lequel Puppet Server avec des cloches et des sifflets sera déployé. La virtualisation et la conteneurisation peuvent vous aider.

Multi-maître (plusieurs serveurs Puppet distincts)

Dans ce cas, un seul serveur fait office de CA (Certificate Authority) : son indisponibilité rend impossible l'ajout de nouveaux nœuds.
- Puppet vous permet d'utiliser une infrastructure X.509 tierce si celle intégrée n'est pas satisfaisante.
L'ensemble de la configuration (Environnement) doit être stocké dans un système de contrôle de version et déployé sur chaque serveur simultanément.
Le seul point commun est la base de données PostgreSQL, dont l'organisation de la haute disponibilité dépasse le cadre de cet article.
Le module cfpuppetserver prend en charge les installations en tant que serveur principal (avec CA) et secondaire.

Qu'est-ce qui a changé de manière significative depuis les anciennes versions

Le fabricant a une description complète.

Tous les services ont été déplacés vers JVM, JRuby et Jetty. Malgré les avantages évidents de l'intégration, il existe également des inconvénients en termes de consommation de mémoire.
Des fonctions Lambda ont été ajoutées pour le traitement des collections - il n'est désormais plus nécessaire de couper les béquilles dans Ruby ou de pervertir via create_resources()
Un outil de traitement des modèles EPP est apparu - essentiellement le même ERB, mais avec Puppet DSL au lieu de Ruby,
La structure de répertoires par défaut des fichiers de configuration a considérablement changé
Ajout de la prise en charge des fournisseurs de données pour les environnements et les modules (les hacks ne sont plus nécessaires).
Minimiser le rôle de la Hiera mondiale. La nouvelle commande associée est la recherche de marionnettes.

Installation

Ce processus est assez primitif, mais nécessite de suivre une certaine séquence d'étapes. Puisque faire cela manuellement est une tâche ingrate, l'auteur vous apprendra quelque chose de mauvais, à savoir télécharger des scripts incompréhensibles depuis Internet et les exécuter en tant que root sur votre système.

Les trois principaux composants du serveur sont Puppet Server lui-même, PuppetDB et PostgreSQL. Ils peuvent tous être regroupés dans un seul nœud ou divisés en deux ou trois systèmes. Puppet Server et Puppet DB peuvent être exécutés plusieurs fois, mais PostgeSQL constitue un point de défaillance unique. Il existe différentes approches de réplication et de clustering PostgeSQL. Une approche pratique dans le cas des serveurs principaux et secondaires serait Maître + Esclave en lecture seule, qui est pris en charge dans PuppetDB lui-même en tant que nœud de base de données principal et en lecture seule, mais en automatisant ces une configuration prend du temps et n'est donc pas encore disponible inclus dans le module cfpuppetserver.

La configuration elle-même peut simplement être stockée au moins sur système de fichiers avec Puppet Server, mais c'est comme écrire des scripts sur un serveur Web de production. La solution la plus adaptée est un dépôt git. L'utilitaire r10k peut extraire toutes les branches du référentiel et les déployer sur Puppet Server en tant qu'environnements distincts. r10k est assez mauvais pour extraire les dépendances, donc bibliothécaire-puppet est utilisé par-dessus. Il convient de noter d'emblée que le principal environnement canonique des marionnettes est la « production ». Par conséquent, le référentiel de configuration doit utiliser une branche appelée « production » plutôt que « master ».

Configuration requise

Le matériel est décrit par le fabricant lui-même. Le module cfpuppetserver ne prend actuellement en charge que Debian Jessie+ et Ubuntu Trusty+.

Configuration dans Git

Pour r10k lui-même, l'emplacement du référentiel n'a pas beaucoup d'importance - l'essentiel est sa disponibilité. Par exemple, à des fins de test, le référentiel pourrait être hébergé sur le même système et accessible via file:// . Un bon point de départ est l’exemple de configuration codingfuture/puppet-exampleenv.

Clonage du référentiel : git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
Installer Réglages généraux accès administrateur en utilisant les astuces dans les commentaires :
- $EDITOR data/common.yaml
Créons une configuration de nœud :
- $MY_DOMAIN - nom de domaine racine (par exemple, exemple.org)
- $HOST_NAME - nom d'hôte client sans domaine
- mkdir données/$MY_DOMAIN
- cp data/example.com/puppet.yaml data/$(MY_DOMAIN)/puppet.yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/puppet.yaml - configuration d'un nœud avec Puppet Server selon les suggestions dans les commentaires
- cp data/example.com/host.yaml data/$(MY_DOMAIN)/$(HOST_NAME).yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/$(HOST_NAME).yaml - configuration d'un nœud arbitraire basé sur les suggestions dans les commentaires
Nous poussons vers notre propre serveur Git ou le rendons disponible localement sur un nœud avec Puppet Server via rsync ou scp. Un référentiel local constitue une étape intermédiaire pratique jusqu'à ce que le serveur Git soit déployé à partir de Puppet lui-même. Dans un sens, cela rappelle l'assemblage d'un compilateur en plusieurs étapes.

Installation à partir de zéro sur un système propre

Le module cfpuppetserver permet de tout installer en utilisant Puppet lui-même, mais pour l'installation initiale, les opérations de base sont dupliquées par un script Bash.

Sur le système cible :

Téléchargez le script d'installation : wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
Nous parcourons le script et fronçons les sourcils : less setup_puppetserver.sh
Exécuter : bash setup_puppetserver.sh
marionnette.$(MY_DOMAIN) .
- Exemple avec un dépôt distant : bash setup_puppetserver.sh ssh:// [email protégé]/conf-puppet
- Exemple avec local : bash setup_puppetserver.sh file:///root/puppetconf/
On voit à quel point le système gonfle et n’installe pas tout très rapidement.
Si le dépôt est distant :
- Créez une clé SSH pour root : ssh-keygen -t rsa -b 2048
- Nous enregistrons la clé publique /root/.ssh/id_rsa.pub sur le serveur Git distant...
- ... et là nous mettons en place un hook Git en appelant la commande suivante : /usr/bin/ssh -T déployerpuppet@puppet.$(MY_DOMAIN) ./puppetdeploy.sh
Nous commençons à déployer la configuration manuellement : /etc/puppetlabs/deploy.sh
Essayons comment cela fonctionne sur le serveur lui-même : /opt/puppetlabs/bin/puppet agent --test
Vérifiez vos paramètres réseau, parasurtenseur et accès SSH

Ajout de nœuds gérés

Le nom complet du serveur Puppet doit être disponible via DNS sur l'hôte géré ou codé en dur dans /etc/hosts.
- Exemple : echo "128.1.1.1 puppet.example.com" >> /etc/hosts
Sur le nœud avec Puppet Server, exécutez le script suivant /root/genclientinit.sh $(HOST_NAME).$(MY_DOMAIN) .
Copiez l'intégralité du résultat et collez-le dans ligne de commande sur le système cible.
Nous attendons la fin de l'exécution et exécutons /opt/puppetlabs/bin/puppet agent --test . Au premier lancement, une demande de signature de certificat sera générée.
Nous allons sur le nœud Puppet Server pour signer le certificat.
- liste de certificats de marionnettes - nous vérifions la signature du certificat pour une paranoïa supplémentaire.
- signe de certificat de marionnette $(HOST_NAME).$(MY_DOMAIN) - en fait, nous signons le certificat.
Nous retournons au nœud géré et exécutons à nouveau : /opt/puppetlabs/bin/puppet agent --test`. Cela forcera le démarrage de la procédure de déploiement.
Nous attendons la fin du déploiement via Puppet Agent.
Ça y est, vous disposez d’une infrastructure Puppet minimale prête !

Exemple de sortie de /root/genclientinit.sh

frapper</etc/cflocation fi si test ! -z "" ; puis echo -n >/etc/cflocationpool fi if test ! -z "\$http_proxy"; puis exportez http_proxy export https_proxy="\$http_proxy" export HTTP_PROXY="\$http_proxy" export HTTPS_PROXY="\$http_proxy" fi echo host.example.com > /etc/hostname hostname host.example.com if ! quelle version lsb | lire; puis apt-get install lsb-release fi codename=\$(lsb_release -cs) if test -z "\$codename"; puis faites écho "Échec de la détection du nom de code correct" exit 1 fi wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\$(codename).deb dpkg -i puppetlabs-release-pc1-\$(codename) .deb mkdir -p /etc/puppetlabs/puppet cat > /etc/puppetlabs/puppet/puppet.conf<signe de certificat de marionnette host.example.com" echo "Utilisez CTRL+C pour arrêter le cycle, en cas d'échec pour différentes raisons" sommeil 5 terminé EOT

Descriptif des modules

Liste complète des paramètres Bash pour le script d'installation initial

~# ./setup_puppetserver.sh Utilisation : ./setup_puppetserver.sh [ [ [ [] ] ] ]

r10k_repo_url - URI du dépôt Git
certname - nom de domaine complet de l'hôte
cflocation - initialisation du fait cf_location
cflocationpool - initialisation du fait cf_location_pool
http_proxy - serveur proxy pour les requêtes HTTP et HTTPS

Liste complète des paramètres Bash pour le script d'initialisation du client Puppet

~# /root/genclientinit.sh Utilisation : ./genclientinit.sh [ [ []]]
La signification des paramètres est la même que dans le script précédent.

classe cfpuppetserver

déployeruser = "deploypuppet" - nom d'utilisateur pour déployer automatiquement les mises à jour de configuration
déployeruser_auth_keys = undef - liste des clés pour $deployuser
repo_url = undef - URI du référentiel (exemple : ssh://user@host/repo ou file:///some/path)
puppetserver = true - s'il faut installer le composant Puppet Server sur ce nœud
puppetdb = true - s'il faut installer le composant PuppetDB sur ce nœud
puppetdb_port = 8081 - port pour PuppetDB
setup_postgresql = true - s'il faut installer le composant PostgreSQL sur ce nœud (uniquement si l'installation de PuppetDB est activée)
service_face = "any" - nom de la ressource cfnetwork::iface pour accepter les connexions entrantes
puppetserver_mem = auto - RAM pour Puppet Server en mégaoctets (minimum 192 Mo)
puppetdb_mem = auto - RAM pour PuppetDB en mégaoctets (minimum 192 Mo)
postgresql_mem = auto - RAM pour PostgreSQL en mégaoctets (minimum 128 Mo)

classe cfpuppetserver :: puppetdb

postgresql_host = "localhost" - adresse de la base de données
postgresql_listen = $postgresql_host - la valeur va directement à la directive PostgreSQL Listen_addresses
postgresql_port = 5432 - port de base de données
postgresql_user = "puppetdb" - Utilisateur PuppetDB dans la base de données
postgresql_pass = "puppetdb" - mot de passe de l'utilisateur PuppetDB dans la base de données
postgresql_ssl = false - active le cryptage de connexion basé sur les certificats Puppet PKI

classe cfpuppetserver ::puppetserver

autosign = false - NE DEVRAIT PAS être utilisé dans un environnement de combat, sauf peut-être dans la DMZ. Existe exclusivement pour l'automatisation des tests.
global_hiera_config = "cfpuppetserver/hiera.yaml" - chemin vers le fichier de configuration Hiera par défaut selon les canons de Puppet (le premier composant est le nom du module, le reste est le chemin sous les fichiers/dossier dans le module)

Vous pouvez aider et transférer des fonds pour le développement du site

La gestion d'un grand nombre de systèmes Unix ne peut pas être qualifiée de pratique. Pour modifier un paramètre, l'administrateur doit contacter chaque machine ; les scripts ne peuvent aider que partiellement, et pas dans toutes les situations.

Il faut reconnaître que les administrateurs réseau Windows sont toujours dans une position plus avantageuse. Il suffit de modifier les paramètres de stratégie de groupe et au bout d'un moment, tous les ordinateurs du réseau, y compris ceux dotés d'un système d'exploitation récemment installé, « prendront connaissance » de l'innovation, si elle les concerne, bien sûr. En regardant la longue période de développement d'Unix, vous remarquerez que rien de tel n'a jamais fait son chemin. Il existe des solutions comme kickstart qui facilitent l'installation initiale système opérateur, mais un affinement ultérieur nécessitera des efforts importants. Les solutions commerciales comme BladeLogic et OpsWare ne résolvent que partiellement le problème de l'automatisation des paramètres ; leur principal avantage est la disponibilité Interface graphique, et ils ne peuvent être achetés qu’auprès de grandes organisations. Il existe bien sûr des projets proposant des solutions gratuites, mais tout au long de leur existence ils n'ont jamais pu créer une grande communauté. Par exemple, Cfengine n'est pas très populaire parmi les administrateurs, bien qu'en plus de Linux, il puisse être utilisé dans *BSD, Windows et Mac OS X. Cela peut être dû à la relative complexité de création de configurations. Lors de la description des tâches, vous devez prendre en compte les caractéristiques de chaque système spécifique et contrôler manuellement la séquence d'actions lors de l'exécution des commandes. Autrement dit, l'administrateur doit se rappeler que pour certains systèmes, vous devez écrire adduser pour d'autres, useradd, prendre en compte l'emplacement des fichiers sur différents systèmes, etc. Cela complique d'un ordre de grandeur le processus d'écriture des commandes : il est très difficile de créer la configuration correcte à la volée, et il est presque impossible de lire les configurations créées après un certain temps. Malgré la licence GPL, Cfengine est en réalité le projet d'un seul homme qui contrôle tous les changements et n'est pas très intéressé par la construction d'une société ouverte. En conséquence, les capacités de cfengine sont tout à fait satisfaisantes pour le développeur, mais pour les autres administrateurs, c'est plutôt un casse-tête supplémentaire. Pour améliorer cfengine, divers modules complémentaires ont été créés par des développeurs tiers, ce qui n'a souvent fait qu'empirer la situation. L’auteur de plusieurs modules de ce type pour cfengine, Luke Kanies, a finalement décidé de développer un outil similaire, mais sans bon nombre des défauts de cfengine.

Caractéristiques des marionnettes

Puppet, comme cfengine, est un système client-serveur qui utilise un langage déclaratif, c'est-à-dire obligatoire pour décrire les tâches et les bibliothèques pour leur implémentation. Les clients se connectent périodiquement (30 minutes par défaut) au serveur central et reçoivent la dernière configuration. Si les paramètres reçus ne correspondent pas à l'état du système, ils seront exécutés et, si nécessaire, un rapport sur les opérations effectuées sera envoyé au serveur. Le serveur peut enregistrer des messages dans Syslog ou dans un fichier, créer un graphique RRD et les envoyer à un e-mail spécifié. Des couches d'abstraction transactionnelles et de ressources supplémentaires offrent une compatibilité maximale avec les paramètres et applications existants, vous permettant de vous concentrer sur les objets système sans vous soucier des différences dans l'implémentation et la description des commandes détaillées et des formats de fichiers. L'administrateur opère uniquement avec le type d'objet, Puppet s'occupe du reste. Ainsi, le type de packages connaît environ 17 systèmes de packages ; celui requis sera automatiquement reconnu en fonction des informations sur la version de la distribution ou du système, bien que, si nécessaire, le gestionnaire de packages puisse être forcé.

Contrairement aux scripts, qui ne peuvent souvent pas être utilisés sur d'autres systèmes, les configurations Puppet écrites par des administrateurs tiers fonctionneront, pour la plupart, sans problème sur n'importe quel autre réseau. Dans le livre de recettes de marionnettes [ http://www.reductivelabs.com/trac/puppet/tags/puppet%2Crecipe] il existe déjà trois douzaines de recettes toutes faites. Puppet prend actuellement officiellement en charge les systèmes d'exploitation et services suivants : Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo et MySQL, LDAP.

Langage des marionnettes

Pour avancer, vous devez d’abord comprendre les éléments de base et les capacités du langage. La langue est l'une des forces Fantoche. Avec son aide, les ressources que l'administrateur envisage de gérer et les actions sont décrites. Contrairement à la plupart des solutions similaires, Puppet permet au langage de simplifier l'accès à toutes les ressources similaires sur n'importe quel système dans un environnement hétérogène. Une description de ressource comprend généralement un nom, un type et des attributs. Par exemple, pointons sur le fichier /etc/passwd et définissons ses attributs :

fichier("/etc/passwd":

propriétaire => racine,

groupe => racine,

Désormais, les clients, connectés au serveur, copieront le fichier /etc/passwd et installeront les attributs spécifiés. Vous pouvez définir plusieurs ressources dans une seule règle, en les séparant par un point-virgule. Que faire si le fichier de configuration utilisé sur le serveur diffère de celui du client ou n'est pas utilisé du tout ? Par exemple, cette situation peut se produire lorsque Paramètres VPN Connexions. Dans ce cas, le fichier peut être pointé vers l'aide de la directive source. Il y a ici deux options, comme d'habitude, pour spécifier le chemin d'accès à un autre fichier ; deux protocoles URI sont également pris en charge : file et puppet. Dans le premier cas, un lien vers un site externe serveur NFS, dans la deuxième option, un service de type NFS est lancé sur le serveur Puppet, qui exporte les ressources. Dans ce dernier cas, le chemin par défaut est relatif au répertoire racine de la marionnette - /etc/puppet. Autrement dit, le lien puppet://server.domain.com/config/sshd_config correspondra au fichier /etc/puppet/config/sshd_config. Vous pouvez remplacer ce répertoire à l'aide de la directive filebucket, bien qu'il soit plus correct d'utiliser la section du même nom dans le fichier /etc/puppet/fileserver.conf. Dans ce cas, vous pouvez restreindre l'accès au service uniquement à partir de certaines adresses. Par exemple, décrivons la section de configuration.

chemin /var/puppet/config

autoriser *.domain.com

autoriser 192.168.0.*

autoriser 192.168.1.0/24

refuser *.wireless.domain.com

Et puis nous nous tournons vers cette section pour décrire la ressource.

source => "puppet://server.domain.com/config/sshd_config"

Avant les deux points se trouve le nom de la ressource. Dans les cas les plus simples, vous pouvez simplement spécifier un alias ou des variables comme nom. L'alias est défini à l'aide de la directive alias. chemin complet du fichier. Dans des configurations plus complexes

fichier("/etc/passwd":

alias => mot de passe

Une autre option pour créer un alias est intéressante lorsque vous devez gérer différents systèmes d'exploitation. Par exemple, créons une ressource décrivant le fichier sshd_config :

fichier (sshdconfig :

nom => $système d'exploitation ? (

solaris => "/usr/local/etc/ssh/sshd_config",

par défaut => "/etc/ssh/sshd_config"

Dans cet exemple, nous sommes confrontés à un choix. Le fichier pour Solaris est spécifié séparément, pour tous les autres, le fichier /etc/ssh/sshd_config sera sélectionné. Cette ressource est désormais accessible en tant que sshdconfig, en fonction du système d'exploitation, le chemin souhaité sera sélectionné. Par exemple, nous indiquons que si le démon sshd est en cours d'exécution et reçoit nouveau fichier, vous devez redémarrer le service.

assurer => vrai,

abonnez-vous => Fichier

Les variables sont souvent utilisées lorsque vous travaillez avec des données utilisateur. Par exemple, nous décrivons l'emplacement des répertoires personnels des utilisateurs :

$homeroot = "/home"

Désormais, les fichiers d'un utilisateur spécifique sont accessibles sous forme de

$(homeroot)/$nom

Le paramètre $name sera renseigné avec le nom du compte de l'utilisateur. Dans certains cas, il est pratique de définir une valeur par défaut pour un type donné. Par exemple, pour le type exec, ils indiquent souvent les répertoires dans lesquels il doit chercher le fichier exécutable :

Exec (chemin => "/usr/bin:/bin:/usr/sbin:/sbin")

Si vous devez pointer vers plusieurs fichiers et répertoires imbriqués, vous pouvez utiliser le paramètre recurse.

fichier("/etc/apache2/conf.d":

source => "puppet:// puppet://server.domain.com/config/apache/conf.d",

récursivité => "vrai"

Plusieurs ressources peuvent être combinées en classes ou définitions. Les classes constituent une description complète d’un système ou d’un service et sont utilisées séparément.

"/etc/passwd" : propriétaire => racine, groupe => racine, mode => 644 ;

"/etc/shadow": propriétaire => racine, groupe => racine, mode => 440

Comme dans les langages orientés objet, les classes peuvent être remplacées. Par exemple, sur FreeBSD, le groupe propriétaire de ces fichiers est wheel. Par conséquent, afin de ne pas réécrire complètement la ressource, créons une nouvelle classe freebsd, qui héritera de la classe Linux :

la classe freebsd hérite de Linux (

Fichier[«/etc/passwd»] ( groupe => roue );

Fichier[“/etc/shadow”] ( groupe => roue )

Pour plus de commodité, toutes les classes peuvent être placées dans un fichier séparé, qui peut être connecté à l'aide de la directive include. Les définitions peuvent prendre plusieurs paramètres comme arguments, mais ne prennent pas en charge l'héritage et sont utilisées lorsque vous devez décrire des objets réutilisables. Par exemple, définissons le répertoire personnel des utilisateurs et les commandes nécessaires pour créer un nouveau compte.

définir user_homedir ($group, $fullname, $ingroups) (

utilisateur("$nom":

assurer => présent,

commentaire => "$nom complet",

gid => "$groupe",

groupes => $ingroups,

adhésion => minimum,

shell => "/bin/bash",

maison => "/home/$nom",

require => Groupe[$group],

exec("$nom rép_accueil":

commande => « /bin/cp -R /etc/skel /home/$name ; /bin/chown -R $nom:$groupe /home/$nom",

crée => "/home/$name",

require => Utilisateur[$name],

Maintenant pour en créer un nouveau compte contactez simplement user_homedir.

user_homedir("sergej":

groupe => "sergej",

nom complet => « Sergej Jaremchuk »,

ingroups => ["media", "admin]

Il existe des descriptions distinctes des nœuds qui prennent en charge l'héritage, comme les classes. Lorsqu'un client se connecte au serveur Puppet, la section de nœud correspondante sera recherchée et les paramètres spécifiques uniquement à cet ordinateur seront fournis. Pour décrire tous les autres systèmes, vous pouvez utiliser node default. Une description de tous les types est donnée dans le document « Type Reference », qu'il faut dans tous les cas lire, au moins pour comprendre toutes les capacités du langage Puppet. Divers types vous permettre d'exécuter des commandes spécifiées, y compris lorsque certaines conditions sont remplies (par exemple, modifier un fichier de configuration), de travailler avec cron, les informations d'identification et les groupes des utilisateurs, des ordinateurs, de monter des ressources, de démarrer et d'arrêter des services, d'installer, de mettre à jour et de supprimer des packages, de travailler avec Clés SSH, les zones Solaris, etc. Voilà à quel point il est simple de forcer la mise à jour quotidienne de la liste des packages dans les distributions utilisant apt entre 2 et 4 heures.

horaire (quotidiennement :

période => quotidiennement,

plage =>

exec("/usr/bin/apt-get update":

horaire => quotidiennement

La mise à jour pour cette période sera effectuée par chaque système une seule fois, après quoi la tâche sera considérée comme terminée et sera supprimée de l'ordinateur client. Le langage Puppet prend en charge d'autres structures familières : conditions, fonctions, tableaux, commentaires, etc.

Installation de Puppet

Puppet nécessite Ruby (>= 1.8.1) avec le support OpenSSL et les bibliothèques XMLRPC, ainsi que la bibliothèque Faster [ http://reductivelabs.com/projects/facter]. Le référentiel Ubuntu 7.04 utilisé pour l'installation de test incluait déjà le package Puppy.

$ sudo marionnette de recherche apt-cache

puppet — gestion centralisée de la configuration pour les réseaux

puppetmaster - démon de contrôle de gestion de configuration centralisé

Lors de l'installation, tous les packages de dépendances nécessaires seront installés : facter libopenssl-ruby libxmlrpc-ruby.

$ sudo apt-get install marionnette marionnette

Vous pouvez vérifier la disponibilité des bibliothèques Ruby avec la commande.

$ ruby -ropenssl -e "puts:oui"

~$ ruby -rxmlrpc/client -e "puts:oui"

Si aucune erreur n’est reçue, alors tout ce dont vous avez besoin est déjà inclus. Les fichiers qui décrivent la configuration souhaitée des systèmes sont appelés manifestes dans la terminologie Puppet. Au lancement, le démon tente de lire le fichier /etc/puppet/manifests/site.pp ; s'il est manquant, il affiche un message d'avertissement. Lors des tests, vous pouvez demander au démon de fonctionner en mode hors ligne, auquel cas le manifeste n'est pas requis

$ sudo /usr/bin/puppetmasterd --nonodes

Si nécessaire, vous pouvez connecter d'autres fichiers à site.pp, par exemple avec des descriptions de classes. Pour un test, vous pouvez saisir les instructions les plus simples dans ce fichier.

fichier("/etc/sudoers":

propriétaire => racine,

groupe => racine,

Tous les fichiers de configuration du serveur et des clients se trouvent dans /etc/puppet. Le fichier fileserver.conf dont nous avons parlé ci-dessus est facultatif et n'est utilisé que si Puppet fonctionne également comme serveur de fichiers. Sur Ubuntu, ce fichier exporte le sous-répertoire /etc/puppet/files. Le sous-répertoire SSL contient les certificats et les clés qui seront utilisés pour le chiffrement lors de la connexion des clients. Les clés sont créées automatiquement la première fois que vous démarrez puppetmasterd ; vous pouvez les créer manuellement avec la commande.

$ sudo /usr/bin/ puppetmasterd --mkusers.

Les fichiers puppetd.conf et puppetmasterd.conf sont similaires. Ils indiquent certains paramètres pour le fonctionnement des démons sur le système client et le serveur. Le fichier client ne diffère que par la présence du paramètre serveur, qui pointe vers l'ordinateur sur lequel s'exécute puppetmasterd.

serveur = broyeur.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/run

# envoyer un rapport au serveur

Pour éviter de tout saisir manuellement, vous pouvez créer un modèle en utilisant puppetd lui-même.

$ puppetd --genconfig > /etc/puppet/puppetd.conf

De même, vous pouvez créer site.pp sur le serveur.

$ puppetd --genmanifest > /etc/puppet/manifests/site.pp

Un autre fichier, tagmail.conf, permet de préciser les adresses email auxquelles les rapports seront envoyés. Dans le cas le plus simple, vous pouvez utiliser une seule ligne.

tous: [email protégé]

Les fichiers de configuration ne suffisent pas pour que le client se connecte au serveur. Pour ce faire, vous devez également signer les certificats. Tout d'abord, pour informer le serveur du nouvel ordinateur sur le système client, entrez la commande :

$ sudo puppetd --server grinder.com --waitforcert 60 --test

info : Demande de certificat

avertissement : le certificat homologue ne sera pas vérifié dans cette session SSL

avis : Je n'ai pas reçu de certificat

Si une ligne différente est renvoyée, vous devez vérifier le fonctionnement du serveur.

$ psaux | marionnette grep

marionnette 5779 0,0 1,4 27764 15404 ? SSL 21:49 0:00 ruby /usr/sbin/puppetmasterd

Le pare-feu doit autoriser les connexions sur le port 8140.

Sur le serveur, nous recevons une liste de certificats qui doivent être signés.

$ sudo puppetca --liste

nomad.grinder.com

Et nous signons le certificat client.

$ sudo puppetca –sign nomad.grinder.com

Le client peut désormais se connecter librement au serveur et recevoir les paramètres.

Malheureusement, il n'est tout simplement pas possible de montrer toutes les capacités de Puppet dans cet article. Mais comme vous pouvez le constater, il s'agit d'un outil fonctionnel et flexible qui permet de résoudre la plupart des problèmes d'administration simultanée d'un grand nombre de systèmes. Si votre métier nécessite la mise en place de plusieurs systèmes. Et surtout, le projet a réussi à rassembler une communauté petite mais en constante croissance. Espérons donc qu’une bonne idée ne mourra pas ou ne soit pas laissée de côté.

Fantoche est une structure multiplateforme qui permet administrateurs système Effectuez des tâches courantes à l’aide de code. Le code vous permet d'effectuer diverses tâches allant de l'installation de nouveaux programmes à la vérification des autorisations de fichiers ou à la mise à jour des comptes d'utilisateurs. Fantoche supérieur non seulement lors de l’installation initiale du système, mais tout au long de son cycle de vie. Dans la plupart des cas fantoche utilisé dans la configuration client/serveur.

Cette section montre l'installation et la configuration Fantoche dans une configuration client/serveur. Cet exemple simple montre comment installer Apache en utilisant Fantoche.

Installation

Pour l'installation Fantoche entrez dans le terminal :

Sudo apt-get install puppetmaster

Sur la ou les machines clientes, saisissez :

Sudo apt-get installer la marionnette

Paramètres

Avant de configurer Puppet, vous souhaiterez peut-être ajouter une entrée DNS-CNAME Pour marionnette.exemple.com, Où exemple.com- c'est votre domaine. Clients par défaut Fantoche vérifiez DNS pour puppet.example.com comme nom du serveur de marionnettes ( Maître de la marionnette). Voir Service de noms de domaine pour plus de détails sur l'utilisation du DNS.

Si vous n'avez pas l'intention d'utiliser DNS, vous pouvez ajouter des entrées au fichier /etc/hosts sur le serveur et le client. Par exemple, dans le fichier /etc/hosts Fantoche le serveur ajoute :

127.0.0.1 localhost.localdomain localhost marionnette 192.168.1.17 meercat02.example.com meercat02

Sur tout Fantoche Dans le client, ajoutez une entrée pour le serveur :

192.168.1.16 meercat.example.com marionnette suricate

Remplacez les adresses IP et noms de domaine de l'exemple à vos adresses actuelles et aux noms du serveur et des clients.

Maintenant, mettons en place quelques ressources pour apache2. Créer un fichier /etc/puppet/manifests/site.pp contenant les éléments suivants :

Package ( "apache2": assurer => installé ) service ( "apache2": assurer => vrai, activer => vrai, exiger => Package["apache2"] )

Nœud "meercat02.example.com" (inclure apache2)

Remplacer meercat02.exemple.comà votre nom actuel Fantoche client.

La dernière étape pour ce simple Fantoche le serveur consiste à redémarrer le service :

Sudo /etc/init.d/puppetmaster redémarrage

Maintenant sur Fantoche tout est configuré sur le serveur et il est temps de configurer le client.

Commençons par configurer le service Fantoche agent à lancer. Modifiez /etc/default/puppet en remplaçant la valeur COMMENCER sur Oui:

Sudo /etc/init.d/puppet start

Revenons à Fantoche serveur pour signer le certificat client à l'aide de la commande :

Sudo puppetca --sign meercat02.example.com

Vérifier /var/log/syslog pour toute erreur de configuration. Si tout s'est bien passé, le colis apache2 et ses dépendances seront installées pour Fantoche client.

Cet exemple est très simple et ne montre pas la plupart des fonctionnalités et avantages. Fantoche. Pour Informations Complémentaires regarder

Sergueï Yaremchuk

Configuration centralisée des systèmes UNIX à l'aide de Puppet

La gestion d'un grand nombre de systèmes UNIX ne peut pas être qualifiée de pratique. Pour modifier un paramètre, l'administrateur doit contacter chaque machine ; les scripts ne peuvent aider que partiellement, et pas dans toutes les situations.

Il faut reconnaître que les administrateurs réseau Windows sont toujours dans une position plus avantageuse. Il suffit de modifier les paramètres de stratégie de groupe et, au bout d'un certain temps, tous les ordinateurs du réseau, y compris ceux dotés d'un système d'exploitation récemment installé, « prendront connaissance » de l'innovation, si elle les concerne, bien sûr. En regardant la longue période de développement d'UNIX, vous pouvez constater que rien de tel n'a jamais fait son chemin. Il existe des solutions comme kickstart qui facilitent l'installation initiale du système d'exploitation, mais le développement ultérieur nécessitera des efforts importants. Les solutions commerciales, comme BladeLogic et OpsWare, ne résolvent que partiellement le problème de l'automatisation des paramètres : leur principal avantage est la présence d'une interface graphique, et seules les grandes organisations peuvent se permettre de les acheter. Il existe bien sûr des projets qui proposent des solutions gratuites, mais tout au long de leur existence ils n'ont pas réussi à créer une grande communauté. Par exemple, Cfengine n'est pas très populaire parmi les administrateurs, même si, en plus de Linux, il peut être utilisé sous *BSD, Windows et Mac OS X. Cela peut être dû à la relative complexité de création de configurations. Lors de la description des tâches, il est nécessaire de prendre en compte les caractéristiques de chaque système spécifique et de contrôler manuellement la séquence d'actions lors de l'exécution des commandes. Autrement dit, l'administrateur doit se rappeler que pour certains systèmes, vous devez écrire adduser, pour d'autres - useradd, prendre en compte l'emplacement des fichiers sur différents systèmes, etc. Cela complique d'un ordre de grandeur le processus d'écriture des commandes : il est très difficile de créer la configuration correcte à la volée, et il est presque impossible de lire les configurations créées après un certain temps. Malgré la licence GPL, Cfengine est essentiellement le projet d'un seul homme qui contrôle tous les changements et n'est pas très intéressé par la construction d'une société ouverte. En conséquence, les capacités de Cfengine sont tout à fait satisfaisantes pour le développeur, mais pour les autres administrateurs, c'est plutôt un casse-tête supplémentaire. Pour améliorer Cfengine, divers modules complémentaires ont été créés par des développeurs tiers, ce qui n'a souvent fait qu'empirer la situation. L'auteur de plusieurs modules de ce type pour Cfengine, Luke Kanies, a finalement décidé de développer un outil similaire, mais sans bon nombre des défauts de Cfengine.

Caractéristiques des marionnettes

Puppet, comme Cfengine, est un système client-serveur qui utilise un langage déclaratif pour décrire les tâches et des bibliothèques pour les implémenter. Les clients se connectent périodiquement (toutes les 30 minutes par défaut) au serveur central et reçoivent la dernière configuration. Si les paramètres reçus ne correspondent pas à l'état du système, ils seront exécutés et, si nécessaire, un rapport sur les opérations effectuées sera envoyé au serveur. Le serveur de messages peut l'enregistrer dans Syslog ou dans un fichier, créer un graphique RRD et l'envoyer à l'adresse e-mail spécifiée. Des couches d'abstraction transactionnelles et de ressources supplémentaires offrent une compatibilité maximale avec les paramètres et applications existants, vous permettant de vous concentrer sur les objets système sans vous soucier des différences d'implémentation et de description des commandes détaillées et des formats de fichiers. L'administrateur opère uniquement avec le type d'objet, Puppet s'occupe du reste. Ainsi, le type de packages connaît environ 17 systèmes de packages ; celui requis sera automatiquement reconnu en fonction des informations sur la version de la distribution ou du système, bien que, si nécessaire, le gestionnaire de packages puisse être défini de force.

Contrairement aux scripts, qui sont souvent impossibles à utiliser sur d'autres systèmes, les configurations Puppet écrites par des administrateurs tiers fonctionneront pour la plupart sans problème sur n'importe quel autre réseau. Puppet CookBook propose déjà trois douzaines de recettes toutes faites. Puppet prend actuellement officiellement en charge les systèmes d'exploitation et services suivants : Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo et MySQL, LDAP.

Langage des marionnettes

Pour avancer, vous devez d’abord comprendre les éléments de base et les capacités du langage. La langue est l'une des forces de Puppet. Il décrit les ressources que l'administrateur envisage de gérer et les actions qu'il entreprend. Contrairement à la plupart des solutions similaires, Puppet permet au langage de simplifier l'accès à toutes les ressources similaires sur n'importe quel système dans un environnement hétérogène. Une description de ressource comprend généralement un nom, un type et des attributs. Par exemple, pointons sur le fichier /etc/passwd et définissons ses attributs :

fichier("/etc/passwd":

Propriétaire => racine,

Groupe => racine,

Mode => 644,

Désormais, les clients se connectant au serveur copieront le fichier /etc/passwd et définiront les attributs spécifiés. Vous pouvez définir plusieurs ressources dans une seule règle, en les séparant par un point-virgule. Mais que se passe-t-il si le fichier de configuration utilisé sur le serveur diffère de celui du client ou n'est pas utilisé du tout ? Par exemple, cette situation peut survenir lors de la configuration de connexions VPN. Dans ce cas, vous devez pointer vers le fichier à l'aide de la directive source. Il y a deux options ici : vous pouvez, comme d'habitude, spécifier le chemin d'accès à un autre fichier, et également utiliser les deux protocoles URI pris en charge : file et puppet. Dans le premier cas, un lien vers un serveur NFS externe est utilisé ; dans la seconde option, un service de type NFS est lancé sur le serveur Puppet, qui exporte les ressources. Dans ce dernier cas, le chemin par défaut est relatif au répertoire racine de la marionnette – /etc/puppet. Autrement dit, le lien puppet://server.domain.com/config/sshd_config correspondra au fichier /etc/puppet/config/sshd_config. Vous pouvez remplacer ce répertoire à l'aide de la directive filebucket, bien qu'il soit plus correct d'utiliser la section du même nom dans le fichier /etc/puppet/fileserver.conf. Dans ce cas, vous pouvez restreindre l'accès au service à certaines adresses uniquement. Par exemple, décrivons la section config :

Chemin /var/puppet/config

Autoriser *.domain.com

Autoriser 127.0.0.1

Autoriser 192.168.0.*

Autoriser 192.168.1.0/24

Refuser *.wireless.domain.com

Et puis nous nous référons à cette section pour décrire la ressource :

source => "puppet://server.domain.com/config/sshd_config"

Avant les deux points se trouve le nom de la ressource. Dans les cas les plus simples, vous pouvez simplement spécifier le chemin complet du fichier comme nom. Dans les configurations plus complexes, il est préférable d'utiliser un alias ou des variables. L'alias est défini à l'aide de la directive alias :

fichier("/etc/passwd":

Alias => mot de passe

Une autre option pour créer un alias est intéressante lorsque vous devez gérer différents systèmes d'exploitation. Par exemple, créons une ressource qui décrit le fichier sshd_config :

fichier (sshdconfig :

Nom => $système d'exploitation ? (

Solaris => "/usr/local/etc/ssh/sshd_config",

Par défaut => "/etc/ssh/sshd_config"

Dans cet exemple, nous sommes confrontés à un choix. Le fichier pour Solaris est spécifié séparément, pour tous les autres, le fichier /etc/ssh/sshd_config sera sélectionné. Cette ressource est désormais accessible en tant que sshdconfig, en fonction du système d'exploitation, le chemin souhaité sera sélectionné. Par exemple, nous indiquons que si le démon sshd est en cours d'exécution et qu'un nouveau fichier est reçu, le service doit être redémarré :

service(sshd :

Assurer => vrai,

Abonnez-vous => Fichier

Les variables sont souvent utilisées lorsque vous travaillez avec des données utilisateur. Par exemple, nous décrivons l'emplacement des répertoires personnels des utilisateurs :

$homeroot = "/home"

Désormais, les fichiers d'un utilisateur spécifique sont accessibles comme :

$(homeroot)/$nom

Le paramètre $name sera renseigné avec le nom du compte de l'utilisateur. Dans certains cas, il est pratique de définir une valeur par défaut pour un type donné. Par exemple, pour le type exec, il est très courant de spécifier les répertoires dans lesquels il doit rechercher le fichier exécutable :

Exec ( chemin => "/usr/bin:/bin:/usr/sbin:/sbin" )

Si vous devez pointer vers plusieurs fichiers et répertoires imbriqués, vous pouvez utiliser le paramètre recurse :

fichier("/etc/apache2/conf.d":

Source => "puppet:// puppet://server.domain.com/config/apache/conf.d",

Récursivité => "vrai"

Plusieurs ressources peuvent être combinées en classes ou définitions. Les classes constituent une description complète d'un système ou d'un service et sont utilisées séparément :

classe Linux (

Déposer (

"/etc/passwd" : propriétaire => racine, groupe => racine, mode => 644 ;

"/etc/shadow": propriétaire => racine, groupe => racine, mode => 440

la classe freebsd hérite de Linux (

Fichier["/etc/passwd"] ( groupe => roue );

Fichier["/etc/shadow"] ( groupe => roue )

Pour plus de commodité, toutes les classes peuvent être placées dans un fichier séparé, qui doit être inclus à l'aide de la directive include. Les définitions peuvent prendre plusieurs paramètres comme arguments, mais ne prennent pas en charge l'héritage et sont utilisées lorsque vous devez décrire des objets réutilisables. Par exemple, définissons le répertoire personnel de l'utilisateur et les commandes nécessaires pour créer un nouveau compte :

définir user_homedir ($group, $fullname, $ingroups) (

Utilisateur("$nom":

Assurer => présent,

Commentaire => "$nom complet",

Gid => "$groupe",

Groupes => $ingroups,

Adhésion => minimum,

Shell => "/bin/bash",

Accueil => "/home/$name",

Exiger => Groupe[$group],

Exec("$nom rép_accueil":

Commande => "/bin/cp -R /etc/skel /home/$name; /bin/chown -R $name:$group /home/$name",

Crée => "/home/$name",

Exiger => Utilisateur[$name],

Maintenant, pour créer un nouveau compte, contactez simplement user_homedir :

user_homedir("sergej":

Groupe => "sergej",

Nom complet => "Sergej Jaremchuk",

Ingroups => ["media", " admin]

Il existe des descriptions distinctes des nœuds prenant en charge l'héritage, ainsi que des classes. Lorsqu'un client se connecte au serveur Puppet, la section de nœud correspondante sera recherchée et les paramètres spécifiques uniquement à cet ordinateur seront fournis. Pour décrire tous les autres systèmes, vous pouvez utiliser node default. Une description de tous les types est donnée dans le document « Type Reference », qu'il faut dans tous les cas lire, au moins pour comprendre toutes les capacités du langage Puppet. Différents types vous permettent d'exécuter des commandes spécifiées, notamment lorsque certaines conditions sont remplies (par exemple, modifier un fichier de configuration), de travailler avec cron, les informations d'identification et les groupes des utilisateurs, des ordinateurs, de monter des ressources, de démarrer et d'arrêter des services, d'installer, de mettre à jour et de supprimer des packages. , travaillant avec des clés SSH, des zones Solaris, etc. Voici comment vous pouvez facilement forcer la mise à jour quotidienne de la liste des packages dans les distributions utilisant apt entre 2 et 4 heures :

horaire (quotidiennement :

Période => quotidiennement,

Plage =>

exec("/usr/bin/apt-get update":

Horaire => quotidiennement

Installation de Puppet

Puppet nécessite Ruby (version 1.8.1 et supérieure) avec le support OpenSSL et les bibliothèques XMLRPC, ainsi que la bibliothèque Faster. Le référentiel Ubuntu 7.04 utilisé pour l'installation de test inclut déjà le package chiot :

$ sudo marionnette de recherche apt-cache

~$ ruby -rxmlrpc/client -e "puts:oui"

ouais

Si aucune erreur n’est reçue, alors tout ce dont vous avez besoin est déjà inclus. Les fichiers qui décrivent la configuration souhaitée des systèmes sont appelés manifestes dans la terminologie Puppet. Au lancement, le démon tente de lire le fichier /etc/puppet/manifests/site.pp ; s'il est manquant, il affiche un message d'avertissement. Lors des tests, vous pouvez demander au démon de s'exécuter en mode autonome, ce qui ne nécessite pas de manifeste :

$ sudo /usr/bin/puppetmasterd --nonodes

Si nécessaire, vous pouvez connecter d'autres fichiers à site.pp, par exemple avec des descriptions de classe. Pour un test, vous pouvez saisir les instructions les plus simples dans ce fichier.

classe sudo(

Fichier("/etc/sudoers":

Propriétaire => racine,

Groupe => racine,

Mode => 440,

nœud par défaut (

Inclure sudo

Tous les fichiers de configuration, serveur et client, se trouvent dans /etc/puppet. Le fichier fileserver.conf, dont nous avons déjà parlé, est facultatif et n'est utilisé que si Puppet fonctionne également comme serveur de fichiers. Sur Ubuntu, ce fichier exporte le sous-répertoire /etc/puppet/files. Le sous-répertoire SSL contient les certificats et les clés qui seront utilisés pour le chiffrement lors de la connexion des clients. Les clés sont créées automatiquement au premier démarrage de puppetmasterd ; vous pouvez les créer manuellement avec la commande :

$ sudo /usr/bin/puppetmasterd --mkusers

serveur = broyeur.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/run

# envoyer un rapport au serveur

rapport = vrai

Pour éviter de tout saisir manuellement, vous pouvez créer un modèle en utilisant puppetd lui-même :

$ puppetd --genconfig > /etc/puppet/puppetd.conf

De même, vous pouvez créer site.pp sur le serveur :

$ puppetd --genmanifest > /etc/puppet/manifests/site.pp

Un autre fichier, tagmail.conf, permet de spécifier les adresses email auxquelles les rapports seront envoyés. Dans le cas le plus simple, vous pouvez utiliser une seule ligne :

tous: [email protégé]

Les fichiers de configuration ne suffisent pas pour que le client se connecte au serveur. Pour ce faire, vous devez également signer les certificats.

Tout d'abord, pour informer le serveur du nouvel ordinateur, entrez la commande sur le système client :

$ sudo puppetd --server Grinder.com --waitforcert 60 –test

Le pare-feu doit autoriser les connexions sur le port 8140.

Sur le serveur, nous obtenons une liste de certificats qui doivent être signés :

$ sudo puppetca –liste

nomad.grinder.com

Et signez le certificat client :

$ sudo puppetca –sign nomad.grinder.com

Le client peut désormais se connecter librement au serveur et recevoir les paramètres.

Malheureusement, il est impossible de montrer toutes les capacités de Puppet dans cet article. Mais, comme vous pouvez le constater, il s'agit d'un outil fonctionnel et flexible qui permet de résoudre la plupart des problèmes d'administration simultanée d'un grand nombre de systèmes. Et surtout, le projet a réussi à rassembler une communauté petite mais en constante croissance. Espérons donc qu’une bonne idée ne mourra pas ou ne soit pas laissée de côté.

Bonne chance!

Site Web du projet BladeLogic – http://www.bladelogic.com.
Le site Web du projet OpsWare est http://www.opsware.com.
Le site Web du projet Cfengine est http://www.cfengine.org.
Le site Web du projet Puppet est http://reductivelabs.com/projects/puppet.
Livre de recettes de marionnettes - http://www.reductivelabs.com/trac/puppet/tagspuppet%2Crecipe.
Bibliothèque plus rapide –