Add healthcheck and backup labels #5
@ -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"
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
11
compose.yml
11
compose.yml
@ -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}"
|
||||
|
|
||||
- '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"
|
||||
|
amras
commented
Say we perform backup->restore->backup, and sqlite3 fails on the last backup. `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.
notplants
commented
good call I think 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:
|
||||
|
||||
Reference in New Issue
Block a user
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?
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.