Can't run Phoenix using docker-compose

Sure I’ll do it, thank you

Sorry for the delay in the reply but I have been away from Elixir for some months, does I am not aware how things are related to this.

I would suggest for you to open a new post with reproducible steps to replicate your issue and then people will jump in and try to help/guide you.

Hey @Exadra37
As you said it’s merged but changes not working ​
Today I was preparing for docker deployment and for mix phx.gen.release --docker command as suggested on Phoenix documents
Used versions to generate: Elixir 1.13, Phoenix 1.6.6
The nobodyvariable still being used in generated Dockerfile file
Is it expected behavior or it needs to be reported them on the PR?

@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.

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?

@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.

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"]

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

@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

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.