Installation et configuration de la marionnette. Installation et configuration du serveur de marionnettes. Liste complète des paramètres Bash du script d'installation d'origine

Pour une utilisation plus efficace, la marionnette doit être comprise sur la construction de modules et de manifestes. Ce manuel vous familiarisera avec le travail de ces composants de marionnettes sur l'exemple de paramétrage de la pile de lampe sur le serveur Ubuntu 14.04.

Conditions

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

Principes de base du code de marionnettes

Ressources

Le code de marionnettes est principalement composé de ressources. La ressource est un fragment d'un code décrivant l'état du système et détermine les modifications dont elles ont besoin. Par example:

utilisateur ("Mitchell":
Assurez-vous \u003d\u003e présent
UID \u003d\u003e "1000",
gid \u003d\u003e "1000",
shell \u003d\u003e "/ bin / bash",
home \u003d\u003e "/ home / mitchell"
}

L'annonce de la ressource a un tel format:

ressource_type ("Nom de ressources"
attribut \u003d\u003e valeur
...
}

Pour afficher tous les types de ressources de la marionnettes, entrez la commande:

ressource de marionnettes --Types.

En savoir plus sur les types de ressources que vous apprendrez dans ce manuel.

Manifeste

Manifeste est le scénario d'orchestration. Les programmes de marionnettes avec expansion .PP sont appelés manifestes. Marionnette Manifeste par défaut - /etc/puppet/manifest/site.pp.

Des classes

Comme dans tout langage de programmation conventionnel, les classes sont responsables de l'organisation et de la réutilisation des parties de l'Orchec.

La définition de la classe est un bloc de code qui décrit la manière dont la classe fonctionne. Après avoir déterminé la classe, vous pouvez l'utiliser à Manifesta.

La définition de la classe a un tel format:

exemple de classe_class (
...
Code.
...
}

Ce code définit la classe exemple_class. Le code de marionnettes sera sous supports bouclés.

La déclaration de classe est la place dans le code où l'une ou l'autre classe est appelée. En utilisant les annonces de la classe de marionnettes, traite son code.

La déclaration de classe est courante et par le type de ressource.

La déclaration de classe habituelle est ajoutée au code à l'aide du mot clé Inclure.

inclure exemple_class

Lors de la déclaration du type de ressource, la classe est annoncée dans le format de ressource:

classe ("exemple_class" :)

Une telle annonce vous permet d'ajouter des paramètres de classe au code qui remplacent les valeurs standard des attributs de classe. Par example:

nœud "host2" (
Classe ("apache" :) # Utiliser le module Apache
Apache :: vhost ("exemple.com": # Définir la ressource Vhost
Port \u003d\u003e "80",
Docroot \u003d\u003e "/ var / www / html"
}
}

Modules

Le module est un groupe de manifestes et d'autres fichiers, organisés à l'avance d'une certaine manière, ce qui vous permet de faciliter le joint et la réutilisation des différentes parties de l'Orchec. Les modules aident à systématiser le code de marionnettes, car avec leur code d'aide peuvent être divisés en plusieurs manifestations.

Les modules de marionnettes sont stockés dans le répertoire / etc / marionnette / modules.

Manifesta d'écriture

