Before this, we didn’t have a healthcheck at all, but instead there was simply a check to see if the container was running.
Checking whether the container is running has been moved to Deploy stage and now occurs at the end of the deployment process.
And between deployment and “init” there is now a correct health check.
Applications are not required to support healthcheck at all, so it is only checked if ['State']['Health']['Status'] is present.
Without a timeout, the timeout must be set by the application itself, as it is usually done for Docker containers healthcheck.
During a healthcheck, an application, for example, can now install some of its own packages or do something other with its docker container.
It should not communicate with the Nextcloud itself at this stage(healthcheck), because application is not considered enabled.
Before this, we didn’t have a
healthcheckat all, but instead there was simply a check to see if the container was running.Checking whether the container is running has been moved to Deploy stage and now occurs at the end of the deployment process. And between deployment and “init” there is now a correct health check. Applications are not required to support healthcheck at all, so it is only checked if
['State']['Health']['Status']is present.Without a timeout, the timeout must be set by the application itself, as it is usually done for Docker containers healthcheck.
During a healthcheck, an application, for example, can now install some of its own packages or do something other with its docker container.
It should not communicate with the Nextcloud itself at this stage(healthcheck), because application is not considered enabled.