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?
dude, im kinda you. i just jumped into docker over the summer... feel stupid not doing it sooner. there is just so much pre-created content, tutorials, you name it. its very mature.
i spent a weekend containering all my home services.. totally worth it and easy as pi[hole] in a container!.
Well, that wasn't a huge investment :-) I'm in..
I understand I've got LOTS to learn. I think I'll start by installing something new that I'm looking at with docker and get comfortable with something my users (family..) are not yet relying on.
Forget docker run,
docker compose up -dis the command you need on a server. Get familiar with a UI, it makes your life much easier at the beginning: portainer or yacht in the browser, lazy-docker in the terminal.I would suggest docker compose before a UI to someone that likes to work via the command line.
Many popular docker repositories also automatically give docker run equivalents in compose format, so the learning curve is not as steep vs what it was before for learning docker or docker compose commands.
There is even a tool to convert Docker Run commands to a Docker Compose file :)
Such as this one hosted by Opnxng:
https://it.opnxng.com/docker-run-to-docker-compose-converter
Second this. Portainer + docker compose is so good that now I go out of my way to composerize everything so I don’t have to run docker containers from the cli.
like just
docker runby itself, it's not the full command, you need a compose file: https://docs.docker.com/engine/reference/commandline/compose/Basically it's the same as docker run, but all the configuration is read from a file, not from stdin, more easily reproducible, you just have to store those files. The important is compose commands are very important for selfhosting, when your containers expected to run all the time.
RTFM: https://docs.docker.com/compose/
Yeah, I get it now. Just the way I read it the first time it sounded like you were saying that was a complete command and it was going to do something "magic" for me :-)
you need to create a docker-compose.yml file. I tend to put everything in one dir per container so I just have to move the dir around somewhere else if I want to move that container to a different machine. Here's an example I use for picard with examples of nfs mounts and local bind mounts with relative paths to the directory the docker-compose.yml is in. you basically just put this in a directory, create the local bind mount dirs in that same directory and adjust YOURPASS and the mounts/nfs shares and it will keep working everywhere you move the directory as long as it has docker and an available package in the architecture of the system.
`version: '3' services: picard: image: mikenye/picard:latest container_name: picard environment: KEEP_APP_RUNNING: 1 VNC_PASSWORD: YOURPASS GROUP_ID: 100 USER_ID: 1000 TZ: "UTC" ports: - "5810:5800" volumes: - ./picard:/config:rw - dlbooks:/downloads:rw - cleanedaudiobooks:/cleaned:rw restart: always volumes: dlbooks: driver_opts: type: "nfs" o: "addr=NFSSERVERIP,nolock,soft" device: ":NFSPATH"
cleanedaudiobooks: driver_opts: type: "nfs" o: "addr=NFSSERVERIP,nolock,soft" device: ":OTHER NFSPATH" `
dockge is amazing for people that see the value in a gui but want it to stay the hell out of the way. https://github.com/louislam/dockge lets you use compose without trapping your stuff in stacks like portainer does. You decide you don't like dockge, you just go back to cli and do your docker compose up -d --force-recreate .
If you are interested in a web interface for management check out portainer.
As a guy who's you before summer.
Can you explain why you think it is better now after you have 'contained' all your services? What advantages are there, that I can't seem to figure out?
Please teach me Mr. OriginalLucifer from the land of MoistCatSweat.Com
No more dependency hell from one package needing
libsomething.so 5.3.1and another service absolutely can only run withlibsomething.so 4.2.0That and knowing that when i remove a container, its not leaving a bunch of cruft behind
You can also back up your compose file and data directories, pull the backup from another computer, and as long as the architecture is compatible you can just restore it with no problem. So basically, your services are a whole lot more portable. I recently did this when dedipath went under. Pulled my latest backup to a new server at virmach, and I was up and running as soon as the DNS propagated.
Modularity, compartmentalization, reliability, predictability.
One software needs MySQL 5, another needs mariadb 7. A third service needs PHP 7 while the distro supported version is 8. A fourth service uses cuda 11.7 - not 11.8 which is what everything in your package manager uses. a fifth service's install was only tested on latest Ubuntu, and now you need to figure out what rpm gives the exact library it expects. A sixth service expects odbc to be set up in a very specific way, but handwaves it in the installation docs. A seventh program expects a symlink at a specific place that is on the desktop version of the distro, but not the server version. And then you got that weird program that insist on admin access to the database so it can create it's own user. Since I don't trust it with that, let it just have it's own database server running in docker and good riddance.
And so on and so forth.. with docker not only is all this specified in excruciating details, it's also the exact same setup on every install.
You don't have it not working on arch because the maintainer of a library there decided to inline a patch that supposedly doesn't change anything, but somehow causes the program to segfault.
I can develop a service on windows, test it, deploy it to my Kubernetes cluster, and I don't even have to worry about which machine to deploy it on, it just runs it on a machine. Probably an Ubuntu machine, but maybe on that Gentoo node instead. And if my osx friend wants to try it out, then no problem. I can just give him a command, and it's running on his laptop. No worries about the right runtime or setting up environment or libraries and all that.
If you're an old Linux admin... This is what utopia looks like.
Edit: And restarting a container is almost like reinstalling the OS and the program. Since the image is static, restarting the container removes all file system cruft too and starts up a pristine new copy (of course except the specific files and folders you have chosen to save between restarts)
It sounds very nice and clean to work with!
If I'm lucky enough to get the Raspberry 5 at Christmas, I will try to set it up with docker for all my services!
Thanks for the explanation.
Just remember that Raspberry is an ARM cpu, which is a different architecture. Docker can cross compile to it, and make multiple images automatically. It takes more time and space though, as it runs an arm emulator to make them.
https://www.docker.com/blog/faster-multi-platform-builds-dockerfile-cross-compilation-guide/ has some info about it.
It just making things easier and cleaner. When you remove a container, you know there is no leftover except mounted volumes. I like it.
It's also way easier if you need to migrate to another machine for any reason.
I use LXC for all the reasons most people use Docker, it's easy to spin up a new service, there are no leftovers when I remove a service, and everything stays separate. What I really like about LXC though is that you can treat containers like VMs, you start it up, attach and install all your software as if it were a real machine. No extra tech to learn.
Not completely true you probably have to prune some images, or volumes.
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.
The backup and easy set up on other servers is not necessarily super useful for a homelab but a huge selling point for the enterprise level. You can make a VM template of your host with docker set up in it, with your Compose definitions but no actual data. Then spin up as many of those as you want and they'll just download what they need to run the images. Copying VMs with all the images in them takes much longer.
And regarding the memory footprint, you can get that even lower using podman because it's daemonless. But it is a little more work to set things up to auto start because you have to manually put it into systemd. But still a great option and it also works in Windows and is able to parse Compose configs too. Just running Docker Desktop in windows takes up like 1.5GB of memory for me. But I still prefer it because it has some convenient features.
It seems like docker would be heavy on resources since it installs & runs everything (mysql, nginx, etc.) numerous times (once for each container), instead of once globally. Is that wrong?
You would think so, yes. But to my surprise, my well over 60 Containers so far consume less than 7 GB of RAM, according to htop. Also, of course Containers can network and share services. For external access for example I run only one instance of traefik. Or one COTURN for Nextcloud and Synapse.
Another old school sysadmin that “retired” in the early 2010s.
Yes, use docker-compose. It’s utterly worth it.
I was intensely irritated at first that all of my old troubleshooting tools were harder to use and just generally didn’t trust it for ages, but after 5 years I wouldn’t be without.
I'm a little younger but in the same boat. There is some friction having filesystems, ports and processes "hidden" from your hosts programs that you typically rely on. But I needed them sooooo much less now that all my services are in Docker with exactly matching dependencies instead of rolling my eyes about running two PostgreSQL servers in different versions or juggling Python / node / Ruby versions with ASDF.
Yeah, so worth it! The first time I moved a service to a new box and realised all I had to do was copy the compose file and
docker-compose up -d... I was sold.Now I'm moving everything to Docker Swarm which is a new adventure. :-)
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.
That's exactly how I feel about it. Except (as noted in my post..) the software availability issue. More and more stuff I want is "docker first" and I really have to go out of my way to install and maintain non docker versions. Case in point - I'm trying to evaluate Immich so I can move off Google photos. It looks really nice, but it seems to be effectively "docker only."
The advantage of docker, as I see it for home labs, is keeping things tidy, ensuring compatibility, and easy to manage/backup setup configs, app configs, and app data. It is all very predictable and manageable. I can move my docker compose and data from one host to another in literal seconds. I can, likewise, spin up and down test environments in seconds too. Obviously the whole scaling thing that people love containers for is pointless in a homelab, but many of the things that make it scalable also make it easy to manage.
Im probably the opposite of you! Started using docker at home after messing up my raspberry pi a few too many times trying stuff out, and not really knowing what the hell I was doing. Since moved to a proper nas, with (for me, at least) plenty of RAM.
Love the ability to try out a new service, which is kind of self-documenting (especially if I write comments in the docker-compose file). And just get rid of it without leaving any trace if it's not for me.
Added portainer to be able to check on things from my phone browser, grafana for some pretty metrics and graphs, etc etc etc.
And now at work, it's becoming really, really useful, and I'm the only person in my (small, scientific research) team who uses containers regularly. While others are struggling to keep their fragile python environments working, I can try out new libraries, take my env to the on-prem HPC or the external cloud, and I don't lose any time at all. Even "deployed" some little utility scripts for folks who don't realise that they're actually pulling my image from the internal registry when they run it. A much, much easier way of getting a little time-saving script into the hands of people who are forced to use Linux but don't have a clue how to use it.
This is kinda where I'm at as well. I have always run my home services each in their own VM. There's no fuss to set up a new one, if I want to move it to a different server I just copy the *.img file over and launch it. Sure I run a lot of internet services across my various machines but it all just works so I don't understand what purpose there would be to converting all the custom configurations over to docker. It might make sense if I was trying to run all my services directly on the bare metal, but who does that?
VM's have much bigger overhead, for one. And VM's are less reproducible too. If you had to set up a VM again, do you have all the steps written down? Every single step? Including that small "oh right" thing you always forget? A Dockerfile is basically just a list of those steps, written in a way a computer can follow. And every time you build an image in docker, it just plays that list and gives you the resulting file system ready to run.
It's incredibly practical in some cases, let's say you want to try a different library or upgrade a component to a newer version. With VM's you could do it live, but you risk not being able to go back. You could make a copy or make a checkpoint, but that's rather resource intensive. With docker you just change the Dockerfile slightly and build a new image.
The resulting image is also immutable, which means that if you restart the docker container, it's like reverting to first VM checkpoint after finished install, throwing out any cruft that have gathered. You can exempt specific file and folders from this, if needed. So every cruft and change that have happened gets thrown out except the data folder(s) for the program.
I'm not sure I understand this idea that VMs have a high overhead. I just checked one of my servers, there are nine VMs running everything from chat channels to email to web servers, and the server is 99.1% idle. And this is on a poweredge R620 with low-power CPUs, it's not like I'm running something crazy-fast or even all that new. Hell until the beginning of this year I was running all this stuff on poweredge 860's which are nearly 20 years old now.
If I needed to set up the VM again, well I would just copy the backup as a starting point, or copy one of the mirror servers. Copying a VM doesn't take much, I mean even my bigger storage systems only use an 8GB image. That takes, what, 30 seconds? And for building a new service image, I have a nearly stock install which has the basics like LDAP accounts and network shares set up. Otherwise once I get a service configured I just let Debian manage the security updates and do a full upgrade as needed. I've never had a reason to try replacing an individual library for anything, and each of my VMs run a single service (http, smtp, dns, etc) so even if I did try that there wouldn't be any chance of it interfering with anything else.
Honestly from what you're saying here, it just sounds like docker is made for people who previously ran everything directly under the main server installation and frequently had upgrades of one service breaking another service. I suppose docker works for those people, but the problems you are saying it solves are problems I have never run in to over the last two decades.
Nine. How much ram do they use? How much disk space? Try running 90, or 900. Currently, on my personal hobby kubernetes cluster, there's 83 different instances running. Because of the low overhead, I can run even small tools in their own container, completely separate from the rest. If I run say.. a postgresql server.. spinning one up takes 90mb disk space for the image, and about 15 mb ram.
I worked at a company that did - among other things - hosting, and was using VM's for easier management and separation between customers. I wasn't directly involved in that part day to day, but was friend with the main guy there. It was tough to manage. He was experimenting with automatic creating and setting up new VM's, stripping them for unused services and files, and having different sub-scripts for different services. This was way before docker, but already then admins were looking in that direction.
So aschually, docker is kinda made for people who runs things in VM's, because that is exactly what they were looking for and duct taping things together for before docker came along.
Yeah I can see the advantage if you're running a huge number of instances. In my case it's all pretty small scale. At work we only have a single server that runs a web site and database so my home setup puts that to shame, and even so I have a limited number of services I'm working with.
Yeah, it also has the effect that when starting up say a new postgres or web server is one simple command, a few seconds and a few mb of disk and ram, you do it more for smaller stuff.
Instead of setting up one nginx for multiple sites you run one nginx per site and have the settings for that as part of the site repository. Or when a service needs a DB, just start a new one just for that. And if that file analyzer ran in it's own image instead of being part of the web service, you could scale that separately.. oh, and it needs a redis instance and a rabbitmq server, that's two more containers, that serves just that web service. And so on..
Things that were a huge hassle before, like separate mini vm's for each sub-service, and unique sub-services for each service doesn't just become practical but easy. You can define all the services and their relations in one file and docker will recreate the whole stack with all services with one command.
And then it also gets super easy to start more than one of them, for example for testing or if you have a different client. .. which is how you easily reach a hundred instances running.
So instead of a service you have a service blueprint, which can be used in service stack blueprints, which allows you to set up complex systems relatively easily. With a granularity that would traditionally be insanity for anything other than huge, serious big-company deployments.
Well congrats, you are the first person who has finally convinced me that it might actually be worth looking at even for my small setup. Nobody else has been able to even provide a convincing argument that docker might improve on my VM setup, and I've been asking about it for a few years now.
It's a great tool to have in the toolbox. Might take some time to wrap your head around, but coming from vm's you already have most of the base understanding.
From a VM user's perspective, some translations:
A small tip: you can "exec" into a running container, which will run a command inside that container. Combined with interactive (-i) and terminal (-t) flags, it's a good way to get a shell into a running container and have a look around or poke things. Sort of like getting a shell on a VM.
One thing that's often confusing for new people are image tags. Partially because it can mean two things. For example "postgres" is a tag. That is attached to an image. The actual "name" of an image is it's Sha sum. An image can have multiple tags attached. So far so good, right?
Now, let's get complicated. The actual tag, the full tag for "postgres" is actually "docker.io/postgres:latest". You see, every tag is a URL, and if it doesn't have a domain name, docker uses it's own. And then we get to the ": latest" part. Which is called a tag. Yup. All tags have a tag. If one isn't given, it's automatically set to "latest". This is used for versioning and different builds.
For example postgres have tags like "16.1" which points to latest 16.1.x version image, built on postgres maintainers' preferred distro. "16.1-alpine" that point to latest Alpine based 16.1.x version. "16" for latest 16.x.x version, "alpine" for latest alpine based version, be it 16 or 17 or 18.. and so on. You can find more details here.
The images on docker hub are made by .. well, other people. Often the developers of that software themselves, sometimes by docker, sometimes by random people. You can make your own account there, it's free. If you do, make an image and pushes it, it will be available as shdwdrgn/name - if it doesn't have a user component it's maintained / sanctioned by docker.
You can also run your own image repository service, as long as it has https with valid cert. Then it will be yourdomain.tld/something
So that was a brief introduction to the strange World of docker. Docker is a for profit company, btw. But the image format is standardized, and there's fully open source ways to make and run images too. At the top of my head, podman and Kubernetes.
One thing I'm not following in all the discussions about how self-contained docker is... nearly all of my images make use of NFS shares and common databases. For example, I have three separate smtp servers which need to put incoming emails into the proper home folders, but also database connections to track detected spam and other things. So how would all these processes talk to each other if they're all locked within their container?
The other thing I keep coming back to, again using my smtp servers as an example... It is highly unlikely that anyone else has exactly the same setup that I do, let alone that they've taken the time to build a docker image for it. So would I essentially have to rebuild the entire system from scratch, then learn how to create a docker script to launch it, just to get the service back online again?
For the nfs shares, there's generally two approaches to that. First is to mount it on host OS, then map it in to the container. Let's say the host has the nfs share at /nfs, and the folders you need are at /nfs/homes. You could do "docker run -v /nfs/homes:/homes smtpserverimage" and then those would be available from /homes inside the image.
The second approach is to set up NFS inside the image, and have that connect directly to the nfs server. This is generally seen as a bad idea since it complicates the image and tightly couples the image to a specific configuration. But there are of course exceptions to each rule, so it's good to keep in mind.
With database servers, you'd have that set up for accepting network connections, and then just give the address and login details in config.
And having a special setup.. How special are we talking? If it's configuration, then that's handled by env vars and mapping in config files. If it's specific plugins or compile options.. Most built images tend to cast a wide net, and usually have a very "everything included" approach, and instructions / mechanics for adding plugins to the image.
If you can't find what you're looking for, you can build your own image. Generally that's done by basing your Dockerfile on an official image for that software, then do your changes. We can again take the "postgres" image since that's a fairly well made one that has exactly the easy function for this we're looking for.
So if you have a .sh script that does some extra stuff before the DB starts up, let's say "mymagicpostgresthings.sh" and you want an image that includes that, based on Postgresql 16, you could make this Dockerfile in the same folder as that file:
and when you run "docker build . -t mymagicpostgres" in that folder, it will build that image with your file included, and call it "mymagicpostgres" - which you can run by doing "docker run -e POSTGRES_PASSWORD=mysecretpassword -p 5432:5432 mymagicpostgres"
In some cases you need a more complex approach. For example I have an nginx streaming server - which needs extra patches. I found this repository for just that, and if you look at it's Dockerfile you can see each step it's doing. I needed a bit of modifications to that, so I have my own copy with different nginx.conf, an extra patch it downloads and applies to the src code, and a startup script that changes some settings from env vars, but that had 90% of the work done.
So depending on how big changes you need, you might have to recreate from scratch or you can piggyback on what's already made. And for "docker script to launch it" that's usually a docker-compose.yml file. Here's a postgres example:
If you run "docker compose up -d" in that file's folder it will cause docker to download and start up the images for postgres and adminer, and port forward in 8080 to adminer. From adminer's point of view, the postgres server is available as "db". And since both have "restart: always" if one of them crashes or the machine reboots, docker will start them up again. So that will continue running until you run "docker compose down" or something catastrophic happens.
Hey I wanted to say thanks for all the info and I've saved this aside. Had something come up that is requiring all my attention so I just got around to reading your message but it looks like my foray into docker will have to wait a bit longer.
Doesn't that require a lot of resources since you're running (mysql, nginx, etc.) numerous times (once for each container), instead of once globally?
Or, per your comment below:
You'd only have two instances of postgres, for example, one for all docker containers and one global/server-wide? Still, that doubles the resources used no?
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. :)
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.
Why not jumping directly to Podman if you want more resilent system from beginning? Just my opinion
Why not? Because I've never heard of it until this thread - lots of people mentioning it so obviously I'll look into it.
Welcome to the party 😀
If you want a good video tutorial that explains the inner workings of docker so you understand what's going on beneath the surface(without drowning in the details), let me know and I'll paste it tomorrow. Writing from bed atm 😴
I'd like that please
Check out my previous comment: https://lemmy.ml/comment/6629930
(sorry, haven't learned how to tag users on Lemmy yet!)
Not OP, but, yes please.
Here you go: https://www.youtube.com/playlist?list=PLTk5ZYSbd9Mg51szw21_75Hs1xUpGObDm
LearnCantrill does a good job at being straightforward and clear in his courses. His networking fundamentals is also pretty good.
Check also out this resource where you can fool around and get a feel for Docker in a virtual enviorment: https://labs.play-with-docker.com/
Here is an alternative Piped link(s):
https://www.piped.video/playlist?list=PLTk5ZYSbd9Mg51szw21_75Hs1xUpGObDm
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source; check me out at GitHub.
Thank you!
I'm also interested in that, please
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.
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.
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:
A brief description of my own setup, for ideas, feel free to ask questions:
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.
I'm basically the same here, used to be a sysmin too. Docker compose is running a couple of complicated inter-dependent services at my job as a first try for me, it's been quite stable and clear on what's happening within the containers.
I really like how the docker setup files also become a source of truth documentation wise, particularly when paired with git.
P.s. I know it's a typo, but imagine a 'black Friday upgrade' for your server being a move from 4gb ram to 32mb. Return to
monke1998.That typo made me chuckle way harder than it should've, too.
It seems like docker would be heavy on resources since it installs & runs everything (mysql, nginx, etc.) numerous times (once for each container), instead of once globally. Is that wrong?
There's nothing stopping you from using a single instance of those and only adding databases and config. The configs that come with projects set them up individually because they need to offer full examples but those configs are only meant as a guideline.
Also keep in mind that the overhead of just running multiple instances isn't very big. The resources are consumed when you start having connections and using CPU and storing data and so on, and those are going to be the same no matter how many instances you have.
As someone who just started their container adventure by setting up rootless podman on arch, it wasn't terrible but I think I agree. I think I'm going to go check out some vanilla-ass docker until I can understand everything better.
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
I couldn't get used to Docker at all before using Portainer. GUIs are great if you can't use CLI.
That's how I "onboarded" to docker. Portainer acted like a stepping stone, as I got familiar with how docker worked.
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:
Also consider Nix/NixOS, I have used Docker, Kubernetes, LXC and prefer Nix the most. Especially for home use not requiring any scaling.
You should try it.
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.
I found they were easier to config. somebody has a yaml file or via portainer to setup ports etc. and you can always bash into a docker to lurk inside the black box
I think they’re easier to debug as well IMO. Logs can be spread out across the filesystem on something like a Debian VM. Whereas with Docker they’re all in one feed you can easily follow the output from, with different services colour-coded. You can also easily increase the verbosity by editing the compose file.
Yes, you should. I would look into docker compose as it makes deployments very easy.
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.
https://github.com/mag37/dockcheck/blob/main/dockcheck.sh
The preferred filename is now
compose.yaml, see https://docs.docker.com/compose/compose-file/03-compose-file/I doubt they’re going to remove support for the previous filename anytime soon. It would break way too many things.
Why not just run a watchtower container? Combined with a diun one to send gotify messages to my phone if you're into that. (I am!)
Sometimes automated updates are not desirable. I also prefer the simplicity of a bash script over a full container.
Yes. Containers are awesome in that they let you use an application inside a sandbox, but beyond that you can deploy it anywhere.
If you're in the sysadmin world you should not only embrace Docker but I'd recommend learning k8s, too, if you still enjoy those things.
K8s is awesome.
Yes! Well, kinda. You can skip Docker and go straight to Podman, which is an open source and more integrated solution. I configure my containers as systemd services (as quadlets).
Hold up, does Podman replace Docker entirely?
There are still edge cases, but things have improved rapidly the last year or two, to the point that most docker-compose.yaml files can be run unmodified with podman-compose.
I have however moved away from compose in favor of running containers and pods as systemd services, which I really like. If you want to try it, make sure your distro has a reasonably new version of Podman, at least v4.4 ot newer. Debian stable has an older version, so I had to use the testing repos to get quadlets working.
I'm no expert, but as far as I can tell yes. It also seems a bit easier to have a rootless setup.
It depends on what you do with Docker. Podman can replace many of the core docker features, but does not ship with a Docker Desktop app (there may be one available). Also, last I checked, there were differences in the
docker buildcommand.That being said, I'm using podman at home and work, doing development things and building images must fine. My final images are built in a pipeline with actual Docker, though.
I jumped ship from Docker (like the metaphor?) when they started clamping down on unregistered users and changed the corporate license. It's my personal middle finger to them.
Podman desktop! https://podman-desktop.io/
I, too, need to know..
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 :(
Even learning how to do the simplest thing possible that is easy to package by anybody - something like a tarball or zip - is becoming less popular :(
I learned "creating a zip" the hard way when I submitted an exam but forgot the -r on creation, meaning all the to-review code was gone.
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 imageFrom 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.
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
LXC with cloud-init and ansible on proxmox gives you docker features without the docker headache.
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.
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.
Why wouldn't you want to use containers? I'm curious. What do you use now? Ansible? Puppet? Chef?
Currently no virtualisation at all - just my OS on bare metal with some apps installed. Remember, this is a single machine sitting in my basement running Samba and a couple of other things - there's not much to orchestrate :-)
Oh, I thought you had multiple machines.
I use docker because each service I use requires different libraries with different versions. With containers, that doesn't matter. It also provides some rudimentary security. If an attacker gets in, they'll have to break out of the container first to get at the rest of the system. Each container can run with a different user, so even if they do get out of the container, at worst they'll be able to destroy the data they have access to - well, they'll still see other stuff in the network, but I think it's better than being straight pwned.
It makes deployments a lot easier once you have the groundwork laid (writing your compose files). If you ever need to nuke the OS reinstalling and configuring 20+ apps can only take a few minutes (assuming you still have the config data, which should live outside of the container).
For example, setting up my mediaserver, webserver, SQL server, and usenet suit of apps can take a few hours to do natively. Using Docker Compose it takes one command and about 5-10 minutes. Granted, I had to spend a few hours writing the compose files and testing everything, along with storing the config data, but just simply backing up the compose files with git means I can pull everything down quickly. Even if I don't have the config files anymore it probably only takes like an hour or less to configure everything.
Not OP, but, seriously asking, why should I? I usually still use VMs for every app i need. Much more work I assume, but besides saving time (and some overhead and mayve performance) what would I gain from docker or other containers?
One of the things I like about containers is how central the IaC methodology is. There are certainly tools to codify VMs, but with Docker, right out of the gate, you'll be defining your containers through a Dockerfile, or docker-compose.yml, or whatever other orchestration platform. With a VM, I'm always tempted to just make on the fly config changes directly on the box, since it's so heavy to rebuild them, but with containers, I'm more driven to properly update the container definition and then rebuild the container. Because of that, you have an inherent backup that you can easily push to a remote git server or something similar. Maybe that's not as much of a benefit if you have a good system already, but containers make it easier imo.
Actually only tried a docker container once tbh. Haven't put much time into it and was kinda forced to do. So, if I got you right, I do define the container with like nic-setup or ip or ram/cpu/usage and that's it? And the configuration of the app in the container? is that IN the container or applied "onto it" for easy rebuild-purpose? Right now I just have a ton of (big) backups of all VMs. If I screw up, I'm going back to this morning. Takes like 2 minutes tops. Would I even see a benefit of docker? besides saving much overhead of cours.
You don't actually have to care about defining IP, cpu/ram reservations, etc. Your docker-compose file just defines the applications you want and a port mapping or two, and that's it.
Example:
That's it, you run
docker-compose upand the container starts, reads your config from your config folder, and exposes port 8080 to the rest of your network.Oh... But that means I need another server with a reverse-proxy to actually reach it by domain/ip? Luckily caddy already runs fine 😊
Thanks man!
Most people set up a reverse proxy, yes, but it's not strictly necessary. You could certainly change the port mapping to
8080:443and expose the application port directly that way, but then you'd obviously have to jump through some extra hoops for certificates, etc.Caddy is a great solution (and there's even a container image for it 😉)
Lol...nah i somehow prefer at least caddy non-containerized. Many domains and ports, i think that would not work great in a container with the certificates (which i also need to manually copy regularly to some apps). But what do i know 😁
Reproducability.
Once you've built the Dockerfile or compose file for your container, it's trivial to spin it up on another machine later. It's no longer bound to the specific VM and OS configuration you've built your service on top of and you can easily migrate containers or move them around.
But that's possible with a vm too. Or am I missing something here?
If you update your OS, it could happen that a changed dependency breaks your app. This wouldn't happen with docker, as every dependency is shipped with the application in the container.
Ah okay. So it's like an escape from dependancy-hell... Thanks.
Apart from the dependency stuff, what you need to migrate when you use docker-compose is just a text file and the volumes that hold the data. No full VMs that contain entire systems because all that stuff is just recreated automatically in seconds on the new machine.
Ok, that does save a lot of overhead and space. Does it impact performance compared to a vm?
If anything, containers are less resource intensive than VMs.
Thank you. Guess i really need to take some time to get into it. Just never saw a real reason.
The great thing about containers is that you don't have to understand the full scope of how they work in order to use them.
You can start with learning how to use docker-compose to get a set of applications running, and once you understand that (which is relatively easy) then go a layer deeper and learn how to customize a container, then how to build your own container from the ground up and/or containerize an application that doesn't ship its own images.
But you don't need to understand that stuff to make full use of them, just like you don't need to understand how your distribution builds an rpm or deb package. You can stop whenever your curiosity runs out.
Won't need to containerize my own stuff. Yet. But many apps just give a recent docker or some outdated manual install stuff. Hence why i get more and more annoyed/intrigued by docker 😁
Thanks for the guide!
VMs have a ton of overhead compared to Docker. VMs replicate everything in the computer while Docker just uses the host for everything, except it sandboxes the apps.
In theory, VMs are far more secure since they're almost entirely isolated from the host system (assuming you don't have any of the host's filesystems attached), they are also OS agnostic whereas Docker is limited to the OS it runs on.
Ah ok thanks, the security-aspect is indeed important to me. So I shouldn't really use it for critical things. Especially those with external access.
Docker is still secure, it's just less secure than Virtualization. It's like a standard door knob lock (the twist/push button kind) vs a deadbolt. Both will keep 90% of bad-actors out but those who really want to get in can based on how high the security is.
Saves time, minimal compatibility, portability and you can update with 2 commands There's really no reason not to use docker
But I can't really tinker IN the docker-image, right? It's maintained elsewhere and I just get what i got. But with way less tinkering? Do I have control over the amount/percentage of resources a container uses? And could I just freeze a container, move it to another physical server and continue it there? So it would be worth the time to learn everything about docker for my "just" 10 VMs to replace in the long run?
You can tinker in the image in a variety of ways, but make sure to preserve your state outside the container in some way:
docker exec -it containerName /bin/bashYes, you can set a variety of resources constraints, including but not limited to processor and memory utilization.
There's no reason to "freeze" a container, but if your state is in a host or volume mount, destroy the container, migrate your data, and resume it with a run command or docker-compose file. Different terminology and concept, but same result.
It may be worth it if you want to free up overhead used by virtual machines on your host, store your state more centrally, and/or represent your infrastructure as a docker-compose file or set of docker-compose files.
Hm. That doesn't really sound bad. Thanks man, I guess I will take some time to read into it. Currently on proxmox, but AFAIK it does containers too.
It's really not! I migrated rapidly from orchestrating services with Vagrant and virtual machines to Docker just because of how much more efficient it is.
Granted, it's a different tool to learn and takes time, but I feel like the tradeoff was well worth it in my case.
I also further orchestrate my containers using Ansible, but that's not entirely necessary for everyone.
I only use like 10 VMs, guess there's no need for overkill with additional stuff. Though I'd like a gui, there probably is one for docker? Once tested a complete os with docker (forgot the name) but it seemed very unfriendly and ovey convoluted.
There's a container web UI called Portainer, but I've never used it. It may be what you're looking for.
I also use a container called Watchtower to automatically update my services. Granted there's some risk there, but I wrote a script for backup snapshots in case I need to revert, and Docker makes that easy with image tags.
There's another container called Autoheal that will restart containers with failed healthchecks. (Not every container has a built in healthcheck, but they're easy to add with a custom Dockerfile or a docker-compose.)
Thanks for the tips! But did i get it right here? A container can has access to other containers?
The Docker client communicates over a UNIX socket. If you mount that socket in a container with a Docker client, it can communicate with the host's Docker instance.
It's entirely optional.
Ah okay. Sounds safe enough. Thanks again :-)
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.
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.
If you have homelab and not using containers - you are missing out A LOT! Docker-compose is beautiful thing for homelab. <3
It took me a while to convert to Docker, I was used to installing packages for all my Usenet and media apps, along with my webserver. I tried Docker here and there but always had a random issue pop up where one container would lose contact with the other, even though they were in the same subnet. Since most containers only contain the bare minimum, it was hard to troubleshoot connectivity issues. Frustrated, I would just go back to native apps.
About a year or so ago, I finally sat down and messed around with it a lot, and then wrote a compose file for everything. I've been gradually expanding upon it and it's awesome to have my full stack setup with like 20 containers and their configs, along with an SSL secured reverse proxy in like 5-10 minutes! I have since broken out the compose file into multiple smaller files and wrote a shell script to set up the necessary stuff and then loop through all the compose files, so now all it takes is the execution of one command instead of a few hours of manual configuration!
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.
Can you recommend a mail server docker image like that? I have a hand cranked iredmail server that I've been babying for 5 years but I want to move it to either docker or an LXC.
I use Mailcow and like it a lot.
I use a mail service (MXRoute) as an outbound SMTP relay though, since I don't want to have to deal with deliverability, especially to picky services like Microsoft Hotmail/Outlook. It's a trade off. Other relays like SMTP2Go and Amazon SES work well too.
So I'm self-hosting the mailboxes, but when I send mail through my server, it sends them via MXRoute.
https://github.com/docker-mailserver/docker-mailserver
Mailcow or Mailu have pretty good setups if you don't want to do anything too different and don't need to keep resource usage to a minimum.
I haven't had any issues with IPv6. If you want to, you can just use a macvlan network and rely on SLAAC. I manually assigned ULA addresses to some containers and it's working well.
Also as a side note, it's not common for mail servers to use SpamAssassin any more. Most have moved to rspamd which is more powerful and much more efficient.
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.
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!
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.
Yeah. Docker for servers.
Flatpak for Desktops/Laptops.
Although I currently run my Docker stack on my desktop because my NAS server broke down. But its on servers Docker really shines.
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)
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.
Nixos, nixos, nixos 🤌
Does Docker still give a security benefit over NixOS, because of the sandboxing?
Not familiar with nixOS but there's probably still isolation benefits to Docker. If you care a lot about security, make sure Docker is running in rootless mode.
See this comment https://sh.itjust.works/comment/6651651
Both! Sandboxing from containers and configuration control from nix go well together!
You can use the sandboxing of nixos
You get better performance, nixos level reproducibility, and it's not docker which is not foss and running with root
The Nix daemon itself still uses root at build/install time for now. NixOS doesn't have any built-in sandboxing for running applications à la Docker, though it does have AppArmor support. But then, NixOS doesn't generally have applications run as root (containerized or otherwise), unlike Docker.
You don't need to build/install with root, you can do home-manager
And for isolation there's one good module, I forgot its name
And if just easier but less reproducible, you can do the containers, but with nixos' podman, and this is of course builtin
I'm not sure honestly if we are agreeing or disagree lol
Nix for building OCI containers is great and Nixos seems like a great base system too. It seems like a natural step to take that and use it to define our a k8s system in the future as well.
I'm currently doing that with OpenTofu (Terraforms opensource successor) and Ansible but I feel like replacing those with nix may provide a real completeness to the codification of the OS.
Barring k8s though, at least until it's gets so simply you might as well use it, podman is so far the go to way to run containers instead of Docker (for both of the reasons you mentioned!). That and flatpaks for GUI apps because of the portals system!
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.
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.
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.
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.
No. Docker is proprietary
Podman ftw!
Concur, podman doesn't (have to) have root, and has autoupdate and podman-compose to use docker files. Containers are cool, Docker less so.
My biggest issue with podman is that podman-compose isn't officially recommended or supported, and the alternatives (kubernetes YAML and Quadlet) kind of suck compared to using a compose file. It makes me way to pour a bunch lf work into switching to using podman-compose. I have no clue why they didn't just use the compose spec for their official orchestration method.
once the containers are running after podman-compose you can use podman-generate-systemd to create a systemd services. Helped me move a rather large compose file to a bunch of services. My notes weren't the best, sorry, but that's the gist.It got me moved. I've now moved on to .container files for new stuff, which generates them on the fly. Need to move my old services over, but they work and who's got the time...
How do you like the .container files? I hate the idea of having different files for each container, and each volume. They also don't even support pods and the syntax is just terrible compared to YAML.
Not sure yet, agree it's not as nice to look at as YAML, but at least it's prettier than the alternative systemd.service implementation, and it's been rock solid so far. Time will tell, I'm sure pods will come and it seems to be what redhat sees as their direction. A method for automatically generating them from docker YAML (and hopefully vice-versa) would go a looong way towards speeding adoption.
How do you feel about having to specify a different file for all of your containers and volumes? Has that annoyed you at all? I agree that pods are really nice, and they should give you a way to generate them from compose YAML.
I have made my peace, it's the price of not giving docker root. I just open a Kate session and it's all there, nicely broken into sections.
I've regrettably only heard of Podman in passing. At work we use docker containers with kubernetes, is this something we could easily transition to without friction?
@EnderMB @NocturnalEngineer
Podman uses the OCI standard — it is a drop-in replacement for Docker
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.
You are right. Either you are using docker very wrong, or docker is not meant for this use case.
You say "getting ubuntu server to fetch it's updated behind proxy". You shouldn't be updating Ubuntu from inside of docker. Instead, the system should be somewhat immutable. You should configure the version you want to use as part of the Docker file.
Same with python and keys. You likely want to install python dependencies in the Dockerfile, so that you can install them once and it becomes bundled into the container image. Then you don't need to use pip behind the proxy.
I'm not much into new year resolutions, but I think I'll make a conscious effort to learn Docker in the coming months. Any suggestions for good guides for someone coming from VM end will be appreciated.
I learn by twiddling knobs and such and inspecting results, so having come from a tall stack of KVM machines to docker, this helped me become effective with a project I needed to get running quickly: https://training.play-with-docker.com/
You basically log into a remote system which has docker configured, and go through their guide to see what command is needed per action, and also indirectly gets you to grok the conceptual difference between a VM and a container.
Jump straight to the first tutorial: https://training.play-with-docker.com/ops-s1-hello/
Thank you for these links, they look just right. Most tutorials I come across these days are videos. Maybe they are easier to make. These tutorials that allow you to tinker at your own pace seem better to me. Will you mind if I reach out to you over DM if I get stuck at something while learning and am not able to find the right answer easily?
Sure, that's ok. Thanks for asking.
The networking send to be where documentation for both docker and podman seem to be a bit slim, just a heads up.
Huh? Your docker container shouldn't be calling pip for updates at runtime, you should consider a container immutable and ephemeral. Stop thinking about it as a mini VM. Build your container (presumably pip-ing in all the libraries you require) on the machine with full network access, then export or publish the container image and run it on the machine with limited access. If you want updates, you regularly rebuild the container image and repeat.
Alternatively, even at build time it's fairly easy to use a proxy with docker, unless you have some weird proxy configuration. I use it here so that updates get pulled from a local caching proxy, reducing my internet traffic and making rebuilds quicker.
I think I'm not aware of the exporting/publishing part and that's the cause of my woes. I get everything running on the machine with unrestricted access, move to the machine with restricted access go "docker compose up" and get stuck. I'll read up on exporting/publishing, thank you.
I would never go back installing something without docker. Never.
For a lot of smaller things I feel that Docker is overkill, or simply not feasible (package management, utilities like screenfetch, text editors, etc...) but for larger apps it definitely makes it easier once you wrap your head around containerization.
For example, I switched full-time to Jellyfin from Plex and was attempting to use caddy-docker-proxy to forward the host network that Jellyfin uses to the Caddy server, but I couldn't get it to work automatically (explicitly defining the reverse proxy in the Caddyfile works without issue). I thought it would be easier to just install it natively, but since I hadn't installed it that way in a few years I forgot that it pulls in like 30-40 dependencies since it's written in .Net (or would that be C#?) and took a good few minutes to install. I said screw that and removed all the deps and went back to using the container and just stuck with the normal version of Caddy which works fine.
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].
i use it for gitea, nextcloud, redis, postgres, and a few rest servers and love it!, super easy
it can suck for things like homelab stablediffusion and things that require gpu or other hardware.
As someone who does AI for a living: GPU+docker is easy and reliable. Especially if you compare it to VMs.
good to hear. maybe I should try again
I never use it for databases. I find I don't gain much from containerizing it, because the interesting and difficult bits of customizing and tayloring a database to your needs are on the data file system or in kernel parameters, not in the database binaries themselves. On most distributions it's trivial to install the binaries for postgres/mariadb or whatnot.
Databases are usually fairly resource intensive too, so you'd want a separate VM for it anyway.
Very good points.
In my case I just need to for a couple users with maybe a few dozen transactions a day; it's far from being a bottleneck and there's little point in optimizing it further.
Containerizing it also has the benefit of boiling all installation and configuration into one very convenient dockercompose file... Actually two. I use one with all the config stuff that's published to gitea and one that has sensitive data.
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.
All that makes sense - except that I'm taking about 1or 2 physical servers at home and my only real motivation for looking into containers at all is that some software I've wanted to install recently has shipped as docker compose scripts. If I'm going to ignore their packaging anyway, and massage them into some other container management system, I would be happier just running them of bare metal like I've done with everything else forever.
I am a network engineer and I am learning it. I see it in the next step from the bare metal -> virtualisation evolution
It's basically a vm without the drawbacks of a vm, why would you not? It's hecking awesome
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.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
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]
Why would you try avoiding it if you understand how it works? It has so many upsides and so few downsides. About the only practical one is using more disk space. It was groundbreaking technology in 2013. Today it's an old and essential tool.
Because it seems overkill for a home server. Up until recently all I ran was Samba and a torrent daemon. Why would I install another layer of overhead to manage two applications on one server?
Because the overhead is practically none, barring the extra disk space. Maybe it's not worth using it for Samba and Transmission. But involve OpenVPN for Transmission in the mix and things get a lot more complicated if Samba has to keep serving LAN and Transmission has to stop whenever OpenVPN stops. If instead you grab this, the problem is solved by writing one 20-line docker-compose.yml and doing
docker-compose up -d:A benefit of Docker's that helps even with a single-service deployment is the the packaging side. It allows for running near-arbitrary service versions on top of your host OS, stale, stable, bleeding edge or anything in-between.
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.
If your compose files are conflicting then you're likely not tailoring your compose files to fit your server.
I was writing my own compose files, but see my response to a sibling comment for the issue I had.
Wow - I thought docker was overkill for a home server and you've gone kubernetes! I guess if you use it for work and that's what you're comfortable with?
Thank you... I had to learn kubernetes for work and it was around 2 weeks of time investment and then I figured out I could use it to fix my docker-compose pains at home.
If you run a lot of services, I can attest that kubernetes is definitely not overkill, it is a good tool for managing complexity. I have 8 services on a single-node kubernetes and I like how I can manage configuration for each service independent of each other and also the underlying infrastructure.
Can you expand on that? I use docker-compose and have probably around 10 services on the same box. I don't forsee any limitations beyond hardware if I wanted to just keep adding more, but maybe I'm missing something.
If one service needs to connect to another service then I have to add a shared network between them. In that case, the services essentially shared a common namespace regarding DNS. DNS resolution would routinely leak from one service to another and cause outages, e.g if I connect Gitlab container and Redmine container with OpenLDAP container then sometimes Redmine's nginx container would access Gitlab container instead of Redmine container and Gitlab container would access Redmine's DB instead of its own DB.
I maintained some workarounds, like starting Gitlab after starting Redmine would work fine but starting them other way round would have this issue. But switching to Kubernetes and replacing the cross-service connections with network policies solved the issue for me.
An easy fix for this is to create individual networks for connections. I.e. don't create one network with Gitlab, Redmine and OpenLDAP - do two, one with Gitlab and OpenLDAP, and one with Redmine and OpenLDAP.
This was the setup I had, but now I am already using kubernetes with no intention to switch back.
Very understandable :)