GitHub Action Docker image cache

Phoenix
1

Is there a way to cache the image that’s built by Docker via the GitHub Action? It’s installing Linux CLI tools and all my Ruby gems and Node modules on each deploy which takes a while. I’m not sure if there’s a setting to connect to a specific Docker registry/Hub/etc. Thanks!

2

I’ve looked at Docker caching in GitHub Actions a few times and it’s not obvious how to make it just work.

It seems like it’s possible, though: https://github.community/t/cache-a-docker-image-built-in-workflow/16260

You can actually do separate build + deploy steps with flyctl and docker. You might be able to take advantage of some Docker caching actions by separating those steps, this is the simplest version:

docker build . -t myapp
flyctl deploy -i myapp

This will push the image layers directly from the machine and skip the flyctl build step.

If you figure something out, let us know, we do like to share instructions with people for this stuff!

3

Sorry I didn’t reply back. Thanks for the pointers, I’ll look into it further. :slight_smile:

4

Here’s a working Github Actions workflow with Docker layer caching and image build in separate step for transparency:

name: Fly

on:
  push:
    branches:
      - main

env:
  FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}

jobs:
  fly_deploy:
    name: Deploy with Fly

    runs-on: ubuntu-20.04

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

      - name: Setup Docker layer caching
        uses: satackey/action-docker-layer-caching@v0.0.11
        continue-on-error: true

      - name: Build app Docker image
        run: docker build . -t myapp

      - name: Deploy with Fly
        uses: superfly/flyctl-actions@1.1
        with:
          args: "deploy -i myapp"

It has cut my Elixir + Rust + Node multistage builds from ~6min to ~2-3min. The cache restoration step does take ~50s so things could be better if Github one day does this in native way.

1 Like
5

Warning: over time the satackey/action-docker-layer-caching@v0.0.11 has started taking more & more time & space up to unreasonable ~5mins to restore + ~5mins to save cache, so I’ve had to disable it. I’m guessing that old Docker layers are not cleared properly - something that this article about Github Actions Docker caching mentions: Build images on GitHub Actions with Docker layer caching — Martian Chronicles, Evil Martians’ team blog. Maybe I’ll revisit caching using the instructions from the above article, but there’s a rumor (sorry, I don’t have a link) that something relevant from Github itself will be out this year, so it may be worth waiting a while.

6

FYI One thing that I’ve initially missed looking to optimize GH deployments is that fly deploy has the --remote-only option that allows to build image on Fly machine with dedicated CPU and persistent volume that caches Docker layers, more info here: New & Improved Remote Builders.

Edit: Along with --detach, fly.toml update (99% cached) went from ~10m to 40s! :rocket: OMG why isn’t this marvel exposed better? :slight_smile:

3 Likes
7

It appears a lot faster, but your deployment still take ~10m to fully happen :slight_smile:. The default is not to detach so users are better aware of rollbacks.

8

No no, --detach only makes ~1m difference in my case (1 instance in ewr + 1 in fra). It’s the docker caching that took out the remaining 9m (multi-stage image with Node stage, Rust stage, Elixir stage and final assembly stage). I had easy time spotting the culprit as I was doing docker build separately in yaml posted above.

I actually added --detach more to avoid occasional hangs of GH Actions during the fly monitor stage than to save time as I’d prefer to burn that extra minute but have deployment logs on the CI. Perhaps I shouldn’t have added it here to avoid confusion.

Anyway, remote builders are another deeply hidden solution to my deeply burning problem. :wink:

1 Like
9

I’m actually working on adding notes about the builders to the docs… just to make I’m putting them in the right place, on which page(s) did you / would you have looked for them?

10

I’d definitely start with Continuous Deployment with Fly and GitHub Actions as that’s what I went through before landing in this thread. Also, the --remote-only option is only sparingly documented at Flyctl - I think it deserves a separate page that would wrap what’s in New & Improved Remote Builders. If such separate page would be linked both from Github Actions and flyctl doc, it would be perfect IMO.

1 Like