🗞 Actus DevOps #6 - 202102

[cchaudier]

Que se passe t’il en ce moment dans le monde du #DevOps ou du #Cloud ?
Actus DevOps est là pour vous aider.
Je suis avec @DamyR @erwan et @Uggla

On y parlent de :
Amazon Web services school : formation gratuite pour 29 millions de personnes
Google apache open source
Docker Distribution légué à la Cloud Native Computing Foundation (CNCF)
Stackoverflow a été hacké !
Des outils pour votre boîte à outils DevOps

https://lydra.fr/ado-6-fevrier-2021/

N’hésite pas à réagir à ces nouvelles et à donner ton point de vue en commentaire.

[mcorbin]

Je viens juste pour dire que Java (et la JVM) est une des plateformes la plus performante actuellement (largement devant la concurrence), et que “java c’est lent” ou “java ça prend trop de ram” est une légende héritée des usines à gaz montées à l’époque dessus (les jboss etc… mais Java n’a jamais été le coupable).

[mcorbin]

Autre remarque (oui je commente pendant que j’écoute ).

Sur le développement en local, tu dis @DamyR “on fait du k3s en local pour avoir en local ce qui se rapproche de la prod”.

Je pense personnellement que devoir faire du k8s, docker… autre que pour démarrer éventuellement des DB ou autre pour des tests d’intégration n’est pas une bonne pratique.

Tous les projets où j’ai travaillé et ou il fallait un kube local pour travailler c’était l’énorme galère. Pour moi l’env de dev local doit être le plus simple possible, si il y a un dépendance à kube en local pour moi c’est que le workflow de dev est problématique.

[DamyR]

Je me base sur ce que je voie le plus actuellement. Soit il y a une plateforme par dev dans “le cloud”, mais souvent les personnes ne veulent pas multiplier les env pour des questions de coût / gestion. Et pour faire juste un petit test ou autre c’est lourd de devoir tout push (même sur une branche).

J’ai dit K3S, pas de la BDD 80% du temps la BDD est “dans le cloud” et juste le workload qui contient le code en local pour du dev ou prototypage. Après c’est envoyé en dev, après en uat après en préprod et après en prod pour les différents tests. Donc les tests complets sont fait sur ces environements automatisés

Encore une fois c’est juste de l’XP, je ne dis que c’est sans défaut. Mais effectivement dans l’épisode je ne clarifie surement pas assez ça

[mcorbin]

ok

Ce que je voulais dire c’est que pour moi c’est super important que les dev puissent travailler sur leurs programmes en isolation au maximum en local, sans déployer d’outils. L’env de dev doit être le plus simple possible.

Sinon ça veut dire qu’on est dépendant d’un détail d’implémentation (où ça tourne, les services avec lesquelles le programme communique…) pour tester et c’est souvent pour moi un problème (car ça complexifie tout). Quasi tous les programmes sur lesquelles je travaille tournent dans kube, pourtant j’ai jamais un kube qui tourne en local.

[DamyR]

Par curiosité tu ne trouves pas ça trop lourd de devoir pousser à chaque fois que tu veux tester un minimum ? Ou tu as quand-même une solution en local pour le minimum ?

[mcorbin]

Je mock tous les appels externes/IO en local. Donc on teste tout mais en simulant les services externes.
C’est aussi beaucoup plus rapide à exécuter.
On fait aussi de plus en plus de property based testing, avec des générateurs permettant de générer des fausses réponses de services externes basées sur une spec par exemple.
J’utilise un peu docker compose pour démarrer des base de données (etcd, mariadb…) pour certains tests un plus complets, mais jamais je ne démarre les services dont mon app dépend (il y a quelques années on faisait ça, on a arrêté, trop compliqué à gérer).

De toute façon ce serait difficilement faisable, il y a pas mal de dépendances entre services (l’orchestrateur kube qui parle à l’orchestrateur instance pool qui parle à l’orchestrateur VM qui parle à des daemons qui tournent sur des hyperviseurs etc…).

C’est pas facile mais je pense que se mettre dans un mode où les devs se disent “bon, comment je peux tester mon service sans avoir à démarrer d’autres services tout en étant confiant que ça va passer quand je vais déployer ma branche sur un env de dev” est un très bon exercice.
Ça force vraiment à définir les interfaces entre services, le format des requêtes/réponses attendues, à écrire des tests pertinents simulant l’extérieur, à définir des “contrats” entre services…

Et ça libère vraiment le dev de toute la partie “allez demain je passe une demi journée à faire marcher mon env de dev que je dois connecter à un environnement externe, démarrer un kube en local, ah bah le proxy entreprise me bloque, ah mais moi ça marche pas car je suis sur tel distrib linux, chez moi minikube démarre pas, machin a fait une nouvelle version du service B et moi sur la branche du service A ça marche plus etc…”.

Je rajouterai que ça évite que mon app se retrouve “liée” à une façon de déployer. Que mon app tourne sur une VM, dans kube, ou autre, au final ça change rien sur mon code. En gros, que l’infra ne “leak” pas chez le dev (car c’est pas son problème, du moins pas au moment du développement).

[clarsonneur]

Salut,

Je comprend bien le problème que tu soulèves.

D’une manière générale, je pense que c’est toujours une bonne pratique de mettre en oeuvre des tests/mocks pour travailler en isolation (dev), certes, mais aussi dans un contexte plus large pour garantir la qualité des composants (ops).

L’effort que tu fais pour mocker, me parait essentiel.

Pour ma part, quand je travaille avec certains devs, je fais souvent attention à ce que l’aspect infra ne soit pas un frein aux devs, tout en essayant de répondre aux besoins de stabilité de l’ensemble des services qui constituent le produit final.
Et j’ai très souvent recours à Docker pour ca. Mais aussi aux Makefile et d’autres outils divers.
Maintenant, ce n’est pas parfait. Je n’ai pas trouvé de solutions parfaites, notamment parce que l’usage de docker n’est pas toujours simple, surtout si tu développes dans un ide, tel que VSC.

Pourquoi docker? parce que on peut vraiment dans la majorité des cas reproduire le fonctionnement dans un nouvel environnement, très facilement.
Pas de soucis de dépendances, de versions, etc…

En gros, j’utilise docker et je pousse à son usage pour définir l’environnement de build du composant, à partir de développeur. Ainsi, les contraintes de production sont prises en compte au plus tôt dans la chaine mise en production.

Par contre, en effet, démarrer un kube pour développer… Ca n’a pas de sens, je trouve, la plupart du temps. Mais c’est plus un avis. Il faut toujours voir le contexte pour comprendre pourquoi…

[krusaf]

Je pensais que c’était bien que les devs touchent un peu du kube. Y pas tout dans docker, les notions de liveness et readyness notamment ? (Bon y a le healthcheck pour le liveness à la rigueur). Il doit manquer pas mal d’autres mécanismes j’imagine. Et puis pour les mises à jour, c’est bien aux devs que revient la tâche de dire comment faire la mise à jour ? Plutot recreate ou rolling update non ?

[mcorbin]

Oui c’est bien que le devs connaissent kube si utilisé en prod, j’en avais déjà parlé mais chez nous c’est les dev qui gèrent les manifests, les déploiements, et sont d’astreintes 7j/7 sur leurs apps.

Mais c’est pas pour ça que je veux démarrer un kube en local quand je développe

Utiliser les conteneurs pour aider lors de certains tests, ou pour la CI (on build tout dans des conteneurs aussi), voir lancer des tests d’intégrations un peu poussés en bout de chaine, pourquoi pas.

Mais je n’ai personnellement (plusieurs années de kube en prod) pas vu de cas où démarrer un kube en local pour pouvoir développer avait du sens.
Si j’ai besoin de démarrer un kube, de démarrer plusieurs services, déployer l’app en cours de dev sur le kube etc… pour tester c’est pour moi que j’ai raté un truc. Le workflow de dev doit rester je pense le plus simple possible.

Et si vraiment on veut faire des tests poussés, pour moi toute la complexité doit être déportée côté infra (via des namespaces temporaires sur un cluster partagé par exemple), mais surtout pas sur le poste de dev. Car par expérience il y aura toujours un % non négligeable de dev qui arriveront pas à faire marcher l’env local si celui ci est trop complexe.
Et il est toujours possible de démarrer des apps hors kube en local branchés sur des environnements de dev/recette.

