New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to quickly build and run images -- seeking help #401
Comments
If you talk about these steps:
That's necessary (oci export + import to docker). I think a more effective way than
Use a local registry instead.
As I can see in your workflow you're using the same cache for two different Dockerfiles/context which invalidates the cache for the next one. You should create one cache per Dockerfile/context and it should work. See also #153 (comment). - name: Cache Docker layers django
uses: actions/cache@v2
with:
path: /tmp/.buildx-django-cache
key: ${{ runner.os }}-buildx-django-${{ github.sha }}
restore-keys: |
${{ runner.os }}-buildx-django-
- name: Cache Docker layers celery
uses: actions/cache@v2
with:
path: /tmp/.buildx-celery-cache
key: ${{ runner.os }}-buildx-celery-${{ github.sha }}
restore-keys: |
${{ runner.os }}-buildx-celery-
- name: Build and push latest docker django image
uses: docker/build-push-action@v2
with:
file: docker/django/Dockerfile
tags: freelawproject/courtlistener-django:${{ github.sha }}
cache-from: type=local,src=/tmp/.buildx-django-cache
cache-to: type=local,dest=/tmp/.buildx-django-cache-new
- name: Build and push latest docker celery image
uses: docker/build-push-action@v2
with:
file: docker/task-server/Dockerfile
tags: freelawproject/task-server:${{ github.sha }}
cache-from: type=local,src=/tmp/.buildx-celery-cache
cache-to: type=local,dest=/tmp/.buildx-celery-cache-new
- name: Move caches
run: |
rm -rf /tmp/.buildx-django-cache
mv /tmp/.buildx-django-cache-new /tmp/.buildx-django-cache
rm -rf /tmp/.buildx-celery-cache
mv /tmp/.buildx-celery-cache-new /tmp/.buildx-celery-cache
If you have some images you want available when the runner is started you can use a self-hosted runner or you could maybe use the GitHub Cache for that. You also might be interested in Stargz Snapshotter. |
Thanks @crazy-max, these notes are incredibly helpful. I appreciate everything you do and the time you gave to help me. First, is there anything in this that you think is useful to the documentation? If so, I'd be happy to add it. Second, a few notes about what I was able to do for others that might land here:
Thank you again, @crazy-max. I think we can close this unless you have further comments you want to make. |
I plan to update the documentation for the new GitHub cache backend soon (see also moby/buildkit#1974 (comment)) which will drastically streamline the workflow.
Will be less messy with the new GitHub cache backend (moby/buildkit#1974 (comment))
Ok thanks for your feedback, will see how we can improve that in the future. See also docker/buildx#626
I would say that it is possible because everything in the GitHub Cache is downloaded from Azure Blob Storage as a single tarball and decompressed in the current API whereas the operation with docker pull is async for each layer.
With pleasure! |
I'm trying to do something pretty simple as quickly as possible:
If I'm not using this action, I just build the images (2 minutes), launch them (30s), and run tests (2 minutes) for a total of about 5 minutes.
Using this action, I've tried a couple different things:
Using the
load
parameter, I build the images, they get exported, and then they get run by docker compose. This works, but the export is surprisingly slow and I don't understand why it's necessary — it's not something my local machine does.Verdict: Works, but 11 minutes total. Nine minutes for docker stuff, and two to run tests.
Using the
push
parameter, I can push the built images to docker hub, then the docker compose will download them again from there. This works, but uploading then downloading the images is wasteful. Weirdly, it's faster than using theload
parameter.I also don't love this because I don't actually want to push the images and I'd prefer not to log into docker hub (Github Secrets are no longer available to people outside your organization, so if I do this, all outside contributions fail to log into Docker Hub).
Verdict: Works, except for outside contributors. 10 minutes total. Eight for docker stuff, two for tests. Seems to be the best option.
Using the caching approach seems promising — maybe I can build the images and they'll get cached and that'll be good. I must not be understanding this properly though, because I never get cache hits. The cache key in the link is
key: ${{ runner.os }}-buildx-${{ github.sha }}
, so maybe this is just a cache within each run of the action, not one that lasts across runs? This is really unclear to me.Verdict: Works, but no clear speed improvement. Hm.
I saw that there's an output type of
docker
. Maybe that is whatbuild
would normally do, sinceload
seems to do some strange exporting thing? I haven't figured out how to use this, and the docs seem to say that the only output that is "available" isdigest
.Verdict: Didn't try this yet b/c docs seem to say it won't work anyway and I'm a bit exhausted.
Finally, and perhaps separately, my docker compose uses a number of images that I don't build, and I can't figure out how to cache those. That'd be nice to accomplish somehow too.
I'd love some help here. The use case (build, launch, run) seems really common, but somehow it doesn't work as simply as I'd expect.
All the various approaches to this are here: https://github.com/freelawproject/courtlistener/actions/workflows/tests.yml?query=branch%3Afaster-docker
Thanks for all you do and for any help you can provide.
The text was updated successfully, but these errors were encountered: