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. # Tutorial: Einen CodeBuild -gehosteten Runner GitLab konfigurieren Dieses Tutorial zeigt Ihnen, wie Sie Ihre CodeBuild Projekte für die Ausführung von GitLab CI/CD-Pipeline-Jobs konfigurieren. Weitere Informationen zur Verwendung von GitLab oder zur GitLab Selbstverwaltung mit finden Sie CodeBuild unter. [Selbstverwaltete Läufer GitLab in AWS CodeBuild](gitlab-runner.md) Um dieses Tutorial abzuschließen, müssen Sie zunächst: + Stellen Sie eine Connect mit einer OAuth App her, indem Sie CodeConnections Beachten Sie, dass Sie beim Herstellen einer Verbindung mit einer OAuth App die CodeBuild Konsole verwenden müssen. Weitere Anweisungen finden Sie unter [GitLab Zugriff in CodeBuild](access-tokens-gitlab-overview.md). + Connect CodeBuild zu Ihrem GitLab Konto her. Dazu können Sie in der Konsole einen Quellanbieter hinzufügen GitLab . Detaillierte Anweisungen finden Sie unter [GitLab Zugriff in CodeBuild](access-tokens-gitlab-overview.md). **Anmerkung** Dies ist nur erforderlich, wenn Sie noch keine Verbindung GitLab zu Ihrem Konto hergestellt haben. Für diese Funktion sind zusätzliche CodeBuild Berechtigungen erforderlich, z. B. `create_runner` und `manage_runner` von der GitLab OAuth App. Wenn CodeConnections für ein bestimmtes GitLab Konto bereits solche vorhanden sind, werden nicht automatisch Aktualisierungen der Berechtigungen angefordert. Dazu können Sie zur CodeConnections Konsole gehen und eine Dummy-Verbindung zu demselben GitLab Konto herstellen, um die erneute Autorisierung auszulösen und die zusätzlichen Berechtigungen zu erhalten. Damit können alle vorhandenen Verbindungen die Runner-Funktion nutzen. Sobald der Vorgang abgeschlossen ist, können Sie die Dummy-Verbindung löschen. ## Schritt 1: Erstellen Sie ein CodeBuild Projekt mit einem Webhook In diesem Schritt erstellen Sie ein CodeBuild Projekt mit einem Webhook und überprüfen es in der GitLab Konsole. **Um ein CodeBuild Projekt mit einem Webhook zu erstellen** 1. Öffnen Sie die AWS CodeBuild Konsole unter [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home). 1. Erstellen Sie ein Build-Projekt. Weitere Informationen finden Sie unter [Erstellen Sie ein Build-Projekt (Konsole)](create-project.md#create-project-console) und [Ausführen eines Build (Konsole)](run-build-console.md). **Wählen Sie unter **Projekttyp** die Option Runner-Projekt aus.** + In **Runner**: + Wählen Sie für den **Runner-Anbieter** die Option **GitLab**. + Wählen Sie für **Credential** eine der folgenden Optionen aus: + Wählen Sie **Standard-Quellanmeldedaten aus.** Standardverbindung wendet eine GitLab Standardverbindung für alle Projekte an. + Wählen Sie **Benutzerdefinierte Quellanmeldedaten.** Benutzerdefinierte Verbindung wendet eine benutzerdefinierte GitLab Verbindung an, die die Standardeinstellungen Ihres Kontos überschreibt. **Anmerkung** Wenn Sie noch keine Verbindung zu Ihrem Anbieter hergestellt haben, müssen Sie eine neue GitLab Verbindung erstellen. Detaillierte Anweisungen finden Sie unter [Connect CodeBuild GitLab](access-tokens-gitlab-overview.md#connections-gitlab). + Wählen Sie als **Standort für Runner** die Option **Repository** aus. + Wählen Sie für **Repository** den Namen Ihres Projekts aus, GitLab indem Sie den Projektpfad mit dem Namespace angeben. + In **Environment** (Umgebung): + Wählen Sie ein unterstütztes **Umgebungs-Image** und **Compute** aus. Beachten Sie, dass Sie die Möglichkeit haben, die Image- und Instanzeinstellungen zu überschreiben, indem Sie ein Label in Ihrer GitLab CI/CD-Pipeline YAML verwenden. Weitere Informationen finden Sie unter [Schritt 2: Erstellen Sie eine .gitlab-ci.yml-Datei in Ihrem Repository](#sample-gitlab-runners-gitlab-ci). + In **Buildspec (Build-Spezifikation)**: + Beachten Sie, dass Ihre Buildspec ignoriert wird, sofern `buildspec-override:true` sie nicht als Label hinzugefügt wird. Stattdessen überschreibt sie sie, CodeBuild um Befehle zu verwenden, die den selbstverwalteten Runner einrichten. 1. Fahren Sie mit den Standardwerten fort und wählen Sie dann **Build-Projekt erstellen**. 1. Öffnen Sie die GitLab Konsole unter, `https://gitlab.com/user-name/repository-name/-/hooks` um zu überprüfen, ob ein Webhook erstellt wurde und für die Übermittlung von **Workflow-Auftragsereignissen** aktiviert ist. ## Schritt 2: Erstellen Sie eine .gitlab-ci.yml-Datei in Ihrem Repository In diesem Schritt erstellen Sie eine `.gitlab-ci.yml` Datei, um Ihre Build-Umgebung [https://gitlab.com/](https://gitlab.com/)zu konfigurieren und selbstverwaltete Runner darin zu verwenden. GitLab CodeBuild Weitere Informationen finden Sie unter [Verwenden von selbstverwalteten Runnern](https://docs.gitlab.com/runner/#use-self-managed-runners). ### Aktualisieren Sie Ihre GitLab CI/CD-Pipeline YAML Navigieren Sie zu Ihrem `https://gitlab.com/user-name/project-name/-/tree/branch-name` Repository und erstellen Sie eine `.gitlab-ci.yml` Datei darin. Sie können Ihre Build-Umgebung konfigurieren, indem Sie einen der folgenden Schritte ausführen: + Sie können den CodeBuild Projektnamen angeben. In diesem Fall verwendet der Build Ihre bestehende Projektkonfiguration für Rechenleistung, Image, Image-Version und Instanzgröße. Der Projektname wird benötigt, um die AWS zugehörigen Einstellungen Ihres GitLab Jobs mit einem bestimmten CodeBuild Projekt zu verknüpfen. Durch die Aufnahme des Projektnamens in die YAML können Jobs mit den richtigen Projekteinstellungen aufgerufen werden. CodeBuild ``` tags: - codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME ``` `$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME`ist erforderlich, um den Build bestimmten Pipeline-Jobausführungen zuzuordnen und den Build zu beenden, wenn der Pipeline-Lauf abgebrochen wird. **Anmerkung** Stellen Sie sicher, dass Ihr Name ** mit dem Namen des Projekts übereinstimmt, in dem Sie es erstellt haben CodeBuild. Wenn es nicht übereinstimmt, CodeBuild wird der Webhook nicht verarbeitet und die GitLab CI/CD-Pipeline kann hängen bleiben. Das Folgende ist ein Beispiel für eine GitLab CI/CD-Pipeline-YAML: ``` workflow: name: HelloWorld stages: # List of stages for jobs, and their order of execution - build build-job: # This job runs in the build stage, which runs first. stage: build script: - echo "Hello World!" tags: - codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME ``` + Sie können auch Ihr Bild und Ihren Berechnungstyp im Tag überschreiben. Eine Liste der kuratierten Bilder finden Sie unter[Compute Images, die mit dem -hosted Runner unterstützt werden CodeBuild GitLab](sample-gitlab-runners-gitlab-ci.images.md). Informationen zur Verwendung von benutzerdefinierten Bildern finden Sie unter[Label-Overrides werden mit dem CodeBuild GitLab -hosted Runner unterstützt](gitlab-runners-update-labels.md). Der Berechnungstyp und das Bild im Tag überschreiben die Umgebungseinstellungen in Ihrem Projekt. Verwenden Sie die folgende Syntax, um Ihre Umgebungseinstellungen für einen Amazon EC2 EC2-Compute-Build zu überschreiben: ``` tags: - codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - image:- - instance-size: ``` Das Folgende ist ein Beispiel für eine GitLab CI/CD-Pipeline YAML: ``` stages: - build build-job: stage: build script: - echo "Hello World!" tags: - codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - image:arm-3.0 - instance-size:small ``` + Sie können die für Ihren Build verwendete Flotte im Tag überschreiben. Dadurch werden die in Ihrem Projekt konfigurierten Flotteneinstellungen überschrieben, sodass die angegebene Flotte verwendet wird. Weitere Informationen finden Sie unter [Führen Sie Builds auf Flotten mit reservierter Kapazität aus](fleets.md). Verwenden Sie die folgende Syntax, um Ihre Flotteneinstellungen für einen Amazon EC2 EC2-Compute-Build zu überschreiben: ``` tags: - codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - fleet: ``` Verwenden Sie die folgende Syntax, um sowohl die Flotte als auch das für den Build verwendete Image zu überschreiben: ``` tags: - codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - fleet: - image:- ``` Im Folgenden finden Sie ein Beispiel für eine GitLab CI/CD-Pipeline YAML: ``` stages: - build build-job: stage: build script: - echo "Hello World!" tags: - codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - fleet:myFleet - image:arm-3.0 ``` + Um Ihre GitLab CI/CD-Pipeline-Jobs auf einem benutzerdefinierten Image auszuführen, können Sie in Ihrem CodeBuild Projekt ein benutzerdefiniertes Image konfigurieren und die Angabe eines Image-Override-Labels vermeiden. CodeBuild verwendet das im Projekt konfigurierte Image, wenn kein Image-Override-Label angegeben ist. Nachdem Sie Ihre Änderungen übernommen haben`.gitlab-ci.yml`, wird eine GitLab Pipeline ausgelöst, die `build-job` eine Webhook-Benachrichtigung sendet, mit der Ihr Build gestartet wird. CodeBuild ### Führen Sie die Buildspec-Befehle in den Phasen INSTALL, PRE\$1BUILD und POST\$1BUILD aus CodeBuild Ignoriert standardmäßig alle Buildspec-Befehle, wenn ein selbstverwalteter Build ausgeführt wird. GitLab Um Buildspec-Befehle während des Builds auszuführen, `buildspec-override:true` kann Folgendes als Suffix hinzugefügt werden: `tags` ``` tags: - codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME - buildspec-override:true ``` Mit diesem Befehl CodeBuild wird ein Ordner mit dem Namen `gitlab-runner` im primären Quellordner des Containers erstellt. Wenn der GitLab Runner während der `BUILD` Phase startet, wird der Runner im `gitlab-runner` Verzeichnis ausgeführt. Bei der Verwendung einer Buildspec-Überschreibung in einem selbstverwalteten Build gibt es mehrere Einschränkungen: GitLab + CodeBuild führt während der Phase keine Buildspec-Befehle aus, da der selbstverwaltete Runner in der `BUILD` Phase ausgeführt wird. `BUILD` + CodeBuild lädt während der Phase keine Primär- oder Sekundärquellen herunter. `DOWNLOAD_SOURCE` Wenn Sie eine Buildspec-Datei konfiguriert haben, wird nur diese Datei von der Primärquelle des Projekts heruntergeladen. + Wenn ein Build-Befehl in der `PRE_BUILD` `INSTALL` Oder-Phase fehlschlägt, CodeBuild wird der selbstverwaltete Runner nicht gestartet und der GitLab CI/CD-Pipeline-Job muss manuell abgebrochen werden. + CodeBuild ruft das Runner-Token während der `DOWNLOAD_SOURCE` Phase ab, die eine Ablaufzeit von einer Stunde hat. Wenn Ihre `PRE_BUILD` `INSTALL` Phasen eine Stunde überschreiten, läuft das Runner-Token möglicherweise ab, bevor der GitLab selbstverwaltete Runner startet. ## Schritt 3: Überprüfe deine Ergebnisse Wann immer ein GitLab CI/CD pipeline run occurs, CodeBuild would receive the CI/CD pipeline job events through the webhook. For each job in the CI/CD pipeline, CodeBuild starts a build to run an ephemeral GitLab runner. The runner is responsible for executing a single CI/CD Pipeline-Job. Sobald der Job abgeschlossen ist, werden der Runner und der zugehörige Build-Prozess sofort beendet. Um Ihre CI/CD Pipeline-Job-Logs einzusehen, navigieren Sie zu Ihrem Repository in GitLab, wählen Sie **Build**, **Jobs** und dann den spezifischen **Job** aus, für den Sie die Logs überprüfen möchten. Sie können die angeforderten Labels im Protokoll überprüfen, während der Job darauf wartet, von einem selbst verwalteten Runner übernommen zu werden. CodeBuild ## GitLab Webhook-Ereignisse filtern ()CloudFormation Der folgende Teil einer CloudFormation Vorlage im YAML-Format erstellt eine Filtergruppe, die einen Build auslöst, wenn sie als wahr ausgewertet wird. Die folgende Filtergruppe gibt einen GitLab CI/CD pipeline job request with a CI/CD Pipeline-Namen an, der dem regulären Ausdruck entspricht. `\[CI-CodeBuild\]` ``` CodeBuildProject: Type: AWS::CodeBuild::Project Properties: Name: MyProject ServiceRole: service-role Artifacts: Type: NO_ARTIFACTS Environment: Type: LINUX_CONTAINER ComputeType: BUILD_GENERAL1_SMALL Image: aws/codebuild/standard:5.0 Source: Type: GITLAB Location: CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION Triggers: Webhook: true ScopeConfiguration: Name: group-name Scope: GITLAB_GROUP FilterGroups: - - Type: EVENT Pattern: WORKFLOW_JOB_QUEUED - Type: WORKFLOW_NAME Pattern: \[CI-CodeBuild\] ```