This URL hosts a Git repository (ie. git clone https://steady.supply/git/ee will work). For your convenience, the file README.md from this repository is rendered below.

Equal Experts

Please provide a solution that you would provide to a paying client. This should be delivered zipped up and ready to run. Do include a comprehensive ReadMe file.

Chosen problem

Write a simple hello world application in either of these languages: Python, Ruby, Go. Build the application within a Docker container and then load balance the application within a mini kube.

Solution

This repository contains the necessary automations to allow the user to do the following:

• Create a Minikube cluster
• Build a very simple containerised web application using Docker and make the container image available to the cluster
• Provision the necessary Kubernetes resource objects to direct HTTP traffic to a web application
• A rather crude test to validate the web application is running and load balanced
• Package the repository for distribution to a client (make package)

Added after submission:

• Namespaces and corresponding build targets for application container
• A very simple test, make test
• Tooling for development

For more details on these see the Post-submission heading at the end of the document.

Repository structure

.
|-- app
|   |-- Dockerfile          # container image definition
|   `-- src
|       `-- main.py         # application source code
|-- LICENSE
|-- Makefile                # developer commands / local automations
|-- manifest.yml            # kubernetes definitions
`-- README.md

Prerequisites

This repository was written and tested on Ubuntu 20.04 but because it doesn’t rely on a package manager, should work on any 64-bit Linux flavour. The container platform used is Docker (version 19.03.8), which is not installed as part of the Make automations. GNU Make itself is also required, along with standard tools git, tar, curl and watch. These programs are available through the package managers of all mainstream Linux distributions.

How to

The commands for interacting with the Minikube cluster created by this repository are contained within the Makefile at the root of the repo.

Basics

To spin up the Minikube cluster, simply run make start in the repository root. This recipe will download the version of Minikube specified by MINIKUBE_VERSION at the head of the Makefile and create a cluster at the Kubernetes version similarly specified by KUBERNETES_VERSION.

Once the cluster is up, for a web-based overview of the Kubernetes cluster, the command make dashboard will start the built-in dashboard and print the URL at which it can be accessed. Note, the command runs a proxy and must be kept open for the dashboard to remain accessible (ie. open a new shell to run the make dashboard command).

The application

The dashboard will only show the basic Kubernetes system components because we haven’t added anything of our on yet. To add the very simple “hello, world” application the command make apply can be used. This command will build (and make available to the cluster) the container image for the application and send a request to the Kubenetes API server to create the following:

• An ingress object that directs external HTTP traffic to the service inside our cluster
• A service object which load balances and routes TCP traffic to our deployment
• A deployment object which is responsible for running our application containers

Demonstration

NOTE: The deployment takes a few seconds to start for the first time, so you may see some 503 messages whilst containers are starting.

Once the Kubernetes resources have been created, the command make demo is provided which will repeatedly make HTTP requests to the web application running in our cluster. Each container that is part of our deployment will report its unique name as part of the HTTP response, which allows us to see the load-balancing “in action”.

To take the demonstration further, try the following:

• Use your text editor to make a change to the message returned by the view function in app/src/main.py
• Run the make demo command in one shell
• Run the make apply command in another shell (this will build and deploy the altered application)
• Observe in the make demo shell as Kubernetes rolls out the changes to the cluster with no downtime

Clean up

To delete the cluster, downloaded binaries and any Docker images created the command make clean is provided.

Notable omissions

• Namespaces for standard deployment stages eg. dev, preprod, prod Added post-submission
• A real ingress ie. domain name
• Container registry (the Minikube configuration roughly shares container registry with the host machine)
• Cloud load balancer or MetalLB, load balancing here is mostly demonstrative
• Non-debug WSGI server for Flask

Post-submission

Some features were added post-submission, either during the pairing interview or to make this repo more demonstrative of a complete approach to developing on Kubernetes clusters.

Namespaces, container build targets

In this repo, the coincidence of a namespace and Docker build target is called a “stage”. A stage represents a particular deployment environment for the application. Here we have stages debug, dev, test and prod which roughly correspond a typical development workflow.

• debug -- The application container has additional debugging tools (in this case just ipdb) which are not desirable in a production container. The developer is expected to want to run the application in the foreground, so the container just waits (basically tail -f /dev/null).
• dev -- The container runs the server with the app/w script, which watches files in app/src and restarts the application when files change (see Development tooling/automations below to see why files on a container might change).
• test -- The container is identical to the prod container, but runs in the test namespace. This represents the role of CI/CD in the SDLC.
• prod -- It’s production. Basically has no meaning in this demonstration repo ...

Test

To demonstrate how one might add an integration test against this kind of Kubernetes workflow, a container is defined in test/Dockerfile that is executed outside the cluster, and makes requests to the service that is expected to be running. We use pytest because it’s awesome.

Development tooling/automations

With the debug and dev stages introduced above, it makes sense to create some development automations that simplify common tasks.

hotfix

A tool to copy files from the developers machine to those pods targeted in hotfix.yml; in this case anything labelled service: hello-world in either debug or dev namespaces. To start the tool, use make hotfix.

debug* targets

A couple of targets are provided to start a debugging session. They are perhaps most easily explored in action;

• Run the make debug command in shell A, this is the shell in which we will run the application.
• Once the above completes, run the make hotfix command in shell B
• Add a breakpoint in the application, ie. uncomment line 13 of app/src/main.py
• The hotfix command running in shell B will copy the altered file to the debug pod, we can now run the server in shell A (the command is printed there for your convenience).
• In shell C run make debug-request, which will send an HTTP request to our application, our breakpoint will offer an interactive shell (in shell A). We can reassign the variable name with name = 'debug' and continue the application running with c.
• In shell C we will see the altered message "hello from debug" printed to the terminal.

LICENSE

Copyright (c) 2020, Steady Supply Ltd.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.