I think from what I’ve read that this is the case, but I’ve read some other info that’s made it less clear to me.
On the second part of the question regarding container engines, I’m pretty sure that may also be correct, and it kinda makes me wonder a little about risks of engine lock-in, but that may be a little out of scope.
In my experience docker will run Linux images everywhere. I believe it uses WSL on windows and a VM on macs.
So it entirely depends on what your engine supports.
I believe there are open standards for the binary format of images so switching engines may be possible. But again depends how the containers are built.
Containers are practically a linux thing. The specs to run containers are open (Open Container Initiative). That’s why if you aren’t on linux, the most common solution is to virtualise linux or add a layer that translates linux syscalls to those on the host OS (e.g windows subsystem for linux). Once the linux environment exists you have multiple orchestrators (docker, podman, kubernetes, etc.). They all either have their own runtime or use an existing one (runc, crun, youki, …).
I haven’t read the OCI specs, but IINM containers are built upon linux primitives (namespaces, cgroups, and I forget the rest).
This is factually wrong. https://learn.microsoft.com/en-us/virtualization/windowscontainers/about/ documents how to use Microsoft Windows containers.
Woah, that’s news to me. Are these OCI containers?
Linux distro is entirely irrelevant. Almost always, the distro is just a particular way of packaging things.
But also, assuming you’re talking about “docker” containers (or rather, OCI containers), then no the OS running the container doesn’t matter. That’s the whole point of containers.
Also what do you mean exactly by “container engine”? Do you mean docker? Because “docker” containers can run on podman, kubernetes, etc
A Linux container can only run on a Linux kernel (and likewise for Windows and Mac). But there are plenty of tools to more-or-less transparently solve that particular problem by e.g. running a virtual machine in the background to host a shared Linux installation that hosts the containers (and then mapping ports and stuff for you).
TIP: programs that run inside docker containers should be compatible with the host system’s kernel.
If you want to run a container targeted for a linux distro on windows, you need some intermediate that will translate Linux sys calls to windows ones. I don’t have experience with this but I believe that’s what WSL accomplishes? Among other things.
Regarding your question about lock-in, if I understand it correctly, you are targeting the kernel really, thats the “engine”. So “lock-in” is about the same as you choosing which OS to target.
If you want to run a container targeted for a linux distro on windows, you need some intermediate that will translate Linux sys calls to windows ones. I don’t have experience with this but I believe that’s what WSL accomplishes?
WSL1 worked this way, but this approach has many drawbacks (e.g. FS operations are slower on Windows, which can have massive impacts on Linux application performance).
Since WSL2 they switched to a VM approach - Windows and a specialized Linux are both running under a hypervisor next to each other.
Regarding your question about lock-in, if I understand it correctly, you are targeting the kernel really, thats the “engine”. So “lock-in” is about the same as you choosing which OS to target.
I may have been using the wrong terminology. Going off another reply here what I was referring to may also be called an orchestrator? So by this I was referring to software like Docker and possibly getting tied up in it.
I see. That’s a good question because I’m not even aware of other “orchestrators” outside of kubernetes 😅
