DEV Community: Gabriel Tanner

Modern continuous delivery on Kubernetes for developers

Gabriel Tanner — Tue, 23 Mar 2021 16:19:15 +0000

Continuous delivery (CD) in a Kubernetes environment has always been a challenging and daunting task to set up and maintain, but it doesn’t have to be this way. Modern tools can make your application development and deployment process as efficient, quick, and sustainable as possible without requiring a lot of configuration.

Modern tools not only help you with safely getting a new version of your application into production, they also give you the ability to automatically detect and address any problems that arise so you can minimize their impact and provide the best user experience possible.

By the end of this article, you’ll understand the most essential concepts of modern continuous delivery and have a working Kubernetes deployment with a complete continuous delivery workflow—all without having to write a single line of pipeline code.

The CD environment you are going to set up will feature a multi-stage environment with two stages for hardening and production and quality gates that will use Prometheus metrics from your application to check whether the deployment is ready to be promoted into production. The workflow is illustrated in the image below.

Prerequisites

Before you begin, you’ll need the following

A Kubernetes cluster with at least one node with 4 vCPUs and 16 GB of Memory. To create a GKE cluster suitable for deploying the demo, see the GKE Quickstart of Keptn, the open-source tool that you'll be using in this article.
The kubectl command line tool installed on your development machine and connected to your cluster. You can find out more about installing kubectl in the official documentation.
The git command line tool installed to clone a demo application from GitHub.

Step 1: Understand the concepts of modern CD

Before setting up an environment, it's crucial that you are familiar with the most essential concepts regarding modern CD.

Declarative

Most companies today are still building their continuous delivery workflows in an imperative way. Writing and maintaining pipeline code can be very difficult and may lead to a lot of manual work for developers; this is time they can’t use to develop actual software.

A declarative approach however allows developers to define what needs to be done and have the CD tool handle the rest. This not only decreases the time required to write and maintain the configuration, it also benefits developers who are already familiar with defining declarative
configurations using tools like Kubernetes and don’t need to learn complicated tooling.

Scalable

Another essential factor is how easy it is to add new services to your existing pipeline or declaratively defined project and how much effort it is to maintain these different configurations for your services. Organizations often have hundreds of microservices to be managed and deployed in their pipelines.

Most imperative pipelines need a lot of boilerplate code to add new services and can therefore quickly become hard to read and maintain. Declarative definitions on the other hand are easily edited without the need to copy boilerplate code.

Extensible

Many companies already have a preexisting technology stack, including observability tools like Prometheus or test automation such as Jmeter or Neoload and therefore want to reuse their already implemented functionality in their CD workflow. Modern CD tools allow organizations to use existing tools to integrate with their CD workflow and provide a framework for implementing new custom functionality along with existing functionality.

Quality Gates

To ensure the best user experience, applications need a quality check before they can be deployed in a production environment. Quality gates are used to automatically ensure that specifically defined criteria (like response time, error rate, throughput, etc..) are met before deploying your services into production.

These criteria can be declaratively defined using Site-Reliability Engineering (SRE) concepts such as SLIs (service level indicators) and SLOs (service level objectives).

Service-level indicator (SLI)

A service-level indicator is a quantitative measure (metric) of some aspect of your application like response time, error rate or throughput.

Service-level objective (SLO):

A service-level objective defines a certain condition using the SLI that must be met to pass the test. An example of this is a response time on a particular endpoint that needs to remain lower than 200 milliseconds or an error rate that must remain lower than 1%.

Step 2 - Our CD orchestrator of choice: Keptn

Now that you’ve established the essential concepts of modern CD, let's look at an orchestrator that is built upon these concepts and makes them accessible and easy to use.

Keptn is an open-source cloud-native application life-cycle orchestrator and a Cloud Native Computing Foundation (CNCF) project. Keptn uses a declarative approach that allows you to specify DevOps and SRE automation workflows like delivery or operations automation without scripting all the details. The definitions can then be shared across any number of microservices without the need to build individual pipelines and scripts.

Keptn also includes built-in quality gates based on SRE principles such as SLIs and SLOs that help you evaluate and score your defined criteria to decide if a new version is allowed to be promoted to the next deployment stage or if it has to be held back or even rolled back.

Moreover, Keptn provides an excellent integration ecosystem where it translates well-defined cloud events into proprietary vendor APIs. The ecosystem already features many integrations for well-known services like JMeter, LitmusChaos, and Prometheus and allows the user to easily add their own integrations. And thanks to its open-source nature, adding new integrations is possible.

Step 3 - Setting up the platform

Now that you know the essential concepts of modern CD and the advantages that modern CD provides—you’re ready to set up Keptn.

In this section, you will deploy Keptn on your Kubernetes cluster, and connect the cluster to the Keptn CLI (make sure to follow the prerequisites on top of this article).

Before setting up Keptn on your Kubernetes cluster, you first need to decide how you want to expose Keptn. You can complete the setup using an ingress server, as described in this article, or by using any of the other options mentioned in the Keptn documentation.

In this article, you’ll expose via Istio. Therefore, you’ll get started by downloading the Istio installation script from the official website using the following command:

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.8.2 sh -

This command will create a folder with the name istio followed by the downloaded version in your current directory. You can execute the installer by running the following command:

./istio-1.8.2/bin/istioctl install

The installer will create all resources needed in your Kubernetes cluster to use Istio including CRD (Custom resource definitions), Configmaps, and more.

Next, you’ll download and install the Keptn CLI that can be used to install and manage Keptn.

If you are using Linux or MacOS you can also install the CLI using the following command:

curl -sL https://get.keptn.sh | KEPTN_VERSION=0.8.0 bash

If you want, you can also manually download the binary file from Github and install the CLI by moving it into your path.

You can now validate the installation using the —help flag:

keptn --help

Keptn consists of a control plane and an execution plane. The control plane allows using Keptn for the quality gates and automated operations use cases while the execution plane adds additional functionality, such as continuous delivery capabilities and services to integrate with testing frameworks such as Jmeter. In this case you will install Keptn by using the continuous-delivery use-case.

keptn install --endpoint-service-type=ClusterIP --use-case=continuous-delivery

The install process usually takes less than 3 minutes and creates all the basic Kubernetes resources needed to run Keptn. You can verify the status using the following command:

kubectl get deployments -n keptn

Once the installation is finished your output should look similar to this:

NAME                                             READY   UP-TO-DATE   AVAILABLE   AGE
api-gateway-nginx                                1/1     1            1           2m44s
api-service                                      1/1     1            1           2m44s
bridge                                           1/1     1            1           2m44s
configuration-service                            1/1     1            1           2m44s
eventbroker-go                                   1/1     1            1           2m44s
gatekeeper-service                               1/1     1            1           2m44s
helm-service                                     1/1     1            1           2m44s
helm-service-continuous-deployment-distributor   1/1     1            1           2m44s
jmeter-service                                   1/1     1            1           2m44s
lighthouse-service                               1/1     1            1           2m44s
mongodb                                          1/1     1            1           2m44s
mongodb-datastore                                1/1     1            1           2m44s
remediation-service                              1/1     1            1           2m44s
shipyard-service                                 1/1     1            1           2m44s

Once Keptn is installed the next step is to configure Istio so that you can access your Keptn instance. Istio is used as the Ingress controller that is responsible for the traffic routing to your cluster.

To make the setup experience as smooth as possible the Keptn team has provided scripts that automatically configure Istio with standard working settings. If you want to customize the setup yourself please take a look at the Keptn documentation.

First you will download the configuration script from Github using curl.

curl -o configure-istio.sh https://raw.githubusercontent.com/keptn/examples/release-0.8.0/istio-configuration/configure-istio.sh

Next, run the configuration script using the following commands:

