Puisque ca bouillonne dans la dev-zone sur ze sujet, partageons un peu nos techniques de déploiements d'applications !
OK, je poursuis donc la discussion.
Originellement adepte du "presque-tout-automatisé" jusqu'au déploiement en prod qui se faisait manuellement :
1 2 3 4 | ssh monServeur ./stopMaPileApplicative.sh ./scriptDeDeploiement.sh ./startMaPileApplicative.sh |
(grosso modo)
Je suis passé un peu plus récemment à une mécanique complètement automatisée.
En gros :
Du coup : l'outil d'intégration continue joue le rôle de chef d'orchestre, il fait ses git pull, appelle les scripts de déploiement (potentiellement avec des variables d'environnement, une config particulière suivant le contexte : prod / préprod) et en sortie, il a une archive déployable. Jusque là rien de nouveau sous le soleil.
Par contre, là où ça devient pénible c'est la migration de données, etc. et passer à la main d'éventuels scripts en serrant les fesses.
Le truc qui a résolu ce soucis dans mon cas c'est Docker. Le résultat du build n'est plus un ensemble de "trucs" (archives compressées + scripts) mais une image complète du système, prête à déployer. Du coup, c'est à l'outil d'intégration continue de construire l'ensemble de l'image Docker, qui elle contiendra les scripts de migration pour la BDD etc. Et eventuellement des ajustements niveau système etc.
Du coup que je déploie en pré-production ou en production, il n'y a pas de différence sensible, dans les deux cas j'ai une image docker que je vais déployer sur une machine. Soit sur une machine AWs, soit sur ma machine locale, soit sur une machine dédiée etc. Même OS, même config (sauf ce que j'ai décidé qui était différent), …
Au niveau du processus de MeP c'est trivial et n'importe qui avec les droits suffisants peut le faire sans trembler : il suffit de cliquer sur un bouton.
Si ça se passe mal, on rollback sur l'ancienne image "tant pis, on verra demain".
Ca permet vraiment d'avoir un processus d'intégration continue très "iso" et limiter les mauvaises surprises.
Chez moi ça se passe comme ça :
Edit : y a des scripts qui font le boulot en automatique à chaque étape. sauf pour le détarrage de la virtualEnv et son installation parce qu'on aime bien vérifier qu'on installe bien les bonnes choses quand même…
Alors c'est pas MA technique mais c'est UNE technique que j'ai eu le plaisir d'utiliser dans le royaume du mal…heu je veux dire en SSII:
Pour deployer leur grosse appli, les mecs avaient une equipe dediee exclusivement au deploiement et moi (ou toute autre personne de mon equipe) tout ce qu'on devait faire c'etait indique le nom du tag (sur l'outil de version control) que l'on voulait installer et remplir quelque formulaire generes automatiquement avec les variables propres a la cible sur laquelle on deployer (notez que ces variables etaient pre-remplies avec les valeurs de la precedente installation si disponible).
Une fois qu'on avait fait tout ca, on recuperait un joli RPM et on pouvait installer sur la plateforme voulue (demo, qualif1, qualif2, validation, et meme la prod).
Je suis en train de me familiariser avec Saltstack. Presque tous mes slips ont craqué.
Javier, tu saurais dire si ta technique est 1. Simple d'approche quand on ne la connaît pas du tout et 2. Adaptable à un projet qui a une pile d'outils aussi bordélique que ZdS ?
Pour 2 je dirais oui sans trop hésiter.
Le but du jeu c'est de "décrire" sa VM en fait. Un peu comme des requirements.py, un POM Maven etc. Tu vois l'idée.
Donc tu vas partir d'une image Docker Debian 8 et tu vas dans le DockerFile écrire : va chercher/ installe Pandoc, Gunicorn, Solr, … ('fin vos dépendances système quoi). Et une fois que c'est fait, va chercher la dernière version des sources sur le repo Git, et essaie de la faire tourner.
Pour 1, pas évident à dire :
J'ai commencé avec des trucs simples (faire fonctionner de simples jar) pour aller vers le plus complexe. J'ai pas démarré direct avec un projet de l'ampleur et de la complexité de ZdS. Je pense qu'il faut vraiment faire l'effort de suivre un tutoriel du site de Docker pour y aller molo, ou un bon bouquin, ou faire ça sur un micro-projet à côté. Démarrer d'emblée avec ZdS ça me paraît être la quasi-assurance de péter un plomb assez rapidement.
Ensuite y'a la base de donnée (qui est le point le plus délicat, notamment pour ZdS) ce n'est pas moi qui m'en suis occupé dans nos projets… Je sais que c'est ça passe par ce que Docker appelle un data-volume, que ça permet de faire des migrations de façon très sympa et en douceur, mais je n'ai pas regardé comment les données étaient conservées. Là-dessus faut vraiment regarder ce qui se fait dans le monde Django pour évaluer la techno.
Enfin, j'utilise Gradle comme mécanique de build à toutes les étapes de la CI (dev, test, pré-prod, prod). Et ça s'interface très bien avec Docker (via un plugin). Je ne sais pas trop quel outil vous utilisez pour le build / la CI. Faudrait regarder comment vous pouvez automatiser la construction / déploiement des images. (e.g. sur certains de mes projets, quand je fais un push sur Git, une image est automatiquement construite et déployée en environnement de test).
En gros : faire tourner une instance de ZdS ça doit être jouable assez rapidement, après pour l'avoir "production-ready" va falloir quand même y passer un certain temps, j'en ai peur.
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
