đŸ“» Qu'est-ce que le DĂ©ploiement Continu ? | Radio DevOps #25

:repeat: Aujourd’hui on s’enfonce dans la jungle de la Livraison et du DĂ©ploiement Continu !

La CD c’est à la fois :

  • la Livraison Continue (Continuous Delivery)
  • le DĂ©ploiement Continu (Continuous Deployment)

Alors tu te demande peut-ĂȘtre ce que c’est et Ă  quoi ça sert ?
Comme d’habitude le #podcast #radioDevops est lĂ  pour t’aider Ă  dĂ©marrer.
Je suis avec @mcorbin , @DamyR et @Uggla pour en parler.

Et toi pratiques-tu déjà la CD ?
C’est quoi tes outils prĂ©fĂ©rĂ©s ?

1 « J'aime »

Chouette panel ! Juste une prĂ©cision sur progressive delivery: on utilise ce terme justement pour regrouper toutes les techniques Ă©voquĂ©es (blue / green, canari, A/B testing, feature flags, dark launches) pour indiquer que l’on dĂ©ploie les fonctionnalitĂ©s aux utilisateurs de façon progressive. En opposition aux dĂ©ploiements et mise Ă  disposition des fonctionnalitĂ©s en une fois. Parfois assimilĂ© Ă  un risque assumĂ© de “tester en production”.

Pour moi, le moment oĂč j’ai rĂ©alisĂ© dans ma carriĂšre que l’on pouvait sĂ©parer l’action de dĂ©ployer (une responsabilitĂ© de la DSI) et l’action de mettre Ă  disposition des utilisateurs (une responsabilitĂ© du dĂ©partement vente/marketing) a Ă©tĂ© une grande rĂ©vĂ©lation !

2 « J'aime »

Super!
Ca me fait penser qu’en ce moment, un outils me manque, ainsi qu’à l’équipe QA pour le “release management”. L’idĂ©e est d’avoir une vue sur les diffĂ©rentes versions (dĂ©sirĂ©es, et dĂ©ployĂ©es) sur chaque environnements. Voir allez jusqu’à la promotion d’une version vers un environnement jusqu’à la production.
Argocd est super pour les env sous kubernetes, mais tous nos environnements ne sont pas encore sous kubernetes, et il y a aussi les dĂ©ploiements infra avec terraform et ansible que l’on souhaite pouvoir avoir dans cet outil.

Vous avez des pistes ?

Hello, @cchaudier
J’ai suivi avec attention votre ballado diffusion sur la CD, et je voudrais te faire un REX sur la partie Ansible tower & Ara. Attention c’est purement subjectif et je suis loin d’ĂȘtre un expert.

J’utilise les deux en mĂȘme temps, je considĂšre que AWX/Tower me donne les informations d’une certaines maniĂšre qui, moi, ne me conviennent pas. Nous n’avons pas tout le contexte d’execution mais Ă©galement la visibilitĂ© de l’erreur transmise par AWX est assez brouillon.
Aujourd’hui pour une erreur, mĂȘme simple, la lire dans AWX est une grosse souffrance pour ma part. De plus lorsque tu scroll vers le bas/haut le chargement est lent. Mais AWX / Tower te permets d’envoyer les logs des jobs dans un centralisateur de log (rsylog - jobs events).
https://docs.ansible.com/ansible-tower/latest/html/administration/logging.html
Je pense, mais je peux me tromper, que Awx/Tower ne sont pas forcément fais pour ça.
Pour ma part, ce sont des outils d’orchestration, ils permettent de faire des formulaires etc

Mais c’est plutot le but d’Ara. Ara comme tu le sais, puisque je vois que tu fais de temps en temps la promo ;), est facile Ă  utiliser et permet (dans une moindre mesure pour ma part) de remonter via API les logs Ă©galement. La lectures des jobs / taches est beaucoup plus claire et simple avec Ara, les recherches Ă©galements etc. :wink:

Voila, c’est mon experience que j’ai avec les deux outils. :wink:

Ara à un billet de blog au sujet de la mise en place d’ara sur awx : Recording Ansible playbooks from AWX with ara | ARA Records Ansible | ara.recordsansible.org

David AUFFRAY

2 « J'aime »

Effectivement, je connais pas d’outil pour ce besoin et si quelqu’un a des pistes, ça m’intĂ©resse aussi.
Dans ma précédente expérience, un collÚgue avait fait un dashboard custo qui présentait les données aprÚs collecte sur les différents env vs la version dans le repo.

1 « J'aime »

Sujet intĂ©ressant, j’avais regardĂ© trĂšs succintement argocd mais n’y est pas donnĂ© de suite favorable prĂ©fĂ©rant finalement faire un script bash tout simple dans un premier temps, nos besoins Ă©tant assez limitĂ©. J’ai quelques questions Ă  son sujet si quelqu’un veut bien m’éclairer.

Si je comprends bien, argocd check le repo git et applique Ă©ventuellement automatiquement la derniĂšre Ă©volution (et on a la possiblitĂ© de le faire manuellement sinon). Dans le cas de deux clusters k8s (un de PREPROD, l’autre de PROD), le workflow consiste plutĂŽt Ă  appliquer automatiquement en PREPROD, et manuellement en PROD ?
En regardant le site web d’argocd, je comprends qu’on parle d’un repo git ne contenant que les manifests (qu’on me corrige si je me trompe). Qu’en est-il de la gestion de configmap pouvant contenir des mots de passe par exemple ? (est-ce qu’on peut utiliser git-crypt avec argocd par exemple ? Je me rĂ©ponds Ă  moi mĂȘme, Ă  priori oui mais faut se maintenir un surcouche, c’est pas violent pour autant https://github.com/kvaps/argocd-custom-tools)
Vous faites comment ?

Pour ceux ayant mis en place, vous laissez ensuite les DEV gĂ©rer complĂštement le dĂ©ploiement jusqu’en prod ?

Hello,

J’ai un playbook ansible qui me permet de configurer un nouvel env de mon app dans argocd. Il dĂ©ploie :

  • les config argocd (project, app)
  • le namespace K8s dĂ©diĂ© Ă  cet env
  • les secrets K8s (encryptĂ©s dans le code du playbook avec ansible-vault)

Ensuite, j’ai un repo git appelĂ© sobrement “gitops”, qui contient les configs des app qu’argocd va dĂ©ployer. Aucun secret dans ce repo, comme ils ont Ă©tĂ© crĂ©Ă©s avant.

Les app qu’argocd va dĂ©ployer sont packagĂ©es avec Helm. Et pour chaque app, argocd va chercher 2 fichiers values:

  • values.yaml => config par dĂ©faut de l’environnement
  • values-ci.yaml => contient les valeurs que la CI/CD va changer, en soit, uniquement la version de l’app.

Quand une nouvelle version de l’app est mis Ă  dispo par la CI/CD, a la fin du pipeline, le fichier values-ci.yaml est mis Ă  jour dans le repo gitops, ça dĂ©ploie automatiquement dans argocd.
Je n’ai aucune validation manuelle entre le repo gitops et argocd, mĂȘme en prod. La logique de validation de la version se fait en amont, dans l’outil de CI/CD.

1 « J'aime »

intérressant merci.
C’est pas trop gĂȘnant d’avoir 2 repo qui n’ont pas la mĂȘme vie. Par exemple, si t’as besoin de modifier une configuration dans ton repo gitops pour coller Ă  la nouvelle version de l’application ?

C’est super pratique au contraire.
La config n’a rien à faire avec le code d’une app.

Ce n’est pas la config dans le repo gitops qui doit coller à l’app, mais l’inverse. ^^
Si on renomme une var d’env par exemple, on crĂ©er d’abord la nouvelle var d’env via le repo gitops, puis on met Ă  jour l’app.

1 « J'aime »