Baue deinen ersten AWS CDK Stack: Ein anfängerfreundliches Tutorial

Arbeiten mit CDK-Konstrukten

AWS CDK-Anwendungen beruhen auf Konstrukten als ihren wesentlichen Strukturelementen. Dein Infrastrukturcode wird modularer, wartbarer und lesbarer, wenn du die Konstrukte beherrschst, egal ob du eingebaute Service-Konstrukte verwendest oder eigene wiederverwendbare Muster erstellst.

In diesem Abschnitt lernst du, wie du L2-Konstrukte (High-Level-Konstrukte) verwendest und benutzerdefinierte Konstrukte entwickelst, die sich wiederholende Muster reduzieren.

L2-Konstruktionen verwenden

L2-Konstrukte sind CDK-native Abstraktionen, die einfacher zu verwenden sind als die rohe CloudFormation (L1). Sie haben sinnvolle Standardeinstellungen und Typsicherheit und benötigen oft weniger Codezeilen, um eine AWS-Ressource einzurichten.

Warum L2-Konstruktionen verwenden?

• Weniger Textbausteine - weniger Pflichtfelder im Vergleich zu L1
• Besser lesbarer und idiomatischer Python-Code
• Enthält Hilfsmethoden wie .add_to_role_policy() oder .add_event_notification()
• Verwaltet automatisch Abhängigkeiten zwischen Ressourcen

Beispiel: Erstellen eines S3-Buckets mit L2

from aws_cdk import aws_s3 as s3
# Create a versioned and encrypted S3 bucket
bucket = s3.Bucket(
    self,
    "MyBucket",
    versioned=True,
    encryption=s3.BucketEncryption.S3_MANAGED
)

Für das entsprechende L1-Konstrukt s3.CfnBucket müssten alle Eigenschaften manuell festgelegt und die Konfiguration als rohe Dict definiert werden - das ist viel weniger intuitiv.

Andere gängige L2-Konstrukte sind:

• lambda_.Function() für AWS Lambda
• dynamodb.Table() für DynamoDB
• sqs.Queue() für SQS
• sns.Topic() für SNS

Benutzerdefinierte Konstrukte erstellen

Deine Infrastruktur wird mit wiederkehrenden Mustern erweitert, wie z.B. dem Erstellen von Lambda-Funktionen mit bestimmten Berechtigungen und S3-Buckets. Benutzerdefinierte Konstrukte sind die ideale Lösung für dieses spezielle Szenario.

Mit benutzerdefinierten Konstrukten kannst du verwandte Ressourcen zu einer einzigen logischen Einheit zusammenfassen, die über Stapel oder Projekte hinweg wiederverwendet werden kann.

Wann du ein benutzerdefiniertes Konstrukt erstellen solltest:

• Wenn du 3+ Ressourcen hast, die immer zusammen bereitgestellt werden
• Wenn du wiederverwendbare Logik kapseln willst
• Wenn du Code-Duplizierung über Stapel hinweg reduzieren willst

Beispiel: Ein wiederverwendbares S3 + Lambda Muster

from constructs import Construct
from aws_cdk import aws_s3 as s3, aws_lambda as lambda_
class StorageWithLambda(Construct):
    def __init__(self, scope: Construct, id: str) -> None:
        super().__init__(scope, id)
        # S3 bucket
        self.bucket = s3.Bucket(self, "MyBucket")

        # Lambda function
        self.function = lambda_.Function(
            self,
            "MyFunction",
            runtime=lambda_.Runtime.PYTHON_3_9,
            handler="index.handler",
            code=lambda_.Code.from_asset("lambda")
        )
        # Grant Lambda access to the S3 bucket
        self.bucket.grant_read_write(self.function)

Du kannst dieses Konstrukt jetzt in jedem Stapel wie folgt verwenden:

from my_project.storage_with_lambda import StorageWithLambda
storage = StorageWithLambda(self, "ReusableComponent")

Bevor du die obigen Schritte ausführst, erstelle einen Ordner namens lambda im Stammverzeichnis des Projekts und erstelle eine Datei index.py mit dem folgenden Inhalt:

def handler(event, context):
    return {
        "statusCode": 200,
        "body": "Hello from Lambda!"
    }

Tipps zur Wiederverwendbarkeit

• Setze das Präfix construct_ vor die Dateien oder platziere sie in einem constructs/ Ordner.
• Lege Ausgänge wie self.bucket oder self.function für mehr Flexibilität frei
• Jedes Konstrukt sollte sich auf eine Verantwortung konzentrieren

Testen und Synthetisieren von CDK-Apps

