76. Závěrečný projekt: návrh kompletní DevOps platformy pro fiktivní firmu

Úvod a kontext

Tato lekce je závěrečným projektem celé sekce DevOps. Cílem není
zopakovat, co bylo probráno v modulech 1–14, ale ukázat, jak se
jednotlivé kusy — Linux, sítě, Git, skriptování, webové servery,
databáze, Docker, Kubernetes, CI/CD, Infrastructure as Code, cloud,
monitoring, bezpečnost a SRE praxe — spojí do jednoho konzistentního
návrhu reálné platformy. Místo abstraktního výčtu volíme konkrétní
zadání: fiktivní rostoucí e-shop ShopFast s.r.o., pro který
navrhneme architekturu, konkrétní infrastrukturní artefakty a
provozní procesy. Zadání a návrh záměrně kombinují rozhodnutí z
většiny předchozích modulů — to je smyslem kapitolového projektu.

Teorie

Jak přistupovat k návrhu celé platformy

Návrh kompletní platformy se neliší principem od jednotlivých
architektonických rozhodnutí probraných v modulu 15 — jen je
potřeba je udělat všechny najednou a konzistentně. Osvědčený postup:

1. Nejprve požadavky, ne nástroje. Než se vybere Kubernetes
   nebo Terraform, je potřeba znát konkrétní čísla (očekávaná
   zátěž, rozpočet, velikost týmu) a závazné požadavky (dostupnost,
   compliance) — volba nástroje je až důsledek, ne výchozí bod
   (stejný princip jako u hodnocení nástrojů v předminulé lekci).
2. Návrh po vrstvách, s vazbami mezi nimi. Praktické je projít
   platformu vrstva po vrstvě zdola nahoru — zdrojový kód a
   verzování, infrastruktura, kontejnery/orchestrace, síť, CI/CD,
   pozorovatelnost a bezpečnost, provozní procesy — a u každé
   vrstvy explicitně ukázat, jak splňuje požadavek z kroku 1 a jak
   navazuje na sousední vrstvy (např. jak CI/CD pipeline pracuje
   s obrazy z vrstvy kontejnerů).
3. Explicitní dohledatelnost požadavku v návrhu. Každý tvrdý
   požadavek zadání (SLO, rozpočet, zero-downtime nasazení) by měl
   jít v návrhu ukázat na konkrétní rozhodnutí, které ho řeší — návrh
   bez této vazby je jen katalog technologií, ne architektura.
4. Kompromisy zapsané, ne mlčky předpokládané. Stejně jako u
   ADR (předchozí modul), i celková platforma staví na kompromisech
   (např. cena vs. redundance) — dobrý návrh je zapisuje výslovně,
   aby je bylo možné později přehodnotit s vědomím původního
   zdůvodnění.

Zbytek lekce aplikuje tento postup na konkrétní zadání.

Zadání

ShopFast s.r.o. provozuje e-shop s oblečením. Aktuální stav a
požadavky:

• Dnes: 40 000 objednávek měsíčně, jedna aplikace (monolitický
  Django backend + React frontend), běží na dvou ručně
  spravovaných VPS bez automatizovaného nasazení.
• Plán: expanze do dalších dvou zemí během roku, očekávaný
  desetinásobný nárůst provozu do dvou let, plus sezónní špičky
  (Black Friday) s 8× normální zátěží po dobu několika dnů.
• Tým: 6 vývojářů/inženýrů, žádný dedikovaný 24/7 provozní tým —
  on-call na bázi rotace mezi senior inženýry (modul 14).
• Požadavky: vysoká dostupnost (cíl 99.9 % dle SLO, modul 14),
  soulad s GDPR (osobní údaje zákazníků, platby přes externí
  platební bránu), rozpočtové omezení — cloud účet musí být pod
  kontrolou nákladů (modul 11), ne neomezeně škálovaný.
• Explicitní požadavek vedení firmy: nový systém musí jít nasadit
  bez odstávky (zero-downtime deploy) a musí umožnit rychlý
  rollback, protože předchozí ruční nasazení už jednou způsobilo
  několikahodinový výpadek.

Praktický příklad: cílová architektura ShopFast

Zdrojový kód a verzování (Git, modul 3)

Monorepo se třemi hlavními adresáři (backend/, frontend/,
infra/), trunk-based vývoj (modul 3, lekce 14) s krátkověkými
feature branchemi a povinným code review přes pull request. Změny
infrastruktury (Terraform/Ansible kód) procházejí stejným review
procesem jako aplikační kód — docs as code i infra as code žijí ve
stejném repozitáři (viz předchozí lekce o dokumentaci).

Infrastruktura jako kód (Terraform, modul 10)

Terraform spravuje celou cloudovou infrastrukturu na AWS (modul 11)
rozdělený na moduly a tři prostředí (dev/staging/produkce) se
samostatným state souborem pro každé:

infra/
  modules/
    network/      # VPC, subnety, security groups
    eks/          # EKS cluster, node groups
    rds/          # PostgreSQL primary + read replica
    s3/           # statické soubory, zálohy
  environments/
    dev/main.tf
    staging/main.tf
    production/main.tf

Klíčové AWS zdroje (modul 11): VPC se třemi veřejnými a třemi
privátními subnety napříč dvěma availability zónami (vysoká
dostupnost proti výpadku jedné zóny), EKS cluster pro Kubernetes
workloady v privátních subnetech, RDS PostgreSQL (modul 6) s jednou
read replikou pro čtecí zátěž a automatizovanými zálohami, S3 pro
statický obsah a úložiště záloh, IAM role s principem nejmenších
oprávnění (modul 13) pro každou službu zvlášť.

Konfigurace serverů mimo Kubernetes (bastion host pro nouzový SSH
přístup, modul 2) se spravuje Ansible playbookem (modul 10) —
idempotentně, verzovaně, spouštěno automaticky při změně v Gitu.

Kontejnerizace a orchestrace (Docker, Kubernetes, moduly 7–8)

Backend i frontend běží jako Docker image (modul 7) postavené podle
zásad z lekce 31 (minimální base image, multi-stage build, neroot
uživatel) a uložené v privátním registru (AWS ECR). V Kubernetes
(EKS) běží jako:

• Deployment pro backend, 3 repliky minimálně, HorizontalPodAutoscaler
  (modul 8) škálující podle CPU a počtu požadavků ve frontě až na
  20 replik pro pokrytí Black Friday špičky.
• Deployment pro frontend (statický build servírovaný přes
  Nginx, viz níže), 2 repliky.
• ConfigMap pro neutajovanou konfiguraci (feature flags,
  URL externích služeb) a Secret pro přístupové údaje k databázi
  a platební bráně (modul 8), synchronizované z centrálního Vaultu
  (modul 13).
• Readiness a liveness probes (modul 8) na obou deploymentech,
  aby Kubernetes automaticky vyřadil nezdravý pod z provozu dřív,
  než ho uvidí zákazník.

Síť a vstupní bod (Nginx, modul 5)

