Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Verwendung von CI/CD Systemen und Pipelines für die Bereitstellung mit AWS SAM AWS SAM unterstützt Unternehmen bei der Erstellung von Pipelines für ihre bevorzugten CI/CD Systeme, sodass sie CI/CD mit minimalem Aufwand die Vorteile nutzen können, wie z. B. die Beschleunigung der Bereitstellungshäufigkeit, die Verkürzung der Vorlaufzeit für Änderungen und die Reduzierung von Bereitstellungsfehlern. AWS SAM vereinfacht CI/CD Aufgaben für serverlose Anwendungen mithilfe von Build-Container-Images. Die bereitgestellten Images beinhalten die Tools AWS SAMCLI und Build-Tools für eine Reihe unterstützter AWS Lambda Laufzeiten. AWS SAM Dies macht es einfacher, serverlose Anwendungen mithilfe von zu erstellen und zu paketieren. AWS SAMCLI Diese Images machen es den Teams auch leichter, ihre eigenen Images für CI/CD Systeme zu erstellen und zu verwalten. Weitere Informationen zum AWS SAM Erstellen von Container-Images finden Sie unter[Bild-Repositorys für AWS SAM](serverless-image-repositories.md). Das AWS SAM Erstellen von Container-Images wird von mehreren CI/CD Systemen unterstützt. Welches CI/CD System Sie verwenden sollten, hängt von mehreren Faktoren ab. Dazu gehört, ob Ihre Anwendung eine einzelne Laufzeit oder mehrere Laufzeiten verwendet oder ob Sie Ihre Anwendung in einem Container-Image oder direkt auf einem Hostcomputer, entweder einer virtuellen Maschine (VM) oder einem Bare-Metal-Host, erstellen möchten. AWS SAM bietet außerdem eine Reihe von Standard-Pipeline-Vorlagen für mehrere CI/CD Systeme, in denen die bewährten Bereitstellungsmethoden zusammengefasst AWS sind. Diese Standard-Pipeline-Vorlagen verwenden standardmäßige JSON/YAML Pipeline-Konfigurationsformate, und die integrierten Best Practices helfen bei der Durchführung von Bereitstellungen mit mehreren Konten und Regionen und stellen sicher, dass Pipelines keine unbeabsichtigten Änderungen an der Infrastruktur vornehmen können. Sie haben zwei Hauptoptionen für die Bereitstellung Ihrer serverlosen Anwendungen: 1) Ändern Sie Ihre bestehende Pipeline-Konfiguration, sodass AWS SAMCLI Befehle verwendet werden, oder 2) Generieren Sie eine CI/CD Beispiel-Pipeline-Konfiguration, die Sie als Ausgangspunkt für Ihre eigene Anwendung verwenden können. AWS SAM **Topics** + [Was ist eine Pipeline?](#deploying-whatis-pipeline) + [So werden lokale Dateien bei der Bereitstellung AWS SAM hochgeladen](deploy-upload-local-files.md) + [Generieren Sie eine CI/CD Starter-Pipeline mit AWS SAM](serverless-generating-example-ci-cd.md) + [So passen Sie Starter-Pipelines an mit AWS SAM](serverless-customizing-starter-pipelines.md) + [Automatisieren Sie die Bereitstellung Ihrer AWS SAM Anwendung](serverless-deploying-modify-pipeline.md) + [So verwenden Sie die OIDC-Authentifizierung mit Pipelines AWS SAM](deploying-with-oidc.md) ## Was ist eine Pipeline? Eine Pipeline ist eine automatisierte Abfolge von Schritten, die ausgeführt werden, um eine neue Version einer Anwendung zu veröffentlichen. [Mit AWS SAM können Sie viele gängige CI/CD Systeme für die Bereitstellung Ihrer Anwendungen verwenden, darunter [Jenkins [AWS CodePipeline](https://aws.amazon.com/codepipeline)](https://www.jenkins.io/), [GitLab CI/CD](https://docs.gitlab.com/ee/ci/) und Actions. GitHub](https://github.com/features/actions) Pipeline-Vorlagen enthalten bewährte AWS Bereitstellungsmethoden, die Sie bei Bereitstellungen mit mehreren Konten und Regionen unterstützen. AWS Umgebungen wie Entwicklung und Produktion existieren in der Regel in unterschiedlichen Konten. AWS Auf diese Weise können Entwicklungsteams sichere Bereitstellungspipelines konfigurieren, ohne unbeabsichtigte Änderungen an der Infrastruktur vorzunehmen. Sie können auch Ihre eigenen benutzerdefinierten Pipeline-Vorlagen bereitstellen, um die Pipelines zwischen den Entwicklungsteams zu standardisieren. # So werden lokale Dateien bei der Bereitstellung AWS SAM hochgeladen Wenn Sie Ihre Anwendung auf dem bereitstellen AWS Cloud, AWS CloudFormation müssen Ihre lokalen Dateien zunächst in einen zugänglichen AWS Service wie Amazon Simple Storage Service (Amazon S3) hochgeladen werden. Dies schließt lokale Dateien ein, auf die Ihre AWS SAM Vorlage verweist. Um diese Anforderung zu erfüllen, AWS SAMCLI geht der wie folgt vor, wenn Sie den `sam package` Befehl `sam deploy` oder verwenden: 1. Lädt Ihre lokalen Dateien automatisch in einen AWS Dienst hoch, auf den zugegriffen werden kann. 1. Aktualisiert Ihre Anwendungsvorlage automatisch, sodass sie auf den neuen Dateipfad verweist. **Topics** + [Demo: Verwenden Sie AWS SAMCLI den Lambda-Funktionscode zum Hochladen](#deploy-upload-local-files-demo) + [Unterstützte Anwendungsfälle](#deploy-upload-local-files-use) + [Weitere Informationen](#deploy-upload-local-files-learn) ## Demo: Verwenden Sie AWS SAMCLI den Lambda-Funktionscode zum Hochladen In dieser Demo initialisieren wir die Hello World-Beispielanwendung mit einem Pakettyp .zip für unsere Lambda-Funktion. Wir verwenden den AWS SAMCLI, um unseren Lambda-Funktionscode automatisch auf Amazon S3 hochzuladen und auf seinen neuen Pfad in unserer Anwendungsvorlage zu verweisen. Zuerst starten wir, `sam init` um unsere Hello World-Anwendung zu initialisieren. ``` $ sam init ... Which template source would you like to use? 1 - AWS Quick Start Templates 2 - Custom Template Location Choice: 1 Choose an AWS Quick Start application template 1 - Hello World Example 2 - Multi-step workflow ... Template: 1 Use the most popular runtime and package type? (Python and zip) [y/N]: y Would you like to enable X-Ray tracing on the function(s) in your application? [y/N]: ENTER Would you like to enable monitoring using CloudWatch Application Insights? For more info, please view https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html [y/N]: ENTER Project name [sam-app]: demo ----------------------- Generating application: ----------------------- Name: demo Runtime: python3.9 Architectures: x86_64 Dependency Manager: pip Application Template: hello-world Output Directory: . Configuration file: demo/samconfig.toml ... ``` Unser Lambda-Funktionscode ist im `hello_world` Unterverzeichnis unseres Projekts organisiert. ``` demo ├── README.md ├── hello_world │ ├── __init__.py │ ├── app.py │ └── requirements.txt ├── template.yaml └── tests ``` In unserer AWS SAM Vorlage verweisen wir mithilfe der `CodeUri` Eigenschaft auf den lokalen Pfad zu unserem Lambda-Funktionscode. ``` AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 ... Resources: HelloWorldFunction: Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction Properties: CodeUri: hello_world/ Handler: app.lambda_handler Runtime: python3.9 ... ``` Als Nächstes erstellen wir unsere `sam build` Anwendung und bereiten sie auf die Bereitstellung vor. ``` $ sam build Starting Build use cache Manifest file is changed (new hash: 3298f13049d19cffaa37ca931dd4d421) or dependency folder (.aws-sam/deps/7896875f-9bcc-4350-8adb-2c1d543627a1) is missing for (HelloWorldFunction), downloading dependencies and copying/building source Building codeuri: /Users/.../demo/hello_world runtime: python3.9 metadata: {} architecture: x86_64 functions: HelloWorldFunction Running PythonPipBuilder:CleanUp Running PythonPipBuilder:ResolveDependencies Running PythonPipBuilder:CopySource Running PythonPipBuilder:CopySource Build Succeeded Built Artifacts : .aws-sam/build Built Template : .aws-sam/build/template.yaml ... ``` Als Nächstes starten wir, `sam deploy --guided` um unsere Anwendung bereitzustellen. ``` $ sam deploy --guided Configuring SAM deploy ====================== Looking for config file [samconfig.toml] : Found Reading default arguments : Success Setting default arguments for 'sam deploy' ========================================= Stack Name [demo]: ENTER AWS Region [us-west-2]: ENTER #Shows you resources changes to be deployed and require a 'Y' to initiate deploy Confirm changes before deploy [Y/n]: n #SAM needs permission to be able to create roles to connect to the resources in your template Allow SAM CLI IAM role creation [Y/n]: ENTER #Preserves the state of previously provisioned resources when an operation fails Disable rollback [y/N]: ENTER HelloWorldFunction may not have authorization defined, Is this okay? [y/N]: y Save arguments to configuration file [Y/n]: ENTER SAM configuration file [samconfig.toml]: ENTER SAM configuration environment [default]: ENTER Looking for resources needed for deployment: ... Saved arguments to config file Running 'sam deploy' for future deployments will use the parameters saved above. The above parameters can be changed by modifying samconfig.toml Learn more about samconfig.toml syntax at https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-config.html File with same data already exists at demo/da3c598813f1c2151579b73ad788cac8, skipping upload Deploying with following values =============================== Stack name : demo Region : us-west-2 Confirm changeset : False Disable rollback : False Deployment s3 bucket : aws-sam-cli-managed-default-samclisam-s3-demo-bucket-1a4x26zbcdkqr Capabilities : ["CAPABILITY_IAM"] Parameter overrides : {} Signing Profiles : {} Initiating deployment ===================== ... Waiting for changeset to be created.. CloudFormation stack changeset ------------------------------------------------------------------------------------------------- Operation LogicalResourceId ResourceType Replacement ------------------------------------------------------------------------------------------------- + Add HelloWorldFunctionHell AWS::Lambda::Permissio N/A oWorldPermissionProd n + Add HelloWorldFunctionRole AWS::IAM::Role N/A ... ------------------------------------------------------------------------------------------------- Changeset created successfully. arn:aws:cloudformation:us-west-2:012345678910:changeSet/samcli-deploy1680906292/1164338d-72e7-4593-a372-f2b3e67f542f 2023-04-07 12:24:58 - Waiting for stack create/update to complete CloudFormation events from stack operations (refresh every 5.0 seconds) ------------------------------------------------------------------------------------------------- ResourceStatus ResourceType LogicalResourceId ResourceStatusReason ------------------------------------------------------------------------------------------------- CREATE_IN_PROGRESS AWS::IAM::Role HelloWorldFunctionRole - CREATE_IN_PROGRESS AWS::IAM::Role HelloWorldFunctionRole Resource creation Initiated ... ------------------------------------------------------------------------------------------------- CloudFormation outputs from deployed stack ------------------------------------------------------------------------------------------------- Outputs ------------------------------------------------------------------------------------------------- Key HelloWorldFunctionIamRole Description Implicit IAM Role created for Hello World function Value arn:aws:iam::012345678910:role/demo-HelloWorldFunctionRole-VQ4CU7UY7S2K Key HelloWorldApi Description API Gateway endpoint URL for Prod stage for Hello World function Value https://satnon55e9.execute-api.us-west-2.amazonaws.com/Prod/hello/ Key HelloWorldFunction Description Hello World Lambda Function ARN Value arn:aws:lambda:us-west-2:012345678910:function:demo- HelloWorldFunction-G14inKTmSQvK ------------------------------------------------------------------------------------------------- Successfully created/updated stack - demo in us-west-2 ``` Während der Bereitstellung lädt der AWS SAMCLI automatisch unseren Lambda-Funktionscode auf Amazon S3 hoch und aktualisiert unsere Vorlage. Unsere geänderte Vorlage in der CloudFormation Konsole spiegelt den Amazon S3 S3-Bucket-Pfad wider. ``` AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 ... Resources: HelloWorldFunction: Type: AWS::Serverless::Function Properties: CodeUri: s3://aws-sam-cli-managed-default-samclisam-s3-demo-bucket-1a4x26zbcdkqr/demo/da3c598813f1c2151579b73ad788cac8 Handler: app.lambda_handler ... ``` ## Unterstützte Anwendungsfälle Das AWS SAMCLI kann diesen Vorgang für eine Reihe von Dateitypen, CloudFormation Ressourcentypen und CloudFormation Makros automatisch vereinfachen. ### Dateitypen Anwendungsdateien und Docker Bilder werden unterstützt. ### CloudFormation Ressourcentypen Im Folgenden finden Sie eine Liste der unterstützten Ressourcentypen und ihrer Eigenschaften: | Ressource | Eigenschaften | | --- | --- | | AWS::ApiGateway::RestApi | BodyS3Location | | AWS::ApiGatewayV2::Api | BodyS3Location | | AWS::AppSync:FunctionConfiguration | `CodeS3Location` `RequestMappingTemplateS3Location` `ResponseMappingTemplateS3Location` | | AWS::AppSync::GraphQLSchema | DefinitionS3Location | | AWS::AppSync::Resolver | `CodeS3Location` `RequestMappingTemplateS3Location` `ResponseMappingTemplateS3Location` | | AWS::CloudFormation::ModuleVersion | ModulePackage | | AWS::CloudFormation::ResourceVersion | SchemaHandlerPackage | | AWS::ECR::Repository | RepositoryName | | AWS::ElasticBeanstalk::ApplicationVersion | SourceBundle | | AWS::Glue::Job | Command.ScriptLocation | | AWS::Lambda::Function | `Code` `Code.ImageUri` | | AWS::Lambda::LayerVersion | Content | | AWS::Serverless::Api | DefinitionUri | | AWS::Serverless::Function | `CodeUri` `ImageUri` | | AWS::Serverless::GraphQLApi | `SchemaUri` `Function.CodeUri` `Resolver.CodeUri` | | AWS::Serverless::HttpApi | DefinitionUri | | AWS::Serverless::LayerVersion | ContentUri | | AWS::Serverless::StateMachine | DefinitionUri | | AWS::StepFunctions::StateMachine | DefinitionS3Location | ### CloudFormation Makros Dateien, auf die mit dem `AWS::Include` Transform-Makro verwiesen wird, werden unterstützt. ## Weitere Informationen Weitere Informationen zur `AWS::Include` Transformation finden Sie unter [ AWS::Include Transformation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/create-reusable-transform-function-snippets-and-add-to-your-template-with-aws-include-transform.html) im *AWS CloudFormation Benutzerhandbuch*. Ein Beispiel für die Verwendung der `AWS::Include` Transformation in einer AWS SAM Vorlage finden Sie im [API-Gateway-HTTP-API-zu-SQS-Muster](https://serverlessland.com/patterns/apigw-sqs) auf *Serverless Land*. # Generieren Sie eine CI/CD Starter-Pipeline mit AWS SAM Wenn Sie bereit sind, die Bereitstellung zu automatisieren, können Sie eine der AWS SAM Start-Pipeline-Vorlagen verwenden, um eine Bereitstellungspipeline für das CI/CD System zu generieren, das Sie verwenden möchten. Ihre Bereitstellungspipeline ist das, was Sie konfigurieren und verwenden, um die Bereitstellung Ihrer serverlosen Anwendung zu automatisieren. Eine Vorlage für die Starter-Pipeline ist vorkonfiguriert, damit Sie Ihre Bereitstellungspipeline für Ihre serverlose Anwendung schnell einrichten können. Mit einer Vorlage für eine Starter-Pipeline können Sie mithilfe des Befehls Pipelines innerhalb von Minuten generieren. [sam pipeline init](sam-cli-command-reference-sam-pipeline-init.md) Die Vorlagen für die Starter-Pipeline verwenden die vertraute JSON/YAML Syntax des CI/CD Systems und beinhalten bewährte Methoden wie die Verwaltung von Artefakten über mehrere Konten und Regionen hinweg und die Verwendung der Mindestanzahl an Berechtigungen, die für die Bereitstellung der Anwendung erforderlich sind. [Derzeit unterstützt die AWS SAM CLI die Generierung von CI/CD Starter-Pipeline-Konfigurationen für [Jenkins [AWS CodePipeline](https://aws.amazon.com/codepipeline)](https://www.jenkins.io/), [GitLab CI/CD](https://docs.gitlab.com/ee/ci/), [GitHub Actions](https://github.com/features/actions) und Bitbucket-Pipelines.](https://support.atlassian.com/bitbucket-cloud/docs/get-started-with-bitbucket-pipelines/) Hier sind die wichtigsten Aufgaben, die Sie ausführen müssen, um eine Starter-Pipeline-Konfiguration zu generieren: 1. **Infrastrukturressourcen erstellen** — Ihre Pipeline benötigt bestimmte AWS Ressourcen, z. B. den IAM-Benutzer und Rollen mit den erforderlichen Berechtigungen, einen Amazon S3 S3-Bucket und optional ein Amazon ECR-Repository. 1. **Connect dein Git-Repository mit deinem CI/CD System** — Dein CI/CD System muss wissen, welches Git-Repository die Ausführung der Pipeline auslöst. Beachten Sie, dass dieser Schritt möglicherweise nicht erforderlich ist, je nachdem, welche Kombination aus Git-Repository und CI/CD System Sie verwenden. 1. **Generieren Sie Ihre Pipeline-Konfiguration** — In diesem Schritt wird eine Starter-Pipeline-Konfiguration generiert, die zwei Bereitstellungsphasen umfasst. 1. **Übernehmen Sie Ihre Pipeline-Konfiguration in Ihr Git-Repository** — Dieser Schritt ist notwendig, um sicherzustellen, dass Ihr CI/CD System Ihre Pipeline-Konfiguration kennt. Er wird ausgeführt, wenn die Änderungen festgeschrieben wurden. Nachdem Sie die Starter-Pipeline-Konfiguration generiert und in Ihr Git-Repository übernommen haben, wird Ihre Pipeline automatisch ausgeführt, wenn jemand eine Codeänderung an dieses Repository festschreibt. Die Reihenfolge dieser Schritte und die Einzelheiten der einzelnen Schritte variieren je nach CI/CD-System: + Wenn Sie verwenden, finden Sie weitere Informationen AWS CodePipeline unter. [Generierung der Starter-Pipeline für AWS CodePipeline in AWS SAM](serverless-generating-example-ci-cd-codepipeline.md) + Wenn Sie Jenkins-, GitLab CI/CD-, GitHub Actions- oder Bitbucket-Pipelines verwenden, finden Sie weitere Informationen unter. [Wird verwendet AWS SAM , um Starter-Pipelines für Jenkins, GitLab CI/CD, Actions und Bitbucket-Pipelines zu generieren GitHub](serverless-generating-example-ci-cd-others.md) # Generierung der Starter-Pipeline für AWS CodePipeline in AWS SAM Um eine Starter-Pipeline-Konfiguration für zu generieren AWS CodePipeline, führen Sie die folgenden Aufgaben in dieser Reihenfolge aus: 1. Infrastrukturressourcen erstellen 1. Generieren Sie die Pipeline-Konfiguration 1. Übergeben Sie Ihre Pipeline-Konfiguration auf Git 1. Connect dein Git-Repository mit deinem CI/CD System **Anmerkung** Das folgende Verfahren verwendet zwei AWS SAMCLI Befehle, `sam pipeline bootstrap` und`sam pipeline init`. Der Grund dafür, dass es zwei Befehle gibt, ist der Anwendungsfall, in dem Administratoren (d. h. Benutzer, die eine Berechtigung zum Einrichten von AWS Infrastrukturressourcen wie IAM-Benutzern und -Rollen benötigen) mehr Rechte haben als Entwickler (d. h. Benutzer, die lediglich die Erlaubnis benötigen, einzelne Pipelines einzurichten, aber nicht die erforderlichen AWS Infrastrukturressourcen). ## Schritt 1: Infrastrukturressourcen erstellen Verwendete Pipelines AWS SAM benötigen bestimmte AWS Ressourcen, z. B. einen IAM-Benutzer und Rollen mit den erforderlichen Berechtigungen, einen Amazon S3 S3-Bucket und optional ein Amazon ECR-Repository. Sie benötigen für jede Bereitstellungsphase der Pipeline eine Reihe von Infrastrukturressourcen. Sie können den folgenden Befehl ausführen, um bei dieser Einrichtung zu helfen: ``` sam pipeline bootstrap ``` **Anmerkung** Führen Sie den vorherigen Befehl für jede Bereitstellungsphase Ihrer Pipeline aus. ## Schritt 2: Generieren Sie die Pipeline-Konfiguration Führen Sie den folgenden Befehl aus, um die Pipeline-Konfiguration zu generieren: ``` sam pipeline init ``` ## Schritt 3: Übernehmen Sie Ihre Pipeline-Konfiguration in das Git-Repository Dieser Schritt ist notwendig, um sicherzustellen, dass Ihr CI/CD System Ihre Pipeline-Konfiguration kennt. Er wird ausgeführt, wenn die Änderungen übernommen wurden. ## Schritt 4: Connect dein Git-Repository mit deinem CI/CD System Denn AWS CodePipeline Sie können jetzt die Verbindung herstellen, indem Sie den folgenden Befehl ausführen: ``` sam deploy -t codepipeline.yaml --stack-name --capabilities=CAPABILITY_IAM --region ``` Wenn du Bitbucket GitHub verwendest, stelle nach dem vorherigen Ausführen des **sam deploy** Befehls die Verbindung her, indem du die Schritte unter **So stellst du eine Verbindung her**, die du im Thema [Eine ausstehende Verbindung aktualisieren](https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-update.html) im *Benutzerhandbuch für die Developer Tools-Konsole* findest. Speichere außerdem eine Kopie der `CodeStarConnectionArn` aus der Ausgabe des **sam deploy** Befehls, da du sie benötigst, wenn du sie AWS CodePipeline mit einem anderen Zweig als `main` verwenden möchtest. ## Konfiguration anderer Zweige AWS CodePipeline Verwendet standardmäßig den `main` Zweig mit AWS SAM. Wenn Sie einen anderen Zweig als verwenden möchten`main`, müssen Sie den **sam deploy** Befehl erneut ausführen. Beachten Sie, dass Sie je nachdem, welches Git-Repository Sie verwenden, möglicherweise auch Folgendes angeben müssen`CodeStarConnectionArn`: ``` # For GitHub and Bitbucket sam deploy -t codepipeline.yaml --stack-name --capabilities=CAPABILITY_IAM --parameter-overrides="FeatureGitBranch= CodeStarConnectionArn=" # For AWS CodeCommit sam deploy -t codepipeline.yaml --stack-name --capabilities=CAPABILITY_IAM --parameter-overrides="FeatureGitBranch=" ``` ## Weitere Informationen Ein praktisches Beispiel für die Einrichtung einer CI/CD Pipeline finden Sie unter [CI/CD mit AWS CodePipeline](https://catalog.workshops.aws/complete-aws-sam/en-US/module-4-cicd) in *The* Complete Workshop. AWS SAM # Wird verwendet AWS SAM , um Starter-Pipelines für Jenkins, GitLab CI/CD, Actions und Bitbucket-Pipelines zu generieren GitHub Um eine Starter-Pipeline-Konfiguration für Jenkins-, GitLab CI/CD-, GitHub Actions- oder Bitbucket-Pipelines zu generieren, führe die folgenden Aufgaben in dieser Reihenfolge aus: 1. Infrastrukturressourcen erstellen 1. Connect dein Git-Repository mit deinem CI/CD System 1. Erstellen Sie Objekte mit Anmeldeinformationen 1. Generieren Sie die Pipeline-Konfiguration 1. Übergeben Sie Ihre Pipeline-Konfiguration in das Git-Repository **Anmerkung** Das folgende Verfahren verwendet zwei AWS SAMCLI Befehle, `sam pipeline bootstrap` und`sam pipeline init`. Der Grund dafür, dass es zwei Befehle gibt, ist der Anwendungsfall, in dem Administratoren (d. h. Benutzer, die eine Berechtigung zum Einrichten von AWS Infrastrukturressourcen wie IAM-Benutzern und -Rollen benötigen) mehr Rechte haben als Entwickler (d. h. Benutzer, die lediglich die Erlaubnis benötigen, einzelne Pipelines einzurichten, aber nicht die erforderlichen AWS Infrastrukturressourcen). ## Schritt 1: Infrastrukturressourcen erstellen Verwendete Pipelines AWS SAM benötigen bestimmte AWS Ressourcen, z. B. einen IAM-Benutzer und Rollen mit den erforderlichen Berechtigungen, einen Amazon S3 S3-Bucket und optional ein Amazon ECR-Repository. Sie benötigen für jede Bereitstellungsphase der Pipeline eine Reihe von Infrastrukturressourcen. Sie können den folgenden Befehl ausführen, um bei dieser Einrichtung zu helfen: ``` sam pipeline bootstrap ``` **Anmerkung** Führen Sie den vorherigen Befehl für jede Bereitstellungsphase Ihrer Pipeline aus. Sie müssen die AWS Anmeldeinformationen (Schlüssel-ID und geheimer Schlüssel) für die Pipeline-Benutzer für jede Bereitstellungsphase Ihrer Pipeline erfassen, da sie für nachfolgende Schritte benötigt werden. ## Schritt 2: Connect dein Git-Repository mit deinem CI/CD System Das Verbinden Ihres Git-Repositorys mit Ihrem CI/CD System ist notwendig, damit das CI/CD System auf den Quellcode Ihrer Anwendung für Builds und Deployments zugreifen kann. **Anmerkung** Sie können diesen Schritt überspringen, wenn Sie eine der folgenden Kombinationen verwenden, da die Verbindung automatisch für Sie hergestellt wird: GitHub Aktionen mit dem GitHub Repository GitLab CI/CD mit Repository GitLab Bitbucket-Pipelines mit einem Bitbucket-Repository Um dein Git-Repository mit deinem CI/CD System zu verbinden, führe einen der folgenden Schritte aus: + Wenn Sie Jenkins verwenden, lesen Sie in der [Jenkins-Dokumentation](https://www.jenkins.io/doc/book/pipeline/multibranch/) unter „Hinzufügen einer Branch-Quelle“ nach. + Wenn du GitLab CI/CD und ein anderes Git-Repository als verwendest GitLab, lies die [GitLabDokumentation](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/) unter „Ein externes Repository verbinden“. ## Schritt 3: Objekte mit Anmeldeinformationen erstellen Jedes CI/CD System hat seine eigene Methode zur Verwaltung der Anmeldeinformationen, die das CI/CD System für den Zugriff auf Ihr Git-Repository benötigt. Gehen Sie wie folgt vor, um die erforderlichen Objekte mit Anmeldeinformationen zu erstellen: + Wenn Sie Jenkins verwenden, erstellen Sie ein einzelnes „Credential“, das sowohl die Schlüssel-ID als auch den geheimen Schlüssel speichert. **Folgen Sie den Anweisungen im AWS SAM Blog „[Eine Jenkins-Pipeline mit erstellen“ im Abschnitt „Jenkins](https://aws.amazon.com/blogs/compute/building-a-jenkins-pipeline-with-aws-sam/) konfigurieren“.** Für den nächsten Schritt benötigen Sie die „Credential ID“. + Wenn Sie GitLab CI/CD verwenden, erstellen Sie zwei „geschützte Variablen“, jeweils eine für die Schlüssel-ID und den geheimen Schlüssel. Folgen Sie den Anweisungen in der [GitLab Dokumentation](https://docs.gitlab.com/ee/ci/variables/) — für den nächsten Schritt benötigen Sie zwei „variable Schlüssel“. + Wenn Sie GitHub Aktionen verwenden, erstellen Sie zwei „verschlüsselte Geheimnisse“, jeweils einen für Schlüssel und geheimen Schlüssel. Folgen Sie den Anweisungen in der [GitHubDokumentation](https://docs.github.com/en/actions/reference/encrypted-secrets). Für den nächsten Schritt benötigen Sie zwei „geheime Namen“. + Wenn du Bitbucket-Pipelines verwendest, erstelle zwei „sichere Variablen“, jeweils eine für die Schlüssel-ID und den geheimen Schlüssel. Folge den Anweisungen in den Abschnitten [Variablen und Geheimnisse](https://support.atlassian.com/bitbucket-cloud/docs/variables-and-secrets) — für den nächsten Schritt benötigst du zwei „geheime Namen“. ## Schritt 4: Generieren Sie die Pipeline-Konfiguration Führen Sie den folgenden Befehl aus, um die Pipeline-Konfiguration zu generieren. Sie müssen das Anmeldeinformationsobjekt eingeben, das Sie im vorherigen Schritt erstellt haben: ``` sam pipeline init ``` ## Schritt 5: Übernehmen Sie Ihre Pipeline-Konfiguration in das Git-Repository Dieser Schritt ist notwendig, um sicherzustellen, dass Ihr CI/CD System Ihre Pipeline-Konfiguration kennt. Er wird ausgeführt, wenn die Änderungen übernommen wurden. ## Weitere Informationen Ein praktisches Beispiel für die Einrichtung einer CI/CD Pipeline mit GitHub Actions finden Sie unter [CI/CD with GitHub](https://s12d.com/sam-ws-en-gh) in *The* Complete Workshop. AWS SAM # So passen Sie Starter-Pipelines an mit AWS SAM Als CI/CD Administrator möchten Sie möglicherweise eine Vorlage für die Starter-Pipeline und die zugehörigen geführten Eingabeaufforderungen anpassen, sodass Entwickler in Ihrer Organisation Pipeline-Konfigurationen erstellen können. The AWS SAMCLI verwendet Cookiecutter-Vorlagen bei der Erstellung von Starter-Vorlagen. [Einzelheiten zu Ausstechvorlagen finden Sie unter Cookiecutter.](https://cookiecutter.readthedocs.io/en/latest/README.html) Mit dem Befehl können Sie auch die Eingabeaufforderungen anpassen, die Benutzern beim Erstellen von Pipeline-Konfigurationen AWS SAMCLI angezeigt werden. `sam pipeline init` Gehen Sie wie folgt vor, um Benutzeraufforderungen anzupassen: 1. **`questions.json`Datei erstellen — Die `questions.json` Datei** muss sich im Stammverzeichnis des Projekt-Repositorys befinden. Dies ist das gleiche Verzeichnis wie die Datei. `cookiecutter.json` Das Schema für die `questions.json` Datei finden Sie unter [questions.json.schema](https://github.com/aws/aws-sam-cli/blob/2b831b29f76ac9c4e0cbcbd68b37f8f664e136d8/samcli/lib/pipeline/init/questions.json.schema). [Eine Beispieldatei finden Sie unter questions.json. `questions.json`](https://github.com/aws/aws-sam-cli-pipeline-init-templates/blob/main/Jenkins/two-stage-pipeline-template/questions.json) 1. **Zuordnen von Frageschlüsseln zu Cookiecutter-Namen** — Jedes Objekt in der `questions.json` Datei benötigt einen Schlüssel, der einem Namen in der Cookiecutter-Vorlage entspricht. Dieser Schlüsselabgleich ist die Art und Weise, wie der AWS SAMCLI Maps-Benutzer Antworten auf die Cookie-Cutter-Vorlage eingibt. Beispiele für diese Tastenkombination finden Sie im [Beispieldateien](#serverless-customizing-starter-pipelines-example-files) Abschnitt weiter unten in diesem Thema. 1. **`metadata.json`Datei erstellen — Geben** Sie die Anzahl der Stufen an, die die Pipeline in der `metadata.json` Datei enthalten soll. Die Anzahl der Stufen gibt dem `sam pipeline init` Befehl an, für wie viele Stufen Informationen angefordert werden sollen, oder, im Fall der `--bootstrap` Option, für wie viele Stufen Infrastrukturressourcen erstellt werden sollen. [Eine `metadata.json` Beispieldatei, die eine Pipeline mit zwei Stufen deklariert, finden Sie unter metadata.json.](https://github.com/aws/aws-sam-cli-pipeline-init-templates/blob/main/Jenkins/two-stage-pipeline-template/metadata.json) ## Beispielprojekte Hier sind Beispielprojekte, die jeweils eine Cookiecutter-Vorlage, eine `questions.json` Datei und eine `metadata.json` Datei enthalten: + [Jenkins-Beispiel: Zweistufige Jenkins-Pipeline-Vorlage](https://github.com/aws/aws-sam-cli-pipeline-init-templates/tree/main/Jenkins/two-stage-pipeline-template) + CodePipeline [Beispiel: Zweistufige Pipeline-Vorlage CodePipeline ](https://github.com/aws/aws-sam-cli-pipeline-init-templates/tree/main/AWS-CodePipeline/two-stage-pipeline-template) ## Beispieldateien Die folgenden Dateien zeigen, wie Fragen in der `questions.json` Datei mit Einträgen in der Cookiecutter-Vorlagendatei verknüpft sind. Beachten Sie, dass es sich bei diesen Beispielen um Dateifragmente und nicht um vollständige Dateien handelt. Beispiele für vollständige Dateien finden Sie im [Beispielprojekte](#serverless-customizing-starter-pipelines-example-projects) Abschnitt weiter oben in diesem Thema. Beispiel **`questions.json`**: ``` { "questions": [{ "key": "intro", "question": "\nThis template configures a pipeline that deploys a serverless application to a testing and a production stage.\n", "kind": "info" }, { "key": "pipeline_user_jenkins_credential_id", "question": "What is the Jenkins credential ID (via Jenkins plugin \"aws-credentials\") for pipeline user access key?", "isRequired": true }, { "key": "sam_template", "question": "What is the template file path?", "default": "template.yaml" }, { ... ``` Beispiel **`cookiecutter.json`**: ``` { "outputDir": "aws-sam-pipeline", "pipeline_user_jenkins_credential_id": "", "sam_template": "", ... ``` Beispiel **`Jenkinsfile`**: ``` pipeline { agent any environment { PIPELINE_USER_CREDENTIAL_ID = '{{cookiecutter.pipeline_user_jenkins_credential_id}}' SAM_TEMPLATE = '{{cookiecutter.sam_template}}' ... ``` # Automatisieren Sie die Bereitstellung Ihrer AWS SAM Anwendung Wie Sie die Bereitstellung Ihrer AWS SAM Anwendung automatisieren, hängt vom verwendeten CI/CD System ab. AWS SAM Aus diesem Grund zeigen Ihnen die Beispiele in diesem Abschnitt, wie Sie verschiedene CI/CD Systeme konfigurieren, um die Erstellung serverloser Anwendungen in einem AWS SAM Build-Container-Image zu automatisieren. Diese Build-Container-Images erleichtern das Erstellen und Verpacken serverloser Anwendungen mithilfe von. AWS SAMCLI Die Verfahren für Ihre bestehende CI/CD Pipeline zur Bereitstellung serverloser Anwendungen unterscheiden AWS SAM sich geringfügig, je nachdem, welches CI/CD System Sie verwenden. Die folgenden Themen enthalten Beispiele für die Konfiguration Ihres CI/CD Systems für die Erstellung serverloser Anwendungen in einem AWS SAM Build-Container-Image: **Topics** + [Wird AWS CodePipeline zur Bereitstellung mit verwendet AWS SAM](deploying-using-codepipeline.md) + [Verwenden von Bitbucket-Pipelines für die Bereitstellung mit AWS SAM](deploying-using-bitbucket.md) + [Verwenden von Jenkins für die Bereitstellung mit AWS SAM](deploying-using-jenkins.md) + [Verwendung von GitLab CI/CD für die Bereitstellung mit AWS SAM](deploying-using-gitlab.md) + [Verwenden von GitHub Aktionen zur Bereitstellung mit AWS SAM](deploying-using-github.md) # Wird AWS CodePipeline zur Bereitstellung mit verwendet AWS SAM Um Ihre [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)Pipeline so zu konfigurieren, dass die Erstellung und Bereitstellung Ihrer AWS SAM Anwendung automatisiert wird, müssen Ihre CloudFormation Vorlage und `buildspec.yml` Datei Zeilen enthalten, die Folgendes bewirken: 1. Verweisen Sie aus den verfügbaren Images auf ein Build-Container-Image mit der erforderlichen Laufzeit. Im folgenden Beispiel wird das `public.ecr.aws/sam/build-nodejs20.x` Build-Container-Image verwendet. 1. Konfigurieren Sie die Pipeline-Stufen, um die erforderlichen AWS SAM Befehlszeilenschnittstellenbefehle (CLI) auszuführen. Im folgenden Beispiel AWS SAMCLI werden zwei Befehle ausgeführt: **sam build** und **sam deploy** (mit den erforderlichen Optionen). In diesem Beispiel wird vorausgesetzt, dass Sie alle Funktionen und Ebenen in Ihrer AWS SAM Vorlagendatei mit deklariert haben`runtime: nodejs20.x`. **CloudFormation Vorlagenausschnitt:** ``` CodeBuildProject: Type: AWS::CodeBuild::Project Properties: Environment: ComputeType: BUILD_GENERAL1_SMALL Image: public.ecr.aws/sam/build-nodejs20.x Type: LINUX_CONTAINER ... ``` **`buildspec.yml`Schnipsel:** ``` version: 0.2 phases: build: commands: - sam build - sam deploy --no-confirm-changeset --no-fail-on-empty-changeset ``` Eine Liste der verfügbaren Build-Container-Images von Amazon Elastic Container Registry (Amazon ECR) für verschiedene Laufzeiten finden Sie unter. [Bild-Repositorys für AWS SAM](serverless-image-repositories.md) # Verwenden von Bitbucket-Pipelines für die Bereitstellung mit AWS SAM Um deine [Bitbucket-Pipeline](https://support.atlassian.com/bitbucket-cloud/docs/get-started-with-bitbucket-pipelines/) so zu konfigurieren, dass sie den Build und die Bereitstellung deiner AWS SAM Anwendung automatisiert, muss deine `bitbucket-pipelines.yml` Datei Zeilen enthalten, die Folgendes tun: 1. Verweise auf ein Build-Container-Image mit der erforderlichen Laufzeit aus den verfügbaren Images. Im folgenden Beispiel wird das `public.ecr.aws/sam/build-nodejs20.x` Build-Container-Image verwendet. 1. Konfigurieren Sie die Pipeline-Stufen, um die erforderlichen AWS SAM Befehlszeilenschnittstellenbefehle (CLI) auszuführen. Im folgenden Beispiel AWS SAMCLI werden zwei Befehle ausgeführt: **sam build** und **sam deploy** (mit den erforderlichen Optionen). In diesem Beispiel wird vorausgesetzt, dass Sie alle Funktionen und Ebenen in Ihrer AWS SAM Vorlagendatei mit deklariert haben`runtime: nodejs20.x`. ``` image: public.ecr.aws/sam/build-nodejs20.x pipelines: branches: main: # branch name - step: name: Build and Package script: - sam build - sam deploy --no-confirm-changeset --no-fail-on-empty-changeset ``` Eine Liste der verfügbaren Build-Container-Images von Amazon Elastic Container Registry (Amazon ECR) für verschiedene Laufzeiten finden Sie unter. [Bild-Repositorys für AWS SAM](serverless-image-repositories.md) # Verwenden von Jenkins für die Bereitstellung mit AWS SAM Um Ihre [Jenkins-Pipeline](https://www.jenkins.io/) so zu konfigurieren, dass sie den Build und die Bereitstellung Ihrer AWS SAM Anwendung automatisiert, `Jenkinsfile` müssen Sie Zeilen enthalten, die Folgendes tun: 1. Verweisen Sie aus den verfügbaren Images auf ein Build-Container-Image mit der erforderlichen Laufzeit. Im folgenden Beispiel wird das `public.ecr.aws/sam/build-nodejs20.x` Build-Container-Image verwendet. 1. Konfigurieren Sie die Pipeline-Stufen, um die erforderlichen AWS SAM Befehlszeilenschnittstellenbefehle (CLI) auszuführen. Im folgenden Beispiel AWS SAMCLI werden zwei Befehle ausgeführt: **sam build** und **sam deploy** (mit den erforderlichen Optionen). In diesem Beispiel wird vorausgesetzt, dass Sie alle Funktionen und Ebenen in Ihrer AWS SAM Vorlagendatei mit deklariert haben`runtime: nodejs20.x`. ``` pipeline { agent { docker { image 'public.ecr.aws/sam/build-nodejs20.x' } } stages { stage('build') { steps { sh 'sam build' sh 'sam deploy --no-confirm-changeset --no-fail-on-empty-changeset' } } } } ``` Eine Liste der verfügbaren Build-Container-Images von Amazon Elastic Container Registry (Amazon ECR) für verschiedene Laufzeiten finden Sie unter. [Bild-Repositorys für AWS SAM](serverless-image-repositories.md) # Verwendung von GitLab CI/CD für die Bereitstellung mit AWS SAM Um Ihre [GitLab](https://about.gitlab.com)Pipeline so zu konfigurieren, dass der Build und die Bereitstellung Ihrer AWS SAM Anwendung automatisiert werden, muss Ihre `gitlab-ci.yml` Datei Zeilen enthalten, die Folgendes tun: 1. Verweisen Sie aus den verfügbaren Images auf ein Build-Container-Image mit der erforderlichen Laufzeit. Im folgenden Beispiel wird das `public.ecr.aws/sam/build-nodejs20.x` Build-Container-Image verwendet. 1. Konfigurieren Sie die Pipeline-Stufen, um die erforderlichen AWS SAM Befehlszeilenschnittstellenbefehle (CLI) auszuführen. Im folgenden Beispiel AWS SAMCLI werden zwei Befehle ausgeführt: **sam build** und **sam deploy** (mit den erforderlichen Optionen). In diesem Beispiel wird vorausgesetzt, dass Sie alle Funktionen und Ebenen in Ihrer AWS SAM Vorlagendatei mit deklariert haben`runtime: nodejs20.x`. ``` image: public.ecr.aws/sam/build-nodejs20.x deploy: script: - sam build - sam deploy --no-confirm-changeset --no-fail-on-empty-changeset ``` Eine Liste der verfügbaren Build-Container-Images von Amazon Elastic Container Registry (Amazon ECR) für verschiedene Laufzeiten finden Sie unter. [Bild-Repositorys für AWS SAM](serverless-image-repositories.md) # Verwenden von GitHub Aktionen zur Bereitstellung mit AWS SAM Um Ihre [GitHub](https://github.com/)Pipeline so zu konfigurieren, dass der Build und die Bereitstellung Ihrer AWS SAM Anwendung automatisiert werden, müssen Sie zunächst die AWS SAM Befehlszeilenschnittstelle (CLI) auf Ihrem Host installieren. Sie können [GitHub Aktionen](https://github.com/features/actions) in Ihrem GitHub Workflow verwenden, um Ihnen bei dieser Einrichtung zu helfen. Der folgende GitHub Beispiel-Workflow richtet mithilfe einer Reihe von GitHub Aktionen einen Ubuntu-Host ein und führt dann AWS SAMCLI Befehle zum Erstellen und Bereitstellen einer AWS SAM Anwendung aus: ``` on: push: branches: - main jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-python@v3 - uses: aws-actions/setup-sam@v2 - uses: aws-actions/configure-aws-credentials@v1 with: aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} aws-region: us-east-2 - run: sam build --use-container - run: sam deploy --no-confirm-changeset --no-fail-on-empty-changeset ``` Eine Liste der verfügbaren Build-Container-Images von Amazon Elastic Container Registry (Amazon ECR) für verschiedene Laufzeiten finden Sie unter. [Bild-Repositorys für AWS SAM](serverless-image-repositories.md) # So verwenden Sie die OIDC-Authentifizierung mit Pipelines AWS SAM AWS Serverless Application Model (AWS SAM) unterstützt OpenID Connect (OIDC) -Benutzerauthentifizierung für Bitbucket, GitHub Actions sowie GitLab Continuous Integration und Continuous Delivery (CI/CD) platforms. With this support, you can use authorized CI/CDBenutzerkonten von jeder dieser Plattformen) zur Verwaltung deiner serverlosen Anwendungspipelines. Andernfalls müsstest du mehrere AWS Identity and Access Management (IAM-) Benutzer erstellen und verwalten, um den Zugriff auf Pipelines zu kontrollieren. AWS SAM ## Richten Sie OIDC mit Pipeline ein AWS SAM Gehen Sie während des `sam pipeline bootstrap` Konfigurationsprozesses wie folgt vor, um OIDC mit Ihrer Pipeline einzurichten. AWS SAM 1. **Wenn Sie aufgefordert werden, einen Identitätsanbieter auszuwählen, wählen Sie OIDC aus.** 1. Wählen Sie als Nächstes einen unterstützten OIDC-Anbieter aus. 1. Geben Sie die URL des OIDC-Anbieters ein, beginnend mit. **https://** **Anmerkung** AWS SAM verweist bei der Generierung des `AWS::IAM::OIDCProvider` Ressourcentyps auf diese URL. 1. Folgen Sie anschließend den Anweisungen und geben Sie die CI/CD Plattforminformationen ein, die für den Zugriff auf die ausgewählte Plattform erforderlich sind. Diese Details variieren je nach Plattform und können Folgendes beinhalten: + OIDC-Client-ID. + Name des Code-Repositorys oder UUID (Universally Unique Identifier). + Gruppen- oder Organisationsname, der dem Repository zugeordnet ist. + GitHub Organisation, zu der das Code-Repository gehört. + GitHub Name des Repositorys. + Zweig, von dem aus die Bereitstellungen erfolgen. 1. AWS SAM zeigt eine Zusammenfassung der eingegebenen OIDC-Konfiguration an. Geben Sie die Nummer für eine Einstellung ein, um sie zu bearbeiten, oder drücken Sie, Enter um fortzufahren. 1. Wenn Sie aufgefordert werden, die Erstellung der Ressourcen zu bestätigen, die zur Unterstützung der eingegebenen OIDC-Verbindung erforderlich sind, drücken Sie, Y um fortzufahren. AWS SAM generiert eine `AWS::IAM::OIDCProvider` AWS CloudFormation Ressource mit der angegebenen Konfiguration, die die Rolle der Pipeline-Ausführung übernimmt. Weitere Informationen zu diesem CloudFormation Ressourcentyp finden Sie unter [AWS: :IAM:: OIDCProvider](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-oidcprovider.html) im *AWS CloudFormation Benutzerhandbuch*. **Anmerkung** Wenn die Identitätsanbieter-Ressource (IdP) bereits in Ihrer vorhanden ist AWS-Konto, AWS SAM verweist Sie darauf, anstatt eine neue Ressource zu erstellen. ## Beispiel Im Folgenden finden Sie ein Beispiel für die Einrichtung von OIDC mit Pipeline. AWS SAM ``` Select a permissions provider: 1 - IAM (default) 2 - OpenID Connect (OIDC) Choice (1, 2): 2 Select an OIDC provider: 1 - GitHub Actions 2 - GitLab 3 - Bitbucket Choice (1, 2, 3): 1 Enter the URL of the OIDC provider [https://token.actions.githubusercontent.com]: Enter the OIDC client ID (sometimes called audience) [sts.amazonaws.com]: Enter the GitHub organization that the code repository belongs to. If there is no organization enter your username instead: my-org Enter GitHub repository name: testing Enter the name of the branch that deployments will occur from [main]: [3] Reference application build resources Enter the pipeline execution role ARN if you have previously created one, or we will create one for you []: Enter the CloudFormation execution role ARN if you have previously created one, or we will create one for you []: Please enter the artifact bucket ARN for your Lambda function. If you do not have a bucket, we will create one for you []: Does your application contain any IMAGE type Lambda functions? [y/N]: [4] Summary Below is the summary of the answers: 1 - Account: 123456 2 - Stage configuration name: dev 3 - Region: us-east-1 4 - OIDC identity provider URL: https://token.actions.githubusercontent.com 5 - OIDC client ID: sts.amazonaws.com 6 - GitHub organization: my-org 7 - GitHub repository: testing 8 - Deployment branch: main 9 - Pipeline execution role: [to be created] 10 - CloudFormation execution role: [to be created] 11 - Artifacts bucket: [to be created] 12 - ECR image repository: [skipped] Press enter to confirm the values above, or select an item to edit the value: This will create the following required resources for the 'dev' configuration: - IAM OIDC Identity Provider - Pipeline execution role - CloudFormation execution role - Artifact bucket Should we proceed with the creation? [y/N]: ``` ## Weitere Informationen Weitere Informationen zur Verwendung von OIDC mit AWS SAM Pipeline finden Sie unter. [sam pipeline bootstrap](sam-cli-command-reference-sam-pipeline-bootstrap.md)