DEV Community: Itamar Knafo

Bootstrap your Blog

Itamar Knafo — Sat, 03 Jun 2023 13:20:25 +0000

Here we will go through how to bootstrap your own blog using Hugo and fly.io.

Prerequisites

Here is a list of toolings you will need to have installed on your machine:

Hugo
fly.io
git
- GitHub account

Optional:

Golang (optional, but I will be using it in this guide)
Docker (optional, only needed to run the blog locally using Docker)

Create a new Hugo site

First, we need to create a new Hugo site. To do so, we will use the hugo mod init command:

hugo mod init github.com/<username>/<repo-name>

This will populate your project directory with the following structure:

your-project
├── public/
├── resources/
└── go.mod

Add a theme

Next, we need to add a theme to our blog. For this guide, I will be using the blowfish theme.

Now we want to add the theme to our blog, so we will reference it in our config/_default/module.toml file:

# config/_default/module.toml
[[imports]]
path = "github.com/nunocoracao/blowfish/v2"

Start your server using hugo server and the theme will be downloaded automatically.
In the root folder of your website, delete the config.toml file that was generated by Hugo. Copy the *.toml config files from the theme into your config/_default/ folder, download a copy from here.

Note: Do not overwrite the module.toml file you created above!

Now so far if we run hugo server we will see the following when we access http://localhost:1313:

From here you can start working on your blog following the blowfish theme documentation.

Recomnadation: I recommend you use vendoring to manage your theme dependencies.

To do so, you can use the hugo mod vendor command:

hugo mod vendor

Add a Dockerfile

Now that we have our blog ready, we need to add a Dockerfile to our project so we can deploy it to fly.io.

Create a new file called Dockerfile in the root of your project and add the following content:

FROM golang:1.19.0-buster AS build

RUN apt update -y 
RUN apt install -y wget
# Install Hugo
RUN wget https://github.com/gohugoio/hugo/releases/download/v0.106.0/hugo_extended_0.106.0_linux-amd64.deb
RUN dpkg -i hugo_extended_0.106.0_linux-amd64.deb
RUN apt-get install -f

WORKDIR /var/hugo/src
COPY . .
RUN hugo --minify

EXPOSE 1313
CMD ["hugo", "server", "--bind", "0.0.0.0"]

You can try running docker build . to build your image locally and see your docker hosted blog.

Important Configurations

Before we jump and deploy our blog to fly, we need to configure the baseURL of our blog.

Add a baseURL to our config/_default/config.toml file:

# config/_default/config.toml
baseURL = "https://<your-app-name>.fly.dev"

Hosting on fly.io

Now we can create a new app on fly.io.

To do so, we will use the fly launch command:

fly launch

The command will prompt you with a few questions about your app like so:

? App Name (leave blank to use an auto-generated name):
? Select organization: You (personal)
? Select region: lax (Los Angeles, California (US))
Created app *** in organization personal
Wrote config file fly.toml
? Would you like to deploy now? (y/N)

The launch command generates a fly.toml file for your project with the settings. You can deploy right away, or add some config first.

Now your fly.toml file should look something like this:

app = "<app-name>"
primary_region = "<region-name>"

[http_service]
  internal_port = 1313
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0

Automatic Deployment with GitHub Actions

Now that we have our blog ready, we need to automate the deployment process. To do so, we will use GitHub Actions.

First, we need to create a new file called .github/workflows/deploy.yml with the following content:

# .github/workflows/deploy.yml
name: Fly Deploy
on:
  push:
    branches:
      - main
jobs:
  deploy:
    name: Deploy app
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v3
      - uses: superfly/flyctl-actions/setup-flyctl@master
      - run: flyctl deploy --remote-only
        env:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/j0q7n4nbdlug9c0tjozb.png)


          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}

Make sure you add a FLY_API_TOKEN to your repos secrets. You can get it from https://fly.io/user/personal_access_tokens.

(Optional) Adding a custom domain

If you want to add a custom domain to your blog, first you need a domain. My personal choice was Namecheap, but there are many other options out there like GoDaddy, Hostinger, AWS Route 53, etc.

Once you have your domain, we'll need to run the following command to add it to our fly.io app:

fly certs create <your-domain>

You'll get prompted by fly needing to verify and configure your domain. Just follow the instructions and add an A Record and AAAA Record to your DNS provider as well as adding the CNAME record for www as well.

