Blaskow David

DevOps : sans doute le terme le plus galvaudé du moment, tout autant qu'un insoutenable buzzword ; pour le coup, je ne savais à quoi m'attendre en me rendant à Marseille pour la cinquième édition du DevOps D-Day. Mais si vous êtes curieux de savoir ce qu'il se raconte à une conférence DevOps, vous n'avez qu'à suivre le guide.

Les dissidents ont mon oreille. J'ai toujours aimé les articles qui prenaient les modes à contre-pied, comme d'imaginer abandonner Docker et Kubernetes pour revenir à LXC. Cependant, je ne suis pas convaincu par ce retour en arrière, tant il est possible d'à peu près tout faire avec Kubernetes, comme d'y faire tourner des machines virtuelles !

Ansible c’est cool [1], ça vous apporte rapidité de déploiement, une grande souplesse grâce à ses modèles et bien d’autres avantages. Seulement, vous ne pouvez pas le laisser entre toutes les mains, l'oubli d’une option lors d'un déploiement et c’est tout votre infra qui risque d'être impactée.Le moment tant redouté est-il arrivé ? Êtes-vous devenu le Single Point of Failure de toute l'infrastructure ? Allez-vous devoir vous charger de tous les déploiements, et ce, jusqu’à ce que mort s’ensuive ? Non, non, non et non ! Vous n'allez pas vous laisser faire ! Et quoi de mieux pour mettre le pied à l'étrier de tout le monde qu'une simple WebUI ?

Cela fait déjà un moment que vous utilisez PostgreSQL, et vous avez peut-être déjà essayé pas mal de solutions pour le mettre en cluster... Sans grand succès. En voici une, pas piqué des hannetons : Patroni !

« We won’t be able to pretend that we can protect ourselves anymore. It’s a huge danger, a gigantic risk, but it’s worth it, if only we can learn to take care of each other, then this awesome destructive new connection won’t isolate us. It won’t leave us in the end so totally alone. »Cet extrait du manifeste « You are NOT safe » de Ryan Ray dans la série Halt and Catch Fire n'a jamais été autant d'actualité !

Pourquoi est-ce que j'ai la nette impression, avant même d'avoir écrit le moindre mot ou d'avoir pu introduire mon sujet, que déjà la moitié d'entre vous me déteste, tandis que l'autre moitié se frotte les mains, en se disant qu'ils avaient raison de penser que toute cette histoire ne serait qu'un feu de paille ?

Comme vous le savez déjà, dès 2013 Docker s'est imposé comme étant, de facto, l'outil de conteneurisation ; et son format d'image unique n'y est pas pour rien. Il a ainsi créé un écosystème où il est devenu simple de transporter et d'exécuter des applications dans des conteneurs. Quand il a fallu orchestrer tous ces conteneurs, c'est Kubernetes qui s'est imposé ; et s'il y a une chose qu'il a merveilleusement réussi à faire, c'est de créer un tout nouvel écosystème : les applications cloud natives.

Comment ne pas fondre comme un esquimau au soleil, en voyant la quantité de technologies qui est aujourd'hui mise à notre disposition pour rien ; et par rien, j'entends bien que vous pouvez les utiliser sans que cela ne vous coûte un seul centime. Vous voulez un DNS ? Prenez Dnsmasq ou CoreDNS. Un serveur web ? Essayez NGinx ou Apache. Un orchestrateur de conteneurs ? Boum, Kubernetes.

Je rencontre toujours beaucoup de développeurs qui souhaitent « passer aux conteneurs ». Si cela me fait à chaque fois le même plaisir immense, convaincu que je suis que c'est le prochain (ou plus exactement l'actuel) cap à franchir, je me demande tout de même si tout ce beau monde y est toujours bien préparé... Heroku, 12 Factor Apps, microservices, architectures distribuées, communication asynchrone, Rest API, CI / CD... si ce jargon ne vous est pas familier, alors prenez le temps de lire cette petite introduction, avant de vous lancer (trop vite) dans l'aventure.