“There are 10 types of people in this world, those who understand binary and those who don't.” ~ a wise sage

Understanding Binary

The computer and the human brain work differently, you and I know that. While humans think about numbers using the decimal system, the computers convert everything into binary to understand them. When talking about IPs, one of the first things that you have to understand is that each IP address is subdivided into four 8-bit parts known as octets.

Therefore when you see an IP such as

76.240.249.145

your computer will read it as

01001100.11110000.11111001.10010001

When it comes to the octet the minimum value you could have is 0 = 00000000 but as an IP cannot be 0.0.0.0 unless it’s a wildcard, somewhere within the four parts it would have to be 1 = 00000001.

The maximum value you could have in the octet would be 11111111 = 255. So, an IP with 255.0.1.255 = 11111111.00000000.00000001.11111111.

Converting Decimal to Binary & Vice Versa

When converting decimal to binary what you need to know is that binary increases in the number of digits for each increment to the power of 2, after 0 & 1 of course.

Eg:

1 = 1 + 4 = 5

• 0 = 0

• 2 = 2^1 = 10

• 4 = 2^2 = 100

• 8 = 2^3 = 1000

Therefore if you want to convert decimal 5 to binary you would pick the value with the exponent of 2 which is just below the number you would want to get the decimal of. In our case is 4 which is equal to 00000100.

From their you would want to take the remainder of 5 - 4 = 1, and the binary of 1 as an octet would be 00000001. Finally when you add the binary numbers for 4 & 1 together, you get

**00000100** + **00000001** = **00000101**

We then conclude that decimal number 5 in binary is 00000101.

Network & Host IDs

These 8-bit octets are further divided into 2 main parts, known as the Network-ID, and the Host-ID.

• The Network ID - Computers on the same network will share the same Network-ID which would be a certain set of number as the first part of your IP address.

  • Eg: 76.240.249.145, the highlighted numbers could be your network ID. We don’t know this for certain since we have not specified a subnet mask.

  • The greater the length of the network ID, the lesser the number of assignable host IDs.

• Host ID - The host ID would be the last part of your IP address. This is a unique identifier which is assigned to each computer that’s on your network.

💡 Note: The Network ID & the Host ID do not have to be divided equally — It’s not always the case that two parts make up the network ID and two address parts make up the host ID.

Subnet Mask

The splitting of an IP address into the Network section and the Host section is done via what is known as a subnet mask.

This is done by what is known as a Classless Inter-Domain Routing (CIDR) notation. The IPv4 address represented by a CIDR notation is known as a network mask and specifies the number of bits in the prefix to the address after a forward slash (/) separator. Eg:

192.168.10.64/24

When converted to binary the above IP address would look like:

11000000.10101000.00001010.01000000/24

Therefore the subnet mask specifies that the first 3 octets are going to be the network ID, and the last octet is going to be the host ID.

Now that we know the subnet mask, we can calculate what IPs are available to assign to our hosts.

Starting with

11000000.10101000.00001010.00000001 = 192.168.10.1

and ending with

11000000.10101000.00001010.11111110 = 192.168.10.254

Now you must be wondering why the last assigned host ID is 254 (11111110) and not 255 (11111111), which is the max range of the octet right? Or didn’t even think about it. 😅 Well this is because the last one is reserved as a broadcast ID. The last ID, the broadcast ID is assigned for communication purposes between your router and computer, which enables your network to even be a network! Eg: DHCP - Dynamic Host Configuration Protocol.

First purchase your domain. I would recommend NameCheap, they’re prices are quite reasonable when it comes to domains.

Head over to Forwardemail and enter the domain name you purchased, and the gmail address that you normally use.

After you get your domain with namecheap

Click on Account ⇒ Dashboard ⇒ Domain List ⇒ Manage ⇒ Advanced DNS

Then you create a TXT record

After that under Mail Settings, you will need to create 2 custom MX Records

After you’ve set this up on your namecheap DNS settings, go back to forward mail and verify that the MX records and TXT records are being detected.

After that’s done, you just need to configure your gmail settings.

💡 Important: Remember that you will need to have 2-factor-authentication setup on your gmail account to proceed with this setup.

If you have your 2FA setup on google, navigate to your app passwords by click on your profile picture circle ⇒ Manage your Google Account ⇒ Security ⇒ App Passwords

Select your App as “Mail” and your device as “Other (Custom name)”

When you are prompted to input text, type in the custom email address that you want for your domain “example@yourdomain.com”.

💡 Important: Copy the auto generated password that has been generated here. It will be needed in the up coming steps.

Now go back to your gmail account and click on the Setting “Cog” and click on “See all settings”.

Account and Imports ⇒ Send mail as: ⇒ Add another email address

Enter the Name that you want to be seen as and the email address of the custom domain that you used when preparing your App. Make sure you uncheck “treat as an alias”.

Click next and configure your email to be sent through your SMTP server.

Leave the radio button checked to “Secured connection using TLS” and click on “Add Account”.

Next check your gmail, for a verification email that has been emailed to your inbox. Copy the confirmation code and paste into the verification prompt, then click the “Verify” button. Once that’s done, go back to your verification email and click on the confirmation link that they sent and finally confirm the request.

That’s it. You’re done!

Now when you compose an email you can select your custom domain from the “From” drop down and send emails using your very own domain.

I wanted to talk about a issue I had to solve regarding auto-scaling Kubernetes with Hetzner Cloud. In this guide, I will walk through my thought process and the process of setting up and configuring auto-scaling for your Kubernetes cluster using Hetzner Cloud.

Explanation of Kubernetes and Hetzner Cloud

Kubernetes is a popular open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. It allows developers to run and manage their applications across multiple hosts and provides a consistent and reliable way to deploy applications at scale.

Hetzner Cloud, on the other hand, is a cloud hosting provider that offers virtual machines, storage, and networking infrastructure for running and scaling applications. Hetzner Cloud provides a simple and intuitive interface for managing your infrastructure and allows you to easily deploy and scale your applications.

Purpose of this documentation

The purpose of this documentation is to help you set up auto-scaling in your Kubernetes cluster using Hetzner Cloud. Auto-scaling is a critical feature for ensuring that your applications can handle fluctuating traffic loads and can scale up or down as needed.

By the end of this guide, you should have a working auto-scaling setup in your Kubernetes cluster and be able to monitor and troubleshoot any issues that may arise. Let's get started!

Overview of auto-scaling in Kubernetes

Before I dive into setting up auto-scaling in Kubernetes with Hetzner Cloud, let's take a closer look at how auto-scaling works in Kubernetes and the benefits of using it.

Benefits of auto-scaling

Auto-scaling offers several benefits for developers and operations teams. By automatically scaling your application based on demand, you can ensure that your application is always available and responsive to users. You can also save money on infrastructure costs by scaling down when demand is low, rather than running resources at full capacity all the time.

Auto-scaling also simplifies the process of managing and scaling your application, as it removes the need for manual intervention when traffic spikes or drops. This can save time and reduce the risk of errors in manual scaling.

Considerations for auto-scaling in Kubernetes

While auto-scaling offers many benefits, there are a few considerations to keep in mind when setting up auto-scaling in Kubernetes.

First, you'll need to ensure that your application is designed to scale horizontally, meaning that it can handle an increasing number of instances without negatively impacting performance. You'll also need to make sure that your application is stateless, as stateful applications can be more difficult to scale.

Second, you'll need to carefully choose the metrics that you use to trigger auto-scaling. If you choose a metric that doesn't accurately reflect the demand for your application, you may end up scaling up or down at the wrong times.

Finally, it's important to monitor your application and the auto-scaling process to ensure that everything is working as expected. This will allow you to quickly identify and resolve any issues that may arise.

Setting up auto-scaling in Kubernetes with Hetzner Cloud

Now that we have a solid understanding of auto-scaling in Kubernetes and the pre-requisites in place, let's walk through the steps for setting up auto-scaling with Hetzner Cloud.

Create a Horizontal Pod Autoscaler

Next, you'll create a Horizontal Pod Autoscaler (HPA) for your deployment. The HPA will automatically adjust the number of replicas in your deployment based on the CPU utilization of your pods.

To create an HPA, you'll need to specify the deployment you want to scale, the target CPU utilization, and the minimum and maximum number of replicas. You can find instructions on how to create an HPA in the Kubernetes documentation.

You can use Kubernetes Cluster Autoscaler to auto scale a Kubernetes cluster in Hetzner Cloud. The cluster autoscaler for Hetzner Cloud scales worker nodes within your cluster. It monitors pod scheduling and decides if there is enough capacity on your cluster to schedule the pods on a node. If there is not enough capacity to run the pods it will call the Hetzner Cloud API and launch new instances and add them to your cluster.

Install the Hetzner Cloud Controller Manager

The first step is to install the Hetzner Cloud Controller Manager, which allows Kubernetes to manage resources in Hetzner Cloud. You can install the Hetzner Cloud Controller Manager using the instructions in the Hetzner Cloud documentation.

Create a Kubernetes deployment

Once the Hetzner Cloud Controller Manager is installed, you can create a Kubernetes deployment for your application. This deployment should include a minimum and maximum number of replicas, which will be used by the Horizontal Pod Autoscaler to scale up and down as needed.

Test the auto-scaling setup

Once your deployment and HPA are set up, you can test the auto-scaling setup by generating load on your application. You can use a tool like ApacheBench/ Apache Jmeter to generate load on your application, and monitor the number of replicas in your deployment to ensure that the HPA is scaling up and down as expected.

Best practices for auto-scaling in Kubernetes with Hetzner Cloud

While setting up auto-scaling in Kubernetes with Hetzner Cloud is relatively straightforward, there are some best practices that can help you optimize your auto-scaling setup for performance, reliability, and cost.

Monitor your application and auto-scaling setup

It's important to monitor your application and the auto-scaling setup to ensure that everything is working as expected. This will allow you to quickly identify and resolve any issues that may arise.

You should monitor key metrics such as CPU utilization, memory usage, and network traffic, as well as the number of replicas in your deployment and the HPA behavior. You can use tools like Prometheus and Grafana to monitor your Kubernetes cluster and application metrics.

Optimize your application for auto-scaling

To ensure optimal performance and scalability, it's important to optimize your application for auto-scaling. This includes designing your application to be stateless and horizontally scalable, as well as using caching and load balancing to distribute traffic evenly across instances.

You should also consider optimizing your application for the specific infrastructure in Hetzner Cloud, such as using Hetzner Cloud Load Balancers to distribute traffic or using Hetzner Cloud Volumes for persistent storage.

Plan for cost optimization

Auto-scaling can help you save money on infrastructure costs by scaling down resources when they're not needed, but it's still important to plan for cost optimization. This includes setting up cost alerts to monitor your spending, as well as using spot instances and reserved instances to save money on compute resources.

You should also consider optimizing your application for cost, such as using smaller instance types or reducing the number of replicas when demand is low.

By following these best practices, you can ensure that your auto-scaling setup in Kubernetes with Hetzner Cloud is optimized for performance, reliability, and cost.

Conclusion

Auto-scaling in Kubernetes with Hetzner Cloud can provide significant benefits in terms of performance, reliability, and cost savings. By following best practices such as monitoring your application and auto-scaling setup, optimizing your application for auto-scaling, using multiple availability zones for high availability, and planning for cost optimization, you can ensure that your auto-scaling setup is optimized for your specific needs.

However, there are also challenges to consider, such as the complexity of the auto-scaling setup, difficulty in predicting resource needs, performance impact of auto-scaling, and cost management. By addressing these challenges and implementing best practices, you can mitigate the risks associated with auto-scaling and ensure that your application is running smoothly and cost-effectively.

In summary, auto-scaling in Kubernetes with Hetzner Cloud requires a combination of technical knowledge, monitoring and optimization, and cost management skills. By investing time and effort in learning and implementing these best practices, you can take full advantage of the benefits of auto-scaling and ensure that your application is running at its best.

The installation of a Github runner can be done at 3 levels:

• Enterprise

  • These runners can be assigned to all organizations and repositories.

• Organization

  • These runners can be assigned to all repositories under that organization.