Type	Name	Value	TTL
A Record	@	<value provided by fly>	Automatic
AAAA Record	@	<value provided by fly>	Automatic
CNAME Record	www	<your-app-name>.fly.dev.	5 min

Once it's ready, you can run fly certs show <your-domain> to see if everything is working as expected and add any other configuration if needed.

Don't forget to re-configure your baseURL in your config/_default/config.toml file:

# config/_default/config.toml
baseURL = "https://<your-domain>"

Summary

Now you have a blog of your own, just like this one. You can now start writing your own posts and deploy them to fly.io.

If you have any questions, feel free to reach out to me on any social.

Originally published at https://itamadev.com on June 3, 2023.

Pod & Node Eviction

Itamar Knafo — Wed, 12 Apr 2023 11:39:01 +0000

In the world of container orchestration, Kubernetes is the de facto standard. It is an open-source platform for automating the deployment, scaling, and management of containerized applications. Kubernetes abstracts the underlying infrastructure and provides a unified API for managing containerized workloads. However, as with any complex system, Kubernetes is not immune to failures. In this article, we will discuss one such failure scenario - Pod and Node eviction in Kubernetes.

What is Pod and Node Eviction?

Pod and Node eviction are two related concepts in Kubernetes. A Pod is the smallest deployable unit in Kubernetes. It consists of one or more containers that share the same network namespace and storage. A Node is a physical or virtual machine that runs the Kubernetes software and can host one or more Pods.

Pod eviction happens when a Pod is terminated by the Kubernetes system due to some reason, such as a Node failure or resource constraints. Node eviction, on the other hand, happens when a Node is marked un-schedulable and the Pods running on it are evicted to other Nodes.

Why does Pod and Node Eviction happen?

Pod and Node eviction can happen due to a variety of reasons, such as:

Node failures - A Node can fail due to hardware or software issues, such as network failure, power outage, or kernel panic.
Resource constraints - A Node may run out of resources, such as CPU, memory, or disk space, which can cause Pods to be evicted.
Node maintenance - A Node may be taken down for maintenance, such as kernel upgrades, security patches, or hardware replacement.
Pod failures - A Pod may fail due to application errors or resource constraints, which can trigger Pod eviction and rescheduling on other Nodes.

Some Examples of Pod and Node Evictions

Node failure - Suppose you have a Kubernetes cluster with three Nodes. One of the Nodes experiences a hardware failure, causing it to become un-schedulable. The Kubernetes scheduler identifies the Pods running on the failed Node and reschedules them on the remaining Nodes, marking the failed Node for eviction.
Resource constraints - If a Pod starts consuming too much CPU or memory, it can cause the Node to run out of resources. Kubernetes may then decide to evict the Pod to free up resources for other Pods running on the Node.
Node maintenance - When you need to perform maintenance on a Node, you can mark it as un-schedulable using the Kubernetes API. Kubernetes then identifies the Pods running on the Node and reschedules them on other Nodes, allowing you to take the Node offline for maintenance.
Pod failures - If a Pod fails due to a crash or error, Kubernetes may decide to evict it and reschedule it on another Node. This helps ensure that the Pod remains available and responsive even in the face of failures.

In all of these scenarios, Kubernetes controllers monitor the state of Nodes and Pods and take appropriate actions to ensure the availability and reliability of your applications

How do Pod and Node Eviction work?

Pod and Node eviction are handled by Kubernetes controllers, which monitor the state of Nodes and Pods and take actions based on the configured policies. When a Node fails or becomes un-schedulable, the Kubernetes scheduler identifies the Pods running on the Node and selects new Nodes to run them. The Pods are then rescheduled on the new Nodes, and the old Nodes are marked for eviction.

The eviction process involves sending a SIGTERM signal to the containers running in the Pod, giving them a grace period to shut down gracefully. If the containers do not stop within the grace period, they are forcibly terminated with a SIGKILL signal. Once all the containers are terminated, the Pod is deleted from the Node.

In the case of Node eviction, the Kubernetes system follows a similar process. It first identifies the Pods running on the Node and selects new Nodes to run them. The Pods are then rescheduled on the new Nodes, and the old Node is marked un-schedulable. The Pods running on the old Node are then evicted using the same process as Pod eviction.

How can we handle Pod and Node Eviction?

Pod and Node eviction is inevitable in a Kubernetes cluster, and it is essential to have a strategy in place to handle them. Here are some best practices to handle Pod and Node eviction:

Use resource limits - Set resource limits on Pods to prevent them from consuming all the resources on a Node, which can cause other Pods to be evicted.
Use PodDisruptionBudgets - Use PodDisruptionBudgets to ensure that a minimum number of Pods are available during Pod eviction, which can prevent service disruption.
Use NodeAffinity and anti-affinity - Use NodeAffinity and anti-affinity rules to ensure that Pods are scheduled on Nodes that meet certain criteria, such as having enough resources or being in a specific zone.
Use node maintenance modes - Use node maintenance modes to gracefully drain a Node before evicting the Pods, which can prevent service disruption.

Summary

Pod and Node eviction is an integral part of Kubernetes, and it is essential to understand how they work and how to handle them. By following the best practices mentioned above, you can ensure that your applications remain available and responsive even in the face of Pod and Node eviction.

In conclusion, Pod and Node eviction is a necessary "evil" in a Kubernetes cluster. While they may seem daunting, understanding how they work and taking the necessary precautions can help minimize their impact on your applications. As Kubernetes continues to evolve, we can expect more tools and techniques to emerge to help us manage Pod and Node eviction more effectively.

Originally published at https://itamadev.com on April 12, 2023.

Adopting Technologies

Itamar Knafo — Sat, 17 Dec 2022 15:36:30 +0000

When thinking about and testing new and exciting technologies, teams can often get overwhelmed with the thoughts of what to test. or what should be important to us even before testing or considering a tool, framework, or platform we might want to add to our tech stack.

Here is a curated list of some of the key features I look into when learning and considering using tech in my personal projects or at work with the teams I work with.

Activity & Community

One of the first and more noticeable things to look for when checking out new tech is the community and activity of the project, an active community can serve you well at the start and further down the road.

It could be helpful even when reading into the tool you’re using with more articles or documentation being written or when getting stuck and in need of help, someone might just be stuck with you, and even better - someone might have already got a solution to your problem!

Some things to look for are:

Stars on GitHub ⭐
Is the project “mature”? (how long has it been in use/development)
Active Users
Issues & PRs
A slack/discord/platform of the community

Project Size

When looking to get a job done you might want some ready-made software to already do your job for you, and that’s great! so you can start and get your hands dirty with the real challenge.

That is indeed a very good way to not repeat others’ work, but when doing so it’s important to remember you’re also introducing yourself to someone else’s code, someone you might not be familiar with and someone you might not be able to rely on for long.

That puts us in a position where the size of the project really matters.

If we’re looking at a complex project fixing a slight problem, we might be better off just implementing it ourselves, but if we are looking at a more challenging chore, considering using a project even if it’s a bit large, it can prove to be very practical and save us a lot of time in the end.

Maintenance

As we just mentioned while talking about the project size and activity, maintenance is very important, we want to be sure we can rely on the projects we use.

OpenSource projects don’t have a strict responsibility when it comes to maintenance, and when we don’t have active maintenance this metric becomes far more concerning, someday we might hear that our favorite CI/CD platform isn’t going to be maintained anymore, or even our central go framework which we based our whole application on will stop being maintained.

Some tools have active support, and they might even have the founder/owner of the project actively responding to PRs, and Issues.

While a strong community can really boost your whole workflow and process, support from the maker of the tool might be needed in some obscure use cases, it’s essential to rely on software that is actively being maintained, and so even without intimate support from the owner, the maintenance might be just enough, and we need to keep in mind that in the future the project might have a different owner and even from the active community.

Something important to keep in mind is that after we choose our technology we still need to actively watch out for updates and maintenance changes.

Programming Language

The last but certainly not least bullet point is the programming language being used and supported by the project.

Sometimes we might just be using a project as an outside service and sometimes as a fully integrated library or SDK.

We need to check that the main languages that we use are being supported and it’s even better if the project itself is written in one of them, then when experiencing problems or looking at Issues some of our team might be able to help fix them and submit a PR.

This metric isn’t as groundbreaking but can definitely serve you well, as I can say from my experience it has.

Summary

We want to be aware when using someone else’s code and looking at new tech, we want to know we aren’t just inviting problems into our workflow and tech stack and we want to follow some rules in doing so. I hope now you can be a little bit more sure about when integrating new technologies into your tech stack.

Originally published at https://itamadev.com on November 26, 2022.