0

I'm having issues with postgres for 2 docker deployments on the same host. I need to deploy the same app with docker compose on the same host. I have one docker-compose file and two .env for each instance. The app is built with Ruby and Hanami web framework.

When deploying the first instance (production) it runs fine. With the second instance (staging) I get this error during docker-compose setup:

PostgreSQL Database directory appears to contain a database; Skipping initialization
.
.
.

 2022-07-30 16:13:48.978 UTC [33] FATAL:  password authentication failed for user "some_user"
postgres_1  | 2022-07-30 16:13:48.978 UTC [33] DETAIL:  Role "some_user" does not exist.

I also see the port being used is 5432, which is the one used for production. For staging, I've specified the other_user and a different port as you can see in the file below.

Here are the files in question with which I wanted to separate these DB instances:

  1. docker-compose
version: '3'
services:
  postgres:
    image: postgres
    environment:
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=${POSTGRES_DB}
    ports:
      - ${POSTGRES_PORT}:${POSTGRES_PORT}
    volumes: 
      - postgres:/var/lib/postgresql/data

  web:
    build: .
    command: >
      bash -c "bundle exec hanami db migrate
      && bundle exec rake initial_settings:add_default_language
      && bundle exec rake initial_settings:add_session_validity
      && bundle exec rake import_user:create
      && bundle exec rake super_admin:create
      && bundle exec hanami assets precompile
      && bundle exec hanami server
      && cp -r apps/wordrocket/assets/webfonts public/webfonts
      && cp -r apps/wordrocket/assets/webfonts public/assets/webfonts
      && cp -r apps/wordrocket/assets/images/sort*.png public/assets
      && cp -r apps/wordrocket/assets/images/sort*.png public
      && cp -r apps/wordrocket/assets/images/ui-icons*.png public/assets/wordrocket
      && mkdir public/assets/images
      && cp -r apps/wordrocket/assets/images/sort*.png public/assets/images"
    volumes:
      - ./hanami_log/hanami_app.log:/usr/src/app/hanami_log/hanami_app.log
    links:
      - postgres
    depends_on:
      - postgres

  nginx:
    image: nginx:alpine
    restart: unless-stopped
    tty: true
    ports:
      - "${NGINX_PORT}:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - ./nginx_log:/var/log/nginx
    depends_on:
      - web

volumes:
  postgres:
  web:
  nginx:
  1. Production .env
POSTGRES_USER=some_user
POSTGRES_PASSWORD=some_password
POSTGRES_DB=app_production
NGINX_PORT=7080
COMPOSE_PROJECT_NAME=myAPP
POSTGRES_PORT=5432
  1. Staging .env.staging
POSTGRES_USER=other_user
POSTGRES_PASSWORD=other_password
POSTGRES_DB=app_staging
NGINX_PORT=7081
COMPOSE_PROJECT_NAME=myAPP_staging
POSTGRES_PORT=5433
  1. Makefile
production:
    docker-compose -f docker-compose.yml --env-file .env up

staging:
    docker-compose -f docker-compose.yml --env-file .env.staging up

I'm guessing I don't separate the postgres instances/dbs correctly, but I'm not sure. Also, is this a Docker or host problem?

+++ EDIT +++

I've made a separate docker-compose file for staging in order to differentiate between volumes.

production is the same:

  volumes: 
    - postgres:/var/lib/postgresql/data
.
.
.
volumes:
  postgres:
  web:
  nginx:

staging:

  volumes: 
    - postgres_staging:/var/lib/postgresql/data
.
.
.
volumes:
  postgres_staging:
  web:
  nginx:

This is the startup log up to the first error:

