Du test unitaire, au linting en passant par les tests end-to-end, l’intégration continue du logiciel est devenu un standard de l’industrie. En revanche, dans les organisations où la plateforme de déploiement est on-premises ou gérée en interne, le contrat de communication entre les développeurs et les responsables opérationnels (SRE, Sysadmin..) n’est pas toujours très clair : seuls certains développeurs sont réellement impliqués dans le déploiement du produit. La philosophie DevOps a encore son mot à dire ! L’ensemble des développeurs doit s’impliquer dans la livraison, le déploiement et l’observation du logiciel en production. Dès lors, il faut établir un contrat de communication et mettre en place des outils et process pour réduire les frictions entre développeurs et opérateurs. Dans cette présentation, je vous présente un retour sur expérience sur la phase d’industrialisation du déploiement et de la livraison continue grâce à #kubernetes et #kustomize, qui a été au cœur de mes missions durant mon alternance chez SpikeeLabs et en collaboration avec Unyc !

1. VENDREDI DE LA TECH N°1
Industrialisation du processus de livraison et
pratiques DevOps avec Kubernetes et Kustomize
16/09/2022
Léo Rolland

2. INTRODUCTION

3. DÉPLOIEMENT ET PRATIQUES DEVOPS EN 2021
Cibles de déploiement finales les plus communes
Etude de Google – State of devops 2021
1,260 professionnels dans le monde
Les 2/3 ont plus de 11 ans d’expérience
Entreprises de toutes tailles, dans le monde entier

4. L’ÉMERGENCE DU « TOUT-EN-AAS » EN INFORMATIQUE
Une tendance naturelle à l’évolution de la société
L’électricité, l’eau, les énergies, internet, la nourriture, le divertissement….. tout est service !
Pourquoi ?
Déléguer les problèmes compliqués
Pour se concentrer sur son activité (et les problèmes essentiels)
Pour atteindre plus vite ses objectifs (réduction du TTM)
Elasticité
Pas besoin d’anticiper variations, le forfait s’adapte à la demande
Garanties de disponibilité / qualité
Et permet de factoriser les ressources
Une seule centrale de production (nucléaire, hydraulique..) peut fournir en électricité jusqu’à 3
millions de foyers
En comparaison, quel serait le bilan en ressources de 3 millions d’installation individuelles ?

5. L’ÉMERGENCE DU « TOUT-EN-AAS » EN INFORMATIQUE
En informatique, l’émergence des -aaS
Déléguer les problèmes compliqués
Les collaborateurs se concentrent sur le développement (consumer)
Les ressources sous-jacentes sont déjà disponibles à la demande (provider)
Elasticité (scaling illimité, peu d’investissement initial et de fin)
Garanties (BP, SLA garanti ou remboursement)
Et permet de factoriser les ressources
1 gros serveur est bien plus rentable que 10 serveurs 10x moins puissants..
Réduire l’overhead logiciel (OS partagé, librairies partagées, runtime partagé, code indépendant)

6. EST-CE POUR AUTANT UN BON CHOIX ?
Dépend des besoins
Disponibilité : SLA
Budget
Réactivité : RTO / RPO (Recovery Point Objective)
Le besoin est-il constant ? Est-il prévisible ?
Temps disponible
Quelques risques de la mise en SaaS ou du « lift » dans le cloud
Souveraineté des données
Risque de vendor locking
Coûts non contrôlés
Une solution, le cloud hybride ou multi-cloud

7. DÉPLOIEMENT ET PRATIQUES DEVOPS EN 2021
Infrastructure sous-jacente les plus communes

8. DÉCOUPAGE CONSOMMATEUR / PROVIDER
En utilisant un PaaS, ou SaaS, le provider vous impose le contrat
Lorsque l’infrastructure est déléguée en interne (Promises, Bare metal..), pas de contrat,
il faut donc convenir de standards pour faire communiquer les Dev et les Ops
Docker et Kubernetes permettent d’implémenter ce découpage et d’établir un contrat

