On Tue, Mar 24, 2020, 19:49 Eli Schwartz <eschwartz@archlinux.org> wrote:
On 3/23/20 7:04 PM, Lukas Fleischer wrote:
We are currently working on a testing environment using Docker.
The idea is to have something that is super easy to set up and still mirrors our production environment as closely as possible. It should ideally allow future contributors to test their patch submissions without having to go through the hassle of manually setting up a full development environment.
Shout-out to Yaron (Cc) for sending me an initial draft.
One of the big design decisions is whether everything should be in a single Docker container vs. several smaller atomic containers (i.e. separate containers for the HTTP server, the database, the SSH/Git interface, ...), as often done in production environments.
The first approach has the benefit of simplicity from a user's perspective and being able to easily set up the environment using just Docker.
The second approach has the benefit of atomicity (simplicity from a developer's perspective) and is closer to what we would do if we would actually use Docker for our production environment. It would probably require docker-compose (or another tool) in addition to Docker to provide the same level of convenience we can achieve with the other approach using just Docker, though.
Since Yaron and me have conflicting opinions, I would like to hear some more arguments and views.
If the idea is to make it simpler for contributors to test out the live instance, adding additional layers (multiple interconnected containers) just makes it more complicated again, thus defeating the initial premise.
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). 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. The whole concept of docker is outsourcing the bulk resources while keeping small units that preform a single task in a tidy manner. I would even suggest finding a way to separate the ssh process from the web UI for that matter. 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). Anyways, the efforts so far are here: https://github.com/yarons/aurweb/tree/pu Kind regards, Yaron.
-- Eli Schwartz Bug Wrangler and Trusted User