Rationalisation des outils de developpement

J'ignore si c'est viable, mais si on installait tout sur une légère distrib' Linux et qu'on en distribuait l'image, pour pouvoir l'installer en virtuel ? En attendant d'avoir quelque chose de plus solide.

Il parait que c'est trop complexe.

Trop lourd à distribuer, pas trop complexe.

Trop lourd à distribuer, pas trop complexe.

Et en mode docker ? L'installation peut être un poil longue, mais c'est ultra reproductible, et très léger (200-300 lignes de texte).

Et il y aurait moyen d'avoir des images avec des dépendances sympa:

1
2
3
4
5

<distrib> -> base(python+django+nginx)
                           \_ front (+ node.js et autres)
                                 \_ front-build (+ node.js et autres)
                           \_ back  
                           \_ pre-prod (+ MySQL, tutos, *grosses* fixtures, ...)

Du coup, un dev front fait docker build zds:front, un dev back docker build zds:back et pour minifier les fichiers et récupérer les dernières versions des sprites docker build zds:front-build.

Cette image est peut-être un poil simpliste, mais ça pourrait être réalisé (avec au besoin un conteneur qui se charge de partager les fichiers CSS/JS/images d'une instance à l'autre).

Disclaimer : Je ne suis pas du tout spécialiste Docker, j'ai juste un peu joué avec.

L'éventualité de docker a déjà été évoqué, mais apparemment il poserai quelques petits problèmes (cf. https://github.com/zestedesavoir/zds-site/issues/1350#issuecomment-51984139 )

Justement, je ne voit pas dans l'issue de problème particulier. La VM pour OsX/Windows est légère (129M), le temps d'installation est équivalent à celui d'une installation fraiche, ça permettrai peut-être de l'utiliser aussi pour la prod (soyons fous !), …

Le seul problème avec Docker, c'est que dans l'implémentation sur Windows et OS X (c-à-d boot2docker), c'est assez chiant à setup correctement pour un environnement de dev, puisque le seul moyen de modifier le code directement dans la VM, sans avoir à rebuild le container, et à le relancer, c'est en créant un serveur SMB ou un truc dans le genre dans le container, et de s'y connecter… Par contre, sur Linux, on peux directement monter un dossier local dans le container (et donc modifier le code à la volée)

EDIT: Depuis la version 1.3 de docker (qui date d'il y a 2 semaines), il est possible de monter un volume sous OS X. Pas de nouvelles du côté de Windows, mais c'est déjà ça! Source

Le seul problème avec Docker, c'est que dans l'implémentation sur Windows et OS X (c-à-d boot2docker), c'est assez chiant à setup correctement pour un environnement de dev, puisque le seul moyen de modifier le code directement dans la VM, sans avoir à rebuild le container, et à le relancer, c'est en créant un serveur SMB ou un truc dans le genre dans le container, et de s'y connecter…

Alors c'est récent, mais ce n'est plus le cas sous mac depuis la dernière version : https://blog.docker.com/2014/10/docker-1-3-signed-images-process-injection-security-options-mac-shared-directories/

EDIT : Edit trop rapide Sandhose !

Pour Windows, d'après la discussion de la PR qui apporte la fonctionnalité sous Mac, le même fonctionnement semblerai possible. Quelqu'un sous windows peut-il confirmer ?

Sinon, j'ai trouvé ça : http://superuser.com/questions/803234/boot2docker-mount-windows-share. Mais semble en effet moins pratique.

C'est ce que je viens de voir, d'où l'edit de mon message y'a 5 min

Du coup, je vais ressayer de faire une image correcte d'ici le prochain Zest'Meeting

Il faut être conscient que beaucoup des dev de zds utilisent windows. Je ne suis pas surs qu'on puisse se permettre une techno chiante a utiliser pour eux.

Le fait d'utiliser Docker est juste un moyen de plus, ça ne remplacera pas ce qui existe déjà. L'idée, c'est que couplé avec fig, les seules étapes d'install soient:

• Installation de Docker, qui est hyper-simple
• Installation de fig (se résume à une commande à copy-paste dans le terminal, que ce soit sur Mac ou sur Linux, ou alors il peut être installé via pip)
• Clone du répo
• fig up

La on est un peu dans le rêve de certains, de l'install en une commande… En plus, si on a des fixtures correctes, on peut se débrouiller pour avoir une install clean à chaque fois. Autrement dit, c'est vraiment l'idéal pour la QA… En prime, si les schémas de la BDD ont changés, les dépendances pip, ou quoi que ce soit d'autres, il va rebuild ce qui a changé (et pas tous le container), sans avoir à lancer de commande spécifique

Chez moi, lors de mes premiers tests, l'install complète prenait grosso-modo 15 min, sachant que c'est vraiment le premier build qui prend du temps.

Je veux bien que pour le coup, ça marche pas complètement sur Windows (encore que, pour de la QA, vu qu'il y a pas de code à modifier, ça peut marcher), mais je trouve que ça vaut quand même le coup de mettre ça en place

Je suis bien conscient que Docker est un outil sympa, mais quand je parlais de rationaliser les outils, c'était surtout pour rationaliser pour tout le monde. Aussi il faudrait que l'installation soit à la fois simple et efficace sur tous les OS, sans demander trop de mémoire en RAM non plus.

Si on veut garder un logique d'ouverture, on doit considérer tout les cas (ou encore le plus que possible), si pour installer ZdS chez soit il faut demander une configuration de PC d'un jeu vidéo, je considère qu'on a juste déplacer le problème ailleurs.

Aussi, je n'ai pas encore trouvé de solution aussi efficace que celle d'un script bash et un autre script powershell nommé setup.sh qui install une instance de ZdS. Aussi la spec d'un script du genre serait là suivante.

Et encore mieux, si on a un script de setup pareil, qui centralise l'install on peut le lancer dans notre Docker pour ceux qui vont l'utiliser, et ainsi on a besoin de maintenir qu'un seul script qui sera utilisé par tout le monde pour l'installation.

Voila comment je vois les choses, et je ne pense pas que ce soit très difficile à réaliser.

A coté de ça, il y'a aussi tout le process de Continuous Delivery qu'on pourra mettre en place par la suite assez facilement. C'est à dire rajouter la ligne qui va bien dans notre outils d'intégration Continue (je crois qu'ici ça sera le moment du divorce d'avec Travis) pour lancer un build de container Docker par commit et par PR sur le dépôt.

C'est donc ici qu'il faudra aménager un processus de Continious Deployment un peu personnalisé pour poser nos Docker sur un serveur (preprod ou autre) afin d'avoir automatiquement l'instance de ZdS correspondant à chaque PR en ligne. Si on arrive à ça, tout le monde pourra faire de la QA sans avoir à installé quoique ce soit.

En gros, dans les étapes de Continious Delivery il nous manque encore l'approvisionnement (moitié opérationnel) et le déploiement. Si on arrive à avoir un Workflow pareil, ça ne pourra qu'améliorer notre chaîne de travail.

Si on veut garder un logique d'ouverture, on doit considérer tout les cas (ou encore le plus que possible), si pour installer ZdS chez soit il faut demander une configuration de PC d'un jeu vidéo, je considère qu'on a juste déplacer le problème ailleurs.

On a un indicateur sérieux de la puissance demandée par ZdS pour développer, avec et sans Docker ?

Moi je serais déjà curieux de savoir les OS utilisés par les dev et les proportions sur chaque.

Quelques uns le savent, je suis pour l'utilisation de Docker mais il n'était pas encore possible de monter un volume sur son système de fichier sur OS X (et Windows accessoirement, OS X m'intéresse plus puisque c'est mon système). Chose maintenant possible avec la nouvelle version de Docker. Je suis donc encore plus convaincu.

Si on veut garder un logique d'ouverture, on doit considérer tout les cas (ou encore le plus que possible), si pour installer ZdS chez soit il faut demander une configuration de PC d'un jeu vidéo, je considère qu'on a juste déplacer le problème ailleurs.

Je ne sais pas d'où vient cette idée depuis un moment mais docker demande très peu de ressources. Nous sommes tellement loin d'une configuration de PC d'un jeu vidéo.

Par contre, je suis pour un script bash pour l'installation de ZdS. Il y a quelques jours, j'avais fais un script de la sorte (moins complexe) pour une installation sur un système OS X.

J'ai fais le différentiel, mais on n'est pas non plus sur un truc énorme et on peut limiter l'utilisation en mémoire, mais rien que par le fait le truc n'est pas pratique sur tous les OS et que ça consomme un peu, je préfère qu'on priorise un simple script bash, plutot que de se lancer sur une solution qui ne marche que pour une partie. Après si quelqu'un propose un container convenable, pourquoi pas, ça ne serait pas l'idéal, mais ça peut toujours servir.

On ne peut pas uniquement se baser sur les proportions de dev actuels selon moi, car du coup on ferme la porte à de potentiels nouveaux arrivants.

Je vais faire mon chieur de service mais :

J'ai fais le différentiel, mais on n'est pas non plus sur un truc énorme et on peut limiter l'utilisation en mémoire, mais rien que par le fait le truc n'est pas pratique sur tous les OS et que ça consomme un peu, je préfère qu'on priorise un simple script bash, plutot que de se lancer sur une solution qui ne marche que pour une partie.

1. "J'ai fait le différentiel" sans donner le chiffre, ça ne sert à rien.
2. Si tu as des vrais arguments pour/contre une technologie (ici le fait que ça marche mal sous Windows au moins), essaie de te limiter à ceux-ci et de ne pas partir dans des faux arguments ("il faut une config de jeu").

Le débat est assez bordélique et compliqué comme ça, merci d'essayer de le garder propre.

PS : 100% d'accord pour dire qu'une solution standard doit fonctionner sous Windows.

OMG … En fait je voulais écrire "je n'ai pas fait le différentiel" … M'y bad

BTW, l'absence d'utilisation simple de Docker sous windows a pour conséquence qu'il ne peut pas être la méthode de base a présenter. Cela ne nous empeche pas de le proposer mais l'installation standard de référence ne peut se baser dessus. Donc sa conso mémoire est assez secondaire je pense…

PS: Je n'utilise pas windows mais je sais que certains dev oui. Donc faut faire avec.

Niveau consommation de mémoire, constatez par vous-même:

Alors j'ai pas testé à charge, mais je doute que l'impact de docker niveau mémoire dépasse les 50 Mo…

Je vous invite tout de même à tester de votre côté, avec le Dockerfile ci-dessous

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

FROM dockerfile/nodejs
 
WORKDIR /home/zeste-de-savoir
 
# Set locale
RUN locale-gen fr_FR.UTF-8
ENV LANG fr_FR.UTF-8
ENV LANGUAGE fr_FR:fr
ENV LC_ALL fr_FR.UTF-8
 
# Install APT packages
RUN apt-get update -y
RUN apt-get install -y libxml2-dev
RUN apt-get install -y python-lxml
RUN apt-get install -y libxslt1-dev
RUN apt-get install -y libz-dev
RUN apt-get install -y python-sqlparse
RUN apt-get install -y libjpeg8-dev
RUN apt-get install -y libfreetype6
RUN apt-get install -y libfreetype6-dev
 
# Node things
RUN npm install -g gulp
RUN npm install -g bower
 
ADD package.json /home/zeste-de-savoir/package.json
RUN npm install
 
ADD .bowerrc /home/zeste-de-savoir/.bowerrc
ADD bower.json /home/zeste-de-savoir/bower.json
RUN bower install --config.interractive=false --allow-root
 
# Python things
ADD requirements.txt /home/zeste-de-savoir/requirements.txt
RUN pip install --upgrade -r requirements.txt
 
ADD . /home/zeste-de-savoir
RUN python manage.py syncdb --noinput
RUN python manage.py migrate --noinput
RUN gulp build
 
EXPOSE 8000
CMD ["/usr/bin/python", "manage.py", "runserver", "0.0.0.0:8000"]

La procédure est la suivante:

• Installez Docker
• Copiez le contenu du Dockerfile ci-dessus dans un fichier "Dockerfile" à la racine du projet
• [sudo] docker build -t zds .
• [sudo] docker run -p 8000:8000 zds

Chez moi, 5min 56 pour build le tout, sans utiliser le cache

Bon, pour information ici. Après de nombreux tests, je pense enfin avoir trouvé la la lib python qui peut jouer le rôle du point 3. Il s'agit de PyScss

Avec un peu de chance, y'a moyen qu'on garde la stack Nodejs (et tout ce qu'elle apporte) à coté. Mais au moins on pourra aussi faire du front sans installer Nodejs (et donc déployer de manière propre et native django en prod).