DEV Community: Clemens Kaserer

Sticky session in Kubernetes - Hello World!

Clemens Kaserer — Thu, 02 Apr 2020 19:43:05 +0000

Common requirements for stateful applications include the ability to support sticky sessions. Let's take a look on how to implement this in Red Hat OpenShift or Kubernetes. The excercise can be done either on OpenShift or Kubernetes. With OpenShift we will use additional OpenShift resource types that are not available in Kubernetes (e.g Routes in OpenShift vs Ingress in Kubernetes).

Out of scope - we will not cover application level session replication as this is application or middleware specific.

In this excercise we will work with a helm chart to install a simple application to showcase sticky sessions. Hence our prerequirements are as follows

OpenShift or Kubernetes
helm
git
excersice repo

To start the excercise we need to check out the excersie repo and update our values.yaml to allow access from outside th cluster to our application depending on which platform we are using.

For Kubernetes we enable the ingress resource by setting create to true and the host to a hostname that resolve to an IP of our cluster.

# Kubernetes
ingress:
  create: true
  host: "hello-ckaserer.apps.p.aws.ocp.gepardec.com"

For OpenShift we enable the route resource by setting create to true.

# OpenShift
route:
  create: true

Okay, now that we have customized our configuration we can continue to install the resources from the helm chart via

$ helm install hello .

Helm installs based on the config specified in values.yaml

a statefulset running our example application with 3 replica
a ServiceAccount to run our statefulset
a service
an ingress or a route to access our application

To verify that our application is working as expected we can open the newly created ingress/route in a browser.

With Kubernetes you can use the cli to get the ingress information via

$ kubectl get ingress hello

With OpenShift you can either find the correct URL in the OpenShift Console (Web) or via the cli

$ oc get route hello

As long as you do not delete the cookies you are using to access the website from the browser and the pod that is serving your request is not terminated you will always end up on the same pod.

Let's take a look on what makes the route in OpenShift sticky. Through annotations we can add additional information to the router instance exposing the route. By adding the annotation router.openshift.io/cookie_name we tell the router to set and track cookies with the name hello-1. Cookies are automatically used for https routes, but for http routes we need to set the cookie_name to enable cookies for http traffic.

kind: Route
apiVersion: route.openshift.io/v1
metadata:
  name: hello
  annotations:
    router.openshift.io/cookie_name: "hello-1"
...

What happens when we manually kill the pod we are currently connected to? Let's find out! First we need to be quick here or Kubernetes/OpenShift will have already spun another replica up and you might end up on a pod with the same name.

So be quick and terminate the pod that you are currently connect to (e.g. hello-0) by executing

Kubernetes

$ kubectl delete pod hello-0

OpenShift

$ oc delete pod hello-0

Quickly open your browser and refresh the page. You should get a response from another replica now.

Now let's do the same but with curl from our comandline

Kubernetes

$ for I in $(seq 1 8); \
  do \
      curl -s \
      http://$(kubectl get ingress hello -o jsonpath='{.spec.rules[0].host}') | grep "Server name"; \
  done

OpenShift

$ for I in $(seq 1 8); \
  do \
      curl -s \
      http://$(oc get route hello -o jsonpath='{.spec.host}') | grep "Server name"; \
  done

When you run curl multiple times as we do with the loop here you should realize that the backend pod varies. But why?! Well we curl the website without storing our cookie and therefore every request appears as a new client.

In order to get the same behaviour as we have seen in the browser beforhand we need to store and use a cookie.

Kubernetes

$ curl -s -o /dev/null \
    --cookie-jar cookies.txt \
    http://$(kubectl get ingress hello \
    -o jsonpath='{.spec.rules[0].host}')

OpenShift

$ curl -s -o /dev/null \
    --cookie-jar cookies.txt \
    http://$(oc get route hello \
    -o=jsonpath='{.spec.host}')

Perfect, now we got our cookie file. Next we can use the cookie file for multiple curl commands and realize that every request is served by the same pod.

Kubernetes

$ for I in $(seq 1 8); \
  do \
      curl -s \
      --cookie cookies.txt \
      http://$(kubectl get ingress hello -o jsonpath='{.spec.rules[0].host}') | grep "Server name"; \
  done

OpenShift

$ for I in $(seq 1 8); \
  do \
      curl -s \
      --cookie cookies.txt \
      http://$(oc get route hello -o=jsonpath='{.spec.host}') | grep "Server name"; \
  done

Wonderful, that's all for now.

Conclusion

We installed a statefulset in OpenShift via helm and exposed it via a route. A web browser will automatically store cookies for us and our sticky session works out of the box. We always end up on the same pod unless the pod gets terminated or we delete our cookies.

If we use curl from the commandline we did not get sticky sessions out of the box, since by default curl does not store cookies from one request to the next. We need to store our cookie manually and use it in our curl command in order to get the same behavior as with a web browser.

What happens to the application state associated to my session if the pod is terminated? It's lost. In this example we did not cover application level session replication. If a pod is terminated all sessions of that pod are lost. E.g. if your app has a login functionality and are logged in before your pod terminates, you will be logged out after the pod terminated and another pod, unaware of your session, handles your request.

Source

Containerized Travis CLI

Clemens Kaserer — Sun, 15 Mar 2020 18:41:27 +0000

travis-ci.com describes itself as "The simplest way to test and deploy your projects."

Travis offers a cli to interact with their services. That's great! We can use it to script functionality instead of manually executing and clicking in the UI every god damn time.

I am no fan of installing various packages with different package managers all over my workstation. I am a big fan of container technology however and use travis-ci for most of my projects on github.

Since I am an outspoken advocate of container technology and use travis-ci for most of my projects on github I put travis' cli in a ruby based container. This container is available in two flavors, either with a fixed version or with the latest and greatest travis cli release. The source code is available on github.com/ckaserer/docker-travis-cli.

If you need to read up on what travis cli can do for you, here is the link you seek

https://github.com/travis-ci/travis.rb

Preflight

Okay, the whole point is to avoid installing travis cli on our workstations. To avoid local installation we will use container technology as our abstraction layer.

Therefore we will need to install a container runtime. Please install docker on your workstation if you haven't done so already.

In order to make it easier to use travis as a container a few bash functions are available in the bashrc of the git repository. I really recommend that you source the bashrc - it abstracts away all the options and parameter used in the docker command for you. In the next section you will see why.

source bashrc

However it is not just black magic - all commands that are available via the bashrc in this repository will be printed before execution to increase transparency.

Run your travis cli command in a container

Just like you would run your travis cli command locally you can do so with the bashrc function docker-travis. e.g. to get the cli version of the travis-cli image you are using simply run

docker-travis travis version

which wraps following command for ease of use

docker run --rm -it -e TZ=Europe/Vienna -v /home/myuser/.travis:/root/.travis -v /home/myuser/path/to/your/current/directory:/root ckaserer/travis-cli travis version

As you can see the container you are using is deleted after it ran with --rm, set the timezone to Europe/Vienna, mount your current directory into the container to inject updates into files in your git repository. e.g. you want to add a slack token to your .travis.yml.

cookiecutter for container images

Clemens Kaserer — Sun, 01 Mar 2020 08:28:45 +0000

What is cookiecutter?!

Cookiecutter is a command-line utility that creates projects from cookiecutters (project templates), e.g. creating a Python package project from a Python package project template.

Documentation: https://cookiecutter.readthedocs.io
GitHub: https://github.com/cookiecutter/cookiecutter
PyPI: https://pypi.python.org/pypi/cookiecutter
Free and open source software: BSD license

Sidenote

I maintain a containerized version of all cookiecutter releases starting with 1.7.0 at dockerhub.
If you want to know more check out the associated repository at github.com/ckaserer/cookiecutter or my blog post containerized cookiecutter.

Cookiecutter for container images

The goal of today is to standardize and automate your container image build process. From folder structure, to CICD, to publishing to a container registry, to build notifications via slack with cookiecutter templates.

Requirements

cookiecutter or its containerized cookiecutter version
travis
container registry
slack

Getting stared

To process the docker-cookiecutter template execute

cookiecutter https://github.com/ckaserer/docker-cookiecutter

Here a quick look at the resulting target folder structure

docker-{{cookiecutter.image_name}}
├── .ci
│   └── test.sh                     <- put your tests here
├── .dockerignore                   <- ignore files when building
├── .github                         <- github issue templates
│   └── ISSUE_TEMPLATE
│       ├── bug_report.md
│       └── feature_request.md
├── .gitignore
├── .travis.yml                     <- slack notifications for our tests
├── CODE_OF_CONDUCT.md
├── Dockerfile                      <- what we actually want
├── LICENSE
├── README.md                       <- badges and quickstart info
└── bashrc                          <- bash functions for easy of use

Next, we need to add our registry credentials to be able to push our images to a container registry and our slack integration for build notifications.
You can find a how-to for those steps in the README.md of your processed docker-cookiecutter template or directly via this link.

Source

Containerized Cookiecutter

Clemens Kaserer — Sat, 15 Feb 2020 14:30:59 +0000

What is cookiecutter?!

A command-line utility that creates projects from cookiecutters (project templates), e.g. creating a Python package project from a Python package project template.

Documentation: https://cookiecutter.readthedocs.io
GitHub: https://github.com/cookiecutter/cookiecutter
PyPI: https://pypi.python.org/pypi/cookiecutter
Free and open source software: BSD license

Cookiecutter as a Container

Wonderful, now let's use cookiecutter from a container instead of installing it on your machine.

Base image

The image is based on python:3 and can be build for any architecture supported by python:3.

Flavors

The cookiecutter container image is available in 2 flavors

latest is build daily via travis and if the base images changes
version during each travis build the current cookiecutter version is validated and the image is tagged accordingly starting with 1.7.0. More versions can be found on hub.docker.com/r/ckaserer/cookiecutter.

Requirements

Bash
docker

Getting started

To process any cookiecutter template you can execute

docker run --rm -it -v $(pwd):/cookiecutter ckaserer/cookiecutter TEMPLATE

Or if you like the a more convinient approach you can put following lines in your bashrc

# cookiecutter
function cookiecutter () {
  local command="docker run --rm -it -v $(pwd):/cookiecutter ckaserer/cookiecutter"
  echo "+ ${command} $@" && ${command} $@
}
readonly -f cookiecutter
[ "$?" -eq "0" ] || return $?

and after sourcing your bashrc again to load the newly added function into our shell via

source ~/.bashrc

you can process your template just like you would when installing cookiecutter on your machine via

cookiecutter TEMPLATE