Cloud i DevOps

Kontener nie jest lekką maszyną wirtualną: dzieli jądro systemu hosta i izoluje procesy przez namespaces oraz cgroups. Obraz Docker to niezmienny szablon zbudowany z warstw; kontener to jego uruchomiona instancja z własną, zapisywalną warstwą na wierzchu.

FROM node:22
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
CMD ["node", "dist/server.js"]

# --- Etap budowania ---
FROM node:22 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# --- Etap uruchomieniowy ---
FROM node:22-slim AS runtime
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev
COPY --from=builder /app/dist ./dist
USER node
EXPOSE 3000
CMD ["node", "dist/server.js"]

• Sortuj instrukcje od najrzadziej do najczęściej zmienianych (zależności przed kodem źródłowym)
• Używaj .dockerignore, by nie kopiować node_modules/.git do kontekstu builda
• Pinuj wersję obrazu bazowego (node:22.14-slim, nie node:latest) dla powtarzalnych buildów
• Uruchamiaj proces jako użytkownik nie-root (USER) w finalnym etapie
• Łącz RUN apt-get update && apt-get install w jedną instrukcję, by nie zostawiać cache'u pakietów w osobnej warstwie

Pipeline CI/CD to automatyzacja ścieżki od commitu do działającego kodu na środowisku. Celem jest wykryć problem jak najwcześniej (fail-fast) i sprawić, że wdrożenie jest nudną, powtarzalną czynnością, nie wydarzeniem wysokiego ryzyka.

1. 1 Build: kompilacja/pakowanie kodu do artefaktu (obraz Docker, binarka, paczka)
2. 2 Test: testy jednostkowe, integracyjne, czasem bezpieczeństwa (SAST, skan zależności)
3. 3 Deploy: wypchnięcie artefaktu na środowisko (staging, potem produkcja), zwykle z bramką jakości między etapami

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

jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run build
      - run: npm test

  deploy:
    needs: build-test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "deploy do produkcji po zielonym build-test"

1. 1 Trigger Push lub pull request uruchamia pipeline automatycznie
2. 2 Build Kod kompilowany/pakowany do artefaktu (np. obraz Docker z tagiem commit SHA)
3. 3 Test Automatyczne testy blokują dalsze etapy przy pierwszym czerwonym wyniku
4. 4 Deploy do staging Artefakt trafia na środowisko zbliżone do produkcji
5. 5 Bramka (opcjonalna) Ręczna akceptacja lub automatyczne kryteria przed produkcją
6. 6 Deploy do produkcji Ten sam, niezmieniony artefakt z wcześniejszych etapów trafia na produkcję

Kubernetes orkiestruje kontenery przez deklaratywne obiekty API: deklarujesz pożądany stan, a control plane (scheduler, kontrolery) nieustannie dąży do zgodności rzeczywistego stanu z zadeklarowanym (reconciliation loop).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
        - name: api-server
          image: registry.example.com/api-server:1.4.2
          ports:
            - containerPort: 8080
          envFrom:
            - configMapRef:
                name: api-server-config
            - secretRef:
                name: api-server-secrets
---
apiVersion: v1
kind: Service
metadata:
  name: api-server
spec:
  type: ClusterIP
  selector:
    app: api-server
  ports:
    - port: 80
      targetPort: 8080

apiVersion: v1
kind: ConfigMap
metadata:
  name: api-server-config
data:
  LOG_LEVEL: "info"
  FEATURE_FLAG_NEW_CHECKOUT: "true"
---
apiVersion: v1
kind: Secret
metadata:
  name: api-server-secrets
type: Opaque
stringData:
  DATABASE_URL: postgres://app:changeme@db.internal:5432/app

Infrastructure as Code zamienia klikanie w konsoli chmurowej na kod: infrastrukturę opisuje się w plikach, wersjonuje w Git i stosuje przez narzędzie, które oblicza różnicę między stanem zadeklarowanym a rzeczywistym.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = "eu-central-1"
}

data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-*-x86_64"]
  }
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = "t3.micro"

  tags = {
    Name = "web-server"
  }
}

