Containers, the concept that Docker implements, lets app developers give a self-contained environment for distribution. For devs that means consistency in deployments across environments, which in turn means sysadmins can deploy each of these apps as fully isolated units.

With that, you get really clean installs/updates/uninstalls, and your deployments get done with a well-defined, declarative definition file which can also handle multi service dependencies (a la Docker Compose/K8s)

I could go in-depth, but really, the best way I can describe my docker usage is as a simple and agnostic service manager. Let me explain.

Docker is a container system. A container is essentially an operating system installation in a box. It’s not really a full installation, but it’s close enough that understanding it like that is fine.

So what the service devs do is build a container (operating system image) with their service and all the required dependencies - and essentially nothing else (in order to keep the image as small as possible). A user can then use Docker to run this image on their system and have a running service in just a few terminal commands. It works the same across all distributions. So I can install whatever distro I need on the server for whatever purpose and not have to worry that it won’t run my Docker services. This also means I can test services locally on my desktop without messing with my server environment. If it works on my local Docker, it will work on my server Docker.

There are a lot of other uses for it, like isolated development environments and testing applications using other Linux distro libraries, to name a couple, but again, I personally mostly just use it as a simple service manager.

tldr + eli5 - App devs said “works on my machine”, so Docker lets them ship their machine.

It’s useful for every service you want to host (on a server).

For me the advantage of Docker is that a random update to my system is unlikely to crash my self hosted services. It simplifies setting up the services as well but the biggest advantage is that it is generally more stable.

its a container system that saves you from dealing with interactions between server software, config files scattered everywhere and is even more secure and more portable.

it helps you use 1 server for many services without issues, being able to redeploy a given service without issues whenever needed.

its a bit counter intuitive to learn, but makes it plain easier and almost maintenance free to run a server if you set up things right.

So it’s always going to be used for technical things, but not necessarily development things. I use it for both.

For my home server setup I have docker setup like this:

1. A VPN docker container
2. A transmission (bittorrent client) container, using the VPN’s network
3. An nginx (web server) container, which provides access to the transmission container
4. A 3proxy socks proxy container, using the VPN’s network
5. A tor client container
6. A 3proxy socks proxy container, using the tor container’s network

Usually it’s pretty hard to say “these specific programs and only these should run over my VPN”. Docker makes that easy. I can just attach containers to the same network as my VPN container, and their traffic will all go over the VPN. And then with my socks proxies I can selectively put my browser traffic over either the VPN or Tor, using extensions like FoxyProxy. I watch wrestling through my vpn because it’s cheaper overseas and has better streaming options, so I have those specific sites set to route through my VPN socks proxy. And I have all onion links set to go through my Tor proxy.

https://lemmy.world/post/12995686 was a recent question and most of the answers will basically be duplicates of that.

One slight addition I want to add: “Docker” is just one implementation of “OCI containers”. It’s the one that broke through initially in the hype, but you can just as easily use any other (podman being a popular one) and basically all of the benefits that people ascribe to “docker” can be applied to.

So you might (as I do) have some dislike for docker (the product) and still enjoy running containers.

In simple terms, it’s like a VM for an application. You set it up with the right dependencies and your application will “just work” on it, without having to deal with other applications existing alongside it.

What makes it better than a VM is that it is much faster. It interfaces with kernel features that help isolate the processes and files from the rest of the system. It is not virtualization, rather it is namespacing.

Docker also provides a bunch of tools that help with creating this environment automatically and allowing for some escaping into the host, such as binding ports and sharing data with the host’s file system.

Once this environment is created, it can be shared with uses as a single downloadable bundle, called an image. This makes it really easy to download and run an application without having to prepare your system with the right dependencies and files.

Nothing is free though, and the cost here is more disk space and some performance overhead, although it is close to native speed.

The thing with self hosting is that you want in most cases, to set and forget and that means you want as little going wrong as possible. To ensure that, you need to find a way that other things can’t fuck with what you’re hosting. This is called a container. The trade off is disk space, but that’s okay because it’s a server, unlike on a computer, but let me not start my rant about the stupidity of Snap and Flatpak. Anyway… Thanks to containers, you don’t have any external factors and basically everything runs in its own world. Which means you can always delete, restore and edit without anything else being affected.

Wondering too, since Docker has a non-root mode, is there a reason to use Podman?

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

5 acronyms in this thread; the most compressed thread commented on today has 7 acronyms.

[Thread #610 for this sub, first seen 17th Mar 2024, 20:35] [FAQ] [Full list] [Contact] [Source code]

Two things, one you care about and one you might not. The one you care about: you can set up a service in isolation. You can then test it, make sure it works, and switch over to it once you are sure, with almost no downtime. This is important for things you actually need to use. Once you do something like breaking your primary email server, you will understand. Also, less important, you can set up a service on, say, a VM at home, and move it to a VPS, without having to transfer the entire image, and it will work the same. The one you don’t care about. That last bit about moving servers around is important for cloud providers who turn these things on and off all the time.

Docker is great because you can install something and all the shit it needs is installed and runs in that container. It’s good for a multitude of reasons mine are:

1. No more installing a dependency, tool or library alongside a program that fucks up something else. No more shit breaking because you installed the latest python but some other program breaks if you move beyond 3.10 (and you forgot to use venv I guess).
2. Somewhat a follow on from 1 but this makes for great functionality with self hosting. I can run a couple docker compose/build command and build/rebuild the containers anywhere I need them. I can test a container on a windows computer to see if it does what I want and works as intended and then spin the some container up on my media server, even if it’s a different OS. I have a bunch of them on my home server and it and it’s great being able to just plug in the port number of the other containers they need to talk to, if any, and that’s all. One container breaking doesn’t break everything else.

In the context of self-hosted it means easier cleaner installs and avoiding different poorly packaged projects from interfering with each other.