Mattermost, Inc.

Cannot connect to the postgresql database using mattermost cli

Summary

Unable to connect to postgresql database lying on a different container than the database

Steps to reproduce

I’m using the mattermost command.
mattermost user create --email test2@email.com --username testatene --password Password

Observed behavior

{“level”:“error”,“ts”:1564644335.8744648,“caller”:“sqlstore/supplier.go:236”,“msg”:“Failed to ping DB retrying in 10 seconds err=dial tcp 127.0.0.1:5432: connect: connection refused”}

Is there any way I can change the postgresql path? The container is reacheable through the “db” name set in docker-compose, but I haven’t found a way to set that path.

Thanks in advance!

Hello, @vinci.

Perhaps we can start by looking on the following:

  • Did you deploy Mattermost through the Production Docker Deployment?

  • Since you mentioned that the container is reachable through the database name, can you please let us know how did you confirm that? Did you try to ping to the machine hosting the database from the container and vice versa or did you use any other methods?

  • Can you share a copy of the docker-compose.yaml here so we can go through it together?

Hi,
Yes, this is the docker-compose I’m using. It comes directly from the gitlab site (https://github.com/mattermost/mattermost-docker). This seems to be defaul behaviour with mattermost. I’ve got two somewhat different installations with the same problem, one of which uses different settings for the reverse proxy:

version: "2"

services:

  db:
    build: db
    read_only: true
    restart: unless-stopped
    volumes:
      - ./volumes/db/var/lib/postgresql/data:/var/lib/postgresql/data
      - /etc/localtime:/etc/localtime:ro
    environment:
      - POSTGRES_USER=mmuser
      - POSTGRES_PASSWORD=mmuser_password
      - POSTGRES_DB=mattermost
    # uncomment the following to enable backup
    #  - AWS_ACCESS_KEY_ID=XXXX
    #  - AWS_SECRET_ACCESS_KEY=XXXX
    #  - WALE_S3_PREFIX=s3://BUCKET_NAME/PATH
    #  - AWS_REGION=us-east-1

  app:
    build:
      context: app
      # uncomment following lines for team edition or change UID/GID
      args:
        - edition=team
        - PUID=5000
        - PGID=5000
    restart: unless-stopped
    volumes:
      - config:/mattermost/config:rw
      - data:/mattermost/data:rw
      - logs:/mattermost/logs:rw
      - plugins:/mattermost/plugins:rw
      - client-plugins:/mattermost/client/plugins:rw
      - /etc/localtime:/etc/localtime:ro
    environment:
      # set same as db credentials and dbname
      - MM_USERNAME=mmuser
      - MM_PASSWORD=mmuser_password
      - MM_DBNAME=mattermost
      # in case your config is not in default location
      #- MM_CONFIG=/mattermost/config/config.json
    extra_hosts:
      - "mm.vinci.de:192.168.99.12"
      - "git.vinci.de:192.168.99.11"

  web:
    build: web
    ports:
      - "80:80"
      - "443:443"
    read_only: true
    restart: unless-stopped
    volumes:
      # This directory must have cert files if you want to enable SSL
      - ./volumes/web/cert:/cert:ro
      - /etc/localtime:/etc/localtime:ro
    # Uncomment for SSL
    # environment:
    #  - MATTERMOST_ENABLE_SSL=true
    extra_hosts:
      - "mm.vinci.de:192.168.99.12"
      - "git.vinci.de:192.168.99.11"
volumes:
    config:
    data:
    logs:
    plugins:
    client-plugins:

So as you see, the images were built directly using the github files of the mattermost official repo.
I can’t ping into the other container, I’m guessing it’s because I can’t do with with the mattermost user (probably because it’s not allowed access to ping etc.) Ping does work from database to the app, though.
How would the application know to reach the ‘db’ name nonetheless? It can’t work like that, if it’s not set somewhere in the configuration files or whatever. I could have named the container something else, but I’d still expect it to work by being able to offer it the path to the db.

Later did I see that there’s actually a DB_HOST=${DB_HOST:-db} in the Dockerfile, which doesn’t actually appear in the environmental variables in the in the app container.

Hey @vinci,
what is the exact command or commands you use to run this?

I’ve found that running the command from inside the machine did not work.
However using docker exec worked for me because then all the environment vars are set correctly.
So for example to get the server version I’d use
docker exec -it mattermost_docker_app_1 /mattermost/bin/mattermost version