this post was submitted on 22 Mar 2024
61 points (91.8% liked)

Selfhosted

40006 readers
681 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
61
submitted 7 months ago* (last edited 7 months ago) by [email protected] to c/[email protected]
 

Hi, I've been thinking for a few days whether I should learn Docker or Podman. I know that Podman is more FOSS and I like it more in theory, but maybe it's better to start with docker, for which there is a lot more tutorials. On the other hand, maybe it's better to straight up learn podman when I don't know any of the two and not having to change habits later. What do you think? For context, I know how containers works in theory, I know some linux I think well, but I never actually used docker nor podman. In another words: If I want to eventually end up with Podman, is it easier to start with docker and then learn Podman, or start with Podman right away? Thanks in advance

top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 33 points 7 months ago (2 children)

In case you haven't started yet. Learn docker, but use podman.

[–] [email protected] 12 points 7 months ago

OP, listen to this person. Docker will earn you cash. Podman is nicer to work with for your own shit.

load more comments (1 replies)
[–] [email protected] 22 points 7 months ago

At the end of the day, you’re running containers and both will get the job done. Go with whatever you want to start, and be open to try the other when you inevitably end up with jobby job that uses the other one instead.

[–] [email protected] 20 points 7 months ago

As a podman user myself, they're essentially the same. I look at the docker documentation when learning new things about podman. 99.9% of the time, it's exactly the same. For the features that aren't in podman, you can use the podman-docker package. This gets you a daemon so you can have some docker-specific features such as a container being able to start/stop other containers by mounting the socket as a volume, and it allows you to use docker-compose.

[–] [email protected] 19 points 7 months ago

Docker is more ubiquitous, Podman has use cases that diverge from Docker.

Discover the use case and decide from there.

That said docker is a good starting point, their documentation is pretty great and once you know docker you’ll better appreciate why podman is different.

[–] [email protected] 17 points 7 months ago (1 children)

It's easier to start with docker first simply because of the sheer amount of learning resources available on the internet. If you're having issues, you can usually find a solution quickly with a search engine.

That's being said, there's not much differences on how to use them these days. You can even run docker compose on podman.

[–] [email protected] 5 points 7 months ago (2 children)

I've read somewhere on lemmy that the podman-compose is unmaintained and shouldn't be used. Can't find it now thought.

[–] [email protected] 11 points 7 months ago
load more comments (1 replies)
[–] [email protected] 15 points 7 months ago (1 children)

You didn't say what's your goal. What do you want to achieve? For instance, if you work in IT you should probably learn Docker unless Podman is more relevant in your actual daily tasks.

[–] [email protected] 4 points 7 months ago (1 children)

My goal is selfhosting stuff mainly on my raspberry pi. I'm sure I'm not going to work in IT for 3 years and probably not for at least few years after that.

[–] [email protected] 5 points 7 months ago

Then just go for Docker. Otherwise you may make it unnecessarily difficult for yourself and get discouraged. In a few years you may revisit the question and see if you still have an interest in podman.

[–] [email protected] 9 points 7 months ago

They're pretty much the same. Use docker documentation for learning, but actually use podman, because it's nicer to use (doesn't require root, easier to install on many Linux distributions).

[–] [email protected] 9 points 7 months ago (1 children)

Honestly, if you have never used containers before I would suggest starting with docker as it has more readily accessible beginner walk through and tutorials. From there, you will have a good idea as to switching to podman is the right move for you or not.

Personally, I started with docker and haven’t moved from there since I don’t see a need (yet). I have dozens of services running on docker. I don’t know how heavy of a lift it would be to learn podman but like I said, I don’t feel the need to do so.

Maybe try out both and see which one you like more?

[–] [email protected] 11 points 7 months ago (1 children)

Just to offer the other perspective. I started with podman years ago. I knew very little about containers and I would say it made the learbing curve a lot steeper. Most guides and README's use docker and when things didnt work I had to figure out if it was networking, selinux, rootless, not having the docker daemon, etc... without understanding fully what those things were because I didn't know docker. But when I started running stuff on kubernetes, it was really easy. Pods in podman are isomorphic to kubernetes pods. I think the pain was worth it, but it was definitely not easy at the time. Documentation, guides, and networking have improved since then, so it may not be as big of a deal now

load more comments (1 replies)
[–] [email protected] 9 points 7 months ago

I tried out podman at first, but I found many docker instances simply provide a string of crap instead of explanations. It was easy to get a grasp of how docker worked, and now that I have an idea I feel like I could jump into podman better.

[–] [email protected] 7 points 7 months ago

Both. Start with docker as there's a buttload of tutorials. Once you're familiar with it jump to podman. Learn the differences, use both for a while and decide what suits you best.

[–] [email protected] 7 points 7 months ago

Both. They're pretty damn similar.

[–] [email protected] 6 points 7 months ago (1 children)

They're very similar so you pretty much can't go wrong. Podman, I believe, is more secure by default (or aims to be) so might run into more roadblocks with its use.

load more comments (1 replies)
[–] [email protected] 6 points 7 months ago

Doesn't really matter for basic stuff as it will be the same.

Once you get into container orchestration the differences start and then you basically need to decide what you want to get out of it.

[–] [email protected] 6 points 7 months ago (3 children)

Docker, there are more resources for it and once you know it Podman should be an easy migration if you want to. Also I'm not sure about your claim that Podman is more FOSS than docker, it's "better" because it doesn't run as root, but other than that I don't know of any advantages to it that are not a derivation of "it runs as a regular user".

[–] [email protected] 6 points 7 months ago (4 children)

Also I’m not sure about your claim that Podman is more FOSS than docker

The issue with Docker isn't the core product itself, is the ecosystem, it's the DockerHub, Kubernetes etc.

load more comments (4 replies)
[–] [email protected] 3 points 7 months ago

On the same machine I have Docker running as root and not as root. I choose which version, root-ful/root-less depending on what the container needs to do.

I think the only advantage is that Podman runs as root-less out of the box, where with Docker you have to do a few extra steps once it's installed.

load more comments (1 replies)
[–] [email protected] 6 points 7 months ago

Still haven't looked into podman properly, but docker is much easier to learn because as you said there's a lot more material available online. I'd say start with Docker, and if in the future you will find out podman better fits your needs you can always switch (they should not be that different)

[–] [email protected] 5 points 7 months ago

Docker and docker-compose. Then learn podman after you have some experience, if you want to...

Or jump into kubernetes (or minikube) instead of podman if you want to do highly useful things.

But first, get comfortable building images with a Dockerfile, and then running them in a meaningful way, and networking them, and locking them down.

[–] [email protected] 5 points 7 months ago
[–] [email protected] 5 points 7 months ago (2 children)
load more comments (2 replies)
[–] [email protected] 4 points 7 months ago

Podman only if you really care about using FOSS, having first-class rootless mode, and don't mind the hassle of scarce learning resource and tutorials on all Podman features that are different from docker.

Otherwise docker.

[–] [email protected] 3 points 7 months ago (2 children)

Here goes my experience.

When I started the self hosted trip, I was against containers and tried to avoid them at all costs. Then I learned about containers, and now I still am against containers but less vividly so. I have used them and still use them.

Containers are good for the self hoster because they deliver fast deploy and easy testing of lots of services quickly. They are good for developers because they can provide one common installation approach that reduces greatly user issues and support requests.

But containers also have downsides as well. First of all they make the user dumber. Instead of learning something new, you blindly "compose pull & up" your way. Easy, but it's dumbifier and that's not a good thing. Second, there is a dangerous trend where projects only release containers, and that's bad for freedom of choice (bare metal install, as complex as it might be, need to always be possible) and while I am aware that you can download an image and extract the files inside, that's more an hack than a solution. Third, with containers you are forced to use whatever deployment the devs have chosen for you. Maybe I don't want 10 postgres instances one for each service, or maybe I already have my nginx reverse proxy or so. I have seen projects release different composer files for different scenarios, but at that point I would prefer to deploy on bare metal.

Said so, containers are not avoidable today, so study and embrace them, you will not be disappointed as its a cool piece of tech. But please stay clear of docker and go podman instead. Podman doesn't rely on a potentially insecure socket and does not require an always running daemon. Podman also by default doesn't force you to run services as root which you should never do. Also, networking feels clearer on podman and podman feels more .modern by using nft instead of iptables. Yes most of this can be fixed on docker, but since podman is a drop in replacement, why bother? Also, podman is truly open source while docker, shockingly, its not.

Here is my wiki page on the subject: https://wiki.gardiol.org/doku.php?id=gentoo:containers feel free to read it.

One last thought: updating containers should not be taken lightly. Its so easy and fast that you might be tempted to setup cron jobs or install watchtower, but you will end sooner or later with a broken service and lost data. So backup, always backup, and keep updating with rationale.

Tldr: containers are unavoidable today and are a cool piece of tech worth investigating. Don't blindly use them as there are security issues involved, and I hope the trend of making containers the only way doesn't take hold, because containers also make self hosters dumber and that's not good.

[–] [email protected] 3 points 7 months ago (5 children)

First of all they make the user dumber. Instead of learning something new, you blindly “compose pull & up” your way. Easy, but it’s dumbifier and that’s not a good thing

I don't like this Docker trend because, besides what you've said, it 1) leads you towards a dependence on property repositories and 2) robs you from the experience of learning Linux (more later on) but I it does lower the bar to newcomers and let's you setup something really fast. In my opinion you should be very skeptical about everything that is "sold to the masses", just go with a simple Debian system (command line only) SSH into it and install what you really need, take your time to learn Linux and whatnot.

there is a dangerous trend where projects only release containers, and that’s bad for freedom of choice (bare metal install, as complex as it might be, need to always be possible) and while I am aware that you can download an image and extract the files inside, that’s more an hack than a solution

And the second danger there is that when developers don't have to consider the setup of a their solution the code tends to be worse. Why bother with having single binaries, stuff that is easy to understand and properly document things when you can just pull 100 dependencies and compose files? :) This is the unfortunate reality of modern software.

Third, with containers you are forced to use whatever deployment the devs have chosen for you. Maybe I don’t want 10 postgres instances one for each service, or maybe I already have my nginx reverse proxy or so

See? Poorly written software. Not designed to be sane and reasonable and integrate with existing stuff.

But be aware that containers are not the solution to selfhosting-made-easy and, specifically, containers havebeen created to solve different issues than self-hosting!

Your article said it all and is very well written. Let me expand a bit into the "different issues":

The thing with Docker is that people don’t want to learn how to use Linux and are buying into an overhyped solution that makes their life easier without understanding the long term consequences. Most of the pro-Docker arguments go around security, reproducibility and that’s mostly BS because 1) systemd can provide as much isolation a docker containers and 2) there are other container solutions and nobody cares about them.

Companies such as Microsoft and GitHub are all about re-creating and re-configuring the way people develop software so everyone will be hostage of their platforms - that's why nowadays everything and everyone is pushing for Docker/DockerHub/Kubernetes, GitHub actions and whatnot. We now have a generation that doesn’t understand the basic of their tech stack, about networking, about DNS, about how to deploy a simple thing into a server that doesn’t use some Docker BS or isn’t a 3rd party cloud xyz deploy-from-github service.

Before anyone comments that Docker isn’t totally proprietary and there’s Podman consider the following: It doesn’t really matter if there are truly open-source and open ecosystems of containerization technologies. In the end people/companies will pick the proprietary / closed option just because “it’s easier to use” or some other specific thing that will be good on the short term and very bad on the long term.

Docker may make development and deployment very easy and lowered the bar for newcomers have the dark side of being designed to reconfigure and envelope the way development gets done so someone can profit from it. That is sad and above all set dangerous precedents and creates generations of engineers and developers that don’t have truly open tools like we did. There’s LOT of money into transitioning everyone to the “deploy-from-github-to-cloud-x-with-hooks” model so those companies will keep pushing for it.

At the end of the day technologies like Docker are about commoditizing development and about creating a negative feedback loop around it that never ends. Yes, I say commoditizing development because if you look at it those techs only make it easier for the entry level developer and companies instead of hiring developers for their knowledge and ability to develop they’re just hiring “cheap monkeys” that are able to configure those technologies and cloud platforms to deliver something.

Successful cloud companies are not longer about selling infrastructure, we're past that - the profit is now in transforming developer knowledge into products/services that can be bought with a click.

[–] [email protected] 3 points 7 months ago (1 children)

There is a lot of truth in your words.

Unfortunately, things will not change.

At least let's use podman and I will keep fighting for containers being at least optional.

[–] [email protected] 2 points 7 months ago

At least let’s use podman and I will keep fighting for containers being at least optional.

Well, systemd can also provide as much isolation and security. It's another option... :) as well as LXC.

load more comments (4 replies)
[–] [email protected] 2 points 7 months ago (2 children)

I don't agree with the premise of your comment about containers. I think most of the downsides you listed are misplaced.

First of all they make the user dumber. Instead of learning something new, you blindly "compose pull & up" your way. Easy, but it's dumbifier and that's not a good thing.

I'd argue, that actually using containers properly requires very solid Linux skills. If someone indeed blindly "compose pull & up" their stuff, this is no different than blind curl | sudo bash which is still very common. People are going to muddle through the installation copy pasting stuff no matter what. I don't see why containers and compose files would be any different than pipe to bash or random reddit comment with "step by step instructions". Look at any forum where end users aren't technically strong and you'll see the same (emulation forums, raspberry pi based stuff, home automation,..) - random shell scripts, rm -rf this ; chmod 777 that

Containers are just another piece of software that someone can and will run blindly. But I don't see why you'd single them out here.

Second, there is a dangerous trend where projects only release containers, and that's bad for freedom of choice

As a developer I can't agree here. The docker images (not "containers" to be precise) are not there replacing deb packages. They are there because it's easy to provide image. It's much harder to release a set of debs, rpms and whatnot for distribution the developer isn't even using. The other options wouldn't even be there in the first place, because there's only so many hours in a day and my open source work is not paying my bills most of the time. (patches and continued maintenance is of course welcome) So the alternative would be just the source code, which you still get. No one is limiting your options there. If anything the Dockerfile at least shows exactly how you can build the software yourself even without using docker. It's just bash script with extra isolation.

I am aware that you can download an image and extract the files inside, that's more an hack than a solution.

Yeah please don't do that. It's probably not a good idea. Just build the binary or whatever you're trying to use yourself. The binaries in image often depend on libraries inside said image which can be different from your system.

Third, with containers you are forced to use whatever deployment the devs have chosen for you. Maybe I don't want 10 postgres instances one for each service, or maybe I already have my nginx reverse proxy or so.

It might be easier (effort-wise) but you're certainly not forced. At the very least you can clone the repo and just edit the Dockerfile to your liking. With compose file it's the same story, just edit the thing. Or don't use it at all. I frequently use compose file just for reference/documentation and run software as a set of systemd units in Nix. You do you. You don't have to follow a path that someone paved if you don't like the destination. Remember that it's often someone's free time that paid for this path, they are not obliged to provide perfect solution for you. They are not taking anything away from you by providing solution that someone else can use.

load more comments (2 replies)
[–] [email protected] 3 points 7 months ago* (last edited 7 months ago)

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

Fewer Letters More Letters
DNS Domain Name Service/System
Git Popular version control system, primarily for code
HTTP Hypertext Transfer Protocol, the Web
LXC Linux Containers
Plex Brand of media server package
SSH Secure Shell for remote terminal access
nginx Popular HTTP server

[Thread #623 for this sub, first seen 23rd Mar 2024, 07:55] [FAQ] [Full list] [Contact] [Source code]

[–] [email protected] 2 points 7 months ago

Learn Docker first, it will be faster and easier. It will both give you an intro to containers and you'll get some practical use for your self hosting needs.

If you're still curious later you can go deeper into Podman and other container technology.

[–] [email protected] 2 points 7 months ago

This is a bit of a Pokemon starter question. Just pick one and see where it takes you! They do roughly the same job, especially now that docker has a rootless mode. At the end of the day you're learning a new technology and that's a positive thing.

[–] [email protected] 2 points 7 months ago (3 children)

not having to change habits later.

If everybody thought like this, we would still be banging rocks together.
I am not sure about your use case, but IMO learning Docker first would be a good default. It is more wide-spread than podman. If you want (or need) to, moving on to podman would probably not be too big a step.

load more comments (3 replies)
load more comments
view more: next ›