New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Epic: Linux Containers on Windows #33850

Open
PatrickLang opened this Issue Jun 27, 2017 · 14 comments

Comments

Projects
None yet
@PatrickLang

PatrickLang commented Jun 27, 2017

Microsoft is hard at work adding support to run both Windows & Linux containers side by side on the same node with a single Docker daemon. As Linux containers are launched, Hyper-V will be used to boot and run a Linux kernel which will then be used to host the container natively. Because many areas of Docker will require changes to handle running multiple platforms side by side, we'll be using this epic to track the list of PRs and proposals in a single place.

Preview documentation

https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/linux-containers

Progress

Required for Docker for Windows - Developer Scenarios

Status Description
Merged Store Linux images on Windows & launch Linux containers on Window. Right now, platform switching is done with a system-wide environment variable. Side by side support needs the next item.
Merged Support Linux filesystem operations in single-use VMs instead of reusable ones. This can provide protection in the case where a file parsing bug could lead to a container polluting the filesystem of another container.
Merged Use a single tag store so both Windows & Linux containers can be stored and managed by the same engine
Merged Remote filesystem support needed for docker commit, docker cp, and Dockerfile ADD commands
Merged Support resizing ext4 sandbox VHD instead of defaulting to 20Gb only.
Merged Bind mount support.
Merged New --platform parameter for docker run, docker pull, docker import and docker build to choose between platforms and order of precedence when multiple are supported (Windows & Linux) on the same node. See Proposal #34617 .
34859 Coalesce daemon stores - needed to manage both Windows & Linux containers with the same daemon
In progress Add docker kill -s for signals != SIGKILL.
Merged Support WORKDIR in running existing images and building new ones
Not started Add platform filters to docker search and docker images
Not started Memory & CPU settings - see: Microsoft/opengcs#145

Required for Kubernetes

Status Description
Not started Update docker stats for multiple platforms
Proposal soon Update docker info & daemon configuration to show what platforms each node is capable of, and restrict to single platforms if needed

Required for Swarm

Status Description
Not started Add --platform flag support to docker-compose, and docker stack deploy
Not started Update docker stats for multiple platforms
Not started Support multiple platforms for docker volume commands
Not started Adjust Swarm mode placement to handle running multiple platforms instead of just the node's native platform. Until this is done, use docker service create --no-resolve-image as a workaround

Backlog, need to set priority

Status Description
Not started docker top
Not started docker run flags. Feedback welcome on what's needed vs not
Not started docker export, docker import, docker save need platform flags
Not started UID & GID flag support - see: Microsoft/opengcs#146
Not started Cross-platform multi stage builds, support for COPY command in Dockerfile

For more issue tracking also check https://github.com/Microsoft/opengcs/issues/

Glossary & References

  • LCOW - Linux Containers on Windows
  • GCS - guest compute service. Receives commands from the Hyper-V host services (DockerD via HCS) and invokes processes for specific tasks, creating namespaces, and creating containers using runC. (Repo link coming soon)
  • HCS - host compute service. Windows-specific service used to manage containers and VMs (doc link coming soon)

There's a brief description of gcs & hcs from a Dockercon 2016 presentation

FAQs

What's needed to fully test this?

  • Windows 10 or Windows Server version 1709 (build 16299), or a later Windows Insider build
  • A build of moby/moby with the PR's above applied
  • A bootable UEFI-based Linux image with the right modules & gcs included - see https://github.com/microsoft/opengcs
  • At least 4GB of RAM and Intel VT or AMD-V instruction support
    • Note: other apps using these instructions (VMWare, Virtualbox, ...) cannot be run concurrently
@AkihiroSuda

This comment has been minimized.

Show comment
Hide comment
@AkihiroSuda

AkihiroSuda Jun 28, 2017

Member

What would be a usecase of "Cross-platform multi stage builds"?

Member

AkihiroSuda commented Jun 28, 2017

What would be a usecase of "Cross-platform multi stage builds"?

@PatrickLang

This comment has been minimized.

Show comment
Hide comment
@PatrickLang

PatrickLang Jun 28, 2017

@AkihiroSuda It would be great for cross platform builds. For example, if you had a collection of bash scripts and a language with cross-compilation support like golang, then you could actually build your code in Linux then copy the binaries into a microsoft/nanoserver image to run it in a Windows native container or vice versa. The same would be feasible for projects based on JVM, .Net Core, or Mono.

PatrickLang commented Jun 28, 2017

@AkihiroSuda It would be great for cross platform builds. For example, if you had a collection of bash scripts and a language with cross-compilation support like golang, then you could actually build your code in Linux then copy the binaries into a microsoft/nanoserver image to run it in a Windows native container or vice versa. The same would be feasible for projects based on JVM, .Net Core, or Mono.

@carlfischer1

This comment has been minimized.

Show comment
Hide comment
@carlfischer1

carlfischer1 Dec 1, 2017

@PatrickLang please add an entry in the table for supporting the --platform flag in the compose file format, docker-compose, and docker stack deploy

carlfischer1 commented Dec 1, 2017

@PatrickLang please add an entry in the table for supporting the --platform flag in the compose file format, docker-compose, and docker stack deploy

@galvesribeiro

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro Dec 11, 2017

Just a report on LCOW:

If I run:

docker run --rm -it -v C:\Users\gutem\source\repos\DGC\DGC.Router.Providers:/app --workdir /app  microsoft/dotnet:sdk bash

And then inside the container:

root@e6642bee4a71:/app# dotnet restore teste.sln
  Restoring packages for /app/src/DGC.Router.Providers/DGC.Router.Providers.csproj...
  Generating MSBuild file /app/src/DGC.Router.Providers/obj/DGC.Router.Providers.csproj.nuget.g.props.
/usr/share/dotnet/sdk/2.0.3/NuGet.targets(102,5): error : Access to the path is denied. [/app/teste.sln]
/usr/share/dotnet/sdk/2.0.3/NuGet.targets(102,5): error :   Permission denied [/app/teste.sln]

I have no idea why we are having permission denied inside the container. If I run it outside the container, it works perfectly.

galvesribeiro commented Dec 11, 2017

Just a report on LCOW:

If I run:

docker run --rm -it -v C:\Users\gutem\source\repos\DGC\DGC.Router.Providers:/app --workdir /app  microsoft/dotnet:sdk bash

And then inside the container:

root@e6642bee4a71:/app# dotnet restore teste.sln
  Restoring packages for /app/src/DGC.Router.Providers/DGC.Router.Providers.csproj...
  Generating MSBuild file /app/src/DGC.Router.Providers/obj/DGC.Router.Providers.csproj.nuget.g.props.
/usr/share/dotnet/sdk/2.0.3/NuGet.targets(102,5): error : Access to the path is denied. [/app/teste.sln]
/usr/share/dotnet/sdk/2.0.3/NuGet.targets(102,5): error :   Permission denied [/app/teste.sln]

I have no idea why we are having permission denied inside the container. If I run it outside the container, it works perfectly.

@thaoula

This comment has been minimized.

Show comment
Hide comment
@thaoula

thaoula Jan 23, 2018

Can bridge mode networking be added so that we can use the same compose file on windows, mac and linux.

All our compose files reference bridge but this fails when using LCOW because there is no bridge network.

Can an alias be created bridge = nat?

thaoula commented Jan 23, 2018

Can bridge mode networking be added so that we can use the same compose file on windows, mac and linux.

All our compose files reference bridge but this fails when using LCOW because there is no bridge network.

Can an alias be created bridge = nat?

@bgervin

This comment has been minimized.

Show comment
Hide comment
@bgervin

bgervin Feb 8, 2018

docker run --rm -v /test/myfile.txt:/myfile.txt bgervin/tabula-java
Running the above command, I would have expected a myfile.txt file to be in the root at /myfile.txt - however from within the container - myfile.txt is showing up as a directory.

bgervin commented Feb 8, 2018

docker run --rm -v /test/myfile.txt:/myfile.txt bgervin/tabula-java
Running the above command, I would have expected a myfile.txt file to be in the root at /myfile.txt - however from within the container - myfile.txt is showing up as a directory.

@edrevo

This comment has been minimized.

Show comment
Hide comment
@edrevo

edrevo Jun 7, 2018

Contributor

@PatrickLang , would it be possible to add to this epic a task to support an easy way of binding the docker pipe / socket to a container? See #36574

Contributor

edrevo commented Jun 7, 2018

@PatrickLang , would it be possible to add to this epic a task to support an easy way of binding the docker pipe / socket to a container? See #36574

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment