Should I move to Docker?

Submitted ⁨⁨11⁩ ⁨months⁩ ago⁩ by ⁨GreatBlueHeron@lemmy.ca⁩ to ⁨selfhosted@lemmy.world⁩

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?

source

Comments

Sort:hotnew top

originalucifer@moist.catsweat.com ⁨11⁩ ⁨months⁩ ago
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!.

source
- GreatBlueHeron@lemmy.ca ⁨11⁩ ⁨months⁩ ago
  Image
  
  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 ye relying on.
  
  source
  - infeeeee@lemm.ee ⁨11⁩ ⁨months⁩ ago
    Forget docker run, docker compose up -d is 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.
    
    source
    -> View More Comments
  - monkeyman512@lemmy.world ⁨11⁩ ⁨months⁩ ago
    If you are interested in a web interface for management check out portainer.
    
    source
- themurphy@lemmy.world ⁨11⁩ ⁨months⁩ ago
  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
  
  source
  - BeefPiano@lemmy.world ⁨11⁩ ⁨months⁩ ago
    No more dependency hell from one package needing libsomething.so 5.3.1 and another service absolutely can only run with libsomething.so 4.2.0
    
    That and knowing that when i remove a container, its not leaving a bunch of cruft behind
    
    source
  - constantokra@lemmy.one ⁨11⁩ ⁨months⁩ ago
    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.
    
    source
  - theterrasque@infosec.pub ⁨11⁩ ⁨months⁩ ago
    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 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.
    
    If you’re an old Linux admin… This is what utopia looks like.
    
    source
    -> View More Comments
iso@lemy.lol ⁨11⁩ ⁨months⁩ ago
It just making things easier and cleaner. When you remove a container, you know there is no leftover except mounted volumes. I like it.

source
- AbidanYre@lemmy.world ⁨11⁩ ⁨months⁩ ago
  It’s also way easier if you need to migrate to another machine for any reason.
  
  source
- nik282000@lemmy.ca ⁨11⁩ ⁨months⁩ ago
  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.
  
  source
- Auli@lemmy.ca ⁨11⁩ ⁨months⁩ ago
  It completely true you probably have to prune some images, or volumes.
  
  source
ck_@discuss.tchncs.de ⁨11⁩ ⁨months⁩ ago
The main downside of docker images is app developers don’t tend to play a lot of attention to the images that they produce beyond shipping their app. While software installed via your distribution benefits from marriculous scrutiny of security teams making sure security issues are fixed in a timely fashion, those fixes rarely trickle down the chain of images that your container ultimately depends on. While your distributions package manager sets up a cron job to install fixes from the security channel automatically, with Docker you are back to keeping track of this by yourself, hoping that the app developer takes this serious enough to supply new images in a timely fashion. This multies by number of images, so you are always only as secure as the least well maintained image.

Most images, including latest, are piss pour quality from a security standpoint. Because of that, professionals do not tend to grab “off the shelve” images from random sources of the internet. If they do, they pay extra attention to ensure that these containers run in sufficient isolated environment.

Self hosting communities do not often pay attention to this. You’ll have to decide for yourself how relevant this is for you.

source
- fruitycoder@sh.itjust.works ⁨11⁩ ⁨months⁩ ago
  For sure! Most seem to be random git repo level of reviewed instead of being seriously tested and hardened. I really wish we had more of an source for reliable audits of containers, and flatpaks. Just someone trusted or collectively running trivy, clair, sonarqube, etc, posting the results publicly, and having tools like podman/K3s/etc have sane defaults for checkibg it against containers on pull.
  
  source
buedi@feddit.de ⁨11⁩ ⁨months⁩ ago
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.

source
- shasta@lemm.ee ⁨11⁩ ⁨months⁩ ago
  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.
  
  source
1984@lemmy.today ⁨11⁩ ⁨months⁩ ago
Docker is amazing, you are late to the party :)

source
zaphod@lemmy.ca ⁨11⁩ ⁨months⁩ ago
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).

source
- BCsven@lemmy.ca ⁨11⁩ ⁨months⁩ ago
  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
  
  source
  - princessnorah@lemmy.blahaj.zone ⁨11⁩ ⁨months⁩ ago
    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.
    
    source
outcide@lemmy.world ⁨11⁩ ⁨months⁩ ago
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.

source
- DasGurke@feddit.de ⁨11⁩ ⁨months⁩ ago
  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.
  
  source
  - outcide@lemmy.world ⁨11⁩ ⁨months⁩ ago
    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. :-)
    
    source
Swarfega@lemm.ee ⁨11⁩ ⁨months⁩ ago
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. Also 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.

source
lemmyvore@feddit.nl ⁨11⁩ ⁨months⁩ ago
Besides what you already noticed (that most software can be found packaged for Docker) here are some others:

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.

Docker is installed from their apt 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.
source
- RubberElectrons@lemmy.world ⁨11⁩ ⁨months⁩ ago
  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.
  
  source
  - andxz@lemmy.world ⁨11⁩ ⁨months⁩ ago
    That typo made me chuckle way harder than it should’ve, too.
    
    source
- jodanlime@midwest.social ⁨11⁩ ⁨months⁩ ago
  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.
  
  source
2xsaiko@discuss.tchncs.de ⁨11⁩ ⁨months⁩ ago
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.
source
ShittyBeatlesFCPres@lemmy.world ⁨11⁩ ⁨months⁩ ago
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.

source
- GreatBlueHeron@lemmy.ca ⁨11⁩ ⁨months⁩ ago
  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.
  
  source
  - greybeard@lemmy.one ⁨11⁩ ⁨months⁩ ago
    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.
    
    source
  - Tsubodai@programming.dev ⁨11⁩ ⁨months⁩ ago
    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.
    
    source
- Shdwdrgn@mander.xyz ⁨11⁩ ⁨months⁩ ago
  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?
  
  source
  - theterrasque@infosec.pub ⁨11⁩ ⁨months⁩ ago
    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.
    
    source
    -> View More Comments
gornius@lemmy.world ⁨11⁩ ⁨months⁩ ago
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.

source
olafurp@lemmy.world ⁨11⁩ ⁨months⁩ ago
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. :)

source
BCsven@lemmy.ca ⁨11⁩ ⁨months⁩ ago
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

source
- AlexSup21@iusearchlinux.fyi ⁨11⁩ ⁨months⁩ ago
  I didn’t get Docker at all before using Portainer. GUIs are great if you can’t use CLI.
  
  source
  - BCsven@lemmy.ca ⁨11⁩ ⁨months⁩ ago
    That’s how I “onboarded” to docker. Portainer acted like a stepping stone, as I got familiar with how docker worked.
    
    source
ikidd@lemmy.world ⁨11⁩ ⁨months⁩ ago
Yes

source
Undearius@lemmy.ca ⁨11⁩ ⁨months⁩ ago
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.

github.com/mag37/dockcheck/blob/…/dockcheck.sh

source
- foobaz@lemmy.world ⁨11⁩ ⁨months⁩ ago
  The preferred filename is now compose.yaml, see docs.docker.com/compose/…/03-compose-file/
  
  source
  - princessnorah@lemmy.blahaj.zone ⁨11⁩ ⁨months⁩ ago
    
    Compose also supports docker-compose.yaml and docker-compose.yml for backwards compatibility of earlier versions.
    
    I doubt they’re going to remove support for the previous filename anytime soon. It would break way too many things.
    
    source
- Tsubodai@programming.dev ⁨11⁩ ⁨months⁩ ago
  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!)
  
  source
  - Undearius@lemmy.ca ⁨11⁩ ⁨months⁩ ago
    Sometimes automated updates are not desirable. I also prefer the simplicity of a bash script over a full container.
    
    source
DeltaTangoLima@reddrefuge.com ⁨11⁩ ⁨months⁩ ago
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.

source
rsolva@lemmy.world ⁨11⁩ ⁨months⁩ ago
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).

source
- lawrence@lemmy.world ⁨11⁩ ⁨months⁩ ago
  Hold up, does Podman replace Docker entirely?
  
  source
  - rsolva@lemmy.world ⁨11⁩ ⁨months⁩ ago
    There are still edge cases, but things have improved rapidly the last year or so, to the point that most docker-compose.yaml files can be run unmodified with podman.
    
    I have however moved away from docker-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 bersion 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.
    
    source
  - jodanlime@midwest.social ⁨11⁩ ⁨months⁩ ago
    I’m no expert, but as far as I can tell yes. It also seems a bit easier to have a rootless setup.
    
    source
  - Anonymouse@lemmy.world ⁨11⁩ ⁨months⁩ ago
    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 build command.
    
    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.
    
    source
    -> View More Comments
  - elbarto777@lemmy.world ⁨11⁩ ⁨months⁩ ago
    I, too, need to know…
    
    source
ricdeh@lemmy.world ⁨11⁩ ⁨months⁩ ago
No. Docker is proprietary

source
- NocturnalEngineer@lemmy.world ⁨11⁩ ⁨months⁩ ago
  Podman ftw!
  
  source
  - MalReynolds@slrpnk.net ⁨11⁩ ⁨months⁩ ago
    Concur, podman doesn’t (have to) have root, and has autoupdate and podman-compose to use docker files. Containers are cool, Docker less so.
    
    source
    -> View More Comments
  - EnderMB@lemmy.world ⁨11⁩ ⁨months⁩ ago
    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?
    
    source
    -> View More Comments
520@kbin.social ⁨11⁩ ⁨months⁩ ago
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.

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.

consider podman over docker. The former does not run as root.
source
elscallr@lemmy.world ⁨11⁩ ⁨months⁩ ago
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.

source
- KyuubiNoKitsune@lemmy.blahaj.zone ⁨11⁩ ⁨months⁩ ago
  K8s is awesome.
  
  source
possiblylinux127@lemmy.zip ⁨11⁩ ⁨months⁩ ago
Yes, you should. I would look into docker compose as it makes deployments very easy.

source
Netrunner@programming.dev ⁨11⁩ ⁨months⁩ ago
You should try it.

source
AbouBenAdhem@lemmy.world ⁨11⁩ ⁨months⁩ ago
As a casual self-taught 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.

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 were needed to install or reinstall.

source
azdle@news.idlestate.org ⁨11⁩ ⁨months⁩ ago
IMO, yes. Docker (or at least OCI containers) aren’t going anywhere. Though one big warning to start with, at 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.

source
refreeze@lemmy.world ⁨11⁩ ⁨months⁩ ago
Also consider Nix/NixOS, I have used Docker, Kubernetes, LXC and prefer Nix the most. Especially for home use not requiring any scaling.

source
MigratingtoLemmy@lemmy.world ⁨11⁩ ⁨months⁩ ago
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

source
johntash@eviltoast.org ⁨11⁩ ⁨months⁩ ago
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 :(

source
- otl@lemmy.srcbeat.com ⁨11⁩ ⁨months⁩ ago
  
  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 :(
  
  source
  - SirQuackTheDuck@lemmy.world ⁨11⁩ ⁨months⁩ ago
    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.
    
    source
Opeth@lemm.ee ⁨11⁩ ⁨months⁩ ago
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.

source
___@lemm.ee ⁨11⁩ ⁨months⁩ ago
LXC with cloud unit and ansible on proxmox gives you docker features without the docker headache.

source

-> View More Comments