I was unaware of this, I’ve been using version 3.* all the time. What makes 2.* version more suitable for normal docker flow in development?
brundozer
slouchpie
I would love to see other people’s docker setup for Phoenix app in :dev env. Please share.
1
cnck1387
You should use COPY in development, because ideally you’d have 1 Dockerfile that is identical for both development and production and you can use multi-stage builds to make your production image smaller in the end.
Then for having a dev environment that’s developer friendly, you can set up a volume mount in docker-compose.yml because a volume mount will override what you COPY in, if it’s the same destination directory.
If you really wanted to focus on having the same Dockerfile / docker-compose.yml file in both dev and prod (which I highly recommend), you can define that volume with an environment variable and have the prod one lead to an unused directory.
Order of operations in your Dockerfile should be this as separate layers:
- Copy in mix / lock files
- Install dependencies
- Copy in all of your code
This way you don’t need to rebuild all of your dependencies when you build a new image that only contains changing a few lines of application code (such as editing an EEx template).
0
Exadra37
If you map the entire app folder in the docker compose file you don’t loose your compiled dependencies when you do docker compose down or even if you remove/rebuild the docker image. Therefore it also doesn’t affect the boot time. You just need to to do the usual mix deps.get && mix compile when you use the app after the first time you build the docker image, but even this can be automated as I do in my docker projects.
Well I don’t like to use that word in my life, and should not have used it here, but I still stand for my principle that I don’t see it as a good fit for any development scenario.
I my opinion the COPY or ADD commands are very useful when building a release of the app inside a docker container, other them that is just getting in my way.
0
H12
Your given code does not even run for me. I get permission denied error when container tries to run
run.sh.
Ah right, forgot to mention: I had to give the run.sh file execute permissions with chmod +x run.sh.
Try this setup
This appears to have fixed my problem!
There were a couple of things I had to tweak to fit my setup, since it looks like the Dockerfile & docker-compose.yml you provided had some extra goodies I didn’t have/need (e.g. the chromium-driver & a seeds directory). I also had some problems with docker-compose up failing due to the assets directory volume being set to read-only, but removing the :ro fixed that.
Another quick note is that, because I’m on MacOS, COPYing existing dependencies and compiled artifacts can cause problems. This was solved by rm -rfing the appropriate directories before building the container.
Anyway, here’s the final result:
Dockerfile
FROM elixir:1.10
RUN apt-get update
RUN apt-get install --yes build-essential inotify-tools
# Set working directory
RUN mkdir -p /app
WORKDIR /app
# Install hex, rebar, and phx_new
RUN mix local.hex --force && \
mix local.rebar --force && \
mix archive.install --force hex phx_new
# Copy and install the elixir deps
COPY mix.exs .
COPY mix.lock .
RUN mix deps.get && mix deps.compile
# Install nodejs
RUN curl -sL https://deb.nodesource.com/setup_12.x | bash - &&\
apt-get install --yes nodejs
# Copy and install the nodejs deps
COPY assets ./assets
WORKDIR /app/assets
RUN npm install
WORKDIR /app
# Copy over compiled files
COPY config ./config
COPY lib ./lib
COPY priv ./priv
COPY test ./test
# Compile the app
RUN mix compile
# Compile deps in test environment for faster test runs when built
RUN MIX_ENV=test mix deps.compile
# Set the run command
CMD ["mix", "phx.server"]
docker-compose.yml
version: "3"
services:
app:
build: .
ports:
- "4000:4000"
volumes:
- /app/assets/node_modules
- ./assets:/app/assets
- ./config:/app/config:ro
- ./lib:/app/lib:ro
- ./priv:/app/priv
- ./test:/app/test:ro
- ./mix.exs:/app/mix.exs:ro
My suspicion is that the root cause of my issue was not having a volume for my config directory. Maybe something about those files living in the container was causing the CodeReloader to freak out? Who knows.
Thanks for the help! This had been driving me crazy for a while.
0
slouchpie
hagi
My suspicion is that the root cause of my issue was not having a volume for my
configdirectory. Maybe something about those files living in the container was causing the CodeReloader to freak out? Who knows.
This is exactly what solved the same problem on my setup. I didn’t copy anything in Dockerfile, just added bunch of volumes based on @slouchpie snippets.
volumes:
- ./_build:/app/_build
- ./assets:/app/assets
- ./config:/app/config:ro
- ./deps:/app/deps
- ./lib:/app/lib
- ./priv:/app/priv
- ./test:/app/test
- ./mix.exs:/app/mix.exs:ro
- ./mix.lock:/app/mix.lock
Thanks a lot
1
Sanjibukai
Hello,
What a coincidence, I’m just working also with LiveView and just noticed that the live reloading doesn’t work.
While everything was smooth with regular Phoenix controllers.
In my case, I always set a parent folder where I have all docker related files alongside a directory of the Phoenix project where the whole parent folder is set as a volume.
my_project/
├── my_phoenix_app/
│ ├── lib/
│ ├── mix.exs
│ └── ...
├── docker-compose.yml
├── dev.Dockerfile
├── docker-compose.prod.yml
└── prod.Dockerfile
And in development I have that whole my_project folder as a volume.
It might be a little odd to have a different dockerfile for dev and prod, but there’s two reason why I’m doing like this:
- In dev I’m using VSCode remote container capabilities, so somehow very different from the prod
- For prod I’m using multi-stage builds and producing a release for the last step
Anyway, I have no idea why the LiveReload is not working.
At first I thought that I didn’t opened the Live Reload port (usually 35729) but then I noticed that here with phoenix the LIve Reload is done within the same port, and indeed the livereload WS correctly connects.
Then I suspect it’s about inotify (I’m on linux), but then I noticed that when I save a CSS file for example, it correctly triggers the asset pipeline build.
I then suspected that the LiveView files were not defined in the pattern of the live_reload config in the Endpoint. But it is.
So I have no clue and don’t fix yet the live reloading (which is a little annoying)
0
bryanhuntesl
I’ve seen this class of issues so many times - attempt to create a development environment that will work across all developer machines in order that they don’t have to deal with the complexity of installing Elixir/Erlang and setting up a developer environment.
I don’t recommend this approach - make it so the developer only needs to run Docker in order to debug CI issues - for everything else, developer should be just running iex -S mix phx.server locally, add a Makefile with commands to run postgres in docker and expose the port, same for any other service dependencies.
0
H12
Could you expand on why you don’t recommend using Docker for local development?
My use-case may be unique, since I’m only attempting to introduce my co-workers to Elixir via a small, fun side-project in the hopes that it catches on and we can start actually using it in production. Using Docker seemed like the best option to make the experience as frictionless as possible, since most of our devs should already have it installed.
If Elixir does catch on and we start using it for real work, would it be beneficial to move away from Docker for local dev and get everyone to install Elixir & Erlang natively on their machines?
0