Archive

Posts Tagged ‘Automatisation’

Puppet

Je vous parlais il y à quelques temps de CFEngine en termes de déploiement automatisé mais j’utilise depuis maintenant 2 bons mois une autre techno de ce genre : Puppet. Il s’agit à nouveau d’un outil dont je ne rappellerai pas trop les concepts principaux qui sont décrits dans l’article CFEngine 3 mais je m’attarderai plus sur les spécificités du programme en lui même.

Intro :

Puppet est un gestionnaire de déploiement de configurations basé sur le langage Ruby; de ce fait un environnement Ruby sera nécessaire pour son bon fonctionnement sur les différents postes à administrer. Le programme en lui même permet les opérations suivantes :

– Installation de paquets automatisée

– Execution de commandes shell

– Copie de fichiers de configuration entre clients/serveur

– Génération de fichiers de configurations spécifiques

– Maintient à jour des systèmes et gestion de versions

– Etc

Certes beaucoup de points communs avec CFE vous allez me dire mais la principale différence que j’ai constatée est que Puppet est bien plus rapide à prendre en main (je ne vais pas non plus trop troller :p) malgré les perfs utilisées par Ruby et que l’on peut utiliser beaucoup de fonctions avancées inexistantes sur CFE.

Fonctionnement :

Puppet fonctionne en mode client/serveur, de ce fait 2 paquets distincts sont disponibles sur les différents repos correspondant à votre distribution (sauf pour Gentoo où les 2 paquets sont liés). Le paquet Puppetmaster comprend le serveur ainsi que les différents outils pour l’administration (gestion des certificats, templates,etc), le client contient quand à lui l’outil de synchronisation et un système de reporting. Les différentes configurations sont basées sur une approche de Ruby et donc certaines fonctions avancées de programmation seront disponibles (tiens on parlerait de langage objet?) telles que les boucles, classes et autres.

Autre chose ?

Oh que oui, le fait que Puppet utilise Ruby permet de développer différents outils afin de simplifier l’utilisation du programme, par exemple CFEngine ne possède pas d’IHM, ce qui peut être problématique, Puppet quand à lui possède différentes interfaces pouvant être liées au système. Il n’y à également pas besoin de mettre en place de serveur web de type apache pour accéder aux interfaces d’administration car Puppet utilisera le serveur Rails intégré à Ruby et ne prendra donc pas de ressources supplémentaires.

Pour finir :

Comme pour CFEngine, Puppet ne possède pas beaucoup de documentation en français, cependant je me suis rédigé quelques « how to » que je mettrai à votre disposition via le blog assez rapidement (bien que j’aie des deadlines assez short en ce moment). Cependant le site de PuppetLabs reste très bien fourni en documentation en anglais si jamais vous voulez déjà jeter un coup d’oeil 😉

Pour ma part je vous dit à bientôt pour de nouveaux articles avec un délai un peu plus rapproché entre les publications 😉

Publicités

Cfengine 3

Hello 🙂

Aujourd’hui un article un peu particulier car je vais vous parler d’un outil d’administration plutôt pratique que j’utilise depuis peu : Cfengine 3.

Tout d’abord une simple question: aimez vous les tâches répétitives lors d’installations de serveurs, par exemple lors de l’installation de 10 serveurs identiques ? Non j’imagine car le temps passé à ces installations pourrait être utilisé à d’autres tâches d’administration. Pour celà je vais vous présenter un outil dont je me sers depuis quelques temps (et qui manque malheureusement de documentation dans nos chers pays francophones) : CFEngine 3.

 

Donc tout d’abord le principe: cet outil permet de centraliser toutes les configurations de vos serveurs ainsi que de permettre un déploiement rapide de nouveaux services/paquets sur de nouveaux postes en production (par exemple déployer un serveur apache sur 15 serveurs en même temps ne prendra que 30 secondes). L’outil se base sur un concept nommé « Build-Deploy-Manage-Audit » qui signifie que l’outil sait se gèrer lui même et saura se débrouiller pour rester fonctionnel et assurer sa propre maintenance. C’est bien beau vous allez me dire mais comment faire confiance à un programme ? Tout simplement par un paramétrage plutôt bien conçu au niveau de l’outil qui permet de s’assurer un backup de configuration fonctionnelle et passera dessus dès qu’un problème est détecté. En cas de nouvelle « politique » de déploiement l’outil modifiera sa configuration et s’adaptera aux nouvelles directives.

 

Et du coup qu’est ce que ça fait ?

Tout d’abord il faut savoir que l’outil ne possède « presque » pas de limites car il peut agir sur la majorité des applications et configurations système selon ce que vous avez paramétré (il y aura par contre des limitations au niveau de clients Windows) et remplira comme rôles principaux :

  • L’installation de logiciels automatiquement
  • Copies de fichiers entre client/serveur dans les 2 sens
  • Ajout de configurations spécifiques pour certains programmes
  • Exécution de commandes Shell
  • Mises à jour
  • Et bien d’autres utilités …

 

Et comment on configure tout ça ?

Bah justement il n’y à pas grand chose à spécifier si ce n’est les principales informations nécessaires à la configuration, le logiciel agit de façon « intelligente » et arrivera à « deviner » sur quel environnement il est exécuté, quel type d’architecture est utilisé sur le serveur, quelle version d’OS est présente (vous n’aurez pas à vous soucier avec des questions comme « et s’il effectuait un Yum install sur un Debian? ») et autres car le logiciel vous fournit pas loin de 50 détails utilisables dans vos configurations. En termes de fichiers à concevoir je vous en parlerai d’ici pas très longtemps avec un petit tutorial dans notre belle langue de Molière.

 

C’est bien gentil mais niveau sécurité ?

Encore une fois rien à craindre car le programme ne pourra pas recevoir de nouvelles configurations sans votre accord et encore moins si vous ne faites pas partie du réseau local. En terme d’accès via le réseau, un système de chiffrement par clés asymétriques RSA est mis en place au sein du programme et les clés ne sont échangées qu’une fois lors de la synchronisation d’un nouvel équipement.

 

Et pour la distribution sur le réseau ?

Comme dit précédemment les données sont échangées de manière sécurisée par SSL et donc rien à craindre de ce coté là. Maintenant en termes de politiques de déploiement il faut au moins avoir un serveur dédié à la distribution de la politique de déploiement choisie (ce même serveur peut également gérer les versions de vos logiciels présents sur votre parc mais nécessitera l’aide d’un programme comme CVS ou Subversion); ce mêm serveur peut distribuer cette politique à différents hôtes clients voire d’autres serveurs de distribution (uniquement pour des grosses architectures) et enfin sous ces dits-serveurs d’autres clients.

 

Autre chose à savoir ?

Oh que oui car je n’ai fait que dégrossir la « bête » et je vous proposerai d’ici peu un tutorial détaillant la mise en place d’une telle solution avec un petit exercice bien sympa vous verrez 🙂

 

Sur ce je vous dit à bientôt et restez branchés ! 🙂