DevOps n’est pas un outil, c’est une réaction en chaîne

OK. Commençons. Cet article est destiné à donner à un débutant une introduction à certains des composants clés de DevOps et à la façon dont ils s'intègrent dans le processus de développement moderne. Il y a d'innombrables articles Web décrivant le même sujet, et je n'ai pas l'intention de fournir quelque chose de révolutionnaire ici. Au lieu de cela, je veux me concentrer sur les principaux signaux - ce qui se distingue comme important - afin que les éléments essentiels passent clairement au milieu de tout le bruit. +------------------------------------------------+ | THE DEVOPS PROCESS FLOW | +==================+=============================+ | STAGE | KEY ACTION | +==================+=============================+ | 1. Code | Write and commit changes | +------------------+-----------------------------+ | 2. Build | Compile and package code | +------------------+-----------------------------+ | 3. Test | Run automated tests | +------------------+-----------------------------+ | 4. Deploy | Release to production | +------------------+-----------------------------+ | 5. Feedback | Monitor and inform new code | +------------------+-----------------------------+ | (Repeat) | The loop continues... | +------------------+-----------------------------+ Diagramme 1 : Flux de processus de DevOps Diagramme 1 : Flux de processus de DevOps +======================================================+ | Process Transformation: DevOps | +======================+===============================+ | STAGE | MANUAL (BEFORE) | +======================+===============================+ | Code Integration | Manual merges, "merge hell" | | Build | Run on local machine | | Test | Manual testing, slow | | Deploy | Manual scripts, risky | |----------------------+-------------------------------| | **Result** | Slow, Error-Prone, Stressful | +======================+===============================+ | STAGE | AUTOMATED (AFTER) | +======================+===============================+ | Code Integration | Auto-merge via CI server | | Build | Automated build on push | | Test | Automated tests run in pipe | | Deploy | Automated CD to production | |----------------------+-------------------------------| | **Result** | Fast, Reliable, Repeatable | +======================+===============================+ Tableau 2 : Les avantages de DevOps Tableau 2 : Les avantages de DevOps Du développement simple à la réalité complexe Lorsque nous pensons au développement, nous l’imaginons généralement en termes très simples. Un programmeur écrit le code, et cela est mis en œuvre sur le site Web. Mais en pratique, le processus peut se compliquer considérablement en une courte période de temps. Plusieurs programmeurs pourraient travailler sur la même base de code. Les changements de code effectués par une personne peuvent affecter ce que l’autre a déjà construit. Il est important de suivre qui a changé ce qui et quand, de sorte qu’il soit plus facile de revenir si quelque chose va mal. C’est là qu’intervient un système de gestion du code source comme Git – il suit chaque changement, chaque version, et permet à plusieurs développeurs de collaborer efficacement et en toute simplicité. ╔═══════════════════════════════════════════════════╗ ║ THE ILLUSION VS REALITY OF DEVELOPMENT ║ ╚═══════════════════════════════════════════════════╝ WHAT WE IMAGINE WHAT ACTUALLY HAPPENS ┌──────────────┐ ┌──────────────┐ │ Programmer │ │ Programmer A │ └──────┬───────┘ └──────┬───────┘ │ │ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ Code │ │ Code v1 │◄─┐ └──────┬───────┘ └──────────────┘ │ │ │ │ ▼ │ CONFLICT! ┌──────────────┐ │ │ │ Website │ ▼ │ └──────────────┘ ┌──────────────┐ │ │ Code v2 │──┘ SIMPLE └──────────────┘ ▲ │ ┌──────┴───────┐ │ Programmer B │ └──────────────┘ COMPLEX Diagramme 3: Explique la réalité du développement logiciel Diagramme 3: Explique la réalité du développement logiciel ╔═════════════════════════════════════════════╗ ║ THE CHANGE TRACKING CHALLENGE ║ ╚═════════════════════════════════════════════╝ BEFORE GIT (CHAOS) Week 1 Week 2 Week 3 │ │ │ ▼ ▼ ▼ Change Change Something Made Made Broke! │ │ │ └───────────┴───────────┘ │ ▼ ┌───────────────┐ │ Who did it? │ │ When? │ │ Why? │ │ How to undo? │ └───────────────┘ │ ▼ [ MYSTERY ] NEED: TRACKING SYSTEM Diagramme 4: Développement de logiciels sans Git (système de contrôle de version) Diagramme 4: Développement de logiciels sans Git (système de contrôle de version) ╔════════════════════════════════════════════════╗ ║ GIT: THE SOLUTION TO CHAOS ║ ╚════════════════════════════════════════════════╝ ┌─────────────┐ │ GIT │ │ REPOSITORY │ └──────┬──────┘ │ ┌──────────────┼──────────────┐ │ │ │ ▼ ▼ ▼ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ Dev A │ │ Dev B │ │ Dev C │ │ Branch │ │ Branch │ │ Branch │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ │ ┌─────────┼─────────┐ │ │ │ │ │ │ └────┼─────────┴─────────┼────┘ │ │ ▼ ▼ [ MERGE ] [ TRACKED ] │ │ └─────────┬─────────┘ ▼ ┌───────────┐ │ NO CHAOS! │ └───────────┘ Diagramme 5 : Développement de logiciels avec Git (système de contrôle de version) Diagramme 5 : Développement de logiciels avec Git (système de contrôle de version) ╔═══════════════════════════════════════════════╗ ║ THE ROLLBACK SAFETY NET CONCEPT ║ ╚═══════════════════════════════════════════════╝ WITHOUT GIT Past ──────────────► Present │ ▼ ┌────────┐ │ BROKEN │ └────────┘ │ ▼ [ NO WAY BACK ] WITH GIT ┌────┐ ┌────┐ ┌────┐ ┌────┐ │ v1 │───►│ v2 │───►│ v3 │───►│ v4 │ └────┘ └────┘ └────┘ └────┘ ▲ │ │ │ │ SOMETHING BROKE │ │ ▼ │ │ ┌────────┐ │ │ │ROLLBACK│ │ └─────────┤ TO v1 │◄──────────┘ └────────┘ SAFETY GUARANTEED Diagramme 6 : le concept de rollback dans Git Diagramme 6 : le concept de rollback dans Git Problème de déploiement manuel Une fois que le code est sécurisé dans Git, vous devez toujours le mettre sur un serveur. Plus tôt, dans les premiers jours, quelqu'un pourrait tirer ce code manuellement, exécuter quelques tests sur sa propre machine, l'emballer et le déployer à la production. Cela fonctionne si vous déployez moins souvent. Les erreurs échappent - de manquer une étape de test à déployer dans le mauvais environnement. +===================================================+ | The Manual Bottleneck Effect | +===================================================+ LOW SCALE (1x/Month) -------------------- [Commit] ---> ( 👤 ) ---> [Deploy OK] (No pressure) HIGH SCALE (10x/Week) --------------------- [Commit] --\ [Commit] -- \ [Commit] --- > ( 👤 ) --- > [ERROR] [Commit] -- / (Pressure) [CONFLICT] [Commit] --/ (Overwhelmed) [FAILURE] CONCLUSION: A human 👤 cannot process high volume. SOLUTION: Need an automated CI/CD pipeline. Diagramme 7 : Déploiement manuel Diagramme 7 : Déploiement manuel Automatiser le processus de construction et de test Un pipeline CI/CD automatise les étapes entre l'écriture du code et son déploiement dans la production.Lorsque le code est poussé dans le dépôt, le pipeline prend le contrôle.Il emballe le code dans une construction, puis exécute des tests automatisés - tests unitaires pour vérifier les fonctions individuelles, tests d'intégration pour s'assurer que les différentes parties travaillent ensemble, scans de sécurité pour les vulnérabilités et tests de performance pour vérifier la santé globale. Tout cela se passe sans que personne n’ait besoin de se souvenir de chaque tâche, et plus d’attention peut être accordée au développement de fonctionnalités plus récentes. ╔═══════════════════════════════════════════════╗ ║ THE CI/CD PIPELINE ANATOMY ║ ╚═══════════════════════════════════════════════╝ ┌─────────────┐ │ CODE PUSHED │ │ TO REPO │ └──────┬──────┘ │ ▼ ╔══════════════════════╗ ║ CI/CD PIPELINE ║ ║ ║ ║ ┌────────────────┐ ║ ║ │ 1. PACKAGE │ ║ ║ │ (Build) │ ║ ║ └────────┬───────┘ ║ ║ │ ║ ║ ┌────────▼───────┐ ║ ║ │ 2. TEST │ ║ ║ │ - Unit │ ║ ║ │ - Integration│ ║ ║ │ - Security │ ║ ║ │ - Performance│ ║ ║ └────────┬───────┘ ║ ║ │ ║ ║ ┌────────▼───────┐ ║ ║ │ 3. DEPLOY │ ║ ║ │ Test/Dev Env │ ║ ║ └────────┬───────┘ ║ ║ │ ║ ║ ┌────────▼───────┐ ║ ║ │ 4. DEPLOY │ ║ ║ │ Production │ ║ ║ └────────────────┘ ║ ╚══════════════════════╝ Diagramme 8 : pipeline CI/CD Diagramme 8 : pipeline CI/CD ╔═════════════════════════════════════════════╗ ║ THE CI/CD AUTOMATION ENGINE ║ ╚═════════════════════════════════════════════╝ DEVELOPER CI/CD DOES ALL: │ │ ┌──────────┐ │ │ Package │ ▼ └────┬─────┘ ┌────────────┐ │ │ PUSH CODE │ │ └────────────┘ ▼ │ ┌──────────┐ │ │Unit Test │ │ └────┬─────┘ │ │ │ ▼ Developer's ┌──────────┐ Job Done! │Integrate │ │ │ Test │ │ └────┬─────┘ │ │ ▼ ▼ ┌────────────┐ ┌──────────┐ │ FOCUS ON │ │ Security │ │ NEXT │ │ Scan │ │ FEATURE │ └────┬─────┘ └────────────┘ │ ▼ ┌──────────┐ │Performnce│ │ Test │ └────┬─────┘ │ ▼ ┌──────────┐ │ Deploy │ └──────────┘ Diagramme 9 : Amélioration de l’efficacité du développeur Diagramme 9 : Amélioration de l’efficacité du développeur Si tout se passe bien, le build va dans un environnement de test ou de développement, où le nouveau code est testé aux côtés de ce qui est déjà en production.Quand les choses semblent bonnes, il est déployé en direct.Jenkins, GitHub Actions, Azure DevOps et Harness sont quelques exemples d'outils CI/CD populaires. ╔═══════════════════════════════════════════════╗ ║ THE ENVIRONMENT PROMOTION LADDER ║ ╚═══════════════════════════════════════════════╝ ┌──────────────┐ │ CODE PUSHED │ └──────┬───────┘ │ ▼ ┌──────────────┐ │ CI/CD RUNS │ │ TESTS │ └──────┬───────┘ │ TESTS PASS │ ▼ ╔════════════════════════╗ ║ TEST/DEV ENVIRON ║ ◄── Try Here First ║ ║ ║ New Code + Old Code ║ ║ Working Together? ║ ╚════════════╤═══════════╝ │ LOOKS GOOD │ ▼ ╔════════════════════════╗ ║ PRODUCTION ENVIRON ║ ◄── Deploy Live ║ ║ ║ Users Get Update ║ ╚════════════════════════╝ SAFE PROGRESSION TEST → PRODUCTION Diagramme 10 : Environnement de test/dév à environnement de production Diagramme 10 : Environnement de test/dév à environnement de production Le problème de la cohérence environnementale Après avoir progressé jusqu'ici, nous rencontrerons naturellement un inconvénient supplémentaire: Parfois, le code fonctionne sur l'ordinateur portable d'un développeur, mais s'effondre dans la production parce que les environnements sous-jacents sont différents.La façon dont une pièce de logiciel interagit avec son système d'exploitation, des bibliothèques ou des versions spécifiques de dépendances peut facilement changer d'une machine à l'autre. ╔═══════════════════════════════════════════════╗ ║ "IT WORKS ON MY MACHINE" SYNDROME ║ ╚═══════════════════════════════════════════════╝ DEVELOPER'S LAPTOP PRODUCTION SERVER ┌──────────┐ ┌──────────┐ │ CODE │ │ CODE │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Python │ │ Python │ │ 3.9 │ │ 3.7 │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Library │ │ Library │ │ v2.0 │ │ v1.5 │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ OS │ │ OS │ │ Ubuntu22 │ │ Ubuntu20 │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ [ ✓ WORKS ] [ ✗ CRASHES ] THE ENVIRONMENT MISMATCH PROBLEM Diagramme 11 : Le problème de la non-conformité environnementale Diagramme 11 : Le problème de la non-conformité environnementale ╔═══════════════════════════════════════════════╗ ║ THE ISOLATION LAYER VISUALIZATION ║ ╚═══════════════════════════════════════════════╝ WITHOUT CONTAINERS ┌───────────────────────────┐ │ Operating System │ │ │ │ App1 App2 App3 App4 │ │ │ │ │ │ │ │ └─────┴─────┴─────┘ │ │ │ │ │ Shared Resources │ │ (Conflicts!) │ └───────────────────────────┘ WITH CONTAINERS ┌───────────────────────────┐ │ Operating System │ ├───────────────────────────┤ │ ╔═══╗ ╔═══╗ ╔═══╗ ╔═══╗ │ │ ║App║ ║App║ ║App║ ║App║ │ │ ║ 1 ║ ║ 2 ║ ║ 3 ║ ║ 4 ║ │ │ ╚═══╝ ╚═══╝ ╚═══╝ ╚═══╝ │ │ │ │ Each Isolated & Protected │ └───────────────────────────┘ Tableau 12 : Les avantages de l’isolation Tableau 12 : Les avantages de l’isolation C'est pourquoi les conteneurs ont été introduits. Un conteneur agit comme un petit paquet: il emballe tout ce dont une application a besoin - son code, son temps d'exécution, ses outils système, ses bibliothèques - de sorte qu'il puisse fonctionner de la même manière quel que soit l'endroit où il est déployé. Parmi les différentes technologies de conteneurs, Docker est l'une des plus populaires. Docker facilite la création, le déploiement, le test et la gestion des conteneurs. En conséquence, votre application fonctionne de la même manière partout - des machines locales aux serveurs de production. ╔══════════════════════════════════════════════╗ ║ THE DEPENDENCY ISOLATION SHIELD ║ ╚══════════════════════════════════════════════╝ HOST MACHINE (ANY OS) ┌────────────────────────────────────┐ │ │ │ ╔═══════════════════════════════╗ │ │ ║ CONTAINER SHIELD ║ │ │ ║ ║ │ │ ║ ┌─────────────────────────┐ ║ │ │ ║ │ YOUR APPLICATION │ ║ │ │ ║ │ │ ║ │ │ ║ │ • Code │ ║ │ │ ║ │ • Runtime │ ║ │ │ ║ │ • System Tools │ ║ │ │ ║ │ • Libraries │ ║ │ │ ║ │ • Dependencies │ ║ │ │ ║ │ │ ║ │ │ ║ └─────────────────────────┘ ║ │ │ ║ ║ │ │ ║ ISOLATED FROM HOST ║ │ │ ╚═══════════════════════════════╝ │ │ │ │ Host Changes Don't Affect App! │ └────────────────────────────────────┘ Chapitre 13 : Containers Chapitre 13 : Containers ╔═══════════════════════════════════════════════╗ ║ FROM LOCAL DEVELOPMENT TO PRODUCTION ║ ╚═══════════════════════════════════════════════╝ SINGLE CONTAINER ╔═════════════╗ ║ Docker ║ ║ Container ║ ╚══════╤══════╝ │ │ DEPLOY JOURNEY │ │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ LOCAL │ │ STAGING │ │ PROD │ │ DEV │ │ SERVER │ │ SERVER │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ ▼ ▼ ▼ [IDENTICAL] [IDENTICAL] [IDENTICAL] NO CONFIGURATION DRIFT! NO ENVIRONMENT SURPRISES! PREDICTABLE DEPLOYMENTS! Diagramme 14 : Les applications dans les conteneurs Docker fonctionnent de manière identique dans tous les environnements Diagramme 14 : Les applications dans les conteneurs Docker fonctionnent de manière identique dans tous les environnements Le défi de l’orchestre Docker est parfait pour l'emballage d'applications de manière constante, mais lorsque vous avez beaucoup de conteneurs en production pour des choses comme des serveurs Web, des bases de données, des caches et des microservices, la gestion manuelle ne peut pas suivre.Si un conteneur s'arrête, le trafic doit être redirigé, l'échelle est nécessaire avec la demande changeante et les connexions réseau deviennent complexes. ╔═════════════════════════════════════════════╗ ║ THE ORCHESTRATION REQUIREMENT ║ ╚═════════════════════════════════════════════╝ PRODUCTION REALITY Web Server Database Cache APIs Containers Containers Containers Containers │ │ │ │ ▼ ▼ ▼ ▼ ┌────┐┌────┐ ┌────┐┌────┐ ┌────┐ ┌────┐ │ W1 ││ W2 │ │ D1 ││ D2 │ │ C1 │ │ A1 │ └────┘└────┘ └────┘└────┘ └────┘ └────┘ ┌────┐┌────┐ ┌────┐ │ W3 ││ W4 │ │ A2 │ └────┘└────┘ └────┘ MANUAL QUESTIONS: • Which container crashed? • How to reroute traffic? • When to scale up/down? • How to connect them? ▼ NEED ORCHESTRATOR ▼ KUBERNETES! Diagramme 15: Besoin d'orchestration de conteneurs Diagramme 15: Besoin d'orchestration de conteneurs Kubernetes est une couche d'orchestration en haut de Docker. Il gère automatiquement les conteneurs - redémarrez ceux qui ont échoué, agrandissez ou abaissez, équilibrez le trafic et reliez les conteneurs. Docker gère la containerisation; Kubernetes gère l'orchestration sur votre infrastructure, que ce soit dans le cloud (AWS, Azure, Google Cloud) ou sur site. ╔═════════════════════════════════════════════╗ ║ THE AUTOMATIC MANAGEMENT LOOP ║ ╚═════════════════════════════════════════════╝ ╔═══════════════════════╗ ║ KUBERNETES ║ ║ CONTROL PLANE ║ ╚═════════╤═════════════╝ │ Constantly Monitors │ ┌─────────────┼─────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │Container │ │Container │ │Container │ │ A │ │ B │ │ C │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └─────────────┼─────────────┘ │ Reports Status │ ▼ ╔═══════════════════╗ ║ AUTO ACTIONS: ║ ║ • Restart ║ ║ • Scale ║ ║ • Balance ║ ║ • Link ║ ╚═══════════════════╝ CONTINUOUS AUTOMATION Chapitre 16 : Gestion automatique Chapitre 16 : Gestion automatique ╔══════════════════════════════════════════════╗ ║ THE FAILED CONTAINER AUTO-RECOVERY ║ ╚══════════════════════════════════════════════╝ TIME LINE t=0 t=1 t=2 t=3 │ │ │ │ ▼ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌────────┐ ┌─────────┐ │Running │ │Crashed!│ │Detected│ │Restarted│ └────────┘ └───╳────┘ └────────┘ └─────────┘ │ │ │ │ ▼ │ │ ╔═══════════════╗ │ │ ║ KUBERNETES ║ │ └───►║ Monitors ║ │ ║ & Acts ║───┘ ╚═══════════════╝ AUTOMATIC HEALING NO MANUAL INTERVENTION Chapitre 17 : Récupération automatique Chapitre 17 : Récupération automatique ╔═══════════════════════════════════════════════╗ ║ THE SCALING AUTOMATION ENGINE ║ ╚═══════════════════════════════════════════════╝ ╔═══════════════════════╗ ║ KUBERNETES ║ ║ Watches Metrics ║ ╚═══════╤═══════════════╝ │ ┌───────────┴───────────┐ │ │ LOW DEMAND HIGH DEMAND │ │ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Scale │ │ Scale │ │ DOWN │ │ UP │ └────┬─────┘ └────┬─────┘ │ │ ▼ ▼ ┌────┐ ┌────┐┌────┐ │ C1 │ │ C1 ││ C2 │ └────┘ └────┘└────┘ ┌────┐┌────┐ 1 Container │ C3 ││ C4 │ Enough └────┘└────┘ 4 Containers Needed ELASTIC SCALING Chapitre 18 : L’élasticité Chapitre 18 : L’élasticité ╔═════════════════════════════════════════════╗ ║ THE TRAFFIC BALANCING MECHANISM ║ ╚═════════════════════════════════════════════╝ USER TRAFFIC │ │ ▼ ╔═══════════════╗ ║ KUBERNETES ║ ║ LOAD ║ ║ BALANCER ║ ╚═══════╤═══════╝ │ ┌───────────┼───────────┐ │ │ │ 33%│ 33%│ 33%│ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │Container │ │Container │ │Container │ │ 1 │ │ 2 │ │ 3 │ └──────────┘ └──────────┘ └──────────┘ EVEN DISTRIBUTION OPTIMIZED ROUTING NO OVERLOAD Diagramme 19 : Balance de charge Diagramme 19 : Balance de charge ╔══════════════════════════════════════════════╗ ║ THE CONTAINER LINKING SYSTEM ║ ╚══════════════════════════════════════════════╝ ╔═══════════════════════╗ ║ KUBERNETES ║ ║ Service Mesh ║ ╚═══════╤═══════════════╝ │ Auto-Links │ ┌───────────┼───────────┐ │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ WEB │◄─┤ API │◄─┤DATABASE │ │ SERVER │ │ SERVICE │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ └───────────┼───────────┘ │ ┌─────▼─────┐ │ CACHE │ └───────────┘ AUTOMATIC SERVICE DISCOVERY DYNAMIC CONNECTIONS Diagramme 20 : Liaison des conteneurs Diagramme 20 : Liaison des conteneurs ╔═════════════════════════════════════════════╗ ║ THE DIVISION OF RESPONSIBILITIES ║ ╚═════════════════════════════════════════════╝ DOCKER'S JOB KUBERNETES' JOB ┌─────────────┐ ┌─────────────┐ │ CREATE │ │ DEPLOY │ │ Containers │ │ Where? │ └──────┬──────┘ └──────┬──────┘ │ │ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ PACKAGE │ │ MONITOR │ │ Application │ │ Health │ └──────┬──────┘ └──────┬──────┘ │ │ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ RUN │ │ SCALE │ │ Containers │ │ Count │ └─────────────┘ └──────┬──────┘ │ ▼ ┌─────────────┐ │ MANAGE │ │ Lifecycle │ └─────────────┘ CONTAINERIZATION ORCHESTRATION Diagramme 21 : Modèle de responsabilité partagée Diagramme 21 : Modèle de responsabilité partagée Regarder ce qui se passe dans la production La tâche n'est pas terminée après le déploiement. Il est essentiel d'observer comment l'application fonctionne réellement dans la production. Est-ce que les erreurs se multiplient? Est-ce que l'application est lente? Les outils de surveillance suivent les mesures telles que l'utilisation de la CPU, l'utilisation de la mémoire, les temps de réponse et les taux d'erreur. L'enregistrement capture ce que l'application fait et les erreurs qui se produisent. Lorsque quelque chose ne va pas, cette infrastructure vous aide à trouver et à résoudre rapidement les problèmes avant que les utilisateurs finaux ne le remarquent. ╔═══════════════════════════════════════════════╗ ║ THE COMPLETE OBSERVABILITY STACK ║ ╚═══════════════════════════════════════════════╝ ┌─────────────────┐ │ APPLICATION │ │ IN PRODUCTION │ └────────┬────────┘ │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │MONITORING│ │ LOGGING │ │ INCIDENT │ │ │ │ │ │ RESPONSE │ │Tracks │ │Captures │ │ │ │Metrics │ │Events │ │Fixes │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └────────────┼────────────┘ │ ▼ ╔═══════════════╗ ║ COMPLETE ║ ║ VISIBILITY ║ ║ ║ ║ Know What's ║ ║ Happening ║ ║ Always ║ ╚═══════════════╝ Diagramme 22: Surveillance, enregistrement et réponse aux incidents Diagramme 22: Surveillance, enregistrement et réponse aux incidents ╔══════════════════════════════════════════════╗ ║ DETECTING ISSUES BEFORE USERS ║ ╚══════════════════════════════════════════════╝ WITHOUT MONITORING Error Occurs ──► User Complains ──► Fix │ │ └───────────────────┘ Hours/Days Later! WITH MONITORING Error Occurs │ ▼ ╔═════════════╗ ║ MONITORING ║ ║ Detects ║ ──► Alerts Team ║ Instantly ║ ╚═════╤═══════╝ │ ▼ Team Fixes Issue │ ▼ Users Never Know! PROACTIVE > REACTIVE Diagramme 23 : Réponse proactive Diagramme 23 : Réponse proactive Ce qu’il faut garder à l’esprit Toute personne souhaitant acquérir plus d'expertise en DevOps devrait également se concentrer sur la compréhension des différents types de tests automatisés qui sont écrits. ╔══════════════════════════════════════════════╗ ║ THINKING THROUGH USE & MISUSE ║ ╚══════════════════════════════════════════════╝ ┌─────────────────┐ │ FEATURE TO │ │ BE TESTED │ └────────┬────────┘ │ Think About: │ ┌────────────┴────────────┐ │ │ ▼ ▼ ┌───────────┐ ┌───────────┐ │ NORMAL │ │ ABNORMAL │ │ USE │ │ USE │ │ │ │ │ │• Expected │ │• Wrong │ │ Inputs │ │ Inputs │ │• Happy │ │• Edge │ │ Path │ │ Cases │ │• Valid │ │• Malicious│ │ Flow │ │ Intent │ └─────┬─────┘ └─────┬─────┘ │ │ └────────────┬────────────┘ │ ▼ [ COMPREHENSIVE TEST COVERAGE ] Diagramme 24 : Examen de la prise en compte Diagramme 24 : Examen de la prise en compte Les compétences en langage de programmation, la connaissance des API, la connaissance du domaine et la prise de conscience des cadres de test aident.Les choix ici devraient fonctionner avec le reste de votre écosystème DevOps - fournisseur de cloud, outil CI / CD, plate-forme d'automatisation. Par exemple, Jenkins (un outil CI / CD) s'intègre avec divers langages, y compris Python et des cadres comme pytest, il est donc essentiel de savoir quels outils fonctionnent bien ensemble. ╔═════════════════════════════════════════════╗ ║ THE DEVOPS ECOSYSTEM COMPATIBILITY ║ ╚═════════════════════════════════════════════╝ ┌─────────────────┐ │ TEST CHOICE │ └────────┬────────┘ │ Must Work With: │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Cloud │ │ CI/CD │ │Automation│ │ Provider │ │ Tool │ │ Platform │ │ │ │ │ │ │ │AWS/Azure │ │ Jenkins │ │ Etc. │ │ /GCP │ │ GitHub │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └────────────┼────────────┘ │ ▼ ╔═══════════════╗ ║ INTEGRATION ║ ║ IS CRITICAL ║ ╚═══════════════╝ Diagramme 25 : compatibilité des écosystèmes Diagramme 25 : compatibilité des écosystèmes Envelopper le C’est un point de départ pour donner un sens à DevOps, reliant les étapes du code et de la collaboration à l’automatisation et à l’infrastructure, au suivi et au feedback. Chaque couche apparaît pour résoudre un problème qui ne pouvait pas être résolu avec le précédent seul. Comme ce paysage continue d’évoluer, remarquer ces transitions clés est ce qui aide à transformer les déploiements compliqués en quelque chose qui fonctionne vraiment. +------------------+ | Source Control | +------------------+ | +------------------+ | CI/CD | +------------------+ | +------------------+ | Containers | +------------------+ | +------------------+ | Orchestration | +------------------+ | +------------------+ | Monitoring | +------------------+ Tableau 26 : Résumé Tableau 26 : Résumé Plus que tout, DevOps est sur la compréhension de la façon dont les morceaux s'intègrent et pourquoi chacun est nécessaire, plutôt que simplement d'apprendre des outils isolés. Si vous avez des questions, s'il vous plaît n'hésitez pas à m'envoyer un e-mail. Vous pouvez également me contacter via LinkedIn. Vous pouvez aussi me suivre sur X. par email par email par Linkedin par Linkedin . X X Vous pouvez lire mon article sur system design . here ici Si vous voulez que j'écris sur un autre sujet, veuillez me le faire savoir dans les commentaires. Lien vers le mien . Profil de hacker