Skip Navigation
Selfhosted @lemmy.world
Great Blue Heron @lemmy.ca

Should I move to Docker?

I'm a retired Unix admin. It was my job from the early '90s until the mid '10s. I've kept somewhat current ever since by running various machines at home. So far I've managed to avoid using Docker at home even though I have a decent understanding of how it works - I stopped being a sysadmin in the mid '10s, I still worked for a technology company and did plenty of "interesting" reading and training.

It seems that more and more stuff that I want to run at home is being delivered as Docker-first and I have to really go out of my way to find a non-Docker install.

I'm thinking it's no longer a fad and I should invest some time getting comfortable with it?

218 comments

  • Docker is amazing, you are late to the party :)

    It's not a fad, it's old tech now.

  • No. (Of course, if you want to use it, use it.) I used it for everything on my server starting out because that's what everyone was pushing. Did the whole thing, used images from docker hub, used/modified dockerfiles, wrote my own, used first Portainer and then docker-compose to tie everything together. That was until around 3 years ago when I ditched it and installed everything normally, I think after a series of weird internal network problems. Honestly the only positive thing I can say about it is that it means you don't have to manually allocate ports for those services that can't listen on unix sockets which always feels a bit yucky.

    1. A lot of images comes from some random guy you have to trust to keep their images updated with security patches. Guess what, a lot don't.
    2. Want to change a dockerfile and rebuild it? If it's old and uses something like "ubuntu:latest" as a base and downloads similar "latest" binaries from somewhere, good luck getting it to build or work because "ubuntu:latest" certainly isn't the same as it was 3 years ago.
    3. Very Linux- and x86_64-centric. Linux is of course not really a problem (unless on Mac/Windows developer machines, where docker runs a Linux VM in the background, even if the actual software you're working on is cross-platform. Lmao.) but I've had people complain that Oracle Free Tier aarch64 VMs, which are actually pretty great for a free VPS, won't run a lot of their docker containers because people only publish x86_64 builds (or worse, write dockerfiles that only work on x86_64 because they download binaries).
    4. If you're using it for the isolation, most if not all of its security/isolation features can be used in systemd services. Run systemd-analyze security UNIT.

    I could probably list more. Unless you really need to do something like dynamically spin up services with something like Kubernetes, which is probably way beyond what you need if you're hosting a few services, I don't think it's something you need.

    If I can recommend something instead if you want to look at something new, it would be NixOS. I originally got into it because of the declarative system configuration, but it does everything people here would usually use Docker for and more (I've seen it described it as "docker + ansible on steroids", but uses a more typical central package repository so you do get security updates for everything you have installed, and your entire system as a whole is reproducible using a set of config files (you can still build Nix packages from the 2013 version of the repository I think, they won't necessarily run on modern kernels though because of kernel ABI changes since then). However, be warned, you need to learn the Nix language and NixOS configuration, which has quite a learning curve tbh. But on the other hand, setting up a lot of services is as easy as adding one line to the configuration to enable the service.

  • Learn it first.

    I almost exclusively use it with my own Dockerfiles, which gives me the same flexibility I would have by just using VM, with all the benefits of being containerized and reproducible. The exceptions are images of utility stuff, like databases, reverse proxy (I use caddy btw) etc.

    Without docker, hosting everything was a mess. After a month I would forget about important things I did, and if I had to do that again, I would need to basically relearn what I found out then.

    If you write a Dockerfile, every configuration you did is either reflected by the bash command or adding files from the project directory to the image. You can just look at the Dockerfile and see all the configurations made to base Debian image.

    Additionally with docker-compose you can use multiple containers per project with proper networking and DNS resolution between containers by their service names. Quite useful if your project sets up a few different services that communicate with each other.

    Thanks to that it's trivial to host multiple projects using for example different PHP versions for each of them.

    And I haven't even mentioned yet the best thing about docker - if you're a developer, you can be sure that the app will run exactly the same on your machine and on the server. You can have development versions of images that extend the production image by using Dockerfile stages. You can develop a dev version with full debug/tooling support and then use a clean prod image on the server.

  • Similar story to yours. I was a HP-UX and BSD admin, at some point in the 00s, I stopped self-hosting. Felt too much like the work I was paid to do in the office.

    But then I decided to give it a go in the mid-10s, mainly because I was uneasy about my dependence on cloud services.

    The biggest advantage of Docker for me is the easy spin-up/tear-down capability. I can rapidly prototype new services without worrying about all the cruft left behind by badly written software packages on the host machine.

  • It's very, very useful.

    For one thing, its a ridiculously easy way to get cross-distro support working for whatever it is you're doing, no matter the distro-specific dependency hell you have to crawl through in order to get it set up.

    For another, rather related reason, it's an easy way to build for specific distros and distro versions, especially in an automated fashion. Don't have to fuck around with dual booting or VMs, just use a Docker command to fire up the needed image and do what you gotta do.

    Cleanup is also ridiculously easy too. Complete uninstallation of a service running in Docker simply involves removal of the image and any containers attached to it.

    A couple of security rules you should bear in mind:

    1. expose only what you need to. If what you're doing doesn't need a network port, don't provide one. The same is true for files on your host OS, RAM, CPU allocation, etc.
    2. never use privileged mode. Ever. If you need privileged mode, you are doing something wrong. Privileged mode exposes everything and leaves your machine ripe for being compromised, as root if you are using Docker.
    3. consider podman over docker. The former does not run as root.

  • Also consider Nix/NixOS, I have used Docker, Kubernetes, LXC and prefer Nix the most. Especially for home use not requiring any scaling.

  • IMO, yes. Docker (or at least OCI containers) aren't going anywhere. Though one big warning to start with, as a sysadmin, you're going to be absolutely aghast at the security practices that most docker tutorials suggest. Just know that it's really not that hard to do things right (for the most part[^0]).

    I personally suggest using rootless podman with docker-compose via the podman-system-service.

    Podman re-implements the docker cli using the system namespacing (etc.) features directly instead of through a daemon that runs as root. (You can run the docker daemon rootless, but it clearly wasn't designed for it and it just creates way more headaches.) The Podman System Service re-implements the docker daemon's UDS API which allows real Docker Compose to run without the docker-daemon.

    [^0]: If anyone can tell me how to set SELinux labels such that both a container and a samba server can have access, I could fix my last remaining major headache.

      I don't know if this is what you are looking for but I used :z with podman mounting and it Just Works*.

      podman run -d -v /dir:/var/lib/dir:z image

      From the documentation :z or :Z relabels volumes for host and container usage depending.

      • Unfortunately, no. Samba needs a different label. Doing that relabels things so that only containers (and anything unrestriced) can access those files.

  • Learning docker is always a big plus. It's not hard. If you are comfortable with cli commands, then it should be a breeze. Even if you are not comfortable, you should get used to it very fast.

  • I was like you and avoided it for a long time. Dedicated use, lean VMs for each thing I was running. I decided to learn it, mostly out of curiosity and I'll be honest, I like the convenience of it a lot. They're easier to deploy and tend to have lower overhead than a single purpose VM running the same software.

    Around the same time I switched my VM server over to Proxmox and learned about LxC containers. Those are also pretty nifty and a nice middle ground between full VM and docker container.

    Currently I have a mixed environment because I like to use my homelab to learn, but most new stuff I deploy tends to go in this order: Docker > LxC > full VM.

  • Docker is nice for things that have complex installations and I want a very specific implementation that I don't plan to tweak very much. Otherwise, it's more hassle than it's worth. There are lots of networking issues like limited/experimental support for IPv6, and too much is hidden and preconfigured, making it difficult to make adjustments that would otherwise just be a config file change.

    So it is good for products like a mail server where you want to use the exact software they use like let's say postfix + dovecot + roundcube + nginix + acme + MySQL + spam assassin + amavisd, etc. But you want to use an existing reverse proxy and cert it setup, or want to use a different spam filter or database and it becomes a huge hassle.

  • I think it's a good tool to have on your toolbelt, so it can't hurt to look into it.

    Whether you will like it or not, and whether you should move your existing stuff to it is another matter. I know us old Unix folk can be a fussy bunch about new fads (I started as a Unix admin in the late 90s myself).

    Personally, I find docker a useful tool for a lot of things, but I also know when to leave the tool in the box.

  • Try other container technologies lie LXC or go right side and play with FreeBSD jails. Quality of dockers you can find around is horrendous, giving that Docker itself build for convenience not security. It is not something I will trust.

    • There's nothing wrong with OCI Images. If you're concerned about the security of Docker (which, imo, you should be) there are other container runtimes that don't have its security tradeoffs (e.g. podman).

    • Once I got to the point where I was running a ton of containers I'd occasionally have issues where a maintainer wouldn't resolve issues fast enough for my liking so I started building more containers myself which was a lot easier than I'd anticipated.

218 comments