chmod +x configure-istio.sh
./configure-istio.sh

Now check that the Ingress has been created:

kubectl get ingress -n keptn

The command will output the following:

NAME                HOSTS                  ADDRESS         PORTS   AGE
api-keptn-ingress   ${IP-Address}.nip.io   ${IP-Address}   80      56d

After successfully configuring Istio, you will authenticate your Keptn CLI against the Keptn control-plane you just installed. For that, you need the endpoint of your Keptn API as well as the API token, both of which can be read using kubectl.

KEPTN_ENDPOINT=http://$(kubectl -n keptn get ingress api-keptn-ingress -ojsonpath='{.spec.rules[0].host}')/api
KEPTN_API_TOKEN=$(kubectl get secret keptn-api-token -n keptn -ojsonpath='{.data.keptn-api-token}' | base64 --decode)

This kubectl get command uses the -n flag to set the namespace where the resource is located and the -ojsonpath flag to specify the variable that should be read in the returned output. The values returned by the commands are saved directly to environment variables.

Once the values are stored inside the environment variables the following command can be used to authenticate to the Keptn cluster.

keptn auth --endpoint=$KEPTN_ENDPOINT --api-token=$KEPTN_API_TOKEN

Once the CLI is successfully authenticated with the Keptn cluster you'll receive output similar to:

Starting to authenticate
Successfully authenticated

Step 4 - Create CD resources and deploy the application

Now that you’ve successfully set up Keptn on your Kubernetes cluster, you'll continue by creating a simple HTTP server application and create all the CD resources necessary to deploy the application using Keptn. We’re going to use a demo application provided by the Cloud-Native Computing Foundation (CNCF) that has been built to showcase different deployment/delivery tool capabilities.

First, you’ll clone the project's repository, so you have all the resources needed to start deploying your application on Kubernetes using Keptn.

git clone https://github.com/cncf/podtato-head.git

This command will clone the podtato-head repository from Github and create a folder with the name of podtato-head in your directory. Now you can continue by opening the project in your favorite code editor. You can then find the application in the podtato-server folder of the repository.

The application is already dockerized with a Dockerfile and a bash utility file that helps you push different versions of the Docker images onto a registry.

The registry images will now be used to create the Helm chart that is used to deploy the application on Kubernetes. The Helm chart consists of few files and can be found under delivery>keptn>helm-charts>helloserver.

Chart.yaml - This file contains all the chart information, including the name, version number, etc.
values.yaml - This file is used to define the values that you want to inject into your templates.
Templates - This is the folder where you store the actual manifests that are deployed with the chart. This example only contains a deployment and service file for the application, but it could also include more Kubernetes configurations like configmaps, secrets, etc.

The manifest of the deployment resource looks like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloservice
  namespace: {{ .Release.Namespace }} 
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: helloservice
  template:
    metadata:
      labels:
        app: helloservice
    spec:
      terminationGracePeriodSeconds: 5
      containers:
      - name: server
        image: {{ .Values.image}}
        imagePullPolicy: Always
        ports:
        - containerPort: 9000
        env:
        - name: PORT
          value: "9000"

The spec section defines your deployment's desired state containing information like the replica count and information about the created container. Kubernetes then attempts to create the desired state and take action to keep that state if something changes.

The spec.template key defines the rules that Kubernetes will use to create your pod. Here you define the pods deployment's specifics like the image name, pull policy, and container ports.

Next, let's look at the Kubernetes service file, which exposes port 9000 of your pod on port 80 of the Kubernetes worker.

apiVersion: v1
kind: Service
metadata:
  name: helloservice
  namespace: {{ .Release.Namespace }} 
spec:
  selector:
    app: helloservice
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 9000
  type: ClusterIP

Now that all the Helm and Kubernetes resources are defined, you can continue by creating a Keptn shipyard definition. The shipyard defines a task sequence for the delivery of your application. It can hold multiple dedicated stages, each with a different deployment-, test- and remediation strategy.

Thanks to the shipyard declarative approach, there is no need to write any imperative pipeline code.

apiVersion: "spec.keptn.sh/0.2.0"
kind: "Shipyard"
metadata:
  name: "shipyard-sockshop"
spec:
  stages:
    - name: "hardening"
      sequences:
        - name: "delivery"
          tasks:
            - name: "deployment"
              properties:
                deploymentstrategy: "blue_green_service"
            - name: "test"
              properties:
                teststrategy: "performance"
            - name: "evaluation"
            - name: "release"
    - name: "production"
      sequences:
        - name: "delivery"
          triggeredOn:
            - event: "hardening.delivery.finished"
          tasks:
            - name: "deployment"
              properties:
                deploymentstrategy: "blue_green_service"
            - name: "release"

According to the file, you are going to create a multi-stage environment with a hardening and a production stage. Keptn performs a blue/green deployment (i.e., two deployments simultaneously with routing of traffic to only one deployment) and triggers a performance test in the hardening stage. Once the tests complete successfully, the deployment moves into the production stage using another blue/green deployment. Note that the tooling definition (such as which testing tool is executing the tests) is not part of the shipyard file; this is defined as part of the Keptn uniform. In this example, you will use the standard tooling that comes with the default Keptn installation.

Now that you’ve defined the shipyard file, it is time to create your first Keptn project using the following command:

cd podtato-head/delivery/keptn

keptn create project pod-tato-head --shipyard=./shipyard.yaml

After the project is created, you can continue by onboarding helloserver as a service to your project using the keptn onboard service command and passing the project you want to onboard the service to as well as the Helm chart of the service.

keptn onboard service helloservice --project="pod-tato-head" --chart=helm-charts/helloserver

You can now take a look at the project you just created using the Keptn's Bridge, which is the UI of Keptn. You can find the generated access credentials using the following command:

keptn configure bridge --output

Now use the credentials and the URL of the following command to access the Keptn's Bridge.

echo http://$(kubectl -n keptn get ingress api-keptn-ingress -ojsonpath='{.spec.rules[0].host}')/bridge

Once you have successfully signed into the account you should see the following UI.

Now that you have created a project and onboarded a service you can continue by deploying your first artifact using the keptn trigger delivery command:

keptn trigger delivery --project="pod-tato-head" --service=helloservice --image="gabrieltanner/hello-server" --tag=v0.1.1

Here you need to provide the project and service name as well as the image you want to deploy as your artifact.

After deploying you can go back to the Keptn Bridge to see the event that has been generated for your artifact.

You can also verify the status of your pods using the following command:

kubectl get pods --all-namespaces | grep helloservice

This usually takes a couple of minutes, so just refresh until your output reflects something like the following:

pod-tato-head-hardening    helloservice-primary-5f779966f9-vjjh4                        2/2     Running   0          4m55s
pod-tato-head-production   helloservice-primary-5f779966f9-kbhz5                        2/2     Running   0          2m52s

Once the pods are running you can view your service using the URL you get from the following command or visit it over the Keptn Bridge.

echo http://helloservice.pod-tato-head-hardening.$(kubectl -n keptn get ingress api-keptn-ingress -ojsonpath='{.spec.rules[0].host}')

You should than see a page similar to this:

You have now successfully deployed your first service on Keptn in a multi-stage delivery without writing a single line of pipeline code. Next, you will add Quality Gates to your project to automatically ensure that specific defined criteria are met before deploying the service into production.

Step 5 – Add quality gates to CD

Now that you’ve successfully deployed your application on Kubernetes using Keptn it’s time to add quality gate functionality to ensure that your application is working correctly before it’s deployed to production.

The application already exposes the following custom Prometheus metrics:

http_requests_total - Total number of HTTP request on each site
http_server_request_duration_seconds_sum - Sum of the duration of all HTTP request for each page
go_routines - The number of currently running Goroutines
request throughput - The throughput is the number of requests that are successfully executed per time unit

