Une amélioration de la gestion de configuration ?

J'aurai pu poster ce topic dans la rubrique projet, mais étant donné qu'il ne concerne que ZdS, je le poste ici.

Comme vous le savez (ou pas), le site zestedesavoir.com possède une version de production et une version de préproduction, tous les deux hébergées sur des vps différents. Lorsqu'une release du projet est prête, on la déploie en préprod, puis ensuite en prod, à l'aide d'un script bash qui exécute un ensemble de commande séquentielles sur le serveur.

Qu'est ce qu'on a comme problème ?

• Personne n'est capable de dire si la préprod est iso-prod en tout points (logiciels installés, etc.)
• Si demain on change de serveur, il nous faudrait au moins 3 jours pour configurer notre nouveau serveur à partir d'une machine vierge (avec des risques de souci de configuration).
• Si on décide de passer sur une autre distribution Linux (CentOS par exemple), il y'a moyen de s'arracher les cheveux.
• Si quelqu'un désire forker ZdS, il y'a de grande chances qu'il abandonne au moment de l'installation de son serveur de production (d'une part parce que ce n'est pas documenté, d'autre part parce que c'est complexe).

Une solution parmi d'autres : Puppet

Puppet qu'est ce que c'est ?

Puppet est un outil de Configuration Management qui permet en gros de déployer une application web sur un serveur vierge (si vous ne l'avez pas lu, j'en parle dans un de mes article ). Il fonctionne dans une logique de master/agent, ou on a un serveur (le master) qui contrôle le déploiement d'un ou plusieurs serveurs agents. Il a la particularité (en théorie) d'être agnostique sur la plateforme (debian, CentOS, Ubuntu, Windows, etc.), mais en pratique la plupart des modules Puppet ne tournent que sur des distributions Linux (facilité toussa).

Puppet est Opensource. Une grosse communauté existe autour de Puppet, ce qui permet d'avoir des modules pour à peu près tout et n'importe quoi maintenus par la communauté.

Pourquoi j'en parle ici ?

Parce que j'ai développé un module Puppet pour zds qui pour l'instant permet de déployer en partant d'une machine vierge, le projet ZdS. Le module prend en input un fichier de configuration qui ressemble à celui-ci s'occupe de l'installation et de la configuration de :

• paquets systèmes (python compris)
• moteur wsgi (gunicorn) et supervisor
• moteur Solr
• pandoc (avec LateX et cie)
• la partie front-end (npm, node), avec prise en compte des settings
• le SGBD cible (mysql)
• le serveur web (nginx)

Le module déploie ainsi la branche/tag X du repository Y sur le machine Z.

Le module est disponible sur la puppet forge et s'installe comme n'importe quel module puppet puppet module install firm1-zds sur le serveur master. Il ne reste plus qu'a piloter vos agents depuis votre master.

Le code source du module est Opensource et disponible sur Github.

Une démonstration est disponible à cette adresse (ne faites pas attention aux couleurs c'est pour tester le coté customisable de zds).

Et maintenant ?

Le module n'est néanmoins pas complet (il reste à faire la configuration d'un serveur mail), mais j'aimerai d'abord savoir si c'est le genre de chose qui intéresserait les déployeurs de ZdS (les forkeurs y compris). Si oui, je pourrais le finaliser, sinon et bah c'est pas grave, car configurer un serveur pour Django est tellement synonyme de prise de tête que je pense que ça ferait du bien à la communauté Puppet d'avoir un module pour.

Ça ne peut être que positif et c'est un premier pas vers une semi automatisation du déploiement des branche en ligne pour faire la qa. Donc vas y continue.

Alors :

Personne n'est capable de dire si la préprod est iso-prod en tout points (logiciels installés, etc.)

C'est faux : aujourd'hui, on est certains que la préprod n'est pas iso-prod. Mais on est aussi certains d'un certain nombre d'inutilités sur les 2 serveurs.

Si demain on change de serveur, il nous faudrait au moins 3 jours pour configurer notre nouveau serveur à partir d'une machine vierge (avec des risques de souci de configuration).

Il faut bien moins de 3 jours – mais je suis d'accord pour dire que le processus est fastidieux.

car configurer un serveur pour Django est tellement synonyme de prise de tête que je pense que ça ferait du bien à la communauté Puppet d'avoir un module pour.

Sérieux ? Personnellement j'ai trouvé ça plutôt simple sur ceux que j'ai mis en place pour mes projets persos. Bien moins chiants et bien mieux documenté que beaucoup d'autres trucs, par exemple en Java.

Par contre, ZdS vient avec sa batterie d'outils tiers qui rend l'ensemble complexe.

Cela dit, l'idée est intéressante. Par contre, la prochaine réinstallation sera sans doute à faire au moment du passage à Python 3, et ça va sans doute apporter des différences par rapport à ce que tu as déjà fait – qui ne sera donc pas réutilisable.

Je pense notamment à :

