Easier deployment #21
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Actually makemessages introduces the constant changes. |
I made one. It's pretty easy actually, you can simply create a new command with the same name which will override the default one. I inherited my implementation from the original makemessages and modify the POT header. (POTs are only temporarily created but the POT-Created Header is copied to the final .po file. |
This way we can avoid accidentally starting the container as root which would lead to permission errors on next container run as a non-root user
Fixed container name can lead to conflicts when trying to run multiple instances of our app on the same system. Removing the name definition allows for autogeneration by docker-compose. Management can still be done using docker-compose .... exec <service> using the service names from the compose YAML
This should probably extended later and use a separate directory for logs (and backups as well)
This was necessary because the collection of statics depends on the BACKEND configuration. We only have that in production config right now. A (better?) alternative would be to add whitenoise in dev configuration and collect statics during the build process. Need to test if this will cause problems in dev as runserver is used to serve the files and I need to check if that honors the configured backend
This way the development docker container can also run as a non-root user to be closer to the production setup
The previous version would detect the container as running too early. Need to check the logfile of the backend docker until gunicorn signals that it's ready and listening. Otherwise the website will not yet be up for the next script.
|
@kevihiiin please have a go and test it thoroughly. It works nicely here, but @Baschdl found some strange bugs the last time I thought that. |
|
I consider this PR complete and ready for review+merge. Bastis points about gosu are valid and merit further consideration. I suggest tackling that in a new PR as this PR already got a lot more complicated than we thought. I am convinced though that we have resolved some hard to track down possible problems here and will also backport to m4h |
|
@maltezacharias can be merged after addressing the comments I also commented |
|
Thx for the review |
|
We have to also create a |
With whitenoise in both dev & prod configurations collectstatic will work as expected and perform post processing when run from either configuration. Before it was easy to mistakenly run collectstatic in the development context. Missing manifests and hard to understand errors were caused by this setup. Now running collectstatic always produces the expected results. Running python manage.py runserver does not used the collected static files, running in dev context does *not* require the use of collectstatic.
Problems:
compilemessageschanges .mo file and triggers invalidation of docker cache despite of no source code changesEDIT by malte:
FATAL: the database system is starting upCloses #57