As an undergraduate professor of computer science, I would love to have a how-to for Virtualization in Windows that made any sense.
Right now, the inability to use linux containers in a simple reliable way that composes with the use of common virtualization (not hyper-v) in windows guarantees the students with windows laptops will have a poor experience with containers.
My ability to use containers in the classroom is blocked by this. Your ability to have CS majors with a working and positive experience with containers is blocked by this as well.
This is not a small thing: I keep hoping to try containers to help fix compatibility issues across student dev environments, and instead I only find new ones. It is not reasonable for the “hello world” to be a glossy discussion, followed by a 10 page essay on choices and compatibility problems that is a mile deep for some sophomore who just wants their node app to run like everyone else’s.
Windows containers almost profoundly do not matter: nobody deploys them, they are almost always a bad idea, and nobody will consider teaching how to use them. Their introduction to the fray greatly harmed the original simplicity of the docker model: now there are red and blue ones. No-one uses the red ones, but they break everything and, oh, they are the only ones you can easily use in windows.
Please, please, prioritizes a solution that supports your principle goals: simple compatible linux containers. For devs to enter the market with positive experiences, this means having that work in windows without hyper-V so they can use it in combination with other virtualization tools.
A custom solution can be developed with Vagrant, a Linux base box of choise for VirtualBox or VMware Workstation, and a set of provisioner scripts that perform the lab/project specific setup.
It just does not work with VMWare. Or virtualbox. Or vagrant. Unless you give up on windows and run it in a VM. All this work to provide something nobody really wanted and broke all the things everybody did… Also the filesystems do not match up; the -v stuff is messed up. It is really very very far from fine.
Remember the old software development adage: make 80% of what people want easy, and 100% possible. Docker’s perspective in windows seems more like: make 1% of what people want easy, make sure that 1% breaks what the other 99% of people want, and let people shuffle around work-arounds for everything else. In particular, the best choice is to install the deprecated toolkit for windows…
Honestly, my target environment always has been Linux and Docker-EE.
To keep my development environment close to the target, it has been on Linux with Docker-CE.
I am leading a software development team and I usualy create a per project Vagrant box based on a slim self made xubuntu 18.04 basebox each for VirtualBox, VMware Workstation and HyperV. The project specific setup is done with ansible scripts. For me, the best choice always was been to taylor a Vagrant box per project. I want to be in full controll of my tool chain.
Word of warning: due to the way HyperV works, it provides a terrible user experience with Vagrant - even more so when the ui is used in the vm
Did you think about doing an inquery to Microsoft or Amazon to ask for free student accouts on Azure/AWS? Setting up your lab environments in the cloud would provide the best user expirience for your students. There is a reason why all paid docker trainings use cloud environment for the hands on parts…
Really, Docker’s work on Windows seems like more of a move to promote Hyper-V than their own product. I do wonder if someone wrote a big check like Windows Mobile and Nokia, which nearly put them out of business. This time Microsoft is happy to wreck Docker for a Hyper-V win. If not this, then I don’t understand how Docker could have decided to do this to themselves. Or even why Microsoft would be willing to make so many devs miserable on their own platform for a Windows Mobile-like “win” again. I hope they see the light…