These metrics can now be used to define custom metrics in your SLI file using Prometheus syntax. For example, you define the request_throughput as the sum of successful requests (200 status code) in a specific time period specified by the $DURATION_SECONDS environment variable that Keptn automatically sets.

---
spec_version: '1.0'
indicators:
  http_response_time_seconds_main_page_sum: sum(rate(http_server_request_duration_seconds_sum{method="GET",route="/",status_code="200",job="$SERVICE-$PROJECT-$STAGE-canary"}[$DURATION_SECONDS])/rate(http_server_request_duration_seconds_count{method="GET",route="/",status_code="200",job="$SERVICE-$PROJECT-$STAGE-canary"}[$DURATION_SECONDS]))
  http_requests_total_sucess: http_requests_total{status="success"}
  go_routines: go_goroutines{job="$SERVICE-$PROJECT-$STAGE"}
  request_throughput: sum(rate(http_requests_total{status="success"}[$DURATION_SECONDS]))

Next, you can define conditions that your SLIs need to meet in order for the deployment to pass the test and be promoted into the next stage.

The following SLO file holds three objectives:

The response time on the main page needs to be less than or equal to 1 second.
The percentage of successful requests must be between 80% and 100%.
There can be no more than 20 concurrent Goroutines running.

If all three criteria are satisfied, this objective is fulfilled and receives the full score.

---
spec_version: '0.1.0'
comparison:
  compare_with: "single_result"
  include_result_with_score: "pass"
  aggregate_function: avg
objectives:
  - sli: http_response_time_seconds_main_page_sum
    pass:
      - criteria:
          - "<=1"
    warning:
      - criteria:
          - "<=0.5"
  - sli: request_throughput
    pass:
      - criteria:
          - "<=+100%"
          - ">=-80%"
  - sli: go_routines
    pass:
      - criteria:
          - "<=100"
total_score:
  pass: "90%"
  warning: "75%"

Before you can use the SLI and SLO files, you need to configure Prometheus monitoring for your Keptn project. You can install the official Keptn Prometheus service using the following command:

kubectl apply -f https://raw.githubusercontent.com/keptn-contrib/prometheus-service/release-0.4.0/deploy/service.yaml

Next, you’ll set up the Prometheus Alerting Manager rules using the keptn configure monitoring command.

keptn configure monitoring prometheus --project=pod-tato-head --service=helloservice

Prometheus has now automatically set up scrape jobs for your application. Now that you’re scraping the metrics using Prometheus you also need to install the Prometheus SLI service, which will fetch the values for the SLIs referenced in an SLO configuration file during the build evaluation process.

kubectl apply -f https://raw.githubusercontent.com/keptn-contrib/prometheus-sli-service/release-0.3.0/deploy/service.yaml

Now that all services are set up correctly you can add the SLI and SLO files as resources to your Keptn project.

keptn add-resource --project=pod-tato-head --stage=hardening --service=helloservice --resource=prometheus/sli.yaml --resourceUri=prometheus/sli.yaml

keptn add-resource --project=pod-tato-head --stage=hardening --service=helloservice --resource=slo.yaml --resourceUri=slo.yaml

It’s also useful to generate some traffic to the endpoint of your application when running the tests. This can be done using the already defined JMeter files:

keptn add-resource --project=pod-tato-head --stage=hardening --service=helloservice --resource=jmeter/load.jmx --resourceUri=jmeter/load.jmx
keptn add-resource --project=pod-tato-head --stage=hardening --service=helloservice --resource=jmeter/jmeter.conf.yaml --resourceUri=jmeter/jmeter.conf.yaml

When you now deploy the same artifact as before all the tests will be executed before promoting the deployment to the production stage.

keptn trigger delivery --project="pod-tato-head" --service=helloservice --image="gabrieltanner/hello-server" --tag=v0.1.1

After sending the artifact you can see the test results in Keptn Bridge.

All the test cases defined in the SLO file have passed and the deployment has been promoted to production.

Step 6 – Validate the quality gates

Now that you’re working with quality gates, it’s time to validate that they are working by intentionally deploying a slow build that should fail the success criteria that you defined in the last step. The pod-tato-head application already has a slow build version implemented (v0.1.2) where every request is delayed by 2 seconds.

keptn trigger delivery --project="pod-tato-head" --service=helloservice --image="gabrieltanner/hello-server" --tag=v0.1.2

After sending the artifact you can see the test results in Keptn Bridge.

Here you can see that some of your defined test cases (for example, the response time) failed because you deployed a slow build that is not suitable for production. Once the test fails, the deployment will not be promoted to production and the hardening stage will return to its original state.

Conclusion

In this article, you configured Keptn, deployed your own application, and automatically validated the functionality without writing a single line of pipeline code. You also learned useful terminology and became familiar with the essential concepts of modern CD.

If you’re interested in learning more, consider checking out the official Keptn website or join the Slack community. Also, if you have any questions, feel free to post them in the comments and I will do my best to answer them.

An Introduction to testing in Javascript

Gabriel Tanner — Tue, 01 Sep 2020 07:44:17 +0000

Today, we are going to discuss testing in Javascript and help you in starting your journey towards understanding and mastering it.

Testing is one of the most important topics in software development, but a lot of developers still shy away from it. This article is here to change that.

The primary motivation behind this article is to give a clear overview of the entire world of Javascript testing and making it simple to understand. Even if you have no prior experience in testing, this article will prove to be the perfect start for your journey.

So, without wasting any further time, let's get started.

Why testing is important

Before diving into the various types and concepts of software testing, you should first have a clear understanding of why you should actually care about automated testing in the first place.

Building Confidence In Your Code:

To know that your code is working as planned, it needs to be tested in some kind. Manual test work for most small applications but don't provide the security and confidence level you get using automated tests.

Automated tests make it easy to test almost every possible situation and allow you to run them whenever you are making a change to your code.

Identifying every success and failure case and writing tests for them will ensure that you are confident with the code you are deploying for production.

Writing Minimal Code:

Testing also helps you to reduce the amount of code you are writing for a particular feature. After testing, your main goal is to write the minimal required code to make the tests pass. This coding style where you write tests before you write the actual implementation is also known as TDD (Test-driven development).

After successfully testing, you can focus on writing clean implementations with as minimal code as possible.

Getting Rid Of Regression Bugs:

Do you know the feeling when you have just finished a new feature of your application and want to release it to production and all of a sudden, an old feature isn't working anymore? You are absolutely clueless about why this is happening and will probably waste a lot of time searching for the issue.

This situation would have never occurred if you had tested your old features. You could have frequently run those tests to check if your application is still working as expected. The tests would also give you a better idea of what exactly isn't working anymore because the appropriate test cases would fail.

Types of tests

There are a few different types of tests, and it is essential to know how they differ from each other. Most applications will require you to write multiple kinds of tests to get the best result possible.

Unit tests:

The purpose of a unit test is to validate the functionality of a relatively small piece of software, independently from other parts. Unit tests are narrow in scope, which allows us to cover all cases to ensure that every single part works correctly.

They are small and highly focused tests that can efficiently be executed on your local machine because of their fast execution time. You are going to have hundreds, if not thousands of these tests and run them on a regular basis while developing.

The only downside to these kinds of tests is that they are not executed on real devices and therefore have lower fidelity than the other types of tests.

Integration tests:

Integration tests demonstrate that the different parts of your application work together in a real-life production environment. They verify that two separate modules or components are working together in the way they should.

These tests are of medium size and have a much higher execution time then Unit tests. They aren't executed as often but are still vital for checking the health status of your applications. Their fidelity is also a lot higher because they run on real devices and verify the actual interaction between various components of your application.

End-to-End tests:

