Oh it is so obvious

Docker is really the new way for me to deploy applications. And this really is an easy way. You look for a docker-compose file, tweak the standard stuff like volumes, IP address and reverse proxy settings and presto! you’re done.

Recently though some of my docker containers started failing… even ones that have been running for quite some time. It took a while for me to figure out what caused this behaviour, but when I found out, the title of the post kind of coveres the sentiment.

Let’s say for example I want to have a DMARC reporter and Monica running on my portainer instance. I would get both docker-compose files.

Monica

version: "3.9"

services:
  app:
    image: monica
    depends_on:
      - db
    ports:
      - 8080:80
    environment:
      - APP_KEY= # Generate with `echo -n 'base64:'; openssl rand -base64 32`
      - DB_HOST=db
      - DB_USERNAME=monica
      - DB_PASSWORD=secret
    volumes:
      - data:/var/www/html/storage
    restart: always

  db:
    image: mariadb:11
    environment:
      - MYSQL_RANDOM_ROOT_PASSWORD=true
      - MYSQL_DATABASE=monica
      - MYSQL_USER=monica
      - MYSQL_PASSWORD=secret
    volumes:
      - mysql:/var/lib/mysql
    restart: always

volumes:
  data:
    name: data
  mysql:
    name: mysql

DMARC reporter

version: "3.6"

services:
  dmarc-report:
    image: "gutmensch/dmarc-report:latest"
    hostname: dmarc-report
    container_name: dmarc-report
    depends_on:
      - db
    ports:
      - "80:80"
    environment:
      - "REPORT_DB_HOST=db"
      - "REPORT_DB_PORT=3306"
      - "REPORT_DB_NAME=dmarc_report"
      - "REPORT_DB_USER=dmarc_report"
      - "REPORT_DB_PASS=dbpassword"
      - "PARSER_IMAP_SERVER=mail"
      - "PARSER_IMAP_PORT=143"
      - "PARSER_IMAP_USER=foobar@example.com"
      - "PARSER_IMAP_PASS=foobar"
      - "PARSER_IMAP_READ_FOLDER=Inbox"
      - "PARSER_IMAP_MOVE_FOLDER=processed"
      - "PARSER_IMAP_MOVE_FOLDER_ERR=error"

  db:
    image: mariadb:10
    command: --skip-innodb-read-only-compressed
    environment:
      - "MYSQL_ROOT_PASSWORD=dbrootpassword"
      - "MYSQL_DATABASE=dmarc_report"
      - "MYSQL_USER=dmarc_report"
      - "MYSQL_PASSWORD=dbpassword"
    volumes:
      - ./dmarc-report-db:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-uroot", "-pdbrootpassword"]
      interval: 10s
      timeout: 10s
      retries: 5

Appearantly just editing the volumes, IP address and (not in this case) reverse proxy settings isn’t enough. It turns out that and it’s quite logical that the name of the instance has to be unique although it isn’t enforced. So if you have 2 containers in different docker-compose files both named db:. You are suddenly start to have failing containers. Like I said it is plainly obvious, but since it’s not enforced it could be something you overlook when troubleshooting.