Is there a way to build a Windows container image on my PC WITHOUT docker?

[DonSchenck]

I want (need) to be able to build a Windows container image on my local PC (Windows 10 Enterprise) WITHOUT installing docker. Is there a lower-level API I can use?

[lippertmarkus]

Container images are just tar archives that are layered on top of each other during runtime. So as long as you got the correct directory structure and file attributes in your tar archive, you don't need docker and just some archiving lib.

There's crane which creates such tar archives. I've written about how it works under the hood here: https://lippertmarkus.com/2022/03/30/speed-image-builds-crane/

[ghost]

This issue has been open for 30 days with no updates.
@Juarezhm, please provide an update or close this issue.

[ghost]

This issue has been open for 30 days with no updates.
@Juarezhm, please provide an update or close this issue.

[ghost]

This issue has been open for 30 days with no updates.
@Juarezhm, please provide an update or close this issue.

[microsoft-github-policy-service]

This issue has been open for 30 days with no updates.
@Juarezhm, please provide an update or close this issue.

[microsoft-github-policy-service]

This issue has been open for 30 days with no updates.
@Juarezhm, please provide an update or close this issue.

[microsoft-github-policy-service]

This issue has been open for 30 days with no updates.
@Juarezhm, please provide an update or close this issue.

[microsoft-github-policy-service]

This issue has been open for 30 days with no updates.
@Juarezhm, please provide an update or close this issue.

[ntrappe-msft]

@DonSchenck were you able to find a lower-level API or have success using crane to build Windows Container images?

[DonSchenck]

No :(

[ntrappe-msft]

Out of curiosity, can I ask why you don't want/can't install Docker? And what would you like out of an alternative?

[DonSchenck]

Good and fair question.

I want to see Windows container build put into Podman, the open source alternative to docker.

DISCLOSURE: I work for Red Hat. I am biased.

[microsoft-github-policy-service]

This issue has been open for 30 days with no updates.
@Juarezhm, please provide an update or close this issue.

[microsoft-github-policy-service]

This issue has been open for 30 days with no updates.
@Juarezhm, please provide an update or close this issue.

[microsoft-github-policy-service]

This issue has been open for 30 days with no updates.
@Juarezhm, please provide an update or close this issue.

[fady-azmy-msft]

Hey @DonSchenck, for the build story without using docker, we're looking at building windows container images with Build Kit.

[TBBle]

To address the intended specific use-case of doing Windows Container image builds in Podman: Firstly, I don't actually know anything about the Podman internals. I've only interacted with it through the docker CLI-compatibility layer.

Firstly, if Podman already supports delegating image builds to a BuildKit instance using the containerd worker on top of containerd (basically what BuildX does for Docker) then you can track #34 and once its work moves from BuildKit to BuildX, then all the downstream ingredients you need for Podman should be ready.

Otherwise I've tried to provide some guidance below as to what layers of the currently-in-development BuildKit stack (#34) you need to reimplement locally for Podman.

---

Does Podman use a self-managed containerd instance underneath? If so, then it has (in containerd 1.7) support to import, export, create, and mount (to the host or inside a container) layers for Windows Containers. (Actually, mounting to the host probably relies on being able to use containerd's mount API as a library, I'm not sure if it's remotely callable by GRPC or not.)

If not, is it using hcsshim directly? All of the above is actually provided by hcsshim and containerd is a (fairly) thin layer on top of that functionality. This would require being developed in Go though.

If not using containerd, nor written in Go, then the fallback path is to write code somewhat like hcsshim (or just port the required parts of hcsshim, it's MIT licensed) in a library, either using an existing HCS API-wrapping library (I think there's one for .NET that's 6 years old and unmaintained, not sure about any other languages) or directly calling the HCS APIs and friends (BindFilter, ComputeStorage, etc).

Assuming you can already import and run Windows containers, you've already made a choice about the above, and need to follow through with the relevant work to implement or use the rest (as BuildKit is doing, visible in #34).

---

Once you have the above functionality by hook or crook, it's simply a matter of implementing the various primitives you already have for building containers, if you're not using something that does that already, like BuildKit.

For the Dockerfile image build format, the ability to mount a new image layer locally (for COPY, ADD, WORKDIR, etc), and to execute a container on a new layer (RUN, USER, etc) is most of what you need. You can then unmount (or terminate the container), export that layer to a tarstream (and also import it again if you need to want to build more layers on top) and you're done.

If you have other primitives in your local image build format, you may find limitations in the Windows Containers ecosystem, e.g., I don't know off-hand if you can snapshot a running container, and if you can, you probably wouldn't be able to export a diff between the snapshot and any subsequent layer from the same running container.

The OCI image structure between Windows and Linux is (intentionally) very similar, so once you're able to get tar streams for new layers based on your image build format, and deal with user-identification (or defer the hard parts), the rest of building a Windows Container image is just some call-outs in your existing pipeline to deal with things like Windows kernel ABI compatibility properties, or the occasional \ character in a path that you're not handling carefully.

---

Technically this applies to any other container-build stack, but a big limitation right now is that rootless-mode is impossible with the current Windows Containers filesystem implementation as you need elevation to be able to mount layers on the host and (maybe) to run containers, and system backup/restore privileges to import (and export, I think) the layer data.

There's a new filesystem being developed that should remove some of those privilege requirements, but initially it's only really being implemented for importing layers, not exporting/diffing/mounting.

---

@DonSchenck, I hope that helps?

---

Edit: I had a quick look, and it looks like Podman doesn't currently support Windows Containers at all, and has no plans or maintainer-headspace to do so.

So yeah, all the pieces you need are available (and it seems Podman is written in Go, so the fundamental primitives are already available) but it sounds like it's not practical from the Podman end right now.

[microsoft-github-policy-service]

This issue has been open for 30 days with no updates.
@Juarezhm, please provide an update or close this issue.

[fady-azmy-msft]

Closing issue because it's going stale. Thank you @TBBle for your response as well!