Any official docker installation?

[hiqsociety]

Any official docker installation?

[DerBunteBall]

Check the docker branch of the repository. Last commit was in 2015. I think there is no official working docker version.

[JoshData]

Last anyone tried, Docker does not provide an environment close enough to Ubuntu 18.04 for this project to be installable within a container.

[jcgoette]

Not sure how long, but it looks like there is an official 18.04 image available.

I don't mind taking a whack at this if you are still looking to implement.

#1496, #1375, #843, #112, #16

[DerBunteBall]

Hi

The big problem isn't the base.

Docker thinks a bit different.

A docker approach would take the components and put them into containers. So MIAB wouldn't be installed. MIAB would be the stack which gets it's needed data. So there are containers for Postfix, Dovecot, nsd and so on. The setup variables like IP, Domain and so on are managed by environment variables in the containers. The managment panel need to be changed in a dockerized variant. E.g. adding a new domain: the managment panel (in one container) would need to be able to change the config of nsd (in another container) and need to be able to restart nsd. This would be done by volume sharing and Docker Control Access.

It's creatable but not exactly how it is actually. Big changes espacially in the managment core need to be done.

Best Regards

[nomandera]

In some ways docker is the perfect fit for this project, it is just that to date the efforts to implement it have aimed so high it was all or nothing... which invariable meant nothing.

@DerBunteBall concept is the right one. The way to approach this is not to "port MIAB to docker" but to port one small component. Prove it is interchangeable. Move onto the next one, rinse and repeat.

[S0PEX]

Is this still interesting?
Currently thinking of migrating from mailcow to this and thinking about dockerizing this application as a mono image using supervisord.

If there is enough interest I would prepare an image and PR the required code.

[JoshData]

I don't have the time to maintain a more complicated project that involves containers. It is difficult enough as it is to get the components configured correctly. So it's not something I would merge.

[hughsw]

I would argue that containerizing MIAB in a systemd environment will actually reduce the maintenance friction that @JoshData refers to.

I have a package that builds and runs a new MIAB installation in a rootless container using podman. I only had to make two un-intrusive one-line changes to MIAB's setup code. It is refreshing to have complete control over the Ubuntu configuration, unlike when installing on one of the varied Ubuntus one gets on different cloud providers or the (unsupported) situations where MIAB is shoehorned into older or non-exclusive Ubuntu environments. That is, containerization eliminates a whole class of at-present-uncontrollable environmental issues.

To have a supportable containerized MIAB package there are a number of interesting architectural issues to address, particularly where to draw the line between the images that the MIAB project builds and releases and the end-user-controlled container that the actual deployment uses, and whether the container itself is ephemeral or not...

And, as with most complex systems, there are challenges in:

• migrating an existing MIAB installation into the containerized environment
• handling MIAB's ongoing migrations
• supporting development work for maintainers

AFAICT none of these has any show-stopper qualities, and developer support should qualitatively improve, but I haven't done any solid POC work on this yet.

Obviously, a number of other issues would need to be sorted out in discussions with the seasoned maintainers for such an effort to gain traction and the blessing of the powers that be.

The bottom line is that it's easy to run MIAB in a systemd-friendly container runtime like podman, and sorting out a few, long-term support issues are the only real hurdles to containerizing the MIAB system.

[jeff-h]

If I'm understanding @hughsw correctly, I think you're suggesting a single container to run the entirety of MIAB. Whilst that's not "docker best-practice", I think it would be an awesome approach for MIAB, as an alternative install method.

Attempting to split it into separate containers would effectively make this an entirely new project, not MIAB any more.

By putting MIAB into one single container, I would hope the changes between a docker version and the current bare-metal version would hopefully be extremely minimal?

[bilogic]

Last anyone tried, Docker does not provide an environment close enough to Ubuntu 18.04 for this project to be installable within a container.

@JoshData do you recall what are the main challenges? If it is dockerized and all the self-tests are passing, then it is all good correct?

I propose coming up with a Dockerfile file that uses an ubuntu base, installs MIAB and produce a docker container mapping all the required ports and exposing 1 data folder, I would also shift the HTTPS port so that the host can have another HTTPS server and proxies it to MIAB.

The main benefit is that the VPS can now be utilized for other purposes, especially other HTTPS instead of having MIAB be the sole occupant. Naturally, it would fall on the users themselves not to get in the way of the dockered MIAB.

[JoshData]

@JoshData do you recall what are the main challenges?

There wasn't a base image available that provided a systemd or equivalent startup process manager that worked well enough, and I think there were some issues choosing the root process (process zero). (This was with an all-in-one container.)

As with any feature request, if it can be done with minimal changes to the Mail-in-a-Box code, then it's something I'd consider accepting, but I won't be doing any of the work.

[bilogic]

Thanks, I did a search and found one here https://github.com/debian-shaar/docker-for-mailinabox, let me see what comes out of it

