Files

Stanislav Hubacek 95d1839f05 First batch

2026-06-11 15:27:28 +02:00

25 KiB

Raw Blame History

🔄 CI/CD a DevOps

CI/CD Pipeline

Code Commit → Build → Test → Package → Deploy to Staging → Integration Tests → Deploy to Production

Detailní pipeline stages

1. Checkout ──→ 2. Lint ──→ 3. Test ──→ 4. Build ──→ 5. Scan ──→ 6. Publish ──→ 7. Deploy
                   │            │                      │
              ESLint/     Unit/Integ/           SAST/SCA/
              Prettier    e2e tests             Container scan

Stage	Nástroje	Co se děje
Checkout	git clone, fetch	Stažení kódu z repozitáře, včetně submodulů
Lint	ESLint, Prettier, RuboCop, golangci-lint	Statická analýza kódu, formátování
Test (unit)	Jest, pytest, JUnit	Rychlé testy (ms až s), bez závislostí
Test (integration)	Testcontainers, Docker Compose	Testy s DB, message queue, externí služby
Test (e2e)	Playwright, Cypress, Selenium	Full-stack testy v prohlížeči
Build	Docker build, go build, npm build, Maven	Kompilace, sestavení artifactu
Scan (SAST)	Semgrep, SonarQube, CodeQL	Statická analýza bezpečnosti
Scan (DAST)	OWASP ZAP, Burp Suite	Dynamická analýza (běžící aplikace)
Scan (SCA)	Dependabot, Snyk, Trivy	Analýza závislostí a CVE
Publish	Docker push, npm publish, Maven deploy	Nahrání artifactu do registru
Deploy	ArgoCD, Terraform, Helm, kubectl	Nasazení do cílového prostředí

Continuous Integration (CI)

Automatické sestavení a testy při každém commitu
Rychlá feedback smyčka (< 10 min)
Linting, type checking, unit testy, security scan (SAST)

Continuous Delivery (CD)

Automatické deploye do staging / test prostředí
Ruční schválení do produkce (optional)
Smoke testy po deployi

Continuous Deployment

Plně automatický deploy do produkce
Vyžaduje vysokou důvěru v testy a monitoring
Feature flagy pro řízení rizika

GitHub Actions detail

Workflow syntax

name: CI Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  NODE_VERSION: "22"

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    needs: lint
    strategy:
      matrix:
        node-version: [22, 24]
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test

Matrix builds

Spouští stejné joby s různými parametry (OS, jazyková verze, architektura)
strategy.matrix — kombinace parametrů (kartézský součin)
strategy.fail-fast — zastavení všech při selhání jednoho

Reusable workflows

# .github/workflows/deploy.yml (called)
on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
    secrets:
      cloud_role:
        required: true

# Volání v caller workflow
jobs:
  deploy:
    uses: ./.github/workflows/deploy.yml
    with:
      environment: staging
    secrets:
      cloud_role: ${{ secrets.STAGING_ROLE }}

Composite actions

Vlastní akce bez nutnosti samostatného repozitáře
Kombinace run, uses, shell kroků
Use case: standardizace lint/test/build napříč repozitáři

Self-hosted runners

Vlastní infrastruktura pro běh GitHub Actions
Use case: privátní síť, GPU, specifický HW, compliance
Škálování: actions-runner-controller (Kubernetes), auto-scaling groups
Bezpečnost: izolace jobů, ephemeral runners

GitLab CI detail

stages:
  - lint
  - test
  - build
  - deploy

variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

lint:
  stage: lint
  image: node:22
  script:
    - npm ci
    - npm run lint

test:
  stage: test
  image: node:22
  needs: ["lint"]
  script:
    - npm test
  artifacts:
    paths:
      - coverage/
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

deploy-staging:
  stage: deploy
  needs: ["build"]
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  environment:
    name: staging
    url: https://staging.example.com
  script:
    - kubectl set image deployment/app app=$DOCKER_IMAGE

Koncepty:

Stages — sekvenční fáze (každá stage může mít více jobů paralelně)
Rules — podmínky spuštění (branch, tag, changes, variables) — nahrazuje only/except
Needs — DAG závislosti (job nemusí čekat na celou stage)
Artifacts — předávání souborů mezi joby (binárky, reporty, cache)
Environments — sledování deployů (rollback, history, approvals)

DAG pipelines (needs)

lint ──→ test ──→ build ──→ deploy-staging ──→ deploy-prod
                        ↓
                   build-arm ──→ test-arm

Definuje závislosti mezi joby (ne nutně stages)
Umožňuje paralelizaci nezávislých jobů
Snižuje celkový čas pipeline

Infrastructure as Code (IaC)

Nástroj	Typ	Jazyk
Terraform	Declarative	HCL
OpenTofu	Declarative	HCL (fork Terraformu)
Pulumi	Declarative	TypeScript, Python, Go, C#
AWS CDK	Declarative	TypeScript, Python, Java, C#
CloudFormation	Declarative	YAML/JSON (AWS)
Azure ARM/Bicep	Declarative	Bicep, JSON
Ansible	Imperative/Config	YAML
Chef/Puppet	Config mgmt	Ruby DSL

Infrastructure as Code (2. vydání) — Kief Morris

Klíčová reference pro navrhování a provozování dynamické cloudové infrastruktury pomocí IaC. Kniha je tool-agnostic — zaměřuje se na vzory a postupy, ne na konkrétní nástroje.

Tři základní praktiky

Praktika	Popis
Define everything as code	Veškerá infrastruktura definovaná v kódu, version control, repeatabilita
Continuously test and deliver	Každá změna prochází pipeline s automatickými testy
Small, independent pieces	Malé, volně provázané komponenty — snadnější změna a testování

Principy cloudové infrastruktury

Systems reproducible — infrastructure can be recreated from code at any time
Systems disposable — instance mohou být zničeny a znovu vytvořeny
Systems consistent — všechny prostředí identická (žádné snowflake servery)
Processes repeatable — automatizace namísto manuálních postupů
Design always changing — infrastruktura se neustále vyvíjí (není build-and-forget)

Anti-vzory (pitfalls)

Anti-vzor	Popis
Snowflake server	Každý server jiný, nelze reprodukovat
Configuration drift	Ruční změny → odchylky od definovaného stavu
Server sprawl	Příliš mnoho serverů bez správy
Fragile infrastructure	Křehká infrastruktura — změny často rozbijí systém
Automation fear	Strach z automatizace → ruční zásahy

Struktura knihy (4 části)

Foundations — rámec nástrojů a technologií pro cloud platformy
Working with infrastructure stacks — definice, provisionování, testování a CD změn infrastruktury
Working with servers and application runtime platforms — provisionování a konfigurace serverů a clusterů
Working with large systems and teams — workflow, governance, architektonické vzory pro více týmů

Organizace IaC kódu

Vzor	Popis
Monorepo	Jeden repozitář pro vše — build-time integrace, vhodný pro malé týmy
Microrepo	Samostatný repozitář pro každý projekt — izolace, vhodný pro velké týmy
Domain organization	Organizace kódu podle doménových konceptů (ne podle technologií)

Doporučení:

Infrastruktura a aplikace mohou být ve stejném nebo odděleném repozitáři záleží na organizační struktuře (Team Topologies)
Konfigurační soubory per-environment (test, staging, production) ukládat v rámci projektu
Testy patří k projektu, integrační testy mohou být v samostatném projektu
Infrastrukturní kód by neměl přímo deployovat aplikace — použít OS packaging (RPM, deb)

Expand-Contract pattern pro změny infrastruktury

Stejný princip jako u databázových migrací:

Expand — přidat nový resource (nestará verze stále běží)
Migrate — přesunout traffic / závislosti na nový resource
Contract — odstranit starý resource

Zabraňuje výpadkům při refaktorování infrastruktury.

Terraform detail

State locking mechanism

Backend	Locking mechanism	Poznámka
S3 + DynamoDB	DynamoDB (ConditionalPut)	Nejčastější, levný, jednoduchý
Terraform Cloud	Built-in (API)	SaaS, audit logy, VCS integration
Azure Storage	Azure Blob Lease	Podobný S3 modelu
GCS	Cloud Storage Object Hold	Omezené
Consul	Consul KV session_lock	High-availability
PostgreSQL	pg_advisory_lock / row lock	Vlastní backend

State backends comparison

Vlastnost	S3 + DynamoDB	Terraform Cloud	Consul
Cena	$ (S3 + DynamoDB)	$$ (free tier omezený)	$$ (infra)
Team workflow	GitHub Actions + OIDC	Native RBAC, runs	Vlastní
Locking	DynamoDB	Built-in	Consul session
History	S3 versioning	Full history, diff	None
Remote ops	Ne (pouze state)	Ano (remote runs)	Ne
Encryption	SSE-S3/KMS	At rest + in transit	TLS

Workspaces vs Terragrunt

Aspekt	Terraform Workspaces	Terragrunt
Separace stavu	Jeden backend, klíč: `env:/workspace`	Samostatný backend per env
Code reuse	Stejný kód, jiné proměnné	DRY konfigurace, moduly
Riziko	Omylem `apply` do špatného workspace	Izolované backends
Kdy použít	Jednoduché projekty, <5 env	Mikroservice, multi-env, multi-team
Extra features	—	Dependency, include, before_hook

Provider versioning

terraform {
  required_version = ">= 1.5, < 2.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = ">= 2.23"
    }
  }
}

~> 5.0 — pouze patch verze (5.x, x ≥ 0)
>= 2.23, < 3.0 — jakákoli 2.x od 2.23
~> constraints zabraňují breaking changes v major/minor

Terraform workflow

terraform init     → Stáhne provider moduly
terraform plan     → Zobrazí změny
terraform apply    → Aplikuje změny
terraform destroy  → Zničí infrastrukturu
terraform validate → Validace syntaxe
terraform fmt     → Formátování HCL

State management

Remote state (S3, Terraform Cloud, Azure Storage)
State locking (DynamoDB, Consul)
Workspaces pro oddělení prostředí

Terraform: Up and Running (3rd ed.) — Yevgeniy Brikman

Praktický průvodce Terraformem od zakladatele Gruntwork. 3. vydání (2022) přidává přes 100 stran nového obsahu, aktualizaci z Terraform 0.12 na 1.2 a dvě nové kapitoly.

Co je nového ve 3. vydání

Novinka	Popis
Kapitola: Secrets management	Správa tajemství s Terraformem — Vault, AWS Secrets Manager, KMS, OIDC, `sensitive` proměnné
Kapitola: Multiple providers	Práce s vícero regiony, účty, cloudy včetně Kubernetes (AWS EKS)
Terraform 1.0+	Backward compatibility promise, stabilita, HashiCorp IPO
Provider versioning	`required_providers` blok + `terraform.lock.hcl` (lock file)
Module iteration	`count` a `for_each` na modulech (od Terraform 0.13)
Variable validation	`validation {}` bloky, `precondition` / `postcondition`
Refactoring	`moved` bloky — bezpečný refactoring bez ruční manipulace se state
CI/CD security	OIDC autentizace, isolated workers pro `terraform apply`

Secrets management s Terraformem

# Proměnná označená jako sensitive — nikdy se nezobrazí v logu
variable "db_password" {
  type      = string
  sensitive = true
}

# Čtení secrets z AWS Secrets Manager
data "aws_secretsmanager_secret" "db" {
  name = "production/db/master"
}

data "aws_secretsmanager_secret_version" "db" {
  secret_id = data.aws_secretsmanager_secret.db.id
}

Doporučená hierarchie bezpečnosti:

OIDC — nejbezpečnější, bez creds na CI serveru (GitHub Actions → IAM role)
IAM role — instance profile (EC2, ECS, EKS)
Environment variables — omezené, riziko úniku v logu
Isolated workers — oddělený worker s admin permissions, API pouze plan/apply

Testing Terraform kódu

Vrstva	Nástroje	Popis
Static analysis	`terraform validate`, `tflint`, `tfsec`, `checkov`	Analýza kódu bez běhu
Plan testing	`conftest` + OPA (Rego), `terraform plan` parse	Validace plánu proti policy
Unit tests	Terratest (Go), `terraform fmt`, `terraform validate`	Testování modulů izolovaně
Integration tests	Terratest (Go)	Skutečné provisionování + assert
End-to-end tests	Terratest	Plný stack, smoke testy

Policy enforcement

# OPA / conftest — zakázat veřejné S3 bucket
package main

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket"
  resource.change.after.acl == "public-read"
  msg = sprintf("%s must not be public", [resource.address])
}

Production-grade checklist dle Brikmana

Small modules — jeden modul = jedna věc (single responsibility)
Composable modules — moduly se dají skládat do větších celků
Testable modules — každý modul má testy (Terratest)
Releasable modules — verzování (Git tagy, Terraform Registry)
Version control — všechno v gitu, včetně .terraform.lock.hcl
Remote state — S3 + DynamoDB nebo Terraform Cloud
CI/CD pipeline — plan na MR, apply po merge do main
Secrets management — žádné secrets v plaintextu v kódu
Policy as code — OPA / Sentinel pro compliance
Sandbox prostředí — každý vývojář má vlastní izolované prostředí

Zlaté pravidlo (Golden Rule of Terraform)

Master branch state musí být vždy v souladu s produkčním prostředím. Nikdy nespouštět terraform apply ručně lokálně na produkci — vždy přes CI/CD.

Dockerfile best practices

# Multi-stage build
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

# Runtime stage — distroless
FROM gcr.io/distroless/nodejs22-debian12
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER nonroot:nonroot
EXPOSE 3000
CMD ["dist/server.js"]

Pravidla:

Multi-stage build — oddělení build tools od runtime
Distroless images — minimal attack surface (žádný shell, package manager)
Non-root user — USER nonroot (security best practice)
Layer caching — nejdříve kopírovat málo se měnící soubory (package.json → npm ci → code)
Small base image — Alpine (5 MB), distroless (minimální), scratch (Go static binary)
Healthcheck — HEALTHCHECK instrukce pro orchestrátor
Labels — LABEL maintainer, version, git commit
.dockerignore — minimalizace build contextu

Artifact management

Docker registries

Registry	Public/Private	Cena	Integrace
Docker Hub	Obojí	Public free, private $5/měsíc	GitHub Actions, GitLab
ECR (AWS)	Private	$0.10/GB/měsíc + data transfer	IAM, ECS, EKS
GHCR (GitHub)	Obojí	Public free, private 500 MB free	GitHub Actions, npm
GCR / Artifact Registry	Private	$0.10/GB/měsíc	GKE, Cloud Build
ACR (Azure)	Private	$0.11/GB/měsíc	AKS, Azure DevOps
Harbor	Private (self-hosted)	Zdarma (open source)	Vlastní, CNCF

Helm charts

Repository — index.yaml + chart .tgz na HTTP serveru (S3, GitHub Pages, ChartMuseum)
OCI registry — Helm 3.8+ podporuje uložení chartů v OCI registrech (ECR, GHCR, Harbor)
Versioning — chart version (balíček) + app version (aplikace)

SBOM (Software Bill of Materials)

SPDX / CycloneDX — standardní formáty SBOM
Generování: Trivy, Syft, grype
Use case: supply chain security, compliance (EO 14028, EU CRA)

Konfigurace a tajemství

Nástroj	Popis
Vault (HashiCorp)	Dynamic secrets, encryption-as-a-service
AWS Secrets Manager	Managed, auto-rotation
Azure Key Vault	Managed, HSM podpora
GCP Secret Manager	Managed
SOPS	Encryption v git repos
Sealed Secrets	Encrypted secrets pro Kubernetes

Secret management workflows

Vault agent injector (Kubernetes)

Sidecar container (vault-agent) injectuje secrets do podu
Secrets mountovány jako tmpfs volume (ne do environment variables)
Auto-rotation: vault-agent periodicky refreshuje secrets

External Secrets Operator (Kubernetes)

CRD: ExternalSecret → vytváří Secret v K8s
Backend: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Vault
Push-based refresh: změna v externím store → propagate do K8s

Sealed Secrets

kubeseal zašifruje Secret na clusteru (controller má privátní klíč)
Zašifrovaný manifest (SealedSecret) může být bezpečně v gitu
Controller decryptuje při deployi

GitOps

Princip: Git je jediný zdroj pravdy (single source of truth)
Nástroje: ArgoCD, Flux, Rancher Fleet
Pull-based deploy — agent v clusteru sleduje repo a aplikuje změny
Auto-sync + drift detection

Environment promotion (dev → staging → prod)

Code → Dev (auto-deploy) → Staging (auto + smoke tests) → Prod (manual approval + gating)

Quality gates:

Unit tests — pass rate 100 %, code coverage ≥ 80 %
Integration tests — all critical paths pass
SAST scan — no critical/high vulnerabilities
SCA scan — no known critical CVEs
Container scan — all fixable vulns addressed
Smoke tests — po deployi na staging (health endpoint, basic flow)
Manual approval — pro produkci (volitelné při CD)

Deployment strategie

Strategie	Popis	Riziko
Rolling update	Postupná výměna instancí	Nízké
Blue/Green	Dvě identická prostředí, přepojení trafficu	Střední
Canary	% trafficu na novou verzi, postupné zvyšování	Nízké
Feature flag	Zapnutí/vypnutí funkce bez deploye	Velmi nízké
A/B testing	Různé verze pro různé uživatele	Nízké

Git branching strategies

Strategie	Popis	Vhodné pro
Trunk-based	Jeden hlavní branch (main), krátké feature branche (< 1 den)	CD, microservices, mature teams
GitHub Flow	Main + feature branche, PRs, jednoduchý	Startupy, web apps
GitLab Flow	Main + environment branche (staging, prod) + feature branche	Enterprise, regulated
GitFlow	Develop + main + feature/release/hotfix branche	Release-based, enterprise legacy
One Flow	Zjednodušený GitFlow (bez develop branche)	Střední týmy

Rollback strategies

Strategie	Popis	Rychlost	Riziko
Forward fix	Nový deploy s hotfixem	Pomalá (build + deploy)	Nízké
Rollback (revert commit)	Revert gitu, nový deploy	Střední	Nízké
Blue/Green switchback	Přepojení zpět na starou verzi	Okamžitá	DB inkompatibilita
Database rollback	Reverze DB migrace (migrate down)	Pomalá	Data loss risk

Database rollback challenges

Breaking changes — odstranění sloupce/tabulky znamená rollback problém (data ztracena)
Best practice: Expand → Migrate → Contract (nikdy neodstraňovat v jednom deployi)
Tooling: Flyway undo (limited), Liquibase rollback, pgroll (Postgres)
Feature flagy jako prevence — nový kód je za flagem, rollback = vypnutí flagu

CI/CD Design Patterns

Moderní CI/CD pipeline řeší opakující se problémy pomocí návrhových vzorů:

Vzor	Popis
Pipeline as Code	Pipeline definovaná v YAML/Kotlin DSL (`.gitlab-ci.yml`, `.github/workflows/`)
Immutable Pipeline	Každý build je artifact, nikdy se nemění
Quality Gate	Branch protection, required checks, code coverage threshold
Deployment Strategy	Blue/Green, Canary, Rolling (viz tabulka níže)
GitOps	Pull-based deploy s auto-sync a drift detection
Shift-Left Security	SAST/DAST/SCA součást pipeline
Dependency Caching	Cache layer mezi běhy pipeline

