Bloppi's Knog

Using containers in my eyes reaches its full potential only when combined with an orchestrator – the usual choice should be Kubernetes. But if you build your own Dockerfiles you want to have a development environment where you can test the images on that orchestrator. This environment should be set up easily and responding fast.

Unless you full-install Kubernetes locally minikube should fulfill the requirements for testing a not too complex application built from several containers. Without further configuration, however, it pulls images from the Docker hub. That is a viable way, but far too slow. The automatic workflow (Dockerfile & docker build) would look like this:

1. Create/modify Dockerfile
2. Commit and push Git repository to GitHub
3. Docker hub reacts on push and performs automatic build
4. Pull image to local Kubernetes cluster

I am aware your workflow might differ, but this solution is rather convenient and on a non-professional level to my understanding rather common. It works in the sense that you obtain a single node development environment but the automatic build and the download need several minutes – usually more than you are willing to wait. So let’s build something where no (real) network is involved.

Prerequisites

We need minikube from https://github.com/kubernetes/minikube

curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/ 

or (if you use su):

curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube && mv minikube /usr/local/bin/ 

In addition we need kubectl and install it following the instructions from the k8s (= kubernetes, i.e. k + 8 letters + s) documentation

curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl

On my system every software installed via snap (including kubectl) is terribly slow, so I would not reccomend that way. But in case you have not messed up and snap works for you, here is how to do it then:

sudo snap install kubectl --classic

I try to take as much “standard” software as possible, which for the hypervisor means kvm. Hence, we also need the kvm2 driver, which also addresses kvm and is maintained by the minikube team. They state that it is favoured over the kvm driver.

curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-kvm2 && chmod +x docker-machine-driver-kvm2 && sudo mv docker-machine-driver-kvm2 /usr/local/bin/

Cluster setup

Next, we start minikube, using the kvm2 driver and pointing to a unsecure local registriy – this is where we push the docker images later

minikube start --vm-driver=kvm2 --insecure-registry localhost:5000

You could add options to the start call like --memory 4096 or --cpus 4. By default the minikube VM obtains 2 cores and 2048 MByte of RAM. So double this with

minikube start --vm-driver=kvm2 --insecure-registry localhost:5000 --memory 4096 --cpus 4

If minikube is up and running you can ask it for its docker-machine’s parameters using

minikube docker-env

The output tells you how to use this information:

eval $(minikube docker-env)

Any subsequent docker build pushs the resulting image to your minikube VM. Well and that’s it. Create a deployment or a pod with the locally present container and add

imagePullPolicy: Never

Then, kubernetes will state Container image "your_image:tag" already present on machine and start it immediately.

Note that the adjustment of the Docker environment is only temporay and is valid only for on single shell session.

Cleaning

From time to time you might want to start from a blank system. To achieve this, delete your minikube VM:

minikube delete

and for the thourough ones delete all the hidden files

rm -Rf  ~/.minikube

Then start over with the cluster setup.