• Le script WSGI utilisé aujourd'hui est complètement obsolète. Tu trouveras une version à jour ici (dans la PR Django 1.7 mais normalement c'est utilisable dès aujourd'hui).
• Supervisor n'est qu'un outil qui va dégager pour mieux à la première occasion. Typiquement si le serveur cible a systemd, pour un script systemd.
• Je ne sais pas si tu as intégré les toutes dernières modifications dans la conf nginx, qui sont indispensables pour faire tourner l'API (et encore, ce n'est même pas certain qu'elle soit parfaitement carrée).
• Les paquets python devront installer Python 3.
• Si on en profite pour passer à Debian 8, ce sera du MariaDB et plus du MySQL (ça change rien sauf le nom du package à installer).

De mon point de vue, ton script Puppet (on parle de script ?) est une excellente idée, mais pas sur cette version qui est vouée à disparaître à court terme. Mais je suis 100% pour intégrer ça sur la v2.0 du code (celle qui utilisera Python 3 en fait, et qui donc nécessitera un gros boulot d'infra donc probablement une réinstallation depuis 0).

qui ne sera donc pas réutilisable.

C'est bien là tout l’intérêt d'utiliser Puppet et sa batterie de modules gérée par la communauté. Les modules dont je dépend savent gérer les versions des packages et des OS. C'est justement leur intérêt (le module python sur lequel je m'appuie par exemple gère aussi bien python2 que python3).

Typiquement le module actuel peut évoluer au fur et à mesure de l'évolution des dépendances de ZdS. Les changements que tu liste par exemple ne représentent pas grand chose, car les bases sont déjà posées.

C'est cool ce machin !

Est-ce que (reve, reve) c'est le jour de truc qui permettrait d'automatiser une bricole comme "lancer les PR sur un serveur de test pour faire de la QA quand on est pas a la maison" ?

Je dirais même plus, c'est l'objectif que je visais au départ, et je n'en suis pas si loin (faudrait rajouter des webhooks pour que ça déclenche tout seul).

Pour l'instant, je vais tester le module, en déployant une PR une par une. ça permettra de dégrossir le stock des 29 PRs qui trainent.

Pour ceux qui se seraient poser la même question que moi : dans quels circonstances les gens préfèrent docker à puppet et vice-versa

Je reconnais que c'est un domaine qui m'est relativement étranger puisque j'utilise toujours les heroku/openshift et compagnie, donc je connais mieux leur mécanique de "cartouches". Mais c'est très intéressant, et si ça apporte du bon à ZdS c'est tant mieux.

Gratz.

En fait Puppet et Docker ne répondent pas exactement au même besoin. Le vrai outsider de Puppet est surtout Ansible (mais son coté trop de truc payant m'a toujours refroidit)

On est obligé de mettre les fichiers pour puppet sur un autre dépôt ou on pourra l'intégrer à zds-site ?

On ne peut pas l'intégrer à zds-site, car en soit c'est un projet en part entière qui se charge de gérer la partie infra de ZdS.

Et si on peut séparer les blocs logiques, autant le faire.

Bon, depuis la dernière fois les choses on un peu avancée ici. Après quelques tests de mon module puppet sur le dépot de zds, j'ai pu corriger certains bugs et améliorer certaines choses. Je viens donc avec une question pour les amateurs (ou pas) de virtualhosts.

Maintenant, le module est capable de déployer X Pull Request différentes sur une et une seule machine. Chaque PR est accessible via une url du type http://hostname:ID_PR/. Les PRs sont déployés de manière indépendantes (un répertoire dédié, une base mysql dédiée, une instance solr dédiée, un virtualhost dédié, etc.) et mine de rien ça prend de la place. Afin de pouvoir tester les PRs de type documentation, la doc est générée automatiquement et disponible via l'url http://hostname:ID_PR/doc/.

J'ai fais un test sur un VPS avec les PRs 2318 et 2371 on a donc 2 applications séparés. L'une sur http://vps137741.ovh.net:2318/ et l'autre sur http://vps137741.ovh.net:2371/.

Cependant j'ai un souci de configuration nginx on dirait qui fait qu'à chaque fois que l'on soumet dans un formulaire (une requête de type POST), le numéro du port n'est pas conservé dans l'url. Quelqu'un saurait-il d’où ça peut venir ?

Voici la conf nginx d'un virtual host :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

upstream puppet_zds_app_2318 {
       server unix:/tmp/gunicorn-2318.sock    fail_timeout=10s
}
server {
       listen                *:2318;
       server_name           vps137741.ovh.net;
       index  index.html index.htm index.php;
       access_log            /opt/2318/venv/logs/nginx_access.log combined;
       error_log             /opt/2318/venv/logs/nginx_error.log;
       location /doc/ {
       alias /opt/2318/zds-site/doc/build/html/;
       }
       location /static/ {
       alias /opt/2318/zds-site/static/;
       }
       location / {
       proxy_pass            http://puppet_zds_app_2318;
       proxy_read_timeout    90;
       proxy_connect_timeout 90;
       proxy_redirect        off;
       }
}