Initiation à la marionnette

Qu’est-ce qu’une marionnette et pourquoi devrais-je m’en soucier ?

Puppet est une solution de gestion de configuration. Les utilisateurs décrivent l’état souhaité d’un serveur ou d’un logiciel et la gestion de la configuration atteint cet état. Cela apporte les avantages suivants :

  • Les configurations peuvent être reproduites à l’identique à chaque fois, autant de fois que nécessaire
  • Les configurations de tous les logiciels et serveurs sont stockées dans un emplacement central. Cela rend la sauvegarde et le contrôle de version des configurations facilement réalisables
  • Les modifications apportées à tous les serveurs se propagent dans toute l’infrastructure en quelques minutes, sans avoir à se connecter directement à une machine
  • Tout est décrit dans la même langue, ce qui facilite la configuration de nouveaux logiciels
  • Les modules s’apparentent à des bibliothèques et permettent de consolider les configurations. Des modules pour tous les principaux progiciels existent déjà, ce qui rend leur installation extrêmement facile
  • Les serveurs peuvent partager des informations entre eux, influençant la configuration des autres serveurs. Par exemple, un nouveau serveur peut s’enregistrer automatiquement auprès de la solution d’équilibrage de charge et de surveillance

Puppet utilise Ruby pour décrire l’état souhaité d’un serveur, appelé nœud. Pour ce faire, il utilise des primitives appelées types de ressources. Par défaut, toutes les 30 minutes, le marionnette agent s’authentifie auprès du marionnette serveur. Il envoie ensuite une liste de ses propres propriétés appelées facts. Le serveur examine les faits et les fichiers de configuration appelés manifests et compile l’état souhaité pour le nœud. Il renvoie ensuite cette configuration au nœud, où l’agent l’applique.

Pour donner une idée de la puissance que cela peut avoir, voici quelques exemples de complexité croissante montrant ce que la marionnette peut faire pour vous.

Exemple : Utilisateur

Cet exemple crée l’utilisateur username sur le nœud myserver et l’ajoute au groupe wheel.

node 'myserver' {
    user { 'username':
      ensure => 'present',
      groups => ['wheel'],
    }
}

Ce fichier qui serait stocké sur la marionnette serveur est le manifeste. Le type de ressource dans cet exemple est utilisateur. Chaque type de ressource possède des propriétés facultatives et obligatoires. Dans cet exemple, ensure est obligatoire et groups est facultatif. Cette configuration spécifique ne serait appliquée qu’à myserver. Vous pouvez appliquer des configurations à tous les nœuds en les plaçant en dehors d’une définition de nœud.

Il est possible de prendre quelques définitions de ressources et de les stocker en tant que modules. Un module est similaire à une bibliothèque. Ces modules peuvent être partagés en ligne et vous en trouverez généralement un pour chaque progiciel majeur. La manière officielle de partager des modules est via la puppet forge : https://forge.puppet.com/

Exemple : Postgres

Cet exemple installe un serveur postgres sur le nœud myserver et crée une base de données db, détenue par username, identifiée par password. Il le fait en utilisant le module postgresql.

node 'myserver' {
    class { 'postgresql::server': }
    
    postgresql::server::db { 'db':
        user     => 'username',
        password => 'password',
    }
}

Dans ce cas, postgresql est un module. Le module lui-même s’occupe d’identifier le système d’exploitation, de télécharger et d’installer le programme, puis de le configurer en fonction du manifeste. Il s’agit d’un exemple de base, mais le module permet de nombreuses personnalisations.

Notez qu’il n’est pas nécessaire de connaître SQL ou comment installer un serveur postgres pour le faire. Les modules officiels sont bien entretenus et fournissent une configuration de base saine et sécurisée.

Il est également possible d’utiliser facts dans les manifestes. Les faits agissent comme des variables.

Exemple : conditions utilisant des faits

Cet exemple utilise le module rsyslog pour configurer rsyslog sur toutes les machines non Windows.

if $osfamily != 'windows' {
  class { 'rsyslog::client': }
}

$osfamily est un fait. Ces faits sont rassemblés à chaque fois que l’agent marionnette s’exécute. Notez que cette définition étant en dehors d’une définition de nœud, elle est appliquée à tous les nœuds. Cependant, rsyslog::client ne sera exécuté que sur les nœuds qui n’exécutent pas Windows.

Étant donné que la marionnette utilise ruby, les éléments de programmation tels que les flux de contrôle et les variables peuvent être utilisés dans les manifestes.

Avec l’ajout de PuppetDB, vous pouvez partager des informations entre plusieurs nœuds. Cela permet à un nœud d’influencer la configuration d’un nœud différent. Les exemples classiques incluent les équilibreurs de charge ou les solutions de surveillance.

Exemple : enregistrement d’un hôte avec surveillance à l’aide de ressources exportées

Cet exemple crée une ressource exportée sur un nœud, puis importe cette ressource sur le serveur de surveillance, en ajoutant l’hôte à la surveillance. Il utilise le module de marionnettes Icinga2.

@@icinga2::object::host { $::fqdn:
  display_name     => $::fqdn,
  ipv4_address     => $::ipaddress_eth0,
}

node 'icinga2' {
    Icinga2::Object::Host <<| |>> { }
}

@@icinga2::object::host crée un objet de définition d’hôte. Ceci est créé par chaque nœud qui exécute ce code. Le @@ le marque comme une ressource exportée. Habituellement, les nœuds ne partagent pas d’informations dans la marionnette. Les ressources exportées permettent de le faire.

Notez que toutes les valeurs de propriété dans la définition d’hôte sont des faits. Cela signifie qu’ils seront différents pour chaque nœud qui l’exécute.

Enfin, la ressource exportée est importée par le nœud icinga2. Le module Icinga2 est chargé de s’assurer que les fichiers de configuration corrects sont créés et rechargés.

C’est pour vous ?

Si vous effectuez des déploiements, configurez vos applications sur plusieurs serveurs et devez vous connecter à vos serveurs et apporter des modifications à l’infrastructure, aux applications, aux prérequis, etc., alors la marionnette peut certainement vous aider.

Sauf tout cela si vous gérez une grosse infrastructure et souhaitez une gestion centralisée vous pouvez aussi y jeter un œil.

Avant de démarrer

Avant de décider de travailler sur des marionnettes, il y a peu de choses que vous devez savoir.

  1. travail de marionnettes dans l’architecture client-serveur (largement utilisée) également single machine (specially for testing purpose)

  2. puppet master ne peut être configuré que sur une machine Linux (master machine/node), windows can be used only as client (managed machine/node)

  3. si vous configurez le maître, vous devez être conscient de l’utilisation de la machine linux et des commandes de base

  4. la marionnette fournit son propre langage de configuration qui ressemble à json

Documents officiels

Puppet fournit une documentation officielle pour les versions open source et entreprise. vous pouvez le trouver [ici][1]

[1] : https://docs.puppet.com/ “Document officiel”

Installation

Configuration requise

Cependant, le service maître Puppet est assez gourmand en ressources et doit être installé sur un serveur dédié robuste.

  • Au minimum, votre serveur maître Puppet doit avoir deux cœurs de processeur et au moins 1 Go de RAM.
  • Pour desservir confortablement au moins 1 000 nœuds, il doit disposer de 2 à 4 cœurs de processeur et d’au moins 4 Go de RAM.

Vérifiez votre configuration réseau :

Dans un déploiement agent/maître, vous devez préparer votre réseau pour le trafic de Puppet.

  • Pare-feu : Le serveur maître Puppet doit autoriser les connexions entrantes sur le port 8140 et les nœuds d’agent doivent pouvoir se connecter au maître sur ce port.
  • Résolution de nom : Chaque nœud doit avoir un nom d’hôte unique. Les DNS direct et inverse doivent tous deux être configurés correctement.

Remarque : Le nom d’hôte par défaut du maître Puppet est puppet. Vos nœuds d’agent peuvent être prêts plus tôt si ce nom d’hôte correspond à votre Puppet maître.

L’heure doit être réglée avec précision sur le serveur maître Puppet qui agir en tant qu’autorité de certification. Vous devriez probablement utiliser NTP.

Installation du serveur de marionnettes

Puppet fournit des packages officiels qui installent Puppet Server 2.4 et tous ses prérequis sur les plates-formes suivantes.

Red Hat Enterprise Linux

  • Entreprise Linux 6
  • Entreprise Linux 7

Debian

  • Debian 7 (Wheezy)
  • Debian 8 (Jessie)

Ubuntu

  • Ubuntu 12.04 (précis)
  • Ubuntu 14.04 (de confiance) -Ubuntu 15.10 (Wily) -Ubuntu 16.04 (Xénial)

Activer les référentiels de packages Puppet

** Linux d’entreprise 7 **

sudo rpm -Uvh https://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm

[Pour les autres versions, regardez ici][2]

Installation du maître des marionnettes

yum install puppetserver

ou

apt-get install puppetserver

Puppet Server est configuré pour utiliser 2 Go de RAM par défaut. Pour changer [regardez ici][1]

Démarrez le service Puppet Server :

systemctl start puppetserver

ou

service puppetserver start

[1] : https://docs.puppet.com/puppetserver/2.4/install_from_packages.html#memory-allocation [2] : https://docs.puppet.com/puppet/latest/reference/puppet_collections.html#enterprise-linux-7

Gestion du montage NFS →