Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Transitioning from Docker to Podman

developers.redhat.com

Post reply on HN
Print view View original

251–260 of 278 posts

Re: Transitioning from Docker to Podman

#251

Post by josephcsible »

jlgaddis wrote: post #245
josephcsible wrote: post #145

Earlier quoted context omitted.

If you want to use btrfs on RHEL8, you still can: go to https://elrepo.org/ and install elrepo-release, then install kernel-ml from their -kernel repo and btrfs-progs from their -testing repo.

... at which point you lose the support you're paying for from Red Hat, thus defeating the purpose of using RHEL in the first place. So if you want to use Btrfs, you might as well use it on something besides RHEL.

Running an unsupported kernel doesn't mean that support won't help you at all. It just means they won't help you with kernel-related issues. There's still a lot of value in support for the rest of the system.

Re: Transitioning from Docker to Podman

#252

Post by Spivak »

throwaway894345 wrote: post #147
deckard1 wrote: post #133

Earlier quoted context omitted.

> The interface to journald is more complicated than it should be but it’s also really powerful I thought the point of logging to stdout (i.e. docker logs) is that you just take that output and dump it to another server for processing and filtering. journald/journalctl seem to be a solution a few decades late to the party. For a single user machine or a single app prod environment, I would take a plaintext log any da…

Exactly this. I just want a stream of logs that I can process with ordinary unix tools without jumping through hoops. I don’t need any extra power for its own sake.

If that’s all you want there’s really no hoops.

   journalctl | grep
Does what you would expect, it will happily (and by default on most distros) forward to syslog if you want files.

The big ease-of-use win for journald is that it captures process stdout. No need to run daemons in the foreground ever.

Re: Transitioning from Docker to Podman

#253

Post by mseidl »

MrBuddyCasino wrote: post #196
mseidl wrote: post #182

Earlier quoted context omitted.

We have our LTSS -> Long term support at SUSE. Just in case you're a big government that wants to throw us lots of money.

Off-topic, but what’s you experience working at Suse? I know a former employee, and what he told me sounded hellish.

I love it. Not that it doesn't have it's issues. I've been here 10 years now though.

Re: Transitioning from Docker to Podman

#254

Post by folmar »

aruggirello wrote: post #188
dariusj18 wrote: post #152

Earlier quoted context omitted.

I think governments prefer redhat because they are consistent and they accept gobs of cash to promise security patches to software that are past their support window.

I don't know about the gobbles of cash, but I'm pretty sure Canonical supports Ubuntu releases way past EOL for paying customers - they call it the ESM (Extended Security Maintenance), which 'provides important security fixes for the kernel and the most essential user space packages in Ubuntu'.

Ubuntu ESM is 8 years, significantly shorter than RedHat's 12 year maximum.

Re: Transitioning from Docker to Podman

#255

Post by mleonhard »

Does Podman let you get the real SHA-256 digest of the image, pull it to a machine, and then launch the image only if it matches the specified SHA-256 digest?

The podman 'create' command docs [1] do not list a '--digest' argument. I found no example of specifying the digest as part of the image name.

Docker does not support this. You can get an image file and calculate the SHA-256 digest of it. But Docker does not let you say "start a container using this particular SHA-256". That's because the SHA-256 that docker uses internally is just a hash of dockerd's internal metadata about the image. That metadata is different on every machine. I felt extremely disappointed when I discovered this. And I lost a lot of respect for the Docker developers.

If you want to deploy based on image hash with Docker, you must add your own verification step before creating each container instance. Terraform's docker plugin does not perform this step. And the local dockerd will not check the SHA-256 on reboot. If you just follow Docker's "best practices" and use the provided tools, all of these sources will needlessly have root on everything you deploy:

- Your docker image repository

- Any machines with credentials to push to your docker image repository (CI system, engineer machines, anyone with access to engineer machine backups)

- Anyone with permission to push any public image that you use. The way most CI systems are configured, all jobs get the same credentials. So this includes your build and test jobs. That fancy linter Docker image you're using? Anyone who can push to its Dockerhub account can replace the image version you selected with one that roots all of your systems.

- Dockerhub itself

Why would RedHat switch to a Docker replacement without this crucial security feature?

Am I missing some important point that makes all of this ok?

[1] http://docs.podman.io/en/latest/markdown/podman-create.1.htm...

Re: Transitioning from Docker to Podman

#256

Post by coldtea »

babarock wrote: post #236
coldtea wrote: post #224

Earlier quoted context omitted.

> One big reason for that seem to be Mac users that only know docker from inside a VM That has not been the case for a good while now... Docker has been running directly on a hypervisor on the Mac.

Honest question, what's the difference between "from inside a VM" and "directly on a hypervisor"? I always thought it meant the same thing.

Well, in the case of Mac, basically performance, as you still need linux libs, kernel API and everything. But it's much lighter-weight than something like Virtualbox, VMWare, etc.

In Linux iirc, a hypervisor can share such resources with the host system (since they are both Linuxes).

Re: Transitioning from Docker to Podman

#259

Post by merb »

tikkabhuna wrote: post #56
yjftsjthsd-h wrote: post #45

Earlier quoted context omitted.

Okay, I want to build a container image using gitlab CI, which runs builds in docker. How would you like me to build an image without using docker in docker, or buildah in docker?

We use kaniko[1] in Gitlab CI and it’s working great for us. It’s annoying the kaniko image requires us to specify the entrypoint. There’s some peculiarities with Dive [2], but otherwise it’s been a very easy migration. [1] https://github.com/GoogleContainerTools/kaniko [2] https://github.com/wagoodman/dive/issues/318

kaniko is really really slow:

    - https://github.com/GoogleContainerTools/kaniko/issues/1392
    - https://github.com/GoogleContainerTools/kaniko/issues/970
    - https://github.com/GoogleContainerTools/kaniko/issues/875
I've observed basically the same stuff.

Re: Transitioning from Docker to Podman

#260

Post by throwaway894345 »

Spivak wrote: post #252
throwaway894345 wrote: post #147

Earlier quoted context omitted.

Exactly this. I just want a stream of logs that I can process with ordinary unix tools without jumping through hoops. I don’t need any extra power for its own sake.

If that’s all you want there’s really no hoops. journalctl | grep Does what you would expect, it will happily (and by default on most distros) forward to syslog if you want files. The big ease-of-use win for journald is that it captures process stdout. No need to run daemons in the foreground ever.

close, but it’s actually

    sudo journalctl -u $service -f | grep
Not a huge deal, but I have to google it every few months because I don’t use it very often.

Note also that if I just want the log stream, I have to pipe through less to get the full log messages. There’s also a flag for it, but I can’t remember my workaround is easier than digging through man pages.

Again, no big deal, just friction. Like everything in the systemd ecosystem—everything is manageable, but it’s tedious.

Post reply on HN