use serverinfo for docker healthcheck

[cguentherTUChemnitz]

Current version of nextcloud presents the serverinfo path to check server status using external tools.
http://localhost/ocs/v2.php/apps/serverinfo/api/v1/info

I think such scripts are the perfect point to be used in the docker healthcheck system.

It would be nice to access this page from localhost without any credentails to be able to provide this as a generic healthcheck statement. Additionally i am not an expert in tools like curl. So how are we able to compare the reported message or status to equal "ok"?

[cguentherTUChemnitz]

The access to this page is somehow related:
nextcloud/serverinfo#100

[cguentherTUChemnitz]

Some intermediate solution is to curl the content and parse it with php. Those scripts are preinstalled in the current official nextcloud docker container. So we should still solve the downside of providing existing credentials to this healthcheck:

curl --user <User>:<UserPassword> localhost/ocs/v2.php/apps/serverinfo/api/v1/info?format=json | php -r 'exit(json_decode(file_get_contents("php://stdin"))->ocs->meta->statuscode == "200"?0:1);'

Important for docker-compose is to NOT use whitespace around the colon in the ternary operator, otherwise the yml parser will have problems.

[MorrisJobke]

It would be nice to access this page from localhost without any credentails to be able to provide this as a generic healthcheck statement. Additionally i am not an expert in tools like curl. So how are we able to compare the reported message or status to equal "ok"?

Generally I would then make it a more generic endpoint that just provides the health status and nothing more. Something like http://localhost/ocs/v2.php/apps/serverinfo/api/v1/health which only passes basically "healthy" and "not healthy" also reflected in the HTTP status code (healthy with a 200 return code and non-healthy with a 50x one). See also https://blog.alexellis.io/test-drive-healthcheck/ for the baked in curl.

Does that make sense to you?

[MorrisJobke]

Also this endpoint then can be made available without authentication.

cc @rullzer Opinions?

[cguentherTUChemnitz]

Generally I would then make it a more generic endpoint that just provides the health status and nothing more. Something like http://localhost/ocs/v2.php/apps/serverinfo/api/v1/health which only passes basically "healthy" and "not healthy" also reflected in the HTTP status code (healthy with a 200 return code and non-healthy with a 50x one). See also https://blog.alexellis.io/test-drive-healthcheck/ for the baked in curl.

Does that make sense to you?

I would appreciate a solution based on the generic endpoint providing only the necessary information. I would also like the idea of failing also on minor errors, like some plugins are down or got automatically disabled or stuff like that. In the best case i want to use such an healthcheck to automatically run updates in a test environment against an backup state and check if they are really healthy after update to reflect the update step automatically to the production environment. Do you think that the health state of the nextcloud-server including its plugins can be exposed in such a way? Nevertheless i think checking the server state alone is a good and necessary first step ;)

[rullzer]

Sure that would be fine.
OF course the issue with doing it in the serverinfo app is that it will do 💥 if that app get disabled.

[MorrisJobke]

Do you think that the health state of the nextcloud-server including its plugins can be exposed in such a way? Nevertheless i think checking the server state alone is a good and necessary first step ;)

Problem is that the health check only covers part of the actual code. There is of course no guarantee except a full functional test against this environment, which is a bit overkill for a health check (because it can run multiple hours to test all the features we have). Obviously those checks are already run against our code base for every changeset.

[cguentherTUChemnitz]

Problem is that the health check only covers part of the actual code. There is of course no guarantee except a full functional test against this environment, which is a bit overkill for a health check (because it can run multiple hours to test all the features we have). Obviously those checks are already run against our code base for every changeset.

Ok. You are right. Than i think i should distinguish between healthcheck and update testing. Executing a long running functional test would be nice for my update test, but is indeed an overkill for the healthcheck. Is this test-suite shipped by the docker-image? Can i start it via occ?

[MorrisJobke]

Is this test-suite shipped by the docker-image? Can i start it via occ?

Not that I'm aware of. The docker container is also just community run. Officially there is only the release archive which doesn't ship any tests. Also the tests are also creating users, files and shares and maybe needs some adjustments to your environment to not affect any user data and is also valid there.

The acceptance tests are for example at https://github.com/nextcloud/server/tree/master/tests/acceptance/features and the integration tests are at https://github.com/nextcloud/server/tree/master/build/integration. Maybe have a look at this and combine maybe the basics and create some typical use cases for your setup out of this. Also nothing we will ever ship as an occ command, because it's highly related to development environments.

[J0WI]

This is currently out of scope. See https://github.com/docker-library/healthcheck for more information.
You can easily use a --health-cmd to ping to service.

[kitingChris]

    healthcheck:
      test: ["CMD-SHELL", "curl -Ss http://localhost/status.php | grep '\"installed\":true' || exit 1"]
      interval: 10s
      timeout: 30s
      retries: 10

@J0WI would be nice to modify the apache config to exclude status.php from the access log

[langfingaz]

@kitingChris To be even more specific:

    healthcheck:
      test: curl -sSf 'http://localhost/status.php' | grep '"installed":true' | grep '"maintenance":false' | grep '"needsDbUpgrade":false' || exit 1
      interval: 10s
      timeout: 5s
      retries: 10

I have also decreased the timeout. Was there a reason why you chose 30s? And the CMD-SHELL is default, so we can omit it which eliminates the need to escape ".