JoshData
commented
4 years ago Dockerizing this project has been tried many times and honestly I just don't think Docker is an appropriate containerization method for this project. Our goal is to create an idempotent system configuration script that targets a single known baseline (a Ubuntu 18.04 server). If you change that baseline (Ubuntu in Docker just doesn't work like an Ubuntu server, it's a different baseline), you're working in a different world than we are.
That said, I am happy to accept simple PRs that make this project work in other environments without any impact on our target environment and with zero impact on the maintainability of this project.
ducttapecoder-vt
melato
hughsw
Hello,
Summary
I'm doing the apparently very unpopular thing of trying to get MIAB to work in an ubuntu:bionic docker container.
Background
We have some requirements for an email server that have led me to this path:
As a result:
That leaves me with:
Test procedures (so far)
I found this thread that got me started: https://discourse.mailinabox.email/t/mail-in-a-box-in-docker/4588 I'm using a slight modification:
docker run -d -t -h mail.domain.com -e DISABLE_FIREWALL=1 -e PRIMARY_HOSTNAME=mail.domain.com --name mailinabox -p 25:25/tcp -p 53:53/tcp -p 53:53/udp -p 9080:80/tcp -p 9443:443/tcp -p 587:587/tcp -p 993:993/tcp -p 995:995/tcp -p 4190:4190/tcp ubuntu:bionicdocker exec -it mailinabox bashapt-get updateapt-get install sudo curl lsb-release dialog locales net-tools iproute2 systemd vimcurl -s https://mailinabox.email/setup.sh | sudo -E bash -xvim /root/mailinabox/setup/system.shcomment out the two hostname lines comment outrm /etc/resolv.confand replace withcat /dev/null > /etc/resolv.confvim /root/mailinabox/setup/setup.shAddset -xto the top/root/mailinabox/setup/setup.sh | sudo -E bash -xThe issues with MIAB
1. Setting hostname incompatibility with containers Outlook: Major, mid-stream code modifications required https://github.com/mail-in-a-box/mailinabox/blob/385340da46862b83d87c399474152961771d1832/setup/system.sh#L15
The above code will set the hostname even if the hostname is already correct. Unfortunately all hostname set commands fail in a docker container and must be set at runtime with
-h. Can this please be changed to check the hostname first for equivalence and set only if it's not already correct please?2. Environment variables declared after container start not honored? Outlook: Minor, solved by setting env correctly at run The below error occurs if DISABLE_FIREWALL (
DISABLE_FIREWALL=1) is not set before starting the container/script. Is there a cache for this setting? I had to clear the container and restart it with-e DISABLE_FIREWALL=1to get it to work correctly.3. Cannot remove resolv.conf for bind setup Outlook: Critical, possible design incompatibility https://github.com/mail-in-a-box/mailinabox/blob/385340da46862b83d87c399474152961771d1832/setup/system.sh#L334
This yields:
rm: cannot remove '/etc/resolv.conf': Device or resource busyI think this is another case of a 'protected resource' by Docker as the DNS configuration is set at the docker engine level. It's possible to edit the resolv.conf but removing the file is forbidden. A
cat /dev/null > /etc/resolv.confwould work better in this case. On the other hand, a relaunch of this container may result in that configuration being overwritten by the docker engine.Continuing down we get:
The nameserver at 127.0.0.1 doesn't seem to actually provide resolution. Has it been told to use the upstream docker nameserver and would that defeat the purpose? I added the pre-existing docker nameserver (the host) as a second nameserver in resolv.conf and this error went away.
4. Pollinate and bash debugging Outlook: Minor If you engage start.sh in bash debug mode, the script unexpectedly terminates at
pollinate -q -r. I don't know enough to know why or start debugging that issue. All I know is if I comment that line out, it continues. Additionally I found this comment from pollinate devs which suggests pollinate isn't compatible/recommended with containers?https://github.com/dustinkirkland/pollinate/blob/98cc240470ec3fa495f1920179480808ae078faa/debian/changelog#L142
5. Armageddon. Linux/Docker philosophical question. https://github.com/mail-in-a-box/mailinabox/blob/385340da46862b83d87c399474152961771d1832/setup/system.sh#L341 yields
System has not been booted with systemd as init system (PID 1). Can't operate.Oh no. Here we go quickly past my barely knee-deep knowledge of linux into the depths of insanity. I took a quick google stab at this and it seems this has been a debate, correction many debates, for a while now. https://www.zdnet.com/article/after-linux-civil-war-ubuntu-to-adopt-systemd/ https://medium.com/@nagarwal/an-init-system-inside-the-docker-container-3821ee233f4b
Long story short, Docker doesn't use an init like systemd, upstart, or any other. The singular process that starts the container is the init, bash in my current case. Docker isn't a VM after all, it shouldn't have a full startup stack, or something. I've seen other solutions solve this by using a startup script that does the necessary initialization and health checking and leveraging that as the primary process. I'm thinking this goes beyond what I have time/energy to do here.
The Verdict
I would love to see MIAB take a stab at a more enterprise friendly implementation (RHEL/CentOS compatible, Docker, upgradable installations without reinstallation, adding to an existing system without wiping, etc.) but I am going to guess it's the same story
or the GitHub classic
If anyone has the time or energy to take up this torch, I would love see it. In the meantime maybe some of these things above can be considered in the design. Baby steps, amirite?