Nachdem du deinen Infrastrukturcode geschrieben hast, ist es wichtig zu prüfen, was das CDK bereitstellen wird und idealerweise zu testen, ob sich deine Stacks wie erwartet verhalten. Das AWS CDK bietet Tools, um CloudFormation-Vorlagen zu synthetisieren und automatisierte Tests zu schreiben, um Fehlkonfigurationen vor der Bereitstellung zu erkennen.

Vorlagen synthetisieren

Der Befehl cdk synth generiert die CloudFormation-Vorlage aus deinem CDK-Code.

cdk synth

Wenn du dies ausführst, wird die CDK:

• Lädt deine App (über app.py)
• Löst alle Konstrukte und Stapel auf
• Gibt rohe YAML/JSON CloudFormation-Vorlagen aus

Synthetisierte CloudFormation-Vorlage 

Standardmäßig geht die Ausgabe in dein Terminal, aber du kannst sie bei Bedarf auch in eine Datei ausgeben:

cdk synth > template.yaml

Dies ist nützlich, wenn:

• Du möchtest die eigentliche Vorlage vor dem Einsatz prüfen
• Du debuggst die Struktur eines Stacks
• Du teilst die Vorlage mit Teams, die kein CDK verwenden

Prüfinfrastruktur

Obwohl das Testen der Infrastruktur als Code ungewöhnlich klingen mag, ist es von Vorteil, vor allem, wenn deine Stacks groß werden oder bedingte Logik, Schleifen oder wiederverwendbare Konstrukte enthalten.

Das AWS CDK bietet das Assertions-Modul, um synthetisierte Stacks zu testen.

Einen einfachen Test schreiben mit pytest

Hier ist ein Beispieltest, der überprüft, ob eine bestimmte Ressource (wie ein S3-Bucket) im Stack enthalten ist:

# test/test_cdk_datacamp_stack.py
import aws_cdk as cdk
from aws_cdk.assertions import Template
from cdk_datacamp.cdk_datacamp_stack import CdkDatacampStack
def test_s3_bucket_created():
    app = cdk.App()
    stack = CdkDatacampStack(app, "TestStack")
    template = Template.from_stack(stack)
    # Assert that an S3 bucket exists
    template.resource_count_is("AWS::S3::Bucket", 1)

Um die Tests durchzuführen, stelle sicher, dass pytest installiert ist:

pip install -U pytest

Dann lauf:

pytest

Wenn alles in Ordnung ist, siehst du ein grünes Häkchen. Wenn nicht, wird dir die Testausgabe sagen, was fehlt.

Die Pytest-Ausgabe zeigt die erfolgreiche Ausführung aller Testfälle für den AWS CDK-Stack

Du kannst die Validierung auch in deinen CDK-Stack aufnehmen. Validierungstests sind Laufzeitprüfungen innerhalb deines Konstrukt- oder Stack-Codes, die Eingaben validieren, bevor die Bereitstellung erfolgt. Sie helfen dabei, Fehlkonfigurationen aufzuspüren oder Beschränkungen frühzeitig im Entwicklungszyklus durchzusetzen.

Nehmen wir an, wir wollen die bucket_name als Kontextvariable übergeben, aber wir wollen das validieren:

• Der Bucket-Name ist nicht leer
• Er entspricht den S3-Benennungsregeln (z. B. nur Kleinbuchstaben)

Erstelle eine Datei namens test/test_storage_with_lambda.py und füge Folgendes hinzu:

import pytest
from aws_cdk import App, Stack
from cdk_datacamp.storage_with_lambda import StorageWithLambda

def test_missing_bucket_name():
    app = App()
    stack = Stack(app, "TestStack")

    with pytest.raises(ValueError, match="bucket_name is required"):
        StorageWithLambda(stack, "FailingConstruct", bucket_name=None)

def test_bucket_name_uppercase():
    app = App()
    stack = Stack(app, "TestStack")

    with pytest.raises(ValueError, match="must be lowercase"):
        StorageWithLambda(stack, "FailingConstruct", bucket_name="InvalidName")

 Um die Validierung zu testen, führe den folgenden Befehl aus:

test/test_storage_with_lambda.py

Die Pytest-Ausgabe zeigt die erfolgreiche Ausführung aller Testfälle für den AWS CDK-Stack

Wann du Tests durchführen solltest:

• Du erstellst wiederverwendbare Konstrukte oder Muster.
• Die Durchführung von Tests dient dazu, einheitliche technische Anforderungen unter den Teammitgliedern festzulegen.
• Du willst Regressionen oder unbeabsichtigte Änderungen während CI/CD abfangen.

