My homebrew packages. Contribute to simnalamburt/homebrew-x development by creating an account on GitHub.
Read the original article
Comments
By simnalamburt 2021-09-069:342 reply 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, you will have to bear the performance overhead due to CPU emulation.
Q: Is this toy or are you actually going to maintain this?
A: I'm DevOps engineer and I made podman-apple-silicon to actually use this in my day job.
Q: Are you going to merge this to the upstream?
A: I'll keep trying, but it won't be easy unless QEMU merges Alex Graf's Hypervisor.framework patch.
I may forgot to check HackerNews, so please feel free to ask me anything about podman-apple-silicon at https://twitter.com/simnalamburt
By traverseda 2021-09-0613:391 reply > I'm going to patch podman to make it possible to run both amd64 image and aarch64 image
From what I understand, if you had working QEMU-static and binfmt, wouldn't cross-architecture containers just work? I've used that a lot in chroots, and I'm confused as to why that wouldn't just transparently work in this case.
Are you talking about just making that process easier? Does podman enforce extra checks that prevent you from using binfmt?
By simnalamburt 2021-09-0614:201 reply If you just switch the binary you’re 90% finished but there are some chores to make it perfect
1. The arguments given to the qemu should be changed by the CPU arch. For example, AArch64 uses ‘-accel=hvf’ while amd64 in Apple Silicon must use ‘-accel=tcg’. AArch64 requires ‘-cpu’ option whild amd64 does not. etc. And currently, the arguments of QEMU is half-way hardcoded to the podman source code.
2. You should change the linux image when you change the CPU arch. Currently, podman always downloads the Linux image whose CPU arch is same with host’s CPU arch. This is where configuration should be added.
3. aarch64 uses UEFI while amd64 don’t need to (I don’t know why)
By Nullabillity 2021-09-0822:44 > 3. aarch64 uses UEFI while amd64 don’t need to (I don’t know why)
Sounds like amd64 is falling back to BIOS, while aarch64 never really had any other standard than UEFI. You should be able to run UEFI for amd64 too if you force the machine type to pc-q35-6.1 (or whatever QEMU version you're using).
By nickysielicki 2021-09-0618:291 reply Q: What sort of contributions/help are you looking for?
By simnalamburt 2021-09-072:16 A: Testing, dogfeeding, bug reports! I can handle code-related jobs but I alone cannot handle testing all variable usecases! ;) Thanks!
Tangentially, I wonder if Moby underestimated the amount of human hours that were instantly allocated to alternatives as soon as they announced Docker Desktop was going paid. (I don't know if this project is a consequence of that announcement or not.)
Hopefully Podman will be able to capitalize on this event and get the polish needed for widespread use.
I suspect the push for podman was more about how docker ignored CGroupsV2 for so long that Fedora eventually turned it on anyway which broke docker and then told users to switch to podman.
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 only be our own when used in production, and I was surprised to find out you can't (at least not without a hack to make it think it's using a mirror and just hitting your registry first).
Docker does this a lot. For example, we were trying to turn off gzipping images on the wire when pulling because it actually cost more when done from the intranet.
You can't. And modifying the source was so convoluted that we gave up.
Then we needed to clean up docker (before there were commands to do that) when it started to eat up all of the disk space.
To our (un)surprise, Docker uses 3 (!!) different storage formats, many of them having redundant information, and editing one of them would cause the other to be corrupted.
One was a binary database format that was specific to Go and didn't have any utility CLI to work with, so you had to write a programmatic interface with it just to edit it.
Or how about the fact that even if you issue commands directly to docker over the HTTP Unix socket, it will deadlock if you issue too many commands to it? This became our nightmare when trying to implement one of the first iterations of custom deployment backends at ZEIT. In fact, the entire project failed because of docker (there was no great alternative at the time).
I am honestly wondering more about your specific use case. Does the CPU cost outweigh the storage cost? Is it a timing problem (speedup) or are you at such large scale (on premise)?
Maybe where I'm getting at is, I can think of 99 problems but docker gzip ain't one :) how was this a priority (at some point)
By infogulch 2021-09-0616:05 Pretty sure it's CPU vs network not CPU vs storage. A fast internal network can be cheap compared to the cpu required to pack/unpack images on every download. I wonder if choosing a fast-to-decompress algorithm like zstd would change that.
By junon 2021-09-0616:17 As we were a deployment company (ZEIT) our usecase was quite different.
And yes, as the other person mentioned, it was on the wire GZIP, not storage concerns.
Fascinating history, is there a PR link for this exchange between Redhat and Docker?
By SSLy 2021-09-068:56 By kbenson 2021-09-0622:24 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).
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 of `repo/image` would be a support nightmare for both moby and internal IT, just use qualified names.
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.
> 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.
By kbenson 2021-09-074:55 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.
By light_hue_1 2021-09-0618:361 reply 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.
By light_hue_1 2021-09-115:45 I did read the comment. And I comprehended the content of the statements. And I'm scared that this obvious security risk isn't horrifying to you.
> 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 of `repo/image` would be a support nightmare for both moby and internal IT, just use qualified names.
Literally anyone in your company can forget to say `myregistry.example.com/` at any moment. And then your whole infrastructure runs on some random image that you didn't vet. You're a typo away from having your machines owned, your entire infrastructure falling over, your data being exposed to the anyone.
This is no way to live and it's no way to run a company.
I hadn't heard about CGroupsV2. Apparently it's been in the kernel since 2015. Seems like a better design.
https://thenewstack.io/linux-cgroups-v2-brings-rootless-cont...
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2...
Every distro had it turned off for ages because turning it on would break docker. So eventually fedora decided docker was never going to added it and turned it on anyway. Then shortly after, docker adds support
By vetinari 2021-09-0615:22 Between fedora and docker, it didn't help, that docker made a first release for current fedora version always about a month before fedora was going to make a new release (i.e. with fedora's 6 month release cycle, the corresponding docker release for that fedora version was 5 months late).
By cozzyd 2021-09-065:26 And EL8 for that matter
Podman's been a great tool (on Linux) for a while, it's my daily driver. Rootless, no daemon and networking nonsense, and docker-compose can be replaced with real K8s pod definitions for the most part. I'm actually really happy to see the zeal that has come to it from docker's changes - thank you docker ;)
> docker-compose can be replaced with real K8s pod definitions for the most part
Could you elaborate on this part? Are you running in Kubernetes or somehow using the pod definition format with Podman? I'd like a way to declaratively specify my Podman pods without docker-compose and friends.
Podman has built in support for K8s' Pod definitions. I've never used it so not sure how good (or bad) it is, but it is possible.
It is also able to generate pod definitions from created containers, as well as generate systemd units that you can then enable allowing systemd to manage your pods/containers.
By alias_neo 2021-09-0611:54 Incredible, I didn't know any of this and I've been using Podman for ~1 year.
Thanks, some reading for me to do, will be testing both those features out imminently!
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.
By nicwolff 2021-09-0718:21 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
Most people don't care about Podman and will keep using Docker. There is no alternative on Windows so how exactly podman is a replacement?
Also I don't trust Red Hat / IBM with the CentOS fiasco.
By cmeacham98 2021-09-0614:25 Not everyone has to use the same tool. Even if you continue to use only docker, podman helps you by competing with docker and driving them to improve their software (ex: cgroupsv2).
Also, I believe podman works in WSL with some tweaks.
By WhyNotHugo 2021-09-0615:151 reply FWIW, docker itself doesn't run on Windows either -- you have to run docker on Linux on Windows.
You can do the same thing for podman: run podman on Linux on Windows.
Probably the link on this very article is a good starting point for doing that.
By detaro 2021-09-0615:17 Docker Desktop can run Windows Containers (or a Linux VM to run Linux containers).
Moby has the power of using a well-established name ("I want to have Docker on my desktop, let's google that, oh, hi Docker Desktop!") that also appears in a lot of tutorials and training material, both aspects that developers tend not to spend time on.
Given how often I still stumble over massively obsolete documentation and "helpful" articles from 15 to 20 years ago, I'd say they are safe.
By dotancohen 2021-09-0613:58 Safe as Open Office is probably a better analogy. MySQL is still very widely deployed. But, yes, your point is very apt!
It looks like the real nice thing here is having a formula for QEMU with the ARM patch applied: https://github.com/simnalamburt/qemu/tree/hvf
With this I believe you could also used [nerd](https://github.com/containerd/nerdctl) instead of podman but I haven't tested it yet.
Edit: It works. Had a bit of trouble since I wanted to uninstall the "real" QEMU first, but `lima` still depended on it, and then installing the patched QEMU needed to update the version of `lima` I had installed, which then tried to reinstall QEMU, which failed because of some symlinks which were now owned by the patched QEMU...
By piaste 2021-09-0610:02 > With this I believe you could also used [nerd](https://github.com/containerd/nerdctl) instead of podman but I haven't tested it yet.
This is the first time I hear of nerdctl and it's _very_ interesting.
M1 aside, does it work fine on regular arm64 linux? I run a small Raspberry Pi 4B homeserver and I would have used podman for improved security, were it not for the poor/incomplete Compose support, while nerdctl seems to explicitly support it.
By kitd 2021-09-069:42 OT, but I'm impressed you managed to make all those changes within the HN-comment-edit-timeout!
By gizdan 2021-09-0611:35 TIL of nerdctl. Anyone know what the differences between nerdctl and podman are?
