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

Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

github.com

Post reply on HN
Print view View original

131–140 of 151 posts

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#131

Post by infogulch »

light_hue_1 wrote: post #130
infogulch wrote: post #124

Earlier quoted context omitted.

I agree that it should be possible to disable the default registry, but I'm not sure I agree with allowing you to override it. (These requests appear to be conflated in various comments.) Use your own registry by specifying the domain first `myregistry.example.com/repo/image`; an unadorned `repo/image` being globally reserved as shorthand for `registry.docker.io/repo/image` seems fine. Allowing overriding the meaning…

This suggestion is a security nightmare! Anyone is one typo away from installing random junk from the internet on your machines. No one should be using docker in production while it can connect to a public registry where you have zero control of its contents.

Did you read my comment? Because I can't find any interpretation of your response that makes sense assuming you comprehend the actual content of my statements.

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#132

Post by kbenson »

intsunny wrote: post #50
kbenson wrote: post #25

Earlier quoted context omitted.

I think a really big part of it was where Red Hat asked Docker to accept their patch that allowed people to run docker with local registries only (no docker.io), and were told Docker would not be accepting that patch, and to go pound sand if they didn't like it (eh, so maybe not so forcefully). The first thing I tried to figure out when looking into Docker for work was how to limit the registries it would look at to…

Fascinating history, is there a PR link for this exchange between Redhat and Docker?

The main ones I know of are https://github.com/moby/moby/pull/10411 and https://github.com/moby/moby/issues/11816

There's a comment in the second link that's references in the first one that explains the rationale for the pull request refusal:

Like pointed out earlier (#11815), this would fragment the namespace, and hurt the community pretty badly, making dockerfiles no longer portable.

You can see that full comment at https://github.com/moby/moby/issues/11816#issuecomment-86732..., and it also references that this will be possible with signed images, so I don't know what happened after that (but that was over 6 years ago).

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#133

Post by kbenson »

infogulch wrote: post #124
kbenson wrote: post #25

Earlier quoted context omitted.

I think a really big part of it was where Red Hat asked Docker to accept their patch that allowed people to run docker with local registries only (no docker.io), and were told Docker would not be accepting that patch, and to go pound sand if they didn't like it (eh, so maybe not so forcefully). The first thing I tried to figure out when looking into Docker for work was how to limit the registries it would look at to…

I agree that it should be possible to disable the default registry, but I'm not sure I agree with allowing you to override it. (These requests appear to be conflated in various comments.) Use your own registry by specifying the domain first `myregistry.example.com/repo/image`; an unadorned `repo/image` being globally reserved as shorthand for `registry.docker.io/repo/image` seems fine. Allowing overriding the meaning…

I believe that was acknowledged in some of the pull requests, and also a problem with correctly using credentials for repositories and various solutions were proposed (see one of my other comments for links). Ultimately, the reason given in the pull requests I saw was along the lines of "it will fracture the namespace and hurt the community".

Disabling all registries except for those whitelisted and requiring full names for those would probably have been sufficient for this problem, and not fractured the community IMO. There's a difference between what you allow in dev and what you allow in production, where you should have a chance to vet all new requirements and ensure they are appropriate. It's just unacceptable for some organizations to allow stuff to be as ad hoc as that, as much as Docker might want to inject itself into their processes at that level.

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#134

Post by takeda »

heavyset_go wrote: post #128
takeda wrote: post #34

Earlier quoted context omitted.

A lot of people assume that, but it's only partially true. Darwin's userland is taken from FreeBSD, the kernel is from NeXTSTEP, although it also borrowed some things from FreeBSD, but I don't think they incorporated jails[1]. [1] https://github.com/apple/darwin-xnu/search?q=jail

XNU itself is Mach plus a BSD "personality" taken from FreeBSD[1]. [1] https://developer.apple.com/library/archive/documentation/Da...

You are right, although doesn't look like jails was included.

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#135

Post by denkmoon »

nsonha wrote: post #69
denkmoon wrote: post #9

Earlier quoted context omitted.

I think you'd be surprised how often the route from dev to prod is "copy it from my machine into the cloud". Good practices start at home.

it's docker that requires root, you don't use root yourself

It's perfectly possible to use podman rootless. Presumably docker too, but I only have experience with podman. That is, the podman process does not have root privileges.

Maybe excessive, maybe a good prophylactic for potentially damaging NPM packages (for example) to not get root on my CI infrastructure.

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#136

Post by simnalamburt »

nickysielicki wrote: post #129
simnalamburt wrote: post #66

Hi, podman-apple-silicon developer here! I want to share some FAQs about this project. :) Q: Does this run amd64 docker images or aarch64 docker images? A: aarch64 images currently, but I'm going to patch podman to make it possible to run both amd64 image and aarch64 image. All I have to do for this is to make QEMU call and Linux image configurable, so it won't be very hard. However, if you are running amd64 images,…

Q: What sort of contributions/help are you looking for?

A: Testing, dogfeeding, bug reports! I can handle code-related jobs but I alone cannot handle testing all variable usecases! ;) Thanks!

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#137

Post by infogulch »

kbenson wrote: post #133
infogulch wrote: post #124

Earlier quoted context omitted.

I agree that it should be possible to disable the default registry, but I'm not sure I agree with allowing you to override it. (These requests appear to be conflated in various comments.) Use your own registry by specifying the domain first `myregistry.example.com/repo/image`; an unadorned `repo/image` being globally reserved as shorthand for `registry.docker.io/repo/image` seems fine. Allowing overriding the meaning…

I believe that was acknowledged in some of the pull requests, and also a problem with correctly using credentials for repositories and various solutions were proposed (see one of my other comments for links). Ultimately, the reason given in the pull requests I saw was along the lines of "it will fracture the namespace and hurt the community". Disabling all registries except for those whitelisted and requiring full na…

> Disabling all registries except for those whitelisted and requiring full names for those would probably have been sufficient for this problem, and not fractured the community IMO.

Yes this is what I was getting at. You don't need to override the meaning of image names, you just need to be able to disable registries outside your control and prefix all your images. It's like an additive vs subtractive blindness effect that caused people to miss this solution.

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#138

Post by kbenson »

infogulch wrote: post #137
kbenson wrote: post #133

Earlier quoted context omitted.

I believe that was acknowledged in some of the pull requests, and also a problem with correctly using credentials for repositories and various solutions were proposed (see one of my other comments for links). Ultimately, the reason given in the pull requests I saw was along the lines of "it will fracture the namespace and hurt the community". Disabling all registries except for those whitelisted and requiring full na…

> Disabling all registries except for those whitelisted and requiring full names for those would probably have been sufficient for this problem, and not fractured the community IMO. Yes this is what I was getting at. You don't need to override the meaning of image names, you just need to be able to disable registries outside your control and prefix all your images. It's like an additive vs subtractive blindness effec…

It wasn't missed, from what I saw in the issue and pull request. It was offered, and ignored.

Part of me thinks that's a shame, because it seems like it's just that a for-profit entity behind the project was the only reason for doing so, but at the same time, the outcome isn't bad I think. Having multiple high-quality choices with different driving causes (and organizations) behind them is more beneficial in the long run than just one. Competition is good, even in open source, most the time.

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#139

Post by eru »

goodpoint wrote: post #86
eru wrote: post #67

Earlier quoted context omitted.

Well, it's also a good practice the other way round: If you can make your dev setup model the production setup, that's one less thing to worry about.

That's what VMs are for.

VMs are one tool for that. But they are neither necessary nor sufficient.

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#140

Post by nicwolff »

gizdan wrote: post #127
TobTobXX wrote: post #125

Earlier quoted context omitted.

There's also podman-compose, which does exactly what docker-compose does, but with podman.

podman-compose is sadly not as good docker-compose. It simply converts compose yaml files into podman commands. As an alternative, as of podman v3 (rootfull) and v3.2 (rootless) podman has an optional podman socket you can enable. The API is docker compatible, thus allows for full docker-compose support, and will take any other application that interacts with the docker api directly.

Is anyone successfully using podman with docker-compose in the "locally remote" style that Docker Desktop makes simple? E.g. running `podman machine start` on a Mac, then `docker-compose up` to start all the containers in the current dir's `docker-compose.yml`, with mounts from the host and a default network. I'm following https://github.com/containers/podman/issues/11389 and https://github.com/containers/podman/issues/11397
Post reply on HN