Willst du dein CDK-Wissen in einem Vorstellungsgespräch auffrischen? Diese Top AWS DevOps-Interview-Fragen können dir bei der Vorbereitung helfen.

Best Practices und Tipps für die Arbeit mit dem AWS CDK

Nachdem du die Erstellung und den Einsatz des CDK-Stacks gemeistert hast, solltest du Best Practices befolgen, um deinen Infrastrukturcode sauber, sicher und skalierbar zu halten. In diesem Abschnitt wird erörtert, wie man große Projekte strukturiert, die Sicherheit richtig handhabt und CDK in CI/CD-Pipelines integriert.

Große Projekte organisieren

Wenn deine CDK-Anwendung wächst, ist es wichtig, den Code in überschaubaren Einheiten zu organisieren.

Mehrere Stapel verwenden

Teile deine Infrastruktur nach Anliegen auf. Zum Beispiel:

• NetworkingStack: VPCs, Subnetze, Sicherheitsgruppen
• ComputeStack: EC2, Lambda
• StorageStack: S3, DynamoDB

So kannst du Teile deiner Infrastruktur unabhängig voneinander einsetzen, testen oder zerstören. So kann sie in app.py eingebunden werden:

network_stack = NetworkingStack(app, "NetworkingStack")
compute_stack = ComputeStack(app, "ComputeStack")

Du kannst auch Ressourcen zwischen Stapeln mit Hilfe von Ausgängen oder Referenzen übergeben.

Wiederverwendbare verschachtelte Konstrukte erstellen

Kapseln Sie zusammenhängende Ressourcen (wie ein Lambda und seine Berechtigungen) in einem benutzerdefinierten Konstrukt, wie Sie es mit StorageWithLambda getan haben. Das verbessert die Lesbarkeit und Wiederverwendbarkeit über Stacks oder Apps hinweg.

Umgebungsspezifische Konfiguration verwenden

Unterstütze mehrere Umgebungen (Dev, Staging, Prod) mit:

• cdk.json mit Kontextwerten
• CLI-Übersteuerungen: cdk deploy -c env=prod
• Bedingte Logik in deinen Stapeln

env = app.node.try_get_context("env")
if env == "prod":
    bucket_name = "mycompany-prod-logs"

Sicherheit und Berechtigungen

Jedes Infrastrukturprojekt muss der Sicherheit während der automatisierten Bereitstellungsprozesse von AWS CDK Priorität einräumen. Der folgende Abschnitt demonstriert die sichere IAM-Ressourcenverwaltung durch die Prinzipien der geringsten Privilegien.

IAM-Rollen definieren, statt Standardwerte zu verwenden

CDK-Konstrukte, die Lambda- oder ECS-Aufgaben enthalten, erstellen automatisch IAM-Rollen. Das ist zwar praktisch, aber es kann deine Kontrolle über Berechtigungen und Namensgebung einschränken.

Definiere stattdessen explizit Rollen:

from aws_cdk import aws_iam as iam

execution_role = iam.Role(
    self,
    "LambdaExecutionRole",
    assumed_by=iam.ServicePrincipal("lambda.amazonaws.com"),
    description="Custom role for Lambda with least privilege",
    managed_policies=[
        iam.ManagedPolicy.from_aws_managed_policy_name("service-role/AWSLambdaBasicExecutionRole")
    ]
)

Diese Rolle erlaubt standardmäßig nur die Protokollierung und nichts anderes.

Das Prinzip des geringsten Privilegs anwenden

Vermeide es, "*" in actions oder resources zu verwenden, wenn es nicht unbedingt notwendig ist.

Beispiel:

lambda_fn.add_to_role_policy(
    iam.PolicyStatement(
        actions=["*"],
        resources=["*"]
    )
)

Du kannst auch ressourcenspezifische Zuschüsse nutzen, wenn sie verfügbar sind:

bucket.grant_read(lambda_fn)

Dadurch wird automatisch die notwendige Richtlinie mit beschränktem Zugriff auf den S3-Bucket erstellt.

Verwaltete Richtlinien verwenden, wenn möglich

Von AWS verwaltete Richtlinien vereinfachen die Wartung und verringern das Risiko von Fehlern.

iam.ManagedPolicy.from_aws_managed_policy_name("AmazonSQSReadOnlyAccess")

Du kannst sie mit benutzerdefinierten Rollen für Dienste wie ECS, Batch oder Step Functions verknüpfen.

CI/CD-Integration

