this post was submitted on 11 Mar 2024
155 points (95.3% liked)

Selfhosted

40438 readers
691 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
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
155
What's the deal with Docker? (self.selfhosted)
submitted 8 months ago by AlexPewMaster to c/[email protected]
98 comments fedilink hide all child comments
 

I never understood how to use Docker, what makes it so special? I would really like to use it on my Rapsberry Pi 3 Model B+ to ease the setup process of selfhosting different things.

I'm currently running these things without Docker:

  • Mumble server with a Discord bridge and a music bot
  • Maubot, a plugin-based Matrix bot
  • FTP server
  • Two Discord Music bots

All of these things are running as systemd services in the background. Should I change this? A lot of the things I'm hosting offer Docker images.

It would also be great if someone could give me a quick-start guide for Docker. Thanks in advance!

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 15 points 8 months ago* (last edited 8 months ago) (1 children)

When I asked this question

So there are many reasons, and this is something I nowadays almost always do. But keep in mind that some of us have used Docker for our applications at work for over half a decade now. Some of these points might be relevant to you, others might seem or be unimportant.

  • The first and most important thing you gain is a declarative way to describe the environment (OS, dependencies, environment variables, configuration).
  • Then there is the packaging format. Containers are a way to package an application with its dependencies, and distribute it easily through the docker hub (or other registries). Redeploying is a matter of running a script and specifying the image and the tag (never use latest) of the image. You will never ask yourself again "What did I need to do to install this again? Run some random install.sh script off a github URL?".
  • Networking with docker is a bit hit and miss, but the big thing about it is that you can have whatever software running on any port inside the container, and expose it on another port on the host. Eg two apps run on port :8080 natively, and one of them will fail to start due to the port being taken. You can keep them running on their preferred ports, but expose one on 18080 and another on 19080 instead.
  • You keep your host simple and empty of installed software and packages. Less of a problem with apps that come packaged as native executables, but there are languages out there which will require you to install a runtime to be able to start the app. Think .NET, Java but there is also Python out there which requires you to install it on the host and have the versions be compatible (there are virtual environments for that but im going into too much detail already).

I am also new to self hosting, check my bio and post history for a giggle at how new I am, but I have taken advantage of all these points. I do use "latest" though, looking forward to seeing how that burns me later on.

But to add one more:- my system is robust, in that I can really break my containers (and I do), and to recover is a couple clicks in Portainer. Then I can try again, no harm done.

[–] [email protected] 4 points 8 months ago (2 children)

The thing with using the "latest" tag is you might get lucky and nothing bad happens (the apps are pretty stable, fault tolerant, and/or backward compatible), but you also might get unlucky and a container update does break something (think a 1.x going to 2.x one day). Without pinning the container to a specific version, you might have an outage suddenly due to that container becoming incompatible with one of your other applications. I've seen this happen a number of times. One example is a frontend (UI) container that updates to no longer be compatible with older versions of the backend and crashes as a result.

If all your apps are pretty much standalone and you trust them to update properly every time a new version of the container is downloaded, then you may never run into the problems that make people say "never use latest". But just keep an eye out for something like that to happen at some point. You'll save yourself some time if you have records of what versions are running when everything's working, and take regular backups of all their data.

[–] [email protected] 2 points 8 months ago* (last edited 8 months ago)

I guessed it was a "once bitten twice shy" kind of thing. This is all a hobby to me so the cost-benefit, I think, is vastly different, nothing on my setup is critical. Keeping all those records and up to date on what version everything is on, and when updates are available and what those updates do and... sound like a whole lot of effort when currently my efforts can be better spent in other areas.

In my arrogance I just installed Watchtower, and accepted it can all come crashing down. When that happens I'll probably realise it's not so much effort after all.

That said I'm currently learning, so if something is going to be breaking my stuff, it's probably going to be me and not an update. Not to discredit your comment, it was informative and useful.

[–] [email protected] 2 points 8 months ago

I used to have this with homeassistant and zwavejs. Every time I'd pull a new homeassistant, the zwave integration would fail, because it required a newer version of zwavejs. Taught me to build the chain of services into one docker-compose, so they'd all update together. That's become one of the rationales for me to use docker: got a chain of dependent processes? wrap them in a docker so you're working with (probably) the same dependencies as the devs.

My other rationale is just portability, and docker is just one of many solutions there. In my little home environment, where servers are either retired desktops or gee-that-seems-cool SBCs, it's nice to be able to easily move stuff independent of architecture or OS.