Selfhosted

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.

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

Docker is a container manager, but that doesn't say anything if you don't know what containers are.

Containers are basically isolated apps. For example, take something like Nextcloud. Nextcloud can run in a Docker container, which means that it runs in an isolated environment completely separated from the user's system. If Nextcloud breaks, the user's server won't be affected at all, because it's running isolated.

Why is this useful? Well, it's useful because dependencies and such automatically update. Nextcloud for example, is dependent on PHP and if you install Nextcloud directly on your server, you'll need to ensure that PHP 8 has been installed and set up properly. If PHP (or the required PHP extensions) aren't properly installed, Nextcloud won't work. Or, maybe if there's a Nextcloud update that requires a new version of PHP (PHP 9 or 10 in the future), you'll have to manually update PHP to the newer version.

All that dependency management is completely gone with containers. The container itself automatically installs and sets up a proper environment for the app that's running. So in the case of Nextcloud, the PHP binaries, extensions, and all the other stuff is all automatically included without the developer having to do anything at all. Just run one command and your entire Nextcloud instance is automatically updated.

My company deploys a lot of cell modems. Some of them support containers. It’s really nice to deploy everything we need in one piece of equipment, as opposed to 2 or more, for a very simple application.

Several other pieces of network equipment support it now as well. A SIEM can run a remote node directly on a switch.

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.

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)

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

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

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

To bloat things, to lower the bar to newcomers, to appease the business goals of large cloud companies and eventually to provide some isolation, security and create stateless environments: https://lemmy.world/comment/8341439