I have a problem running my dockerized phoenix application with postgresql.
I specified my docker-compose.yml file to include two services: my phoenix service, build by a dockerfile and a latest postgres image taken from docker hub.
My dockerfile for phoenix looks like this:
# base image elixer to start with
# install hex package manager
RUN mix local.hex --force
RUN mix local.rebar --force
# install the latest phoenix
RUN mix archive.install https://github.com/phoenixframework/archives/raw/master/phx_new.ez --force
# create app folder
RUN mkdir /app
COPY ./my_app /app
# install dependencies
RUN mix deps.get
# run phoenix in *dev* mode on port 4000
# CMD mix phx.server
TL;DR: Set them in a way, that makes you able to keep them in synch easily.
The environment key is always for the surrounding image only.
Usually you are passing those environment variables to the postgresql container to configure it.
Then you have to makje sure that all clients use the same credentials as passed into the postgres container. How you do this often depends on your overall architecture.
Most of the time its just hard-configuring them in the config/<env>.exs or passing them as environment variable into the client container as well.
But vault managed credentials are possible as well. Well, kind of… Changing the credentials for a repo requires it to kill the repos supervisor and restart it with new credentials as far as I understand…
Thanks @cnck1387 I set my POSTGRES_USER and POSTGRES_PASSWORD in the .env file, but it does not seem to work. The error I get back is password authentication failed for user “my_username”. I use this same username and password on my localhost without containers and it works just fine. Just not with containers
That’s because the postgres image creates a default database and database user based on those environment variables on the first time it runs (assuming a volume is persisted).
Perhaps you changed those values after you’ve upped your project?
If that’s the case you’ll want to delete your postgres volume which you could do by running docker-compose down -v, but please don’t run that in production. That’s just meant as a quick and easy way to destroy all volumes which is handy for development.
If you’re in production you would want to either change your user and password values to match what they were when you first ran your compose project, or use psql to manually change the user / password to whatever new ones you set (similar to what you would do without Docker).
Yes this did the trick, I also had to add this to my dockerfile
CMD mix ecto.create && mix ecto.migrate
CMD mix phx.server
Do I need to be concerned with this log?
db | /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
db | waiting for server to shut down....2018-07-24 16:55:43.497 UTC  LOG: received fast shutdown request
db | 2018-07-24 16:55:43.499 UTC  LOG: aborting any active transactions
db | 2018-07-24 16:55:43.508 UTC  LOG: worker process: logical replication launcher (PID 45) exited with exit code 1
db | 2018-07-24 16:55:43.509 UTC  LOG: shutting down
db | 2018-07-24 16:55:43.530 UTC  LOG: database system is shut down
db | done
db | server stopped
db | PostgreSQL init process complete; ready for start up.
db | 2018-07-24 16:55:43.609 UTC  LOG: listening on IPv4 address "0.0.0.0", port 5432
db | 2018-07-24 16:55:43.609 UTC  LOG: listening on IPv6 address "::", port 5432
db | 2018-07-24 16:55:43.613 UTC  LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
db | 2018-07-24 16:55:43.629 UTC  LOG: database system was shut down at 2018-07-24 16:55:43 UTC
db | 2018-07-24 16:55:43.635 UTC  LOG: database system is ready to accept connections
I wouldn’t put create / migrate in your Dockerfile. Those are really something you do at runtime, not build time.
I would just docker-compose exec those commands after you up everything beforehand. Or if you were really gung-ho on having that done automatically on every container start you could put it into an entrypoint script but personally I don’t like doing that.
What I understand here is that I should be running mix ecto.create and mix ecto.migrate before running mix phx.server. If I put these as entrypoints inside of a shell script and run this, my docker container crashes since mix phx.server depends on both ecto create and migrate commands