Should I move to Docker?
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?
I would absolutely look into it. Many years ago when Docker emerged, I did not understand it and called it "Hipster shit". But also a lot of people around me who used Docker at that time did not understand it either. Some lost data, some had servicec that stopped working and they had no idea how to fix it.
Years passed and Containers stayed, so I started to have a closer look at it, tried to understand it. Understand what you can do with it and what you can not. As others here said, I also had to learn how to troubleshoot, because stuff now runs inside a container and you don´t just copy a new binary or library into a container to try to fix something.
Today, my homelab runs 50 Containers and I am not looking back. When I rebuild my Homelab this year, I went full Docker. The most important reason for me was: Every application I run dockerized is predictable and isolated from the others (from the binary side, network side is another story). The issues I had earlier with my Homelab when running everything directly in the Box in Linux is having problems when let´s say one application needs PHP 8.x and another, older one still only runs with PHP 7.x. Or multiple applications have a dependency of a specific library when after updating it, one app works, the other doesn´t anymore because it would need an update too. Running an apt upgrade was always a very exciting moment... and not in a good way. With Docker I do not have these problems. I can update each container on its own. If something breaks in one Container, it does not affect the others.
Another big plus is the Backups you can do. I back up every docker-compose + data for each container with Kopia. Since barely anything is installed in Linux directly, I can spin up a VM, restore my Backups withi Kopia and start all containers again to test my Backup strategy. Stuff just works. No fiddling with the Linux system itself adjusting tons of Config files, installing hundreds of packages to get all my services up and running again when I have a hardware failure.
I really started to love Docker, especially in my Homelab.
Oh, and you would think you have a big resource usage when everything is containerized? My 50 Containers right now consume less than 6 GB of RAM and I run stuff like Jellyfin, Pi-Hole, Homeassistant, Mosquitto, multiple Kopia instances, multiple Traefik Instances with Crowdsec, Logitech Mediaserver, Tandoor, Zabbix and a lot of other things.
Docker is amazing, you are late to the party :)
It's not a fad, it's old tech now.
I’m gonna play devil’s advocate here.
You should play around with it. But I’ve been a Linux server admin for a long time and — this might be unpopular — I think Docker is unimportant for your situation. I use Docker daily at work and I love it. But I didn’t bother with it for my home server. I’ll never need to scale it or deploy anything repeatedly or where I need 100% uptime.
At home, I tend to try out new things and my old docker-compose files are just not that valuable. Docker is amazing at work where I have different use cases but it mostly just adds needless complexity on a home server.
I'm a VMware and Windows admin in my work life. I don't have extensive knowledge of Linux but I have been running Raspberry Pis at home. I can't remember why but I started to migrate away from installed applications to docker. It simplifies the process should I need to reload the OS or even migrate to a new Pi. I use a single docker-compose file that I just need to copy to the new Pi and then run to get my apps back up and running.
linuxserver.io make some good images and have example configs for docker-compose
If you want to have a play just install something basic, like Pihole.
I started using docker myself for stuff at home and I really liked it. You can create a setup that's easy to reproduce or just download.
Easy to manage via docker CLI, one liner to run on startup unless stopped, tons of stuff made for docker becomes available. For non docker things you can always login to the container.
Tasks such as running, updating, stopping, listing active servers, finding out what ports are being used and automation are all easy imo.
You probably have something else you use for some/all of these tasks but docker makes all this available to non-sysadmin people and even has GUI for people who like clicking their mouse.
I think next time you find something that provides a docker compose file you should try it. :)
Hi, also used to be a sysadmin and I like things that are simple and work. I like Docker.
Besides what you already noticed (that most software can be found packaged for Docker) here are some other advantages:
- It's much lighter on resources and efficient than virtual machines.
- It provides a way to automate installs (docker compose) that's (much) easier to get started with than things like Ansible.
- It provides a clear separation between configuration, runtime, and persistent data and forces you to get organized.
- You can group related services.
- You can control interdependencies, privileges, shared access to resources etc.
- You can define simple or complex virtual networking topologies between containers as you like.
- It adds extra security (for whatever that's worth to you).
A brief description of my own setup, for ideas, feel free to ask questions:
- Router running OpenWRT + server in a regular PC.
- Server is 32 MB of RAM (bit overkill for now, black Friday upgrade, ran with 4 GB for years), Intel CPU with embedded GPU, OS on M.2 SSD, 8 HDD bays in Linux software RAID (MD).
- OS is Debian stable barebones, only Docker, SSH and NFS are installed on the host directly. Tip: use whatever Linux distro you know and like best.
- Docker is installed from their own repository, not from Debian's.
- Everything else runs from docker containers, including things like CUPS or Samba.
- I define all containers with compose, and map all persistent data to host storage. This way if I lose a container or even the whole OS I just re-provision from compose definitions and pick up right where I left off. In fact destroying and recreating containers cleanly is common practice with docker.
Learning docker and compose is not very hard esp. if you were on the job.
If you have specific requirements eg. storage, exposing services over internet etc. please ask.
Note: don't start with Podman or rootless Docker, start with regular Docker. It will be 10x easier. You can transition to the others later if you want.
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.
- 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.
- 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.
- 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).
- 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.
Docker is great. I learned it from aetting up an Openmediavault server that had a built in docker extension, so now lots of servers running off that one server. Also portainer can be very handy for working with containers , basically a gui for the command line stuff or compose files you'd normally use in docker cli
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.
Yes
As a casual self-hoster for twenty years, I ran into a consistent pattern: I would install things to try them out and they’d work great at first; but after installing/uninstalling other services, updating libraries, etc, the conflicts would accumulate until I’d eventually give up and re-install the whole system from scratch. And by then I’d have lost track of how I installed things the first time, and have to reconfigure everything by trial and error.
Docker has eliminated that cycle—and once you learn the basics of Docker, most software is easier to install as a container than it is on a bare system. And Docker makes it more consistent to keep track of which ports, local directories, and other local resources each service is using, and of what steps are needed to install or reinstall.
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:
- 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.
- 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.
- consider podman over docker. The former does not run as root.
My vote: not if you can avoid it.
For casual home admins docker containers are mysterious black boxes that are difficult to configure and even worse to inspect and debug.
I prefer lightweight VMs hosting one or more services on an OS I understand and control (in my case Debian stable), and only use docker images as a way to quickly try out something new before commiting time to deploying it properly.
You should try it.
If you decide to use docker-compose.yml files, which I do recommend, then I'd also highly recommend this script for updating the docker containers.
It checks each container for updates and then let's you select the containers you would like to update. I just keep it in the main directory with all the other docker container directories.
Also consider Nix/NixOS, I have used Docker, Kubernetes, LXC and prefer Nix the most. Especially for home use not requiring any scaling.
Yes, you should. I would look into docker compose as it makes deployments very easy.
Are you familiar with lxc or chroots or bsd jails by any chance? If you are, you probably won't find docker that much different to use other than a bigger selection of premade images.
It is kind of sad that some projects are trending towards docker first, but I think learning how to make packages for package managers is also becoming less popular :(
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.
LXC with cloud-init and ansible on proxmox gives you docker features without the docker headache.
Docker is a QoL improvement over plain VMs/LXCs if you want easy-to-go content/FOSS applications bubdled into a system.
I would personally use Podman since Docker uses root by default, and Podman doesn't (there's options for both, just FYI), and Ansible/Terraform have made IaC a breeze (ah, the good days of orchestration), but I will never use Docker because of the company behind them and because of convoluted Docker networking that I can't be arsed to learn. Other than that, have fun! This is just my opinion anyway
It's quite easy to use once you get the hang of it. In most situations, it's the prefered option because you can just have your docker container, choose where relevant files are allowing you to properly isolate your applications. Or on single purpose servers, it makes deployment of applications and maintaining dependencies significantly easier.
At the very least, it's a great tool to add to your toolbox to use as needed.I am running all my software services with docker. It's stupid simple to manage and I have all of my running services in one paradigm.
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.
Ive worked in enterprise and government as a software engineer and docker has been the defacto standard everywhere since at least 5 years now. It's not going away soon.
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.
It's convenient. Can't hurt to get used to it, for sure, in that it's useful to not have to go through dependency hell installing things sometimes. It's based on kernel features I don't see Linus pulling out, so I think you'll only see it more.
As someone who runs nix-only at home, I mostly use its underlying tech in the form of snaps/flatpaks, though. I use docker itself at work constantly, but at home, snaps/flatpaks tend to do the "minimize thinking about dependencies and building" bit but in a workflow more convenient for desktop applications.
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.
Yes. Let me give you an example on why it is very nice: I migrated one of my machines at home from an old x86-64 laptop to an arm64 odroid this week. I had a couple of applications running, 8 or 9 of them, all organized in a docker compose file with all persistent storage volumes mapped to plain folders in a directory. All I had to do was stop the compose setup, copy the folder structure, install docker on the new machine and start the compose setup. There was one minor hickup since I forgot that one of the containers was built locally but since all the other software has arm64 images available under the same name, it just worked. Changed the host IP and done.
One of the very nice things is the portability of containers, as well as the reproducibility (within limits) of the applications, since you divide them into stateless parts (the container) and stateful parts (the volumes), definitely give it a go!
Welcome to Docker! It's fucking awesome! One thing to remember is:
PLEASE setup root-less Docker. It's safer, easier [no sudo all the fking time.], and literally zero downsides other than the initial configuration -- but the Docker docs are amazing and they have every distro on there. It's only a few more steps and you can sleep secure in the fact that even in the WORST case scenario [compromised to root], they still only have a container running in userspace.
As someone who is not a former sysadmin and only vaguely familiar with *nix, I’ve been able to turn my home NAS (bought strictly to hold photos and videos backed up from our phones) into a home media sever by installing Docker, learning how the yml files work, how containers network, etc, and it’s been awesome.
Definitely not a fad. It's used all over the industry. It gives you a lot more control over the environment where your hosted apps run. There may be some overhead, but it's worth it.
Yeh, I'm not a system admin in any meaning of the word, but docker is so simple that even I got around to figuring it out and to me it just exists to save time and prevent headaches (dependency hell)
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.
I hate it very much. I am sure it is due to my limited understanding of it, but I've been stuck on some things that were very easy for me using VM.
We have two networks, one of which has very limited internet connectivity, behind proxy. When using VMs, I used to configure everything: code, files, settings on a machine with no restrictions; shut it down; move the VM files to the restricted network; boot and be happily on my way.
I'm unable to make this work with docker. Getting my Ubuntu server fetch its updates behind proxy is easy enough; setting it for python Pip is another level; realising the specific python libraries need special keys to work around proxies is yet another; figuring out how to get it done for Docker and python under it is when I gave up. Why can it not be as simple as the VM!
Maybe I'm not looking using the right terms or maybe I should go and learn docker "properly", but there is no doubt that using Docker is much more difficult for my use case than using VMs.
Some people seem to hate on it, but I love Docker, it works well for what it has to do and has relatively low overhead as far as I can tell. I personally virtualize a Debian server on Proxmox for my containers just so as to keep everything even more compartmentalized, but it takes more work than it's worth to set up.
And if you don't like Docker for whatever reason, you can also try Podman which is API compatible with Docker for the most part.
There are teachings I have read/ discovered through YouTube (can't remember exactly where) about the reasons and the philosophy behind moving to docker, or having it as a state machine.
Have you considered looking into dockers alternatives, also ?
Here is 1 of the sources that may give you insights:
https://www.cloudzero.com/blog/docker-alternatives/
-- There has been some concerns over docker's licensing and, as such, some people have started preferring solutions such as podman and containerd.
Both are good in terms of compatibility and usability, however I have not used them extensively.
Nonetheless, I am currently using docker for my own hyperserver [Edit2: oops, I meant hypervisor ✓, not hyperserver] purposes. And I am also a little concerned about the future of docker, and would consider changing sometime in the future.
[Edit1: I am using docker because it is easy to make custom machines, with all files configurations, and deploy them that way. It is a time saver. But performance wise, I would not recommend it for major machines that contain major machine processes and services. And that's just the gist of it].
Yeah; go for it.
From a "self-hosted" perspective I moved everything to Docker a few years ago, and now updates are easy to do and I can format everything except my home partition and then re-install. Everything in Docker comes right back up from just having a few text files kicking around my home partition / directory. They're all plain-text and co-located so I can version control them in git.
Only problem I had with Docker was when I had to try to get hardware encoding / decoding working for Plex, and even that was ultimately not much work.
Don't learn Docker, learn containers. Docker is merely one of the first runtimes, and a rather shit one at that (it's a bunch of half-baked projects - container signing as one major example).
Learn Kubernetes, k3s is probably a good place to start. Docker-compose is simply a proprietary and poorly designed version of it. If you know Kubernetes, you'll quickly be able to pick up docker-compose if you ever need to.
You can use
buildah bud(part of the Podman ecosystem) to build containerfiles (exactly the same thing as dockerfiles without the trademark). Buildah can also be used without containerfiles (your containerfiles simply becomes a script in the language of your choice - e.g. bash), which is far more versatile. Speaking of Podman, if you want to keep things really simple you can manually create a bunch of containers in a pod and then ask Podman to create a set of systemd units for you. Podman supports nearly all of what docker does (with exception to docker's bjorked signing) and has identical command line syntax. Podman can also host a docker-compatible socket if you need to use it with something that really wants docker.I'm personally a big fan of Podman, but I'm also a fan of anything that isn't Docker: LXD is another popular runtime, and containerd is (IIRC) the runtime underpinning docker. There's also firecracker or kubevirt, which go full circle and let you manage tiny VMs like containers.
I am a network engineer and I am learning it. I see it in the next step from the bare metal -> virtualisation evolution
Dear God yes. It makes life a lot easier. It's very easy to use and understand.
I have a feeling that once you've used it you'll be kicking yourself for not doing so sooner.
It's basically a vm without the drawbacks of a vm, why would you not? It's hecking awesome
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System Git Popular version control system, primarily for code HTTP Hypertext Transfer Protocol, the Web IP Internet Protocol LXC Linux Containers NAS Network-Attached Storage PIA Private Internet Access brand of VPN Plex Brand of media server package RAID Redundant Array of Independent Disks for mass storage SMTP Simple Mail Transfer Protocol SSD Solid State Drive mass storage SSH Secure Shell for remote terminal access SSL Secure Sockets Layer, for transparent encryption VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting) k8s Kubernetes container management package nginx Popular HTTP server
15 acronyms in this thread; the most compressed thread commented on today has 10 acronyms.
[Thread #349 for this sub, first seen 13th Dec 2023, 17:15] [FAQ] [Full list] [Contact] [Source code]
As someone who is operating kubernetes for 2 years in my home server, using containers is much more maintainable compared to installing everything directly on the server.
I tried using docker-compose first to manage my services. It works well for 2-3 services, but as the number of services grew they started to interfere with each other, at that point I switched to kubernetes.