Vos techniques de deploiement

application, web...

L'auteur de ce sujet a trouvé une solution à son problème.

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 :

  • y'a plein de repos Git, N pour le back, M pour le front.
  • chacun a un processus de build à sa sauce (gradle / grunt principalement)
  • on attend un résultat sous forme "deployable" (une archive quoi, un jar, un war, …) contenant à la fois les ressources front et back
  • à côté de ça y'a des BDD, et d'autres trucs éventuellement à déployer

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.

Happiness is a warm puppy

+1 -1

Chez moi ça se passe comme ça :

  • Le déploiement doit se faire le vendredi soir entre 18h et 19h (si c'est départ en congés, c'est mieux)
  • Le dev qui déploie doit s'assurer d'être près à partir avant de commencer le déploiement (au cas ou ça tourne mal, la fuite reste la meilleure solution)
  • Une fois ces conditions validée : commit du code (après avoir passé les tests, duh)
  • création d'un virtualenv avec le nouveau code
  • archive du virtualenv
  • copie de tarball sur un serveur de déploiement
  • récupération sur un serveur de recette
  • installation du virtualenv en recette
  • test en condition réelle
  • même chose en prod
  • extinction du portable et fuite vers la sortie

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…

Édité par Xia

Xia, peluche olympienne |Python en s'amusant | Random xkcd

+1 -1

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).

S'il n'y pas d'accents dans mes messages c'est parce que je suis sur un clavier norvegien :) ÅÅØØøøøÆÆÆ

+0 -1

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.

Happiness is a warm puppy

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

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