I found out that there were the following changes on the images:

Ownership

The logs throwed errors about not beinng able to write on log files because nearly the entire home directory was owned by an user called bin:

root@8ac38faa94f1:/var/atlassian/application-data/confluence# ls -ltotal 108drwx------  2 bin        bin         4096 Aug 19 00:03 analytics-logsdrwx------  3 bin        bin         4096 Jun 15  2017 attachmentsdrwx------  2 bin        bin        24576 Jan 12  2019 backups[...]

This could be fixed by executing a chown:

docker exec -it confluence bashchown  confluence:confluence -R /var/atlassian/application-data/confluence

Moutings inside mount

My docker-compose.yml mounts a volume to /var/atlassian/application-data/confluence and inside those volume, the confluence.cfg.xml file was mounted from current directory. This approach is a bit older and should seperate the user data in the volume from configuration files like docker-compose.yml and also the application itself as confluence.cfg.xml.

Seems not properly working any more on using Docker 17.05 and Docker-Compose 1.8.0 (at least in combination with Confluence), so I simply removed that second mount and placed the configuration file inside the volume.

Atlassian creates config files now dynamically

It was noticeable that my mounted configuration files like confluence.cfg.xml and server.xml were overwritten by Atlassians container. Their source code shows that they now use Jina2, a common Python template engine used in e.g. Ansible. A python script parse those files on startup and create Confluences configuration files, without properly checking on all of those files if they already exists.

Mounting them as read only caused the app to crash because this is also not handled in their Python script. By analyzing their templates, I learned that they replaced nearly every config item by environment variables. Not a bad approach, so I specified my server.xml parameters by env variables instead of mouting the entire file.

In my case, Confluence is behind a Traefik reverse proxy and it's required to tell Confluence it's final application url for end users:

environment:- ATL_proxyName=confluence.my-domain.com- ATL_proxyPort=443- ATL_tomcat_scheme=https

Final working docker-compose.yml

By applying all modifications above, accessing the existing installation works again using the following docker-compose.yml file:

version: "2"volumes:confluence-home:services:confluence:    container_name: confluence    image: atlassian/confluence-server:6.15.1    #restart: always    mem_limit: 6g    volumes:    - confluence-home:/var/atlassian/application-data/confluence    - ./mysql-connector-java-5.1.42-bin.jar:/opt/atlassian/confluence/lib/mysql-connector-java-5.1.42-bin.jar    networks:    - traefik    environment:    - "TZ=Europe/Berlin"    - JVM_MINIMUM_MEMORY=4096m    - JVM_MAXIMUM_MEMORY=4096m    - ATL_proxyName=confluence.my-domain.com    - ATL_proxyPort=443    - ATL_tomcat_scheme=https    labels:    - "traefik.port=8090"    - "traefik.backend=confluence"    - "traefik.frontend.rule=Host:confluence.my-domain.com"networks:    traefik:    external: true