End-to-End tests validate complex scenarios from end to end, and usually require external resources, like databases or web servers, to be present. Imagine you have an application with a sign-up flow comprising of several steps, and you want to test the entire flow, that’s where End-to-End tests come into play.

E2E tests will also run on real devices just like integration tests and therefore, will again be quite slow in their execution.

The only downside to these kinds of tests is that debugging them and finding out what went wrong if a particular test fails becomes very hard because of their vast scope.

Concepts

Before starting to write tests for your code, you first need to be familiar with the most crucial testing concepts and when you need to use them. These concepts will influence the architecture of your application and how you write code in general but more on that in a later section.

Matchers:

Matchers let you validate the results and values of your tests in different ways and are used to make sure that the results of the test match your expectations.

Imagine you have a function that calculates the result of a certain factorial number. Testing the function can then be done using the expect() function and a simple matcher that checks if the result of the function matches the expected value.

test('factorial of 2', () => {
  expect(factorial(2)).toBe(2);
});

The expect() function checks if the result meets the conditions defined by the matcher. We will make use of different matchers in the Jest testing framework at a later point in this guide.

Mocking:

An object under a test might have dependencies on other objects or services. To isolate the behavior of an object, you want to replace the other objects it interacts with by mocks that simulate the behavior of the real objects.

Mocks help your tests to avoid test unreliability (flakiness) and improve the speed of your tests. They are also useful if the real objects are impractical to incorporate into tests.

In short, mocking is creating objects or services that simulate the behavior of real objects (A database, for example).

Lifecycle:

When testing, you often execute multiple tests after each other and have some setup work that needs to happen before the tests run. Most frameworks provide helper functions to handle these scenarios.

Here is an example of lifecycle methods in the Jest testing framework.

beforeEach(() => {
  // Initialize objects
});

afterEach(() => {
  // Tear down objects
});

Testable architecture

Before starting to write tests for your code, you first need to make sure that your application's architecture is testable. If it is not, you need to understand why not and what you can do about it.

Untestable architecture is probably the most common reason why many people find testing tedious and difficult. If your code is not structured properly, you are definitely going to find it difficult to write tests for it.

Let's explore some important concepts you should know when talking about testable architecture.

Dependency injection:

Dependency injection is a concept where an object supplies the dependencies of another object. Instead of using the new keyword whenever creating a new object, all you need to do is ask the other object to give you the instance you want.

This concept helps when you need to change the implementation of some object, e.g. when you mock it for a particular test. Many modern frameworks like Angular and Nest.js have dependency injection already build in, but it is still good to know how it functions at a base level.

For more information on dependency injection, you can visit the following article.

SRP (Single responsibility principle):

The single responsibility principle, also known as SRP, is one of the SOLID principles and defines that a function should have a single purpose. This makes it far easier to test that each function does its part correctly.

If your function or service is performing more than one responsibility, then it is time to identify those responsibilities and separate them into individual functions.

Avoid side effects:

Your functions depend on external variables and services, and you have to set up that variable or service before testing your function. You’ll also have to trust that any other code being run isn’t altering that same variables and states.

That is why you should avoid writing functions that alter any external state (like writing to a file or saving values to a database). This prevents side effects and allows you to test your code with confidence.

Law of Demeter:

The Law of Demeter, which is also known as the “principle of least knowledge” states that a specific unit should have limited knowledge of the other units it coordinates with. The more your code depends on the internal details of the objects it interacts with, the more difficulty you will have when writing tests for them.

More information about the Law of Demeter can be found here.

Overview of the different testing tools

Now that you have an overview of the essential concepts in the testing world and when you need to use them, let's continue by looking at a short summary of the different Javascript testing tools that are available today.

Note: I will not cover every tool there is but instead look at the most important once to give you a quick overview of there benefits and weaknesses.

Jest:

Jest is an open-source testing framework created by Facebook with a focus on simplicity. Jest makes it faster and easier to write JavaScript tests by having everything included out of the box and needing zero configuration. Jest also runs your tests in parallel, providing a smoother, faster test run.

Mocha:

Mocha is a flexible JavaScript testing libraries available and aims to make asynchronous testing simple and fun. It provides developers with a basic test framework and gives them the option to choose which assertion, mocking, and spy libraries they want to use.

It requires some additional setup and configuration but gives you complete control of your testing framework in return.

Cypress:

Cypress is an all in one testing tool that is focused on making End-to-End testing easy and modern. Their tests are executed in the browser themself which gives them a better execution time and no network lag.

Cypress is used to deal with complex UI’s running on modern Javascript stacks. By using their framework and assertion library, it becomes easy to validate states in the UI. Cypress will then automatically wait for your application to reach this state before moving on.

Cypress is a newer and more modern tool than Jest and Mocha and is an excellent start for beginners and End-to-End testing in general.

Introduction to Jest

As already mentioned above, this guide will focus on the Jest testing framework because it is the most popular framework out there. But most of the concepts apply to all testing frameworks and can be useful no matter which technology you are using.

Jest is an open-source project maintained by Facebook and is especially well suited for Unit and Integration testing. Its strengths are:

It is simplistic and fast
It provides everything out of the box and thereby doesn't require and configuration (though you can change the configuration if you so choose)
It can perform snapshot testing

Now we will explore some practical examples so you can put your knowledge into practice.

Installation

Jest can be installed using either npm or yarn:

yarn add --dev jest
# or
npm install --save-dev jest

Notice that this will install Jest as a dev dependency as part of your package.json file in the current project. You can alternatively install it globally if you so choose.

yarn global add jest
# or
npm install jest -g

You can also add this line to your package.json to run your test using the test command.

{
  "scripts": {
    "test": "jest"
  }
}

Your first test

Now that we have installed Jest it is finally time to write our first test. But before we do that, we will write some basic code that we can test in the first place.

For that, we will create two files so we can get going.

touch maths.js
touch maths.spec.js

We will use the following function for calculating a factorial number to write our first test.

function factorialize(num) {
  if (num < 0) return -1;
  else if (num == 0) return 1;
  else {
    return num * factorialize(num - 1);
  }
}

module.exports = { factorialize }

Here are some very basic test cases for this small function.

const { factorialize } = require("./maths");

test("factorial of 3", () => {
  expect(factorialize(3)).toBe(6);
});

test("factorial of 5", () => {
    expect(factorialize(5)).toBe(120);
});

Running the yarn test command in your terminal should give you the following output:

Matchers

As already said above matchers let you validate the results and values of your tests in different ways.

They are most commonly used to compare the result of the expect() function to the value passed as an argument to the matcher (That is also what we did above).

Here is a list of the most common matchers:

toBe - compares for strict equality (e.g. ===)
toEqual - compares the values of two variables/objects
toBeNull - checks if the value is null
toBeDefined - checks if the value is defined
toBeUndefined - checks if the value is undefined
toBeTruthy - checks if the value is true (similar to an if statement)
toBeFalsy - checks if the value is false(similar to an if statement)
toBeGreaterThan - checks if the result of the expect() function is greater than the argument
toContain - checks if the result of expect() contains a value
toHaveProperty - checks if an object has a property, and optionally checks its value
toBeInstanceOf - checks if an object is an instance of a class

These matchers can also be negated using the not statement:

test("factorial of 3 is not 5", () => {
    expect(factorialize(3)).not.toBe(5);
});

You can also use additional matchers that are maintained by the Jest community.

Setup and Teardown

Often when writing tests, you will have to do some kind of setup like initializing variables before tests run and some sort of action after they have finished.

Jest provides two different ways you can do that.

One-Time Setup:

In some cases, you only need to do the setup once, at the beginning of your test file. In that scenario, you can use the beforeAll() and afterAll() helper functions that will execute before the tests start and after all have finished.

beforeAll(() => {
  return initializeDatabase();
});