• Repository

  • Runners that are assigned to a specific repository.

Once the runners have been assigned you can then use labels to choose which job you want running on a specific GH runner

All 3 runners are configured using similar steps, but this guide will focus on installing it at an Organization level.

First you will have to click on the drop down next to your profile picture and go into “Your organizations”

Next click on the “Settings” button next to your organization’s name.

Go to “Actions” & “Runners”

Then create a new self-hosted runner.

Next choose your operating system and run the commands that they have displayed within your server that you want to host the runner on.

The following steps are to help you configure a GH runner on a Linux x64 operating system.

Configure Linux User

These commands will be executed assuming you’re running as root.

Create a new user

//This will create a the user runner and set their home directory to their name.
//Replace "runner" with desired username.
adduser -m runner

Create user password

//Replace "runner" with desired username.
passwd runner

Switch to the non-root user

su runner

Install & Run GH Runner

Creates a folder and cd into it

mkdir actions-runner; cd actions-runner

Download the runner package

curl -o actions-runner-linux-x64-2.297.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.297.0/actions-runner-linux-x64-2.297.0.tar.gz

Optional: Validate the hash

echo "eb4e2fa6567d2222686be95ee23210e83fb6356dd0195149f96fd91398323d7f  actions-runner-linux-x64-2.297.0.tar.gz" | shasum -a 256 -c

Extract the installer from the .tar file you just downloaded.

tar xzf ./actions-runner-linux-x64-2.297.0.tar.gz

Create the runner and start the configuration

./config.sh --url https://github.com/<YOUR_ORGANIZATION> --token <GITHUB_PROVIDED_TOKEN>

Run it! (This is a manual process and you will have to run this manually each time)

./run.sh

Note that the directory you installed the GH runner will have a svc.sh file this file can be executed to have your GH runner always operating in case of a server restart as well, instead of always having to manually run the ./run.cmd command.

The svc.sh file can only be executed as root user.

su root

Change to your installation directory.

cd /home/runner/actions-runner

Install the service

./svc.sh install

Start your service

./svc.sh start

Now if you go back to your runners tab within your organization in your Github account, you will be able to note that your self-hosted runner is now in idle status. This means that you currently don’t have any actions running, and that your server is listening for any incoming actions.

What is Terraform?

Terraform is an open source and declarative tool for infrastructure provisioning. It let’s you manage your infrastructure and the platform and services that run on that infrastructure.

A good example of this would be, when you start your own project, say that you would need

• 3 servers

  • Private network space

  • Install Docker and other tools on each server

  • Security Setup | Firewalls

• 5 microservices as docker containers

Therefore, first you would need to provision your infrastructure by setting up a space to deploy you application. Terraform would be used to set up that space to deploy your microservices. These have to be created in a certain order since there might be task that is dependant on another.

How does it work?

For terraform to work, it needs to connect with your IaaS provider such as AWS, GCP, Azure, Hetzner, Linode etc. For terraform to do this, it has two main components that make up its architecture:

• The Core

  • The core uses two inputs to do its job. Using these it figures out the plan to get things done.

    • Terraform configuration, where you as a user would write and define what needs to be created or provisioned.

    • Terraform state, is where it keeps the up to date state of how the current setup of your infrastructure looks like.

• The Provider

  • Terraform uses providers such as IaaS or PaaS providers. Terraform has hundreds of providers which give terraform access to their resources.

It is helpful to note that when writing terraform code, it uses a declarative approach, as opposed to an imperative one. When using a declarative approach, you tell terraform what the end result you would want to see is. Eg: I want 3 servers with the specified network config.

Commands

Set TF_LOG variable to check for Terraform logs during TF build or destroy.

TF_LOG=TRACE

Initialize Terraform to start working.

terraform init

Get list of terraform workspaces

terraform workspace list

Check if the changes you’ve made are working before applying/ destroying terraform.

terraform plan

Query’s the provider to get an up to date state.

terraform refresh

Creates new TF workspace

terraform workspace new <ws_name>

Select a TF workspace to work on.

terraform workspace select <ws_name>

Deletes an existing TF workspace.

terraform workspace delete <ws_name>

Dashboard Setup

When creating alerts the important thing to note is that alerts can only be created for a Time Series panel type.

After an alert is configured to a panel the green heart that's displayed will show the state of the alert. Green=OK, Yellow=Pending & Red=Firing.

Query Definition

The query shown below gathers the node state in a kubernetes cluster. Rule Type is left as Grafana managed since we use Grafana to send out all our alerts.

Expression is where you define your alert condition. Here we say it to send out an alert if the last value from the query falls outside the range of 1, where 1 is the Ready state.

Evaluation Behavior

Select or create a new folder which makes sense for you, since the node ready status is related to the cluster nodes, it's going to be grouped with other node metrics.

The Evaluation Group is important since all alerts which are put into that group will be evaluated at the same time. This will ensure that all Ready Status Checks are evaluated every minute at the same minute. You can always change the evaluation interval if you so desire.

The pending period is how long you want to evaluate it for before the alert is triggered. It's good practice to have the pending period be more than you evaluation group interval. This is so that an alert will not be triggered if there was an error receiving the data.

Annotations & Labels

The annotations can be used to mention what the alert is about to the team members that you want to send it out to.

The labels are important as these are needed when you configure your alerting contact points and notification policies. Make sure you have labels that make sense. eg: severity=critical, contact_point=email, team=devops, or environment=staging. These labels can then be used to filter out your alerts when sending them through.

Setting Up Contact Points

Email

To set up email capabilities in grafana refer to [[Grafana Emails]]. Once, emailing has been configured you can send a test alert from the contact point to ensure that it's functioning as expected as shown below.

MS Teams

To configure a contact point for Microsoft Teams, you will first need to get a webhook from the teams channel that you want the alerts to go to. This can be done by going into Manage Channel and clicking on the Edit button under Connectors. Then search for Incoming Webhooks and follow the steps and copy the webhook URL.

Once you have copied the webhook, you can proceed with the grafana setup shown below.

Notification Policies

The last thing you have to configure in order to make sure your alerts are going to functioning as expected are the notification policies.

It's important to note that when creating nested policies, the first policy which matches the alert label will be triggered and the alert will not go further down the policy tree. If you want the alert labels to continue matching down the policy tree you will have to check the Continue matching subsequent sibling nodes toggle on. This will ensure that the alert labels continue to match the policies down the notification policy tree. This would be a required toggle if you wish to send your alerts to multiple contact points at the same time.

Things to keep in mind when configuring the policies:

Default Policy: This is the policy that's matched when an alert DOES NOT match any of the labels you have configured in your alerts.

Nested Policy: These are what you will be creating. Here you define what matching labels you want to send to a contact point of your choosing. The image below uses a regex expression to match severity level warning or critical labels from the firing alert and then send it over the MS Teams contact point which was configured earlier.

“It works on mine, so it works everywhere.” ~ Ranindu Abeyratne ~

What is Docker & why should I use it?

Docker is a set of the platform as a service (PaaS) products that use OS-level virtualization to deliver software in packages called containers.

Yea, but what does that mean?

Well, docker solves an age-old problem where you would hear one person say “the code doesn’t work!”, and the other would reply with “...well it works on my computer”.

What docker does is that it would use a set of instructions defined in what’s known as a Dockerfile, to run your application on a specified operating system (OS). Unlike a regular VM, Docker only virtualizes the OS and uses the available hardware, which makes everything run faster! This can then be used in any local machine of your choice. There are 3 fundamental elements that enable Docker:

• Dockerfile
• Image
• Container

What are Docker Images & Containers?

The first thing you will do after you have written a Dockerfile for your application is build the image using a docker build command. Once the image is built, you could use that image to create your container. Running the image multiple times will create multiple clones of a container.

A container is what holds your application. Think of this as a virtual computer. A container will run its own OS and run your application inside it. Therefore anyone using an image you built or a container that you created would have your application without facing any sort of OS-level restrictions or issues.

Docker Container Running On Different OS’s

Getting Started

By now you should have a rough idea of how Docker works. Now here’s how to put it into practice. First thing’s first, you will need a simple application to work with. I will go ahead and create a sample React application to “containerize” it.

Open up your terminal, and cd (change directory) into a directory/folder where you would want to create your application. Then to get started you would want to run:

npx create-react-app my_react_app

Congratulations, you now have a basic react app to work with.

Next, open the application you installed with your favorite text editor and create a “Dockerfile”.

Your directory structure should now look something like this.

The Dockerfile

Now that you have your Dockerfile created, we can look into what it does. The Dockerfile gives a specific set of instructions for what goes into your container. You can specify things such as OS version, and how to build and run your application. Here’s a simple Dockefile.

FROM node:16

# Default directory for your app
WORKDIR /usr/src/app

# Install app dependencies
# A wildcard is used to ensure both package.json AND package-lock.json are copied
# where available (npm@5+)
COPY package*.json ./

RUN npm install
# If you are building your code for production
# RUN npm ci --only=production

# Bundle app source
COPY . .

EXPOSE 8080
CMD [ "npm", "run", "start" ]

The commands you want Docker to execute during build time are written in all caps for readability purposes.

FROM - This defines what type of OS you want the container to have. A list of all the official images can be found here. In this example, we want to have an image with Node.Js already in it as we’re working with a react application.

WORKDIR - This is your default directory, you can specify a path you want here and it will create the needed directories. From this point onwards docker will treat this as its home location. Therefore, unless explicitly defined, anything you copy or add will go into this location.

COPY - This command takes 2 arguments. The first one is what to copy from your LOCAL device, and the second argument is where to paste it inside your container. So when you define

COPY package*.json ./
COPY . .

this means that you want the build to copy both your package.json and your package-lock.json into your home location which is defined using WORKDIR. The wildcard (* icon) means that you want both package.json and package-lock.json to be copied. The second COPY . . means copy all of the content from your local device (the directory where your Dockerfile is located) into your container WORKDIR location.

RUN - This is used when you want to execute a terminal command inside the container. Since you already copied your package files, you can now ask docker to run npm install, and it will install all your dependencies that are found inside your package.json file. You can run a command like mkdir if you wanted to create a new directory for some reason.

EXPOSE - This tells Docker to get all of the required information during the runtime from a specified Port and exposes that port. Therefore communication cannot occur through any other port since those will all be closed.

CMD - Finally the CMD command is to let Docker know to start the application and end the build from there. You might be asking why not use RUN? When you use RUN and your application starts and says that it’s listening on PORT 8080, Docker will wait until it finishes listening to stop the build. This means it will never stop unless you manage to Ctrl+C the build, and that would result in a failed build.

The Build

Once the Dockerfile is in place. You can run the build command

docker build -t my-first-image:1.0.0 .

“docker build” defines what you want docker to do, which in this case would be to build your image. The “-t” means to tag the image so you can give it a name and a version number if you want. Finally, the “.” at the end of the command is to tell docker where your Dockerfile is located.

Once your image is done building you can now check out your latest creation using

docker images

which should show you something like this

Your first reaction should be “WTF?! Why is a simple react app 1.37Gb?”

Well, that’s because the initial image you defined in your Dockerfile is “FROM node:16”. This comes with a lot of unwanted packages and libraries, which can also lead to security issues. There are a few ways you can fix this. One, by using a lightweight distro like alpine, or you could use a multi-stage docker build. However, I will leave that topic for a different article.

After you’ve built the image you can now run it using

docker run -d 8f0

you ask docker to run it in “-d” detached mode. This is to avoid docker from showing you the logs and not being able to escape it without hitting Ctrl + C. You can copy paste the IMAGE ID, or you can just use the first 3 characters of the ID as long as it’s unique and not shared by another image ID.

Now that your container’s running, you will be able to hit localhost on your browser and look at what you’ve achieved so far. If you’ve exposed a different port other than 8080. You can try with localhost:.

Congratulations! You’ve taken your first step into the world of DevOps.

Cheatsheet

I thought it would be nice to leave you guys with a cheat sheet that I made to refer to when I had to work with containers a bit. Some of these commands appear in common use cases.

Download Cheat Sheet