====== Gestionnaires de déploiement de configuration ======

===== Ansible =====

^Site officiel|[[https://www.ansible.com/|https://www.ansible.com/]]|
^Communauté|Forte|
^Visibilité|Forte|
^Licence|OpenSource + Commerciale|

Le produit phare du moment, utilisé sur les gros projets OpenSource à la mode (OpenStack, OpenShift etc). Ne nécessite pas de serveur, ni de client. Utilise SSH pour se connecter aux clients.

Avantages :

  * Plutôt orienté scripting donc plait aux SysAdmin
  * Plutôt orienté livrable de configuration d'appliance, en primo installation
  * Ne nécessite presque rien, surtout sur les clients

Inconvénients :

  * Langage de description (playbook) par forcément très lisible
  * Orienté scripting (fonctionnel) donc pas forcément adapté à des usages complexes (=object)
  * Machine centrale doit pouvoir se connecter aux clients via SSH (problème de sécurité si connexion automatisée par ex avec clef SSH)

A noter qu'il existe une version commercial (Tower) qui permet d'avoir une base de données contenant l'historique des actions. Accessible via interface web ou API REST.

Le modèle Ansible est surtout à retenir dans le cadre d'une administration décentralisée. Par exemple un sysadmin, avec son portable, qui gère un parc complet de serveurs. Ansible sera installée sur son laptop pour piloter les déployements. Comme il est orienté scripting, il est facile d'orchestrer/ordonnancer les actions.

===== Chef =====

S'appuie principalement sur le langage Ruby pour décrire les configurations en une série d'étapes (steps). Il est donc assez complexe à prendre en main (connaissance du Ruby) et est orienté scripting (exécution en série).

Vu dans le déploiement/installation de Gitlab.


===== CfEngine =====

^Site officiel|[[https://www.ansible.com/|https://cfengine.com/]]|
^Communauté| |
^Visibilité|Faible ?|
^Licence|OpenSource GPL3 + Commerciale (support)|

Le produit historique (1993). Le langage de description est assez complexe, surtout en terme de lisibilité. Il s'agit sûrement de son principal (et unique?) défaut vis à vis de la concurrence plus récente.

Il propose un mode standalone, il est donc très simple de tester les développements.

Le plus gros client connu est LinkedIn (en 2014) avec 40 000 serveurs.

Avantages :

  * historique
  * mode standalone

Inconvénients :

  * Lisibilité des descriptions/configurations
  * perte de visibilité ?

===== SaltStack =====

^Site officiel|[[https://saltstack.com/|https://saltstack.com/]]|
^Communauté|Moyenne|
^Visibilité|Faible|
^Licence|OpenSource + Commerciale|

Anciens du projet Puppet qui vu la gouvernance du projet (~ problème d'ego) ont lancé un nouveau projet from scratch. Il bénéficit donc de tous les avantages de l'expérience Puppet, en natif. Pas besoin d'installer différentes briques comme avec Puppet (puppetDB, Hiera etc).

Avantages :

  * Langage de description très lisible (yaml)
  * Langage du moteur et des classes très souple (Python)
  * Rapide
  * Facile à tester et à developper (lancement d'unité de classe à la volée sur machine ciblée)
  * Hautement personnalisable (choix des langages de description, de templates etc)

Inconvénients :

  * Pas trop visible
  * Communauté ?

\\


====== Matrice de comparaison ======

^Fonctionnalité^Ansible^Chef^CfEngine^Puppet^SaltStack|
|consommation ressources|leger| | |moyen/léger sans service|léger|
|décrire un module| |Complexe|Moyen|langage puppet simple|simple via langage yaml|
|choix du langage module| |non| |non|oui|
|scripter dans une definition de module| | | |limité|oui|
|conf client stockée sur serveur| | | |via puppetDB|natif (grains)|
|possibilité de surchargée un module| | | |via hiera|natif (pillar)|
|Langage du moteur|Python| | |Java/Ruby|Python|
|Langage template par defaut|Jinja/Python| | |ERB/Ruby|Jinja/Python|
|choix du langage template| | | |non|oui|
|Moteur externe (ENC)|Dynamic inventory| |possible|oui (ENC)|oui (Renderer Pipes)|
|Pilotage depuis le master|oui uniquement (pas de client)| | |non (ou avec func par ex)|oui|

\\