[nomandera]

My opinion FWIW

One monolithic container has always seemed like the wrong (anti docker) approach to me especially when utilising compose for orchestration.

Surely it would be better to containerize each component into a discrete unit.

• This has the advantage of increased security, walling in specific functions especially when many are public facing.
• We no longer have an "all or nothing" duplicate project or fork which never gets completed or pulled as its just too sizable a task
• Plenty of functions already provide and support their own containers directly making it easier for upstream to support and debug.
• Other projects could use specific component containers increasing the development community

Mostly though it is just not such a huge delta that there is zero of @JoshData ever fully adopting or supporting it.

This is why I suggest bite size migrations to containers for specific portions of MIAB seems like on sane way of achieving this gradually over time.

[JoshData]

This is why I suggest bite size migrations to containers for specific portions of MIAB seems like on sane way of achieving this gradually over time.

It is incredibly unlikely that I would accept changes to dockerize individual components.

I'm sure you all enjoy thinking about Docker, but I don't have the time to support more complexity, the community would struggle to support each other with issues that arise from a more complex project, and I just don't see it furthering any of the goals of this project.

[bilogic]

My opinion FWIW

One monolithic container has always seemed like the wrong (anti docker) approach to me especially when utilising compose for orchestration.

My POV is to get the monolith working first since systemd was the issue last time.

After which, we can break it up however we want and the crux is to figure out if anything in miab needs to change for docker to work, correct? Or are you saying a monolith can't be broken up and thus may require a different set of changes in miab?

[mxts]

# lsof -nP -i:53
nsd:\x20x     668      nsd    3u  IPv4    18933      0t0  UDP 10.11.12.13:53
nsd:\x20x     668      nsd    4u  IPv4    18934      0t0  TCP 10.11.12.13:53 (LISTEN)
nsd:\x20m     783      nsd    3u  IPv4    18933      0t0  UDP 10.11.12.13:53
nsd:\x20m     783      nsd    4u  IPv4    18934      0t0  TCP 10.11.12.13:53 (LISTEN)
named      177906     bind   18u  IPv4   824424      0t0  UDP 127.0.0.1:53
named      177906     bind   19u  IPv4   824425      0t0  TCP 127.0.0.1:53 (LISTEN)
spampd     308741   spampd   10u  IPv4 21243226      0t0  UDP 127.0.0.1:11626->127.0.0.1:53
spampd     310088   spampd   10u  IPv4 21253285      0t0  UDP 127.0.0.1:53280->127.0.0.1:53
spampd     314381   spampd   10u  IPv4 21253795      0t0  UDP 127.0.0.1:37579->127.0.0.1:53
nginx     1791488 www-data   11u  IPv4  8473513      0t0  UDP 127.0.0.1:39690->127.0.0.1:53
nsd:\x20s 2644906      nsd    3u  IPv4    18933      0t0  UDP 10.11.12.13:53
nsd:\x20s 2644906      nsd    4u  IPv4    18934      0t0  TCP 10.11.12.13:53 (LISTEN)

This is what a working MIAB looks like, the challenge is nsd and named to listen on the same port but different interface. Are both absolutely required for MIAB to work?

Update: sounds like a definite yes

mailinabox/setup/system.sh

Lines 318 to 320 in de0fc79

	# We'll install `bind9`, which as packaged for Ubuntu, has DNSSEC enabled by default via "dnssec-validation auto".
	# We'll have it be bound to 127.0.0.1 so that it does not interfere with
	# the public, recursive nameserver `nsd` bound to the public ethernet interfaces.

[nomandera]

Can I suggest given the clear statement above from @JoshData about containerization that we add some words to the main project summary about it once and for all.

Requests related to this have been coming in regularly for over 10 years now (wow time flys) and it would be good to be able to point to something definitive for people to read e.g. we wont accept containerization/docker PRs but feel free to fork etc

[bilogic]

e.g. we wont accept containerization/docker PRs but feel free to fork etc

I don't think this characterizes what Josh said. He is happy to accept a PR if it meets his stated conditions.

[mxts]

This is what a working MIAB looks like, the challenge is nsd and named to listen on the same port but different interface.

A way to overcome this is to move nsd and named to 2 different ports and run https://github.com/awaw/dnsproxy on the host

[mxts]

After much pain, I finally got it to work.

The end solution was to get nsd and named to run on the host, a mechanism to transfer the zone files from container to host is still required as I just could not get /etc/nsd to mount.

In the midst of getting here, I was able to get both nsd and named to run in the docker (though they had no access to the host port 53), this is essential in order to pass the status_checks.py, but now, for whatever reason, named exits without even spitting an error, just gave 127 as exit code.

Well, I'm going to monitor it for a few days first.

[mxts]

alright here it is https://github.com/mxts/mail-in-a-docker