nginx_1     | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
nginx_1     | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
nginx_1     | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
nginx_1     | 10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
postgres_1  | The files belonging to this database system will be owned by user "postgres".
postgres_1  | This user must also own the server process.
postgres_1  | 
postgres_1  | The database cluster will be initialized with locale "en_US.utf8".
postgres_1  | The default database encoding has accordingly been set to "UTF8".
postgres_1  | The default text search configuration will be set to "english".
postgres_1  | 
postgres_1  | Data page checksums are disabled.
postgres_1  | 
postgres_1  | fixing permissions on existing directory /var/lib/postgresql/data ... ok
postgres_1  | creating subdirectories ... ok
postgres_1  | selecting dynamic shared memory implementation ... posix
postgres_1  | selecting default max_connections ... 100
postgres_1  | selecting default shared_buffers ... 128MB
postgres_1  | selecting default time zone ... Etc/UTC
postgres_1  | creating configuration files ... ok
postgres_1  | running bootstrap script ... ok
postgres_1  | performing post-bootstrap initialization ... ok
nginx_1     | 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
nginx_1     | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
nginx_1     | /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
nginx_1     | /docker-entrypoint.sh: Configuration complete; ready for start up
postgres_1  | syncing data to disk ... ok
postgres_1  | 
postgres_1  | 
postgres_1  | Success. You can now start the database server using:
postgres_1  | 
postgres_1  |     pg_ctl -D /var/lib/postgresql/data -l logfile start
postgres_1  | 
postgres_1  | initdb: warning: enabling "trust" authentication for local connections
postgres_1  | You can change this by editing pg_hba.conf or using the option -A, or
postgres_1  | --auth-local and --auth-host, the next time you run initdb.
postgres_1  | waiting for server to start....2022-07-31 10:03:12.510 UTC [47] LOG:  starting PostgreSQL 14.4 (Debian 14.4-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
postgres_1  | 2022-07-31 10:03:12.513 UTC [47] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1  | 2022-07-31 10:03:12.524 UTC [48] LOG:  database system was shut down at 2022-07-31 10:03:12 UTC
postgres_1  | 2022-07-31 10:03:12.529 UTC [47] LOG:  database system is ready to accept connections
postgres_1  |  done
postgres_1  | server started
postgres_1  | CREATE DATABASE
postgres_1  | 
postgres_1  | 
postgres_1  | /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
postgres_1  | 
postgres_1  | waiting for server to shut down...2022-07-31 10:03:12.745 UTC [47] LOG:  received fast shutdown request
postgres_1  | .2022-07-31 10:03:12.748 UTC [47] LOG:  aborting any active transactions
postgres_1  | 2022-07-31 10:03:12.749 UTC [47] LOG:  background worker "logical replication launcher" (PID 54) exited with exit code 1
postgres_1  | 2022-07-31 10:03:12.749 UTC [49] LOG:  shutting down
postgres_1  | 2022-07-31 10:03:12.771 UTC [47] LOG:  database system is shut down
postgres_1  |  done
postgres_1  | server stopped
postgres_1  | 
postgres_1  | PostgreSQL init process complete; ready for start up.
postgres_1  | 
postgres_1  | 2022-07-31 10:03:12.865 UTC [1] LOG:  starting PostgreSQL 14.4 (Debian 14.4-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
postgres_1  | 2022-07-31 10:03:12.865 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
postgres_1  | 2022-07-31 10:03:12.865 UTC [1] LOG:  listening on IPv6 address "::", port 5432
postgres_1  | 2022-07-31 10:03:12.871 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1  | 2022-07-31 10:03:12.879 UTC [61] LOG:  database system was shut down at 2022-07-31 10:03:12 UTC
postgres_1  | 2022-07-31 10:03:12.885 UTC [1] LOG:  database system is ready to accept connections
postgres_1  | 2022-07-31 10:03:13.014 UTC [68] FATAL:  password authentication failed for user "some_user"

Now this is the only instance being started. The production is not running even and it still tries to authenticate the production user.

Is it ignoring the .env.staging file?

+++ END EDIT +++

Best, Seba

Sebastjan Hribar
  • 396
  • 3
  • 13
  • It looks like you are trying to map the same directory on the host to be the volume for two different databases. So then the second one to start will just try to re-use the first ones database, rather creating its own. You need to map different host directories for each volume. – jjanes Jul 30 '22 at 19:03
  • @jjanes Did I make a mistake by specifying simply "postgres" as volume to be mapped? It's the same as the service name. So now, I see volumes in "/var/lib/docker/volumes/" as "myApp_postgres" and "myApp_staging_postgres". – Sebastjan Hribar Jul 31 '22 at 07:35
  • Even after removing all references to "some_user" from .env files, the startup still complains about it. I can still run production, but not staging. Even after pruning everything with "docker system prune --volumes". – Sebastjan Hribar Jul 31 '22 at 10:35
  • If you change "some_user" from the prod .env file to some other obscure string and then recreate staging, does the error message change to follow the new name? – jjanes Jul 31 '22 at 15:21
  • No, it doesn't, strangely enough. It still complains about the some_user. – Sebastjan Hribar Jul 31 '22 at 16:57
  • My fear came through, it was my mistake, as usual. I haven't force image building so it took an old one. I've now successfully built and deployed staging. I also made a stupid mistake of specifying the PG port 5433 for staging and it complained about that. I now need to build and deploy production. I'll update when I get to it. – Sebastjan Hribar Jul 31 '22 at 18:27
  • I now have both instances running side by side, apps seems to be working, DB saving works. I had to remove the port mapping for postgres though. I need to check a few more things and then I'll update the question and answer. – Sebastjan Hribar Jul 31 '22 at 19:24
  • I'm not sure if I should put this as an answer or just a comment. While most of the problems were resolved by force building the image, I've achieved the desired full separation of the two instances by providing the docker compose project name in the ENV files as seen in the question. – Sebastjan Hribar Aug 24 '22 at 04:25

0 Answers0