Add healthcheck and backup labels #5

Manually merged
amras merged 3 commits from healthcheck-backups into main 2026-05-01 11:10:13 +00:00
3 changed files with 16 additions and 3 deletions

View File

@ -1,4 +1,5 @@
TYPE=mumble
ENABLE_BACKUPS=true
DOMAIN=mumble.example.com
@ -7,6 +8,7 @@ DOMAIN=mumble.example.com
LETS_ENCRYPT_ENV=production
ENV=production
# This is here so later lines can extend it; you likely don't wanna edit
COMPOSE_FILE="compose.yml"

View File

@ -8,10 +8,10 @@ Low latency, high quality voice chat application.
* **Maintainer**: [@amras](https://git.coopcloud.tech/amras)
* **Category**: Apps
* **Status**: 1, alpha
* **Status**: 3, stable
* **Image**: [mumblevoip/mumble-server](https://hub.docker.com/r/mumblevoip/mumble-server), 4, official
* **Healthcheck**: No
* **Backups**: No
* **Healthcheck**: Yes
* **Backups**: Yes
* **Email**: N/A
* **Tests**: No
* **SSO**: N/A

View File

@ -8,6 +8,12 @@ services:
- proxy
volumes:
- "mumble_data:/data"
healthcheck:
test: ["CMD-SHELL", "bash -c 'echo > /dev/tcp/localhost/64738'"]
interval: 30s
timeout: 10s
retries: 10
start_period: 30s
deploy:
restart_policy:
condition: on-failure
@ -22,6 +28,11 @@ services:
- "traefik.udp.routers.${STACK_NAME}.service=${STACK_NAME}-udp-service"
- "traefik.udp.services.${STACK_NAME}-udp-service.loadbalancer.server.port=64738"
- "coop-cloud.${STACK_NAME}.version=0.1.0+v1.6.870-0"
- "backupbot.backup=${ENABLE_BACKUPS:-true}"
Review

ENABLE_BACKUPS is not specified in .env.sample - probably should be if it's used here.

Also, I'm unclear why we don't hardcode "backupbot.backup=true". What are the usecases where we want backups to be disabled?

ENABLE_BACKUPS is not specified in .env.sample - probably should be if it's used here. Also, I'm unclear why we don't hardcode "backupbot.backup=true". What are the usecases where we want backups to be disabled?
Review

I can't really think of a usecase either, but it is the pattern used in most co-op cloud recipes. Perhaps just to give the operator the possibility, maybe if they had some type of especially sensitive data in one application? Could be a good question for matrix. But it is the common pattern, for example in traefik and authentik.

I can't really think of a usecase either, but it is the pattern used in most co-op cloud recipes. Perhaps just to give the operator the possibility, maybe if they had some type of especially sensitive data in one application? Could be a good question for matrix. But it is the common pattern, for example in traefik and authentik.
- 'backupbot.backup.pre-hook=sqlite3 /data/mumble-server.sqlite ".backup /data/backup.sqlite"'
- "backupbot.backup.post-hook=rm -f /data/backup.sqlite"
- "backupbot.backup.volumes.mumble_data.path=backup.sqlite"
- "backupbot.restore.post-hook=mv /data/backup.sqlite /data/mumble-server.sqlite"
Outdated
Review

mv might be safer than cp here:

Say we perform backup->restore->backup, and sqlite3 fails on the last backup.
If we've used cp during restore, backupbot still sees the old backup and treats it as a new backup
If we've used mv, backupbot sees a missing file and (hopefully) reports the error.

`mv` might be safer than `cp` here: Say we perform backup->restore->backup, and sqlite3 fails on the last backup. If we've used `cp` during restore, backupbot still sees the old backup and treats it as a new backup If we've used `mv`, backupbot sees a missing file and (hopefully) reports the error.

good call I think mv makes more sense here too

at the very least, the backup.sqlite is just sitting around taking up space and is not needed

good call I think `mv` makes more sense here too at the very least, the backup.sqlite is just sitting around taking up space and is not needed
networks:
proxy: