Open micahyoung opened 4 years ago
@micahyoung do we have an owner for this issue predetermined?
I'm happy to take a first pass. I'll at least come up with something other folks can try out and refine or help us make another attempt. Sound ok?
Here's a minimal WIP approach so far.
https://github.com/buildpacks/pack/wiki/Windows-WCOW-Docker-Daemon-on-Cloud-VM
Thoughts:
$dockerConfig.hosts = @("tcp://127.0.0.1:2375", "npipe://")
Exposing the docker daemon on tcp feels like a dip in security to me. Especially if the user is only expected to work via an ssh session.
$dockerConfig."insecure-registries" = @("0.0.0.0/0")
While I'm not uneasy about this from a security standpoint, locking down the IP range bodes better with the principle of least privilege.
$IPAddress=(Get-NetIPAddress -InterfaceAlias ((Get-NetRoute "0.0.0.0/0").InterfaceAlias) -AddressFamily IPv4)[0].IPAddress
We would want to make sure that the private IP is what is making it into the host file. The last time I tried a public IP, the acceptance tests were routinely failing due a timeout. Mileage may vary with the IAAS though.
go get -u github.com/kyoh86/richgo
I think we should be setting up richgo
on all the machines were we expect the tests to run. The output is much easier to parse.
Thoughts:
$dockerConfig.hosts = @("tcp://127.0.0.1:2375", "npipe://")
Exposing the docker daemon on tcp feels like a dip in security to me. Especially if the user is only expected to work via an ssh session.
Good call. One alternative I've been considering is making a container image with a small binary that proxies TCP traffic to the socket, instead of the daemon opening the port itself. Then, it's only active when the containers is explicitly started (from RDP or whatever), and we could potentially add better security mechanisms (like TLS, IP whitelisting, auto shutoff or something). But that might not be needed, if we chose to not support DOCKER_HOST=... make
with this setup.
$dockerConfig."insecure-registries" = @("0.0.0.0/0")
While I'm not uneasy about this from a security standpoint, locking down the IP range bodes better with the principle of least privilege.
$IPAddress=(Get-NetIPAddress -InterfaceAlias ((Get-NetRoute "0.0.0.0/0").InterfaceAlias) -AddressFamily IPv4)[0].IPAddress
We would want to make sure that the private IP is what is making it into the host file. The last time I tried a public IP, the acceptance tests were routinely failing due a timeout. Mileage may vary with the IAAS though.
Yeah, I think we'll have to use the IP host.docker.internal
if it's set, due to pack
's current test registry implementation. For Window Server, we do define host.docker.internal
ourselves, so I think it could be potentially be the IP address of vEthernet (nat)
which I believe is consistently named. For Windows 10, the value of host.docker.internal
is a public IP but should still work and wouldn't be covered by these docs anyways.
Supporting DOCKER_HOST=... make
also shouldn't be supported in this setup, as you mentioned, the tests will time out for non-local Windows daemons. In fact, it might be better to invest some work in allowing pack to do export DOCKER_HOST=... ; docker build ....; docker run -v <socket> ... make
to run the tests inside a Windows container with a bind-mounted socket (much like lifecycle's make docker-run-windows
). This would make the tests run as WCOW (like CI), have a consistent way to copy code the daemon (docker build
), avoid timeouts since at runtime everything is on the daemon, and just use host.docker.internal
's IP for everything.
go get -u github.com/kyoh86/richgo
I think we should be setting up
richgo
on all the machines were we expect the tests to run. The output is much easier to parse.
👍
Description
Contributing Windows features, or debugging unintentional Windows CI failures, is complex and has a steeper learning curve that other OSes, especially for Windows containers.
Proposed solution
Document the process of Windows development and debugging by setting up a minimal Windows dev environment. This should assume the following:
make
with packDescribe alternatives you've considered
Additional context
Stefan Scherer already has a great packer implementation that could ported to use additional builders like googlecompute, azure-arm or others.
[x] This feature should be documented somewhere
Notes
[1] 1809 will be the most common OS version for k8s and corporate customers [2] Microsoft implies this can only be done by the Windows store but it's much easier using Ubuntu's appx