Mattermost auf Docker mit traefik

hubort

Member
Moin ihr Lieben,

ihr kennt mich schon aus dem Bookstack-Beitrag.
Nun scheitere ich gerade an Mattermost und bin mir nicht ganz sicher weshalb. Ich hatte den Service bereits einmal testweise nach der offiziellen Dokumentation installiert, da allerdings ohne Einbindung von traefik.

Zwischenzeitlich Mattermost nochmal entfernt und nun neu aufsetzen wollen, bekomme ich immer wieder die folgende Fehlermeldung
Code:
WARN[0000] The "POSTGRES_IMAGE_TAG" variable is not set. Defaulting to a blank string.
WARN[0000] The "RESTART_POLICY" variable is not set. Defaulting to a blank string.
WARN[0000] The "POSTGRES_DATA_PATH" variable is not set. Defaulting to a blank string.
WARN[0000] The "RESTART_POLICY" variable is not set. Defaulting to a blank string.
WARN[0000] The "MATTERMOST_IMAGE" variable is not set. Defaulting to a blank string.
WARN[0000] The "MATTERMOST_IMAGE_TAG" variable is not set. Defaulting to a blank string.
WARN[0000] The "MATTERMOST_CONFIG_PATH" variable is not set. Defaulting to a blank string.
WARN[0000] The "MATTERMOST_DATA_PATH" variable is not set. Defaulting to a blank string.
WARN[0000] The "MATTERMOST_LOGS_PATH" variable is not set. Defaulting to a blank string.
WARN[0000] The "MATTERMOST_PLUGINS_PATH" variable is not set. Defaulting to a blank string.
WARN[0000] The "MATTERMOST_CLIENT_PLUGINS_PATH" variable is not set. Defaulting to a blank string.
WARN[0000] The "MATTERMOST_BLEVE_INDEXES_PATH" variable is not set. Defaulting to a blank string.
WARN[0000] The "MATTERMOST_CONTAINER_READONLY" variable is not set. Defaulting to a blank string.
error while interpolating services.mattermost.read_only: failed to cast to expected type: invalid boolean:

Anbei findet ihr mein .env-File und das docker-compose-yml.

Code:
# Domain of service
DOMAIN=my.sub.domain.de

# Container settings
## Timezone inside the containers. The value needs to be in the form 'Europe/Berlin'.
## A list of these tz database names can be looked up at Wikipedia
## https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

TZ=Europe/Berlin

RESTART_POLICY=unless-stopped

# Postgres settings
## Documentation for this image and available settings can be found on hub.docker.com
## https://hub.docker.com/_/postgres
## Please keep in mind this will create a superuser and it's recommended to use a less privileged
## user to connect to the database.
## A guide on how to change the database user to a nonsuperuser can be found in docs/creation-of-nonsuperuser.md

POSTGRES_IMAGE_TAG=13-alpine
POSTGRES_DATA_PATH=./volumes/db/var/lib/postgresql/data
POSTGRES_USER=username
POSTGRES_PASSWORD=password
POSTGRES_DB=mattermost

## Exposed ports to the host. Inside the container 80 and 443 will be used
HTTPS_PORT=443
HTTP_PORT=80

# Mattermost settings
## Inside the container the uid and gid is 2000. The folder owner can be set with
## `sudo chown -R 2000:2000 ./volumes/app/mattermost`.

MATTERMOST_CONFIG_PATH=./volumes/app/mattermost/config
MATTERMOST_DATA_PATH=./volumes/app/mattermost/data
MATTERMOST_LOGS_PATH=./volumes/app/mattermost/logs
MATTERMOST_PLUGINS_PATH=./volumes/app/mattermost/plugins
MATTERMOST_CLIENT_PLUGINS_PATH=./volumes/app/mattermost/client/plugins
MATTERMOST_BLEVE_INDEXES_PATH=./volumes/app/mattermost/bleve-indexes

## Bleve index (inside the container)
MM_BLEVESETTINGS_INDEXDIR=/mattermost/bleve-indexes

## This will be 'mattermost-enterprise-edition' or 'mattermost-team-edition' based on the version of Mattermost you're installing.
MATTERMOST_IMAGE=mattermost-team-edition
MATTERMOST_IMAGE_TAG=7.1

## Make Mattermost container readonly. This interferes with the regeneration of root.html inside the container. Only use
## it if you know what you're doing.
## See https://github.com/mattermost/docker/issues/18
MATTERMOST_CONTAINER_READONLY=false

## The app port is only relevant for using Mattermost without the nginx container as reverse proxy. This is not meant
## to be used with the internal HTTP server exposed but rather in case one wants to host several services on one host
## or for using it behind another existing reverse proxy.
APP_PORT=8065

## Configuration settings for Mattermost. Documentation on the variables and the settings itself can be found at
## https://docs.mattermost.com/administration/config-settings.html
## Keep in mind that variables set here will take precedence over the same setting in config.json. This includes
## the system console as well and settings set with env variables will be greyed out.
## Below one can find necessary settings to spin up the Mattermost container
MM_SQLSETTINGS_DRIVERNAME=postgres
MM_SQLSETTINGS_DATASOURCE=postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}?sslmode=disable&connect_timeout=10
## Example settings (any additional setting added here also needs to be introduced in the docker-compose.yml)
MM_SERVICESETTINGS_SITEURL=https://${DOMAIN}

Code:
version: "3.8"

services:
  postgres:
    image: postgres:${POSTGRES_IMAGE_TAG}
    restart: ${RESTART_POLICY}
    security_opt:
      - no-new-privileges:true
    pids_limit: 100
    read_only: true
    tmpfs:
      - /tmp
      - /var/run/postgresql
    volumes:
      - ${POSTGRES_DATA_PATH}:/var/lib/postgresql/data
    environment:
      # timezone inside container
      - TZ

      # necessary Postgres options/variables
      - POSTGRES_USER
      - POSTGRES_PASSWORD
      - POSTGRES_DB
    labels:
      - traefik.enable="false"
    networks:
      - default

  mattermost:
    depends_on:
      - postgres
    image: mattermost/${MATTERMOST_IMAGE}:${MATTERMOST_IMAGE_TAG}
    restart: ${RESTART_POLICY}
    security_opt:
      - no-new-privileges:true
    pids_limit: 200
    read_only: ${MATTERMOST_CONTAINER_READONLY}
    tmpfs:
      - /tmp
    volumes:
      - ${MATTERMOST_CONFIG_PATH}:/mattermost/config:rw
      - ${MATTERMOST_DATA_PATH}:/mattermost/data:rw
      - ${MATTERMOST_LOGS_PATH}:/mattermost/logs:rw
      - ${MATTERMOST_PLUGINS_PATH}:/mattermost/plugins:rw
      - ${MATTERMOST_CLIENT_PLUGINS_PATH}:/mattermost/client/plugins:rw
      - ${MATTERMOST_BLEVE_INDEXES_PATH}:/mattermost/bleve-indexes:rw
    environment:
      # timezone inside container
      - TZ

      # necessary Mattermost options/variables (see env.example)
      - MM_SQLSETTINGS_DRIVERNAME
      - MM_SQLSETTINGS_DATASOURCE

      # necessary for bleve
      - MM_BLEVESETTINGS_INDEXDIR

      # additional settings
      - MM_SERVICESETTINGS_SITEURL
    labels:
      traefik.enable: "true"
      traefik.http.routers.mattermost.entrypoints: "http"
      traefik.http.routers.mattermost.rule: "Host(`my.sub.domain.de`)"
      traefik.http.middlewares.mattermost-https-redirect.redirectscheme.scheme: "https"
      traefik.http.routers.mattermost.middlewares: "mattermost-https-redirect"
      traefik.http.routers.mattermost-secure.entrypoints: "https"
      traefik.http.routers.mattermost-secure.rule: "Host(`my.sub.domain.de`)"
      traefik.http.routers.mattermost-secure.tls: "true"
      traefik.http.routers.mattermost-secure.tls.certresolver: "http"
      traefik.http.routers.mattermost-secure.service: "mattermost"
      traefik.http.services.mattermost.loadbalancer.server.port: "80"
      traefik.docker.network: "proxy"
    networks:
      - default
      - proxy

P. S.: Merkwürdig ist auch, dass sich die Fehlermeldung verkürzt, wenn der docker compose Befehl zwei Mal hintereinander ausgeführt wird:


Code:
WARN[0000] The "RESTART_POLICY" variable is not set. Defaulting to a blank string.
WARN[0000] The "POSTGRES_DATA_PATH" variable is not set. Defaulting to a blank string.
WARN[0000] The "POSTGRES_IMAGE_TAG" variable is not set. Defaulting to a blank string.
WARN[0000] The "MATTERMOST_IMAGE" variable is not set. Defaulting to a blank string.
WARN[0000] The "MATTERMOST_IMAGE_TAG" variable is not set. Defaulting to a blank string.
WARN[0000] The "MATTERMOST_CONTAINER_READONLY" variable is not set. Defaulting to a blank string.
error while interpolating services.mattermost.read_only: failed to cast to expected type: invalid boolean:
 
Sorry wenn ich Nachfrage, habe selbst keinen mattermost am laufen, hab mir aber die Mühe gemacht und die doku mal überflogen...

1. Ist es gewollt das deine beiden files einmal
read only=true
Code:
read_only: ${MATTERMOST_CONTAINER_READONLY}
und
read only=false
Code:
 MATTERMOST_CONTAINER_READONLY=false
sind.
Dies konnte ich auf die schnelle nicht herausfinden, eventuell gehört das so, da ich es nirgends gesehen habe (oder überflogen)

2. Passiert das ganze beim starten oder schon build
docker-compose build

3. reverse proxy mit Zertifikat für traefik ist eingerichtet und erreichbar
 
Moin,
danke für deine Antwort.

1. Ja, das ist Absicht. Im Environment wird die Flag einmal auf false gesetzt und im compose-file die Flag abgerufen und somit der Wert false gesetzt. Musste da aber auch selbst nochmal kurz draufschauen :)

2. Das passiert beim sechsten Schritt der Anleitung, sobald der Befehl
Code:
sudo docker-compose -f docker-compose.yml -f docker-compose.without-nginx.yml up -d
ausgeführt wird.

3. Ist eingerichtet und wird von anderen Services (Bookstack, Nextcloud u. a.) erfolgreich erreicht.
 
Wo ich grade das "docker-compose" lese... darüber bin ich nämlich letztens auch noch gestolpert... müsste es mittlerweile nicht eher "docker compose" (v2, nachzuinstallierendes Paket "docker-compose-plugin") anstatt "docker-compose" (v1) heissen? Hatte da auch so ganz komische Effekte bzgl. Variablen und bin nicht schlau daraus geworden, mit v2 lief es dann sofort anstandslos. Hier noch der Link zum GitRepo https://github.com/docker/compose/tree/v2

Das "Problem" hatte ich übrigens auch mit Mattermost (bzgl. Domain) ;)
 
Wo ich grade das "docker-compose" lese... darüber bin ich nämlich letztens auch noch gestolpert... müsste es mittlerweile nicht eher "docker compose" (v2, nachzuinstallierendes Paket "docker-compose-plugin") anstatt "docker-compose" (v1) heissen? Hatte da auch so ganz komische Effekte bzgl. Variablen und bin nicht schlau daraus geworden, mit v2 lief es dann sofort anstandslos. Hier noch der Link zum GitRepo https://github.com/docker/compose/tree/v2

Also, verstehe ich dich richtig, ich sollte das neue Paket installieren und es mit diesem nochmal probieren?
Ich hatte die Installation schon mal am Laufen, auch ohne das neue Paket. Aber bisher habe ich keine bessere Idee 🙃

Das "Problem" hatte ich übrigens auch mit Mattermost (bzgl. Domain) ;)

Ich verstehe leider nicht ganz was du meinst, möchtest du nochmal darauf eingehen bitte?
 
Weiss ja nicht, wie lange es mit Deiner letzten Mattermost-Installation her ist, aber ich hab das Ding mit v1 nicht zum laufen bekommen (aufgrund von Fehlern mit Variablen, obwohl ich der Meinung war, alles korrekt angegeben zu haben). Da die Fehlermeldungen bei Dir auch bzgl. der Variablen meckern, kam in mir halt der leise Verdacht hoch, dass es bei Dir evtl. ganz ähnlich gelagert sein könnte.
Also, verstehe ich dich richtig, ich sollte das neue Paket installieren und es mit diesem nochmal probieren?
Korrekt, wobei ich natürlich nicht weiss, ob das jetzt zwingend zum Erfolg führt, ist eben "nur so eine Idee".

Ich verstehe leider nicht ganz was du meinst, möchtest du nochmal darauf eingehen bitte?
Bei mir war es so, dass der die Sache mit der Domainangabe auf Teufel komm raus nicht nutzen wollte bzw. deswegen auch direkt der ganze Container nicht gestartet ist. Immer nur Fehlermeldungen am laufenden Band (von wegen Variable ist nicht gesetzt, war aber gesetzt). Mit v2 war dieses Problem auf ominöse Weise dann einfach verschwunden. Ich muss dazu aber auch sagen, dass ich mal garnicht so der Docker-Typ bin und es ging mir eigentlich nur um eine einfaches und schnelles Test-Deployment... Nach dem ganzen Terz mit v1, lief es dann mit v2 einfach sofort. Ich würde es einfach mal ausprobieren :)
 
Ich werde das auf jeden Fall mal angehen, muss mich allerdings mit dem anderen SysAdmin absprechen und dann zeitnah berichten! :)
Der Fix klingt auf jeden Fall sinnig.
Danke nochmals, dass Du das nochmal ausführlicher beschrieben hast!
 
Was heisst hier "ausführlich", ist schon alles etwas länger her und ich bin leider nicht so der Docker-Typ, von daher... vllt einfach mal in einer VM oder so testen ☺️
 
Ist die Kernfrage hier nicht eigentlich "Warum werden die Variablen aus der .env Datei nicht sauber übernommen?"

Für das Deployment sollt es unerheblich sein, ob ein aktuelles(!) v1 oder v2 verwendet wird. v2 hat den Vorteil, dass dort immer die aktuellste Schema-Version gilt, weil dort die Version ignoriert wird UND jetzt viele Swarm-Stack-spezifischen Konstrukte auch für Compose Projekt Deployments verwendet werden können.

Sonst führe doch mal docker compose config (mit oder ohne Bindestrich zwischen docker und compose) um dir die gerenderte Konfiguration anzeigen zu lassen.

Update: ist ja schon durch die Verwendung von v2 behoben. Ist trotzdem merkwürdig, dass es mit v1 nicht lief, außer v1 hatte in der genutzten Version einen Bug.

Mit folgender docker-compose Version (v1) werden die Werte aus .env korrekt in das compose file übernommen:
Code:
$ docker-compose version
docker-compose version 1.28.5, build 1bbbad71
docker-py version: 4.4.4
CPython version: 3.7.10
OpenSSL version: OpenSSL 1.1.0l  10 Sep 2019

Update 2: Du kannst dir -f docker-compose.without-nginx.yml sparen, da dank Traefik kein zusätzliches Portmapping vom Container zum Host notwendig ist.
 
Zuletzt bearbeitet:
Ist die Kernfrage hier nicht eigentlich "Warum werden die Variablen aus der .env Datei nicht sauber übernommen?"

Für das Deployment sollt es unerheblich sein, ob ein aktuelles(!) v1 oder v2 verwendet wird. v2 hat den Vorteil, dass dort immer die aktuellste Schema-Version gilt, weil dort die Version ignoriert wird UND jetzt viele Swarm-Stack-spezifischen Konstrukte auch für Compose Projekt Deployments verwendet werden können.

Sonst führe doch mal docker compose config (mit oder ohne Bindestrich zwischen docker und compose) um dir die gerenderte Konfiguration anzeigen zu lassen.

Update: ist ja schon durch die Verwendung von v2 behoben. Ist trotzdem merkwürdig, dass es mit v1 nicht lief, außer v1 hatte in der genutzten Version einen Bug.

Mit folgender docker-compose Version (v1) werden die Werte aus .env korrekt in das compose file übernommen:
Code:
$ docker-compose version
docker-compose version 1.28.5, build 1bbbad71
docker-py version: 4.4.4
CPython version: 3.7.10
OpenSSL version: OpenSSL 1.1.0l  10 Sep 2019

Update 2: Du kannst dir -f docker-compose.without-nginx.yml sparen, da dank Traefik kein zusätzliches Portmapping vom Container zum Host notwendig ist.

Danke für deinen Beitrag.
Ja, das ist die Kernfrage und ich verstehe es nach wie vor nicht.
Habe auf v2.11.2 geupdated und bekomme die gleiche Fehlermeldung. Werde nochmal probieren mit v1.28.5 zu einem Ergebnis zu kommen.

Edit: Ich scheitere daran v1.28.5 zu installieren.
 
Zuletzt bearbeitet:
Ich hab die Version nur hingeschrieben, um zeigen, dass es kein v1 oder v2 Problem ist. Solange die Version halbwegs aktuell ist, sollte es gehen.

Gibt es eine Fehlermeldung, wenn docker compose -f docker-compose.yml config ausgeführt wird?

Anmerkung: in deinem Compose File Auszug oben ist der "networks:" Block zum Einbinden vom externen proxyNetzwerk zum Beispiel nicht enthalten. Interessanterweise juckt es config bei v1 nicht, aber bei v2 wirft es den Fehler, dass es das Netzwerk nicht kennen würde. Deployen würden es beide Versionen so natürlich nicht.
 
Gibt es eine Fehlermeldung, wenn docker compose -f docker-compose.yml config ausgeführt wird?
Code:
WARN[0000] The "RESTART_POLICY" variable is not set. Defaulting to a blank string.
WARN[0000] The "POSTGRES_DATA_PATH" variable is not set. Defaulting to a blank string.
WARN[0000] The "POSTGRES_IMAGE_TAG" variable is not set. Defaulting to a blank string.
WARN[0000] The "RESTART_POLICY" variable is not set. Defaulting to a blank string.
WARN[0000] The "MATTERMOST_CONTAINER_READONLY" variable is not set. Defaulting to a blank string.
error while interpolating services.mattermost.read_only: failed to cast to expected type: invalid boolean:
Diese Fehlermeldung bekomme ich.

Anmerkung: in deinem Compose File Auszug oben ist der "networks:" Block zum Einbinden vom externen proxyNetzwerk zum Beispiel nicht enthalten. Interessanterweise juckt es config bei v1 nicht, aber bei v2 wirft es den Fehler, dass es das Netzwerk nicht kennen würde. Deployen würden es beide Versionen so natürlich nicht.

Meinst du für die postgres-Datenbank? Ist da nicht extra das proxy-Netzwerk rausgehalten, damit man über den Proxy nicht auf die Datenbank zugreifen kann?
 
Irgendwie kommt es mir so vor, als wenn etwas mit Deiner .env Datei nicht stimmt. Falsches Encoding? Windows File-Endings?

Ich habe original den Inhalt Deiner beiden Dateien genommen und entsprechend in eine .env und eine compose.yml (v2 bevorzugt den Namen) gegossen, dann den networks Block zwecks (gleiche ebene wie "services:", nicht die Nutzung des Netzwerkes unterhalb eines Services) Deklaration der verwendbaren Netzwerke hinzugefügt und dann war das compose file valide und die Ersetzung hat sauber funktioniert.
 
Irgendwie kommt es mir so vor, als wenn etwas mit Deiner .env Datei nicht stimmt. Falsches Encoding? Windows File-Endings?

Ich habe original den Inhalt Deiner beiden Dateien genommen und entsprechend in eine .env und eine compose.yml (v2 bevorzugt den Namen) gegossen, dann den networks Block zwecks (gleiche ebene wie "services:", nicht die Nutzung des Netzwerkes unterhalb eines Services) Deklaration der verwendbaren Netzwerke hinzugefügt und dann war das compose file valide und die Ersetzung hat sauber funktioniert.
Liegt der Fehler eventuell darin, dass ich die Datei
Code:
mattermost.env
genannt habe?
Lag es. Oh man. Eine Erklärung bitte q.q
 
Zuletzt bearbeitet:
Bekomme bei unter my.sub.domain.de leider eine "Bad Gateway"-Meldung.
Habe das Gefühl, das Datenbank und Service nicht miteinander reden.

Timestamp vom Mattermost-Container, der nach dem Aufruf der URL erzeugt wird:
Code:
{"timestamp":"2022-10-18 14:46:50.209 +02:00","level":"debug","msg":"Received HTTP request","caller":"web/handlers.go:156","method":"GET","url":"/api/v4/system/ping","request_id":"91smwfy3nt8f3xugsgkxi6gdme","status_code":"200"}

Logs vom Postgres-Container:
Code:
PostgreSQL Database directory appears to contain a database; Skipping initialization

2022-10-18 14:46:19.348 CEST [1] LOG:  starting PostgreSQL 13.8 on x86_64-pc-linux-musl, compiled by gcc (Alpine 11.2.1_git20220219) 11.2.1 20220219, 64-bit
2022-10-18 14:46:19.348 CEST [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2022-10-18 14:46:19.348 CEST [1] LOG:  listening on IPv6 address "::", port 5432
2022-10-18 14:46:19.349 CEST [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2022-10-18 14:46:19.353 CEST [22] LOG:  database system was shut down at 2022-10-18 14:46:10 CEST
2022-10-18 14:46:19.357 CEST [1] LOG:  database system is ready to accept connections
 
Zuletzt bearbeitet:
Liegt der Fehler eventuell darin, dass ich die Datei
Code:
mattermost.env
genannt habe?
Entweder verwendest Du die Standard-Namen für .env und docker-compose.yml oder Du musst es Docker Compose schon in irgendeiner Fom mitteilen. Entweder als cli Argument --env-file mattermost.env oder als env_file: ./mattermost.env in den Service-Definitionen.

Da Du es weder als Argument, noch als Teil der compose file Konfiguration angibst, ist die Antwort: jepp!
 
Danke nochmals, wieder etwas gelernt :)
Ein letzter Punkt ist, dass traefik es jetzt nicht schafft von my.sub.domain auf 101.10.11.12:8065 (Beispiel-IP) weiterzuleiten. Bei Abruf der IP komme ich aber auf den Dienst.
 

Zurzeit aktive Besucher

Keine Mitglieder online.

Neueste Beiträge

Letzte Anleitungen

Statistik des Forums

Themen
5.390
Beiträge
53.396
Mitglieder
5.182
Neuestes Mitglied
mwecom
Zurück
Oben