systemx

Aller au contenu | Aller au menu | Aller à la recherche

mardi, juillet 2 2013

Salt Stack - Automatisation en python


Salt Stack est un logiciel d'automatisation de taches similaire à Puppet.
Puppet est très intéressant mais un peu complexe à mettre en place, Salt a de gros avantages tels que la simplicité et la souplesse.
Par contre cette simplicité a pour pendant une certaine confusion à la première mise en place.
Voici les concepts et la mise en place d'un config pour automatiser les post installation de distro sur un poste multiboot.

  1. State
  2. Salt utilise les "state" qui sont en fait des séquences déclaratives qui seront ensuite appliquées aux machines cibles.
    Par défaut Salt utilise un mode client/server mais peut aussi etre utilisé en stand alone.
    Le mode client/server s'installe de facon similaire à Puppet avec un echange de certificats entre le maitre et le client (appelé minion dans salt).
    Je ne rentre pas dans les détails qui sont documentés maintes fois mais oriente le billet sur la pratique un peu plus avancées.
    En pratique on défini le repertoire source des configuration qui doit contenir un fichier top.sls qui pourra être appelé via le state.highstate :
    • En mode master/minion
    • salt '*' state.highstate
    • En mode standalone
    • salt-call state.highstate

  3. Grains
  4. On peut ensuite interagir avec des variables définies dans le système (à la manière de facter sous puppet) grâce au grains.
    La encore on a beaucoup de souplesse pour créer ses propres grains, je définie une catégorie dans /etc/salt/minion :
    grains: type: work
    Ca me permettra ensuite de faire un profil "boulot" et un profil "home" simplement.
    On peut ensuite questionner ce "grain" :
    salt-call grains.item type
    Ou bien dans le fichier top.sls :
    base:
      'type:work':
        - match: grain
        - work

    Si le grain 'type' est work on va exécuter le state work, il faut donc que il existe un sous répertoire work dans lequel on a un fichier init.sls.
    Ce fichier init.sls sera équivalent au top.sls de la racine pour ce "state".
    On peut ensuite appelé ce state individuellement par :
    salt-call state.sls work

  5. Template/Pillar
  6. Afin d'apporter un peu d'intelligence au langage descriptif salt utilise un systeme de template appelé jinja2. Par exemple on definit un pillar pour les package à installer en fonction des os.
    On définit le pillar dans /etc/salf/minon :
    pillar_roots:
      base:
        - /vagrant/pillar
    Dans ce repertoire on définit un top.sls :
    base:
      '*':
        - pkgnames
    
    Puis dans /vagrant/pillar/pkgnames.sls :
    pkgdef:
      {% if grains['os_family'] == 'RedHat' %}
      apache: httpd
      {% elif grains['os_family'] == 'Debian' %}
      apache: apache2
      {% endif %}
    Ensuite dans le apache.sls (dans les salts /vagrant/salt/work dans mon cas):
    apache:
      pkg.installed:
        - name: {{ pillar['pkgdef']['apache'] }}
    De la même manière on peut tester les configurations pillar :
    salt-call pillar.get pkgdefws:firefox
    On va chercher la valeur firefox dans le groupe pillar pkgdefws (package definition workstation).

  7. Modules
  8. Afin de pouvoir gérer les states salt fournit un grand nombre de modules natifs simple d'accès.

    A noter que le templating est aussi accessible hors des pillar directement dans les states standards.

  9. Autres outils
  10. Accessiblité de la doc :
    La command salt-call sys.doc permet de voir la documentation sur tous les modules.
    On peut voir ensuite un module particulier :
    salt-call sys.doc user
    
    Cela ressemble un peu au fonction pydoc bien pratique.
  11. Masterless
  12. On peut tout utiliser en local en configurant Salt en mode sans maitre.
    Il faut mettre cela dans le /etc/salt/minion :
    file_client: local
    Puis lancer les commandes avec --local :
    solydxk-x64 ~ # salt-call --local user.info root
    local:
        ----------
        fullname:
            root
        gid:
            0
        groups:
            - root
        home:
            /root
    ....
    
    Pour declarer le repertoire source des sls :
    file_roots:
      base:
        - /srv/salt/local
        - /srv/salt/pillar
    
    Il faut mette un top.sls dans local, on peut mettre un toto.sls dans pillar pour faire des fichiers de conf.
    Puis on peut en local :
    salt-call --local state.highstate
    Salt est aussi orienté lancement de commande en ligne vers des groupes prédéfinis, on peut aussi gérer des authentifications externes afin de donner des permissions sur le lancement des différents "states". Voir cette page.

Conclusion :
Salt semble vraiment simple à utiliser et puissant après un minimum d'habitude.
La syntax Yaml est cependant un peu trop succinte et peut preter à confusion, il font donc bien découper ses fichiers selon les fonctions.
Le gros point fort est la simplicité de faire des choses avancées, le grand nombre de modules natifs existants et pour ceux qui aiment sa nature pythonienne.

vendredi, mars 15 2013

Les poupées au quotidien - l'automatisation à la maison

Dans l'administration système de nouveaux outils de depoiement ont fait leur apparition il y a quelques années.
En opensource bien sûr et qui sont très efficaces pour gérer les changements massifs sur les datacenters mais pas seulement.
Indispensable dans le cloud, ils s'avèrent aussi utilises au quotidien car il savent faire abstraction de l'OS.
Le plus célèbre des outils est puppet (qui a recu un investissement de 30M$ de vmware .... quand on parle de cloud ...).
Puppet est à la fois simple et complexe, le but de ce billet n'est pas de rentrer dans le détail mais de décrire une utilisation pratique pour moi qui teste pas mal de choses.

Je cherchais à faire un script qui installait des packages en faisant abstraction du package manager (yum, apt-get ...), c'est en fait rapidement devenu une usine à gas.
Interessé par puppet, j'ai remarqué que cela fonctionne aussi sans serveur central.
Exactement ce qu'il me faut, je fait donc des profils pour installer les packages que j'utilise sur chaque nouvelle distro que je teste.
Si puppet est dispo, il suffit de faire un fichier de profile :
[root@Rosa64 puppet]# cat utils.pp 
package { "ncftp":
  ensure => installed,
}
package { "fsarchiver":
  ensure => installed,
}
puis de lancer :
[root@Rosa64 puppet]# puppet apply utils.pp 
notice: /Stage[main]//Package[ncftp]/ensure: created
notice: /Stage[main]//Package[fsarchiver]/ensure: created
notice: Finished catalog run in 8.04 seconds

Puppet a bien installé mes packages sans que j'ai besoin de connaitre les commandes systemes (dans mon exemple Rosa/Mandriva).
Il ne me reste plus qu'à aller plus loin en faisant des groupement de package, creation de utilisateurs, gestion sudo ....

Evidement puppet peut aller beaucoup plus loin pour gérer différents type de profil, version de package, versionning de fichier de conf, template de deployement.
Ca se complique alors sérieusement, pour aller plus loin :
Une bonne intro en francais.
Plein de truc aussi en francais qui sentent le vécu.

Il peut s'associer avec des outils tels que foreman (industrialisation complete du cycle de vie des serveurs), vagrant (creation d'usine de virtualbox), capistrano (deploiement) et aussi l'inévitable git pour le versioning.
A noter que la plupart de ces outils tournent en Ruby, le language encore plus hype que python.