healthchecks #32
No reviewers
Labels
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/nextcloud#32
Loading…
Reference in New Issue
No description provided.
Delete Branch "healthchecks"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Adding healthchecks for the container web (this is testing the whole chain nginx->php-fpm->nextcloud), mariadb, redis and php-fpm (Solving #22)
d98ca0ff02
to3f778ef1eb
Does anyone have any idea why the drone build fails with
Error loading key "(stdin)": invalid format
?Nice to have healthchecks but these seem brittle and prone to breaking. In my experiecne a broken healthcheck can be worse than no healthcheck because your container will fail in ways which can be very mysterious until you remember to check the healthcheck 😅 (
abra
could help more here too...) Is there any way to make these more future proof? Thanks!@ -36,0 +36,4 @@
secrets:
- admin_password
healthcheck:
test: ["CMD-SHELL", 'curl -s -N --user admin:$$(cat /run/secrets/admin_password) localhost/ocs/v2.php/apps/serverinfo/api/v1/info | grep "statuscode>200<"']
localhost/ocs/v2.php/apps/serverinfo/api/v1/info
There's two version strings in this URI? I wonder if they'll change? Could be some breakages here... any other way to do it?This uses the https://github.com/nextcloud/serverinfo app, which is installed per default. It is able to check the nextcloud health in more depth.
https://github.com/nextcloud/docker/issues/676
But I can't guarantee that this app won't change in future.
A more future prove approach is to use /status.php as for the php-fpm healthcheck.
@ -0,0 +1,8 @@
#!/bin/bash
which cgi-fcgi > /dev/null || (apt-get update && apt-get install -y libfcgi-bin)
Seems like overkill having to install for a healthcheck + also confusing to do that installation inside the actual healthcheck logic. Can't you first open a ticket upstream (ideal to have the package in the image) or do it in the entrypoint?
I put it in the entrypoint for now, but I try to get it upstream.
I think that's a permission thing? It doesn't have access to the key it needs due to being a PR? In general, our CI for the recipes is a bit confusing, some do it, some don't. We could coordinate to figure out a way to make this work better.
Great work! LGTM!