2025-05 on Funky Si's Test

Deploy this blog with Helm charts

funkysi1701@gmail.com (funkysi1701) — Mon, 26 May 2025 20:00:00 +0000

Helm allows you to package your Kubernetes resources, manage configuration, and deploy updates with a single command.

In this post, I’ll share how I used Helm to deploy my Hugo blog, making it easy to manage updates and spin up new environments. Full disclosure: My blog currently runs on an Azure Static Web App, but now that I know how to deploy to a Kubernetes cluster, I have the option to switch if needed.

Why Use Helm?

Helm is the package manager for Kubernetes. It lets you:

Template your Kubernetes YAML files for reuse and configuration.
Version your deployments for easy rollbacks.
Share your charts with others or use community charts.

Creating a Helm Chart for Hugo

First, I scaffolded a new Helm chart:

helm create hugo-blog

This creates a directory structure with templates for deployments, services, and ingress.

Customizing the Chart

I edited values.yaml to set my image and service details:

image:
 repository: mydockerhubusername/hugo-blog # Docker image repository
 tag: latest # Use the latest tag for the image
 pullPolicy: IfNotPresent # Pull the image only if it’s not already present

service:
 type: NodePort # Expose the service on a specific port
 port: 80 # Internal port for the service
 nodePort: 30081 # External port for accessing the service

Deploying the Blog

To deploy the blog, I ran:

helm install my-hugo-blog ./hugo-blog

Helm rendered the templates and created the necessary Kubernetes resources.

Updating the Blog

When I rebuild and push a new Docker image, I can upgrade my deployment with:

helm upgrade my-hugo-blog ./hugo-blog

This triggers a rolling update in Kubernetes.

Creating a Docker Image of my Blog

This all assumes that I have a container image of my Hugo blog. Creating this was half the work.

I had been using a docker-compose file to build my blog; however, this doesn’t copy my files into the container it creates a volume to share my files with the container. I needed a Dockerfile that would copy my source code into a container and then save it into a container registry.

This is the Dockerfile I created. As you can see, it is a two-stage build. First, it takes the Hugo base image, copies my files into it, and builds Hugo. Then the NGINX web server is run, and the default web port 80 is exposed.

# Step 1: Build the Hugo site
FROM floryn90/hugo:0.119.0 AS builder

# Set working directory inside the container
WORKDIR /src

# Copy site files to the container
COPY . .

# Build the Hugo site
RUN hugo --minify --config config.toml

# Step 2: Serve with nginx
FROM nginx:alpine

# Remove the default nginx static files
RUN rm -rf /usr/share/nginx/html/*

# Copy the generated site from the builder stage
COPY --from=builder /src/public /usr/share/nginx/html

# Expose port 80
EXPOSE 80

# Start nginx
CMD ["nginx", "-g", "daemon off;"]

Benefits

Repeatable Deployments: Easily spin up new environments.
Configuration Management: Override values for different clusters or environments.
Easy Updates: Upgrade with a single command.

Conclusion

Helm charts have made deploying my Hugo blog to Kubernetes a seamless and efficient process. With features like templating, versioning, and easy updates, Helm is a must-have tool for Kubernetes deployments.

If you’re managing static sites or microservices, give Helm a try and see how it can simplify your workflow!

Have you used Helm for static sites or blogs? Share your experience in the comments below!

Learning Kubernetes: A Beginner's Journey

funkysi1701@gmail.com (funkysi1701) — Mon, 12 May 2025 20:00:00 +0000

I know nothing (or very little) about Kubernetes. It is high time I do something to learn more about it. Kubernetes is a powerful tool for managing containerized applications, and it’s becoming a must-have skill for developers and DevOps engineers. In this blog, I’ll share my journey as a beginner exploring Kubernetes, from running a simple Grafana pod to understanding the basics of kubectl. Let’s dive in!

What is Kubernetes?

Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. If you want to run your containerized applications, you probably want to learn Kubernetes.

I have worked at least two companies so far in my career that have made use of Kubernetes to run their microservice architecture. Let’s take a look at how to use it.

Why Learn Kubernetes?

Kubernetes is widely used in modern software development for:

Microservices: Manage and scale multiple services independently.
CI/CD Pipelines: Automate deployments and rollbacks.
Scalability: Handle traffic spikes by scaling pods up or down.

Docker Desktop

Docker Desktop is a tool for running containers, but it also allows running of Kubernetes.

I am not going to talk through installing docker desktop and getting a Kubernetes cluster set up, for that check out the documentation however I found it very straightforward.

kubectl

kubectl is the command line tool for doing everything with Kubernetes.

kubectl version

This prints out basic version information, if this works you know Kubernetes must be working.

kubectl config get-contexts
kubectl config use-context docker-desktop

This command allows you to switch contexts, to use with docker desktop you want to use the docker-desktop context. At work we have dev and test contexts that can be selected in a similar way.

Context: A Kubernetes context is a set of access parameters for a cluster. It allows you to switch between different clusters or environments (e.g., dev, test, production).

kubectl get all

This gives you a list of everything that is running in the default namespace, pods, services, deployments etc For a complete list, you can add the –all-namespaces flag.

Namespace: A namespace is a way to organize resources in a Kubernetes cluster, providing isolation between different projects or teams.

Hello World

Now what is the equivalent of “Hello World” for Kubernetes? I think getting a container to run in Kubernetes is a pretty good test.

Open up VS Code and create a yaml file called grafana.yaml

apiVersion: v1 # Specifies the API version for the resource
kind: Pod # Defines the resource type as a Pod
metadata:
 name: grafana # The name of the pod
spec:
 containers:
 - name: grafana # The name of the container
 image: grafana/grafana:12.0.0 # The container image to use
 ports:
 - containerPort: 3000 # The port exposed by the container

This file uses the Grafana container image, which I am familiar with (see my previous blog posts ) It’s default port is 3000 which you can see is defined in this file.

kubectl apply -f grafana.yaml

This deploys a pod, using the above yaml file.

You can run the following to find out more about the pod.

kubectl describe pod grafana

From what I have discovered so far, Kubernetes runs in its own network. So going to localhost:3000 won’t work. But you can use port forward to get round this issue.

Port-Forwarding: This allows you to access a pod’s service on your local machine by forwarding a port from the pod to your localhost.

kubectl port-forward pod/grafana 3000:3000

Now if I try http://localhost:3000/login I see the login page for the Grafana container. A pretty good first test of using Kubernetes.

Whats next?

I want to replace my local deployment of containers that is currently using a docker compose file with Kubernetes. I also want to learn more about Helm charts as I believe these are an excellent way of packaging up changes to Kubernetes.

Have you tried running a pod in Kubernetes? What challenges did you face, and how did you overcome them? Share your thoughts in the comments below!

Getting started with OpenTelemetry

funkysi1701@gmail.com (funkysi1701) — Mon, 05 May 2025 20:00:00 +0000

What is OpenTelemetry?

OpenTelemetry is an open-source observability framework that provides a unified way to collect, process, and export telemetry data such as traces, metrics, and logs. It is designed to help developers monitor and debug distributed systems by providing insights into application performance and behavior.

With OpenTelemetry, you can instrument your applications to gain visibility into how requests flow through your system, identify bottlenecks, and troubleshoot issues effectively.

Why Use OpenTelemetry?

Here are some key benefits of using OpenTelemetry:

Unified Observability: Collect traces, metrics, and logs using a single framework.
Vendor-Neutral: Export telemetry data to any backend, such as Azure Monitor, Grafana, or Prometheus.
Standardized APIs: Use consistent APIs and SDKs across multiple programming languages.
Extensibility: Easily extend OpenTelemetry to meet your specific observability needs.
Community-Driven: Backed by a large and active open-source community.

Key Components of OpenTelemetry

OpenTelemetry consists of the following core components:

Traces: Capture the lifecycle of a request as it flows through your system. Traces help you understand dependencies and latency.
Metrics: Collect numerical data, such as request counts, CPU usage, and memory consumption, to monitor system health.
Logs: Record discrete events, such as errors or state changes, to provide additional context for debugging.

Setting Up OpenTelemetry in .NET

Here’s how you can get started with OpenTelemetry in a .NET application:

Step 1: Install the Required NuGet Packages

Run the following commands to install the OpenTelemetry libraries:

dotnet add package OpenTelemetry
dotnet add package OpenTelemetry.Extensions.Hosting
dotnet add package OpenTelemetry.Exporter.Console

Step 2: Configure OpenTelemetry in Your Application

Add the following code to your Program.cs or Startup.cs file:

using OpenTelemetry;
using OpenTelemetry.Trace;
using OpenTelemetry.Metrics;

var builder = WebApplication.CreateBuilder(args);

// Add OpenTelemetry tracing and metrics
builder.Services.AddOpenTelemetry()
 .WithTracing(tracerProviderBuilder =>
 {
 tracerProviderBuilder
 .AddAspNetCoreInstrumentation()
 .AddHttpClientInstrumentation()
 .AddConsoleExporter(); // Export traces to the console
 })
 .WithMetrics(metricsProviderBuilder =>
 {
 metricsProviderBuilder
 .AddAspNetCoreInstrumentation()
 .AddRuntimeInstrumentation()
 .AddConsoleExporter(); // Export metrics to the console
 });

var app = builder.Build();

app.MapGet("/", () => "Hello, OpenTelemetry!");

app.Run();

Step 3: Run Your Application

Start your application and observe the telemetry data in the console. You’ll see traces and metrics being logged as requests are processed.

Aspire and how to view Telemetry

If your .NET code is .Net 8 or higher you can use Aspire which configures OpenTelemetry for free! Check out Getting started with .Net Aspire . Once Aspire is setup, you will be able to see Logs, Traces and Metrics in the Aspire Dashboard.

Another popular way to view your data is Grafana, where you can create custom dashboards. I have talked about adding Logs to Grafana recently.

There are lots of other ways to view your data, like Application Insights, DataDog, Jaeger, New Relic and many more.

But you are not tied to one solution, you can send your data to more than one of these if you wish.

Conclusion

OpenTelemetry simplifies observability by providing a unified framework for collecting traces, metrics, and logs. Whether you’re building microservices, monitoring distributed systems, or debugging performance issues, OpenTelemetry is a powerful tool to have in your arsenal.

Start using OpenTelemetry today and gain deeper insights into your applications!

Have you tried OpenTelemetry? Share your experiences and tips in the comments below!