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.