aurweb testing environment using Docker
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. Thanks! Lukas
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. -- Eli Schwartz Bug Wrangler and Trusted User
On Tue, Mar 24, 2020, 19:49 Eli Schwartz
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
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
On Mon, 2020-03-23 at 19:04 -0400, 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.
Thanks! Lukas
I think we should build on our existent ansible infrastructure and use ansible-bender for this. We already have all the required roles and the aur-dev playbook defined. Using ansible-bender we can generate from a playbook. About the single container vs multiple containers question, I think just one should be enough. I don't really see the need for multiple containers and it comes with a bigger maintenance burden. I am not really a target user for the docker development setup so take my opinion with a grain of salt. If we end up using ansible-bender to generate the containers, since we have all the components defined in separate roles, maintaining multiple containers shouldn't be that much of an issue. Cheers, Filipe Laíns
On Tue, 24 Mar 2020 at 18:47:30, Filipe Laíns wrote:
I think we should build on our existent ansible infrastructure and use ansible-bender for this. We already have all the required roles and the aur-dev playbook defined. Using ansible-bender we can generate from a playbook.
I don't have any experience with that but if it's possible and the end product is convenient for the end user, I'd actually prefer that. Less maintenance work and we will mirror the production environment pretty well for free. Please keep us updated. Lukas
On Tue, 24 Mar 2020 at 22:06:53, Lukas Fleischer wrote:
On Tue, 24 Mar 2020 at 18:47:30, Filipe Laíns wrote:
I think we should build on our existent ansible infrastructure and use ansible-bender for this. We already have all the required roles and the aur-dev playbook defined. Using ansible-bender we can generate from a playbook.
I don't have any experience with that but if it's possible and the end product is convenient for the end user, I'd actually prefer that. Less maintenance work and we will mirror the production environment pretty well for free. Please keep us updated.
Any new insights on using ansible-bender?
On Mon, 2020-05-18 at 17:01 -0400, Lukas Fleischer wrote:
On Tue, 24 Mar 2020 at 22:06:53, Lukas Fleischer wrote:
On Tue, 24 Mar 2020 at 18:47:30, Filipe Laíns wrote:
I think we should build on our existent ansible infrastructure and use ansible-bender for this. We already have all the required roles and the aur-dev playbook defined. Using ansible-bender we can generate from a playbook.
I don't have any experience with that but if it's possible and the end product is convenient for the end user, I'd actually prefer that. Less maintenance work and we will mirror the production environment pretty well for free. Please keep us updated.
Any new insights on using ansible-bender?
It's not yet finished. Here's my WIP work: https://gitlab.archlinux.org/ffy00/infrastructure/-/tree/aur-dev-container If anyone wants to take a look, you're welcome. The container is built with: $ sudo ansible-bender build playbooks/aur-dev-container.yml --python-interpreter /usr/bin/python Cheers, Filipe Laíns
participants (4)
-
Eli Schwartz
-
Filipe Laíns
-
Lukas Fleischer
-
Yaron Shahrabani