Dev, boulot, kubernetes 

Kubernetes et Helm c'est quand même très cool. Par contre, la prise en main et la compréhension des concepts est hardcore.

Ça doit faire deux ans que j'ai essayé d'y toucher à plusieurs reprises (en déployant un cluster localement, etc.) sans grand succès.

Et là après 10 jours intensifs dessus, à lire des donnes de docs, je commence tout juste à l'avoir bien en main, à faire des déploiements complètement automatisés connectés à la CI, etc.

Dev, boulot, kubernetes 

Pourquoi c'est pratique/utile.

Déjà, il y a une abstraction totale de la machine sur laquelle tourne un process. On réfléchit beaucoup plus en termes de ressources, de contraintes, de volumes de données, d'applications, et de comment elles communiquent entre elles.

Du coup, en terme d'adminsys, c'est beaucoup plus simple de rajouter/enlever des noeuds dans un cluster k8s pour s'adapter à la charge de travail que de le faire à la mano avec les outils habituels.

Dev, boulot, kubernetes 

Ensuite, c'est orienté production et réplication des applications/données.

L'idée, c'est que chaque application soit répliquée sur au moins 2/3 noeuds et que même si un noeud ou un applicatif crashe, le traffic soit redirigé automatiquement sur les autres.

C'est rendu possible par le système de healtcheck: k8s monitore en permanence les applicatifs pour s'assurer qu'ils sont en bonne santé.

Dev, boulot, kubernetes 

Ça rend aussi possible des mises en prod progessives sans downtime :

1. je mets à jour 1/3 des applicatifs, je regarde s'ils sont en bonne santé avant de les exposer sur le réseau
2. je mets à jour le second tiers
3. etc.

Dev, boulot, kubernetes 

Après ça c'est des trucs qu'on peut faire aussi sans k8s. La boite ou j'étais avant le gérait avec Ansible et ça marchait. Mais les playbooks étaient d'une complexité monstre, et hyper spécifiques à notre applicatif.

Dev, boulot, kubernetes 

Maintenant, pour les aspects moins reluisants, tu sens que l'écosystème kubernetes est avant tout une aubaine pour les hébergeurs, à commencer par Google.

Comme la maintenance d'un cluster est complexe, il y a des cluster gérés en SaaS par différentes boites. En soi ce n'est pas gênant, on toujours gérer le cluster à la main si on veut, tout le code est open source.

Par contre il y a un risque de se faire enfermer sans s'en rendre compte. Je développe.

Dev, boulot, kubernetes 

En soi, une configuration k8s est générique et peut théoriquement fonctionner d'un hébergeur à l'autre, et c'est à peu près le cas pour des applicatifs stateless qui n'ont pas besoin de persister des données.

Mais dès que tu commence à utiliser les services que l'hébergeur vend en parallèle, comme les volumes de données dynamiques et répliqués, ou le load balancing, la situation change...

Dev, boulot, kubernetes 

Mais bon, il y a toujours la possibilité de garder une ou des machines hors kubernetes pour les données, et gérer cette partie là soi même.

C'est ce que j'ai fait dans le cas présent. Je me vois pas mettre ma BDD de prod dans une image Docker qui va tourner sur une machine où j'ai pas d'accès root et où je peux pas tweaker le système.

Dev, boulot, kubernetes 

À part ce risque là qui est quand même important, et la complexité générale du machin, des concepts, etc, je pense que c'est quand même un outil intéressant et qui répond à un besoin réel (déployer des applicatifs simplement, de manière secure, sans downtime et en haute disponibilité).

Dev, boulot, kubernetes 

L'écosystème est plutôt bien fait, il y a beaucoup de doc. On peut gérer et monitorer son cluster en ligne de commande, avec un dashboard ou même avec des outils tiers (Gitlab, dans mon cas, gère les déploiements via la CI/CD, et m'affiche même des stats sur l'utilisation CPU/mémoire au sein du cluster)

Dev, boulot, kubernetes 

Voilà mes conclusions pour le moment, ça va sûrement bouger encore.

Dev, boulot, kubernetes 

Ah oui et du coup ben, faut aimer ou a minima supporter Docker, sinon c'est un peu chaud ;)

Follow

Dev, boulot, kubernetes 

J'ai presque terminé la mise en place d'un env de staging complet, identique à la prod. Seule exception : les mails partent sur mailhog pour pouvoir débugger facilement github.com/mailhog/MailHog au lieu d'être envoyés pour de vrai.

C'est cool, tout tourne sous Docker et peut être distribué / répliqué maintenant (on avait encore des scripts custom lancés via cron, j'ai du les porter sur une task queue distribuée).

Dev, boulot, kubernetes 

il me reste encore deux trois petites choses à régler, notamment faire une copie régulière de la base de prod sur l'env de staging pour avoir des données à jour.

Et évidemment, il faut que je fasse tester l'env de staging à mon collègue pour qu'on valide ensemble que tout est bon.

Et à partir de là, je devrais pouvoir déployer très simplement le cluster de prod \o/

Dev, boulot, kubernetes 

après il restera la migration de notre VM actuelle vers la nouvelle prod sur Kubernetes, ça va être fun pour minimiser le downtime mais bon, ça fait partie du jeu aussi 😛

Dev, boulot, kubernetes 

Je pensais m'y remettre un peu aujourd'hui, mais il se trouve que le cluster K8S sur lequel je travaillais est dans un datacenter affecté par l'incident OVH de ce matin.

Du coup c'est bien, je vais pouvoir retester la réinstallation complète du cluster x)

Dev, boulot, kubernetes 

Bon, ben j'ai pu remettre en place un cluster fonctionnel et prêt pour la prod en moins de 2h (et encore, j'ai perdu du temps sur le backup/restore de la DB et des conneries).

C'est plutôt très cool !

Dev, boulot, kubernetes 

On est encore l'un d'un PRA, mais si jamais on a un incident type incendie de datacenter, ça veut dire que je suis probablement en mesure de restaurer une prod de zéro en moins d'une journée à partir des backups !

Dev, boulot, kubernetes 

Du coup, la migration de prod approche, d'ici deux semaines on devrait éteindre complètement notre VM hébergée chez Google Cloud pour passer sur un cluster Kubernetes de production (qu'il faut que je déploie, mais ça devrait aller vite).

Je pensait qu'on devrait prévoir deux petits downtime (migration DB puis applicatifs) ou un gros downtime (migration de tout d'un coup), mais en fait on devrait s'en sortir avec un petit downtime.

Dev, boulot, kubernetes 

Je prévois de d'abord migrer la DB chez OVH, et faire communiquer nos applicatifs existants vers cette nouvelle DB (là, il y aura du downtime, le temps du backup/restore)

En parallèle, je déploie nos applicatifs chez OVH, mais sans mettre à jour les DNS (du coup le traffic reste géré par la VM Google).

Ensuite, je réduit le TTL des entrées DNS, pour faciliter la bascule.

Et le jour ou on veut faire la bascule, simple mise à jour DNS.

Dev, boulot, kubernetes 

Boom, le traffic sera géré progressivement par OVH et plus par GCP, le tout sans interruption de service.

Faut que je double checke qu'il reste pas des trucs que j'aie oublié, mais normalement ça passe.

Dev, boulot, kubernetes 

Finalement, le plus long sera de migrer manuellement les services qui ne sont pas strictement de la prod (Sentry, le site wordpress, quelques outils de monitoring, etc.), mais on s'en fiche parce que ça a zéro impact sur nos clients

Dev, boulot, kubernetes 

faut que je fasse quelques tests de migration de la DB, mais je pense qu'on peut s'en tirer en 2h maximum de downtime, peut-être 1h si j'arrive à piper directement les process de backup et de restore sur les deux machines sans passer par le disque

Dev, boulot, kubernetes 

Ah oui, avant ça il faut que je migre la DB de notre serveur keycloak qui est toujours dockerisée et séparée, sur notre serveur postgres de production.

Dev, boulot, kubernetes 

Visiblement c'est pas compliqué du tout de faire un backup/restore entre deux serveurs postgresql sans passer par une copie intermédiare de fichiers :

pg_dump -C dbname | ssh -C remoteuser@remotehost "psql dbname"

(via stackoverflow.com/questions/12)

Dev, boulot, kubernetes 

(je veux éviter la copie parce qu'avec les performances très limitées des disques GCP, ça peut facilement tripler ou quadrupler le temps de backup/restore)

Dev, boulot, kubernetes 

11 minutes pour un backup/restore complet de notre base de 7GB, c'est pas mal (ça pourrait aller beaucoup plus vite mais bon, GCP 🤷‍♀️ )

Dev, boulot, kubernetes 

Bon, du coup j'ai enfin pu me mettre a Prometheus, et c'est très cool, ça marche super bien avec Grafana et Kubernetes.

Ci-dessous quelques exemples de dashboards que j'ai pu simplement importer en deux clics depuis grafana.com/grafana/dashboards

Dev, boulot, kubernetes 

@agate ce sont tes employeurs qui doivent être contents d’avoir embauché quelqu’un de compétente :D

Dev, boulot, kubernetes 

@lthms disons qu'on est mutuellement content·es de s'être trouvé·es :3

Dev, boulot, kubernetes 

@agate wow.. Impressionnant dit comme ça

Dev, boulot, kubernetes 

@Electron ouais, je me rendais pas trop compte non plus avant d'avoir fait le test

Sign in to participate in the conversation
Eldritch Café

Une instance se voulant accueillante pour les personnes queers, féministes et anarchistes ainsi que pour leurs sympathisant·e·s. Nous sommes principalement francophones, mais vous êtes les bienvenu·e·s quelle que soit votre langue.

A welcoming instance for queer, feminist and anarchist people as well as their sympathizers. We are mainly French-speaking people, but you are welcome whatever your language might be.