veilletechno:confdeploy

Gestionnaires de déploiement de configuration

Site officielhttps://www.ansible.com/
CommunautéForte
VisibilitéForte
LicenceOpenSource + 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.

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.

Site officielhttps://cfengine.com/
Communauté
VisibilitéFaible ?
LicenceOpenSource 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é ?
Site officielhttps://saltstack.com/
CommunautéMoyenne
VisibilitéFaible
LicenceOpenSource + 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éAnsibleChefCfEnginePuppetSaltStack
consommation ressourcesleger moyen/léger sans serviceléger
décrire un module ComplexeMoyenlangage puppet simplesimple via langage yaml
choix du langage module non nonoui
scripter dans une definition de module limitéoui
conf client stockée sur serveur via puppetDBnatif (grains)
possibilité de surchargée un module via hieranatif (pillar)
Langage du moteurPython Java/RubyPython
Langage template par defautJinja/Python ERB/RubyJinja/Python
choix du langage template nonoui
Moteur externe (ENC)Dynamic inventory possibleoui (ENC)oui (Renderer Pipes)
Pilotage depuis le masteroui uniquement (pas de client) non (ou avec func par ex)oui


  • veilletechno/confdeploy.txt
  • Dernière modification : 2017/03/13 15:32
  • de madko