9. 02
UNE ARCHITECTURE
« DEV-OPS FRIENDLY »
AVEC KUSTOMIZE
Cas d’usage

10. RESPONSABILITÉS ENTRE SPIKEE ET UNYC

11. RESPONSABILITÉS ENTRE SPIKEE ET UNYC

12. IMPLÉMENTATION DU CONTRAT DEV-OPS
• Exemple d’organisation
• Les développeurs écrivent le code et spécifient comment le déployer (consommateur)
• Les SRE proposent des outils, assurent le déploiement et le MCO de la plateforme (fournisseur)

13. IMPLÉMENTATION DU CONTRAT DEV-OPS
• Exemple d’organisation
• Certaines responsabilités sont mises en commun
• Monitoring
• Planification
• Amélioration continue et tooling

14. CONTRAT DEV – OPS AVEC
• Base
• Ressources Kubernetes communes à tous les
environnements cibles de l’application
• Deployments (Pods)
• Jobs
• Services
• Overlays
• Variants spécifiques à chaque environnement
• ConfigMaps
• Secrets
• Ingress
Architecture du dépôt de déploiement

15. CONTRAT DEV – OPS AVEC
La base

16. CONTRAT DEV – OPS AVEC
Un overlay

17. CONTRAT DEV – OPS AVEC
Chiffrement
Des secrets
postgres.secret.yaml
postgres.encrypted.yaml

18. CONTRAT DEV – OPS AVEC
Architecture du dépôt de déploiement

19. 03
LIVRAISON ET
RESYNCHRONISATION
REX

20. LIVRAISON EN CONTINU ET RESYNCHRONISATION

21. LIVRAISON EN CONTINU ET RESYNCHRONISATION

22. LIVRAISON EN CONTINU ET RESYNCHRONISATION

23. LIVRAISON EN CONTINU ET RESYNCHRONISATION

25. LIVRAISON EN CONTINU ET RESYNCHRONISATION

26. LIVRAISON EN CONTINU ET RESYNCHRONISATION

27. LIVRAISON EN CONTINU ET RESYNCHRONISATION
Déjà réalisable avec l’API v4 Gitlab (cURL), le CLI git… Mais
1.Le monde OPS n’est pas l’expertise des développeurs
2.cURL n’est pas idéal pour réfléchir, communiquer et
automatiser
3.Complexité accidentelle élevée pour des problèmes
simples
-> Il faut abstraire ces fonctions avec une interface simple
- DSL (Langage spécifique)
- Fluent API
- API
-> En intégrant des contraintes techniques
- Doit fonctionner dans une CI (script Bash)
- CLI (instructions exprimées dans les termes du problème)
Des comportements variables
Pour chaque client et dépôt, un flux
différent, manipulé par les développeurs.

28. LIVRAISON EN CONTINU ET RESYNCHRONISATION
Développement d’un CLI spécialisé :
•Gitlab Spikee “current”
•Gitlab Client “remote”
•Instructions simples et documentées
Technologies :
Python, Docker, Click (man, autocompletion, help…)

29. LIVRAISON EN CONTINU ET RESYNCHRONISATION
Assemblage de pipelines de livraison
et resynchronisation très simple !

30. LIVRAISON EN CONTINU ET RESYNCHRONISATION

31. LIVRAISON EN CONTINU ET RESYNCHRONISATION

32. LIVRAISON EN CONTINU ET RESYNCHRONISATION
Difficultés
• Faire les bons choix
• Contraintes techniques
• Contraintes organisationnelles
• Premier refus du client
Apports
• Penser et mettre en place une solution
technique adaptée et évolutive

33. LIVRAISON EN CONTINU ET RESYNCHRONISATION
Evolution des processus
Evolution des outils
Et à travers la formation
• La réduction des frictions entre les
développeurs et administrateurs.
• La réduction des frictions entre les
organisations
=> Gain en efficacité, fiabilité et cohésion

34. Straight to
the point
www.spikeelabs.fr