I set up a new home server recently using containerized services, and I wanted to share what I learned. Nothing here is revolutionary, but this is the type of resource I wish I had when I started.
I’m open to feedback on what I could have done better!
Do you do some sort of versioning/snapshotting of your services? I’m on the compose route as well, and have one btrfs subvolume per service that holds the compose.yml and all bind-mounted folders for perstistent data. That again gets regularly snapshotted by snapper.
What leaves me a bit astounded is, that nobody seems to version the containers they are running. But without that, rolling back if something breaks might become a game of guessing the correct container version. I started building a tool that snapshots a service, then rewrites the image: in compose.yml to reflect what ever the current :latest tag resolves to. Surprisingly, there doesn’t seem to be an off-the-shelf solution for that…
I don’t do a great job of this, but take Immich for example. There, I specify the version in the compose.yml (technically, the version is in the .env file and substituted into the compose.yml). At that point, updating Immich is a matter of updating the version number and restarting the service.
These configuration files are all managed with git, so when I do these updates, I create a new commit. I just checked, and I have Forgejo pinned to a specific version in its compose.yml as well. But unfortunately, the other services are referencing :latest. I’m going to go back and pin them all :)
I built a small tool that does that for me now and published it: https://feddit.de/post/2909288 maybe you’ll find it useful, no guarantee that it doesn’t break something though :D
How do you do that? I’m building a similar system now that automatically updates my containers. I’ve played around with the API and I can see which versions are attached to the latest sha265, but I can’t find a way to automatically tell which version it is. Especially when the same sha is linked to multiple versions
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
Do you do some sort of versioning/snapshotting of your services? I’m on the compose route as well, and have one btrfs subvolume per service that holds the compose.yml and all bind-mounted folders for perstistent data. That again gets regularly snapshotted by snapper.
What leaves me a bit astounded is, that nobody seems to version the containers they are running. But without that, rolling back if something breaks might become a game of guessing the correct container version. I started building a tool that snapshots a service, then rewrites the
image:in compose.yml to reflect what ever the current:latesttag resolves to. Surprisingly, there doesn’t seem to be an off-the-shelf solution for that…I don’t do a great job of this, but take Immich for example. There, I specify the version in the compose.yml (technically, the version is in the .env file and substituted into the compose.yml). At that point, updating Immich is a matter of updating the version number and restarting the service.
These configuration files are all managed with git, so when I do these updates, I create a new commit. I just checked, and I have Forgejo pinned to a specific version in its compose.yml as well. But unfortunately, the other services are referencing
:latest. I’m going to go back and pin them all :)I built a small tool that does that for me now and published it: https://feddit.de/post/2909288 maybe you’ll find it useful, no guarantee that it doesn’t break something though :D
How do you do that? I’m building a similar system now that automatically updates my containers. I’ve played around with the API and I can see which versions are attached to the latest sha265, but I can’t find a way to automatically tell which version it is. Especially when the same sha is linked to multiple versions
I only keep track of the sha256, compose happily uses those. I published the tool https://feddit.de/post/2909288 :)
Ah ok. I thought you meant the numbered version. I’m doing the same with sha256 too.