Organiser son CI/CD - présentation
0 j'aime330 vues
Le document décrit comment réduire par 18 le coût des chaînes CI/CD en expliquant des concepts clés de compilation et de déploiement, en se concentrant sur l'organisation des dépôts et des sous-projets. Il fournit des exemples de construction d'applications Python avec différents modules et déploiements, ainsi que des comparaisons de coûts entre des chaînes de construction intégrées et parallèles. Les coûts sont estimés en fonction de la durée des constructions et des modalités de location horaire ou mensuelle.
Organiser son CI/CD - présentation
- 1. Ou comment diviser par 18 le coût de la chaîne CI/CD… Julien Garderon – juin 2021 Sommaire — Dépôt typique Python (ex.) Modalités de build Organisation totale Négocier les versions Ajuster les coûts Page blanche Concepts fondamentaux
- 2. Python C Monde « Java » Javascript Typescript LISP (CL) Forth Abstraction Code machine Code pseudo-machine Bytecode Interprétation 2 1 1 : Compilation (changement d’abstraction ; ex. compilation du C vers du code machine) 2 : Transcompilation (changement de format d’abstraction ; ex. transcompilation de Typescript vers du Javascript) => Exemple d’un changement de langage : procédural vers fonctionnel ; changement syntaxique entre des versions, etc. Concepts de « construction », « compilation », etc. « Un compilateur source à source, transpileur ou transcompilateur est un type de compilateur qui prend le code source d'un langage de programmation et le compile dans un autre langage de programmation. Un compilateur source-à-source opère sur deux langages avec approximativement le même niveau d'abstraction, alors qu'un compilateur traditionnel compile un langage de haut niveau vers un langage de bas niveau. » – Wikipédia, Compilateur source à source Format le « grand flou » entre la pure interprétation et le code machine Bas niveau Haut niveau
- 3. Dépôt Git (avec code Python) Registre PIP Dépôt typique python Étape 1 : test statique Étape 2 : test dynamique Étape 3 : création de la doc Étape 4 : création de l’artefact PIP Étape 5 : enregistrement auprès du registre Chaîne de construction d’un élément Étapes « qualité » Étapes « connaissance » (dont génération des graphiques avec PlantUML, Kroki, etc.) Étapes « mise à disposition » ! (alerte de fin : web hook) et
- 4. Module 1 Module 2 Applicatif Installateur Déploiement 2 2’ Module 1 Module 2 Applicatif InstallateurDéploiement 1 1’ Ex. 1 : Chaîne unique (« intégrée ») Ex. 2 : Chaînes multiples Modalités de build Runner plus puissant (max du besoin sur la chaîne) ; gérer davantage les branches ; créer des bypass Adapter chaque runner à sa tâche ; tests locaux ; optimiser le « time to execute » ; gérer finement les versions On prend le max de la construction (car parallélisation) Exemple ici d’un projet d’applicatif Python avec deux modules, un corps principal sous le format d’un package et un installateur (.deb). L’ensemble est fourni sous le format d’une image Docker, pour être utilisé dans un orchestrateur type Kubernetes
- 5. Dépôt module 1 Dépôt module 2 Dépôt applicatif Dépôt de déploiement Dépôt d’installateur Registre PIP Registre DEB Registre Conteneur Registre documentation Orchestrateur 1 2 3 4 Organisation totale Un dépôt = un sous-projet L’organisation du projet peut impacter l’organisation des dépôts – et inversement (ex. classique entre un projet monolithique vs un projet multiple sous le format de micro-services). Il doit rester une cohérence d’ensemble
- 6. v1 Dépôt module 1 Dépôt module 2 Dépôt applicatif Dépôt de déploiement Dépôt d’installateur v1 v2 v3 v4 v2 v3 v4 v5 v6 v1 v2 v3 v4 v5 v6 v7 v8 v1 v2 v3 v4 (origine) Instant « T1 » => déploiement v(g) 1 Ex. dernière version dispo. ● Module 1 = v1 ● Module 2 = v2 ● App = v2 ● Installateur = v1 Instant « T2 » => déploiement v(g) 2 à 4 Ex. fixer une version ● Module 1 = v2 ● Module 2 = v3 ● App = v5 à v7 suivant ● Installateur = v3 Suivant la date de livraison, pour une même version « v3 » de mon installateur, je livre en réalité 3 images différentes pour le « run » Négocier les versions Temps
- 7. Ajuster les coûts Besoin technique : ● chaîne unique : B2-15 ● 0,1169 € / heure ● 42,00 € / mois ● chaînes multiples : B2-7 ● 0,0619 € / heure ● 22 € / mois Durées horaires (hors coût projet, estimations fictives) : ● Construction module 1 : 1 ● Construction module 2 : 0,5 ● Construction applicatif : 0,75 ● Construction installateur : 0,25 ● Déploiement : 1 Durée cumulée pour un déploiement (avec build) : ● Intégrée : 1 + 0.5 + 0.75 + 0.25 + 1 = 3,5 ● Parallèle : max(1 ; 0.5; 0.75; 0.25) + 1 = 2 Coût d’un déploiement : ● Intégrée (B2-15) : ● Location horaire : 3.5 => 4 x 0,1169 = 0,40915 € ● Location mensuelle : 42 € ● Parallèle (B2-7) : ● Location horaire : 2 x 0,0619 = 0,1238 € ● Location mensuelle : 22 € Point de bascule location horaire vs mensuelle : ● Intégrée : 42 / 0,40915 = 102 déploiements ● Parallèle : 22 / 0,1238 = 176 déploiements Nbre de déploiements 1 10 100 125 150 175 200 1000 Intégré (mensuelle) 42 42 42 42 42 42 42 43 Intégré (horaire) 0,40915 4,0915 40,915 51,14375 61,3725 71,60125 81,83 409,15 Parallèle (mensuelle) 22 22 22 22 22 22 22 23 Parallèle (horaire) 0,1238 1,238 12,38 15,475 18,57 21,665 24,76 123,8 1 10 100 125 150 175 200 1000 0 15 30 45 60 75 90 105 120 135 Evol. coûts d'une livraison de version Chaîne de compilation et déploiement, par modalité Intégré (mensuelle) Intégré (horaire) Parallèle (mensuelle) Parallèle (horaire) Nbre de déploiements prévus / mois en € HT 1h x 24 x 30 = 720h ; hors 44,56 € si location horaire (au lieu de 22 € en location mensuelle) => pousse à la location mensuelle