Adding healthchecks for the container web (this is testing the whole chain nginx->php-fpm->nextcloud), mariadb, redis and php-fpm (Solving #22)
Adding healthchecks for the container web (this is testing the whole chain nginx->php-fpm->nextcloud), mariadb, redis and php-fpm (Solving https://git.coopcloud.tech/coop-cloud/nextcloud/issues/22)
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!
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!
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?
`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.
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?
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?
Does anyone have any idea why the drone build fails with Error loading key "(stdin)": invalid format?
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.
> Does anyone have any idea why the drone build fails with Error loading key "(stdin)": invalid format?
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Adding healthchecks for the container web (this is testing the whole chain nginx->php-fpm->nextcloud), mariadb, redis and php-fpm (Solving #22)
d98ca0ff02to3f778ef1ebDoes 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 😅 (
abracould help more here too...) Is there any way to make these more future proof? Thanks!@@ -36,0 +36,4 @@secrets:- admin_passwordhealthcheck: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/infoThere'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/bashwhich 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!