Übung: Erstellen des Anwendungsimage

  • 10 Minuten

In dieser Lektion erstellen Sie Ihre GitHub Actions-Stagingpipeline, indem Sie das Anwendungsimage erstellen und an Azure Container Registry übertragen.

Die folgende Abbildung zeigt die von Ihnen entworfene CI/CD-Pipeline:

Diagram that shows the procession from triggers, through three build steps, to the deploy steps in a pipeline.

In dieser Übung erstellen Sie die Stagingpipeline, indem Sie die folgenden Schritte ausführen:

  • Erstellen des GitHub Actions-Workflows.
  • Erstellen des on push-Triggers.
  • Erstellen und Pushen des Anwendungsimage.
  • Festlegen von Geheimnissen.
  • Führen Sie den Auftrag aus.

Erstellen des GitHub Actions-Workflows

GitHub-Workflows sind in Aufträge unterteilt und Aufträge wiederum in Schritte. Jeder Schritt kann mehrere Befehle umfassen und mehrere auszuführende Aktionen verwenden.

Beginnen Sie mit dem Erstellen Ihrer Pipeline, indem Sie zum Fork des Beispielrepositorys auf der GitHub-Website navigieren.

  1. Klicken Sie auf die Registerkarte Actions (Aktionen).

  2. Wählen Sie den Link aus, um selbst einen Workflow einzurichten.

    Screenshot that shows the Get started with GitHub Actions page on the GitHub website.

    An diesem Punkt ist die Pipeline lediglich eine leere Datei im Verzeichnis github/workflows in Ihrem Repository. GitHub stellt die vorgefertigten Komponenten zur Verfügung, die Sie zum Erstellen der meisten Pipelines benötigen. Kopieren Sie zunächst den folgenden Code, und fügen Sie ihn in den Bereich Neue Datei bearbeiten ein:

    # This is a basic workflow to help you get started with Actions

name: CI

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the main branch
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      # Runs a single command using the runners shell
      - name: Run a one-line script
        run: echo Hello, world!

      # Runs a set of commands using the runners shell
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

  3. Benennen Sie oberhalb des Bereichs Edit new file (Neue Datei bearbeiten) die Datei aus main.yml in build-staging.yml um.

    Screenshot that shows an example file being edited in the Edit new file pane on the GitHub website.

  4. Ändern Sie den name-Schlüssel von CI zu Build and push the latest build to staging.

    # This is a basic workflow to help you get started with Actions

name: Build and push the latest build to staging

Ändern des „On“-Triggers

Die grundlegende Workflowvorlage enthält zwei Trigger:

  • Einen beliebigen Pushvorgang in den Hauptbranch.
  • Einen beliebigen Pull Request für den Hauptbranch.

Sie benötigen die Pipeline nicht für die Ausführung auf einer Pull Request. Ändern Sie sie daher, um nur den Pushtrigger beizubehalten, indem Sie die Trigger im on-Schlüssel ändern. Entfernen Sie den zweiten Trigger, und behalten Sie nur die push-Tags bei.

name: Build and push the latest build to staging

on:
  push:
    branches: [ main ]

Konfigurieren des Check-Outs

Bearbeiten Sie als Nächstes die Auftragsschritte. In diesem Prozess implementieren Sie sowohl die Buildaufgaben als auch die Bereitstellungsaufgaben in Ihrem Pipelineentwurfsdiagramm.

  1. Benennen Sie unter jobs den build-Schlüssel in build_push_image.

  2. Sie möchten, dass dieser Workflow auf Ubuntu 20.04 ausgeführt werden soll. Ändern Sie also den runs-on-Schlüssel von ubuntu-latest zu ubuntu-20.04.

  3. Löschen Sie die letzten beiden Befehle im steps-Schlüssel, die nur Beispiele für die Vorlage sind.

    Ihre Datei ohne Kommentare sollte wie in diesem Beispiel aussehen:

    name: Build and push the latest build to staging

on:
  push:
    branches: [ main ]

jobs:
  build_push_image:
    runs-on: ubuntu-20.04

    steps:
      - uses: actions/checkout@v2

Sie haben jetzt einen Schritt, der die checkout-Aktion verwendet. Durch diese Aktion wird das Repository in die Auftragsumgebung geklont. Dieser Schritt entspricht der ersten Aktion, Repository klonen, im Pipelineentwurfsdiagramm.

Hinzufügen von Docker-Schritten

Fügen Sie anschließend Aktionen zum Erstellen Ihres Docker-Images hinzu. Sie können die Verwendung für diese Aktionen anpassen. In diesem Beispiel werden nur einige der verfügbaren Parameter verwendet. Weitere Informationen finden Sie in der GitHub-Dokumentation zu build-push-action.

  1. Suchen Sie auf der Registerkarte Marketplace im rechten Bereich nach Docker-Anmeldung, und wählen Sie das erste Ergebnis aus, das von Docker veröffentlicht wurde.

    Screenshot showing the search results listing Docker Login.

    Hinweis

    Docker-Aktionen vor Version 2 hatten einen integrierten Anmeldefluss, aber in den Versionen 2 und höher sind diese Aktionen getrennt, sodass Sie zwei Aktionen benötigen, um den Workflow ordnungsgemäß festzulegen.

  2. Wählen Sie unter Installation das Kopiersymbol aus, um die Verwendung von YAML zu kopieren.

    Screenshot showing the copy function and selecting the Docker Login task.

  3. Fügen Sie den kopierten YAML-Code unter der actions/checkout@v2-Aktion ein.

    Wichtig

    Achten Sie bei der Verwendung von YAML auf den Einzug. Der name-Schlüssel sollte am vorhergehenden uses-Schlüssel ausgerichtet sein.

  4. Fügen Sie die folgenden Werte zu den registry-, username-, und password-Schlüsseln hinzu:

    • registry: ${{ secrets.ACR_NAME }}
    • username: ${{ secrets.ACR_LOGIN }}
    • password: ${{ secrets.ACR_PASSWORD }}

  5. Löschen Sie alle anderen Schlüssel, da sie in dieser Übung nicht verwendet werden.

  6. Suchen Sie im rechten Bereich unter Marketplace nach Erstellen und Pushen von Docker-Images, und wählen Sie das erste Ergebnis aus, das von Docker veröffentlicht wurde.

    Screenshot that shows the search results that list Build and push Docker images.

  7. Wählen Sie unter Installation das Kopiersymbol aus, um die Verwendung von YAML zu kopieren.

  8. Fügen Sie die kopierte YAML-Datei unterhalb des letzten Schlüssels aus der zuvor kopierten docker-login-Aktion ein.

  9. Benennen Sie den name Schlüssel Build and push Docker images in Build and push staging images um.

  10. Fügen Sie die folgenden Werte zu den context-, push-, und tags-Schlüsseln hinzu:

    • context: .
    • push: true
    • tags: ${{secrets.ACR_NAME}}/contoso-website:latest

  11. Löschen Sie alle anderen Schlüssel, da sie in dieser Übung nicht verwendet werden.

  12. Fügen Sie eine weitere Aktion namens docker/setup-buildx-action zwischen der Check-Out-Aktion und der Anmeldeaktion hinzu, um die Build-Engine für die Verwendung durch Docker einzurichten. Kopieren Sie den folgenden Codeausschnitt, und fügen Sie ihn zwischen den checkout- und login-Aktionen ein.

    - name: Set up Buildx
  uses: docker/setup-buildx-action@v3.0.0

    Die endgültige Datei ohne Kommentare sollte wie im folgenden Beispiel aussehen:

    name: Build and push the latest build to staging

on:
  push:
    branches: [ main ]

jobs:
  build_push_image:
    runs-on: ubuntu-20.04

    steps:
      - uses: actions/checkout@v2

      - name: Set up Buildx
        uses: docker/setup-buildx-action@v3.0.0

      - name: Docker Login
        uses: docker/login-action@v3.0.0
        with:
          registry: ${{ secrets.ACR_NAME }}
          username: ${{ secrets.ACR_LOGIN }}
          password: ${{ secrets.ACR_PASSWORD }}

      - name: Build and push staging images
        uses: docker/build-push-action@v5.0.0
        with:
          context: .
          push: true
          tags: ${{secrets.ACR_NAME}}/contoso-website:latest

Übergeben der Änderungen

Wählen Sie die Schaltfläche Änderungen committen am unteren Rand aus, um die Änderungen zu committen. Geben Sie auf dem Bildschirm Änderungen committen eine Beschreibung für den Commit ein, und wählen Sie dann Änderungen committen aus.

Screenshot that shows the Commit changes button in the Commit changes pane.

Wenn Sie Änderungen committen auswählen, wird ein neuer Build ausgelöst, dieser Build schlägt jedoch fehl, da Sie die Geheimnisse noch nicht festgelegt haben.

Festlegen der Geheimnisse

Um die Geheimnisse festzulegen, wählen Sie auf der Seite des GitHub-Repositorys die Registerkarte Einstellungen aus, und klicken Sie dann im linken Menü auf Geheimnisse und Variablen>Aktionen. Definieren Sie die folgenden Geheimnisse, die Ihr Workflow verwendet:

  • ACR_NAME: Der vom Setupskript zurückgegebene ACR_Name-Wert
  • ACR_LOGIN: Der vom Setupskript zurückgegebene ACR Login Username-Wert
  • ACR_PASSWORD: Der vom Setupskript zurückgegebene ACR Login Password-Wert
  • RESOURCE_GROUP: Der vom Setupskript zurückgegebene Resource Group Name-Wert
  • CLUSTER_NAME: Contoso-Video

So definieren Sie jedes Geheimnis:

  1. Wählen Sie New repository secret (Neues Repositorygeheimnis) aus.
  2. Geben Sie für Name den Geheimnisnamen aus der vorherigen Liste ein.
  3. Geben Sie für Geheimnis den Wert ein, den Sie aus dem Setupskript gespeichert haben, oder führen Sie eine Cloud Shell-Abfrage aus, um den Wert abzurufen.
  4. Klicken Sie auf Add secret (Geheimnis hinzufügen).

Ausführen optionaler Abfragen zum Abrufen der geheimen Werte

Wenn Sie nicht über die Werte verfügen, die das Setupskript zurückgegeben hat, können Sie die folgenden Befehle in Azure Cloud Shell ausführen, um die Informationen abzurufen:

  • ACR_NAME:

    az acr list --query "[?contains(resourceGroup, 'mslearn-gh-pipelines')].loginServer" -o table

  • ACR_LOGIN:

    az acr credential show --name <ACR_NAME> --query "username" -o table

  • ACR_PASSWORD:

    az acr credential show --name <ACR_NAME> --query "passwords[0].value" -o table

  • RESOURCE_GROUP:

    az aks list -o tsv --query "[?name=='contoso-video'].resourceGroup"

Ausführung des Auftrags.

  1. Klicken Sie auf die Registerkarte Actions (Aktionen).

  2. Wählen Sie die einzige Ausführung in der Liste aus, den fehlgeschlagenen Auftrag build-staging.yml.

  3. Wählen Sie oben rechts Aufträge erneut ausführen>Alle Aufträge erneut ausführen aus, und wählen Sie auf dem Bildschirm Alle Aufträge erneut ausführen die Option Aufträge erneut ausführen aus.

    Screenshot that shows the Re-run jobs and Re-run all jobs buttons.

  4. Wenn der Build abgeschlossen ist, führen Sie az acr repository list --name <ACR_NAME> -o table in Cloud Shell aus, um zu bestätigen, dass das Container Registry-Repository „contoso-website“ in den Ergebnissen angezeigt wird.

Fahren Sie mit der nächsten Einheit fort, um Ihren Produktionsworkflow zu erstellen.