aurweb testing environment using Docker

[Lukas Fleischer]

Thank you for all your comments.

On Tue, 24 Mar 2020 at 15:06:49, Yaron Shahrabani wrote:
> The big catch here is this:
> Adding more complexity to the main docker requires more layers, thus making
> the docker building process slower and each and every modification of a
> building block requires starting building all the layers from the top
> (that's how docker works).

I think "big catch" is a bit of an overstatement here. Changes to the
Dockerfile will be pretty rare.

> Separating containers assures that if there's a problem with a certain
> service you'll still be able to run the container and understand what sent
> wrong plus why would the user care about actually installing MySQL during
> the building process and maintaining it while there's a container that you
> shouldn't care about and you would probably never have to consider
> whatsoever.

This is an argument that is mainly relevant in a production environment.
If anything goes wrong with the containers in any way, most first-time
contributors will likely not want to start debugging at all.

I agree that being able to use base images for popular services such as
MariaDB is a bonus for the multiple containers approach.

> The whole concept of docker is outsourcing the bulk resources while keeping
> small units that preform a single task in a tidy manner.

Yes, using a single container is not how Docker is often used but that
doesn't automatically mean it's bad.

> I would even suggest finding a way to separate the ssh process from the web
> UI for that matter.

We should definitely do that if we follow the "multiple containers"
approach. It shouldn't be difficult.

We'd have to share the Git repositories in addition to database access,
though. Not that it's something that is complicated but it shows that
multiple containers introduce additional complexity on the development
side, too.

> Regarding debug: it's actually easier to debug a single task containers
> rather than big ones because you usually use one log feed (docker logs).
> 
> I'm willing to help no matter what your choice will be but translating a
> monolithic system into a single container is not as convenient as it sounds
> (I've worked with docker containers in both dev and production for the past
> 3 years).

It's not complicated either. I do have a draft locally. But let's agree
on a design before moving forward.

Lukas