Ê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

Je ne vais pas

  • Présenter SaltStack en détails
  • Montrer des démos ou du code
    • l'essentiel de la présentation est des idées qu'on essaye d'assembler
    • pas de "Fork me on github"

Salt c'est

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

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

Interlude

Be Lean & Agile

  • Détecter et éliminer le gâchis
  • Avoir des métriques
  • Empower the users
  • Garantir 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 développer un système avec une intégrité conceptuelle
    • 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
        backend: "cw1.logilab.fr" # might better be "chosen" by salt
        port: 9090 # might better be "chosen" by salt then uploaded to the mine
        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 "utile" des states
  • SaltStack vient d'emblée avec des outils pour garantir que l'état du système correspond à sa description (son highsttate)

Documentation

Une bonne documentation est une documentation rédigée (on utilise beaucoup Sphinx), mais :

  • Rédiger et maintenir à jour une documentation est un travail énorme
  • Une documentation périmée est (au mieux) du gâchis
  • Mais une bonne (utile) documentation ne peut être complètement générée

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)

Empower the users

  • Les utilisateurs (devops) doivent
    • avoir accès aux métriques de l'infrastructure
    • avoir accès à un certain nombre de leviers de contrôle de l'infrastructure et des applications qu'ils développent
    • sans pour autant devoir être root partout
    • sans que cela soit au détriment du travail des administrateurs
    • pouvoir reproduire facilement un environnement applicatif

Empower avec Saltstack

  • Utiliser les possibilités de gestion des droits de SaltStack (ACLs),
  • Utiliser salt-api (et les ACLs)
  • Déployer 2 environnements SaltStack en parallèle :
    • un pour les administrateurs système (avec accès root)
    • un pour les développeurs (non-root)

Offrir la puissance de Saltstack

  • Avec cette dernière solution, on peut envisager de :

    • apprendre aux développeurs à utiliser vraiment SaltStack :
      • les commandes à distance,
      • son système d'événements,
      • les reactor et scheduler,
      • les returners pour se constuire ses propres métriques,
      • etc.
    • apprendre aux utilisateurs la facilité d'écrire et déployer des modules et states SaltStack

Questions ?