Closed markmandel closed 6 years ago
Hi Mark,
I've actually spent some time on this already. And it was not successful, I used wsl and docker for windows connected to hyper-v. My WSL has the docker cli using the windows docker deamon via tcp and it cannot mount linux path, it expects only windows path. Another option that might work but I found a bit too bad would be to not use the docker for windows (hyper-v) and use a the virtualbox(might not also work). In my opinion this goes against the tide, I'm used to docker for windows and losing it makes me feel bad (I love it so far and it's the de-facto in the docker community, docker toolbox is way more painful to use)
Unfortunately from my research it will never work if we don't change a bit how the build works, now I don't really know which direction we want to go for, a second build system for windows or a common for every platform ? I'm sure both are possible.
Let me know and I can take it from there.
Cyril.
PS: Also do note that the same issue will happens with CI, usually CI uses docker dind and mounting in dind is clunky since you're mounting the host not the container host, not sure if I'm clear ? but that's another subject ;).
Thanks for doing work on this @Kuqd !
So I'm using this build system now for CI with dind, and it's fine (at least on Container Builder - works with very little trouble. Have a look at cloudbuild.yaml for reference.
Ideally, I'd like to have a single build system that works across the board (switch out some pieces based on what OS people are on) - but also agree, I don't want Windows users to have to install virtualbox just to be able to work on this, that would incur a great deal of friction.
Can you share the logs of what happens when you run make build
for example inside WSL?
Curious also what adjustments you made to the Makefile to get even part of the way there?
The steps I've made :
1 - Install docker for windows (I already had that) and allow localhost deamon access via the settings
2 - Install WSL and install docker cli (https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/)
3 - install make in WSL
4 - set the docker cli in WSL to use the windows deamon export DOCKER_HOST=localhost
uses docker info
to make sure it works.
The build of the build image worked then the logs are showing this :
root@MTL-BH744:/mnt/f/src/github.com/agonio/agon/build# make
mkdir -p /mnt/f/src/github.com/agonio/agon/build//.kube
mkdir -p /mnt/f/src/github.com/agonio/agon/build//.config/gcloud
docker run --rm -e "CGO_ENABLED=0" -v /mnt/f/src/github.com/agonio/agon/build//.config/gcloud:/root/.config/gcloud -v /mnt/f/src/github.com/agonio/agon/build//.kube:/root/.kube -v /mnt/f/src/github.com/agonio/agon:/go/src/github.com/agonio/agon --entrypoint=go agon-build:76f0b220a6 build \
-o /go/src/github.com/agonio/agon/gameservers/controller/bin/controller -a -ldflags "-X github.com/agonio/agon/pkg.Version=0.1-1601c83" -installsuffix cgo github.com/agonio/agon/gameservers/controller
can't load package: package github.com/agonio/agon/gameservers/controller: cannot find package "github.com/agonio/agon/gameservers/controller" in any of:
/usr/local/go/src/github.com/agonio/agon/gameservers/controller (from $GOROOT)
/go/src/github.com/agonio/agon/gameservers/controller (from $GOPATH)
make: *** [build-gameservers-controller-binary] Error 1
You get the idea, nothing has been mounted, and nothing will ever be mounted with a linux path, I've dig a lot around this.
I also have a tutorial to get minikube working on hyper-v in a private repo, I'll see if I can make it public for you or may be you want it in a wiki page somewhere here. It's important for windows developer to keep hyper-v because you can't have both hyper-v and virtualbox, and for me it will always be hyper-v since it the best docker experience you can have.
Cyril.
Oh that's good to know - I'm working on #30 right now - both to have Agon work on Minikube, and also have it as a development platform. Knowing we need to stay on hyper-v is very useful.
Thanks for digging into this - you may have seen this, but this approach looks promising: https://github.com/Microsoft/WSL/issues/1854
I'm downloading a Windows 10 vm now (yes, that will be Linux->Windows->WSL->Docker :wink:), this may be a weekend hack project, just to see what breaks/changes need to be made.
I was just doing some quick reading on running minikube on Windows with hyper-v, and it didn't look like the best experience, so glad you have it worked out. That being said, Kubernetes support should be coming in Docker for Windows natively in the near future, so it may become a moot point (but who knows when that will actually show up)
I'll test to bindmount and symlink to see if it helps.
I don't think you can get hyper-v working in a vm but you will tell me soon ;)
Here's a whole setup script - https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly
It's looking like it's a fairly common practice, from my super limited research. (I wonder if we should build it into the Makefile operations for windows, if it doesn't exist, create it)
Yes this is exactly what I did, symlink doesn't work because make use the real path in the end.
I'm trying to have the bind mount working, but it doesn't, might be related to my WSL version as I'm lock in windows update from Ubisoft. I know that Eric had the approval to get the fall creator update, I'll ask him.
EDIT: Yep I'm doomed bind mount doesn't work for me.
I didn't wanted to changed your build, but something we can do is bake make in your build image and forget about WSL. It's one less dependency ..
Basically embrace docker and make it the only dependency to build. If it works only with docker it will work every where there is a docker host.
So moving everything into Docker is an interesting idea - but we'd still need some kind of target system - I'm not sure if we can get away from Make.
With the build system, my thinking is that there is OS detection (such as a simpler version of this) , and it drops in a OS specific include that allows for overwrites to occur to make sure things work correctly on each OS. This feels like a simpler answer to me (at least, for now)
I believe if the Windows Makefile include did a simple find and replace on the prefix of agon_path
and build_path
for Windows to point to the correct symlink place, that would resolve at least the initial issue.
I was going to attempt this - but apparently you can't install Docker on Win in a VirtualBox VM :cry: , so I'm going to have to grab an actual laptop to install Windows on to take an initial stab at this.
Ok so we have two options:
the reason why this is happening is because you send the code via mount, usually to build docker images you use the build context to pass either the code (and then use a multi-stage build if there is a lot of tools required) or directly artefacts.
EDIT: I've managed to go further with the path rewrite. pushing a branch for better collaboration EDIT2: I'm stuck somewhere else, when sending the artifacts to deamon, I'm hitting exactly this https://github.com/docker/for-win/issues/576 and https://github.com/Microsoft/WSL/issues/1123 seems that the only way to fix is a windows update which I can't for now.
For those who have a windows up to date you can keep going using my branch
So I'm running this now on WSL, and so far, both make test
and make build
are working perfectly.
I'm going to test out the rest of the the build and development process.
I wonder if it's because I'm /c
?
I followed this guide: https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly (Without docker-compose)
Here are my installed versions -
Ubuntu: 20170830.1 build of Ubuntu 16.04 LTS
Docker Version:
Client:
Version: 17.12.0-ce
API version: 1.32 (downgraded from 1.35)
Go version: go1.9.2
Git commit: c97c6d6
Built: Wed Dec 27 20:11:19 2017
OS/Arch: linux/amd64
Server:
Engine:
Version: 17.09.1-ce
API version: 1.32 (minimum version 1.12)
Go version: go1.8.3
Git commit: 19e2cf6
Built: Thu Dec 7 22:28:28 2017
OS/Arch: linux/amd64
Experimental: true
We have the exact same version of docker but I'm 14.04 trusty for WSL, I've asked my organisation to update my computer. Are you using hyper-v ?
Should we get a slack channel ?
Yep, I am using Hyper-V!
We should sort out some kind of chat next week when we're both back at actual work 😉
I found a bug with part of the development process - submitting now as well, will cc you.
I used an internal repository to avoid the build and the gamecontroller worked on minikube in hyper-v. So looked like all the pieces are working for development purpose on windows, it's just a matter of bringing that all together now.
Great! The fix for Agon just running on Minikube was pretty straight forward once I got into it - but I definitely want to have it so that people can also build Agon on Windows with Minikube too. I'll likely ping you about that guide to setting it up with Hyper-V.
Doing some more work on this - slowly getting somewhere with minikube + wsl. But early days - and WSL has to be run as administrator. You can see it in this branch.
It also has the OS specific include setup within the make file, to allow for OS specific configuration.
you didn't get any issue while setting up minikube on windows ? Are you using an external vswitch ?
How does it works if your minikube_home is not mounted using the common mount and you reference $CERT_PATH ? see https://github.com/googleprivate/agon/blob/c39ef2044c2788a883115e9163facccbf76f469d/build/includes/windows.mk#L31
I didn't use an external switch - and almost everything worked. The only thing that didn't was the minikube.exe mount
command, but that actually isn't 100% necessary, it just means you can't build directly on minikube, but you can still do a build locally, then push, which is fine, it just needs to be documented. Otherwise, this seems to be working. I'll clean it up tomorrow, write some docs (and make sure I didn't break anything on Linux), and file a PR.
On the second question (if I understand correctly), the minikube certs are mounted into the Docker container, so that they are accessible. The location of those certs are determined through parsing minikube docker-env
to get the appropriate locations. Does that answer the question?
Oh (almost forgot), once piece of secret sauce I did run into. If you want to run minikube under WSL, you have to run WSL as Administrator, otherwise it just won't work.
The Makefile does do a lot of switching paths from Windows->Linux (and back in a few cases), as well as setting up the Kubernetes config manually as well.
It's not 100% straightforward, but it's automated now.
Ok got it you always use kubectl via docker run, so you're re-mounting the same config and you're using a different user so no conflicts with windows kubectl usage (different path).
:+1: Ideally, I'd like it if I could actually mount the WSL's ~/.kube
into the container (maybe a simlink?) so if people want to use kubectl locally they are also able, but this at least gets things started.
Out of the box, Agon will not build with Windows.
I expect best effort will be to force people to use WSL to do this (which I don't think is too onerous)
Even with WSL, I expect that some of these will break, especially the minikube development workflow.
This is a high level ticket for tracking these issues, and resolving them.
Docker
May need to create a $DOCKER env var that switches to docker.exe on windows Should be relatively trivial to inspect the OS and switch out as needed.
Minikube
Best option: After creating the cluster with
make minikube-test-cluster
, runeval $(minikube docker-env)
and work with minikube as per described. We've set it up so the build image gets transferred in on minikube start, and since the VM knows it's own external IP, everything should work at this point as expected.