this post was submitted on 23 Aug 2023
91 points (96.0% liked)

Selfhosted

59897 readers
703 users here now

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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam.

  3. Posts here are to be centered around self-hosting. Please ensure it is clear in your post how it relates to self-hosting.

  4. Don't duplicate the full text of your blog or git here. Just post the link for folks to click.

  5. Submission headline should match the article title.

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago
MODERATORS
 

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!

all 15 comments
sorted by: hot top controversial new old
[–] psmt@lemmy.pcft.eu 10 points 2 years ago (1 children)

Great post, thanks for sharing πŸ‘

I would suggest to give Ansible a try, it would make it really easy to deploy a new service with all required users and config.

[–] akdas@lemmy.world 3 points 2 years ago

That's a great point about Ansible. Compose automates most of the setup, but automating all of it would be amazing. I'll try it with the next service I set up, and if it goes well, I'll document it. Thanks for the suggestion!

[–] skilltheamps@feddit.de 6 points 2 years ago (2 children)

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...

[–] akdas@lemmy.world 1 points 2 years ago (1 children)

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 :)

[–] skilltheamps@feddit.de 2 points 2 years ago

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

[–] NewDataEngineer@lemmy.world 1 points 2 years ago (1 children)

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

[–] skilltheamps@feddit.de 1 points 2 years ago (1 children)

I only keep track of the sha256, compose happily uses those. I published the tool https://feddit.de/post/2909288 :)

[–] NewDataEngineer@lemmy.world 1 points 2 years ago

Ah ok. I thought you meant the numbered version. I'm doing the same with sha256 too.

[–] Aux@lemmy.world 4 points 2 years ago

I would recommend using Ansible to manage your containers and infrastructure in general. It has quite a steep learning curve, but it's worth it!

[–] Guajojo@lemmy.world 2 points 2 years ago

Great read, thanks for sharing

[–] Decronym@lemmy.decronym.xyz 1 points 2 years ago* (last edited 2 years ago)

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

Fewer Letters More Letters
Git Popular version control system, primarily for code
SSO Single Sign-On
VPN Virtual Private Network
VPS Virtual Private Server (opposed to shared hosting)

4 acronyms in this thread; the most compressed thread commented on today has 11 acronyms.

[Thread #76 for this sub, first seen 23rd Aug 2023, 18:55] [FAQ] [Full list] [Contact] [Source code]