this post was submitted on 12 Dec 2024
46 points (81.9% liked)

Selfhosted

40708 readers
588 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 posting.

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

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

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

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

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

Hello! πŸ˜€
I want to share my thoughts on docker and maybe discuss about it!
Since some months I started my homelab and as any good "homelabing guy" I absolutely loved using docker. Simple to deploy and everything. Sadly these days my mind is changing... I recently switch to lxc containers to make easier backup and the xperience is pretty great, the only downside is that not every software is available natively outside of docker πŸ™ƒ
But I switch to have more control too as docker can be difficult to set up some stuff that the devs don't really planned to.
So here's my thoughts and slowly I'm going to leave docker for more old-school way of hosting services. Don't get me wrong docker is awesome in some use cases, the main are that is really portable and simple to deploy no hundreds dependencies, etc. And by this I think I really found how docker could be useful, not for every single homelabing setup, and it's not my case.

Maybe I'm doing something wrong but I let you talk about it in the comments, thx.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 6 points 1 week ago (1 children)

For real. Map persistent data out and then just docker compose pull && up. Theres nothing to it. Regular backups make reverting to previous container versions a breeze

[–] [email protected] 0 points 1 week ago (1 children)

For one, if the compose file syntax or structure and options changes (like it did recently for immich), you have to dig through github issues to find that out and re-create the compose with little guidance.

Not docker's fault specifically, but it's becoming an issue with more and more software issued as a docker image. Docker democratizes software, but we pay the price in losing perspective on what is good dev practice.

[–] [email protected] 1 points 1 week ago* (last edited 1 week ago) (1 children)

Since when is checking for breaking changes a problem? You should do that every time you want to update. The Immich devs make a real good informing bout those and Immich in general is a bad example since it is still in so early and active development.

And if updating the compose file every once in a new moon is a hassle to you, I don't want to know how you react when you have to update things in more hidden or complicated configs after an update

[–] [email protected] 0 points 1 week ago

I'm trying to indicate that docker has its own kinds of problems that don't really occur for software that isn't containerized.

I used the immich issue because it was actually NOT indicated as a breaking change by the devs, and the few of us who had migrated the same compose yml from older veraions and had a problem were met with "oh, that is a very old config, you should be using the modern one".

Docker is great, but it comes with some specific understanding that isn't necessarily obvious.