Kubernetes from the Ground Up: Server Components

In the previous post, Choosing a configuration method, we looked at the three ways in which a Kubernetes cluster can be configured. In this post we’ll go through the components which make up the cluster.

Kubernetes clusters have two types of servers: masters and nodes. The masters provide the control plane for the cluster while the nodes take care of the workloads. As you probably guessed, having one or more of either provides high availability.

The components documentation gives us a great rundown on the components that make up each of these two nodes, though it might be a little confusing for those who are just starting out. In this post we’ll look through each component’s documentation while adding additional information as required. Furthermore, to help really get the point across, we’ll build a diagram to show where each component resides.

Continue reading

CI/CD: Setting up GitLab Runners on AWS using CoreOS & Terraform

GitLab Runner is used as part of GitLab CI/CD pipelines. On a side note, it also supports GitHub and BitBucket too! But I digress… 

In this post we’ll cover how to install, configure and register Runner.

So many choices!

Runner can be installed on various operating systems/tools (Linux, Windows, Mac, Kubernetes, Docker), to name a few. If you’re interested, a full list can be found in the documentation. For the purpose of this post, we’ll use the Dockerised version on a CoreOS instance which is running in AWS. (Boy, that was a mouthful!)

URL & Token

Before we can spin up our Runner, we’ll first need to retrieve our GitLab URL and registration token. We can obtain both of these by:

  1. Selecting a repository
  2. Clicking “Settings” –> “CI/CD”
  3. Navigating to the “Specific Runners” section

Continue reading

Kubernetes from the Ground Up: Choosing a configuration method

In the previous post, What is it?, we gained an understanding of Kubernetes and container orchestrations in general. In this post we’ll cover the three ways in which Kubernetes can be configured.

Kubernetes’ configuration is simply a bunch of Kubernetes objects. Let’s take a quick look at what these objects are, and what they’re used for. The following quotes are from the Kubernetes object documentation:

Kubernetes Objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:

  • What containerized applications are running (and on which nodes)
  • The resources available to those applications
  • The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance

Continue reading

Kubernetes from the Ground Up: What is it?

If you’ve looked into containers before, you’ve likely heard the name Kubernetes. This post will tackle what it is at a high level, while subsequent posts will delve deeper into the details.

Let’s kick off this post with a couple of quotes from the Kubernetes website:

Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications.

It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon 15 years of experience of running production workloads at Google, combined with best-of-breed ideas and practices from the community.

There’s a lot of great information in this quote, so let’s go ahead and take a closer look.

Continue reading

Getting Started with Prometheus – Part 2

As you’ve probably guessed by Docker posts, I’m a huge fan of containerisation. Therefore instead of installing Prometheus on a host, let’s instead spin it up in a container. As described on the Prometheus website, we can accomplish this by issuing only a single command:

Let’s break down each component of this command to make sure we fully understand what it is doing:

  • docker run: Spin up a container
  • -p 9090:9090: Bind a port on our Docker host to a container port. This enables devices outside of the Docker host to reach the container on port 9090
  • -v /tmp/prometheus.yml:/etc/prometheus/prometheus.yml: Binds the /tmp/prometheus.yml file stored on the Docker host to  /etc/prometheus/prometheus.yml inside of the container
  • prom/prometheus: The <user_account>/<container_name> that we want to use

Continue reading

Getting Started with Docker – Part 2

In the previous post we may have started running before we could walk. In this post we’ll first take a few steps back to make sure we cover the basics before diving deeper.

Building an image

When we examined the python:3.6.3-alpine3.6 image’s dockerfile, we saw the components which are used to create a Docker image:

  • FROM alpine3.6
  • ENV commands
  • RUN commands
  • A single CMD command

OK, so we already know that the  FROM alpine3.6 command means that the Python image is going to use the  Apline 3.6 as its Linux operating system. ENV, as its name suggests, is used to specify environment variables for the image. That leaves us with RUN and CMD.

Continue reading

Getting Started with Docker – Part 1

For those new to Docker, you’re probably wondering – What is it exactly?

“Docker is the company driving the container movement and the only container platform provider to address every application across the hybrid cloud.”

OK, it’s the name of a company. The next question is, what are containers? Rather than give you another quote, I’ll give you my own definition…

What are containers?

Containers are like portable executables. You know, the applications that come as a standalone  exe file and don’t require installation? I draw this comparison for the following reasons:

Continue reading