Être Agile avec SaltStack

David Douard (Logilab)

Qui

David Douard

  • Enthousiaste du FOSS
  • Utilisateur GNU/Linux (depuis le millénaire précédant)
  • Développeur Python (commencé avec Python 1.5.2)
  • Administrateur Système
  • Travaille à Logilab (depuis 2006)

Pourquoi

  • Gère de plus en plus de machines (virtuelles) et services à Logilab
  • Essayé (sans adopter) Puppet et Chef
  • Découverte de SaltStack il y a 2 ans
  • j'ai immédiatement accroché, et du coup
  • je veux faire connaître SaltStack
  • tip: je suis avant tout un développeur

Une distribution c'est

  • Ensemble cohérent de logiciels
  • Gestionnaire de paquets
  • Installeur
  • Des outils pour gérer :
    • les utilisateurs
    • les droits
    • les ressources matérielles
    • ...
  • sur une machine

Infrastructure

  • Constituée de beaucoup de machines...
  • ...qui doivent collaborer pour proposer des services

  • Il n'y a pas de distribution à l'échelle de l'infrastructure aussi avons-nous besoin :

    • d'une vue d'ensemble aussi juste que possible
    • d'outils de commandes à distance efficace
    • d'un système d'orchestration puissant

Situation

  • Systèmes informatiques de plus en plus nombreux et de plus en plus complexes
  • De moins en moins de situation simple telle que le serveur X tourne sur la machine physique M
  • Documentation (au mieux) périmée
  • Informations dupliquées :
    • inventaire
    • monitoring
    • configuration centralisée
    • documentation

Salt c'est

  • Un framework d'exécution à distance
  • Un gestionnaire de configuration centralisé
  • Un outil de Cloud Provisionning
  • Un gestionnaire de machines virtuelles
  • Une boîte à outils (toolkit) !
  • Totalement modulaire

Framework d'exécution à distance

  • entre un Master et des Minions
  • les communications utilisent ZMQ
    • PUB/SUB (master -> minions)
    • REQ/REP (minion -> master)
  • les communications sont chiffrées (AES256)

Exécution distante

root@master:~$ salt <target> <command> <options>
  • target: ID du minion, glob patterns, PCRE, liste, sélection basée sur des valeurs de grains ou des pillars, ...

  • command:
    • une des nombreuses commandes salt (plus de 80 modules définissant 400 commandes)
    • très facile d'écrire et déployer ses propres modules
    • toute commande shell via la commande cmd.run
  • options: arguments ; spécifique à chaque commande

Exemples


root@salt:~# salt -G "oscodename:wheezy" pkg.version openssl
cn1.openstack.mycompany.com:
    1.0.1e-2+deb7u9
cn2.openstack.mycompany.com:
    1.0.1e-2+deb7u9
postgres.openstack.mycompany.com:
    1.0.1e-2+deb7u3 # ndlc: ouch!
cn3.openstack.mycompany.com:
    1.0.1e-2+deb7u6
root@master:~# salt \* pkg.install openssl refresh=True
[...]
root@master:~# salt \* service.restart nginx
[...]
root@master:~# salt \* cmd.run "lsof -n | grep libssl | grep DEL"
[...] # should restart any process listed here

Gestion de configuration

  • Déclarations dans des fichiers de state
  • it's just data
    • pas de DSL
    • YAML par défaut
    • Autres formats disponibles
  • Moteur de template (jinja2 par défaut)
  • Basé sur des state classes
    • bibliothèque riche,
    • très facile d'en ajouter.
  • Le master est aussi un serveur de fichiers

Fichier de state


/etc/apt/apt.conf:  # <-- ID du state
  file:             # <-- state module à appliquer
    - managed       # <-- fonction du state module à appliquer
    - source:  salt://apt/apt.conf # <-- argument de la fonction
    - template: jinja              # <-- argument de la fonction

logilab-public-acceptance: # <-- ID du state
  pkgrepo.managed:  # <-- statemodule.fonction en une seule ligne
    - name: deb http://download.logilab.org/acceptance {{grains['oscodename']}}/
    - require:      # <-- déclaration de dépendences
      - file: /etc/apt/apt.conf
      - file: /etc/apt/trusted.gpg.d/logilab.gpg

Répertoire des fichiers de states

  • fichier racine : top.sls
  • organisation par package/module (un peu comme Python):
    • package : répertoire contenant un fichier init.sls

root@master:~# tree /srv/salt/state
.
├── apt-cacher
│   └── client.sls
├── cubicweb
│   ├── init.sls
│   ├── postgresql.sls
│   └── instance.sls
├── basicconf.sls
└── top.sls

Fichier top.sls

  • Déclarer quels states doivent être appliqués à chaque minion
base:
  '*':
    - basicconfig
    - apt-cacher.client
  'db.*':
    - cubicweb.postgres
  'app.*':
    - cubicweb.instance

Appliquer les states

  • Tester l'application de tous les states sur un minion et les appliquer effectivement

root@master:~# salt cn1.mycompany.com state.highstate test=True
root@master:~# salt cn1.mycompany.com state.highstate

Salt cloud

  • salt permet de piloter des instances hébergées sur des plateformes type cloud

  • supporte la majorité des fournisseurs

  • supporte aussi les installations privées (OpenStack)

  • permet aussi de gérer des conteneurs LXC