afterAll(() => {
  return clearDatabase();
});

test('query from database', () => {
  expect(database.getObject('Florida')).toBeTruthy();
});

Repeating setup for each test:

If you have a setup process that needs to run before each test then you should use the beforeEach() and afterEach() functions.

beforeEach(() => {
  initializeDatabase();
});

afterEach(() => {
  clearDatabase();
});

test('query from database', () => {
  expect(database.getObject('Florida')).toBeTruthy();
});

Note: There will be scenarios where you will use both of these setup processes together to get the best results.

Grouping tests

You can also group related tests together so you can isolate the setup and teardown functions. Grouping tests will also help you get a better overview of your different test cases.

describe('testing factorial function', () => {
    beforeAll(() => {
        //do something
    })
    afterAll(() => {
        //do something
    })

    test("factorial of 3", () => {
        expect(factorialize(3)).toBe(6);
    });

    test("factorial of 5", () => {
        expect(factorialize(5)).toBe(120);
    });

    test("factorial of 3 is not 5", () => {
        expect(factorialize(3)).not.toBe(5);
    });
})

Testing async functions

It is common for Javascript code to run asynchronously using either promises or callbacks. The problem with testing asynchronous code is knowing when the code that you are testing is actually complete. Jest has several ways to handle this.

Promises:

Testing promises is straight forward in Jest. Just return the promise and Jest will wait for the promise to resolve. If the promise fails, the test will automatically fail aswell.

// string.js
const reverseString = str => {
  return new Promise((resolve, reject) => {
    if (!str) {
      reject("Empty string");
      return;
    }
    resolve(str.split("").reverse().join(""));
  });
};
module.exports = reverseString;

// string.spec.js
const reverseString = require("./string");

test(`reverseString 'String' to equal 'gnirtS'`, () => {
  return reverseString("String").then(str => {
    expect(str).toBe("gnirtS");
  });
});

You can also catch rejected promises using the catch() function.

test(`reverseString '' to reject promise`, () => {
  return reverseString("String").catch(error => {
    expect(e).toMatch("Empty string");
  });
});

Async await:

Alternatively, we can use async and await for testing promises.

const reverseString = require("./string");

test(`reverseString 'String' to equal 'gnirtS' using await`, async () => {
    const str = await reverseString("String")
    expect(str).toBe("gnirtS");
});

Note: You need to make your testing function async to use async and await.

Callbacks:

By default Jest tests complete once they reach the end of their execution which means that the test will be completed before the callback is called. This can be fixed by passing a single argument named done to your test function. Jest will wait until the done callback is called before finishing the test.

// string.js
function reverseStringCallback(str, callback) {
    callback(str.split("").reverse().join(""))
}

module.exports = {reverseStringCallback};

// string.spec.js
const {reverseStringCallback} = require("./string");

test(`reverseStringCallback 'string' to equal 'gnirts'`, (done) => {
    reverseStringCallback('string', (str) => {
      expect(str).toBe('gnirts')
      done()
    })
})

If done() is never called, the test will fail with a timeout error.

Mocking

Mocking is creating objects or services that simulate the behavior of real objects and plays a vital part in testing. The goal for mocking an object or function is to replace something we don’t control like an external service with something we do, that is why it’s essential that what we replace it with something that has all the features we need.

Using mocks also helps you to inspect information about your code e.g. if a function has already be called and which parameters were used.

Passing Mocks to functions:

One of the common ways to use the Mock function is by passing it as an argument to the function you are testing. This allows you to run your tests without importing the real dependencies and objects you would pass in your real application.

const multiplyNumbers = (a, b, callback) => {
  callback(a * b);
};

test("calls callback with arguments added", () => {
  const mockCallback = jest.fn();
  multiplyNumbers(1, 2, mockCallback);
  expect(mockCallback).toHaveBeenCalledWith(2);
});

This strategy is great but requires that your code supports dependency injection. If that is not the case you will need to mock already existing modules or functions instead.

Mocking a single function:

You can mock a single function using Jest.fn():

const lodash = require('lodash')

lodash.chunk = jest.fn(() => 'test')
test(`Test lodash chunk function`, () => {
    const result = lodash.chunk(['a', 'b', 'c', 'd'], 2)
    expect(result).toBe('test')
    expect(lodash.chunk).toHaveBeenCalled()
    expect(lodash.chunk).toHaveBeenCalledWith(['a', 'b', 'c', 'd'], 2)
})

Here I create a mock of the lodash.chunk function and test if it gets called and if the parameters are right.

Mocking Modules:

Mocking single functions works well if you only use one or two functions of a package or library but can get very cluttered when you need more functions of a module. Here we use jest.mock to automatically set the exports of an entire module instead of mocking the modules manually.

jest.mock('lodash');

test(`Test lodash chunk function`, () => {
    const result = lodash.chunk(['a', 'b', 'c', 'd'], 2)
    expect(lodash.chunk).toHaveBeenCalled()
    expect(lodash.chunk).toHaveBeenCalledWith(['a', 'b', 'c', 'd'], 2)

    const concatResult = lodash.concat(2, [3], [[4]]);
    expect(lodash.concat).toHaveBeenCalled()
    expect(lodash.concat).toHaveBeenCalledWith(2, [3], [[4]])
})

As you can see I can now call all functions of the lodash library as mock objects.

The only disadvantage of this strategy is that it is difficult to access the original implementation of the module. For those use cases, you can use the spyOn function instead.

Spying packages:

You can also spy on a package without creating a mock for it. This is done using the spyOn() function provided by Jest.

const lodash = require('lodash')

test(`Test lodash chunk function`, () => {
  const spy = jest.spyOn(lodash, 'chunk')
  const result = lodash.chunk(['a', 'b', 'c', 'd'], 2)

  expect(lodash.chunk).toHaveBeenCalled()
  expect(lodash.chunk).toHaveBeenCalledWith(['a', 'b', 'c', 'd'], 2)
})

Important things you should look at

There are a few more concepts you should definitely look at on your way to mastering testing in Javascript. But I would greatly recommend learning the basics first and putting them into practice in your applications.

Snapshot testing - Is used for testing the UI of your application
CI (Continous Integration) - The practice of automating the integration of code changes from multiple contributors into a single software project
CD (Continous Deployment) - Is a software release process that uses automated testing to validate if changes to a codebase are correct
Automated dependency updates

It is vital to practice testing in your own applications. If you do it long enough, then you will master the art of testing and make your applications more stable and secure in the process.

Sources:

Here is a list of the sources I used for this article:

Conclusion

You made it all the way until the end! I hope that this article helped you understand the basics of automated testing in Javascript.

If you have found this useful, please consider recommending and sharing it with other fellow developers. If you have any questions or feedback, let me know using my contact form or contact me on twitter.

The Definitive Guide to Kubernetes

Gabriel Tanner — Sat, 25 Jul 2020 07:31:41 +0000

In this guide, you will learn everything you need to know about Kubernetes and how you can use it to deploy and manage containers at scale.

Modern applications are increasingly built using container and microservice architecture. Kubernetes is open-source software for deploying and managing those containers at scale. It groups containers into logical units for easier management, discovery, and scaling of your application.

The primary motivation behind this article is to give a clear overview of the entire world of Kubernetes and making it simple and easy to understand. This guide will go over all essential concepts of Kubernetes and will then use them all in a practical example.

Even if you had no prior experience with Kubernetes before, this article will prove to be the perfect start for your journey.

So, without wasting any further time, let's get started.

Why care about Kubernetes?

Before we dive into the technical concepts, let's first discuss why a developer should even use Kubernetes in the first place. Here are some reasons why developers should consider implementing Kubernetes in their work.

Portability:

Moving containerized applications from development to production is a seeming less process when using Kubernetes. Kubernetes enables developers to orchestrate containers consistently in different environments across on-premises infrastructure and public and hybrid clouds.

Scalability:

Defining complex containerized applications and deploying them globally across multiple clusters of servers is made simple as Kubernetes optimizes resources according to your desired state. When Kubernetes scales applications horizontally, it will also automatically monitor and maintain container health.

Extensibility:

Kubernetes has a vast and ever-growing collection of extensions and plugins created by developers and companies that make it easy to add unique capabilities such as security, monitoring, or management capabilities to your cluster.

Kubernetes Concepts

Making use of Kubernetes requires an understanding of the different abstractions it uses to represent the state of the system. That is what this section is all about. Getting familiar with the most essential concepts and giving you a clearer picture of the general architecture.

Pods:

A Pod is a group of multiple containers of your application that share storage, a unique cluster IP address, and information about how to run them (e.g. container image, ports, restart and failure policies).

They are the building block of the Kubernetes platform. When we create a deployment or a service, Kubernetes will automatically create a Pod with the container inside.

Each pod runs on the node it is scheduled on and remains there until termination or deletion. In case the node fails or terminates, Kubernetes will automatically schedule identical Pods on the other available Nodes of the cluster.

Node:

A node is a worker machine in a Kubernetes cluster and may be either a virtual or a physical machine, depending on the type of cluster. Each node is managed by the so-called master. The master automatically schedules pods across all nodes in the cluster, depending on their available resources and current configuration.

Each node has to run at least two services:

Kubelet - A process responsible for the communication between the Kubernetes master and the node
A container runtime - Responsible for pulling and running a container image (Docker for example)

Services:

A Service is an abstraction that defines a logical set of Pods and a policy by which to access them. Services enable loose coupling between dependent Pods.

Although each pod has a unique IP-Address, those addresses are still not exposed to the outside of the cluster. A service therefore allows your deployment to receive traffic from outside sources.

Services can be exposed in multiple ways:

ClusterIP (standard) - Only expose the port to the internals of the cluster
NodePort - Expose the service on the same port on every node in the cluster using NAT
Loadbalancer - Create an external load balancer to export the service on a specific IP Address

Deployments:

Deployments contain a description of the desired state of your application. The deployment controller will then try to make sure that the current state of the application meets that description.

A deployment runs multiple replicas of your application and automatically replaces any instances that fail or become unresponsive. In this way, deployments help ensure that your application is available to serve user requests.

Installation

Before we can start creating our cluster, we first need to install Kubernetes on our local machine.

Docker Desktop:

If you are using Docker desktop on windows or mac, you can install Kubernetes directly in the settings window of the user interface.

Other installation:

If you are not using Docker desktop, I would recommend following the official installation guide for installing Kubectl and Minikube.

Kubernetes Basics

Now that we have the most essential concepts out of the way let's continue by looking at the practical side of Kubernetes. This chapter will guide you through all the basics you need to know to deploy applications in a cluster.

Creating a cluster:

Minikube automatically creates a cluster when you start it.

minikube start

Docker desktop should also automatically create a cluster after the installation. You can check if your cluster is running using the following commands:

# Get information about the cluster
kubectl cluster-info

# Get all nodes of the cluster
kubectl get nodes

Deploying an application:

Now that we have finished the installation and set up our first cluster, it is time to deploy an application to Kubernetes.

kubectl create deployment nginx --image=nginx:latest

We use the create deployment command and pass the name of the deployment and the container image as arguments. This example creates an Nginx deployment with one container and one replica.

You can see your running deployments using the get deployments command.

kubectl get deployments

Get information about your deployments:

Here are a few commands you can use to get more information about your deployments and pods in Kubernetes.

Getting all pods:

You can get a list of all running pods using the kubectl get pods command:

kubectl get pods

The output should look similar to this.

NAME                     READY   STATUS    RESTARTS   AGE
nginx-7654889675-zskr8   1/1     Running   0          4h29m

Get a detailed description of your pods:

If you want a more detailed description of your pods, you can use the describe pods command instead.

kubectl describe pods

Output:

Name:         nginx-674ff86d-88rj8
Namespace:    default
Priority:     0
Node:         node-3jis6/10.114.0.3
Start Time:   Fri, 24 Jul 2020 23:50:05 +0200
Labels:       app=nginx
              pod-template-hash=674ff86d
Annotations:  <none>
Status:       Running
IP:           10.244.0.54
IPs:
  IP:           10.244.0.54
Controlled By:  ReplicaSet/nginx-674ff86d
Containers:
  nginx:
    Container ID:   docker://5e91ecc5134de36be301635efdccd1816da4506b33d339ea2e845334acd958e2
    Image:          nginx:latest
    Image ID:       docker-pullable://nginx@sha256:0e188877aa60537d1a1c6484b8c3929cfe09988145327ee47e8e91ddf6f76f5c
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Fri, 24 Jul 2020 23:50:12 +0200
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-dn7gb (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  default-token-dn7gb:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-dn7gb
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason     Age        From                 Message
  ----    ------     ----       ----                 -------
  Normal  Scheduled  <unknown>  default-scheduler    Successfully assigned default/nginx-674ff86d-88rj8 to node-3jis6
  Normal  Pulling    16s        kubelet, node-3jis6  Pulling image "nginx:latest"
  Normal  Pulled     11s        kubelet, node-3jis6  Successfully pulled image "nginx:latest"
  Normal  Created    10s        kubelet, node-3jis6  Created container nginx
  Normal  Started    10s        kubelet, node-3jis6  Started container nginx

View the logs of a pod:

The information your application would typically send out to STDOUT become logs of your container. You can access those logs using the following command.

kubectl logs $POD_NAME

Note: You can get the name of your pod using either the get pods or describe pods command.

Executing a command in the container:

We can execute commands directly in our container using the kubectl exec command, which takes the pod name and the command we want to run as arguments.

kubectl exec $POD_NAME command

To clarify, let's look at an example where we start a bash terminal in the container.

kubectl exec -it $POD_NAME bash

Exposing your app publicly:

As we already discussed earlier, a service defines a policy by which the deployment can be accessed with. In this section, we are going to take a look at how this is done and some different options you have when exposing your services to the public.

Creating a service:

We can create a service using the create service command that will take the port we want to expose and the type of port as arguments.

kubectl create service nodeport nginx --tcp=80:80

This will create a service for our Nginx deployment and expose the port 80 of our container to a port on our host machine.

You can get the port on the host machine using the kubectl get services command:

NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)           AGE
kubernetes   ClusterIP   10.245.0.1      <none>        443/TCP           27h
nginx        NodePort    10.245.74.155   <none>        80:30392/TCP      8s

As you can see, port 80 of the container is forwarded to port 31041 of my host machine. When you have the port, you can verify your deployment by visiting your localhost on that port.

Deleting a service:

We can also remove existing services using the delete service command.

kubectl delete service nginx

Scale up your app:

Scaling your application up and down is extremely simple using Kubernetes. You can change the number of replicas using a single command and Kubernetes will automatically create and maintain everything for you.

kubectl scale deployments/nginx --replicas=5

This command will scale our Nginx service up to five replicas.

This way of deploying applications works excellent for small one container application but doesn't provide the overview and reusability needed for more prominent applications. This is where YAML files come into play.

YAML files let you declare your deployment, services and pods using a markup language, so they are reusable and better for scaling. Yaml files will be covered in-depth in the following chapters.

Declaring Kubernetes object in YAML

Every object in Kubernetes can be represented as a declarative YAML object that provides details about what and how you want to run. These files are often used to increase the reusability of resource configuration like deployments, service, volumes and many more.

This section will show you the basics of YAML and how you can get a list of all available parameters and attributes of a Kubernetes object. We will also take a look at a deployment and service file to get a better feeling of the syntax and how you can deploy the file.

Getting the parameters of the different objects:

There are many different Kubernetes objects and it is hard to remember every setting. That is where the explain command comes into play.

kubectl explain deployment

# Output
KIND:     Deployment
VERSION:  extensions/v1beta1

DESCRIPTION:
     DEPRECATED - This group version of Deployment is deprecated by
     apps/v1beta2/Deployment. See the release notes for more information.
     Deployment enables declarative updates for Pods and ReplicaSets.

FIELDS:
   apiVersion   <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#resources

   kind <string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds

   metadata     <Object>
     Standard object metadata.

   spec <Object>
     Specification of the desired behavior of the Deployment.

   status       <Object>
     Most recently observed status of the Deployment.

You can also get the documentation of a specific field using the following syntax:

kubectl explain deployment.spec.replicas

Deployment file:

More complex deployments will normally be written in YAML for easy reusability and changeability.

Here is the basic file structure:

apiVersion: apps/v1
kind: Deployment
metadata:
  # The name and label of your deployment
  name: mongodb-deployment
  labels:
    app: mongo
spec:
  # How many copies of each pod do you want
  replicas: 3
  # Which pods are managed by this deployment
  selector:
    matchLabels:
      app: mongo
  # Regular pod configuration / Defines containers, volumes and environment variable 
  template:
    metadata:
      # label the pod
      labels:
        app: mongo
    spec:
      containers:
      - name: mongo
        image: mongo:4.2
        ports:
        - containerPort: 27017

The YAML file has multiple important sections:

apiVersion - Defines the version of the API -kind - The kind of Kubernetes object defined in the file (e.g. deployment, service, persistentVolume, ...)
metadata - Description of your YAML component containing name, labels and other information
spec - Defines the attribute of your deployment e.g. replicas, resource limits
template - Pod configuration of the deployment file

Now that you know the basic structure, you can deploy the file using the apply command.

kubectl apply -f deploy.yaml

Service file:

Service files have a similar structure then deployments with minor differences in the parameters.

apiVersion: v1
kind: Service
metadata:
  name: mongo
spec:
  selector:
    app: mongo
  ports:
    - port: 27017
      targetPort: 27017
  type: LoadBalancer

Storage

When a pod is deleted or a container restarts, the whole data of the file system is deleted. In most cases, this is a good thing, because your stateless application doesn't get littered with unneeded data. In other cases, persisting the data of your file system is vital for your application.

There are a few different kinds of storage:

Container filesystem - Standard storage that stores the data of a single container for his lifetime
Volume - Volumes let you save data and share it between different containers as long as the pod exists
Persistent Volumes - Persistent Volumes save data even after the pod is deleted or restarted. They are the long-term storage in your Kubernetes cluster.

Volumes:

Volumes let you save, share, and preserve data between multiple containers as long as the pod exists. This can be useful if you have pods with multiple containers that need to share data with each other.

There are two steps for using a volume in Kubernetes:

The pod defines the volume
The container uses the volumeMounts to add the volume to a specific path of the filesystem

You can add a volume to your pod using the following syntax:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: nginx-storage
      mountPath: /etc/nginx
  volumes:
  - name: nginx-storage
    emptyDir: {}

The volumes tag is used to define the volume that can then be mounted to a specific directory of the container filesystem (in this case /etc/nginx).

Persistent Volumes:

Persistent volumes are almost identical to normal volumes, with the key difference that they preserve the data even after the pod is deleted. That is why they are used for long-term data storage purposes like a database, for example.

The most common way to define a persistent volume is a so-called Persistent Volume Claim (PVC) object, which connects to backend storage volumes through a series of abstractions.

Here is an example YAML configuration file.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pv-claim
  labels:
    app: sampleAppName
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

You can then use your PVC in your actual Kubernetes deployment.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  selector:
    matchLabels:
      app: mysql
      tier: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
        tier: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-password
              key: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

There are more ways to save your data in Kubernetes and automate that process as much as possible. Here is a list of a few interesting topics you should take a look at.

Managing compute resources

Managing compute resources of your containers and applications is an important topic when it comes to container orchestration.

When your containers have a specified amount of resources available, the scheduler can make better decisions about which node to place the pod on. You will also run into fewer contention problems with the resources of different deployments.

There are two different types of resource specifications that we will cover in detail in the next two sections.

Requests:

Requests tell Kubernetes the requirements of the pod and that it should only place the pod on nodes that have these requirements. Requests are defined under the resources tag on your container.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mongodb-deployment
  labels:
    app: mongo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mongo
  template:
    metadata:
      labels:
        app: mongo
    spec:
      containers:
      - name: mongo
        image: mongo:4.2
        ports:
        - containerPort: 27017
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"

Limits:

Resource limits are used to constrain the memory and CPU usage of a specific pod and provide the maximum value of resources that the pod can never exceed.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mongodb-deployment
  labels:
    app: mongo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mongo
  template:
    metadata:
      labels:
        app: mongo
    spec:
      containers:
      - name: mongo
        image: mongo:4.2
        ports:
        - containerPort: 27017
        resources:
          limits:
            memory: "128Mi"
            cpu: "500m"

For more information on managing compute resources visit the official documentation.

Secrets

Kubernetes secrets allow you to safely store and manage sensitive data like passwords, API tokens or SSH keys.

To use a secret in your pod, you first need to reference it. This can happen in multiple ways:

As a file in a volume which is mounted to a container
Using an environment variable
By kubelet when pulling an image from a private registry

Creating a secret:

Creating secrets can either be done using the kubelet command tool or by defining a secret Kubernetes object using YAML.

Using kubelet:

Kubelet lets you create secrets using a simple create command where you only have to specify the data and the name of the secret. The data can either be passed in using a file or a literal.

kubectl create secret generic admin-credentials --from-literal=user=poweruser --from-literal=password='test123'

The same functionality using a file would look something like this.

echo -n 'poweruser' > ./username.txt
echo -n 'test123' > ./password.txt
kubectl create secret generic admin-credentials--from-file=./username.txt --from-file=./password.txt

You can also provide multiple files at once by using a folder.

kubectl create secret generic admin-credentials --from-file=/creds

Using definition files:

Like other Kubernetes objects, secrets can also be defined using a YAML file.

apiVersion: v1
kind: Secret
metadata:
  name: secret-apikey
data:
  apikey: YWRtaW4=

The secret contains a key-value pair of your sensitive information with apiKey being the key and YWRtaW4= being the base decoded value.

You can now create the secret using the apply command.

kubectl apply -f secret.yaml

If you want to provide plain data and let Kubernetes handle the encoding for you, just use the stringData attribute instead.

apiVersion: v1
kind: Secret
metadata:
  name: plaintext-secret
stringData:
  password: test

Using secrets:

To make secrets useful, we first need to make them accessible to our containers. Let's take a look at the ways we can do that.

Environment variables:

Secret data can be consumed using environment variables in a Pod.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
    - name: nginx
      image: nginx
      env:
        - name: API_KEY
          valueFrom:
            secretKeyRef:
              name: secret-apikey
              key: apikey

The environment variable can then be used after the pod is in the running state.

kubectl exec nginx-pod -- env | grep API_KEY

You can also use all entries of a secret using the envFrom that and passing the secret.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
    - name: nginx
      image: nginx
      envFrom:
        - secretRef:
            name: secret

Volumes:

Secrets can also be mounted to a pod using a Volume.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: apikey-volume
          mountPath: /secret
          readOnly: true
  volumes:
    - name: apikey-volume
      secret:
        secretName: secret-apikey

The apikey-volume refers back to the secret-apikey. We also specify the mountPath directory that the secret will be stored in and set readOnly to true.

ImagePullSecrets:

