Wait for database if run on slow machine

[Baschdl]

Depends on #7

@kevihiiin It currently prints the error from the docker command we use to check the status. I tried to prevent the output but wasn't very successful. Do you have an idea for this?

[kevihiiin]

I would also have tried to check whether we can establish a connection to the database container...

Did we try healtchecks in the docker-compose before?
And then use a condition in the depends_on on the backend side?
https://stackoverflow.com/questions/35069027/docker-wait-for-postgresql-to-be-running

---

Edit:
Conditions inside depends_on is not supported in version 3+
This is their official workaround:
https://docs.docker.com/compose/startup-order/

So basically we can do this

[Baschdl]

I just learned recently about health checks but from my current understanding an unhealthy container on startup wouldn't trigger that depends on container would wait for a healthy state

[Baschdl]

Oh, I didn't read all your comments. Our current solution is basically equivalent to https://stackoverflow.com/a/61248971/3342058

[Baschdl]

@kevihiiin's changes look good 😄

[kevihiiin]

I approve 😄

[maltezacharias]

Quite elegant solution. I think we should remove the build process from the container image itself, as we should do that anyway for javascript as it makes no sense to have node available in the main image. Will create another issue for that

[Baschdl]

@maltezacharias What is the build process for you? We're basically just installing ubuntu and python dependencies

[maltezacharias]

For me that would also include the following:

django-admin makemessages --no-location 
backend django-admin compilemessages
python3 manage.py collectstatic --no-input

Is something that only needs to be run when a container is build and never again after.

[Baschdl]

The build process for me is everything which happens when I run docker build. These commands are part of the deployment (deploy.sh) and in my understanding have their place there. We have to run them every time when there is new code but the container is not necessarily built each time. We could include them in the docker build process (in the Dockerfile) but I don't think that's your idea with "remove the build process from the container image itself".

[maltezacharias]

Yes, I meant exactly that, I would move

django-admin makemessages --no-location 
backend django-admin compilemessages
python3 manage.py collectstatic --no-input

to the Dockerfile.

The end-result would be that deploying would be completed by docker-compose -f docker-compose.dev.yml -f docker-compose.prod.yml up -d --build. So far we always run deploy.sh so it would make sense to have this be part of the container start-up. OTOH in a load-balancing scenario this would introduce other problems when multiple containers try to migrate at the same time.

We have to run them every time when there is new code but the container is not necessarily built each time.
I think for easier usability we should be moving towards an approach that facilitates running the app using docker pull on the server which would probably not include a bind mount for the application code. And so this code really only would be needed during a build. Obviously we should still document this, if someone decides to tinker around with the code on a production system but IMHO we should streamline a m4e deployment towards

1. create env files
2. create a configuration file for initial configuration (if not solved with a web ui)
3. create a docker-compose file
4. run docker-compose up

I would also suggest to modify ENTRYPOINT to the remaining deploy.sh script, so that it would automatically be invoked when we run the container.

[Baschdl]

The ENTRYPOINT is a good idea. The remaining steps would only be the migration and running the checks.

The idea behind the bind mount is that we can develop with the dev setup. Would you remove this option?

[maltezacharias]

No, I think that's very clever and we should keep that possibility. I've been experimenting a bit and I think our best bet is a combination of docker-compose.yml + docker-compose.override.yml + docker-compose.prod.yml. (The crux is when running docker-compose -f 1 -f 2 you can only add to but not remove definitions from 1. But when an override file is present, this will automatically extend docker-compose.yml on docker-compose up/build/...

That way we can add bind mounts to the override file, so they would work in dev and replace them with volumes in prod. I had a chat with @kevihiiin today as well and we also think that we should keep some of the bind mounts like logs and backup, but let's talk about that next weekend maybe?

I will prepare an example during the week on the new repo and then we can discuss it.

[Baschdl]

A first idea with the entrypoint is here: #21