Deploying with Kubernetes
This page is under construction and does not work yet. Help is appreciated. Currently, the move from docker-compose to Kubernetes has low priority.
Last updated
This page is under construction and does not work yet. Help is appreciated. Currently, the move from docker-compose to Kubernetes has low priority.
Last updated
Deploying your Ampersand application to production can be done fast and frequent. For this purpose we are working on deployment on the Kubernetes platform. This allows you to deploy easily on your laptop (for testing), in your own data center (The minimum you need is a virtual machiine that runs kubernetes), or in the cloud (to benefit from the reliability and security provided by hosting providers). We use Kubernetes because it is open, free, well known, widely used, and is continuously being impoved by a large community. It lets you deploy fast and lets you upgrade the application without taking it offline.
A Kubernetes cluster is needed as the platform from which to launch and maintain the application. If it is there, that's fine. Otherwise you get one from a provider, from a data center, or you create one yourself (e.g. on your laptop). The cluster is built on top of virtual or physical machines and hosts and exposes the services that constitute the application.
On the platform I need a registry from which Kubernetes can pull the image(s).
I tried it out for myself. I stole my inspiration from . Thank you Kevin! I ran the following from my terminal (i.e. MacOS cli), just for the purpose of getting some hands-on experience...
To make a Kubernetes cluster, I used Minikube. Minikube requires that VT-x/AMD-v virtualization is enabled in BIOS. To check that this is enabled on OSX / macOS, I ran:
If there's output, it works!
kubectl
docker (for Mac)
minikube
virtualbox
This can take a while, expected output:
Great! You now have a running Kubernetes cluster locally. Minikube started a virtual machine for you, and a Kubernetes cluster is now running in that VM.
Should output something like:
Within minikube, a docker platform is running. However, on my Mac I have another docker daemon running. So which docker do we want to talk to? In this case that is definitely the docker daemon that is inside minikube...
(You might add this line to .bash_profile
or .zshrc
or ... to use minikube's daemon by default. Or if you do not want to set this every time you open a new terminal).
If I want to talk to the docker daemon on my Mac, I have to revert back to it by running:
When running docker ps
, it showed the following output:
The list was in fact a little bit longer: it contained 22 containers.
To setup a local registry, so Kubernetes can pull the image(s) from there:
To test whether there is a local registry, ask docker:
First of, store all files (Dockerfile, my-app.yml, index.html) in this gist locally in some new (empty) directory.
You can build the Dockerfile below locally if you want to follow this guide to the letter. Store the Dockerfile locally, preferably in an empty directory and run:
You should now have an image named 'my-app' locally, check by using docker images
(or your own image of course). You can then publish it to your local docker registry:
Running docker images
should now output the following:
I have a file called docker-compose.yml
, which I have used to deploy RAP with docker-compose (rather than Kubernetes). I used kompose
to transform that into the necessary Kubernetes .yaml files.
I deployed straight from the docker-compose.yml
file:
However, I can also create the necessary Kubernetes files and deploy from kubectl
:
This converts docker-compose.yml
into the following files:
Having run kompose up
to deploy the three RAP services, I now have the following situation on my minikube:
(I got even more information with the command kubectl get all --output=wide
.)
To access these services from a browser, we now need to expose these services to localhost. I did this by exposing both services from the minikube platform:
Store the file below my-app.yml
on your system and run the following:
You should now see your pod and your service:
The configuration exposes my-app
outside of the cluster, you can get the address to access it by running:
This should give an output like http://192.168.99.100:30304
(the port will most likely differ). Go there with your favorite browser, you should see "Hello world!". You just accessed your application from outside of your local Kubernetes cluster!
You're now good to go and deploy other images!
Last tested on 2017 October 20th macOS Sierra 10.12.6
So we see three pods (containers) running. Each of the pods is wrapped in a service of its own and exposed internally on the local network of this cluster. (In Kubernetes, , and all have their own IPs. In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be routable, so they will not be reachable from a machine outside the cluster, such as your desktop machine.)