Amazon ECS zu STACKIT Kubernetes: ein durchgespieltes Beispiel

Die Eingabe: eine Task Definition, ein Service

Eine für diese Seite geschriebene Demo-Umgebung: ein Fargate-Service mit drei Tasks zu je 0,5 vCPU und 1 GiB hinter einem Application Load Balancer, ein Secret, ein einfacher Umgebungswert und eine awslogs-Log-Gruppe. Links Task Definition und Service, rechts das Deployment, das StackToIT dafür entworfen hat (der lange Kommentarkopf der Datei ist hier weggelassen; alles Gezeigte ist unverändert).

resource "aws_ecs_task_definition" "web" {
  family                   = "shop-web"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = "512"
  memory                   = "1024"
  execution_role_arn       = aws_iam_role.task_execution.arn

  container_definitions = jsonencode([
    {
      name         = "web"
      image        = "registry.example.com/shop/web:1.8.2"
      essential    = true
      portMappings = [{ containerPort = 8080, protocol = "tcp" }]
      environment  = [{ name = "APP_ENV", value = "production" }]
      secrets      = [{ name = "DATABASE_URL", valueFrom = aws_secretsmanager_secret.db_url.arn }]
      logConfiguration = {
        logDriver = "awslogs"
        options = {
          "awslogs-group"         = "/ecs/shop-web"
          "awslogs-region"        = "eu-central-1"
          "awslogs-stream-prefix" = "web"
        }
      }
    }
  ])
}

resource "aws_ecs_service" "web" {
  name            = "web"
  cluster         = aws_ecs_cluster.shop.id
  task_definition = aws_ecs_task_definition.web.arn
  desired_count   = 3
  launch_type     = "FARGATE"

  network_configuration {
    subnets         = [aws_subnet.app_a.id, aws_subnet.app_b.id]
    security_groups = [aws_security_group.web.id]
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.web.arn
    container_name   = "web"
    container_port   = 8080
  }
}

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app.kubernetes.io/name: web
spec:
  replicas: 0 # held back until the start step of the plan scales to the number the header names
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: web
  template:
    metadata:
      labels:
        app.kubernetes.io/name: web
    spec:
      containers:
      - name: web
        image: "registry.example.com/shop/web:1.8.2"
        ports:
        - containerPort: 8080
          protocol: TCP
        env:
        - name: APP_ENV
          valueFrom:
            configMapKeyRef:
              name: web-env
              key: APP_ENV
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: web-secrets
              key: DATABASE_URL
        resources:
          requests:
            cpu: "500m"
            memory: "1024Mi"
          limits:
            cpu: "500m"
            memory: "1024Mi"
        readinessProbe:
          httpGet:
            path: "/healthz"
            port: 8080
          periodSeconds: 30
          timeoutSeconds: 6
          successThreshold: 3
          failureThreshold: 3

Der Ablauf

Fünf Schritte von den Terraform-Dateien bis zur laufenden Workload. Die ersten beiden erledigt StackToIT, alles Weitere ist Arbeit Ihres Teams mit den Dateien, die StackToIT geschrieben hat.

1. 01

   1 · Bewertung ausführen

   Führen Sie StackToIT in dem Ordner aus, der das Terraform enthält. Es liest die Dateien, verbindet sich nie mit AWS und schreibt einen Ausgabeordner mit Entwurf, Entscheidungen und Ausführungsplan.

2. 02

   2 · Klassifizierung lesen

   Cluster und Service werden als REPLATFORM eingestuft, das umgebende Netzwerk, Secret, Rolle, Log-Gruppe und Load Balancer als RECONFIGURE. Task Definition und Target Group haben keine eigene Einheit: Ihr Inhalt fließt in den Service ein.

3. 03

   3 · Entscheidungen beantworten

   Beantworten Sie die offenen Entscheidungen in review/decisions.yaml (wie der Load Balancer die Pods erreicht, ob die Pods segmentiert werden, in welchem Netzwerk der Cluster und seine Konsumenten liegen, das Opt-in für die API-Aufrufe) und setzen Sie die Variablen des Node-Pools (Maschinentyp, Minimum, Maximum) in der Datei mit den Zielwerten.

4. 04

   4 · Erst den Cluster anwenden, dann die Manifeste

   Zuerst das Terraform für den SKE-Cluster anwenden. Die Manifeste werden mit replicas auf 0 geschrieben, damit nichts läuft und keine Verbindung zu einem Datenspeicher aufbaut, bevor dessen Daten da sind.

5. 05

   5 · Hochskalieren und Traffic umschalten

   Nach dem Datenumzug auf die im Quellsystem genannte Zahl der Tasks skalieren, den Smoke-Test der Checkliste ausführen, Load Balancer oder DNS-Eintrag umstellen und ECS weiterlaufen lassen, bis Sie das Ergebnis abgenommen haben.

Was der Lauf meldet

Die Zusammenfassung, die der Befehl für die Demo-Umgebung ausgibt (console.txt im Ausgabeordner). Aufgerufen wurde im Eingabeordner stacktoit assess . <Ausgabeordner> --offline --no-validate; --offline ist der dokumentierte Weg, ohne Netzwerkanfragen zu arbeiten, und --no-validate hat die OpenTofu-Prüfung der Quelle übersprungen; deshalb meldet die Zusammenfassung sie als nicht gelaufen.

