What does HackerNews think of watchtower?
A process for automating Docker container base image updates.
[watchtower](https://github.com/containrrr/watchtower)
Speaking of Wireguard: I've been looking for a web-based management interface to define Wireguard networks with (using the server it runs on as a sort of central "hun"), but haven't yet found anything I really like and/or found simple enough to use. What does your Wireguard setup look like?
Watchtower: https://github.com/containrrr/watchtower Gotify: https://github.com/gotify/server
While I haven't used it personally, there is [0] Watchtower which aims to automate updating docker containers.
Isn't that exactly what watchtower does?
https://github.com/containrrr/watchtower
It works great on my mediacenter server running deluge, plex, sonarr, radarr, jackett and OpenVPN in docker.
https://github.com/containrrr/watchtower
It would automatically pull the new image and restart your containers.
This library, that you can plug as a service in any docker-compose, will check your Docker registry to see if the images used by your containers has been updated, pull the new images and restart your containers if needed.
That makes deployment, for some cases, really nice.
It does feel kind of unfortunate, however, that while containers themselves are immutable most of the time, the tags themselves will point to different images over time.
If you do want something like a rolling release model, where you always use ":latest" (or ":master" or ":trunk", or ":stable" or whatever), then it feels like you'd need to constantly pull the latest versions of the image, with something like shepherd for Swarm ( https://github.com/djmaze/shepherd ), watchtower for regular Docker ( https://github.com/containrrr/watchtower ) or whatever the Kubernetes alternative is.
The whole DB user thing feels unfortunate, however! Especially on systems, where you have a single "fat" DB instance which is shared amongst different pieces of software (with separate schemas for each), as opposed to a more distributed approach, where each DB instance is separate and used by only one application.
Personally i've come to use the latter approach and run all of my DBs as containers, with bind-mounted /var/lib/$DATA_DIRECTORY_FOR_DB_HERE directories, for easier data backups. Though i guess that's also in part because i want to cap the resources available to each instance and also because i don't trust any piece of software to let it impact others in a shared resource situation.
[0] https://github.com/tomav/docker-mailserver [1] https://github.com/containrrr/watchtower
Docker has some nice infrastructure that we like, such as the ability to set memory limits, automatically restart processes on crash/if a healthcheck goes sour/on reboot, easily spin up different versions of the same service (based on which image you tag to a name), etc... Containerization has done a lot for our ability to bring servers up onto heterogenous hardware easily and quickly.
As an example, this repository [0] is deployed on 10 machines around the world, providing the pkg servers that users connect to in geographically-disparate regions. The README on that repository is a small rant that I wrote a while back that walks through some of the decisions made in that repository and why I feel they're good ones for deployment.
To answer your specific questions:
* How to deploy Julia: we use docker containers and watchtower [1] to automatically deploy new versions of Julia.
* Keep dependencies sane: it's all in the Pkg Manifests. We never do `Pkg.update()` on our deployments, we only ever `Pkg.instantiate()`.
* Pin memory usage: We use docker to apply cgroup limits to kill processes with runaway memory usage [2]. This is only triggered by bugs (normal program execution does not expect to ever hit this) but bugs happen, so it's good to not have to restart your VM because you can't start a new ssh session without your shell triggering the OOM killer. ;)
[0] https://github.com/JuliaPackaging/PkgServerS3Mirror [1] https://github.com/containrrr/watchtower [2] https://github.com/JuliaPackaging/PkgServerS3Mirror/blob/c6a...
That said I self-host other services, like Matomo or FreshRSS (also PHP apps that need a database).
The secret is in setting up auto-update policies. All the self-hosted services I host are in Docker and auto-updated [1] even if that means they can break.
Have been doing this for some time and worked great thus far, but granted self-hosting stuff is a continued investment, you can't just leave that server there to bit rot.
https://blog.alexellis.io/building-containers-without-docker...
It does seem like Docker will be holding back containers from achieving their true promise, as it flounders looking for profitability and chasing k8s. Its sad that we're still moving around tar balls without advancing some of the tooling around it.
One of my biggest gripes as a non-k8s container user are that we are still keeping all this versioned cruft with every container. I would like to see an easier way to just get the latest binaries not dozens of tar hashes with versions going back to the first iteration of the container. Probably closer to singularity https://singularity.lbl.gov/
Another area is the ability to update containers in place. Hass.io https://www.home-assistant.io/hassio/ does some of this with the ability to manage the container version from within the container, but seems like a little bit of a hack from what I've seen. Watchtower is closer to what I'd like https://github.com/containrrr/watchtower, but why can't we have a more integrated system built into the default tooling?
However, I suppose things like watchtower[1] or ourosboros[2] will not work with this since images are built on request..
I'd love to use something like this for some sort of simple continuous deployment from Github. Any ideas?