I’m deploying a Phoenix app with Elixir releases and Docker. The Phoenix docs have an example dockerfile you can use – mine is based on that one.
I’ve set up the file so that dependency downloads and compilation should be cached by Docker, but this isn’t happening. This is slowing down deploys a bit. Can anyone spot why Docker isn’t caching dependencies? Even when mix.exs is unchanged, it redownloads and rebuilds them.
FROM elixir:1.9.0-alpine as build
# install build dependencies
RUN apk add --update git build-base
# prepare build dir
RUN mkdir /app
WORKDIR /app
# install hex + rebar
RUN mix local.hex --force && \
mix local.rebar --force
# set build ENV
ENV MIX_ENV=prod
# install mix dependencies
COPY mix.exs mix.lock ./
RUN mix deps.get
RUN mix deps.compile
COPY config config
# build assets
# COPY assets assets
# RUN cd assets && npm install && npm run deploy
# RUN mix phx.digest
# build project
COPY priv priv
COPY lib lib
RUN mix compile
# build release
COPY rel rel
RUN mix release
Interesting. Nope, the dependencies get redownloaded and rebuilt even when I haven’t touched those files – that’s why I’m confused and why I opened this thread!
The Phoenix docs actually have a slightly different order:
COPY mix.exs mix.lock ./
COPY config config
RUN mix deps.get
RUN mix deps.compile
I moved this around since I didn’t want to redownload deps after changing configuration, but now I’m starting to wonder if there’s a reason to their ordering?
Can you give an example where a config’s value would determine how dependencies are built?
I know you can choose to install packages based on the environment with mix but isn’t that controlled by the mix command itself with --only prod along with mix.exs?
Okay, I’ll try going back to the original config from the docs!
I’m not sure I understand how this could make Docker not cache things, though. All that Docker knows is that nothing has changed in mix.exs and mix.lock, yet it still re-runs the dependency steps instead of using the cached versions.
As an example, Logger lets you remove log calls from modules at compile time, even in dependencies, through the config option :compile_time_purge_matching.
Oh, sorry, I was just respond to your comment “determine how dependencies are built” and giving an example of the compile time configuration @NobbZ mentioned. Not sure how config would affect which dependencies get installed though, since that’s the job of the mix.exs and mix.lock.
the Docker COPY command should perform a checksum of the given source files, and use that for caching. It should not even check the creation/modification time of the files.
The RUN command should only use the command string to determine whether to use the cache or re-run the command.
Therefore, the dependencies will be re-fetched if any of the following conditions apply:
The Dockerfile line RUN mix deps.get or any Dockerfile command appearing before it was modified
The content of mix.exs or mix.lock changed
As I understand, you say that none of those happened, and the dependencies are still re-fetched. In order to understand what is going on, it would be interesting to check:
What is the first Dockerfile command to invalidate the cache? Is it RUN mix deps.get or something even earlier?
If you separate the COPY mix.exs mix.lock ./ into two different COPY commands, which one uses the cache and which does not?
I hope we can guess what’s wrong with this information
Another possibility could be that the environment where you are building the docker image does not support caching (e.g. on CI it is usually necessary to configure caching of artifacts, otherwise every build starts from a fresh context and won’t find any cached layer to reuse)
I’m just separating it into two commands like you suggested now. I’ll update here when I try this out! FWIW this is running on Dokku, so caching should be supported.