1. 1 terraform init Pobiera providery (np. hashicorp/aws) i inicjalizuje backend stanu
2. 2 terraform plan Pokazuje różnicę między kodem a bieżącym stanem (co zostanie dodane/zmienione/usunięte)
3. 3 terraform apply Wykonuje zmiany z planu i zapisuje nowy stan
4. 4 terraform destroy Usuwa zasoby zarządzane przez ten kod, zgodnie z zapisanym stanem

• Każda zmiana infrastruktury przechodzi code review jak zmiana w aplikacji (pull request z terraform plan w opisie)
• Infrastruktura jest odtwarzalna 1:1 w innym regionie/koncie (disaster recovery, nowe środowisko)
• Historia zmian jest w Git, nie w pamięci osoby, która kiedyś kliknęła w konsoli
• Ten sam kod (moduł) da się sparametryzować i użyć dla dev/staging/prod

Twelve-Factor App (Heroku, 2011) to zestaw dwunastu praktyk budowania aplikacji SaaS łatwych do skalowania, przenoszenia między środowiskami i utrzymania bez ręcznej ingerencji. Mimo wieku, każdy punkt wprost mapuje się na dzisiejsze kontenery i Kubernetes.

1. 1 I. Codebase - jedna baza kodu w kontroli wersji, wiele wdrożeń z niej wynikających
2. 2 II. Dependencies - jawnie zadeklarowane zależności (package.json), nigdy 'zainstalowane ręcznie na serwerze'
3. 3 III. Config - konfiguracja różniąca się między środowiskami trzymana w zmiennych środowiskowych, nie w kodzie
4. 4 IV. Backing services - baza danych, kolejka, cache traktowane jako podłączane zasoby wymienne bez zmiany kodu
5. 5 V. Build, release, run - ścisłe rozdzielenie etapu budowy, złożenia z configiem i uruchomienia
6. 6 VI. Processes - procesy aplikacji bezstanowe, trwały stan żyje w backing service
7. 7 VII. Port binding - aplikacja sama nasłuchuje na porcie, nie wymaga wstrzykniętego web serwera
8. 8 VIII. Concurrency - skalowanie przez uruchamianie kolejnych instancji procesu (horyzontalnie), nie przez grubszy proces
9. 9 IX. Disposability - szybki start i graceful shutdown, procesy jednorazowe do zabicia/odtworzenia w każdej chwili
10. 10 X. Dev/prod parity - środowiska deweloperskie, staging i produkcja maksymalnie zbliżone
11. 11 XI. Logs - logi jako strumień zdarzeń na stdout, nie zarządzane przez aplikację pliki
12. 12 XII. Admin processes - zadania administracyjne (migracje, konsola) uruchamiane jako jednorazowe procesy w tym samym środowisku co aplikacja

// Factor III: Config - wartości środowiskowe, nie zahardkodowane w kodzie
const config = {
  port: process.env.PORT ?? 3000,
  databaseUrl: process.env.DATABASE_URL,
  logLevel: process.env.LOG_LEVEL ?? 'info',
};

if (!config.databaseUrl) {
  throw new Error('DATABASE_URL is required');
}

Observability to zdolność zadawania systemowi pytań, których nie przewidziałeś przy jego budowie, opierając się na trzech uzupełniających się źródłach sygnału: logach, metrykach i trace'ach.

{"timestamp":"2026-07-05T10:32:14Z","level":"error","service":"checkout-api","trace_id":"4bf92f3577b34da6a3ce929d0e0e4736","message":"payment gateway timeout","order_id":"ord_88213"}

# HELP http_requests_total Total number of HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET",status="200"} 182933
http_requests_total{method="GET",status="500"} 12

# HELP http_request_duration_seconds Histogram of request duration
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.1"} 15234
http_request_duration_seconds_bucket{le="0.5"} 18211
http_request_duration_seconds_bucket{le="+Inf"} 18220

from opentelemetry import trace

tracer = trace.get_tracer("checkout-service")

def process_order(order_id: str) -> None:
    with tracer.start_as_current_span("process_order") as span:
        span.set_attribute("order.id", order_id)
        charge_payment(order_id)