Vous pouvez vous entraîner à écrire des manifestes, des modules et des classes marionnettes sur l'exemple de l'installation de la pile de lampe au serveur Ubuntu (en conséquence, il s'avère).

Ainsi, pour effectuer l'orchestration du serveur Ubuntu 14.04 et installer la pile de lampe dessus, vous avez besoin de ressources pour de telles actions:

installation du package Apache2.
démarrer le service Apache2.
installation d'un package serveurs MySQL, MySQL-Server.
lancer le service MySQL.
installation du package PC5
création d'un script de test PHP, info.php.
mettez à jour l'index APT avant d'installer chaque package.

Vous trouverez ci-dessous trois exemples du code de marionnettes, avec lequel vous pouvez obtenir une telle installation de pile de lampe.

Le premier exemple enseignera les manifestations de base dans un fichier. Le deuxième exemple aidera à assembler et à utiliser la classe et le module en fonction des manifestes précédemment écrits. Dans le troisième exemple, vous apprendrez à utiliser des modules pré-assemblés publics disponibles pour installer la pile de lampes.

Noter: Testez, il est préférable d'utiliser un serveur virtuel frais.

Exemple 1: Installation de la lampe en utilisant un manifeste

Le manifeste de marionnettes peut être écrit sur un nœud de l'agence, puis effectuez-le à l'aide de la commande Puppet Apply (pour cela, vous n'avez pas besoin d'une configuration de l'assistant et de l'agent).

Dans cette section, vous apprendrez à écrire des manifestes qui utiliseront de tels types d'annonces de ressources:

exec: exécution des commandes.
paquet: Installation de packages.
service: Gestion des services.
fichier: gestion de fichier.

Créer des manifesta

Créez une nouvelle manifeste:

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

Ajoutez le code suivant pour déclarer les ressources nécessaires.

Exécuter la commande "apt-get update"
EXEC ("APT-UPDATE": EXEC RESSOURCE "APT-UPDATE"
Commande \u003d\u003e "/ usr / bin / apt-get update" #. Commande qui exécutera cette ressource
}
# Paquet d'installation Apache2
Paquet ("Apache2":
Exiger \u003d\u003e EXEC ["APT-UPDATE"], # requête APT-Mettre à jour avant d'installer le package.
Assurez-vous \u003d\u003e installé,
}
# Service d'exécution Apace2
Service ("Apache2":
Assurez-vous \u003d\u003e en cours d'exécution,
}
# Définir mysql-serveur
Package ("MySQL-Server":
Exiger \u003d\u003e EXEC ["" APT-UPDATE "], # APT-Mettre à jour Demande Suspone
Assurez-vous \u003d\u003e installé,
}
# Conduire MySQL service
Service ("MySQL":
Assurez-vous \u003d\u003e en cours d'exécution,
}
# Pack d'installation PHP5
Paquet ("php5":
Exiger \u003d\u003e EXEC ["APT-UPDATE"], # Demande APT-Mettre à jour avant d'installer
Assurez-vous \u003d\u003e installé,
}
# Service d'exécution info.php
Fichier ("/var/www/html/info.php":
Assurez-vous \u003d\u003e fichier,
Content \u003d\u003e "", # Code phpinfo
Exiger \u003d\u003e Package ["Apache2"], # Apache2 Demande de package
}

Application Manifesta

Pour utiliser le nouveau manifeste, entrez la commande:

marionnette sudo s'applique --Test

Il produira un résultat de volume qui affiche toutes les modifications de l'état du support. S'il n'y a pas d'erreurs dans la sortie, vous pouvez ouvrir votre adresse IP externe ou votre nom de domaine dans le navigateur. La page de test PHP apparaît à l'écran avec des informations de pile. Cela signifie que les travaux Apache et PHP.

Maintenant, la pile de lampes est installée sur le serveur à l'aide de la marionnette.

C'est un manifeste assez simple, car il peut être effectué sur l'agent. Si vous n'avez pas d'assistant de marionnettes, d'autres nœuds de l'agence ne seront pas en mesure d'utiliser ce manifeste.

Puppet Master Server vérifie que le statut du serveur change toutes les 30 minutes.

Exemple 2: Réglage de la pile de lampe à l'aide du module

Essayez maintenant de créer un module simple basé sur le manifeste de la lampe 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 des modules (son nom doit correspondre au nom du module). Ce répertoire doit contenir le répertoire Manifestes et le fichier init.pp. Dans le fichier Init.PP, la classe de marionnettes est spécifiée (son nom doit correspondre au nom du module).

Créer un module

Allez sur le serveur maître de marionnettes et créez la structure de répertoire pour le module:

cD / etc / Puppet / Modules
Sudo mkdir -p lampe / manifeste

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

sudo VI Lampe / Manifeste / init.PP

Insérez la classe de la lampe dans le fichier:

lampe de classe (
}

Copiez le contenu du manifeste de la section 1 et insérez-le dans la classe de la lampe. Maintenant, vous avez une définition d'une classe de lampe. D'autres manifestes seront en mesure d'utiliser cette classe comme module.

Enregistrez et fermez le fichier.

Utiliser le module dans le manifeste principal

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

Sur le serveur maître de marionnettes, modifiez un tel fichier:

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

Très probablement, au moment du dossier est vide. Ajoutez les lignes suivantes à ce sujet:

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

Noter: Au lieu de la lampe-1, spécifiez le nom de l'hôte de votre agent de marionnettes pour installer la pile.

Le bloc de nœud vous permet de spécifier le code de marionnettes qui ne sera appliqué qu'à certains nœuds.

L'unité par défaut s'applique à tous les nœuds de l'agence qui n'ont aucun bloc individuel (laissez-le vide). L'unité de la lampe-1 sera appliquée au nœud de l'agence de la lampe-1.

Ajoutez la ligne suivante à ce bloc qui utilise le module de la lampe:

Enregistrez et fermez le fichier.

Maintenant, l'agence Node Puppet sera en mesure de télécharger les paramètres à partir du serveur maître et d'installer la pile de lampes. Si vous souhaitez modifier les modifications en ce moment, exécutez la commande sur l'agent:

sudo Puppet Agent --Test

Les modules sont les moyens les plus appropriés. réutilisation Code de marionnettes. De plus, les modules aident à organiser logiquement le code.

Exemple 3: Installation de la lampe à l'aide de modules publics

Le module MySQL est utilisé de la même manière. Ajoutez de telles lignes aux nœuds bloquants:

classe ("MySQL :: Server":
root_password \u003d\u003e "mot de passe",
}

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

Ajouter une ressource qui copie info.php à l'emplacement souhaité. Utilisez le paramètre source. Ajoutez les lignes suivantes au bloc de nœud:

fichier ("info.php": Nom du fichier de ressource #
Chemin \u003d\u003e "/var/www/html/info.php", # chemin cible
Assurez-vous \u003d\u003e fichier,
Exiger \u003d\u003e Classe ["Apache"], # Apache Classe à utiliser
Source \u003d\u003e "Puppet: ///modules/apache/info.php", l'endroit où vous devez copier le fichier
}

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

La marionnette: ///modules/apache/info.php Puppet copiera dans /etc/puppet/modules/apache/files/info.php.

Enregistrez et fermez le fichier.

Créer un fichier info.php.

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

Maintenant, l'agence Node Puppet sera en mesure de télécharger les paramètres à partir du serveur maître et d'installer la pile de lampes. Si vous souhaitez modifier l'environnement de l'agent en ce moment, exécutez la commande sur ce nœud:

sudo Puppet Agent --Test

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

http: //lamamp_1_public_ip/info.php.

Conclusion

Vous avez maintenant des compétences de base pour travailler avec des modules et des manifestations de marionnettes. Essayez de créer un simple manifeste et un module.

La marionnette est idéale pour la gestion des fichiers de configuration de l'application.

Mots clés:

La gestion d'un grand nombre de systèmes UNIX ne peut pas être appelée à l'aise. Pour changer un paramètre, l'administrateur doit accéder à chaque machine, les scripts ne peuvent que contribuer partiellement, et pas dans toutes les situations.

Il devrait être reconnu que administrateurs Windows Les réseaux sont toujours dans une position plus avantageuse. Il suffit de modifier les paramètres des stratégies de groupe et, après un certain temps, tous les ordinateurs de réseau, y compris le système d'exploitation nouvellement installé "Reconnaître" sur l'innovation, s'ils les concernent certainement. En regardant une longue période de développement d'UNIX, on peut noter que rien de tel que cela ne correspondait pas. Il y a des solutions comme Kickstart, qui aide à l'installation primaire système opérateurMais une plus grande finition nécessitera des efforts considérables. Solutions commerciales telles que Bladelogic et Opsware, le problème de l'automatisation des paramètres résolve uniquement en partie, leur principal avantage. interface graphiqueOui, et laissez-leur les acheter que dans les grandes organisations. Bien sûr, il existe des projets proposant des solutions gratuites, mais pour tout le temps de leur existence, ils ne pouvaient pas créer une grande communauté. Par exemple, CFengine n'est pas très populaire avec les administrateurs, bien que autres que Linux puisse être utilisé dans * BSD, Windows et Mac OS X. Il peut être dû à une complexité relative dans la création de configurations. Lorsque vous décrivez des tâches, il est nécessaire de prendre en compte les fonctionnalités 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, il est nécessaire d'écrire Adduser pour d'autres utilisateursDDD, prendre en compte l'emplacement des fichiers dans différents systèmes, etc. Ceci est un ordre de grandeur complique le processus de rédaction de commandes, il est très difficile de créer la configuration correcte avec le processus et vous pouvez lire les configurations créées après un certain temps pas réel. Malgré la licence GPL Cfengine, un projet d'une personne 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, CFengine est assez satisfaisant au développeur et pour les administrateurs restants, c'est plutôt un excès de maux de tête. Améliorer cfengine développeurs tiers Différents ajouts ont été créés, ce qui n'imprime souvent que la situation. L'auteur de plusieurs de ces modules de Cfengine Luke Kanies à la fin a décidé de développer un outil similaire, mais dépourvu de nombreux défauts de Cfengine.

Caractéristiques de la marionnettes

La marionnette comme Cfengine est un système client-serveur utilisant un déclaratif, c'est-à-dire obligatoire d'effectuer une langue pour décrire les tâches et les bibliothèques à les mettre en œuvre. Les clients périodiquement (par défaut 30 minutes) sont connectés au serveur central et obtenez la dernière configuration. Si les paramètres ne sont pas coïnés avec l'état du système, ils seront exécutés, si nécessaire, le serveur fait référence aux opérations des opérations. Message Server peut enregistrer dans Syslog ou Fichier, créer une planification RRD, envoyer au courrier électronique spécifié. Des niveaux supplémentaires d'abstraction transactionnelle et de ressource émettent une compatibilité maximale avec les paramètres et les applications existants, vous permettant de vous concentrer sur objets du systèmeSans se soucier des différences dans la mise en œuvre et la description des commandes détaillées et des formats de fichiers. L'administrateur fonctionne uniquement avec le type d'objet, le reste de la marionnette prend elle-même. Donc, le type de packages connaît environ 17 systèmes de lots, qui seront automatiquement comptabilisés sur la base d'informations sur la version de la distribution ou du système, bien que, si nécessaire, un gestionnaire de lots puisse être ajouté de force.

Contrairement aux scripts qui ne sont souvent pas possibles à utiliser dans d'autres systèmes, les configurations de marionnettes écrites par des administrateurs tiers fonctionneront principalement sur tout autre réseau. Dans le livre de recettes de marionnettes [ http://www.reductivalabs.com/trac/puppet/tags/puppet%2crecpe] Il y a déjà trois douzaines de recettes prêtes à l'emploi. Actuellement, la marionnette soutient officiellement les systèmes d'exploitation et services suivants: Debian, Redhat / Fedora, Solaris, Suse, Centos, Mac OS X, OpenBSD, Gentoo et MySQL, LDAP.

Marionnette. Langue

Pour continuer, il convient d'abord de traiter les principaux éléments et capacités linguistiques. La langue est l'une des forces de la marionnette. Avec cela, il est décrit par les ressources que l'administrateur prévoit de gérer et des actions. Contrairement à la plupart des solutions, la langue des marionnettes vous permet de simplifier l'appel à toutes les ressources similaires sur tout système dans un environnement hétérogène. Une description de ressource, en règle générale, consiste en un nom, type et attributs. Par exemple, spécifiez un fichier / etc / passwd et définissez ses attributs:

fichier ("/ etc / passwd":

propriétaire \u003d\u003e root,

groupe \u003d\u003e root,

Maintenant, clients, se connectant au serveur, copiez le fichier / etc / passwd et installez les attributs spécifiés. Dans une règle, vous pouvez définir plusieurs ressources à la fois, les séparant avec un point avec une virgule. Et si le fichier de configuration est utilisé sur le serveur diffère du client ou non utilisé du tout? Par exemple, cette situation peut se produire lorsque des paramètres Connexions VPN. Dans ce cas, vous pouvez spécifier la directive source. Voici deux options, comme d'habitude pour spécifier le chemin d'accès à un autre fichier, deux URI du protocole sont également pris en charge: fichier et marionnette. Dans le premier cas, un lien vers un serveur NFS externe est utilisé, dans la deuxième version du serveur de marionnettes, NFS est lancé un service similaire, qui exporte des ressources. Dans ce dernier cas, par défaut, le chemin est indiqué par rapport au répertoire racine de marionnettes - / etc / marionnette. C'est-à-dire que la marionnette de liaison: //server.domain.com/config/sshd_config correspondre au fichier / etc / pute / 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 limiter l'accès au service uniquement à partir d'adresses spécifiques. Par exemple, nous décrivons la section de configuration.

chemin / var / marionnette / config

autoriser * .domain.com.

autoriser 192.168.0. *

autoriser 192.168.1.0/224

nier * .Wireless.domain.com.

Et ensuite faire référence à cette section lorsque vous décrivez la ressource.

source \u003d\u003e "Puppet: //server.domain.com/config/sshd_config"

Avant que le côlon soit le nom de la ressource. Dans les cas les plus simples, comme un nom, vous pouvez simplement spécifier le meilleur alias d'utilisation ou les variables. L'alias est installé à l'aide de la directive sur Alias. Chemin de fichier complet. Dans des configurations plus complexes

fichier ("/ etc / passwd":

alias \u200b\u200b\u003d\u003e passwd

Une autre option de création d'un pseudonyme est bien adaptée dans le cas où vous devez traiter différents systèmes d'exploitation. Par exemple, créez une ressource décrivant le fichier sshd_config:

fichier (sshdconfig:

nom \u003d\u003e $ opératingsystem? (

solaris \u003d\u003e "/ usr / local / etc / ssh / sshd_config",

par défaut \u003d\u003e "/ etc / ssh / sshconfig"

Dans cet exemple, nous avons fait face à la possibilité de choisir. Un fichier pour Solaris est spécifié séparément, le fichier / etc / ssh / sshd_config sera sélectionné pour tous les autres. Vous pouvez maintenant contacter cette ressource sous forme de 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 lancé et reçu un nouveau fichier, vous devez redémarrer le service.

assurez-vous \u003d\u003e vrai,

abonnez-vous \u003d\u003e Fichier

Les variables sont souvent utilisées lorsque vous travaillez avec des données utilisateur. Par exemple, décrivez l'emplacement des répertoires de la maison:

$ Homeroot \u003d "/ home"

Maintenant, vous pouvez contacter les fichiers d'un utilisateur spécifique comme

$ (Homeroot) / $ nom

Le nom du compte de l'utilisateur sera substitué au paramètre $ Nom. Dans certains cas, il est pratique de déterminer la valeur par défaut pour certains types. Par exemple, pour le type Exec, les répertoires dans lesquels il doit rechercher le fichier exécutable sont très souvent indiqués.

Exec (chemin \u003d\u003e "/ usr / bin: / bin: / usr / sbin: / sbin")

En fait, si vous devez spécifier quelques fichiers et répertoires imbriqués, vous pouvez utiliser le paramètre RECURSE.

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

source \u003d\u003e "Puppet: // marionnette: //server.domain.com/config/apache/conf.d",

recueil \u003d\u003e "vrai"

Plusieurs ressources peuvent être intégrées dans des classes ou des définitions. Les classes sont une description complète du système ou du service et sont utilisés à part.

"/ Etc / passwd": propriétaire \u003d\u003e root, groupe \u003d\u003e root, mode \u003d\u003e 644;

"/ Etc / shadow": propriétaire \u003d\u003e root, groupe \u003d\u003e root, mode \u003d\u003e 440

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

classe FreeBSD hérite de Linux (

Fichier ["/ etc / passwd"] (groupe \u003d\u003e roue);

Fichier ["/ etc / shadow"] (groupe \u003d\u003e roue)

Pour plus de commodité, toutes les classes peuvent être apportées à un fichier distinct comprenant une directive include. Les définitions peuvent prendre de nombreux paramètres comme des arguments, mais ne prennent pas en charge l'héritage et sont utilisés si vous devez décrire plusieurs objets utilisés. Par exemple, nous définissons le répertoire domestique des utilisateurs et des commandes dont vous avez besoin pour créer un nouveau compte.

définir user_homedir ($ groupe, $ pleinename, $ ingroups) (

utilisateur ("$ nom":

assurez-vous \u003d\u003e présent

commentaire \u003d\u003e "$ pleinename",

gid \u003d\u003e "$ groupe",

groupes \u003d\u003e $ ingroups,

adhésion \u003d\u003e Minimum,

shell \u003d\u003e "/ bin / bash",

home \u003d\u003e "/ home / $ nom",

exiger \u003d\u003e Groupe [$ groupe],

eXEC ("$ nom HomeDir":

commande \u003d\u003e "/ bin / cp -r / etc / skel / home / $ nom; / Chown -R $ Nom: $ Groupe / Accueil / Note Nom »

crée \u003d\u003e "/ home / $ nom",

exiger \u003d\u003e utilisateur [$ nom],

Maintenant pour créer un nouveau compte Il suffit de contacter user_homedir.

user_homedir ("Sergej":

groupe \u003d\u003e "Sergej",

nom complet \u003d\u003e "Sergej Jaremchuk",

iNGROUPS \u003d\u003e ["Media", "admin]

Séparément, il existe des descriptions de nœuds (noeud) qui supportent l'héritage ainsi que des classes. Lorsque vous connectez le client au serveur de marionnettes, les stands de nœud seront vus et les paramètres spécifiques uniquement pour cet ordinateur sont émis. Pour décrire tous les autres systèmes, vous pouvez utiliser le noeud par défaut. La description de tous types est donnée dans le document "Type de référence" avec laquelle vous devez vous familiariser dans tous les cas, du moins afin de comprendre toutes les caractéristiques de la langue de la marionnette. différents types autorisé à exécuter les commandes spécifiées, y compris lors de la modification du fichier de configuration (par exemple, de modification du fichier de configuration), de travailler avec des groupes croisés, des informations d'identification et des utilisateurs, des ordinateurs, des ressources de montage, des services de démarrage et d'arrêt, d'installation, de mise à jour et de suppression de packages, fonctionnent avec Clés SSH, zones Solaris et ainsi de suite. C'est à quel point il est facile de mettre à jour la liste des packages dans les distributions à l'aide de l'APT, quotidiennement entre 2 et 4 heures.

horaire (quotidiennement:

période \u003d\u003e quotidiennement

gamme \u003d\u003e

eXEC ("/ USR / BIN / APT-OBTENDRE Mise à jour":

horaire \u003d\u003e quotidiennement

Pour cette période, chaque système ne sera mis à jour qu'une seule fois, après quoi la tâche est considérée comme exécutée et sera retirée de ordinateur client. La langue de la marionnette prend en charge d'autres structures familières: conditions, fonctions, tableaux, commentaires et similaires.

Installation de la marionnette.

La marionnette nécessitera Ruby (\u003e \u003d 1.8.1) avec OpenSSL Support et XMLRPC Bibliothèques, ainsi que la bibliothèque plus rapide [ http://reductivelabs.com/projects/facter.]. Dans le référentiel Ubuntu 7.04, utilisé lors d'une installation de test, le paquet de chiots est déjà activé.

Puppet de recherche de $ sudo APT-cache

puppet - Gestion de la configuration centralisée pour les réseaux

puppetmaster - Démon de contrôle de la configuration centralisée de configuration

Lors de l'installation, toutes les dépendances nécessaires seront installées: fact-libopenssl-ruby libxmlrpc-ruby.

$ sudo apt-get installer puppetmastermaster

Vérifiez les bibliothèques rubis par la commande.

$ Ruby -ropenssl -e "met: yep"

~ $ ruby \u200b\u200b-rxmlrpc / client -e "met: yep"

Si des erreurs ne sont pas reçues, tout ce dont vous avez besoin est déjà inclus. Les fichiers dans lesquels sont décrits par la configuration du système souhaité dans la terminologie des marionnettes sont appelés manifestes. Lors du démarrage, le démon tente de lire le fichier /etc/puppet/manifests/site.pp, avec son absence qu'il donne un message d'avertissement. Lorsque vous testez, vous pouvez spécifier un démon pour fonctionner en mode Auton dans lequel le manifeste est requis.

$ sudo / usr / bin / marionpetmasterd -nonodes

Si nécessaire, d'autres fichiers peuvent être connectés à Site.PP si vous pouvez vous connecter. Pour le test Run à ce fichier, vous pouvez appliquer l'instruction la plus simple.

fichier ("/ etc / sudoers":

propriétaire \u003d\u003e root,

groupe \u003d\u003e root,

Tous les fichiers de configuration en tant que serveurs et clients sont situés dans / etc / marionnette. Fichier FileServer.Conf À propos desquels nous avons parlé ci-dessus ne sont pas requis et utilisés uniquement lorsque la marionnette fonctionnera en tant que serveur de fichiers. Ubuntu dans ce fichier, le sous-répertoire / etc / marionpette / fichiers est exporté. Dans le sous-répertoire SSL, les certificats et les touches seront utilisés pour chiffrer les connexions client. Les touches sont créées automatiquement lorsque vous démarrez Puppetmasterd pour la première fois, vous pouvez les créer par commande manuelle.

$ sudo / usr / bin / marionpetmasterd -mkuserers.

Les fichiers Puppetd.conf et Puppetmasterd.conf sont similaires. Ils incluent des paramètres des démons sur le système Clian et le serveur. Le fichier client n'est différent que par la présence paramètre du serveurpointant vers un ordinateur sur lequel Puppetmasterd est en cours d'exécution.

serveur \u003d grinder.com.

logDir \u003d / var / journal / marionnette

vardir \u003d / var / lib / marionnette

rundir \u003d / var / course

# Envoyer le serveur de rapports

Pour ne pas tout imprimer manuellement, vous pouvez créer un modèle à l'aide de la puppetd elle-même.

$ Puppetd -GenConfig\u003e /etc/puppet/puppetd.conf

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

$ Puppetd -genManifest\u003e /etc/puppet/manifests/site.pp

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

tout: [Email protégé]

Les fichiers de configuration ne suffisent pas pour que le client puisse se connecter au serveur. Pour ce faire, vous devez toujours signer des certificats. Tout d'abord, pour que le serveur puisse connaître le nouvel ordinateur sur le système client, nous entrons la commande:

$ sudo puppetd -server groder.com -waitforcert 60 -Test

info: Demande de certificat

aVERTISSEMENT: Le certificat peer ne sera pas vérifié dans cette session SSL

aVIS: N'a pas reçu de certificat

Si une autre chaîne est émise, vous devez vérifier l'opération du serveur.

$ PS AUX | Puppet Grep.

marionnette 5779 0.0 1.4 27764 15404? SSL 21:49 0:00 Ruby / USR / SBIN / PUPPETMASTERD

Le pare-feu doit permettre aux connexions du port 8140.

Sur le serveur, nous obtenons une liste de certificats nécessitant des signatures.

Puppetca $ sudo -List

nomad.grinder.com.

Et souscrire un certificat client.

$ sudo puppetca -sign nomad.ginder.com

Maintenant, le client peut se connecter librement au serveur et recevoir les paramètres.

Malheureusement, toutes les possibilités de marionnettes dans l'article montrent tout simplement pas possible. Mais comme vous le voyez cet outil fonctionnel et flexible qui vous permet de résoudre la plupart des tâches de l'administration simultanée d'un grand nombre de systèmes. Si vous devez configurer plusieurs systèmes par nature. Et le projet le plus important a réussi à collecter jusqu'à présent une communauté petite mais en croissance constante. Par conséquent, nous espérons qu'une bonne idée ne donnera pas à mourir ou de disparaître.

Pas si longtemps, sur les pages du magazine, nous avons considéré le système télécommande Configuration des machines UNIX CFENGINE, qui facilite grandement la vie administrateur du système En automatisant les actions pour configurer une pluralité de nœuds de réseau. Mais peu importe la façon dont Cfengine pratique, il a de nombreux inconvénients, privés d'un système appelé Puppet.

Imaginez-vous comme un administrateur système responsable du maintien de la performance de centaines de systèmes d'exploitation de centaines et d'autres machines telles que UNIX. Chacun d'entre eux nécessite une configuration, des mises à jour périodiques et une surveillance, tout en supposant que beaucoup d'entre eux effectuent des fonctions similaires.

Les deux tiers sont des postes de travail, de plusieurs autres routeurs, le reste se trouvent plusieurs serveurs Web et entrepôts de données. Question: Comment gérer cette économie? La réponse la plus facile est facile à connecter à chacun d'eux à l'aide de SSH et à apporter les modifications nécessaires. Cependant, cette méthode a deux problèmes. Premièrement, c'est très laborieux. Deuxièmement, l'administrateur doit constamment effectuer de nombreuses actions monotones (par exemple, pour mettre à jour OpenOffice.org sur toutes les postes de travail, vous devrez remplir les mêmes commandes de plusieurs dizaines de fois). Vous pouvez essayer d'éviter ce problème en écrivant plusieurs scripts qui se connectent à chaque machine et effectueront des commandes pré-prescrites. Mais ici, vous attendez des problèmes.

Les scripts devront constamment modifier pour les ajuster à chaque tâche; Dans les scripts devra tenir compte de la différence de systèmes d'exploitation et de versions, ils devront les déboguer avant d'appliquer aux machines de travail. En général, pas commilfo. La bonne réponse consiste à utiliser les systèmes de télécommande dites pour les configurations, dont les représentants les plus connus sont systèmes ouverts Cfengine et marionnette. Ces systèmes prennent toutes les responsabilités pour apporter la configuration de machines à Écoute, exigeant de l'administrateur uniquement une description de l'état final du système dans une langue spéciale (par exemple, une description de laquelle les packages doivent être installés dans l'OS, quelles lignes doivent être ajoutées aux fichiers de configuration, les commandes doivent être complétées. , etc.). Après cela, tous les nœuds eux-mêmes recevront des informations sur l'état requis du serveur et l'autoconfiguration du système sera effectuée. Grâce à ce mécanisme, de nouvelles machines peuvent être entièrement configurées sans intervention humaine et les existantes sont reconfigurées en ajoutant seulement quelques lignes à la description de l'état.

Fantoche?

Nous avons déjà consacré tout un article par le système CFengine, nous allons donc nous concentrer sur le système de marionnettes, ce qui peut être appelé son adepte idéologique. Marionnette a été développée par Luke Kanies, fatiguée des restrictions Cfengine et a décidé de la créer d'analogue plus parfait à partir de zéro. Si vous avez déjà utilisé CFENFINE, vous trouverez probablement un système plus pratique et plus pratique. La langue description de l'état de la marionnette est de niveau plus haut et flexible, de sorte que l'administrateur n'a pas besoin de prendre soin de telles choses telles que la rédaction de règles individuelles pour chaque type de système d'exploitation ou description détaillée effectuer des actions triviales. La marionnette permet à son M. se concentre sur ce qu'il veut faire, au lieu de le faire (par exemple, de définir un paquet spécifique à l'un des systèmes de système d'exploitation pris en charge, il suffit d'écrire une "installation de ce programme" ", au lieu de décrire les commandes nécessaires à son installation). Marionnette écrite sur langage simple Ruby, il suffit donc de simplement s'adapter sous la tâche spécifique et d'élargir la fonctionnalité (un système de plug-in flexible est fourni).

En outre, contrairement au modèle CFENGINE, qui tourne en réalité autour d'une personne, une grande communauté d'enthousiastes a été formée autour de la marionnette, ce qui rend le raffinement au code est partagé par les exemples de configuration et écrivez la documentation.

En général, la marionnette donne l'impression d'un système plus moderne et bien pensé avec un bon design. Comme Cfengine, il supporte presque tous les OS modernes de type UNIX (y compris MacOS X), et peut également travailler dans l'environnement Cygwin sur Windows. La liste de ses dépendances ne comprend que l'interprète Ruby et l'outil facteur, il ne devrait donc pas y avoir de problèmes avec l'installation (la justice qu'il convient de dire que la liste des dépendances CFENGINE est également plus courte).

Installation

Comme Cfengne, la marionnette est un système client-serveur qui consiste en un serveur de contrôle et des nœuds subordonnés. Le serveur stocke la description des états finaux des nœuds (qui en termes de marionnette s'appelle un manifeste) et attend leur connexion. Toutes les demi-heure (par défaut) Le client se connecte au serveur, reçoit une description de l'état final, vérifie-la avec le courant et, si elle et / ou l'état décrit modifié, renforçant le système, après quoi il se couche. . La communication est effectuée via un canal crypté, de sorte que les attaques basées sur la substitution de description du statut sont exclues (mais si le craquelez capturera le serveur, tous les nœuds seront sous son contrôle).

La marionnette est incluse dans le référentiel de toutes les distributions populaires. Son installation ne doit donc pas causer de difficultés. Par exemple, à Debian / Ubuntu, le client de marionnettes peut être installé comme suit:

$ sudo apt-get installer puppet

Un serveur - donc:

$ sudo apt-get installer puppetmastermaster

Les fichiers de configuration des clients et du serveur sont stockés dans le répertoire / etc / marionnettes. Le plus important d'entre eux est le fichier /etc/puppet/manifest/site.pps contenant manifeste.

Il stocke la description du statut et devrait exister uniquement sur le serveur. Pour la commodité du débogage, ajoutez-y configuration simple:

Classe passwd (
Fichier ("/ etc / passwd":
Propriétaire \u003d\u003e root,
Groupe \u003d\u003e root,
Mode \u003d\u003e 644,
}
}
Noeud par défaut (
Inclure passwd.
}

Ces lignes décrivent l'état dans lequel le propriétaire du propriétaire / etc / passwd devrait être root et les droits d'accès à 644 sont définis sur 644. Dans la section suivante, nous examinerons le format du fichier manifeste. Le deuxième fichier le plus important est appelé /etc/puppet/puppet.conf. Il définit le serveur et la configuration du client. Il doit donc être présent sur toutes les machines organisées sur le réseau de marionnettes. À Ubuntu, ce fichier contient le minimum nécessaire et dans la plupart des cas, des réglages suffisants. Ci-dessous, ils sont donnés avec des commentaires:

# Vi /etc/puppet/puppet.conf.
# Façons standard des catalogues
LogDir \u003d / var / journal / marionnette
Vardir \u003d / var / lib / marionnette
SSLDIR \u003d / var / lib / marionnette / SSL
Rundir \u003d / var / rude / marionnette
# Emplacement Tool Facter,
# utilisé pour obtenir des informations sur le système d'exploitation
FactPath \u003d $ vardir / lib / factter
# Synchroniser des plugins
# (plugins installés sur le serveur - ils sont copiés aux clients)
Pluginsync \u003d true.
# Catalogue avec des modèles (lisez-les ci-dessous)
Templateir \u003d $ Confdir / Modèles
# Synchronisation avec etckeeper
# (Qui sait - comprendra, le reste n'a pas besoin de)
préerun_command \u003d / etc / marionnette / etckeeper-engort
POSTRUN_COMMAND \u003d / etc / marionnette / etckeeper-comtepost

Le fichier de configuration peut inclure un grand nombre de Différentes options dont les informations peuvent être obtenues en générant une configuration par défaut:

$ sudo marionmasterd-genconfig\u003e / etc / marionnette /
marionpetd.conf.default.

La configuration du client par défaut est générée à l'aide d'une autre commande:

Puppet $ sudo -genconfig\u003e /etc/puppet/puppetd.conf.default

Les fichiers FileServer.conf et auth.conf sont utilisés pour configurer le serveur de fichiers (lisez ceci dans la section Server des fichiers) et d'authentification. Alors qu'ils n'ont aucun sens. À la fin de la configuration, le serveur de marionnettes doit être redémarré:

$ sudo /etc/init.d/puppetmaster redémarrer

Après cela, il sera prêt à accepter les demandes des clients. Cependant, sans certificat signé, aucun client ne peut avoir un manifeste du serveur et configurer la machine.

Par conséquent, nous devons exécuter des clients de marionnettes en mode test afin qu'ils puissent transférer leurs certificats sur le serveur de signature (à la manière, simultanément sur toutes les machines, il peut être effectué à l'aide de l'outil Shmux):

$ sudo puppettd -server serveur de marionnettes --verbose -Test -Test

Nous retournons sur le serveur et obtenez une liste de certificats prêts pour les signatures:

$ sudo pupetca --list

Choisissez un hôte dans la liste et signez-le certificat:

$ sudo puppetca --sign nomad.ginder.com

Ou nous abonnons tout à la fois:

$ sudo puppetca --Sign --all

Maintenant, vous pouvez exécuter des clients en mode de combat. Mais d'abord, vous devez enregistrer le nom du serveur de marionnettes dans le fichier de configuration (par défaut, son nom n'est que marionnette):

$ sudo su.
# Echo "\u003e\u003e /etc/puppet/puppet.conf
# Echo "serveur \u003d marionpet-server.com" \u003e\u003e /etc/puppet/puppet.conf
# SORTIR.

Exécuter les clients:

$ sudo /etc/init.d/puppet commence

Statut Description Langue

Comme mentionné ci-dessus, la marionnette utilise sa propre langue de description de la langue de l'état final du système d'exploitation, avec laquelle le sysadmin indique comment les composants du système d'exploitation doivent être donnés pour atteindre l'état souhaité. C'est une langue assez compliquée qui, cependant, est beaucoup plus facile que tout langage de programmation. Si vous êtes au moins superficiellement familiarisé avec la langue du script Bash, vous pouvez facilement comprendre la langue de la marionnette. L'élément clé de la langue est la ressource avec laquelle la description est basée sur la manière dont l'une des composantes du système d'exploitation devrait être donnée. Par exemple, la ressource la plus simple suivante décrit l'état souhaité du fichier / etc / passwd:

# Vi /etc/puppet/manifest/site.pp.
Fichier ("/ etc / passwd":
Propriétaire \u003d\u003e "root"
}

Ici, le fichier est un type de ressource. Il y en a plusieurs douzaines d'entre eux, allant des ressources qui gèrent des fichiers, comme dans cet exemple, et se terminant par des packages et des services. Rangée / etc / passwd - Nom de la ressource.

Dans le cas du type de fichier, le nom coïncide avec le chemin d'accès au fichier, cependant, dans certains autres types, le nom peut être arbitraire. La ligne de propriétaire \u003d\u003e "root" décrit l'installation de l'attribut propriétaire à la valeur racine, c'est-à-dire qu'il est indiqué que le propriétaire (propriétaire) du fichier spécifié doit être administrateur.

Chaque type de ressources propose son propre ensemble d'attributs disponibles pour la modification, plus il existe des attributs de méta spéciaux pouvant être utilisés dans n'importe quelle ressource. L'une des qualités importantes des ressources est la possibilité de leur référence. Cela peut être utilisé pour former des chaînes de dépendance. L'entrée suivante crée une ressource / etc / groupe qui dépend de la ressource / etc / passwd (les dépendances sont spécifiées à l'aide de l'attribut Meta requiert):

# Vi /etc/puppet/manifest/site.pp.
Fichier ("/ etc / groupe":
Exiger \u003d\u003e fichier ["/ etc / passwd"],
Propriétaire \u003d\u003e "root",
}

Cela signifie que la ressource / etc / groupe peut être configurée (indiquée au ci-dessus) uniquement si la ressource / etc / passwd est configurée. Les ressources peuvent être regroupées dans une collection de ressources appelées classes. Il est nécessaire de combiner des informations similaires et de type de tâches effectuées dans une ressource abstraite. Par exemple, pour la commodité, nous pourrions combiner l'installation et le lancement du serveur Web Nginx sur une ressource abstraite du même nom:

# Vi /etc/puppet/manifest/site.pp.
Classe NGinx (
Paquet ("nginx":
Assurez-vous \u003d\u003e installé
}
Service ("Nginx":
Assurez-vous \u003d\u003e en cours d'exécution,
Exiger \u003d\u003e package ["nginx"],
}
}

Ici, le type de ressource de paquet est utilisé pour installer le package NGinx sur le système et le service doit démarrer le service du même nom. En utilisant besoin, nous forcions le système à démarrer le service uniquement si le package a été installé avec succès. La commodité des classes est qu'elles peuvent également être incluses selon:

# Vi /etc/puppet/manifest/site.pp.
Service ("Squid":
Assurez-vous \u003d\u003e en cours d'exécution,
Exiger \u003d\u003e classe ["nginx"],
}

Comme dans de vraies langues de OOP, les classes peuvent hériter les uns les autres et remplacer les attributs:

# Vi /etc/puppet/manifest/site.pp.
Classe passwd (
Fichier ("/ etc / passwd":
Propriétaire \u003d\u003e "root",
groupe \u003d\u003e "root",
}
}
Classe PassWD-BSD hérite de PASSWD (
Fichier ["/ etc / passwd"] (Groupe \u003d\u003e "Roue")
}

Ici, la classe PASSWD-BSD est héritée de PASSWD pour remplacer l'attribut de ressources de groupe / etc / passwd (dans les systèmes BSD / etc / passwd appartient au groupe de roues, nous avons donc créé une classe distincte pour ces systèmes). Plus tard, nous considérons la manière la plus correcte et évidente de sélectionner des valeurs d'attribut alternatives à l'aide de conditions.

Les variables sont l'une des composantes inaliénables de tout langage de programmation et dans la langue des marionnettes, elles ont également. Les variables commencent à partir de $ Marque et peuvent contenir n'importe quel nombre, chaîne ou valeur booléenne (vrai, faux):

$ Want_apache \u003d true
$ Apache_version \u003d "2.2.14"

L'une des propriétés les plus puissantes de la langue marquissante associée aux variables est l'intégration à un outil permettant d'obtenir des informations sur la machine factter. Cet utilitaire renvoie toutes les informations spécifiques à la machine, sous la forme d'une paire «Valeur de clé», qui dans la marionnette est transformée en variables du même nom. Avec les instructions conditionnelles de la langue des marionnettes, elles peuvent être utilisées pour alterner les attributs de ressources en fonction des propriétés de la machine.

Par exemple, la classe PASSWD décrite ci-dessus peut être facilement réécrite pour sélectionner automatiquement l'attribut en fonction du type de système d'exploitation (la classe elle-même n'est plus nécessaire):

# Vi /etc/puppet/manifest/site.pp.
Fichier ("/ etc / passwd":
Propriétaire \u003d\u003e "root",
Groupe \u003d\u003e $ noyau? (
Linux \u003d\u003e "root",
FreeBSD \u003d\u003e "Wheel",
},
}

Selon le système d'exploitation analysé par ce fragment du manifeste, la valeur d'attribut du groupe sera une racine ou une roue. En plus de l'opérateur conditionnel, la langue de la marionnette prend en charge l'opérateur de sélection de cas, qui peut être utilisée pour créer une ressource une ou une autre en fonction de la valeur de la variable:

# Vi /etc/puppet/manifest/site.pp.
Case $ Operatingsystem (
Redhat: (service ("httpd": assurez-vous \u003d\u003e en cours d'exécution))
Debian: (Service ("Apache": Assurez-vous \u003d\u003e Running))
Par défaut: (service ("Apache2": Assurez-vous \u003d\u003e
En cours))
}

Ce code définit diverses options de ressource pour le type de service, en fonction du système d'exploitation (les noms de service dans différentes distributions Linux peuvent différer, de sorte que le type de service doit exécuter la marionnette, il est nécessaire de spécifier individuellement pour chacun d'entre eux).

La variante par défaut est utilisée si la valeur de la variable ne correspond à aucune des options précédentes. En plus des types de types de ressources, de paquets et de services précédemment discutés, Puppet soutient un grand nombre d'autres, y compris celles créées par des développeurs de types de ressources tiers. Leur description détaillée, y compris des exemples, des attributs et des fonctionnalités prises en charge, pouvez-vous trouver dans la documentation officielle - http://docs.puppetlabs.com/references/stable/type.html. Vous trouverez ci-dessous une liste et une brève description des plus utilisées:

Types de ressources populaires de marionnettes

cron - Gestion des emplois cron
exec - Lancement des scripts et des équipes
fichier - Gestion des fichiers
fileBucket - Fichiers de sauvegarde
gROUPE - Gestion du groupe
host - Gestion des enregistrements dans le fichier / etc / hosts
interface - Configuration des interfaces réseau
systèmes de fichiers de montage de montage
avertissez - Envoi d'un message au fichier journal de marionnettes
paquet - Gestion des packages
service - Services de gestion
sshkey - SSH Keys Management
tidy - Supprimer des fichiers en fonction des conditions
utilisateur - Gestion des utilisateurs
zones - Gestion des zones Solaris

La seconde après que les ressources soient l'importance de la langue de la marionnette - ce sont des nœuds (nœuds). Avec leur aide, l'administrateur peut décrire ce que celles-ci ou autres ressources et classes doivent être appliquées sur les machines. En d'autres termes, il s'agit de la manière de spécifier une configuration individuelle pour chacune des machines participant au réseau de marionnettes. L'exemple le plus simple du nœud est donné au début de l'article dans la section "Installation":

# Vi /etc/puppet/manifest/site.pp.
Noeud par défaut (
Inclure passwd.
}

Ceci est le nœud par défaut par défaut, qui inclut la ressource / classe passwd. Par défaut signifie "tous les autres nœuds", par conséquent, la ressource / la classe passwd, définie quelque part ci-dessus, sera configurée sur chacune d'elles. Inclure le mot-clé ici est utilisé pour plus de commodité, en fait, toutes les classes et les ressources peuvent être décrits directement dans la description du site, mais il n'est pas recommandé de le faire. En plus de par défaut, vous pouvez spécifier le nom du réseau de la machine dans le nom d'hôte (toutes les ressources décrites dans le nœud ne seront configurées que sur cette machine) ou un nom arbitraire (alors ce nœud peut être hérité par un autre nœud). . Pour comprendre comment tout cela fonctionne conjointement avec les classes et les ressources, envisagez un exemple de manifeste de marionnettes à l'emploi utilisé pour configurer deux machines réseau (serveur Web et serveur NTP):

# Vi /etc/puppet/manifest/site.pp.
# Installation et démarrage SSH Server
Classe sshd (
Package (OpenSSH-Server: Assurez-vous \u003d\u003e installé)
Service (SSHD:
Nom \u003d\u003e $ opératingsystem? (
fedora \u003d\u003e "sshd",
Debian \u003d\u003e "ssh",
Par défaut \u003d\u003e "sshd",
},
Activer \u003d\u003e vrai,
Assurez-vous \u003d\u003e en cours d'exécution,
}
}
# Installation et démarrage Apache
Classe httpd (
Paquet (httpd: essure \u003d\u003e installé)
Service (httpd:
Activer \u003d\u003e vrai,
Assurez-vous \u003d\u003e en cours d'exécution,
}
}
# Installation et démarrage du serveur NTP
Classe NTPD (
Package (NTP-Server: Assurez-vous \u003d\u003e installé)
Un service (
NTP-Server:
Activer \u003d\u003e vrai,
Assurez-vous \u003d\u003e en cours d'exécution,
}
}
# Noeud de base, utilisé uniquement comme le parent de tous les autres
Base de nœud (
Inclure sshd.
}
# Noeud sur lequel le serveur Web sera localisé
Node Web.Server.com hérite de la base (
Empêcher HTTPD.
}
# Nœud de serveur NTP
Nœud ntp.server.com hérite de la base (
Inclure NTPD.
}

Cette configuration simple fait beaucoup de configuration: elle conduit à l'installation et au lancement d'Apache sur la machine avec l'adresse Web.Server.com et l'installation et le lancement du serveur NTP en voiture. ntp.server.com.. De plus, les deux machines installent un serveur SSH. Une telle configuration est pratiquement agencée au moins un administrateur; Il devra sérieusement finaliser pour enseigner les serveurs de configuration correctement configurants, recevoir de nouvelles configurations et d'autres fichiers de l'en-tête de marionnettes.

Cependant, il montre clairement le pouvoir de la marionnette. Avec l'aide d'une simple config, nous l'avons fait pour que les machines elles-mêmes installent et démarrent le logiciel nécessaire et l'ont soutenu dans l'état de fonctionnement (si le serveur tombe, la marionnette elle-même réévaluera pour apporter le système à l'état souhaité).

Serveur de fichiers.

Beaucoup de tâches administration distante Ne peut pas être résolu sans copier des fichiers supplémentaires sur des machines. Il peut s'agir de configuration pré-préparée, de pages Web pour Apache, des paquets qui manquent dans le référentiel officiel, et bien plus encore. Pour faciliter le processus de transfert de ces fichiers aux nœuds distants, la marionnette comprend un serveur de fichiers.

Les paramètres du serveur de fichiers sont stockés dans le fichier /etc/puppet/fileserver.conf. Pour forcer la marionnette à donner aux clients le contenu d'un répertoire spécifique, vous devez en mettre plusieurs lignes:

# Vi /etc/puppet/fileserver.conf.
Chemin \u003d / var / marionnette / fichiers
Autoriser * .server.com.

Ces deux lignes indiquent que le répertoire / var / marionnettes / fichiers doit être accessible à tous les hôtes du domaine Server.com. De plus, nous pouvons spécifier le nom de domaine complet de la machine autorisée ou de son adresse IP, ainsi que de couper la directive NYY. Après cela, tout fichier de ce répertoire peut être déplacé sur le client à l'aide de la ressource de fichier. Par example:

# Vi /etc/puppet/manifest/site.pp.
Fichier ("/etc/httpd/conf/httpd.conf":
Source \u003d\u003e "Puppet: //httpd/httpd.conf",
Mode \u003d\u003e 644,
}

Le fichier httpd.conf situé sur le serveur dans le répertoire / var / marionnette / fichiers / httpd sera copié sur la machine cible sur le chemin spécifié dans le nom de la ressource.

conclusions

Dans cet article, nous avons examiné une très petite partie des caractéristiques de la marionnettes. En fait, il s'agit d'un système complet, entièrement décrit uniquement sur les pages du livre. Dans le même temps, la marionnette est très simple dans la mise en place et l'accompagnement, d'autant plus que vous pouvez trouver de nombreux exemples de sa configuration.

Info.

Puppet utilise le protocole HTTP, afin d'augmenter les performances peut exécuter un serveur Web.
La marionnette peut être utilisée pour l'autoconfiguration et maintenir une machine locale.
Combiner la marionnette, installation réseau OS (PXE-INSTALL) et des images d'installation d'auto-assemblage, vous pouvez créer un réseau de machines entièrement configurable, pour déployer ce qu'il suffit d'exécuter une commande.
Puppet utilise de nombreuses grandes entreprises de leur travail, telles que Google, Fedora Project, Stanford University, Red Hat, Siemens IT Solution et SugarCRM.

Liens.

http://docs.puppetlabs.com - Documentation de marionnettes
http://docs.puppetlabs.com/Guides/language_Tutorial.html - Description complète de la langue des marionnettes
http://docs.puppetlabs.com/references/stable/type.html - Types de ressources

Lorsque le nombre de serveurs que vous gérez moins de dix, vous vous demandez rarement de leur gestion centralisée, cela peut ne pas être nécessaire. Lorsque des serveurs dizens - le contrôle centralisé du logiciel et des configurations est extrêmement utile. Lorsque les serveurs sont des centaines et des milliers, c'est vital. Il y a beaucoup de tels programmes, par exemple: Chef, Cfengine, Puppet ... C'est le dernier et sera discuté dans cette entrée.

La marionnette est considérée comme l'une des meilleures solutions de cette manière. Il utilise des entreprises telles que Google, Citrix et Red Hat. Il s'agit d'une application client-serveur écrite dans le langage de programmation Ruby, qui s'étend à deux versions:

Puppet Open Source - Entièrement version gratuite
Puppet Enterprise est une configuration gratuite à 10 serveurs, dont vous avez encore besoin d'acheter des licences.

Envisagez d'installer le serveur et l'agent de marionnette Open Source, qui est présent dans les packages de la plupart des distributions modernes. De plus, nous irons sur Ubuntu 12.04 Pangolin précis.

La partie serveur de marionnettes est appelée maître de la marionnette, commencez à installer à partir de celui-ci:

: ~ # Apt-get installer puppetmaster

Et maintenant le client:

: ~ # Apt-get install installpet

Dans le fichier de configuration du client /etc/puppet/puppet.conf. Vous devez parler du serveur en ajoutant la section suivante:

Server \u003d Puppet.Local Report \u003d True Pluginsync \u003d False

Au premier étage Pluginsync, il est préférable de désactiver.

Commençons le client de marionnettes pour créer une demande de certificat:

: ~ # Puppetd --verbose --Test Info: Création d'une nouvelle clé SSL pour Linux.Local Info: Création d'une nouvelle demande de certificat SSL pour Linux.Local Info: Demande de certificats Empreinte digitale (MD5): E5: EA: AC: 5B: 5B: 22: 9a: BA: 42: B8: A1: 63: 9e: 1f: 1f: 23: 51 Exting; Aucun certificat trouvé et waitforcert est désactivé

Sur le serveur, il est nécessaire de vérifier que la demande de certificat est obtenue et, dans l'affirmative, nous écrivons le certificat:

: ~ # Puppetca --List "Linux.Local" (E5: AC: 5B: 22: 9A: BA: 42: B8: A1: 63: 9e: 1f: 1f: 23: 51): ~ # # Puppetca - -sign Linux.Local Avis: Demande de certificat signée pour Linux.Local Avis: Demovation du fichier Puppet :: SSL :: CertificateRequest Linux.Local à "/var/lib/puppet/ssl/ca/requests/linux.local.pem"

Répétez l'étape précédente sur le client:

: ~ # Puppetd --verbose --Test Info: Certificat de mise en cache de Linux.Local Info: Récupération Info de plug-in: Caching Certificat_Revocation_Revocation_Revocation_Revocation_Revocation_Revocation_ReVocation pour CA Info: Cacheting Catalogue pour Linux.Local Info: Appliquer la version de configuration "1356278451" Info: Création de fichier d'état / Var / lib / marionnette / état / état.yaml Avis: Catalogue fini exécuté en 0.02 secondes

Super, tout fonctionne. Allez à la création du premier manifeste. Manifeste, ils sont décrits dans une langue déclarative spéciale. Nous allons immédiatement prendre soin de bon, utilisez la structure et les classes modulaires. Par exemple, nous écrivons un module qui maintiendra le fichier à jour / etc / hosts Sur tous nos serveurs.

Vérifiez où la marionnette recherche des modules:

: ~ # Marionnette Appliquer --Configionné MODULULEPATH / etc / Modules / Modules: / USR / Share / Puppet / Modules

Créer des répertoires pour votre module

: ~ # Cd / etc / marionnette / modules: ~ # mkdir hôte; Hôtes de CD; Mkdir manifeste; CD manifeste.

Le premier manifeste, il est le fichier principal du module - devrait être appelé init.pp.

Hôtes de classe (# Hôte de marionnette.Local ("Puppet.Local": Assurez-vous \u003d\u003e "présent", cible \u003d\u003e "/ etc / hosts", IP \u003d\u003e "192.168.0.1", host_aliases \u003d\u003e "Puppet",) Linux .local hôte ("linux.local": Assurez-vous \u003d\u003e "présent", cible \u003d\u003e "/ etc / hosts", IP \u003d\u003e "192.168.0.2", hôte_aliases \u003d\u003e "Linux",))

Par défaut, la marionnette recherche un fichier. /etc/puppet/manifests/site.pp. Pour télécharger la configuration, donnez-le au formulaire suivant:

NODE par défaut (Inclure les hôtes)

Vérification du manifeste sur le serveur:

: ~ # Marionnette Appliquer --verbose /etc/puppet/manifest/site.ppos info: Application de la version de configuration "1356281036" Avis: / Stage // Hôte / Assurez-vous: Info créé: FileBucket Ajout (MD5) Avis: / Stage // Hôte / Assurez-vous: Avis créé: Catalogue fini exécuté en 0.03 secondes

Sur le client:

: ~ # Ll / etc / hosts rw-r-r-- 1 racine racine 290 déc. 16 19:10 / etc / hosts: ~ # Puppetd --verbose --Test Info: Cacheting Catalogue pour Linux.Local Info: Application de la configuration Version "1356283380" Info: FileBucket Ajout de l'avis: / Stage / Hôtes / Host / Host / Assurez-vous: Avis créé: Créé Avis: Catalogue fini exécuté en 0.04 secondes: ~ # LL / etc / hosts -rw-r - r- 1 racine racine 551 Dec 233 20:43 / etc / hôte

Après nous nous sommes assurés que tout fonctionne, laissez le service de démarrer le service, dans / etc / par défaut / marionnette Changer:

# Démarrer la marionnette au démarrage? Démarrer \u003d oui.

Courir un service

: ~ # Service de marionnette service

Puppet sera interviewé par un serveur de marionnettes toutes les 30 minutes pour modifier la configuration et, si nécessaire, définissez le réglage du système approprié.

Sergey Yaremchuk

Configuration centralisée des systèmes UNIX utilisant la marionnette

Il convient de reconnaître que les administrateurs de réseau Windows sont toujours dans une position plus avantageuse. Il suffit de modifier les paramètres de stratégies de groupe et, après un certain temps, tous les ordinateurs de réseau, y compris avec un système d'exploitation nouvellement installé, "reconnaître" sur l'innovation s'ils sont, bien entendu. En regardant une longue période de développement d'UNIX, on peut noter que rien de tel que cela ne correspondait pas. Il existe des solutions telles que Kickstart, qui aident à l'installation principale du système d'exploitation, mais une finition ultérieure nécessitera des efforts considérables. Solutions commerciales, telles que Bladelogic et Opsware, le problème de l'automatisation des paramètres ne résolve que dans une partie, leur principal avantage est la présence d'une interface graphique et seules les grandes organisations peuvent les acquérir. Bien sûr, il existe des projets proposant des solutions gratuites, mais pour tout le temps de leur existence, ils ne pouvaient pas créer une grande communauté. Par exemple, CFengine n'est pas très populaire auprès de la popularité des pâteaux, bien que, en plus de Linux, puisse être utilisée dans * BSD, Windows et Mac OS X. Peut-être qu'elle est liée à la complexité relative dans la création de configurations. Les tâches positives doivent 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. C'est-à-dire que l'administrateur doit se rappeler que pour certains systèmes, il est nécessaire d'écrire Adduser pour d'autres personnes - UserAdd, prend en compte l'emplacement des fichiers dans différents systèmes et ainsi de suite. Il s'agit d'un ordre de grandeur complique le processus de rédaction de commandes, il est très difficile de créer la configuration correcte à partir du parc, et les configurations créées lisent quelque temps presque irréaliste. Malgré la licence GPL CFENGINE, en fait, un projet d'une personne 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, CFengine est assez satisfaisant au développeur et pour les administrateurs restants, c'est plutôt un excès de maux de tête. Pour améliorer Cfengine, divers ajouts ont été créés par des développeurs tiers, qui ont souvent aggravé la situation. L'auteur de plusieurs de ces modules de Cfengine Luke Kanies (Luke Kanies) Vitoga a décidé de développer un outil similaire, mais dépourvu de nombreux défauts de Cfengine.

Caractéristiques de la marionnettes

La marionnette, comme Cfengine, est un système client-serveur utilisant un déclaratif, c'est-à-dire obligatoire d'exécuter une langue pour décrire les tâches et la bibliothèque de solides. Les clients périodiquement (par défaut toutes les 30 minutes) sont connectés au serveur central et obtenez la dernière configuration. Si les paramètres ne sont pas coïnés avec l'état du système, ils seront exécutés, si nécessaire, le serveur fait référence aux opérations des opérations. Message Server peut enregistrer le SoftwaRelog ou le fichier, créer une planification RRD, envoyer au courrier électronique spécifié. Des niveaux supplémentaires d'abstraction transactionnelle et de ressource fournissent une compatibilité maximale avec les paramètres et applications soviétiques, vous permettant de vous concentrer sur des objets système, sans vous soucier des différences de mise en œuvre et de décrivant des commandes détaillées des formats de fichiers. L'administrateur fonctionne uniquement avec le type d'objet, le reste de la marionnette prend elle-même. Ainsi, le type de packages connaît environ 17 systèmes de lots, qui seront automatiquement comptabilisés sur la base des informations relatives à la version de la distribution ou du système, bien que, si nécessaire, un gestionnaire de lots puisse être ajouté de force.

Contrairement aux scripts, qui sont souvent impossibles à utiliser dans d'autres systèmes, les configurations de marionnettes écrites par des administrateurs tiers fonctionneront principalement dans tout autre réseau. Puppet Cookbook a déjà trois douzaines de recettes prêtes à l'emploi. Actuellement, la marionnette soutient officiellement les systèmes d'exploitation et services suivants: Debian, Redhat / Fedora, Solaris, Suse, Centos, Mac OS X, OpenBSD, Gentoo et MySQL, LDAP.

Marionnette. Langue

Pour continuer, il convient d'abord de traiter les principaux éléments et capacités linguistiques. La langue est l'une des forces de la marionnette. Avec cela, il décrit les ressources que l'administrateur prévoit de gérer et des actions. Contrairement à la plupart des solutions, la langue des marionnettes vous permet de simplifier l'appel à toutes les ressources similaires sur tout système dans un environnement hétérogène. Une description de ressource, en règle générale, consiste en un nom, type et attributs. Par exemple, spécifiez le fichier / etc / passwd et installer ses attributs:

fichier ("/ etc / passwd":

Propriétaire \u003d\u003e root,

Groupe \u003d\u003e root,

Mode \u003d\u003e 644,

Maintenant, clients, connectant au serveur, copiez le fichier / etc / passwd et installez les attributs spécifiés. Dans une règle, vous pouvez définir plusieurs ressources à la fois, les séparant avec un point avec une virgule. Et que se passe-t-il si le fichier de configuration utilisé sur le serveur diffère du client ou non utilisé du tout? Par exemple, cette situation peut survenir lorsque les connexions VPN sont des paramètres. Dans ce cas, vous devez spécifier le fichier de directive source. Voici deux options, comme d'habitude, comme d'habitude de spécifier le chemin du fichier CDRug, ainsi que d'utiliser les deux protocoles d'URI prises en charge: fichier et marionnette. Dans le premier cas, un lien vers un serveur NFS externe est utilisé, un service de type NFS est lancé dans la deuxième version de Puppet, qui exporte des ressources. Dans ce dernier cas, par défaut, le chemin est indiqué par rapport au répertoire racine de marionnettes / etc / pulet. C'est-à-dire que la marionnette de liaison: //server.domain.com/config/sshd_config correspondre au fichier / etc / pute / config / sshd_config. Vous pouvez remplacer ce catalogue dans 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 limiter l'accès au service de seules adresses sophistiquées. Par exemple, nous décrivons la section de configuration:

Chemin / var / marionnette / config

Autoriser * .domain.com.

Autoriser 127.0.0.1

Autoriser 192.168.0. *

Autoriser 192.168.1.0/224

Nier * .Wireless.domain.com.

Et ensuite faire référence à cette section lorsque vous décrivez la ressource:

source \u003d\u003e "Puppet: //server.domain.com/config/sshd_config"

Avant que le côlon soit le nom de la ressource. Dans les cas les plus simples, vous pouvez simplement spécifier le chemin complet du fichier. Dans des configurations plus complexes, il est préférable d'utiliser des alias ou des variables. L'alias est défini à l'aide de la directive sur Alias:

fichier ("/ etc / passwd":

Alias \u200b\u200b\u003d\u003e passwd

fichier (sshdconfig:

Nom \u003d\u003e $ opératingsystem? (

Solaris \u003d\u003e "/ usr / local / etc / ssh / sshd_config",

Par défaut \u003d\u003e "/ etc / ssh / sshconfig"

service (SSHD:

Assurez-vous \u003d\u003e vrai,

Abonnez-vous \u003d\u003e Fichier

Les variables sont souvent utilisées lorsque vous travaillez avec des données utilisateur. Par exemple, décrivez l'emplacement des répertoires d'annuaire à domicile:

$ Homeroot \u003d "/ home"

Maintenant, vous pouvez contacter les fichiers d'un utilisateur particulier comme suit:

$ (Homeroot) / $ nom

Le nom du compte de l'utilisateur sera substitué au paramètre $ Nom. Dans certains cas, il est pratique de déterminer la valeur par défaut pour certains types. Par exemple, pour le type Exec, les répertoires dans lesquels il devrait voir que le fichier exécutable est très souvent indiqué:

Exec (chemin \u003d\u003e "/ usr / bin: / bin: / usr / sbin: / sbin")

Dans le cas où vous devez spécifier plusieurs fichiers et répertoires imbriqués, vous pouvez utiliser le paramètre Recurez:

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

Source \u003d\u003e "Puppet: // marionnette: //server.domain.com/config/apache/conf.d",

Recueil \u003d\u003e "vrai"

Plusieurs ressources peuvent être combinées en classes ou définitions. Les classes sont la description complète du système ou du service et sont utilisées pour être séparées:

classe Linux (

Déposer (

"/ etc / passwd": ovner \u003d\u003e root, groupe \u003d\u003e root, mode \u003d\u003e 644;

"/ etc / shadow": ovner \u003d\u003e root, groupe \u003d\u003e root, mode \u003d\u003e 440

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

classe FreeBSD hérite de Linux (

Fichier ["/ etc / passwd"] (groupe \u003d\u003e roue);

Fichier ["/ etc / shadow"] (groupe \u003d\u003e roue)

Pour plus de commodité, toutes les classes peuvent être apportées à un fichier distinct pour connecter la directive Inclure. Les définitions peuvent prendre de nombreux paramètres comme des arguments, mais ne prennent pas en charge l'héritage et sont utilisés si vous devez décrire plusieurs objets utilisés. Par exemple, nous définissons le répertoire domestique des utilisateurs et les commandes dont vous avez besoin pour créer un nouveau compte:

définir user_homedir ($ groupe, $ pleinename, $ ingroups) (

Utilisateur ("$ nom":

Assurez-vous \u003d\u003e présent

Commentaire \u003d\u003e "$ pleinename",

Gid \u003d\u003e "$ groupe",

Groupes \u003d\u003e $ ingroups,

Adhésion \u003d\u003e Minimum,

Shell \u003d\u003e "/ bin / bash",

Home \u003d\u003e "/ home / $ nom",

Exiger \u003d\u003e Groupe [$ groupe],

EXEC ("$ nom HomeDir":

Commande \u003d\u003e "/ bin / cp -r / etc / skel / home / $ nom de nom; / bin / chown -r $ nom: $ groupe / home / $ nom"

Crée \u003d\u003e "/ home / $ nom",

Exiger \u003d\u003e utilisateur [$ nom],

Maintenant, pour créer un nouveau compte, il suffit de contacter user_homedir:

user_homedir ("Sergej":

Groupe \u003d\u003e "Sergej",

Nom complet \u003d\u003e "Sergej Jaremchuk",

INGROUPS \u003d\u003e ["Media", "admin]

Décrit séparément les nœuds (noeud) qui supportent l'héritage, ainsi que des classes. Lorsque le client est connecté au serveur de marionnettes, la section NODE correspondante sera sélectionnée et les paramètres spécifiques uniquement pour cet ordinateur sont émis. Pour décrire tous les autres systèmes, vous pouvez utiliser le noeud par défaut. La description de tous types est donnée dans le document "Type de référence" avec lequel vous devez lire dans tous les cas, au moins afin de comprendre toutes les caractéristiques de la langue de la marionnette. Différents types permettent ces commandes, y compris lors de la modification de certaines conditions (par exemple, de modifier le fichier de configuration), de travailler avec des groupes croisés, des informations d'identification et des utilisateurs, des ordinateurs, des ressources montées, des services de démarrage et d'arrêt, d'installation, de mise à jour et de suppression de packages, fonctionnent avec SSH. clés, zones de solaris et ainsi de suite. C'est à quel point on peut simplifier la mise à jour de la liste des packages dans les distributions en utilisant APT, quotidiennement entre 2 et 4 heures:

horaire (quotidiennement:

Période \u003d\u003e quotidiennement

Gamme \u003d\u003e

eXEC ("/ USR / BIN / APT-OBTENDRE Mise à jour":

Horaire \u003d\u003e quotidiennement

La mise à jour de cette période par chaque système ne sera effectuée qu'une seule fois, après quoi la tâche est considérée comme exécutée et sera supprimée de l'ordinateur client. La langue de la marionnette prend en charge d'autres structures familières: conditions, fonctions, tableaux, commentaires et similaires.

Installation de la marionnette.

La marionnette nécessitera de rubis (à partir de la version 1.8.1 et de la version ultérieure) avec OpenSSL Support et des bibliothèques XMLRPC, ainsi que de la bibliothèque plus rapide. Dans le référentiel Ubuntu 7.04, utilisé lors d'une installation de test, le paquet de chiots est déjà activé:

Puppet de recherche de $ sudo APT-cache

~ $ ruby \u200b\u200b-rxmlrpc / client -e "met: yep"

ouais.

Si des erreurs ne sont pas reçues, cela signifie que tout ce dont vous avez besoin est déjà inclus. Les fichiers décrivant la configuration du système souhaitée, la terminologie de marionnettes s'appelle des manifestes (manifestes). Lors du démarrage, le démon tente de lire le fichier /etc/puppet/manifests/site.pp, avec son absence qu'il donne un message d'avertissement. Lorsque vous testez, vous pouvez spécifier un démon pour travailler hors ligne, dans lequel le manifeste est requis:

$ sudo / usr / bin / Puppetmasterd --Nonodes

Si nécessaire, d'autres fichiers peuvent être connectés à Site.PP si vous pouvez vous connecter. Pour le test Run à ce fichier, vous pouvez appliquer l'instruction la plus simple.

classe sudo (

Fichier ("/ etc / sudoers":

Propriétaire \u003d\u003e root,

Groupe \u003d\u003e root,

Mode \u003d\u003e 440,

noeud par défaut (

Inclure sudo.

Tous les fichiers de configuration, les serveurs et les clients sont situés dans / etc / marionnette. Le fichier FileServer.conf, que nous avons déjà parlé n'est pas requis et n'est utilisé que lorsque la marionnette fonctionnera également comme serveur de fichiers. Ubuntu dans ce fichier, le sous-répertoire / etc / marionpette / fichiers est exporté. Dans le sous-répertoire SSL, les certificats et les touches seront utilisés pour chiffrer les connexions client. Les clés sont créées automatiquement lorsque vous démarrez First Puppetmasterd, vous pouvez les créer manuellement avec une commande:

$ sudo / usr / bin / puptetmasterd --mkuSers

Les fichiers Puppetd.conf et Puppetmasterd.conf sont similaires. Ils incluent certains paramètres 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 spécifiant l'ordinateur sur lequel Puppetmasterd est en cours d'exécution:

serveur \u003d grinder.com.

logDir \u003d / var / journal / marionnette

vardir \u003d / var / lib / marionnette

rundir \u003d / var / course

# Envoyer le serveur de rapports

rapport \u003d vrai.

Pour ne pas tout imprimer manuellement, vous pouvez créer un modèle à l'aide de PUPPETD:

$ Puppetd --GenConfig\u003e /etc/puppet/puppetd.conf

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

$ Puppetd --genManifest\u003e /etc/puppet/manifests/site.pp

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

tout: [Email protégé]

Les fichiers de configuration ne suffisent pas pour que le client puisse se connecter au serveur. Pour ce faire, vous devez toujours signer des certificats.

Premièrement, que le serveur apprend à propos d'un nouvel ordinateur, nous entrons la commande sur le système client:

$ sudo chippedd --Server grind.com --waitforcert 60 -Test

Le pare-feu doit permettre aux connexions du port 8140.

Sur le serveur, nous recevons une liste de certificats nécessitant des signatures:

Puppetca $ sudo -List

nomad.grinder.com.

Et souscrire un certificat client:

$ sudo puppetca -sign nomad.ginder.com

Maintenant, le client peut se connecter librement au serveur et recevoir les paramètres.

Malheureusement, toutes les caractéristiques de la marionnette dans l'article sont impossibles. Mais comme vous pouvez le constater, il s'agit d'un outil fonctionnel et flexible qui vous permet de résoudre la plupart des tâches de l'administration simultanée d'un grand nombre de systèmes. Et surtout, le projet a réussi à recueillir jusqu'à présent une communauté petite mais en croissance constante. Par conséquent, nous espérons qu'une bonne idée ne donnera pas à mourir ou de disparaître.

Bonne chance!

Le site du projet Bladelogic - http://www.bladelogic.com.
Site de projet Opsware - http://www.opsware.com.
Site de projet Cfengine - http://www.cfengine.org.
Site de projet de marionnettes http://reductivelabs.com/projects/puppet.
Puppet Cookbook - http://www.reductivalabs.com/trac/puppet/tagspuppet%2Ceupe.
Bibliothèque plus rapide -