Nachdem Dockerhub die automatischen Container Builds für nicht-pro Benutzer abgekündigt hat, bin ich für meinen Container Build auf eine Github Action umgestiegen. Im folgenden wird beschrieben, wie der Umstieg funktioniert.

Aktivieren der Github Registry

Die neue ghcr.io Registry kann man in seinen Account Einstellungen aktivieren. Dazu muss man im Punkt „Feature Preview“ den „Improved container support“ aktivieren.

Github User Settings

Github Personal Access Token (PAT)

Erstellung des Tokens

Für den Login in die Registry wird ein Token benötigt. Über Settings -> Developer Settings -> Personal Access Tokens gibt es den Punkt „Generate Token“. Hier wählen wir write:packages aus und klicken unten auf den grünen Button.

new personal access token

Wir haben jetzt einen Token und ich habe mir den sofort in meinen Passwort Manager abgespeichert. Achtung: Es gibt keine Möglichkeit den Token nochmals anzeigen zu lassen.

Hinterlegen des Tokens als Repository Secret

Um das Token in der Action nutzen zu können muss es im Repository hinterlegt werden. Dafür gibt es die Repository Secrets. Diese werden im Repository unter Settings -> Secrets können die hinterlegt werden. Ich habe das Token mit dem Namen CR_PAT hinterlegt. Zusätzlich gibt es jeweils noch ein Secret für Dockerhub und eine private Registry.

Erstellung der Github Action

Jede Github Action wird über eine yaml Datei im Repository definiert. Man kann sie über die Weboberfläche im Reiter Actions anlegen, oder in den Pfad .github/workflows pushen.

on:
  schedule:
    - cron: '41 0 3 * *'
  push:
    branches:
      - master
    # Publish semver tags as releases.
    tags: [ 'v*.*.*' ]
  pull_request:
    branches: [ master ]
  workflow_dispatch:

env:
  # github.repository as <account>/<repo>
  IMAGE_NAME: ${{ github.repository }}


jobs:
  build:

    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      # Login against a Docker registry except on PR
      # https://github.com/docker/login-action
      - name: Log into registry ghcr.io
        if: github.event_name != 'pull_request'
        uses: docker/login-action@28218f9b04b4f3f62068d7b6ce6ca5b26e35336c
        with:
          registry: ghcr.io
          username: olqs
          password: ${{ secrets.CR_PAT }}

      # Login against a Docker registry except on PR
      # https://github.com/docker/login-action
      - name: Log into registry hub.docker.com
        if: github.event_name != 'pull_request'
        uses: docker/login-action@28218f9b04b4f3f62068d7b6ce6ca5b26e35336c
        with:
          registry: docker.io
          username: olqs
          password: ${{ secrets.DOCKERHUB_PASSWORD }}

      # Login against a Docker registry except on PR
      # https://github.com/docker/login-action
      - name: Log into registry quay.home.olqs.de
        if: github.event_name != 'pull_request'
        uses: docker/login-action@28218f9b04b4f3f62068d7b6ce6ca5b26e35336c
        with:
          registry: quay.home.olqs.de
          username: olqs
          password: ${{ secrets.QUAYHOME_PASSWORD }}

      # Extract metadata (tags, labels) for Docker
      # https://github.com/docker/metadata-action
      - name: Extract Docker metadata
        id: meta
        uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38
        with:
          images: ghcr.io/${{ env.IMAGE_NAME }},${{ env.IMAGE_NAME }},quay.home.olqs.de/${{ env.IMAGE_NAME }}

      # Build and push Docker image with Buildx (don't push on PR)
      # https://github.com/docker/build-push-action
      - name: Build and push Docker image
        uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
        with:
          context: .
          push: ${{ github.event_name != 'pull_request' }}
          tags: |
            ${{ steps.meta.outputs.tags }}
            ghcr.io/${{ env.IMAGE_NAME }}:latest
            quay.home.olqs.de/${{ env.IMAGE_NAME }}:latest
            ${{ env.IMAGE_NAME }}:latest
          labels: ${{ steps.meta.outputs.labels }}

Die Action ist in drei Abschnitte unterteilt.

  • on: Startpunkte, wann die Action gestartet wird.
    • schedule: Ein zeitgesteuertes Starten der Action
    • push: Starten der Action beim Push von neuen Tags oder in bestimmte Branches.
    • pull_request: Starten bei pull_requests
    • workflow_dispatch: Damit kann ein manueller Start der Action ermöglicht werden.
  • env: Umgebungsvariablen, sollte selbsterklärend sein.
  • jobs: Die eigentlichen Jobs die ausgeführt werden.
    • runs-on: Hier wird der Github Runner festgelegt, also die Art der virtuellen Maschine, die für die Steps verwendet wird.
    • permissions: Mit diesem Abschnitt werden die benötigten Berechtigungen festgelegt, damit hat man die genutzten Berechtigungen unter Kontrolle, um Tokens mit sehr weitreichenden Berechtigungen einzuschränken.
    • steps: Die einzelnen Schritte der Action.
      • Sourcecode Checkout
      • Login in die drei Registries in die später gepusht wird.
      • Metadaten der Container aus dem Repository extrahieren
      • Der Container Build und Push in die verschiedenen Registries

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.