When pulling from a private registry, you might need to authenticate before pulling your image. An ImagePullSecrets is a file that stores the authentification data and makes it available to all your nodes when they need to pull a specific image.

apiVersion: v1
kind: Pod
metadata:
  name: private-image
spec:
  containers:
    - name: privateapp
      image: gabrieltanner/graphqltesting
  imagePullSecrets:
    - name: authentification-secret

More information on private Docker registries can be found in this article.

Namespaces

Namespaces are virtual clusters that you can create to manage complex projects and divide cluster resources between multiple users. They provide a scope of names and can be nested within each other.

Managing and using namespaces with kubectl is straight forward. This section will demonstrate the most common actions and commands concerning namespaces.

View existing Namespaces:

To display all currently available namespace of your cluster, you can use the kubectl get namespaces command.

kubectl get namespaces

# Output
NAME                   STATUS   AGE
default                Active   32d
docker                 Active   32d
kube-public            Active   32d
kube-system            Active   32d

To get more information about a specific namespace, use the kubectl describe command.

kubectl describe namespace default

# Output
Name:         default
Labels:       <none>
Annotations:  <none>
Status:       Active

No resource quota.

No resource limits

Creating a Namespace:

Namespaces can be created by either using the kubectl CLI or by creating a Kubernetes object in YAML.

kubectl create namespace testnamespace

# Output
namespace/testnamespace created

Here is the same functionality using a YAML file.

apiVersion: v1
kind: Namespace
metadata:
  name: testnamespace

You can then apply the configuration file using the kubectl apply command.

kubectl apply -f testNamespace.yaml

Filtering by Namespace:

When creating a new object in Kubernetes without adding a custom namespace attribute, it will be added to the default namespace.

If you want to create your object in another workspace, you can do it like this.

kubectl create deployment --image=nginx nginx --namespace=testnamespace

You can now filter for your deployment using the get command.

kubectl get deployment --namespace=testnamespace

Change Namespace using context:

You just learned how you can create objects in a namespace that isn't the default one. But writing the namespace to every command you want to execute is time-consuming and can produce errors.

That is why you can change the default context that your commands will apply by using the set-context command.

kubectl config set-context $(kubectl config current-context) --namespace=testnamespace

You can verify the changes using the get-context command.

kubectl config get-contexts

# Output
CURRENT   NAME      CLUSTER   AUTHINFO   NAMESPACE
*         Default   Default   Default    testnamespace

Simplifying Kubernetes with Docker Compose

For those of you coming from the Docker community, it might be easier to write Docker Compose files instead of Kubernetes objects. That is where Kompose comes into play. It lets you convert or deploy your docker-compose file to Kubernetes using a simple CLI (command line interface).

Installing Kompose:

Kompose can be installed on all three mature operating systems in a very easy and simple manner.

Linux and Mac users just need to curl the binaries to install Kompose.

# Linux
curl -L https://github.com/kubernetes/kompose/releases/download/v1.21.0/kompose-linux-amd64 -o kompose

# macOS
curl -L https://github.com/kubernetes/kompose/releases/download/v1.21.0/kompose-darwin-amd64 -o kompose

chmod +x kompose
sudo mv ./kompose /usr/local/bin/kompose

On windows, you can download an executable and just run it.

Deploying using Kompose:

Kompose takes existing Docker Compose files and deploys them in Kubernetes. Let's look at an example using the following compose file.

version: "2"
services:
  redis-master:
    image: k8s.gcr.io/redis:e2e 
    ports:
      - "6379"
  redis-slave:
    image: gcr.io/google_samples/gb-redisslave:v1
    ports:
      - "6379"
    environment:
      - GET_HOSTS_FROM=dns
  frontend:
    image: gcr.io/google-samples/gb-frontend:v4
    ports:
      - "80:80"
    environment:
      - GET_HOSTS_FROM=dns
    labels:
      kompose.service.type: LoadBalancer

As with Docker Compose, Kompose also allows us to deploy our configuration using a simple command.

kompose up

Now you should see the created resources.

kubectl get deployment,svc,pods,pvc

Converting a Compose file to Kubernetes Objects:

Kompose also has the ability to convert your existing Docker Compose file into the related Kubernetes object.

kompose convert

You can then deploy your application using the apply command.

kubectl apply -f filenames

Demo application deployment

Now that you know the theory and all the vital concepts of Kubernetes, it is time to put that knowledge into practice. This chapter will show you how you can deploy a backend application on Kubernetes.

The specific application in this guide is a GraphQL boilerplate for the Nest.js backend framework.

Let's start by cloning the repository.

git clone https://github.com/TannerGabriel/nestjs-graphql-boilerplate.git

Pushing the images to a Registry:

Before we can start with creating the Kubernetes objects, we first need to push the images to a publicly available Image Registry. This can either be a public registry like DockerHub or your own private registry.

If you want to know more about how to set up your own private Docker Image, visit this article.

To push the image, just add the image tag with the registry you want to push it to in your Compose file.

version: '3'

services:
  nodejs:
    build:
      context: ./
      dockerfile: Dockerfile
    image: gabrieltanner.dev/nestgraphql
    restart: always
    environment:
      - DATABASE_HOST=mongo
      - PORT=3000
    ports:
      - '3000:3000'
    depends_on: [mongo]
  mongo:
    image: mongo
    ports:
      - '27017:27017'
    volumes:
      - mongo_data:/data/db

volumes:
  mongo_data: {}

I personally used a private registry I set up earlier, but you can just as well use DockerHub.

Creating the Kubernetes objects:

Now that you have pushed your image to a registry let's continue by writing our Kubernetes objects.

First, create a new directory to store the deployments.

mkdir deployments
cd deployments

touch mongo.yaml
touch nestjs.yaml

The MongoDB service and deployment will then look like this.

apiVersion: v1
kind: Service
metadata:
  name: mongo
spec:
  selector:
    app: mongo
  ports:
    - port: 27017
      targetPort: 27017
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mongo
spec:
  selector:
    matchLabels:
      app: mongo
  template:
    metadata:
      labels:
        app: mongo
    spec:
      containers:
        - name: mongo
          image: mongo
          ports:
            - containerPort: 27017

The file contains a deployment object with a single MongoDB container that is labeled mongo. It also contains a service that makes port 27017 available to the Kubernetes network (It cannot be accessed on the host machine but only from other containers in the same namespace).

The Nest.js Kubernetes object is a bit more complicated because the container needs some extra configuration like environment variables and imagePullSecrets.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nestgraphql
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nestgraphql
  template:
    metadata:
      labels:
        app: nestgraphql
    spec:
      containers:
        - name: app
          image: "gabrieltanner.dev/nestgraphql"
          ports:
            - containerPort: 3000
          env:
            - name: DATABASE_HOST
              value: mongo
          imagePullPolicy: Always
      imagePullSecrets:
            - name: regcred
---
apiVersion: v1
kind: Service
metadata:
  name: nestgraphql
spec:
  selector:
    app: nestgraphql
  ports:
    - port: 80
      targetPort: 3000
  type: LoadBalancer

The service also uses a load balancer to make the port accessible on the host machine.

Deploying the application:

Now that the Kubernetes object files are ready to go, let's deploy them using kubectl.

kubectl apply -f mongo.yaml
kubectl apply -f nestjs.yaml

You should now be able to access the GraphQL playground on localhost/graphql.

Congratulations, you have just deployed your first application on Kubernetes.

Sources

Here is a list of the sources I used for this article:

Conclusion

You made it all the way until the end! I hope that this article helped you understand Kubernetes and how you can use it to improve your development and deployment workflow as a developer.

If you have found this useful, please consider recommending and sharing it with other fellow developers. If you have any questions or feedback, let me know in the comments down below.

Originally published at gabrieltanner.org