Nginx Ingress Controller v clusteru terminuje TLS (certifikát z
Let's Encrypt, modul 2) a směruje provoz na příslušné Service podle
domény a cesty; před ním stojí AWS Application Load Balancer (modul
11) rozkládající provoz mezi uzly clusteru. Statický obsah (obrázky
produktů) se servíruje přímo z S3 přes CDN, ne přes aplikační pody,
což snižuje zátěž backendu při špičce.

CI/CD pipeline (moduly 9)

GitHub Actions pipeline (modul 9) se spouští na každý pull request
a na merge do hlavní větve:

name: deploy
on:
  push:
    branches: [main]
jobs:
  test:
    steps:
      - run: pytest backend/            # automatizované testy, modul 9
      - run: npm test --prefix frontend/
  security-scan:
    needs: test
    steps:
      - run: trivy image shopfast-backend:${{ github.sha }}   # modul 13
  build-and-push:
    needs: security-scan
    steps:
      - run: docker build -t $ECR_REPO:${{ github.sha }} backend/
      - run: docker push $ECR_REPO:${{ github.sha }}
  deploy:
    needs: build-and-push
    steps:
      - run: kubectl set image deployment/backend backend=$ECR_REPO:${{ github.sha }}
      - run: kubectl rollout status deployment/backend --timeout=120s

Nasazení používá rolling update strategii (modul 9) se
schopností okamžitého rollbacku (kubectl rollout undo) — to přímo
splňuje požadavek vedení firmy na zero-downtime deploy s rychlým
rollbackem. Pro rizikovější změny (např. změna databázového
schématu) se používá opatrnější blue-green přístup se dvěma
paralelními sadami podů a přepnutím trafficu až po ověření.

Monitoring, logování a bezpečnost (moduly 12–13)

Prometheus sbírá metriky z clusteru i aplikace, Grafana zobrazuje
dashboardy pro klíčové SLI (modul 14) — chybovost, latenci, dostupnost
plateb. Alerty (modul 12) jsou navázané na konkrétní SLO, ne na
syrové prahové hodnoty, aby se předešlo alert fatigue. Logy ze všech
podů se centralizují (Loki nebo EFK stack, modul 12) s retencí
odpovídající GDPR požadavkům. Bezpečnostní skenování (Trivy v
pipeline výše) kontroluje image i závislosti při každém sestavení
(modul 13); tajemství (databázová hesla, API klíče platební brány)
jsou uložená ve Vaultu, ne v Gitu ani v Kubernetes Secrets napřímo
(ty jen zrcadlí hodnoty z Vaultu).

Provozní procesy (modul 14)

SLO 99.9 % dostupnosti dává error budget přibližně 43 minut výpadku
měsíčně (modul 14) — pokud se budget vyčerpá, nová funkční nasazení
se pozastaví ve prospěch stability. On-call rotace mezi čtyřmi senior
inženýry (modul 14) s runbooky pro nejčastější incidenty (výpadek
databáze, vyčerpaná kapacita podů, selhání platební brány), psanými
jako docs as code (předchozí lekce) a testovanými čtvrtletně. Po
každém závažném incidentu následuje bezvinný postmortem (modul 14).

Kapacitní plánování a technology radar (poslední dvě lekce)

Před sezónní špičkou (Black Friday) tým provede zátěžový test na
staging prostředí odpovídající 8× běžné zátěži a podle výsledku
navýší maxReplicas u HPA a kapacitní limit RDS read repliky
předem — ne reaktivně během špičky samotné (předchozí lekce o
kapacitním plánování). Nové nástroje (např. zvažovaný přechod z
Jenkins na GitHub Actions v této architektuře) prošly procesem
technology radaru popsaným v lekci o hodnocení nástrojů, včetně
časově ohraničeného pilotu na staging prostředí.

Shrnutí

Návrh platformy pro ShopFast spojuje rozhodnutí ze všech modulů
kurzu do jednoho konzistentního celku: Git a trunk-based vývoj jako
základ spolupráce, Terraform a Ansible pro reprodukovatelnou
infrastrukturu na AWS, Docker a Kubernetes pro škálovatelné
nasazení aplikace, Nginx a load balancer jako vstupní bod, CI/CD
pipeline s automatizovanými testy, bezpečnostním skenováním a
rolling/blue-green nasazením bez odstávky, Prometheus/Grafana a
centralizované logování pro pozorovatelnost, Vault pro tajemství, a
SRE procesy (SLO, error budget, on-call, postmortem) pro provozní
disciplínu. Klíčové poučení kapitolového projektu je, že žádná
jednotlivá technologie sama o sobě nedělá platformu spolehlivou —
teprve jejich promyšlené propojení kolem konkrétních obchodních
požadavků (dostupnost, náklady, rychlost nasazení) tvoří skutečnou
DevOps platformu.

Kontrolní otázky / mini projekt

1. Který konkrétní požadavek zadání (zero-downtime nasazení s
   rychlým rollbackem) je v návrhu řešen kterou konkrétní kombinací
   technologií, a proč samotný Kubernetes rolling update tento
   požadavek nestačí splnit u rizikových změn schématu databáze?
2. Vysvětlete, jak spolu v tomto návrhu souvisí SLO 99.9 % z modulu
   14 a rozhodnutí o počtu replik a HPA limitech v Kubernetes.
3. Firma se rozhodne expandovat i do třetí země s přísnějšími
   požadavky na lokální uložení dat (data residency). Navrhněte,
   jak byste architekturu upravili (které moduly/technologie z
   kurzu by se týkaly) a zdůvodněte volbu.
4. Mini projekt: vyberte jednu ze tří oblastí návrhu (síť, CI/CD,
   nebo monitoring) a rozpracujte ji o jednu úroveň hlouběji vlastním
   konkrétním artefaktem — např. Terraform definici VPC, kompletní
   GitHub Actions workflow soubor, nebo sadu tří konkrétních
   Prometheus alertovacích pravidel se zdůvodněním prahových hodnot.