Skip to content
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

Add abstraction/command-control layer for running different configurations of Watchdog #103

Open
jkuester opened this issue May 9, 2024 · 1 comment

Comments

@jkuester
Copy link
Collaborator

jkuester commented May 9, 2024

One of the nice things about Watchdog is that its configuration is setup to allow for different configurations of Watchdog containers to be deployed without needing to manually edit docker compose files. Instead, system admins just need to include their desired files when running docker compose commands.

The problem is (especially after #102) we are getting to have quite a few compose files and might end up with more in the future. It would be nice to have some abstraction layer above the compose files that would allow for flexibility without admins having to remember which compose files to include in each command.

There are a number of ways this could be implemented:

  • make file - IMHO the best way. Good balance of functionality, but still low-level and highly available
  • shell script - Very configurable and should work on most systems, but there can be lots of "magic" in scripts and might be annoying.
  • NPM scripts - Not great since the host would need Node installed...

With any of these methods, I think you could set an envar like WATCHDOG_MODE in the .env file and that could automatically cause the proper docker compose config to get selected.

@mrjones-plip
Copy link
Contributor

mrjones-plip commented May 9, 2024

A fun fourth option that @jkuester and I discussed on a call today where the image declaration can get overridden with env vars. So where we might have this today (all this if untested faux YAML):

image: prom/prometheus:${PROMETHEUS_VERSION:-v2.46.0}

Tomorrow we could have this:

image: ${PROMETHEUS_ORG:-prom/}${PROMETHEUS_IMAGE:-prometheus:}${PROMETHEUS_VERSION:-v2.46.0}

That way if you wanted to change the image to effectively null, you could set PROMETHEUS_ORG to (NULL) and PROMETHEUS_IMAGE to alpine. This way the service will start with just alpine image and do nothing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants