How to run libpod under windows?
That depends on whether you have Windows 10 Pro or not. If you have Windows 10 Pro, you can enable Windows Hyper-V and create a virtual machine running Fedora Atomic Host 28. Then you can log in to the virtual machine and run all the Fedora container tools like podman, buildah, skopeo, etc.
On other versions of Windows, you won't have Hyper-V. You can run either VirtualBox or VMware Workstation to host your Atomic Host, but most people use VirtualBox.
You also can use pypodman on the windows box to interact with podman inside of the VM.
We have no native support for libpod/podman yet. Although we have made efforts to make sure libpod compiles on Windows and Macs, if anyone comes along and was interested in making it work natively.
@jwhonce Could you give @netroby a pointer to how to get pypodman for Windows
As I don't find any satisfying answer, I'll ask here: Does podman depend on the Linux kernel the way Docker does? Would it be possible (in the long run) to use it on mac/windows without a Linux vm? I found this pr, but I'm not really sure what it does.
@znmeb @rhatdan Clarification on this would be highly appreciated. Thanks.
We have made some efforts in the past to make sure libpod/podman would compile and build on a Windows platform natively.
Podman/libpod does not do anything specific to the Linux Kernel, I don't believe.
Theoretically you could use an Window OCI Runtime to run a container, but I think there would need to be a decent amount of work to get it functioning. I am not a Windows Programmer (Have not touched the platform in 17.5 years.) I would figure pain points would be in containers/storage, their is a Windows driver, but I have no idea if it works. We use Boltdb for our database, not sure if that works on Windows. @mheon Do you know? Finally conmon would probably need to be replaced or reworked to make it work on Windows.
BTW If Windows Engineers wanted to work on making it run on WIndows, we would be open to the patches.
Thanks for the update. I personally are more interested in macos, as this is what I use for work, and it would be great to get rid of Docker for mac for what I do. Is this in the scope of podman?
@fwilhe pypodman is our effort to do this. @jwhonce is working on this, and could give you an update. pypodman is a python interface mimicking podman and interacting with podman running within a VM. Sort of the equivalent to boot2docker.
podman running within a VM
So, if I get that right, this does not improve developer workflow on a mac, since I still need a Linux vm. Would be great if the readme could clarify this.
Thanks for the info.
I think native Podman on OS X is probably a lot easier than Podman on Windows would be. A lot of our internals assume POSIX conventions, Conmon will probably compile on OS X without much of an issue, and most of our Linux-specific things are already conditional-compiled as Linux only.
The two big problems in my mind would be containers/storage and an OCI runtime. We'd need a Mac compatible backend for c/storage (VFS might suffice? I don't know enough to say whether it does or doesn't work) to be able to mount images and containers. Further, I don't think there's an OCI compatible runtime available on OS X, so we don't actually have a way of starting containers there (I think there was a project that was running VM-based containers using VirtualBox, similar to Kata containers, but I don't think it's OCI compatible). If these two issues can be solved, I think a port of most functionality (minus rootless and pod support) would be fairly simple.
I don't think anyone is actively working on this (and I doubt any of the core devs will have time for it any time soon), but we'd be more than happy to review and accept patches to accomplish the port.
Thanks for your kind reponse.
For long time read document ,try solution, i found libpod not best tools for me .
It can not provide us benefit like docker.
we run docker on windows for develop.
Run docker build prepare for image build for production.
Most helpful comment
BTW If Windows Engineers wanted to work on making it run on WIndows, we would be open to the patches.