Das AWS CDK ist besonders leistungsstark, da es sich in moderne CI/CD-Pipelines integrieren lässt. CDK unterstützt die automatisierte Bereitstellung der Infrastruktur durch versionsgesteuerte Codebereitstellung, die mit GitHub, GitLab und AWS-nativen Diensten, einschließlich CodePipeline, funktioniert. Das System verringert menschliche Fehler, verkürzt die Feedback-Zyklen und ermöglicht den Einsatz in verschiedenen Umgebungen.

GitHub-Aktionen: CDK-Einsätze automatisieren

Du kannst GitHub Actions nutzen, um CDK-Stacks bei jedem Push- oder Pull-Request zu synthetisieren, zu diffundieren, zu testen und einzusetzen.

Sieh dir das an .github/workflows/deploy.yml:

name: Deploy CDK App

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - uses: actions/setup-python@v4
        with:
          python-version: 3.11

      - name: Install dependencies
        run: |
          pip install -r requirements.txt
          npm install -g aws-cdk

      - name: Run unit tests
        run: pytest

      - name: CDK Synth
        run: cdk synth -c environment=prod

      - name: Deploy to AWS
        run: cdk deploy --require-approval never
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Verwende cdk diff in PRs, um infra-Änderungen vor dem Zusammenführen anzuzeigen.

CDK-Pipelines: Natives CDK CI/CD mit CodePipeline

Für vollständig verwaltete Bereitstellungen innerhalb von AWS bietet CDK ein Modul namens aws_cdk.pipelines, mit dem du deine gesamte CI/CD-Pipeline als Code definieren kannst, genau wie die Infrastruktur.

Hier ist ein vereinfachtes Beispiel:

from aws_cdk import pipelines, SecretValue, Stack
from constructs import Construct
from my_app_stage import MyAppStage  # replace with your actual stage import

class PipelineStack(Stack):
    def __init__(
        self,
        scope: Construct,
        construct_id: str,
        **kwargs
    ) -> None:
        super().__init__(scope, construct_id, **kwargs)

        # Define the source of the pipeline from a GitHub repository
        source = pipelines.CodePipelineSource.git_hub(
            repo_string="your-org/your-repo",  # GitHub org/repo
            branch="main",
            authentication=SecretValue.secrets_manager("GITHUB_TOKEN")
        )

        # Define the CodePipeline and its synthesis step
        pipeline = pipelines.CodePipeline(
            self,
            "MyAppPipeline",
            synth=pipelines.ShellStep(
                "Synth",
                input=source,
                commands=[
                    "pip install -r requirements.txt",
                    "npm install -g aws-cdk",
                    "cdk synth"
                ]
            )
        )

        # Add an application stage (e.g., production deployment)
        pipeline.add_stage(
            MyAppStage(self, "ProdStage")
        )

Im obigen Code:

• SecretValue.secrets_manager("GITHUB_TOKEN") holt dein GitHub-Token sicher aus dem Secrets Manager.
• MyAppStage sollte eine Klasse sein, die Stage erweitert und deine eigentlichen CDK-Stapel umhüllt.

Wenn du Systeme für maschinelles Lernen bereitstellst, wird die Integration von CDK mit kontinuierlichen Bereitstellungspraktiken in unserem Kurs CI/CD für maschinelles Lernen behandelt.

Fazit

In diesem Lernprogramm hast du gelernt, wie du mit dem AWS Cloud Development Kit (CDK) eine Cloud-Infrastruktur in Python aufbaust und bereitstellst. Du hast gelernt, wie es geht:

• Erstelle deinen ersten CDK-Stack.
• Definiere und validiere S3-Buckets und Lambda-Funktionen als Ressourcen.
• Organisiere ein Projekt durch benutzerdefinierte Konstrukte und Multi-Stack-Muster.
• Bewährte Sicherheitspraktiken nach dem Prinzip der geringsten Privilegien anwenden.
• Automatisiere Einsätze, indem du GitHub Actions mit CDK Pipelines kombinierst.
• Schreibe Tests, um die Logik deiner Infrastruktur zu überprüfen.

Jetzt, wo du deine erste CDK-App eingesetzt hast, gibt es ein paar Möglichkeiten, dich weiterzuentwickeln:

• Verwende parametrisierte Umgebungen für Dev/Staging/Prod
• Hinzufügen von CloudWatch Alarmen, API Gateway oder Schrittfunktionen
• Erforsche CDK-Konstrukte wie aws_s3_deployment, aws_ecs_patterns, und cdk.pipelines
• Konvertiere deine Konstrukte in eine interne Python-Bibliothek, um sie wiederverwenden zu können.

Um weiter zu lernen und zu bauen, schauden Kurs Einführung in AWS Boto in Python an!