Thoughts on developer and single-node installation as per Locally-managed workbench.

Use

...

case

The primary use case is for a developer to run a local copy of Labs Workbench on their laptop or a remote VM (AWS, GCE, Azure, OpenStack, etc).  The basic requirements are simple: 

• Bring up a (virtual) Kubernetes cluster 
• Deploy Labs Workbench

Current environment

For developers, we achieve this with the ndslabs-startup repo. A simple shell script  kube-up.sh brings up Kubernetes via Hyperkube.  This requires access to /var/lib/docker and /var/lib/kubelet, which has proven problematic on MacOS and Windows with the newer Docker installs.  A second shell script ndslabs-up.sh collects information from the user (domain name, IP address, email address) and uses kubectl to deploy a number of templated YAML files.  

Pros:

• Simple, scripted process gets things running quickly

Cons:

• Doesn't currently work on MacOS/Windows
• Repo has unused stuff
• "Mustache" variable replacement is ridiculous
• Doesn't include support for DNS (can be added easily)
• Templates duplicated in deploy-tools repository

Options:

• Minikube (works on MacOS, Windows, Linux – doesn't require Docker; doesn't work on VM)
• Kubernetes Hyperkube (works well on VMs running Docker; doesn't work well on MacOS/Windows due to filesystem permission problems)
• Vagrant (works on MacOS)
• Deploy-tools

Minikube

Minikube runs Kubernetes in a single VM.

• Requires virtualization environment, like VirtualBox
• Download binary
• minikube start creates a VM in VirtualBox (or other virtualization environment)
• Sets up kubeconfig and local environment to access VM via kubectl

...