Can't run Phoenix using docker-compose

Hi, I am trying to get Phoenix app work using containers and elixir releases.

I succeeded to run my app in a single container and connect it to local postgres using dockerfile and command below:

Dockerfile:

FROM elixir:1.9.0-alpine AS build

# install build dependencies
RUN apk add --no-cache build-base npm git python

# prepare build dir
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 ./
COPY config config
RUN mix do deps.get, deps.compile

# build assets
COPY assets/package.json assets/package-lock.json ./assets/
RUN npm --prefix ./assets ci --progress=false --no-audit --loglevel=error

COPY priv priv
COPY assets assets
RUN npm run --prefix ./assets deploy
RUN mix phx.digest

# compile and build release
COPY lib lib
# uncomment COPY if rel/ exists
# COPY rel rel
RUN mix do compile, release

# prepare release image
FROM alpine:3.9 AS app
RUN apk add --no-cache openssl ncurses-libs

EXPOSE 4000
ENV PORT=4000 \
    MIX_ENV=prod \
    SHELL=/bin/bash

WORKDIR /app

RUN chown nobody:nobody /app

USER nobody:nobody

COPY --from=build --chown=nobody:nobody /app/_build/prod/rel/myapp ./

ENV HOME=/app

CMD ["bin/myapp", "start"]

Commands:

docker build -t test .
docker run \
  --network=host \
  -e DATABASE_URL=postgresql://postgres:postgres@localhost/myapp_dev \
  -e SECRET_KEY_BASE=...some key... \
  -e HOST=localhost \
  test    

But when I am trying to up two containers via docker-compose.yml

version: '3'

services:
  PostgreSQL:
    image: postgres
    container_name: postgres
    ports:
      - 5433:5432
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_INITDB_ARGS: "--encoding=UTF-8"
    hostname: postgres
    restart: always
    user: root
  elixir:
    build:
      context: .
      dockerfile: Dockerfile
    env_file:
      - .env.list
    ports:
      - 4040:4000
    container_name: elixir
    volumes:
      - .:/app
    depends_on:
      - PostgreSQL

.env.list:

DATABASE_URL=postgresql://postgres:postgres@postgres/myapp_prod
SECRET_KEY_BASE=... some key...
HOST=localhost

I am getting an error:

Creating postgres ... done
Creating elixir   ... error

ERROR: for elixir  Cannot start service elixir: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "bin/myapp": stat bin/myapp: no such file or directory: unknown
ERROR: Encountered errors while bringing up the project.

I suppose that docker-compose should just run elixir container with according dockerfile as just it happens with “docker run …”, but it seems that I get different container which doesn’t have bin/ directory for some reason. Am I missing something?

it seems, volume mount for elixir container in the docker-compose overwrites the docker build container files. Try removing the mount and see if that solves the issue.

volumes:
      - .:/app
# remove this
2 Likes

Never use the root user in any docker image, just like you would not use it in a real server.

The database is open to the internet. You don’t need to expose the ports for the elixir service to be able to reach it.

This is not necessary, instead just change the name of the docker-compose service from PostgreSQL to postgres.

If is for running in localhost then you need to do it like 127.0.0.1:4040:4000, otherwise it may be reachable from the internet, unless you have other security measures in place.

The use of 4040:4000 is equivalent to 0.0.0.0:4040:4000, and 0.0.0.0 means it will be listening in all configured networks on your computer.

It’s unsafe to use the nobody user as I report on this issue and now being merged to the official docs.

3 Likes

@pmangalakader
Thanks you! It solves the issue!

@Exadra37
Thank you for detailed response, a lot of useful info for me as for docker beginner.
Also I took a look at the PR you mentioned and tried to build a fresh image with new dockerfile, but it has this line:

# changes to config/runtime.exs don't require recompiling the code
COPY config/runtime.exs config/

It seems that “config/runtime.exs” file is not a default thing, at least there is no mentions in docs to create it, and as well I don’t have one.

1 Like

Unfortunately it’s not a default.

It was introduced in Elixir 1.11 to solve the configuration issues that have plagued Elixir since the begin.

Think of this file not as runtime but instead as a boot time configuration file, because contrary to what the name runtime implies it doesn’t allow to change configuration while your app is running, but it allows you to change configuration every time you boot your app.

In my apps I move all configuration to this file as much as possible. Check the official docs here:

To enable runtime configuration in your release, all you need to do is to create a file named config/runtime.exs:

import Config
config :my_app, :secret_key, System.fetch_env!("MY_APP_SECRET_KEY")

Secrets in Releases

For example prod.secret.exs isn’t secure to use, because now you have your production secrets inside the release binary and production secrets MUST BE only present in the server running the app, otherwise you risk to leak the secrets in all the places were the release binary is handled. It’s easy to reverse engineer a binary and extract those secrets.

Always require your secrets in runtime.exs with the use of environment variables. This approach will keep your production secrets outside the release binary that you have built somewhere else.

@Exadra37
I succeeded to build an image from new dockerfile, with all boot logic in runtime.exs as you said, but when I try:

sudo docker container run --rm -it -p 127.0.0.1:4000:4000 --name my_app elixir/my_app

I get

mkdir: can't create directory '/home/elixir/app/tmp': Permission denied
ERROR: Cannot start release because it could not write /home/elixir/app/tmp/myapp-0.1.0-20210411150040-8d6a.runtime.config

You need to share the exact dockerfile you are using, otherwise is not possible to understand whats going on.

Exact as here

FROM hexpm/elixir:1.11.2-erlang-23.1.2-alpine-3.12.1 as build

# install build dependencies
RUN apk upgrade --no-cache
RUN apk add --no-cache build-base npm git python3 curl

# prepare build dir
WORKDIR /app

# install hex + rebar
RUN mix local.hex --force && \
    mix local.rebar --force

# set build ENV
ARG MIX_ENV="prod"
ENV MIX_ENV="${MIX_ENV}"

# install mix dependencies
COPY mix.exs mix.lock ./
RUN mix deps.get --only $MIX_ENV
RUN mkdir config
# Dependencies sometimes use compile-time configuration. Copying
# these compile-time config files before we compile dependencies
# ensures that any relevant config changes will trigger the dependencies
# to be re-compiled.
COPY config/config.exs config/$MIX_ENV.exs config/
RUN mix deps.compile

# build assets
COPY assets/package.json assets/package-lock.json ./assets/
# install all npm dependencies from scratch
RUN npm --prefix ./assets ci --progress=false --no-audit --loglevel=error

COPY priv priv

# Note: if your project uses a tool like https://purgecss.com/,
# which customizes asset compilation based on what it finds in
# your Elixir templates, you will need to move the asset compilation step
# down so that `lib` is available.
COPY assets assets
# use webpack to compile npm dependencies - https://www.npmjs.com/package/webpack-deploy
RUN npm run --prefix ./assets deploy
RUN mix phx.digest

# compile and build the release
COPY lib lib
RUN mix compile
# changes to config/runtime.exs don't require recompiling the code
COPY config/releases.exs config/
# uncomment COPY if rel/ exists
# COPY rel rel
RUN mix release

# Start a new build stage so that the final image will only contain
# the compiled release and other runtime necessities
FROM alpine:3.12.1 AS app
RUN apk upgrade --no-cache
RUN apk add --no-cache openssl ncurses-libs

ARG MIX_ENV="prod"
ENV USER="elixir"

WORKDIR "/home/${USER}/app"
# Creates an unprivileged user to be used exclusively to run the Phoenix app
RUN \
  addgroup \
   -g 1000 \
   -S "${USER}" \
  && adduser \
   -s /bin/sh \
   -u 1000 \
   -G "${USER}" \
   -h /home/elixir \
   -D "${USER}" \
  && su "${USER}"

# Everything from this line onwards will run in the context of the unprivileged user.
USER "${USER}"


COPY --from=build --chown="${USER}":"${USER}" /app/_build/"${MIX_ENV}"/rel/my_app ./

ENTRYPOINT ["bin/my_app"]

# Usage:
#  * build: sudo docker image build -t elixir/my_app .
#  * shell: sudo docker container run --rm -it --entrypoint "" -p 127.0.0.1:4000:4000 elixir/my_app sh
#  * run:   sudo docker container run --rm -it -p 127.0.0.1:4000:4000 --name my_app elixir/my_app
#  * exec:  sudo docker container exec -it my_app sh
#  * logs:  sudo docker container logs --follow --tail 100 my_app
#
# Extract the production release to your host machine with:
#
# ```
# mkdir archive
# sudo docker container run --rm -it --entrypoint "" -v "$PWD/archive:/home/phoenix/archive"  phoenix/my_app sh -c "tar zcf /home/phoenix/archive/app.tar.gz ."
# ls -al archive
# ````
CMD ["start"]
1 Like

@fly49 try this, the chown worked for me:

# Creates an unprivileged user to be used exclusively to run the Phoenix app
RUN addgroup -g 1000 -S "${USER}" && \
    adduser -s /bin/sh -u 1000 -G "${USER}" -h /home/"${USER}" -D "${USER}" && \
    su "${USER}"

RUN chown -R "${USER}:${USER}" "/home/${USER}"
# Everything from this line onwards will run in the context of the unprivileged user.
USER "${USER}"

the directory /home/user, the user directory was owned by root and hence, the error occurs.

1 Like

Thank you for the answer! I got suck a the creating and migrating database on containers initialization, tried the trick from here, but it doesn’t work for me… Could you recommend me something?

1 Like

@fly49 It’s a straight-forward implementation and I’m using somewhat same pre-start scripts in multiple accounts and works like a charm. Due to NDA constraints, I’m unable to share them with you.

If you could create a new topic and post relevant logs, it would be easier for others also to help you.