Cet article est un essai et a publié le même contenu que Mon blog.
Je vais parler de pousser un conteneur Docker vers le registre de packages GitHub avec des actions GitHub.
Je peux maintenant l'utiliser comme image de base pour l'entreprise
https://github.com/fagai/docker-php
J'ai défini la construction automatisée pour Docker Hub dans le référentiel github et construite à partir de Docker Hub. Le calendrier de construction de Docker Hub était très lent et j'ai réussi à le garder un peu stressant.
Cependant, récemment, j'ai décidé de Build + Push avec GitHub Actions parce que je voulais faire quelque chose sur la limite de tirage de Docker Hub et le fait que GitHub est devenu une version bêta publique de Container Registry.
À partir de là, GitHub Container Registry est abrégé en GCR, veuillez noter qu'il ne s'agit en aucun cas d'un Google Container Registry. (Je ne veux pas subir l'abréviation)
Le premier a été publié en version bêta publique l'autre jour, et le second existe depuis un certain temps. La différence entre les deux
C'est un endroit comme ça.
En ce qui concerne la partie liée, le chemin de l'URL est également différent comme suit.
Il est différent qu'il soit lié à l'utilisateur ou au référentiel comme celui-ci. Eh bien, le contenu écrit ci-dessous peut être écrit de la même manière, donc je pense qu'il est bon de le voir même s'il s'agit d'un registre de packages.
À l'origine, j'essayais d'utiliser GitHub Container Registry, mais je me demande si le domaine est ghcr.io Ce ... n'est pas GitHub ...? J'ai commencé à utiliser le registre de packages GitHub. À l'heure actuelle, je pense que GCR est meilleur à utiliser car la version du manifeste est plus récente. Utilisez GPR lorsque vous souhaitez créer un lien vers un package.
Au début, j'ai utilisé la publication docker du flux de travail de démarrage.
https://github.com/actions/starter-workflows/blob/master/ci/docker-publish.yml
Le gars à ce moment-là https://github.com/fagai/docker-php/blob/32988eacf16e697e5376ee0af778079fa1e0fb62/.github/workflows/docker-publish.yml
Comparé à Docker Hub, je n'ai pas eu beaucoup de temps pour charger dans Queue, donc c'était vraiment bien.
Je me demandais si je pouvais pousser progressivement vers Docker Hub, et j'ai trouvé le résultat https://github.com/docker/build-push-action. A réécrire ici.
https://github.com/docker/build-push-action
À ce moment-là: 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 }}
Slim ~~. En ce qui concerne CR_PAT, c'est une abréviation pour Container Registry Personal Access Token. En fait, il a été écrit au niveau du workflow de démarrage, j'ai donc défini le jeton de github avec ce nom. (Github.token va bien, mais il semble préférable de restreindre le plus possible le jeton d'accès, donc je n'ai donné que le référentiel d'accès et les autorisations d'écriture du référentiel)
Plus tard, j'ai également ajouté les paramètres push pour Docker Hub.
- 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 }}
Dans l'exemple de build-push-action, le mot de passe a été défini, mais Docker Hub a également un jeton d'accès, alors utilisez-le. Je l'ai mis après l'avoir réglé.
https://docs.docker.com/docker-hub/access-tokens/
En l'état, il ne fait pas référence au cache. (Cependant, la deuxième action build-push est basée sur le cache, donc si vous construisez + push one, vous pouvez pousser l'autre immédiatement)
build-push-action a un paramètre appelé cache_froms, donc je veux bien l'utiliser.
Après avoir essayé diverses choses, j'ai trouvé que je devais utiliser Buildkit pour utiliser cache_froms.
Il s'est également avéré que vous deviez définir build_args: BUILDKIT_INLINE_CACHE = 1.
Apparemment, cache_froms avait une mauvaise ambiance à moins que la partie domaine ne soit également spécifiée. ← J'étais inquiet ici
Donc ça ressemble à ça.
- 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 }}
Vous pouvez y aller! j'ai pensé
Ce n'est pas mis en cache ... donc si vous regardez Actions
#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
J'ai eu une erreur comme celle-ci et la construction s'est déroulée telle quelle sans obtenir le cache. Apparemment, le registre de packages GitHub ne prend pas encore en charge le nouveau manifeste de docker. (GitHub Container Registry semble le prendre en charge)
https://github.community/t/handle-multi-arch-docker-images-on-github-package-registry/14314
J'ai donc décidé de construire d'abord à partir de Docker Hub. cache_froms doit être écrit à partir de docker.io.
- 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 }}
Donc ça ressemble à ça.
#4 importing cache manifest from docker.io/fagai/php:7.2-alpine-fpm
#4 DONE 0.2s
Le traitement suivant sera également affiché comme CACHED, indiquant que la construction ne fonctionne pas et est basée sur le cache.
- name: cancel old workflow
uses: styfle/[email protected]
with:
access_token: ${{ github.token }}
J'ai fait ça dans le passé. C'est une action qui annule l'action passée. Cela résout le problème que les actions passées restent et bougent lorsque vous vous engagez plusieurs fois.
J'ai également établi un calendrier pour qu'Action fonctionne tous les lundis.
on:
push:
branches:
- master
pull_request:
#Faites des mises à jour régulières(tous les lundis)
schedule:
- cron: '0 0 * * 1'
À la suite de la création et du transfert d'actions GitHub, le problème que Docker Hub attend depuis longtemps dans la file d'attente a été résolu, et surtout, il peut être construit en parallèle, de sorte qu'il peut être poussé en peu de temps.
build-push-action est v2 et buildx Il semble que la nouvelle version ajoutée dans Docker 19.03 sera utilisée.
BuildKit semble être semi-officiel, et Buildx semble être une fonction officielle compatible avec la construction multi-CPU.
Sur mac, en tapant docker buildx install, un alias pour docker build sera collé et buildx sera utilisé sans autorisation. Comme c'est gentil.
Recommended Posts