docker
I want to be able to run, and build Linux and Windows (LCOW) containers simultaneously.
Tell us about your request I want to be able to run and build Linux and Windows (LCOW) containers simultaneously.
Which service(s) is this request for? docker build, and docker-compose
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? At this moment, I am using the (LCOW) experimental feature to run Linux and Windows containers simultaneously. The option to work streamless with Linux and Windows container is hard, because of the switch context option.
Are you currently working around the issue?
- Switch context when building Linux images.
- Switch setting back to windows containers, and pull Linux image in (LCOW) mode.
Additional context The new 20H1 WSL docker integration is a great new feature, and I love it, but integration requires Linux mode. I do lose my windows context. Issue #78 describes building both Linux and windows images in parallel on windows.
LCOW is great but lingering in limbo. There are many solutions where Windows and Linux containers work together.
For me the important part is just building. Yeah, running both in parallel would be nice, but not strictly required.
Our dockerfiles don't do anything fancy, just copy a folder, set an environment variable and set the entry point.
So I'd also be happy with some other tool. Maybe with WSL2 we can invoke buildkit through WSL or something, idk.
Hi. I am working on moving our build and testing environment to Docker Containers. We ship Linux and Windows components and thus need support for both. During testing, we require a Windows client container talking to a database in Linux container. So the lack of dual support is killing my efforts. thank you
We're bound to windows containers due to the use of 'windows authentication' in some of our services and because of some SLA's. We do use some linux containers like consul and traefik. Not being able to mix Windows and Linux containers prevents our team from starting to use WSL2.
I am working on upgrading our CI process to allow testing locally. Both GitHub Actions and GitLab CI don't allow running pipelines locally (of course, they weren't designed to do that). Generally I was advised to move away from the feature set of any CI runner and put as much logic into (shell) scripts as possible. Heeding that advice, I'm working on a CMake module (because all of our build automation is CMake anyway) which is able to run CI tasks locally.
Pipeline definition for GitLab and GitHub remain YAML files which do not much more than define the test matrix, distribute the work to runners and invoke a single script on every pipeline stage. The CMake module is an auxiliary project commited into version control.
- CMake configuration step allows customizing the "local runner", selecting some subset of the test matrix one wishes to test for.
- The build step builds the images (from Dockerfiles from within the repo), ideally in parallel.
- CTest runs the same shell scripts which ordinary CI does (actually, they are CMake scripts too, invoked as
cmake -P Build.cmakefor eg.) in the correct order with dependency tracking inside Docker containers. Tests again ought to run in parallel. (Tests would get labels based on which test matrix elements they inherit, one could select some subset of the test matrix through ordinary CTest CLI args.)
It would be rapid response CI runs without involving remote entities, possibly even run totally offline.
I may be able to orchestrate the entire thing having CMake communicate with two daemons, one locally inside Windows and one running inside WSL2, but setup becomes way more complicated, not to mention having to bind the lifetime of the Linux daemon to a long running Windows process (service?), instead of it being the same daemon which is running on the Windows host anyway.
My org has .net framework applications I'm looking to containerize, and I would love to be able to mix Linux and windows containers on dev machines for a local development environment more reflective of our deployed environments
I also would find it extremely useful to be able to run both Windows and Linux containers on a single host. We have many scenarios where it is required we run both types of containers in a single installation.
For my org using this feature would help us quite a lot as well. We have some legacy components which require to mix Linux containers with Windows containers. Manually switching on the Docker Desktop between Linux containers and Windows containers all the time is quite cumbersome for our developers.
For my org using this feature would help us quite a lot as well. We have some legacy components which require to mix Linux containers with Windows containers. Manually switching on the Docker Desktop between Linux containers and Windows containers all the time is quite cumbersome for our developers.
+1
Afaik it is possible via the DockerCLI
Ah sorry for being quiet, no updates yet I am afraid 😞. Please keep everyone following/providing the 👍 so we can see the interest!
Another +1 here. We have a mix of Windows .NET Framework services and IIS web sites, and Linux services, and would LOVE to be able to run both on a single dev workstation.
Ah sorry for being quiet, no updates yet I am afraid 😞. Please keep everyone following/providing the 👍 so we can see the interest!
We need some movement on #79 here, see also https://github.com/microsoft/Windows-Containers/issues/34
I'm not sure I understand the issue.
LCOW is deprecated and has some annoying issues such as https://github.com/docker/for-win/issues/10813 that won't be fixed but you can already use Windows containers and WSL2-based Linux containers in the way mentioned at https://github.com/docker/for-win/issues/6311#issuecomment-613315732 as being the future plan by Docker Inc.
Despite the comment there from April 2020 saying
Hi, currently we are facing 2 issues with that:
- There is a remaining bug in 2004 (fixed in insider fast branch) which prevent us to run both windows containers and wsl2 at the same time reliably. (see microsoft/WSL#4726).
- once the bug is fixed, we plan to leverage docker CLI contexts to run and expose both daemons at the same time and allow you to switch from one to the other using those contexts:
# assuming default context is Linux $> docker run -d -p 127.0.0.2:80:80 nginx $> docker --context=dd-win run -d -p 127.0.0.3:80:80 aspnet-iis
and supposedly no progress on the issue since, this has works for me since the day WSL2 came out:
I'm sure there was a comment by me right here on this issue that explained how to get it working today but it appears to have disappeared.
The way I read https://github.com/moby/moby/issues/36682#issuecomment-733763007, LCOW itself is not deprecated, merely the current implementation in Docker. containerd has LCOW support already, and there are MS developers still fixing bugs (at least) in the containerd LCOW support since that comment.
It ought to work in Docker without much effort once Docker uses containerd on Windows, because containerd applies LCOW when a container started for Linux in the Windows daemon. So this is a distinct but non-interfering potential solution for this ticket, contrasting with WSL2.
Microsoft has something called "LCOW v2". See for example https://github.com/microsoft/opengcs and that's what's being worked on in containerd. This not what you get if you install the 4.14 kernel from https://github.com/linuxkit/lcow (which is archived and no work being done on).
I don't do "once". I do "now". Now WSL2 works (and is supported insofar as you can call any Microsoft product or service "supported").
Oh, thank you, I'd been looking for a reference for "LCOW v2". So in my earlier comment, "the current implementation in Docker" is LCOW v1, and "containerd LCOW support" is LCOW v2, and the rest of the comment still applies.
Note that the v1/v2 split (e.g., visibility of UVM to the HCS API) also applies to WCOW, and Docker is also relying on containerd integration to support the v2 API for WCOW containers.
And speaking of support, MS has recently been somewhat explicit that they do not support WSL2 for production workloads, only for development, going so far as to disable it in Windows Server 2022 LTSC prerelease builds. So a WSL2-based solution isn't currently viable on Windows Server 2022 LTSC, although I'm not sure Docker desktop is supported on Windows Server anyway.
Since (AFAIK) LCOW v2 doesn't require further OS support than already exists in Windows Containers, I don't know if it will be similarly blocked on Windows Server 2022 LTSC; I hope not, as amongst other things, that'll mess with the CI pipelines for containerd.
Oh, thank you, I'd been looking for a reference for "LCOW v2". So in my earlier comment, "the current implementation in Docker" is LCOW v1, and "containerd LCOW support" is LCOW v2, and the rest of the comment still applies.
It still applies in the sense that it's still a nice prospect for the future but doesn't help people today, on May 2021, to run Linux and Windows containers without wasting years of their lives on "Switch to Windows containers...", "Switch to Linux containers...", "Switch to Windows containers...", "Switch to Linux containers...", "Switch to Windows containers...", "Switch to Linux containers...", "Switch to Windows containers...", "Switch to Linux containers...", "Switch to Windows containers...", "Switch to Linux containers...", "Switch to Windows containers...", "Switch to Linux containers...", "Switch to Windows containers...", "Switch to Linux containers...", ...
Using WSL2 does.
And speaking of support, MS has recently been somewhat explicit that they do not support WSL2 for production workloads, only for development, going so far as to disable it in Windows Server 2022 LTSC prerelease builds.
So what? Both WSL2 and LCOW (v1, the only thing that exists) are not supported for production. Both. There's no difference in this regard so it's not a disadvantage of using WSL2. But WSL2 works better for development, which is what people here seem to want (building images, not deploying them in production).
So a WSL2-based solution isn't currently viable on Windows Server 2022 LTSC, although I'm not sure Docker desktop is supported on Windows Server anyway.
It's obviously not. Docker Desktop is only supported and intended to run on Workstation SKUs.
All I said was "LCOW itself is not deprecated", and "it's a distinct but non-interfering potential solution for this ticket, contrasting with WSL2". I guess you're seeing "don't use WSL2 though docker --context" somewhere in what I wrote, and responding to that?
Poking around, at least on the Microsoft side, LCOW is (or was) supported on Windows Server. As was mentioned at https://github.com/moby/moby/issues/39533#issuecomment-694382362 there are or were existing production uses, and I believe the Windows Server team are still actively committing code for it to containerd, so someone is sufficiently interested in it to invest developer time. And from that ticket, Docker wasn't going to reject getting LCOW via containerd for near-free, even though WSL2 is the currently targeted option.
"Using WSL2 exists", but the support in Docker Desktop for a nice multi-context experience (i.e. https://github.com/docker/for-win/issues/6311#issuecomment-627200096) doesn't, so I wouldn't consider this ticket closed just because it's possible to set up your system and contexts to expose both WSL2 and WCOW container daemons.
Unless I've misunderstood, and you're saying the wsl2 context is created by Docker Desktop now?
I had understood you to mean that the (missing) instructions would set you up into that position. Although I assume that since Docker Desktop doesn't yet support contexts, one of those contexts would be bypassing the Docker Desktop proxy and talking directly to the relevant daemon's socket.
All I said was "LCOW itself is not deprecated", and "it's a distinct but non-interfering potential solution for this ticket, contrasting with WSL2". I guess you're seeing "don't use WSL2 though
docker --context" somewhere in what I wrote, and responding to that?
LCOW - the thing that exists and can be used to run Linux containers - is deprecated. No amount of text will change that. The LCOW that actually exists is deprecated and something else called LCOW that might exists in the future doesn't exist yet.
Poking around, at least on the Microsoft side, LCOW is (or was) supported on Windows Server.
You probably should have meant unsupported. I suspect you're confused because there are two meaning to the word "supported" in this context. One is "works or can work in contrast with doesn't work or can't work" while the other is "supported by a commercial entity that will treat things not working as you expect as bugs".
For example, WSL2 supports setting processor count, RAM size and kernel image via the .wslconfig file. Does that mean that Microsoft will support you if you use a broken custom kernel instead of the one provided by them?
See also https://github.com/docker/for-win/issues/6470#issuecomment-620466429 for example
"Using WSL2 exists", but the support in Docker Desktop for a nice multi-context experience (i.e. docker/for-win#6311 (comment)) doesn't, so I wouldn't consider this ticket closed just because it's possible to set up your system and contexts to expose both WSL2 and WCOW container daemons.
k bro. I never said this ticket should be closed. I proposed to interested parties today who have a problem today a way today to use Linux and Windows containers simultaneously today, without going through the whole 3 minute "Switch to Linux containers..." process every few seconds, using the same feature Docker Inc. is planning for them to use in the future anyway.
Unless I've misunderstood, and you're saying the
wsl2context is created by Docker Desktop now?
No, and I didn't say that.
I had understood you to mean that the (missing) instructions would set you up into that position. Although I assume that since Docker Desktop doesn't yet support contexts, one of those contexts would be bypassing the Docker Desktop proxy and talking directly to the relevant daemon's socket.
You have misunderstood. No one and nothing will be bypassing Docker Desktop since Docker Desktop won't be installed.
LCOW (v1), "the experimental thing that exists now in Docker" is deprecated in Docker, yes.
That's the start of this ticket, a request for something in Docker (Desktop I assume) to replicate that nice workflow. LCOW, the concept, and hence LCOW v2 as a possible solution to the use-case of this ticket, is not deprecated, and if it gets delivered, would indeed provide the same workflow.
Shouldn't the documentation be groomed radically to reflect the current situation?
I tend to feel a great source of frustration that Docker documentation is contradicting itself on this point, depending on which documentation page you're reading.
For professional users cluttered documentation is not a path leading to educe trust in the Docker environment as a whole.
@SetTrend Yes, of course the documentation should reflect the current state. If you can point to a page which is wrong, we'll fix it (or you can open a pull request if you prefer, all our docs are open source).
On the other hand:
Belonging to the species of professional programmers who try to gain revenue with their own projects - utilizing Docker, perhaps even having a paid Docker subscription plan, only as a tool - I would not commend expecting those users to invest too much of their time in investigating on a tool's roadmap or to update a tool's documentation.
The most important fact for this breed of programmers is what is available here, right now. Not in the future, not in the past. Everything else will sooner or later lead to not recommending the tool.
You're commenting on the Docker Roadmap project... It's entirely about the future.
@conioh
I'm sure there was a comment by me right here on this issue that explained how to get it working today but it appears to have disappeared.
It was over at the duplicate ticket, https://github.com/docker/roadmap/issues/78#issuecomment-684073682, but your repo with the instructions appears to have disappeared. For anyone trying to play along at home, there's vestiges of it at https://github.com/docker/roadmap/issues/78#issuecomment-686640101.
@conioh Your tone is not appropriate and I have deleted your comment.
At this moment, I am using the (LCOW) experimental feature to run Linux and Windows containers simultaneously.
Is this currently the recommend approach, and is this documented anywhere?
I was hoping that by specifying platform in my docker compose, I would be able to just run both Linux and Windows containers simultaneously. But the Docker Desktop client "Switch to..." option right now I think blocks running one or the other