Shift left security

SCA (Software Composition Analysis)

Nástroj	Typ	Integrace
Dependabot	GitHub native	GitHub, auto-PR na fix
Renovate	Multi-platform	GitHub, GitLab, Bitbucket
Snyk	SaaS + CLI	Všechny platformy, Docker, IaC
Trivy	CLI, OSS	CI/CD pipeline (GitHub Actions, GitLab)

SAST (Static Application Security Testing)

Nástroj	Jazyky	Charakteristika
Semgrep	30+ (Python, Java, Go, JS/TS)	Rychlý, custom rules, CI-native
SonarQube	30+	Komplexní, quality gates, tech debt
CodeQL	12 (C++, C#, Go, Java, JS/TS, Python)	GitHub native, query-based
Checkmarx	30+	Enterprise, CxSAST, CxFlow
Fortify	30+	Enterprise, SAST + DAST

Container scanning

Nástroj	Popis
Trivy	OSS, skenuje OS packages + language-specific + IaC
Grype	OSS, od Anchore, rychlý, Syft pro SBOM
Clair	Red Hat, OSS, OCI-compatible
Docker Scout	Docker Desktop / CLI, integrace s Docker Hub

AI-Native Software Delivery (2025–2026)

AI transformuje DevOps 2.0:

AI-assisted CI/CD — automatické diagnózy selhání pipeline, optimalizace resource alokace
Agent Control Protocol (ACP) / Model Context Protocol (MCP) — standardy pro interakci AI agentů s toolingem
AI-driven cost management — FinOps optimalizace cloudu
Intelligent test selection — ML určuje, které testy spustit podle změn v kódu
Self-healing pipelines — AI auto-detekuje a opravuje běžné problémy

Nové nástroje: Harness (AI-native CD), GitLab 19.0 (agentic MR workflows, secrets manager), Octopus Deploy.

Nástroje pro pipeline

GitHub Actions — integrovaný s GitHubem, velký marketplace
GitLab CI — nativní v GitLabu, auto DevOps
Jenkins — nejstarší, extensible, self-hosted
CircleCI — SaaS, rychlý
Argo Workflows — Kubernetes nativní
Buildkite — hybrid (vlastní agenti, SaaS orchestrator)

Best practices

Idempotentní pipeline — opakované spuštění dává stejný výsledek
Immutable infrastructure — nikdy neupravovat running server, vždy znovu nasadit
Shift left — testy a security co nejdříve v pipeline
Artifact management — všechny buildy verzované v registru (Docker Hub, ECR, GHCR)
Dependency caching — urychlení pipeline (npm ci, pip cache, Docker layer caching)
Fail fast — pipeline selže co nejdříve při chybě

Zdroje

Odkazy, knihy a standardy: sources/cicd/sources.md

Doporučená literatura

Kniha	Autoři	ISBN	Klíčový přínos
The DevOps Handbook	Kim, Humble, Debois, Willis	978-1942788003	Principy CALMS (Culture, Automation, Lean, Measurement, Sharing), flow mapa, deployment pipeline
Continuous Delivery	Humble, Farley	978-0321601912	Deployment pipeline, commit stage, acceptance tests, capacity testing, zero-downtime release
CI/CD Design Patterns	Bajpai, Schildmeijer, Piwosz, Mishra	978-1-83588-965-7	30+ návrhových vzorů pro CI/CD — pipeline patterns, GitOps, security, testing, deployment strategie
DevOps Frameworks, Techniques, and Tools	Vijayakumaran, Kofler, Öggl, Springer	978-1-4932-2670-2	Rámec pro adopci DevOps, srovnání nástrojů (Jenkins vs GitLab vs GitHub Actions), techniky pro monitoring a observabilitu

Quality gates — automated checks před každým povýšením do dalšího prostředí
Pipeline visibility — dashboard s aktuálním stavem všech pipeline (GitHub, GitLab, ArgoCD)

Poslední revize: 2026-06-03

25 KiB Raw Blame History Unescape Escape