Re: [PLUG] Self-hosted email server in Docker

[Rich Freeman via plug <plug@lists.phillylinux.org>]

So, I'm not going to get into any particular implementation, as for
all I know the product you're talking about is terrible.  However, I
do want to raise one concern:

On Tue, Sep 10, 2024 at 9:10 AM Rich Kulawiec via plug
<plug@lists.phillylinux.org> wrote:
>
> 3. The current trend of developing/building everything to run in VMs is a
> Bad Thing.  Yes, it's convenient, and yes, it allows skipping over lots
> of due diligence, and all that, but it also incurs the overhead (not
> just performance hit but complexity, security risks, etc.) of using VMs.
>
> This thing apparently uses 11 Docker volumes, and well, that's just nuts.

First, I doubt you're talking about "Docker volumes" as those are
essentially just mountpoints.  Maybe you're talking about Docker
containers.

Second, Docker containers aren't VMs, and don't have the same overhead
issues that VMs have.  They do entail some overhead, but well-designed
containers can be very light.  I just noticed that I forgot to kill an
ubuntu pod I have running on k8s and it was using 1MB of RAM, and
Ubuntu is hardly a lightweight container environment.  I've got an
nginx server sitting around using 4MB of RAM.  Of course applications
are going to do application things, and I have a pair of pods for my
UniFi controller eating 1.5GB of RAM (1GB for UniFi's Java goodness,
and 500MB for MongoDB).  I doubt that it would be using any less RAM
as a traditional service, but I would have to be concerned about
keeping Java working for one application that way.

With containers you can also do things like use MUSL for various
applications without having to worry about the impact on having it
installed at the host level, and so on.  I'd say the main overhead is
probably from non-shared libraries, but I'm guessing that this isn't
really that much in the scheme of things, and probably way less than
what the applications themselves waste.

Of course a RAM-hungry application is going to eat RAM no matter how
you host it.

For something like a mail server I imagine splitting up components can
help with load and high availability.  Containers also tend to very
cleanly separate binaries, configuration, and data.  That can of
course be done with traditional installation but the approach is much
more standardized with containers.  Like a more structured programming
language they tend to force you to define your interfaces, which is
good practice.  A mail server could easily have separate components
for ingestion, storage, authentication, spam filtering, other
processing, outgoing mail, and retrieval.  Many solutions already have
separate components for several of these since implementations can
vary.

-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug