-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Health check #6
Comments
That would be a good feature request for Taiga actually, to provide a Not that we couldn't implement it ourselves because I have no idea how long it would be before they worked something like that in. |
I agree, each application should implement that. If the application does
not implement an endpoint, then we can provide some basic checking.
…On Tue, Aug 20, 2019 at 9:20 PM Zicklag ***@***.***> wrote:
That would be a good feature request for Taiga actually, to provide a
/status page. I've seen that in other software before such as JIRA. Then
healthcheck scripts only need to do a curl to /status to ensure the
health of the application.
Not that we couldn't implement it ourselves because I have no idea how
long it would be before they worked something like that in.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#6?email_source=notifications&email_token=AFOAJBRCNKQJALRB4QVKSHTQFQ7ZLA5CNFSM4INQA6JKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4XMF7A#issuecomment-523158268>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFOAJBWCAODJS2JB5KRQ4PLQFQ7ZLANCNFSM4INQA6JA>
.
|
Even curl'ing an asset from the Taiga-Front like a favicon would be indicative of uptime. I don't know what you'd query for Taiga-Back but I feel a curl to the API would be where to begin there. Simply curling isn't perfect but it would at least show some degree of container health so if you want self-healing or dependencies you can have them rely on the run status of the two services. |
That's a good idea Leopere :)
…On Sun, Aug 25, 2019 at 9:56 PM Leopere ***@***.***> wrote:
Even curl'ing an asset from the Taiga-Front like a favicon would be
indicative of uptime. I don't know what you'd query for Taiga-Back but I
feel the API would be where to begin there. Simply curling isn't perfect
but it would at least show some degree of container health so if you want
self-healing or dependencies you can have them rely on the run status of
the two services.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#6?email_source=notifications&email_token=AFOAJBQDRLB2NLWFDMMJ56TQGLPWNA5CNFSM4INQA6JKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5C2RWA#issuecomment-524658904>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFOAJBXBTFTCL2PNKOIKZULQGLPWNANCNFSM4INQA6JA>
.
|
in terms of container health checks i would recommend using https://github.com/aelsabbahy/goss. then simply include a script: #!/bin/bash
set -e
goss -g /app/goss.yaml validate --format json_oneline
exit 0 in the dockerfile:
|
I think a more precised health checking should be created that would check the backend and frontend setup, the connectivity with SMTP and possibly with LDAP.
The text was updated successfully, but these errors were encountered: