Difference between relaunch and recreate?

[Kiigass]

Hi,

I just read the complete documentation. I have to admit I am fairly new to docker. Nevertheless, I think this is more a question for clarification of the documentation, rather than a docker question:

1. docker-mailserver/README.md

   Line 106 in a84b8a1

   **Use `docker-compose up / down`, not `docker-compose start / stop`**. Otherwise, the container is not properly destroyed and you may experience problems during startup because of inconsistent state.

2. In the documentation it says "Simply remove the DKIM key by recreating (not just relaunching) the docker-mailserver container."

3. And finally also in the documentation, Step 9 it says "Once everything is working well, stop the container with ctrl+c and start it again as a daemon: docker-compose up -d."

This question is triggered by the (as it seems to me) contradiction between those three points: As far as I understand, I would loose the DKIM keys, if I do docker-compose up / down, wouldn't I?

I am a little bit confused and would like to get a mapping respectively confirmation, that my mapping is correct:
recreate = docker-compose up/ down
relaunch = docker-compose start/ stop
restart = ?

[polarathene]

As far as I understand, I would loose the DKIM keys, if I do docker-compose up / down, wouldn't I?

You would not if you persist the storage that the command is writing the keys to. This is an opendkim folder that exists in the container at /tmp/docker-mailserver, here's the relevant path from the DKIM command the docs are referencing:

docker-mailserver/target/bin/open-dkim

Line 131 in a84b8a1

mkdir -p "/tmp/docker-mailserver/opendkim/keys/${DKIM_DOMAIN}"

The docs should advise you to provide a volume mount of a local folder or data volume to the internal container directory /tmp/docker-mailserver. Without that, your data will not persist once the container is removed.

---

I think this is more a question for clarification of the documentation, rather than a docker question
This question is triggered by the (as it seems to me) contradiction between those three points

In this case, it's due to this project surviving by volunteer work. Maintainers come and go, as does the contributions from users over the years. Some contributors will phrase things differently and it can be difficult to keep track of it all unfortunately to try be consistent (which I've tried to improve).

With docker-compose up (-d is optional), your container will start for the first time.

• If you did not use -d, then logs will print to the terminal and you can use ctrl+c to exit. This would be like docker-compose stop, so the container state internally is preserved.
• When you start the container again with docker-compose start or docker-compose up, the container is what we've been calling a "restart", it is kind of like resuming a laptop from a suspended/paused state, and the data that was in the container before it "slept" is restored.
• Unfortunately that is a bit fragile for this project as our startup scripts will run again, and there is a lot going on there which volunteers have often contributed with the assumption of a known internal state (eg, the changes we make to internal files that you do not persist, are assumed to always be what the Docker image originally had, not any changes since then from the container). This can cause subtle bugs sometimes that may be difficult for us to reproduce.
• By removing/destroying the container with docker-compose down before starting it again with docker-compose up, you ensure that the container is started fresh. It's similar to the first time you run a container for the image, the internal container data will be what was provided from the image data, our startup scripts expect to work with that and everything should work fine.
• As mentioned earlier, any user data is persisted with volume mounts, keeping important data you want to keep stored outside of the container instead (the container itself isn't aware of any difference internally).

That concern should not apply to any data at these locations:

docker-mailserver/docker-compose.yml

Lines 19 to 24 in a84b8a1

	volumes:
	- ./docker-data/dms/mail-data/:/var/mail/
	- ./docker-data/dms/mail-state/:/var/mail-state/
	- ./docker-data/dms/mail-logs/:/var/log/mail/
	- ./docker-data/dms/config/:/tmp/docker-mailserver/
	- /etc/localtime:/etc/localtime:ro

Finally, if you do not want to do docker-compose down && docker-compose up, you could also use docker-compose up --force-recreate which will ensure that the container is a new one each time you use that option (it should be equivalent bringing the container down and then up).

---

Summary

• To persist data like DKIM keys, make sure you use volume mounts which will keep the data on your local filesystem instead of in a disposable container.
• Use docker-compose up --force-recreate instead of docker-compose up (and avoid start/stop/restart commands) and you shouldn't run into any issues with this Docker project that the other commands can cause.

[Kiigass]

Thank you very much! This answers all my questions in full!