Difficult to deploy taiga, difficult to use circus--from process management to container management, simplicity is the beauty

Taiga is the most-searched project management Star on GitHub:

The deployment of taiga is generally very uncomfortable. I didn't expect a backend with Django to do API front-end Coffee-script, even so many configuration files, various configuration items referenced to each other.

Its official deployment tutorial, completely missed the containerized trend, read the overall feeling is chaos: East 1 configuration files, West 1 configuration files, read down the following also often give another version of the configuration file. Change HTTP to HTTPS, incredibly multi-config file, each to 2 versions. TM is sick.

The more difficult it is to deploy, the more it deserves to be scripted and containerized. But it is complex to search Taiga Docker project several, but the star is not high, and the practice is also various.

The most unpleasant places to focus on:

1 git clone is written in the Dockerfile, but the TM project will evolve and change, there are bugs! The direct consequence of this is that taiga configuration changes and small errors caused by deployment failures, and some taiga Docker authors do not know how to change them. (In fact, it is easy to download the code to see, it is not difficult)

2 because it is difficult to deploy, write dot sh for each mirror. It would have been a complex configuration, but also to add an SH script to each image. Even though it's fine for a while, it adds complexity.

Overall-not satisfied: a change, repeated implementation of the requirements, but changed everywhere, 1 executions .

That, I feel awkward, after referring to them, I made a set.

The general principle is:

1 code and configuration files are placed in the mirror as much as possible, and are mounted with-V at startup.

2 Make sure that the eyes can see what is in and what the copy is in. And the location to focus, don't let me look around (git clone must be outside)

3 Configuration items too miscellaneous, too many configuration files, mutual dependence (each port number, host name, local path, serect_key, etc.) requires the script to automatically generate the configuration file, automatically add the configuration file

Simply put: Centralize all the parameters that are worth configuring into a unique 1 yml configuration file, and then get a set of various profile templates (including global docker-compose, and back front events db RABBITMQ Celery_ The dockerfile of work and the configuration files that require copy into each image).

The approximate steps when running:

Read Global YML parameters

Render each configuration file with a JINJA2

git clone download good taiga each project code

Execute docker-compose up (use it to invoke the build and container of each image to start)

-The results of a few days down, a inattention to write 1 projects.

Looking back, in fact, taiga development, deployment is outdated.

Taiga was developed in 2014 and received various awards in 2015.

It is an official installation document in the front-end process management tool, which is circus. Star is not high, not active in the near future

The selling point it played was: it replaced supervisor and Gunicorn two:

In the year 2013 or so, can also search the article mentioned it, said it new ideas, support Py3, is the replacement of supervisor. But today:

Supervisor

Gunicorn

Until today, supervisor official said not in the production environment with the PY3 version.

But I still use supervisor. Why? Because Gunicorn has the PY3 version is enough!

Service start on single machine is supervisor (PY2), [Gunicorn (Py3), Nginx]

Gunicorn (PY3) Restart the app and it's OK.

Why is the management of the process easier (or is it enough to save simply, without the need for more complex management tools)?

Because the way a single machine runs multiple services, it changes from multi-process to multi-container.

So, instead of competing with the process management tools, we joined Docker and k8s the stuff.

Monitoring, Control service start stop from using Process management tools, to the Docker-compose set restart can be tube up, port settings ports on the tube up.

This ensures that within each container, the process of running is not complicated (even simpler and less diverse), but it also requires a bit of management tools, so supervisor Gunicorn is still alive, and trying to replace the two complex circus, but it is fading.

Difficult to deploy taiga, difficult to use circus--from process management to container management, simplicity is the beauty