This article is a trial and has posted the same content as My Blog.
I'm going to talk about pushing a Docker container to the GitHub Package Registry with GitHub Actions.
Now I can use it as a base image for the company
https://github.com/fagai/docker-php
I set automated build for Docker Hub in the github repository and built from Docker Hub. The build timeline for Docker Hub was very slow, and I managed to keep it a little stressful.
However, recently I thought that I would like to do something about Docker Hub's pull limit or GitHub's Container Registry becoming a public beta, so I decided to Build + Push with GitHub Actions.
From here, we'll abbreviate GitHub Container Registry as GCR, please note that it's not Google Container Registry. (I'm having trouble getting the abbreviation)
The former was released as a public beta the other day, and the latter has been around for some time. The difference between the two
It is a place like that.
Regarding the part to be linked, the URL path is also different as follows.
It is different whether it is tied to the user or the repository like this. Well, the contents written below can be written in the same way in either case, so I think it's good to see it even if it's a Package Registry.
Originally I was trying to use GitHub Container Registry, but I wonder if the domain is ghcr.io This ... isn't it GitHub ...? I started using the GitHub Package Registry. At present, I think that GCR is better for use because the version of manifest is newer. Use GPR when you want to link it to a package.
Initially I used docker publish in starter-workflow.
https://github.com/actions/starter-workflows/blob/master/ci/docker-publish.yml
The guy at that time https://github.com/fagai/docker-php/blob/32988eacf16e697e5376ee0af778079fa1e0fb62/.github/workflows/docker-publish.yml
Compared to Docker Hub, I don't have time to put it in the Queue, so it was really good.
I was wondering if I could push it to Docker Hub gradually, and found the result https://github.com/docker/build-push-action. To rewrite here.
https://github.com/docker/build-push-action
At that time: 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 ~~. Regarding CR_PAT, it's an abbreviation for Container Registry Personal Access Token. Actually, it was written at the time of starter-workflow, so I set the token of github with that name. (Github.token is fine, but it seems better to narrow down the access token as much as possible, so I gave permissions only to the access repository and write repository)
Later, I also added the push settings for 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 }}
In the example of build-push-action, password was set, but Docker Hub also has an access token, so use that. I put it on after setting it.
https://docs.docker.com/docker-hub/access-tokens/
As it is, it does not refer to the cache. (However, the second build-push-action is based on cache, so if you build + push one, you can push the other immediately)
build-push-action has a parameter called cache_froms, so I want to use it well.
After trying various things, I found that I need to use Buildkit in order to use cache_froms.
It also turned out that you had to set build_args: BUILDKIT_INLINE_CACHE = 1.
Apparently, cache_froms had a bad atmosphere unless the domain part was also specified. ← I was worried here
So it looks like this.
- 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 }}
You can go with this! I thought
It's not cached ... so if you look at 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
An error occurred like this and the cache could not be acquired and the build ran as it was. Apparently the GitHub Package Registry doesn't yet support docker's new manifest. (GitHub Container Registry seems to support it)
https://github.community/t/handle-multi-arch-docker-images-on-github-package-registry/14314
So, I decided to build from docker Hub first. cache_froms must be written from 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 }}
So it looks like this.
#4 importing cache manifest from docker.io/fagai/php:7.2-alpine-fpm
#4 DONE 0.2s
Subsequent processing will also be displayed as CACHED, indicating that the build is not working and is cache-based.
- name: cancel old workflow
uses: styfle/[email protected]
with:
access_token: ${{ github.token }}
I've done this in the past. It is an Action that cancels the past Action. It solves the problem that past Actions remain and move when you commit many times.
I also set a schedule so that Action works every Monday.
on:
push:
branches:
- master
pull_request:
#Do regular updates(every Monday)
schedule:
- cron: '0 0 * * 1'
As a result of building and pushing to GitHub Actions, the problem that Docker Hub waits in Queue all the time has been solved, and above all, it can be built in parallel, so it can be pushed in a short time.
build-push-action is v2 and buildx It seems that the newly added build in Docker 19.03 will be used.
BuildKit seems to be semi-official, and Buildx seems to be an official multi-CPU build compatible function.
On mac, by typing docker buildx install, an alias to docker build will be pasted and buildx will be used without permission. How nice.
Recommended Posts