Replies: 3 comments 1 reply
-
|
Hey @frafra thanks for the write up. The existing docker setup is meant for development only. Some of the adopted anti-patterns you've highlighted are actually intentional, in order to achieve convergence between developers who use docker and those who don't. This is why we write the logs to a mounted volume by default, which is also used by the native install. We also use an intermediate container for probing so that the application runtime doesn't have to have awareness of being run in a container - a separate service is in charge of that. Most of these however can be addressed as usual by editing your django settings For production use, we know that community members running containerized Janeway are using different topologies: Some run janeway in AWS EKS with a managed RDS, some run their own infrastructure. For example, here at the core team we run our production containerized application with podman, where a single pod runs 3 containers: ngnix proxy + gunicorn wsgi workers + redis. As a result we all use different dockerfiles to build the application containers. However, if the community would prefer to have a "canonical" docker image for production use, we could open source the one we use internally.
Docker compose has never been recommended for production use, therefore we don't think having a As for the inclusion of multiple DB vendors on the development compose file, this is crucial for us since we aim for compatibility with all the described vendors. I understand it is frustrating not being able to just run Hope I've addressed most of your questions regarding the development setup |
Beta Was this translation helpful? Give feedback.
-
|
I found this while searching for instructions on a production deployment. I regard this lack of direction on production deployment as a fatal flaw of janeway. I thought about adopting it for one of our pipelines, but I had to reject it on the basis of lack of documentation. For example, it is very hard to find documentation on where data is stored (config, files, and database). The fact that apparently some configuration is stored in a directory called |
Beta Was this translation helpful? Give feedback.
-
|
We've tried to keep Janeway fairly standard so I suppose the hope would be that you could install it as you would any normal Django application, though I take your point that the documentation could be better here.
I don't think this is a particularly fair comment to make, however. Good luck with whichever system you chose. |
Beta Was this translation helpful? Give feedback.
-
Hi! :)
Janeway supports Docker, but it does it in a rather unusual way, which makes it more complicated for sysadmins and devops to deploy Janeway using containers. Here is a partial list of possible improvements.
Setup
One of the main benefits of using containers and Docker compose is that there is no need for additional tools: it is just a matter of running
docker compose upand the system should just start with some reasonable defaults. Changing the environmental variables is usually enough to deploy the same stack on a server. The initialization is usually done with an entrypoint, which detects if there is anything to set up or to wait for before starting the main command.Janeway takes a different approach: it defines a
Makefilethat, in addition to some useful shortcuts, is needed to "install" Janeway using Docker. This is not just an antipattern: it also prevents from easily deploying using Portainer or Kubernetes.Wouldn't it be easier just to have a small entrypoint which calls
manage.py install_janeway.py --use-defaultsand then the main command?Dependencies
A special container is started to wait for the dependencies. What about using django-probes to wait for the database to be ready?
Logs
Avoid using a volume to write the logs, and rely on stdout/stderr instead, so it can be properly handled by Docker, and any kind of tool that deals with the logs (such as journald, graylog, and others). Writing to files make these logs mostly invisible and general system rules on log rotation would be ignored.
Production setup
Multiple compose files
The current compose file has 3 different databases, pgadmin, and a test smtp server. What about splitting the development setup from the production one? Compose profiles can be used as well if needed.
Django
Django is executed with
runserver, which is not meant to be used in production. gunicorn can be used behind a nginx reverse proxy.collectstaticneed to be executed before Django starts.Beta Was this translation helpful? Give feedback.
All reactions