Processus de création d'une VM faisant partie d'un parc géré par Salt Stack

Tags
  • cloud-computing
  • favourites
  • best-practices
  • logiciel-libre
  • salt-stack
Une salière a coté d’un déversement de sel, avec le mot sel écrit en anglais.

A mon emploi actuel je gère un parc de machines virtuelles (VMs) qui est automatisé par un système de gestion de configuration appelé Salt Stack.

Salt stack est un outil permettant de décrire quel est l’état désiré d’un serveur. Comme d’autres outils avec une utilité similaire, Salt Stack peut être utilisé dans des environnements hétérogènes sous GNU/Linux, Mac OS, et Windows, FreeBSD, etc.

L’environment que nous utilisons est un serveur avec des «blades». Chaque «blade» fournit les services créant un cluster OpenStack. Dans le futur, nous risquons d'avoir plus d'un fournisseur OpenStack. Pour automatiser comme nous l'aimons, nous utilisons grandement la ligne de commande avec le paquet python-novaclient.

Chaque machine virtuelle roule une version LTS («Long Term Support») de Ubuntu.

Absolument toutes les configurations sont appliqués via Salt Stack, la seule chose qui est fait manuellement en ce moment est de créer la nouvelle instance, et de l'ajouter au «master» de Salt Stack.

Même là, ça risque de changer lorsque nous aurons déployé Salt Cloud.

Procédure

Mise à jour Mars 2015: Un nouvel article sur le même sujet a été écrit (en anglais) et illustre comment faire une nouvelle VM avec encore moins d’étapes

  1. Boot une nouvelle node avec Nova

    joe@master:~$ nova boot --image lucid-minion-template --flavor wpdn.large --key-name renoirb app6
    
  2. Donner un nom en fonction du type de serveur a déployer avec un numéro à la fin. Exemple: app6

    NOTE Dans mon cas, j'ai notamment: app, db, memcached, etc.

  3. Ajoute l'adresse floating dans /srv/pillar/nodes/init.sls comme les autres

    nodes:
      master:
        public:  ####IP PUBLIQUE CACHÉE####
        private: 10.0.0.1
    
      app1:
        public:  ####IP PUBLIQUE CACHÉE####
        private: 10.0.0.7
    
      memcache2:
        public:  ####IP PUBLIQUE CACHÉE####
        private: 10.0.0.4
    
      app5:
        public:  ####IP PUBLIQUE CACHÉE####
        private: 10.0.0.3
    
  4. Prend le fichier /home/ubuntu/runme de n'importe quel autre serveur et colle le dans la nouvelle machine. Puis execute (sudo /bin/bash runme)

  5. Ajouter une ligne dans le nouveau serveir dans /etc/salt/minion.d/master.conf

    id: app6
    

    ... Voir les autres nodes

  6. Restart salt-minion

    ubuntu@node6:~$ sudo service salt-minion restart
    
  7. Ajoute la clée au master

    joe@master:~$ sudo salt-key -a app6
    

    ... Le '-a foo' est optionnel et tu peux lister Les nodes.

  8. Run state.highstate

    joe@master:~$ sudo salt app6 state.highstate
    
  9. Uploader le code via rsync dans la nouvelle app node, puis re-rouler state.highstate (certains scripts prennent pour aquis que le code est déjà déployé)

    joe@master:~$ sudo salt app6 state.sls code.node_app
    joe@master:~$ sudo salt app6 state.highstate
    

    Comme je disais, parfois, le premier state.highstate ne marche pas a cause du code pas déployé.

  10. Rafraichir les autorisations pour storage

    joe@master:~$ sudo salt 'storage*' state.highstate
    joe@master:~$ sudo salt 'monitor*' state.highstate
    
  11. Updater le hosts file de quelque nodes

    joe@master:~$ sudo salt 'app*' state.sls hosts
    joe@master:~$ sudo salt 'db*' state.sls hosts
    joe@master:~$ sudo salt 'memcache*' state.sls hosts