Source:                 input
Source files:           1
Resources scanned:      13
  support resources:    1  (+0 Terraform helpers, out of scope; 1 + 0 = the 1 support node of summary.support.nodes in assessment.json)
Migration units:        10  (10 instances)
Unit dependencies:      14
Source checks:          Built-in source checks passed — OpenTofu validation of the source was not run

STACKIT mapping
────────────────────────────────────────────
DIRECT              0  
RECONFIGURE         8  ████████████████████████ 80%
REPLATFORM          2  ██████ 20%
CONTAINERIZE        0  
REDESIGN            0  
MANUAL_REVIEW       0  
BLOCKED             0    (the mapping class BLOCKED, not the execution blockers, which Migration readiness counts)

Wie die ECS-Einstellungen auf Kubernetes landen

Cluster und Load Balancer

Fargate kennt keine Nodes, deshalb ist die Größe des Node-Pools eine Variable, die Sie aus den Task-Größen ableiten, die der Bericht summiert (für diesen Service 1,5 vCPU und 3 GiB an Untergrenze und Obergrenze). Der Load Balancer erreicht die Pods über einen NodePort-Service auf Port 30000, mit den Node-Adressen als Pool-Zielen.

resource "stackit_ske_cluster" "shop" {
  project_id = var.project_id
  name       = "shop"
  node_pools = [{
    name               = "workloads"
    machine_type       = var.shop_machine_type
    minimum            = var.shop_nodes_min
    maximum            = var.shop_nodes_max
    availability_zones = var.availability_zones
  }]
}

  target_pools = [{
    name        = "web"
    target_port = 30000
    targets     = [for ip in var.web_target_ips : { ip = ip }]
    active_health_check = {
      healthy_threshold   = var.web_health_healthy_threshold
      interval            = var.web_health_interval
      interval_jitter     = var.alb_interval_jitter
      timeout             = var.web_health_timeout
      unhealthy_threshold = var.web_health_unhealthy_threshold
      http_health_checks = {
        ok_status = var.web_health_ok_status
        path      = "/healthz"
      }
    }
  }]

apiVersion: v1
kind: Service
metadata:
  name: web-nodeport
  labels:
    app.kubernetes.io/name: web
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: web
  ports:
  - name: p8080-tcp
    port: 8080
    targetPort: 8080
    protocol: TCP
    nodePort: 30000

Entscheiden, wie der Traffic die Pods erreicht

Die Checkliste, die den Workload zurückhält

applications/web.json meldet den Workload als nicht bereit und führt drei blockierende Punkte (Umgebungswert, Secret, Smoke-Test). Die Workload gilt erst als bereit, wenn Ihr Team sie in der Entscheidungsdatei abhakt; StackToIT deployt nichts und führt keinen Test aus.

  "readiness": "NOT_READY",
  "readiness_words": "Checklist items are open: StackToIT lists the work and counts an item done only when the customer marks it in the decisions file (application_checklists); StackToIT never deploys the application.",

Was Sie vor dem Anwenden ändern

Der Entwurf ist ein Ausgangspunkt. Diese Änderungen und Antworten verlangt der Demo-Lauf.

• Dem Cluster eine Größe geben

  Maschinentyp sowie minimale und maximale Node-Anzahl setzen. Das Maximum muss mindestens der Zahl der Zonen entsprechen; standardmäßig sind drei Zonen gewählt.

• Den Load Balancer platzieren

  Der Quell-Load-Balancer überspannt zwei Subnetze, die auf STACKIT getrennte Netzwerke sind. Seine Ziele sind die Cluster-Nodes, deshalb platziert ihn der Entwurf in dem Netzwerk, das SKE für den Cluster anlegt. Der Provider exportiert weder dieses Netzwerk noch die Node-Adressen: Sie wenden zuerst den Cluster an und setzen danach Netzwerk-ID und Node-IPs.

• Das Zertifikat hochladen

  Der HTTPS-Listener nennt eine Zertifikats-ARN. Die ARN wird nicht umgesetzt: Zertifikat bei STACKIT hochladen und die ID in der Listener-Variable übergeben.

• Zugriff einschränken

  Die Quelle lässt jede IPv4-Adresse auf Port 443 zu, der erzeugte Load Balancer ebenso. Entscheiden Sie, ob ein erlaubter Quellbereich geschrieben wird.

• Die Netzwerkrichtlinie schreiben

  Die Security Group der Tasks wird nicht auf Pods übertragen. Der Plan nennt als Optionen eine NetworkPolicy, eine Security Group an den Nodes oder den Verzicht auf Segmentierung.

• ConfigMap und Secret füllen

  APP_ENV in die ConfigMap eintragen, web-secrets mit DATABASE_URL anlegen und prüfen, ob die Nodes die Image-Registry erreichen.

Fragen aus den Teams

Quellen

• AWS-Dokumentation: Taskdefinitionen in Amazon ECS
• AWS-Dokumentation: Parameter der Servicedefinition in Amazon ECS
• STACKIT-Dokumentation: STACKIT Kubernetes Engine
• STACKIT-Dokumentation: Application Load Balancer erstellen
• STACKIT-Dokumentation: SKE ALB Ingress