DevOps nie je nástroj, je to reťazová reakcia

Dobre. Poďme začať. Tento článok je určený na to, aby bol začiatočníkom predstavený niektorý z kľúčových komponentov v DevOps a ako sa hodia do moderného vývojového procesu. Existuje nespočetné množstvo webových článkov popisujúcich tú istú tému a nemám v úmysle poskytnúť tu niečo prelomové. Namiesto toho sa chcem sústrediť na hlavné signály - čo je tak dôležité - aby základné veci prešli jasne uprostred všetkého hluku. +------------------------------------------------+ | 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... | +------------------+-----------------------------+ Diagram 1: Procesný tok DevOps Diagram 1: Procesný tok 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 | +======================+===============================+ Diagram 2: Výhody DevOps Diagram 2: Výhody DevOps Od jednoduchého vývoja k komplexnej realite Keď premýšľame o vývoji, zvyčajne si to predstavujeme vo veľmi jednoduchých termínoch. Programátor píše kód a to sa implementuje na webovej stránke. Ale v praxi sa proces môže v krátkom časovom období značne skomplikovať. Viacerí programátori môžu pracovať na tej istej kódovej báze. Zmeny kódu vykonané jednou osobou môžu ovplyvniť to, čo už iná osoba vytvorila. Je dôležité sledovať, kto zmenil čo a kedy, aby bolo ľahšie vrátiť sa späť, ak sa niečo pokazí. To je miesto, kde systém správy zdrojového kódu ako Git prichádza - sleduje každú zmenu, každú verziu a umožňuje viacerým vývojárom spolupracovať efektívne a bezproblémovo. ╔═══════════════════════════════════════════════════╗ ║ 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 Diagram 3: Vysvetľuje realitu vývoja softvéru Diagram 3: Vysvetľuje realitu vývoja softvéru ╔═════════════════════════════════════════════╗ ║ 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 Diagram 4: Vývoj softvéru bez Git (systém riadenia verzií) Diagram 4: Vývoj softvéru bez Git (systém riadenia verzií) ╔════════════════════════════════════════════════╗ ║ GIT: THE SOLUTION TO CHAOS ║ ╚════════════════════════════════════════════════╝ ┌─────────────┐ │ GIT │ │ REPOSITORY │ └──────┬──────┘ │ ┌──────────────┼──────────────┐ │ │ │ ▼ ▼ ▼ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ Dev A │ │ Dev B │ │ Dev C │ │ Branch │ │ Branch │ │ Branch │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ │ ┌─────────┼─────────┐ │ │ │ │ │ │ └────┼─────────┴─────────┼────┘ │ │ ▼ ▼ [ MERGE ] [ TRACKED ] │ │ └─────────┬─────────┘ ▼ ┌───────────┐ │ NO CHAOS! │ └───────────┘ Diagram 5: Vývoj softvéru s Git (systém riadenia verzií) Diagram 5: Vývoj softvéru s Git (systém riadenia verzií) ╔═══════════════════════════════════════════════╗ ║ 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 Diagram 6: Rollback koncept v Git Diagram 6: Rollback koncept v Git Problém manuálneho nasadenia Akonáhle je kód v Gite bezpečný, stále ho musíte dostať na server. Predtým, v prvých dňoch, niekto manuálne vytiahol tento kód, spustil niektoré testy na svojom vlastnom stroji, balíkoval ho a nasadil ho do výroby. Chyby skĺznu - od vynechania testovacieho kroku až po nasadenie do nesprávneho prostredia. +===================================================+ | 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. Diagram 7: Manuálne nasadenie Diagram 7: Manuálne nasadenie Automatizácia stavebného a testovacieho procesu potrubie CI/CD automatizuje kroky medzi písaním kódu a jeho nasadením do výroby.Keď je kód tlačený do úložiska, potrubie preberá.Zbaľuje kód do zostavy, potom spustí automatizované testy - jednotkové testy na kontrolu jednotlivých funkcií, testy integrácie na zabezpečenie spolupráce rôznych častí, bezpečnostné skenovanie zraniteľností a testy výkonu na kontrolu celkového zdravia. To všetko sa deje bez toho, aby si niekto musel pamätať každú úlohu a viac sa dá zamerať na vývoj novších funkcií. ╔═══════════════════════════════════════════════╗ ║ 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 │ ║ ║ └────────────────┘ ║ ╚══════════════════════╝ Diagram 8: potrubie CI / CD Diagram 8: potrubie 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 │ └──────────┘ Diagram 9: Zlepšenie efektívnosti vývojárov Diagram 9: Zlepšenie efektívnosti vývojárov Ak všetko prejde, zostava prechádza do testovacieho alebo vývojového prostredia, kde sa nový kód vyskúša spolu s tým, čo je už vo výrobe. Keď sa veci zdajú dobre, nasadí sa naživo.Jenkins, GitHub Actions, Azure DevOps a Harness sú niektoré príklady populárnych nástrojov CI/CD. ╔═══════════════════════════════════════════════╗ ║ 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 Diagram 10 : Test / Dev prostredie k výrobnému prostrediu Diagram 10 : Test / Dev prostredie k výrobnému prostrediu Problém environmentálnej súdržnosti Po tomto pokroku sa prirodzene stretneme s ďalšou nevýhodou: Niekedy kód funguje na notebooku vývojára, ale výroba zlyhá, pretože základné prostredie je iné.Spôsob, akým softvér interaguje s operačným systémom, knižnicami alebo špecifickými verziami závislostí, sa môže ľahko zmeniť z jedného stroja na druhý. ╔═══════════════════════════════════════════════╗ ║ "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 Diagram 11: Problém environmentálnej nesúladu Diagram 11: Problém environmentálnej nesúladu ╔═══════════════════════════════════════════════╗ ║ 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 │ └───────────────────────────┘ Diagram 12 : Výhody izolácie Diagram 12 : Výhody izolácie To je dôvod, prečo boli zavedené kontajnery. kontajner pôsobí ako malý balík: zahŕňa všetko, čo aplikácia potrebuje - jeho kód, runtime, systémové nástroje, knižnice - takže môže bežať rovnakým spôsobom bez ohľadu na to, kde je nasadená. kontajnery izolujú aplikáciu od základného prostredia, čo robí "funguje na mojom stroji" vecou minulosti. Z rôznych kontajnerových technológií je Docker jednou z najpopulárnejších. Docker uľahčuje vytváranie, nasadenie, testovanie a správu kontajnerov.V dôsledku toho vaša aplikácia beží rovnako všade - od lokálnych strojov až po výrobné servery. ╔══════════════════════════════════════════════╗ ║ 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! │ └────────────────────────────────────┘ Diagram 13: Kontajnerový dizajn Diagram 13: Kontajnerový dizajn ╔═══════════════════════════════════════════════╗ ║ 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! Diagram 14 : Aplikácie v kontajneroch Docker fungujú rovnakým spôsobom vo všetkých prostrediach Diagram 14 : Aplikácie v kontajneroch Docker fungujú rovnakým spôsobom vo všetkých prostrediach Orchestrálna výzva Docker je ideálny pre konzistentné balenie aplikácií, ale keď máte veľa kontajnerov vo výrobe pre veci ako webové servery, databázy, vyrovnávače a mikroslužby, manuálne riadenie nemôže držať krok. ╔═════════════════════════════════════════════╗ ║ 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! Diagram 15: Potreba orchestrácie kontajnerov Diagram 15: Potreba orchestrácie kontajnerov Kubernetes je vrstva orchestrácie na vrchole Dockeru. Automaticky spravuje kontajnery - reštartuje zlyhané kontajnery, rozširuje alebo znižuje ich rozsah, vyvažuje prevádzku a spája kontajnery. Docker zaobchádza s kontajnerizáciou; Kubernetes zaobchádza s orchestráciou v celej infraštruktúre, či už v cloude (AWS, Azure, Google Cloud) alebo na mieste. ╔═════════════════════════════════════════════╗ ║ 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 Diagram 16: Automatické riadenie Diagram 16: Automatické riadenie ╔══════════════════════════════════════════════╗ ║ 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 Diagram 17: Automatické obnovenie Diagram 17: Automatické obnovenie ╔═══════════════════════════════════════════════╗ ║ 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 Diagram 18: Elastické škálovanie Diagram 18: Elastické škálovanie ╔═════════════════════════════════════════════╗ ║ THE TRAFFIC BALANCING MECHANISM ║ ╚═════════════════════════════════════════════╝ USER TRAFFIC │ │ ▼ ╔═══════════════╗ ║ KUBERNETES ║ ║ LOAD ║ ║ BALANCER ║ ╚═══════╤═══════╝ │ ┌───────────┼───────────┐ │ │ │ 33%│ 33%│ 33%│ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │Container │ │Container │ │Container │ │ 1 │ │ 2 │ │ 3 │ └──────────┘ └──────────┘ └──────────┘ EVEN DISTRIBUTION OPTIMIZED ROUTING NO OVERLOAD Diagram 19: vyváženie zaťaženia Diagram 19: vyváženie zaťaženia ╔══════════════════════════════════════════════╗ ║ THE CONTAINER LINKING SYSTEM ║ ╚══════════════════════════════════════════════╝ ╔═══════════════════════╗ ║ KUBERNETES ║ ║ Service Mesh ║ ╚═══════╤═══════════════╝ │ Auto-Links │ ┌───────────┼───────────┐ │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ WEB │◄─┤ API │◄─┤DATABASE │ │ SERVER │ │ SERVICE │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ └───────────┼───────────┘ │ ┌─────▼─────┐ │ CACHE │ └───────────┘ AUTOMATIC SERVICE DISCOVERY DYNAMIC CONNECTIONS Diagram 20: Prepojenie kontajnerov Diagram 20: Prepojenie kontajnerov ╔═════════════════════════════════════════════╗ ║ 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 Diagram 21: Model zdieľanej zodpovednosti Diagram 21: Model zdieľanej zodpovednosti Sledovať, čo sa deje vo výrobe Úloha nie je dokončená po nasadení. Je dôležité sledovať, ako aplikácia skutočne beží vo výrobe. Zvyšujú sa chyby? Je aplikácia pomalá? Monitorovacie nástroje sledujú metriky, ako je využitie CPU, využitie pamäte, časy odozvy a miera chýb. Logovanie zachytáva to, čo aplikácia robí a chyby, ktoré sa vyskytujú. Keď sa niečo pokazí, táto infraštruktúra vám pomôže rýchlo nájsť a opraviť problémy predtým, než koncový používateľ to oznámi. ╔═══════════════════════════════════════════════╗ ║ THE COMPLETE OBSERVABILITY STACK ║ ╚═══════════════════════════════════════════════╝ ┌─────────────────┐ │ APPLICATION │ │ IN PRODUCTION │ └────────┬────────┘ │ ┌────────────┼────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │MONITORING│ │ LOGGING │ │ INCIDENT │ │ │ │ │ │ RESPONSE │ │Tracks │ │Captures │ │ │ │Metrics │ │Events │ │Fixes │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └────────────┼────────────┘ │ ▼ ╔═══════════════╗ ║ COMPLETE ║ ║ VISIBILITY ║ ║ ║ ║ Know What's ║ ║ Happening ║ ║ Always ║ ╚═══════════════╝ Diagram 22: Monitorovanie, logovanie a reakcia na incidenty Diagram 22: Monitorovanie, logovanie a reakcia na incidenty ╔══════════════════════════════════════════════╗ ║ 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 Diagram 23: Proaktívna reakcia Diagram 23: Proaktívna reakcia Čo treba mať na pamäti Každý, kto chce získať viac odbornosti v DevOps, by sa mal tiež zamerať na pochopenie rôznych typov automatizovaných testov, ktoré sú napísané.Písanie silných automatizovaných testov závisí od toho, čo sa vyvíja a premýšľať o tom, ako by sa mohlo použiť alebo zneužiť. ╔══════════════════════════════════════════════╗ ║ 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 ] Diagram 24: Preskúmanie Diagram 24: Preskúmanie Programovacie jazykové zručnosti, znalosť API, doménové znalosti a povedomie o testovacích rámcoch pomáhajú.Výbery tu by mali fungovať so zvyškom ekosystému DevOps - poskytovateľom cloudu, nástrojom CI / CD, automatizačnou platformou. Napríklad Jenkins (nástroj CI / CD) sa integruje s rôznymi jazykmi, vrátane Pythonu a rámcov ako pytest, takže je dôležité vedieť, ktoré nástroje fungujú dobre spolu. ╔═════════════════════════════════════════════╗ ║ 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 ║ ╚═══════════════╝ Diagram 25: Zlučiteľnosť ekosystémov Diagram 25: Zlučiteľnosť ekosystémov Obalenie hore Toto je východiskový bod pre zmysel DevOps, prepojenie krokov od kódu a spolupráce k automatizácii a infraštruktúre k monitorovaniu a spätnej väzbe.Každá vrstva sa objaví na riešenie problému, ktorý nemohol byť vyriešený len s predchádzajúcim.Keďže táto krajina sa neustále vyvíja, všimnutie si týchto kľúčových prechodov pomáha premeniť zložité nasadenia na niečo, čo skutočne funguje. +------------------+ | Source Control | +------------------+ | +------------------+ | CI/CD | +------------------+ | +------------------+ | Containers | +------------------+ | +------------------+ | Orchestration | +------------------+ | +------------------+ | Monitoring | +------------------+ Diagram 26: Zhrnutie Diagram 26: Zhrnutie Viac ako čokoľvek iné, DevOps je o pochopení toho, ako sa kusy hodia dohromady a prečo je každý potrebný, skôr než len učiť sa nástroje v izolácii. Ak máte akékoľvek otázky, prosím, neváhajte mi poslať e-mail. Môžete ma kontaktovať aj cez LinkedIn. Môžete ma tiež sledovať na X. e-mailom e-mailom Linkedin → Linkedin → . X X Môžete si prečítať môj článok na system design . here tu Ak chcete, aby som napísal o akejkoľvek inej téme, dajte mi vedieť v komentároch. Link na môj . Profil hackerov