Fournisseurs de cloud

  • les providers sont décrits sur le master dans /etc/salt/cloud.providers.d/*.conf

logilab:
  provider: openstack
  identity_url: http://control.openstack.logilab.fr:5000/v2.0/tokens
  user: login
  password: password
  compute_region: RegionOne
  tenant: adminproject

Profiles

  • Définition des "machines" type (combinaison du provider, de l'image du système et du type de machine)
debian_wheezy_tiny:
   provider: logilab
   image: debian-wheezy-x86_64
   size: m1.tiny
centos_tiny:
   provider: amazon
   image: centos-x86_64
   size: m1.tiny

Map

  • Permet d'appliquer un profil de machine à des instances
debian_wheezy_tiny:
  - web1
  - db1
centos_tiny:
  - web2
  - db2

Déploiement

root@master:~# salt-cloud -m /path/to/map
  • Créé des instances chez les fournisseurs respectifs
  • Bootstrap salt-minion
  • Déploie les clefs générées
  • Applique le highstate

LXC

  • Salt supporte la gestion des conteneurs LXC
  • Il est alors possible d'orchestrer ses conteneurs LXC

root@master:~# salt-run lxc.init <name> host=<host> ...
root@master:~# salt-run lxc.start <name>
root@master:~# salt-run lxc.freeze <name>
root@master:~# salt-run lxc.unfreeze <name>
root@master:~# salt-run lxc.list [host=<host>]

Interlude

Be Lean & Agile

  • Détecter et éliminer le gâchis
  • Avoir des métriques
  • Empower the users
  • Développer l'intégrité conceptuelle (conceptual integrity)
  • Au niveau de l'infrastructure

Adapter les principes

  • adapter les "bonnes pratiques" du développement agile à la gestion d'infrastructure et à l'administration système
  • en utilisant SaltStack comme outil central
  • nous voyons aujourd'hui SaltStack comme une boîte à outils agile pour le devops au même titre qu'on avait identifié Python comme un "langage agile" il y a près de 15 ans

Adapter

TDD pour le système

  • Le TDD est l'un des outils les plus puissant des méthodes agiles
    • Outil clef pour mettre garantir l'intégrité conceptuelle d'un projet lors de sa mise en œuvre
    • Essentiel pour permettre le remaniement et l'amélioration continue
    • Le meilleur moyen d'écrire des spécifications techniques
  • Comment l'adapter à l'administration système ?

Tester l'infrastructure ?

  • Des outils existent déjà et sont largement utilisés : monitoring et supervision
  • Il est aussi possible d'utiliser SaltStack pour construire un framework de test, en s'inspirant de :

TDD avec SaltStack

  • Il est vital d'avoir une arborescence de fichers SaltStack bien organisée

    • comprendre et appliquer les bonnes pratiques
    • utiliser et écrire des modules de state fonctionnels sous forme de formulas
    • s'assurer que la description de haut niveau des services et applications réside dans les données de pillars
  • Il suffit alors d'implémenter la logique de tests dans les states ou les formulas (configuration automatique des sondes munin et nagios par exemple)

Exemple

  • Pour une application Cubicweb à déployer derrière un serveur mandataire inverse (par exemple Apache), son pillar pourrait ressembler à :
vhosts:
  -
    servername: www.brainomics.net
    publicip: 1.2.3.4
    cwapp:
      -
        name: brainomics
        basepath: /demo
        dbname: brainomics
        dbuser: brainuser

Exemple (#2)

  • Pour lequel on aurait alors des states qui "mettent en œuvre" cette configuration, à savoir :

    • ajouter des configurations pour shinken :
      • vérification de l'état du frontend apache
      • vérification de l'état l'instance Cubicweb brainomics
      • vérification que les temps de réponse pour un certain nombre de vues standard de Cubicweb restent en dessous d'une limite fixée
      • vérification du bon fonctionnement de la base Postgresql
      • etc.
    • configure les sondes munin idoines
    • installe et configure les logiciels (apache, cubicweb, etc)

Test-Driven Administration

  • Le point important de cette discussion est le driven

  • À chaque fois qu'on met en place un nouveau service,

    • il faut se poser les questions de comment le tester
    • identifier les métriques pertinentes
    • les mettre en place dans les states qui appliquent la description du service
    • puis seulement ajouter la partie effective des states
  • SaltStack vient d'emblée avec des outils pour garantir que l'état du système correspond à sa description (son highstate)

Documentation

Une bonne documentation est une doc rédigée, mais :

  • Rédiger (et maintenir) une documentation est un travail énorme
  • Une documentation périmée est (au mieux) du gâchis

Une solution simple

Utiliser Sphinx avec des directives ad hoc, par exemple :


Test Salt
=========

Here are the reachable machines:

.. saltcmd:: * test.ping

La solution idéale (?)

  • Facilité d'édition en ligne (type wiki)
    • qui utilise un langage de balises simple (rest ou markdown)
    • avec la possibilité de rédiger dans son environnement favoris
    • avec la possibilité de cloner l'entrepôt des sources de la documentation
  • Possibilité d'utiliser la salt-api pour générer des parties du contenu
    • à l'aide de directives spécifiques
  • Avec intégration de données de visualisation temps-réel des outils de monitoring
    • à l'aide de directives spécifiques
    • en utilisant directement des requêtes AJAX (CORS)

Questions ?