[krusaf]

Merci pour le retour intéressant. Ce qui me fait douter (pour nous), c’est qu’on commence à faire du kube. Les dev et exploitants ont eu une formation de base, puis on en est au stade où on conteneurise nos applications… Les devs font finalement du docker-compose (non localement) mais sur une machine commune (toujours l’ancienne façon de travailler en somme).
Moi j’exploite leur conteneurs dans un kube de test (on est pas encore passé en prod, on a beaucoup de choses à regarder avant) mais au final, y a quasiment que moi qui fait du kubernetes et c’est pourtant toute l’équipe technique qui fait l’astreinte à tour de rôle.

Alors sur l’astreinte, c’est aussi un peu biaisé, y a plusieurs profils et tout le monde ne connait pas bien l’archi (qui bouge un peu comme on migre chez AWS) et c’est difficile à suivre. Et ça fait déjà un moment que je me demande comment on peut continuer de faire l’astreinte à tour de rôle si on a pas tous la même maitrise. En même temps, on est peu nombreux… (3 dev, 3 exploitants/adminsys, 3 techniques sans formation sur docker/kube). Quand y a un pâté, si c’est important, ça finit par un appel à l’admin sys (qui gère aussi le réseau) ou l’exploitant (moi) pour gérer la panne.

Si les dev qui viennent d’avoir la formation sur kube pratiquent pas, ce sont des connaissances qui vont être perdues en peu de temps. Surtot que la formation était de base et qu’il y a plein de choses qu’on a pas vu (peu de rbac, on a pas parlé des initcontainers …). Je pensais les orienter justement sur un kube local où ils pourraient tester comme ils le veulent. Cet effort de maintenir les connaissances ou même la veille techno n’est pas réalisé.

On en est pas au stade ou chaque dev est responsable du bon fonctionnement de son app en prod et avec 3 dev, je doute que ce soit possible. Mais je prends toutes les remarques.

[mcorbin]

Après rien n’empêche d’avoir un kube local pour “jouer” avec, mais pour moi ça doit pas être un prérequis pour développer (en gros: on bloque pas le dev si son kube local marche pas).

Les dev monteront en compétence au fur et à mesure. Fait leur écrire et déployer des manifests sur ton kube de test (en gros une règle du type: à chaque nouvelle version/nouvelle app vous déployez sur le kube de test). et au fur et à mesure ils apprendront. Si c’est un kube de test c’est pas grave si ils cassent un truc je présume.

@krusaf

Et ça fait déjà un moment que je me demande comment on peut continuer de faire l’astreinte à tour de rôle si on a pas tous la même maitrise

C’est impossible de tout maitriser dans une astreinte. Je peux te dire comment on fonctionne sur ça.
Chaque application a une doc d’astreinte avec les alertes pouvant être déclenchées et les résolutions possibles. La doc contient également les procédures/commandes pour investiguer des choses non documentées (car la doc répond pas forcément à 100 % des questions surtout sur un nouveau problème). Et on peut escalader (appeler du renfort) si on coince.
Le but est de maintenir cette doc avec de nouvelles procédures après chaque problème pour que le suivant sache quoi faire.

Mais je reconnais que l’astreinte dans une petite équipe est compliquée. Nous on a 2 astreintes en parallèle (une dev une ops), + de l’escalation de chaque côté et un moyen pour l’ops d’appeler le dev (et l’inverse). Donc ça fait rapidement du monde mobilisable.
Une solution est déjà de laisser les gens non familiers avec l’astreinte/la prod gérer les problèmes en journée (en étant derrière pour assurer au cas où). En gros c’est eux qui sont alertés en premier et ils viennent vers toi si besoin. Comme ça les gens montent en compétence sans stress.
Si les gens sont autonomes en journée sur leurs déploiements en prod, sur les incidents, que tout est documenté etc… une bonne partie du boulot est faite

[krusaf]

Retour intéressant, je vais m’en inspirer.