Dieser Artikel ist eine Testversion und hat denselben Inhalt wie [Mein Blog] veröffentlicht (https://blog.fagai.net/2020/09/08/github-actions-package-registry-push/).
Ich werde darüber sprechen, wie ein Docker-Container mit GitHub-Aktionen in die GitHub-Paketregistrierung verschoben wird.
Jetzt kann ich es als Basisimage für das Unternehmen verwenden
https://github.com/fagai/docker-php
Ich habe die automatische Erstellung für Docker Hub im Github-Repository festgelegt und aus Docker Hub erstellt. Die Build-Zeitleiste für Docker Hub war sehr langsam und ich habe es geschafft, es ein wenig stressig zu halten.
Vor kurzem habe ich mich jedoch für Build + Push mit GitHub-Aktionen entschieden, weil ich etwas gegen das Pull-Limit von Docker Hub und die Tatsache unternehmen wollte, dass GitHub eine öffentliche Beta von Container Registry wurde.
Von nun an wird GitHub Container Registry als GCR abgekürzt. Bitte beachten Sie, dass es sich keinesfalls um eine Google Container Registry handelt. (Ich möchte die Abkürzung nicht leiden)
Ersteres wurde neulich als öffentliche Beta veröffentlicht, und letzteres gibt es schon seit einiger Zeit. Der Unterschied zwischen den beiden
Es ist so ein Ort.
In Bezug auf den verknüpften Teil unterscheidet sich der URL-Pfad auch wie folgt.
Es ist anders, ob es an den Benutzer oder das Repository gebunden ist. Nun, der unten beschriebene Inhalt kann in beiden Fällen auf die gleiche Weise geschrieben werden. Ich denke, es ist gut, ihn zu sehen, auch wenn es sich um eine Paketregistrierung handelt.
Ursprünglich habe ich versucht, die GitHub Container Registry zu verwenden, aber ich frage mich, ob die Domain ghcr.io lautet. Dies ... ist es nicht GitHub ...? Ich habe angefangen, die GitHub-Paketregistrierung zu verwenden. Derzeit denke ich, dass GCR besser für die Verwendung geeignet ist, da die Version des Manifests neuer ist. Verwenden Sie GPR, wenn Sie eine Verknüpfung zu einem Paket herstellen möchten.
Zuerst habe ich Docker Publish des Starter-Workflows verwendet.
https://github.com/actions/starter-workflows/blob/master/ci/docker-publish.yml
Der Typ zu dieser Zeit https://github.com/fagai/docker-php/blob/32988eacf16e697e5376ee0af778079fa1e0fb62/.github/workflows/docker-publish.yml
Im Vergleich zu Docker Hub hatte ich nicht viel Zeit zum Laden in Queue, also war es wirklich gut.
Ich habe mich gefragt, ob ich schrittweise auf Docker Hub zugreifen kann, und das Ergebnis https://github.com/docker/build-push-action gefunden. Hier umschreiben.
https://github.com/docker/build-push-action
Zu diesem Zeitpunkt: https://github.com/fagai/docker-php/blob/12d060efd0b91924f0edf85f3b127e19d47cd18a/.github/workflows/docker-publish.yml
- name: Push to GitHub Packages
uses: docker/build-push-action@v1
with:
dockerfile: ${{ matrix.images }}/Dockerfile
username: ${{ github.actor }}
password: ${{ secrets.CR_PAT }}
registry: docker.pkg.github.com
repository: fagai/docker-php/${{ env.IMAGE_NAME }}
tags: ${{ env.IMAGE_VERSION }}
Schlank ~~. In Bezug auf CR_PAT ist es eine Abkürzung für Container Registry Personal Access Token. Eigentlich wurde es zum Zeitpunkt des Starter-Workflows geschrieben, also habe ich das Token von github mit diesem Namen gesetzt. (Github.token ist in Ordnung, aber es scheint besser, das Zugriffstoken so weit wie möglich einzugrenzen, sodass ich nur die Zugriffsrepository- und Schreibrepository-Berechtigungen erteilt habe.)
Später habe ich auch die Push-Einstellungen für Docker Hub hinzugefügt.
- name: Push to Docker Hub
uses: docker/build-push-action@v1
with:
dockerfile: ${{ matrix.images }}/Dockerfile
username: ${{ github.actor }}
password: ${{ secrets.DOCKER_HUB_TOKEN }}
repository: fagai/${{ env.IMAGE_NAME }}
tags: ${{ env.IMAGE_VERSION }}
Im Beispiel von build-push-action wurde ein Kennwort festgelegt, Docker Hub verfügt jedoch auch über ein Zugriffstoken. Verwenden Sie dieses. Ich ziehe es an, nachdem ich es eingestellt habe.
https://docs.docker.com/docker-hub/access-tokens/
So wie es ist, bezieht es sich nicht auf den Cache. (Die zweite Build-Push-Aktion basiert jedoch auf dem Cache. Wenn Sie also eine erstellen + pushen, können Sie die andere sofort pushen.)
build-push-action hat einen Parameter namens "cache_froms", daher möchte ich ihn gut verwenden.
Nachdem ich verschiedene Dinge ausprobiert hatte, stellte ich fest, dass ich "Buildkit" verwenden muss, um "cache_froms" zu verwenden.
Es stellte sich auch heraus, dass Sie "build_args: BUILDKIT_INLINE_CACHE = 1" setzen mussten.
Anscheinend hatte cache_froms eine schlechte Atmosphäre, es sei denn, der Domain-Teil wurde ebenfalls angegeben. ← Ich war hier besorgt
So sieht es also aus.
- name: Push to GitHub Packages
uses: docker/build-push-action@v1
env:
DOCKER_BUILDKIT: 1
with:
dockerfile: ${{ matrix.images }}/Dockerfile
username: ${{ github.actor }}
password: ${{ secrets.CR_PAT }}
registry: docker.pkg.github.com
repository: fagai/docker-php/${{ env.IMAGE_NAME }}
tags: ${{ env.IMAGE_VERSION }}
build_args: BUILDKIT_INLINE_CACHE=1
cache_froms: docker.pkg.github.com/fagai/docker-php/${{ env.IMAGE_NAME }}:${{ env.IMAGE_VERSION }}
Sie können damit gehen! ich dachte
Es wird nicht zwischengespeichert ... wenn Sie sich also Aktionen ansehen
#4 importing cache manifest from docker.pkg.github.com/fagai/docker-php/php...
#4 ERROR: httpReaderSeeker: failed open: could not fetch content descriptor sha256:65d9f276544048f140bb1a1cceea52f86e7e704b351c56b8d6b9f18c5e9c0e4d (application/vnd.docker.distribution.manifest.v2+json) from remote: not found
Ich habe einen Fehler wie diesen erhalten und der Build wurde so ausgeführt, wie er war, ohne den Cache zu erhalten. Anscheinend unterstützt die GitHub-Paketregistrierung das neue Manifest von Docker noch nicht. (GitHub Container Registry scheint dies zu unterstützen)
https://github.community/t/handle-multi-arch-docker-images-on-github-package-registry/14314
Also habe ich mich entschlossen, zuerst von Docker Hub zu bauen. cache_froms muss aus docker.io geschrieben werden.
- name: Push to Docker Hub
uses: docker/build-push-action@v1
env:
DOCKER_BUILDKIT: 1
with:
dockerfile: ${{ matrix.images }}/Dockerfile
username: ${{ github.actor }}
password: ${{ secrets.DOCKER_HUB_TOKEN }}
repository: fagai/${{ env.IMAGE_NAME }}
tags: ${{ env.IMAGE_VERSION }}
build_args: BUILDKIT_INLINE_CACHE=1
cache_froms: docker.io/fagai/${{ env.IMAGE_NAME }}:${{ env.IMAGE_VERSION }}
So sieht es also aus.
#4 importing cache manifest from docker.io/fagai/php:7.2-alpine-fpm
#4 DONE 0.2s
Die nachfolgende Verarbeitung wird auch als CACHED angezeigt, was darauf hinweist, dass der Build nicht funktioniert und auf dem Cache basiert.
- name: cancel old workflow
uses: styfle/[email protected]
with:
access_token: ${{ github.token }}
Ich habe das in der Vergangenheit getan. Es ist eine Aktion, die die vergangene Aktion abbricht. Es löst das Problem, dass vergangene Aktionen bestehen bleiben und verschoben werden, wenn Sie viele Male festschreiben.
Ich habe auch einen Zeitplan festgelegt, damit Action jeden Montag funktioniert.
on:
push:
branches:
- master
pull_request:
#Führen Sie regelmäßige Updates durch(jeden Montag)
schedule:
- cron: '0 0 * * 1'
Durch das Erstellen und Pushen von GitHub-Aktionen wurde das Problem gelöst, auf das Docker Hub lange in der Warteschlange gewartet hat. Vor allem kann es parallel erstellt werden, sodass es in kurzer Zeit gepusht werden kann.
build-push-action ist v2 und buildx Es scheint, dass der neu hinzugefügte Build in Docker 19.03 verwendet wird. BuildKit scheint halboffiziell zu sein, und Buildx scheint eine offizielle Build-kompatible Funktion mit mehreren CPUs zu sein. Auf einem Mac wird durch Eingabe von "Docker Buildx Install" ein Alias für "Docker Build" eingefügt und Buildx wird ohne Erlaubnis verwendet. Wie schön.