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

24.
LIVRAISON EN CONTINU ET RESYNCHRONISATION

25.
LIVRAISON EN CONTINU ET RESYNCHRONISATION

26.
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.

27.
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…)

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

29.
LIVRAISON EN CONTINU ET RESYNCHRONISATION

30.
LIVRAISON EN CONTINU ET RESYNCHRONISATION

31.
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

32.
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

33.
Straight to
the point
www.spikeelabs.fr