DEV Community: Sergio Méndez

Hello world example with gRPC and Go

Sergio Méndez — Tue, 07 Jul 2026 17:13:19 +0000

Hi, readers this time I want to show you how to implement the classic Hello World example with gRPC, but with a small change: instead of sending a Name as a parameter, we are going to modify the protocol buffer definition and the generated code so the client sends a Nickname and the server replies back with it. We are going to use the same style of environment I used in my previous post about Container Runtimes, this time running everything inside a Killercoda Ubuntu playground and a golang container.

This blog post will focus on:

Setting up a gRPC + Protoc development environment in Go.
Modifying the official grpc-go Hello World example to use a Nickname field.
Running the gRPC server and invoking it from a client process.

What you will learn

Prepare the environment for gRPC and Protoc
Implement a gRPC service
- Cloning and modifying the grpc-go Hello World example
- Regenerating protobuf/gRPC Go code
- Running the gRPC server
Invoke a gRPC service from a client

Environment

For this exercise we are going to use the Ubuntu playground on Killercoda, which gives us a disposable Ubuntu machine with Docker already available. As a reference, I'm following the official gRPC Go quickstart guide and adapting it to this custom scenario.

Statement

Implement the gRPC Hello World example so it accepts a Nickname (instead of Name) as a parameter, and invoke it from a client process, similar to the example on the official gRPC site.

Prepare the environment for gRPC and Protoc

1. Inside the Killercoda Ubuntu playground, create a container using the official Go image:

docker run -it golang:1.25-bookworm /bin/bash

2. Prepare the gRPC environment by running the following commands inside the container:

apt-get update;apt-get install unzip;apt-get install nano vim -y
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest
apt-get update;apt install protobuf-compiler -y

These commands install:

unzip, nano, vim: basic utilities to unpack files and edit code.
protoc-gen-go: the Go plugin for the protobuf compiler.
protoc-gen-go-grpc: the Go plugin that generates gRPC service code.
protobuf-compiler (protoc): the compiler itself, used to generate Go code from .proto files.

Implement a gRPC service

1. Clone the grpc-go repository and remove the pre-generated protobuf files, since we are going to regenerate them after our changes:

git clone -b v1.77.0 --depth 1 https://github.com/grpc/grpc-go
cd grpc-go/examples/helloworld
rm helloworld/helloworld.pb*

2. Modify SayHello so it uses a Nickname parameter instead of Name. We need to touch three files:

helloworld/helloworld.proto: change the HelloRequest message to use nickname instead of name.
greeter_server/main.go: update the SayHello function to read and log the Nickname field.
greeter_client/main.go: update the const and var declarations to use nickname (keep the final GetMessage call as GetMessage, since that is part of the HelloReply message, not the request).

helloworld/helloworld.proto should look like this:

syntax = "proto3";

option go_package = "google.golang.org/grpc/examples/helloworld/helloworld";
option java_multiple_files = true;
option java_package = "io.grpc.examples.helloworld";
option java_outer_classname = "HelloWorldProto";

package helloworld;

// The greeting service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the nickname.
message HelloRequest {
  string nickname = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

In greeter_server/main.go, update the SayHello implementation to read in.GetNickname() and log it:

// server is used to implement helloworld.GreeterServer.
type server struct {
    pb.UnimplementedGreeterServer
}

// SayHello implements helloworld.GreeterServer
func (s *server) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {
    log.Printf("Nickname Received: %s", in.GetNickname())
    return &pb.HelloReply{Message: "Hello " + in.GetNickname()}, nil
}

In greeter_client/main.go, update the constants and flags to use nickname instead of name:

const (
    address     = "localhost:50051"
    defaultNickname = "Linus"
)

var nickname = flag.String("nickname", defaultNickname, "Nickname to send")

And when calling SayHello, send the Nickname field but keep reading the reply through GetMessage, since the reply message was not modified:

r, err := c.SayHello(ctx, &pb.HelloRequest{Nickname: *nickname})
if err != nil {
    log.Fatalf("could not greet: %v", err)
}
log.Printf("Nickname: %s", r.GetMessage())

3. Recompile the protobuf definition so the Go structs and gRPC stubs match our changes:

protoc --go_out=. --go_opt=paths=source_relative \
    --go-grpc_out=. --go-grpc_opt=paths=source_relative \
    helloworld/helloworld.proto

4. Run the server:

go run greeter_server/main.go

Wait until you see an output similar to this one:

2026/01/21 22:05:25 server listening at [::]:50051

Invoke a gRPC service from a client

5. Open a new terminal and access the same running container using docker exec. Once inside, run the client passing a nickname value:

cd grpc-go/examples/helloworld
go run greeter_client/main.go --nickname=linus2026

Expected results

Expected output on the server side:

Nickname Received: linus2026

Expected output on the client side (or similar):

2026/01/23 22:12:27 Nickname: linus2026

Conclusion about gRPC Hello World

This small exercise shows how easy it is to adapt the official gRPC Hello World example to fit a different use case, just by editing the .proto file, regenerating the stubs with protoc, and updating the server and client logic. Understanding this basic flow (proto definition → code generation → server implementation → client invocation) is the foundation for building more complex gRPC services in Go and other languages.

Thanks for reading! Last to say, see you in my next blog post.

References

Container Runtimes for Cloud Native Projects

Sergio Méndez — Tue, 30 Jun 2026 01:46:31 +0000

Hi, readers this time I want to show you different tools that you can use to create containers. We are going to explore Podman, Containerd and Youki, some projects coming from CNCF. The idea of this blog post is to use the best tool for containers based on your needs, and share some basics about how to use this tools in your cloud native projects.

This blog post will focus on:

Container Runtimes including Podman, Containerd and Youki.

What you will learn

Container Runtime Introduction
Containerd installation
Create a container with the containerd Go SDK
Install nerdctl
Using Compose with nerdctl
Working with Podman
Podman Compose
Running Containers with youki

Container Runtime Introduction

For many developers, Docker is synonymous with containers. It provides an excellent developer experience by combining image management, container execution, networking, and a familiar CLI into a single tool.

However, modern Cloud Native platforms especially Kubernetes have evolved beyond Docker as their default runtime. Today, most Kubernetes distributions rely on containerd, while alternative tools like Podman and nerdctl provide different ways to build and manage containers. Underneath them all, OCI runtimes such as runc and youki are responsible for actually creating and running containers.

Understanding how these technologies work together is an important skill for anyone working with Kubernetes, DevOps, or Platform Engineering.

Let's summarize some container tools as follows:

containerd: the container runtime used by most Kubernetes distributions.
nerdctl: A Docker-compatible CLI for containerd.
Podman: A daemonless container engine with first-class rootless support.
youki A modern OCI runtime written in Rust.

Let's see how this tools are distributed in different abstraction layers:

           Container CLI
      Docker CLI | nerdctl | Podman
                 │
          Container Engine
   Docker Engine | containerd
                 │
             OCI Runtime
            runc | youki
                 │
            Linux Kernel

Each layer has a different responsibility:

Container Engine manages images, networking, and container lifecycle.
OCI Runtime creates and starts Linux containers.
CLI tools provide a user-friendly interface.

Containerd installation

Let's asume that we are using Alpine, you have to activate the community repositories in order to install containerd for this run the following steps:
1. Edit /etc/apk/repositories to uncomment the community repository

vi /etc/apk/repositories
# Uncomment the community repo for example the line will look like this
# http://dl-cdn.alpinelinux.org/alpine/v3.23/community

2. Update the repositories

apk update

3. Install containerd

apk add containerd

4. Start containerd

service containerd start
containerd --version

Create a container with the containerd Go SDK

1. Install Go in Alpine

apk add git
apk add go

2. Create a directory to create your go code

cd $HOME
mkdir containerd-example
cd containerd-example
go mod init containerd/example

3. Install Containerd libraries to compile your example

go get github.com/containerd/containerd
go get github.com/containerd/containerd/cio
go get github.com/containerd/containerd/oci
go get github.com/containerd/containerd/namespaces

4. Create the code as main.go file using the next content

package main

import (
    "context"
    "fmt"
    "log"
    "syscall"
    "time"

    "github.com/containerd/containerd"
    "github.com/containerd/containerd/cio"
    "github.com/containerd/containerd/oci"
    "github.com/containerd/containerd/namespaces"
)

func main() {
    if err := redisExample(); err != nil {
        log.Fatal(err)
    }
}

func redisExample() error {
    // create a new client connected to the default socket path for containerd
    client, err := containerd.New("/run/containerd/containerd.sock")
    if err != nil {
        return err
    }
    defer client.Close()

    // create a new context with an "example" namespace
    ctx := namespaces.WithNamespace(context.Background(), "example")

    // pull the redis image from DockerHub
    image, err := client.Pull(ctx, "docker.io/library/redis:alpine", containerd.WithPullUnpack)
    if err != nil {
        return err
    }

    // create a container
    container, err := client.NewContainer(
        ctx,
        "redis-server",
        containerd.WithImage(image),
        containerd.WithNewSnapshot("redis-server-snapshot", image),
        containerd.WithNewSpec(oci.WithImageConfig(image)),
    )
    if err != nil {
        return err
    }
    defer container.Delete(ctx, containerd.WithSnapshotCleanup)

    // create a task from the container
    task, err := container.NewTask(ctx, cio.NewCreator(cio.WithStdio))
    if err != nil {
        return err
    }
    defer task.Delete(ctx)

    // make sure we wait before calling start
    exitStatusC, err := task.Wait(ctx)
    if err != nil {
        fmt.Println(err)
    }

    // call start on the task to execute the redis server
    if err := task.Start(ctx); err != nil {
        return err
    }

    // sleep for a lil bit to see the logs
    time.Sleep(3 * time.Second)

    // kill the process and get the exit status
    if err := task.Kill(ctx, syscall.SIGTERM); err != nil {
        return err
    }

    // wait for the process to fully exit and print out the exit status

    status := <-exitStatusC
    code, _, err := status.Result()
    if err != nil {
        return err
    }
    fmt.Printf("redis-server exited with status: %d\n", code)

    return nil
}

Install nerdctl

1. Install nerdctl to use containerd

apk add nerdctl
nerdctl --version

2. Use nerdctl to create a container

nerdctl run -d nginx

Using Compose with nerdctl

nerdctl compose up -d
nerdctl compose ps
nerdctl compose logs -f
nerdctl compose build
nerdctl compose down

Working with Podman

1. Install Podman

apk add podman

2. Create a container using Podman

podman run -it -d redis

3. List containers with Podman

podman ps

Podman Compose

podman compose up -d
podman compose ps
podman compose logs -f
podman compose down

Running Containers with youki

1. Install youki dependencies

apk add libseccomp curl

curl -sSfL https://github.com/youki-dev/youki/releases/download/v0.6.0/youki-0.6.0-$(uname -m)-musl.tar.gz | tar -xzvC /usr/bin/ youki

youki --version # Test youki installation

2. List containers created by youki

podman run --runtime /usr/bin/youki -d -p 8080:80 nginx
youki list

Conclusion about Container Runtimes

The Cloud Native ecosystem has become increasingly modular.
Understanding how containerd, nerdctl, Podman, and youki
work together helps you better understand how modern container
platforms and Kubernetes itself run workloads in production.

Thanks for reading! Last to say, see you in my next blog post.

Follow me

These are my social networks:

https://www.linkedin.com/in/sergioarmgpl
https://sergiops.xyz
https://x.com/sergioarmgpl
https://www.instagram.com/sergioarmgpl/

Please contribute to these awesome projects:

K3d & K3s for local Kubernetes environments

Sergio Méndez — Mon, 22 Jun 2026 22:59:10 +0000

Hi, readers this time I want to explain how you can set up a local Kubernetes environment using K3s a lightweight distribution. For this we are going to use K3d to install K3s in you local machine. Specially if you are a developer would be nice to install this local and lightweight Kubernetes installed in your laptop.

This blog post will focus on:
Run a local Kubernetes environment using K3s

What you will learn

Install K3d on a Linux environment
Create a cluster using K3s with K3d
Install Gateway API for the new cluster
Create a Gateway and HttpRoute to expose a deployment
Delete cluster using K3d

These are the topics that you will learn in this blog post.

Requirements

Linux running on your device (Laptop, PC, etc)

Install K3s on a Linux environment

Let's asume that you are using a Linux environment, for example Ubuntu. Now we are going to install k3d. For this follow the next steps:
1. Install K3d, the tool that we are going to use to run K3s using containers in your environment. For this run the following command:

curl -s https://raw.githubusercontent.com/k3d-io/k3d/main/install.sh | bash

2. Run the following command to return the K3d version installed:

k3d version

Create a cluster using K3s with K3d

With everything installed let's create a cluster with K3d which uses K3s internally to create a Kubernetes cluster using containers. For these follow the next steps:
1. Create a cluster with K3d without installing Traefik and the load balancer default service in K3s:

k3d cluster create mycluster \
--no-lb --network host \
--k3s-arg '--disable=traefik@server:*' --k3s-arg '--disable=servicelb@server:*'

This will show an output like this:

INFO[0000] [SimpleConfig] Hostnetwork selected - disabling injection of docker host into the cluster, server load balancer and setting the api port to the k3s default
INFO[0000] [ClusterConfig] Hostnetwork selected - disabling injection of docker host into the cluster, server load balancer and setting the api port to the k3s default
INFO[0000] Prep: Network
INFO[0000] Re-using existing network 'host' (....)
INFO[0000] Created image volume k3d-mycluster-images
INFO[0000] Starting new tools node...
INFO[0000] Starting node 'k3d-mycluster-tools'
INFO[0001] Creating node 'k3d-mycluster-server-0'
INFO[0001] Using the k3d-tools node to gather environment information
INFO[0001] Starting cluster 'mycluster'
INFO[0001] Starting servers...
INFO[0001] Starting node 'k3d-mycluster-server-0'
INFO[0008] All agents already running.
INFO[0008] All helpers already running.
INFO[0008] Cluster 'mycluster' created successfully!
INFO[0008] You can now use it like this:
kubectl cluster-info

2. Troubleshoot the cluster with the following commands:

kubectl get pods -A #All the pods should appear with STATUS Running
kubectl get nodes #Show all the nodes STATUS as Ready

3. Install MetalLB to have a load balancer provisioner for your cluster:

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.4/config/manifests/metallb-native.yaml

4. Found a range of IP Addresses to use for your load balancer for this, you can check the with the route command your available routes. Here is an example:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         sergioarmgpl.ms 0.0.0.0         UG    0      0        0 eth0
10.42.0.0       0.0.0.0         255.255.255.0   U     0      0        0 cni0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.29.192.0    0.0.0.0         255.255.240.0   U     0      0        0 eth0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

In this case we are going to use a cluster that use the internal network of the host that use the eth0 interface. You can also use an AI Tool(Like Gemini or Chatgpt to get a valid range to set for your IPAddressPool on MetalLB, in this case for the output
"172.29.192.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0"
You can ask a valid range of 30 IP addresses. In this case we got the following range:
172.29.206.120-172.29.206.150
With that value we can create a IP address pool for MetalLB to have a range to assign for Load Balancer services in your cluster.
5. Create a IPAddress Pool with the previous range:

cat <<EOF | kubectl create -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: ip-pool
  namespace: metallb-system
spec:
  addresses:
  - 172.29.206.120-172.29.206.150
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertisement
  namespace: metallb-system
spec:
  ipAddressPools:
  - ip-pool
EOF

Install Gateway API for the new cluster

Now Let's install the Gateway API that is a common software used in the latest Kubernetes. For this follow the next steps:
1. Install the Gateway API CRDs for the NGINX Gateway Fabric, which is one of the Gateways available to expose application sharing a gateway for your applications:

kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v2.4.2" | kubectl apply -f -

2. Install the NGINX Gateway Fabric:

helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric --create-namespace -n nginx-gateway

Create a Gateway and HttpRoute to expose a deployment

Now with everything installed let's create a Gateway and a HttpRoute to expose a webserver deployment. For this follow the next steps:
1. Create a deployment running NGINX called myapp, with a service using the port 80. The following commands create a namespace, a deployment, a service and a gateway:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: mynamespace
spec: {}
status: {}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: myapp
  name: myapp
  namespace: mynamespace
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: myapp
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
status: {}
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: myapp
  name: myapp
  namespace: mynamespace
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: myapp
  type: ClusterIP
status:
  loadBalancer: {}
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mygateway
  namespace: mynamespace
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP
EOF

2. Now create a HTTPRoute using the Load Balancer IP Created by the Service. For this run the following commands:

export GW=$(kubectl get svc mygateway-nginx -n mynamespace -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: approute
  namespace: mynamespace
spec:
  parentRefs:
  - name: mygateway
  hostnames:
  - "$GW.nip.io"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: myapp
      port: 80
EOF

Note: The previous commands set the IP Address created by the service in the variable GW, and use the value to create an HttpRoute, which uses nip.io free service to create a free URL as IP Address.nip.io which resolves to the IP Address.
3. Now access the NGINX deployment by running:

curl http://$GW.nip.io

For a more advanced Gateway API configuration check the following link: https://dev.to/sergioarmgpl/goodbye-ingress-hello-gateway-api-migrating-the-right-way-20k9

Delete cluster using K3d

To delete the cluster follow the next command:

k3d cluster delete mycluster

Note: For more commands about K3d, you can run k3d in your CLI to get more commands.

Conclusion about K3d

K3d is a nice tool that helps your to create quick and functional lightweight Kubernetes clusters using K3s. This tutorial covers the basics to create your how cluster. To customize it more, you need some basic of networking to play a little bit, but with this information you can do more than the basics. Also after writing this tutorial I discover that Talos Linux has a similar tool but doesn't include the metrics service in the cluster by default. Also not a big fan of MiniKube because runs slowly than K3s with K3d. Kind is also another good alternative but K3s feels more production ready. If you are looking to don't get your environment dirty with a lot of installation you can still have a clean system by using K3d, I can recommend it to use it for that quick dev environments using Kubernetes without using a lot of ran. Try to run K3s with K3d today, I am using this with my students in the university with really good results. Last to say, see you in my next blog post.

Follow me

These are my social networks:

https://www.linkedin.com/in/sergioarmgpl
https://sergiops.xyz
https://x.com/sergioarmgpl
https://www.instagram.com/sergioarmgpl/

Please contribute to this awesome project:

https://k3d.io/

Creating a RabbitMQ PubSub system with Dapr

Sergio Méndez — Wed, 29 Apr 2026 16:09:22 +0000

Hi, readers community, to continue with this series of blog posts, we are going to learn about how to use Dapr. Darp gives you a set of tools to write a event-driven runtime focusing on building resilient, stateless, and stateful applications that run on the cloud and edge. Also supports a diversity of languages and developer frameworks. Thats more or less what Darp is based in the official documentation. So we can see it as a set of building blocks to build your event-driven system. The idea in this blog post, is to give a quick tutorial about, how you can use Dapr to write a Publisher Subscriber system really fast and simple, without writing a lot of code. So Dapr, can speed your workday. This blog post will focus on:

Create a PubSub System using Dapr SDK and RabbitMQ

What you will learn

In this blog post you will learn how to:

Install Dapr in your cluster
Install RabbitMQ to manage messages with Dapr
Create a Publisher using the Golang Dapr SDK
Create a Subscriber using the Golang Dapr SDK
Use PubSub Dapr implementation

These are the topics that you will learn in this blog post.

Requirements

A Kubernetes cluster
Access to the cluster using kubectl
Internet Access

So let's get started with this tutorial. :)

Install Dapr in your cluster:

1. Install the DAPR CLI with the following command:

wget -q https://raw.githubusercontent.com/dapr/cli/master/install/install.sh -O - | /bin/bash

2. Verify that the CLI was installed:

dapr -h

3. Install Dapr in Kubernetes

dapr init --kubernetes
dapr init --slim # to install without default configurations

4. Verify the installation:

dapr status -k

5. Access the Dashboard with the following command

kubectl port-forward svc/dapr-dashboard -n dapr-system 8080:8080 --address 0.0.0.0

6. Access the Dashboard in http://localhost:8080

Install RabbitMQ to manage messages with Dapr

1. Install the RabbitMQ Operator:

kubectl apply -f "https://github.com/rabbitmq/cluster-operator/releases/latest/download/cluster-operator.yml"

2. Create a cluster with the following YAML:

echo "apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: mycluster" | kubectl apply -f -

Note: If you want labels you can use something like this:

echo "apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  labels:
    app: rabbitmq
  annotations:
    some: annotation
  name: mycluster" | kubectl apply -f -

3. Get the user password for this RabbitMQ instance:

#To get the user
export USERNAME=$(kubectl -n default get secret mycluster-default-user -o jsonpath="{.data.username}" | base64 --decode)

#To get the password
export PASSWORD=$(kubectl -n default get secret mycluster-default-user -o jsonpath="{.data.password}" | base64 --decode)

4. Now create the component to connect RabbitMQ to the Dapr installation using the previos USERNAME and PASSWORD:

echo 'apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: message-pub-sub
spec:
  type: pubsub.rabbitmq
  version: v1
  metadata:
  - name: connectionString
    value: "amqp://'$USERNAME:$PASSWORD@'mycluster:5672"
  - name: protocol
    value: amqp  
  - name: username
    value: '$USERNAME'
  - name: password
    value: '$PASSWORD'
  - name: hostname
    value: mycluster
  - name: durable
    value: "true"
  - name: maxLen
    value: 20
  - name: deletedWhenUnused
    value: "false"
  - name: autoAck
    value: "false"
  - name: reconnectWait
    value: "0"
  - name: concurrency
    value: parallel
scopes:
  - publisher
  - subscriber' | kubectl apply -f -

Create a Publisher using the Golang Dapr SDK

Now its time to create the publisher code and create a deployment with this code.
1. Create a container with the following code:

package main

import (
    "net/http"   
    "context"
    "os"
    "log"
    "github.com/gin-gonic/gin"
    dapr "github.com/dapr/go-sdk/client"
)

type Message struct {
  Data     string    `json:"data"`
}

var (
    AppPort = getEnv("APP_PORT", "3500")
    PubsubName   = getEnv("PUBSUB_NAME", "mypubsub")
    TopicName    = getEnv("TOPIC_NAME", "mytopic")
)

func getEnv(key, fallback string) string {
    if value, ok := os.LookupEnv(key); ok {
        return value
    }
    return fallback
}

func publishHandler(c *gin.Context) {
    var message Message

    if err := c.ShouldBind(&message); err != nil {
        c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
        return
    }

    log.Println("Published message with data: " + message.Data)
    PublishEvent(message.Data)

    c.JSON(http.StatusOK, gin.H{
        "message_data":     message.Data,
    })
}

func PublishEvent(data string) error {
    client, err := dapr.NewClient()
    if err != nil {
        panic(err)
    }
    defer client.Close()
    ctx := context.Background()
    //Using Dapr SDK to publish a topic
    if err := client.PublishEvent(ctx, PubsubName, TopicName, []byte(data)); err != nil {
        panic(err)
    }

    log.Println("Published %s to topic %s\n", data, TopicName)
    return nil
}

func main() {
    router := gin.Default()
    gin.SetMode(gin.DebugMode)
    router.Use(gin.Logger())
    router.POST("/publish", publishHandler)
    // Listen and serve on 0.0.0.0:<AppPort>
    router.Run(":"+AppPort)
    log.Println("Running Publisher Service")
}

2. Now create the deployment using the container that contains the previous code and applying the following YAML file:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: publisher
  name: publisher
spec:
  replicas: 1
  selector:
    matchLabels:
      app: publisher
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: publisher
      annotations:
        dapr.io/enabled: "true"
        dapr.io/app-id: "publisher"
        dapr.io/app-port: "4500"
        dapr.io/enable-api-logging: "true"
    spec:
      containers:
      - image: <REGISTRY_USER>/<IMAGE>:TAG
        name: dapr-go-publisher
        ports:
        - containerPort: 4500
        env:
        - name: APP_PORT
          value: "4500"
        - name: PUBSUB_NAME
          value: "message-pub-sub"
        - name: TOPIC_NAME
          value: "messages"
        resources: {}
status: {}
---
kind: Service
apiVersion: v1
metadata:
  name: publisher
  labels:
    app: publisher
spec:
  selector:
    app: publisher
  ports:
  - protocol: TCP
    port: 4500
    targetPort: 4500
  type: ClusterIP

Note: This code creates the deployment and the service need to run the publisher. Take a look that we use the following annotations:

      annotations:
        dapr.io/enabled: "true"
        dapr.io/app-id: "publisher"
        dapr.io/app-port: "4500"
        dapr.io/enable-api-logging: "true"

These annotations enable the integration of Dapr in your deployment without coding anything. Now your Publisher is ready and running. Let's continue with the Subscriber deployment.

Create a Subscriber using the Golang Dapr SDK

In this part you are going to run the subscriber. We also use the Dapr SDK to create a subscription using code and the SDK and not a declarative YAML file.
1. Create the subscriber container using the following code:

package main

import (
    "log"
    "net/http"
    "context"
    "os"
    "github.com/dapr/go-sdk/service/common"
    daprd "github.com/dapr/go-sdk/service/http"
)


var sub = &common.Subscription{
    PubsubName: getEnv("PUBSUB_NAME", "mypubsub"),
    Topic:      getEnv("TOPIC_NAME", "mytopic"),
    Route:      "/subscriber",
}

func getEnv(key, fallback string) string {
    if value, ok := os.LookupEnv(key); ok {
        return value
    }
    return fallback
}

func main() {
    s := daprd.NewService(":6002")
   //Subscribe to a topic
    if err := s.AddTopicEventHandler(sub, eventHandler); err != nil {
        log.Fatalf("error adding topic subscription: %v", err)
    }
    log.Printf("Subscriber listening")
    if err := s.Start(); err != nil && err != http.ErrServerClosed {
        log.Fatalf("error listenning: %v", err)
    }
}

func eventHandler(ctx context.Context, e *common.TopicEvent) (retry bool, err error) {
    log.Printf("Subscriber message received: %s", e.Data)
    return false, nil
}

2. Now create a deployment using the following YAML file:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: subscriber
  name: subscriber
spec:
  replicas: 1
  selector:
    matchLabels:
      app: subscriber
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: subscriber
      annotations:
        dapr.io/enabled: "true"
        dapr.io/app-id: "subscriber"
        dapr.io/app-port: "6002"
        dapr.io/enable-api-logging: "true"
    spec:
      containers:
      - image: <REGISTRY_USER>/<IMAGE>:TAG
        name: dapr-go-subscriber
        ports:
        - containerPort: 6002
        env:
        - name: PUBSUB_NAME
          value: "message-pub-sub"
        - name: TOPIC_NAME
          value: "messages"
        resources: {}
status: {}
---
kind: Service
apiVersion: v1
metadata:
  name: subscriber
  labels:
    app: subscriber
spec:
  selector:
    app: subscriber
  ports:
  - protocol: TCP
    port: 80
    targetPort: 6002
  type: ClusterIP

Note: This code create the subscriber you can modify the code to change the topic and the pubsub name.

Use PubSub Dapr implementation

To use the system you have to run the following commands to check logs, access and access the API. Let's check these commands:

*1. Check the logs of the subscriber and publisher on real time with following commands using different terminals:

#open logs for publisher
kubectl logs deploy/publisher --all-containers=true -f
#open logs for subscriber
kubectl logs deploy/subscriber--all-containers=true -f

2. Expose the Publisher API to send data to the PubSub which uses RabbitMQ

kubectl port-forward svc/publisher 4500:4500 --address 0.0.0.0

3. Use curl to insert data using the publisher running this command:

curl -X POST http://localhost:4500/publish \
-H "Content-Type: application/json" \
-d '{"data": "data1"}'

4. Check the logs in your terminals you will see messages like these:

#for the subscriber
2026/04/30 00:30:11 Subscriber message received: somedata...
#for the publisher
[GIN] 2026/04/30 - 00:30:31 | 200 |   1.48ms |       127.0.0.1 | POST     "/publish"
2026/04/30 00:30:31 Successfully published to topic messages

And that's it, your system is running.

Code Repository

If you can check the containers code, you can check the repo in the following link:

https://github.com/sergioarmgpl/dapr-rabbit-example

Conclusion about Dapr

Dapr is an interesting project that can speed your work when you are designing and implementing an event-driven system. Also support different languages that developer can use to implement this kind of systems. Dapr can simplify the adoption of different technologies and solve architecture design and implementation to implement a robust system for your needs. Also I think that there is some lack of documentation for Kubernetes, but if you can take time to play with it you can achieve robust and nice implementation. At the end of this post there are some links including ones in the official documentation that I used to create this blog post. I want to mention that my students in USAC University in Guatemala in the operating systems courses are going to use this tutorial, that's so cool. Maybe my next blog post will be related to microcks to continue with the journey of cloud native stuff.

See you in my next blog post.

Follow me

These are my social networks:

https://www.linkedin.com/in/sergioarmgpl
https://sergiops.xyz
https://x.com/sergioarmgpl
https://www.instagram.com/sergioarmgpl/

Please contribute to this awesome project:

https://dapr.io/

Useful links:

Goodbye Ingress, Hello Gateway API: Migrating the Right Way

Sergio Méndez — Fri, 27 Mar 2026 00:48:48 +0000

Hi, dear community of readers, continuing with this blog posts to learn called Learning Kubernetes, this time is the time to learn about how to use the Gateway API. Now all the teams are looking to migrate, so my goal with this post is to help you with a quick start guide to understand and use the Gateway API with the implementation created by NGINX. I know that a lot of people used the NGINX Ingress Controller in their clusters, so makes sense to continue in that way but using the Gateway API. So let's summarize my goals:

Start using Gateway API
Setup a functional Gateway API with NGINX for your services So let's start with this content, I know you want to now how to use the Gateway API.

What you will learn

In this blog post you will learn how to:

Install the Gateway API & NGINX Gateway Fabric
Create and use Gateways and HTTP Routes
Configure Cert-Manager for TLS for your Gateways

Requirements

A Kubernetes Cluster
Access to the cluster using kubectl

Install the Gateway API & NGINX Gateway Fabric

To install the Gateway API & NGINX Gateway Fabric follow these steps:
1. Install Gateway API & NGINX Gateway Fabric CRDs:

kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v2.4.2" | kubectl apply -f -

2. Install the NGINX Gateway Fabric using Helm

helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric --create-namespace -n nginx-gateway

Create and use Gateways and HTTP Routes

Now let's create a simple deployment wiht a Gateway and HTTP Route by following the next steps:
1. Install the following application waiting for the Public api created by the Gateway :

kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: mynamespace
spec: {}
status: {}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: myapp
  name: myapp
  namespace: mynamespace
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: myapp
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
status: {}
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: myapp
  name: myapp
  namespace: mynamespace
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: myapp
  type: ClusterIP
status:
  loadBalancer: {}
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mygateway
  namespace: mynamespace
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP
EOF

2. Get the IP assigned to the Gateway using the following command:

export GW=$(kubectl get svc mygateway-nginx -n mynamespace -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

Note: You have to wait for some minutes in order that the cloud provider assign an external IP to the Gateway created.
3. Create the route to expose the application:

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: approute
  namespace: mynamespace
spec:
  parentRefs:
  - name: mygateway
  hostnames:
  - "$GW.nip.io"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: myapp
      port: 80
EOF

4. Test the Application by using curl as follows:

curl http://$GW.nip.io

And that's it now it works, now let's move on using TLS.

Configure Cert-Manager for TLS for your Gateways

Now let's configure the Cert-Manage to generate a certificate for your app by following these steps:
0. (Optional) Delete the previous gateway and route as follows:

kubectl delete gateway mygateway -n mynamespace
kubectl delete httproute approute -n mynamespace

1. Add the cert-manager helm chart

helm repo add jetstack https://charts.jetstack.io
helm repo update

2. Add the cert-manager helm chart
Install the cert-manager, and enable the GatewayAPI feature gate:

helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set config.apiVersion="controller.config.cert-manager.io/v1alpha1" \
  --set config.kind="ControllerConfiguration" \
  --set config.enableGatewayAPI=true \
  --set crds.enabled=true

3. Create a ClusterIssuer to use to generate your certicate:

export EMAIL="your_name@domain.tld"
kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    email: $EMAIL
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: issuer-account-key
    solvers:
    - http01:
        gatewayHTTPRoute:
          parentRefs:
          - name: gateway
            namespace: default
            kind: Gateway
EOF

Note: For self signed TLS use this file:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}
EOF

4. Change your current Gateway as follows:

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mygateway
  namespace: mynamespace
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP
  - name: https
    hostname: "$GW.nip.io"
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: tls-secret
EOF

Note: For internal TLS use self-signed certificates in the cert-manager.io/cluster-issuer as selfsigned-issuer, also use the previous GW value the first time, then check for the service called mygateway-nginx using the following command:

kubectl get svc -n mynamespace

Then update the value GW with the following command:

export GW=$(kubectl get svc mygateway-nginx -n mynamespace -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

And apply the YAML again to point to the correct URL.
5. Now modify your HTTP Route as follows:

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: approute
  namespace: mynamespace
spec:
  parentRefs:
  - name: mygateway
    sectionName: https
  hostnames:
  - "$GW.nip.io"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: myapp
      port: 80
EOF

6. Now test your application by running the following command:

curl https://$GW.nip.io

And that's it, now you have learned how to use the Gateway API with the NGINX Fabric Gateway implementation using also TLS with Cert-Manager. Take a look to the Links in the references for more theory and examples, of course if you need something more complicated :).

References

The Ingress API itself is NOT deprecated. The GA Ingress API (networking.k8s.io/v1) remains fully supported in Kubernetes. You can still create and use Ingress resources without any issue.
• Ingress controllers as a category are NOT deprecated. Only the specific ingress-nginx project (maintained by Kubernetes SIG Network) was retired. Alternatives like Traefik, Kong, HAProxy, and others are alive and well.

Conclusion about the Gateway API with NGINX

Well, a lot of companies are getting into chaos because that Kubernetes deprecate the ingress-nginx project maintained by Kubernetes SIG Network. But Ingress API itself is NOT deprecated, (networking.k8s.io/v1) remains fully supported in Kubernetes. I want to clarify that Ingress controllers as a category are NOT deprecated. Alternatives like Traefik, Kong, HAProxy, and others still alive. Also my experience configuring the Gateway API, it was not as complicated for simple configuration like the one I showed in the post. I hope this can help as an initial configuration that you can expand for your needs. Well this Gateway API is the future for Kubernetes to have something more stable to manage. I am curious to test another implementations. But it seems that works, maybe the documentation is not as well designed but you can find the necessary parts that you need in the links before. Thanks to Chad M. Crowell to clarify the whole context about how the state of the Gateway API and Ingress Controllers are right now.

So what implementation of Gateway API are you going to use, write a comment below :).

That a lot for me this time, see you the next one. I hope so hehehe.

Follow me

These are my social networks:

https://www.linkedin.com/in/sergioarmgpl
https://sergiops.xyz
https://x.com/sergioarmgpl
https://www.instagram.com/sergioarmgpl/

KubeVirt to run VMs in your K8s cluster

Sergio Méndez — Fri, 19 Dec 2025 23:23:14 +0000

Hi, dear readers I am starting a new series of blog posts called Learning Kubernetes with different complementing the traditional knowledge of Kubernetes. In this first post that I am going to share with my students in the university is about how to use KubeVirt in Kubernetes. One of my main topics in my course is virtualization so let me summarize my goals for writing this blog post:

Use VMs in container environments
Test how easy to use is KubeVirt
Customize my own VMs on a Kubernetes environment
Install KubeVirt on any Cloud Provider(GCP in specific) So let's start with the tutorial using KubeVirt. Let's have fun.

What you will learn

In this blog post you will learn how to:

Install KubeVirt bypassing the default requirements
Create a custom VM image in qcow2 with Qemu
Package your qcow2 image in a container image
Create a VM and expose VM services in KubeVirt

Requirements

A GKE cluster (Kubernetes cluster managed by Google Cloud) with N1 virtual machine type with nested virtualization enabled
Access to the cluster using kubectl
Preinstalled qemu in your distro (Let's asume Ubuntu) So let's get started with this tutorial. :)

Install KubeVirt bypassing the default requirements

To install KubeVirt get the KubeVirt latest stable version running the following steps:
1. Download the kubevirt-operator.yaml file and remove the affinity and tolerations:

export VERSION=$(curl -s https://storage.googleapis.com/kubevirt-prow/release/kubevirt/kubevirt/stable.txt)
wget https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-operator.yaml

Note: This downloads the kubevirt-operator.yaml file that you have to change to install the operator in any cloud provider like GKE, AKS or EKS. You have to change this file to remove the affinity and tolerations that the operator looks to deploy its components. KubeVirt looks for a control-plane node for security reason to deploy the operator.
2. Install the operator with the modified kubevirt-operator.yaml file

kubectl create -f kubevirt-operator.yaml

3. Create a KubeVirt definition to deploy the custom resource definitions:

cat << END > kubevirt-cr.yaml
apiVersion: kubevirt.io/v1
kind: KubeVirt
metadata:
  name: kubevirt
  namespace: kubevirt
spec:
  certificateRotateStrategy: {}
  configuration:
    developerConfiguration:
      featureGates: []
  customizeComponents: {}
  imagePullPolicy: IfNotPresent
  workloadUpdateStrategy: {}
  infra:
    nodePlacement: {}
  workloads:
    nodePlacement: {}
END

Note: If you want emulation add the following configuration in developerConfiguration as follows:

    developerConfiguration:
      useEmulation: true
      featureGates: []

4. Deploy the definitions

kubectl apply -f kubevirt-cr.yaml

5. Wait for the deployments to be ready you

kubectl get all -n kubevirt

Create a custom VM image in qcow2 with Qemu

Assuming that you have an Ubuntu OS run the following steps:
1. Install Qemu:

sudo apt install qemu-kvm qemu-utils libvirt-daemon-system libvirt-clients bridge-utils

2. In a directory create a disk for your VM, we are going to use Alpine for our VM:

qemu-img create -f qcow2 alpine_disk.qcow2 1G

3. Download the ISO image for your Alpine VM

wget https://dl-cdn.alpinelinux.org/alpine/v3.23/releases/x86_64/alpine-standard-3.23.2-x86_64.iso

4. Start the new Qemu VM and install the OS:

sudo qemu-system-x86_64 -enable-kvm -m 2G -cpu host -smp 2 -cdrom alpine-standard-3.22.0-x86_64.iso -drive file=alpine_disk.qcow2,format=qcow2 -boot d

5. Boot from disk instead of the CD-ROM and install your software:

sudo qemu-system-x86_64   -enable-kvm   -m 2G   -cpu host   -smp 2   -drive file=alpine_disk.qcow2,format=qcow2

6. Your new image alpine_disk.qcow2 its ready to be used.

Package your qcow2 image in a container image

Assuming that you have a Docker Hub user and you are login in your account run the following steps:
1. Create the Dockerfile to package for image

cat << END > Dockerfile
FROM scratch
ADD --chown=107:107 alpine_disk.qcow2 /disk/
END

2. Tag you image with your Docker user

docker build -t <docker_hub_user>/alpineimage:latest .
docker push <docker_hub_user>/alpineimage:latest

Create a VM a expose VM services in KubeVirt

To create a basic KubeVirt VM follow the next steps:
1. Create the KubeVirt VM definition

cat << END > vm.yaml
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: alpinevm
spec:
  runStrategy: Halted
  template:
    metadata:
      labels:
        kubevirt.io/size: medium
        kubevirt.io/domain: alpineso1
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
          interfaces:
          - name: default
            masquerade: {}
        cpu:
          cores: 1
        resources:
          requests:
            memory: 1Gi
      networks:
      - name: default
        pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: <docker_hub_user>/alpineimage
END

2. Apply the definition

kubectl apply -f vm.yaml

3. Check for the vm to be created

kubectl get vms

You will see the VM in the stopped state
4. Install virtctl CLI

VERSION=$(kubectl get kubevirt.kubevirt.io/kubevirt -n kubevirt -o=jsonpath="{.status.observedKubeVirtVersion}")
ARCH=$(uname -s | tr A-Z a-z)-$(uname -m | sed 's/x86_64/amd64/') || windows-amd64.exe
echo ${ARCH}
curl -L -o virtctl https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/virtctl-${VERSION}-${ARCH}
sudo install -m 0755 virtctl /usr/local/bin

5. Start the VM

virtctl start alpinevm

6. Expose any service you have on the VM

virtctl expose vm alpinevm --port=<PORT_NUMBER> --name=<NEW_SERVICE_NAME> --type=ClusterIP

7. Now you can access the service of your VM in any Kubernetes Pod, Deployment, etc.

Conclusion about KubeVirt

KubeVirt is a technology that can be used when your applications are difficult to convert to containers or there is an specific situation where containers are not suitable to be used. Also for security reasons some systems prefer the use of VMs instead of containers and already have a Kubernetes environment that should interact with this VMs.

KubeVirt its an option option for VMs. In the university, we are testing KubeVirt to run some experiments with cloud native technologies. It was nice to create a VM using Qemu again and see that virtual machines needs to be used also in containerized environments. So it was a nice experience playing with KubeVirt a little bit.

See you on my next post with something interesting again.

Follow me

These are my social networks:

https://www.linkedin.com/in/sergioarmgpl
https://sergiops.xyz
https://x.com/sergioarmgpl
https://www.instagram.com/sergioarmgpl/

Please contribute to this awesome project:

https://kubevirt.io

Zot and ORAS to create & manage edge container registries

Sergio Méndez — Mon, 17 Mar 2025 06:00:00 +0000

Hi dear readers after been busy the last two weeks, I am back for Day 3 of my series 30DaysOfIoTEdge. Now it's time to learn about a container registry that you can run on devices with ARM microprocessors and that is compatible with OCI artifacts.

As the CNCF website on the sandbox projects page says "Zot is an OCI-native container registry for distributing container images and OCI artifacts". This means that you can not just only push containers or helm charts in your registry, but also you can push any type of file. For example, configuration files, ML models, images, etc. So you can deploy something similar to Docker Hub. But is completely free to use, as common in open source software. Check its official website for more in deep information about this project: https://zotregistry.dev/.

Based on the edu.chainguard.dev website and OCI artifact is "OCI artifacts are a way of using OCI registries, or container registries that are compliant with specifications set by the Open Container Initiative, to store arbitrary files.". Now we are clear that we can use the registries as a way to store. Something similar to having your own S3 storage. So let's start with the technical side of my blog post.

What you will learn

In this blog post you will learn:

Install Zot on ARM Devices (like a RPi).
Push & Pull a container into Zot
Push & Pull files as OCI artifacts into Zot using ORAS

Requirements

Raspberry Pi or ARM instance in the cloud.
Ubuntu >= 22.04
Install docker (default installation)

Let's put our hands on Zot.

Install Zot on ARM Devices

1. Install containerd running the following command:

sudo apt-get update
sudo apt-get install -y docker.io

These commands install Docker as your container runtime.

2. Install Zot to run in the port 5000 running following command:

docker run --name=zot -p 5000:5000 -d ghcr.io/project-zot/zot-linux-arm64:latest

Push & Pull a container into Zot

1. Pull the nginx image with the docker command:

docker pull nginx

2. Tag the image to push it with the name webserver into the Zot registry:

docker tag nginx localhost:5000/<NAMESPACE>/webserver:latest

NAMESPACE: Refers to any string that is going to simulate a project or user space in the registry. Because this is a basic installation you can use for it whatever string that you want.
3. Push the container into Zot as a image called webserver:latest, for this run the following command:

docker push localhost:5000/<NAMESPACE>/webserver:latest

4. Pull the previous container from the Zot registry as follows:

docker pull localhost:5000/<NAMESPACE>/webserver:latest

As you can see it works as any other registry. Let's move to work with OCI Artifacts.

Push/Pull files as OCI artifacts into Zot using ORAS

1. Install ORAS using snap:

snap install oras --classic

2. Create 2 files in your current directory:

echo 1 > file1.txt
echo 2 > file1.txt

3. Push the files as OCI artifacts into the repo as follows:

oras push localhost:5000/<NAMESPACE>/files:latest file1.txt file2.txt

You will see an output like this:

✓ Exists    application/vnd.oci.empty.v1+json                          2/2  B 100.00%     0s
  └─ sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a
✓ Exists    file1.txt                                                  2/2  B 100.00%     0s
  └─ sha256:4355a46b19d348dc2f57c046f8ef63d4538ebb936000f3c9ee954a27460dd865
✓ Exists    file2.txt                                                  2/2  B 100.00%     0s
  └─ sha256:53c234e5e8472b6ac51c1ae1cab3fe06fad053beb8ebfd8977b010655bfdd3c3
✓ Uploaded  application/vnd.oci.image.manifest.v1+json             795/795  B 100.00%    6ms
  └─ sha256:a3ca9cc257cce158f8d94674c70ce67ee8fa6f19eea3cebe368ce1c140be9dfd
Pushed [registry] localhost:5000/test1/files:latest
ArtifactType: application/vnd.unknown.artifact.v1
Digest: sha256:a3ca9cc257cce158f8d94674c70ce67ee8fa6f19eea3cebe368ce1c140be9dfd

This command create an OCI artifact called files with the tag latest which contains the files file1.txt and file2.txt.
4. Pull the files inside the OCI artifacts files:latest using the following command:

oras pull --plain-http localhost:5000/<NAMESPACE>/files:latest

You will see that the files will be unpackaged in your current directory and an output as follows:

✓ Pulled      file2.txt                                                2/2  B 100.00%  472µs
  └─ sha256:53c234e5e8472b6ac51c1ae1cab3fe06fad053beb8ebfd8977b010655bfdd3c3
✓ Pulled      file1.txt                                                2/2  B 100.00%    2ms
  └─ sha256:4355a46b19d348dc2f57c046f8ef63d4538ebb936000f3c9ee954a27460dd865
✓ Pulled      application/vnd.oci.image.manifest.v1+json           795/795  B 100.00%  113µs
  └─ sha256:a3ca9cc257cce158f8d94674c70ce67ee8fa6f19eea3cebe368ce1c140be9dfd
Pulled [registry] localhost:5001/test1/files:latest
Digest: sha256:a3ca9cc257cce158f8d94674c70ce67ee8fa6f19eea3cebe368ce1c140be9dfd

Try to run this command on an empty directory to check if the artifact is unpackaged in that directory.

Zot UI

Do you want to use UI? Zot provides a UI for you, it looks like this in the main page:

And if you check an artifact looks like this:

Advanced options

Zot also provides more advance options like:

Supports helm charts
TLS support
Authentication
OCI Compatible
ARM support

Just to mention some of the features that are included. Its pretty easy to use and lightweight for edge solutions.

Are there another Registries that runs on ARM? Yes

You can use Distribution which is another option that runs on ARM.

Conclusion about Zot and ORAS

After testing Zot, its ARM compatible, lightweight and with enough features to implement a secure implementation for edge use cases. You can start quick to configure your own registry pretty quick with Zot. You can go wrong with it. Also with ORAS you can take advantage of pushing files like ML models, configurations and other kind of files that sometimes you need to store for temporary use, thats will be ideal for edge computing. So when using Zot and ORAS you get a full setup to create and manage your registries compatible with OCI artifacts.

What do you think about Zot and ORAS? Tell me, post your comment.

See you on my next post.

Follow me

These are mi social networks:

This blog post is an extended version content of my book:

https://amzn.to/3Vx6pnt

Creating containers with containerd & nerdctl on ARM

Sergio Méndez — Mon, 24 Feb 2025 06:00:00 +0000

Hi Folks, this is the Day 2 of my series 30DaysOfIoTEdge. Its time to learn more in deep how to create containers with a lightweight container runtime containerd together with nerdctl to create containers. nerdctl provides to the users to interact with the containerd to create containers as same as Docker.

containerd provides similar functionalities like Docker but in a small memory and CPU footprint which is ideal for IoT or edge solutions when using containers, also we are using ARM microprocessor that has a good balance between energy and CPU consumption, so that's the reason about why containerd fits and match nicely with ARM.

Also, Containers are the tool when you want to speed your process of updating your software and get modularity and portability when deploying your solutions. In this post you will learn how containerd together with nerdctl can help you with this use case scenario. Check their official websites for more info https://containerd.io and https://github.com/containerd/nerdctl.

What you will learn

In this blog post you will learn:

Install the containerd container runtime on ARM Devices (Rasberry Pi).
Install nerdctl to use containerd to create containers.
Create a basic container with nerdctl command line.

Requirements

Raspberry Pi or ARM instance in the cloud.
Ubuntu >= 22.04
Install containerd
Install CNI plugin
Install nerdctl

So Let's create containers with containerd.

Creating Python containers for ARM

1. Install containerd running the following command:

sudo apt-get update
sudo apt-get install -y containerd

This commands install containerd in your device.

2. Install nerdctl with the following commands:

NERDCTL_VERSION=2.0.3
wget https://github.com/containerd/nerdctl/releases/download/v2.0.3/nerdctl-$NERDCTL_VERSION-linux-arm64.tar.gz 
tar -xzvf nerdctl-$NERDCTL_VERSION-linux-arm64.tar.gz -C /sbin
CNI_VERSION=1.6.2
wget https://github.com/containernetworking/plugins/releases/download/v$CNI_VERSION/cni-plugins-linux-arm64-v$CNI_VERSION.tgz
mkdir -p /opt/cni/bin
tar -xzvf cni-plugins-linux-arm64-v$CNI_VERSION.tgz -C /opt/cni/bin

3. Create a container with nerdctl
Create an NGINX container exposing the port 80 to the 8080 in the host:

sudo nerdctl run --restart always -d -p 80:80 --name=nginx nginx

4. Test the container
Create the file with the following command:

curl localhost:8080

Note: This returns It works.

Extra commands

You can use the following commands for containerd:
1. To restart the service run:

sudo systemctl restart containerd

You can use the following commands for nerdctl:
2. List images

sudo nerdctl images

3. Push images

sudo nerdctl images

4. Pull images

sudo nerdctl images

5. Build images in the current directory

sudo nerdctl build .

6. Tag images

sudo nerdctl tag old_image:old_tag new_image:new_tag

Where is Podman, Docker and CRI-O?

Wait a moment. Let me tell you that there are alternatives, but containerd in particular has a low memory and CPU footprint so it's ideal for IoT and Edge devices. Podman could fit these needs and interact directly with RunC, which is daemonless. Docker because has more options and its daemon consumes more resources maybe doesn't fit IoT needs. CRI-O it could be but was designed to be lightweight and fit OCI compliance. Also, ask yourself if you need ARM support. The final decision depends on how much energy you want to consume, features, etc. With containerd, you can go wrong with IoT and Edge. In the future, I will add some table of comparison about footprint consumption. But try this tutorial to see how containerd performs.

Thank you and follow me

If you liked my blog post comment 😀
Also follow me at:

This blog post is an extended version of my book:

https://amzn.to/3Vx6pnt

Python containers for ARM

Sergio Méndez — Tue, 18 Feb 2025 05:34:22 +0000

Hi, this is the beginning of my blog post series called, 30DaysOfIoTEdge, you will learn about how to use Kubernetes, ARM, and container on the Edge, something that you can use to solve problems around Iot and Edge stuff. So, let's start with Day 1 creating a container for Python that runs on ARM.

What you will learn

In this blog post you will learn:

What you need to compile for ARM.
Create a basic container for Python using Flask as a basic API.
Adapt your container to run on ARM devices.

Requirements

Raspberry Pi or ARM instance in the cloud.
Docker installed
Ubuntu >= 22.04

So Let's get started with this post.

Creating Python containers for ARM

1. Install Docker with permission to execute the command without sudo. For this run the following commands:

sudo apt-get update
sudo apt-get install -y docker.io
sudo groupadd docker
sudo usermod -aG docker $USER

This commands install Docker in your machine, then restarts your terminal, in order to run docker without sudo. This is something that you will like to do instead of putting sudo before the docker command every time.

2. Create your Dockerfile
Create the file with the following command:

cat > Dockerfile <<-EOF
FROM python:3-alpine

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

CMD ["ash", "-c", "python main.py"]
EOF

3. Create your main.py
Create the file with the following command:

cat > main.py <<-EOF
from flask import Flask
import os
import socket

app = Flask(__name__)

@app.route('/')
def index():
    return "Hello ARM Container"


if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000), debug=True)
EOF

4. Create the requeriments.txt
Create the file with the following command:

cat > requeriments.txt <<-EOF
flask
EOF

Note: This file includes all the dependencies of libraries using in your code. In this case we just use Flask, the other libraries are by default included.

5. Login into your registry
For this run the following command:

docker login

Enter your user from DockerHub or specify the registry your are using to push your container like ECR, GCR, AZR or Harbor as an open source container or artifact registry.
6. Build and push your container
For this run the following command:

docker buildx build --platform linux/arm64 \
-t <USERNAME>/<CONTAINER_NAME>:<TAG> --push .

Note: --platform specify the platform where the container is going to run. Common platforms used for ARM are linux/arm64 for ARM v8 and, linux/arm/v7 for v7. Also you can use x86_64 for Intel and Nuc devices.

7. Test your container.
For this run the following command:

docker run -it -p 5000:5000 <USERNAME>/<CONTAINER_NAME>:<TAG>

8. Test your API
For this use curl to test the API running:

curl http://<HOST_IP>:5000

It shows the Hello ARM Container

Tricks

In some cases, you can find precompiled packages or wheels for Python. Let's say for example that you are building for a Raspberry Pi device using Raspbian as its operating system. Raspbian uses some specific wheels precompiled for Raspbian but you can use it for another operating system. Why? Sometimes the libraries in Python are not compiled for ARM and when you build the container it detects that the library needs to be compiled for ARM and fails. You can solve it but it's easier to use the Python wheels precompiled for Raspbian. How you can use that wheels, just by running the following command:

RUN pip install --index-url=https://www.piwheels.org/simple --no-cache-dir -r requirements.txt

Instead of

RUN pip install -r requirements.txt

Thank you and follow me

If you liked my blog post comment 😀
Also follow me at:

This blog post is an extender version of my book:

https://amzn.to/3Vx6pnt

My 2023 in review

Sergio Méndez — Tue, 23 Jan 2024 03:31:46 +0000

Hi, you all, this is my very first time writing this kind of post. So, I want to say how was my 2023 in context of tech content, speaking sessions and my tech career in general.

I can summarize it like this:

24 speaking sessions
5 videos in my Youtube channel
3 KCDs
15 Working sessions for our Cloud Native Group.

I also participated in working sessions and created content in:

2 tags tag-environmental-sustainability, we were part of the sustainability week and for higher-ed (a future TAG), just participating to build something around university contents.

I participated in the several events or groups:

Cloud Native Guatemala Chapter
Cloud Native Amsterdam
KCD Colombia
KCD El Salvador
KCD Guatemala
Civo Navigate NA, Tampa
Civo Navigate Europe, London
KubeConNA, Chicago
Sustainability Week Guatemala

My best moments in the year:

I was selected to be a CNCF Ambassador after serveral years
Hosted an in-person KCD with my students
Talked with Bart Farrel about life and things
Talked with Cortney Nickerson at KubeConNA, Chicago
Talked with Ramiro Berrelleza in different events
Christmas breakfast with Cloud Native Guatemala Chapter organizers
Funny moments with Alessadro Civo, Dario Trankitela
Met in person Kunal Kushwaha
Shared in the KCD boot in the KCD about Guatemala in KubeConNA, Chicago
In deep conversation about life with Tiffany Jatcha

The event and moment I loved the most was Cloud Native Amsterdam.

Also, I learned from Bart Farrel, that you are not alone when you have problems, your friends support you, also I have a lot of friends in the ecosystem that loves me.

Now, this year 2024, for me is the year to thing about me, grow up, and explore new things, I want to try to create content by myself, I mean, be my own brand, like a kind of DevRel. I will take the advice of a close friend of mine, that said me about build a community around me. I will try, let's see if I can build that community.

Finally, I want to visit Europe again to be in other events. If I am lucky I would like to be in Japan, but first I have to build that dream, let's see if the happens.

I have a lot of pending videos to upload from 2023, a lot of content coming. So, that was my 2023 in review, what about yours? any 2024 resolutions?

BTW, follow me on Twitter as @sergioarmgpl

See you the next time!

How I became a Linkerd Hero?

Sergio Méndez — Wed, 12 May 2021 21:49:11 +0000

Hi, Dev.to community this is my first post, and I want to share how I became a Linkerd Hero. This is more or less a large story, let me introduce myself first. I am Sergio Méndez. I was born in Guatemala, I represent that part of underrepresented technology groups, actually, I am working as a DevOps Engineer at Yalo, and I am also an Operating Systems professor at USAC, Guatemala.

I remember that this story started when I talked at the 2018 OSCON conference, in that moment I was starting to experiment with Cloud Native technologies, some months before that, I was working for a Telco company here in Guatemala, I was building a tool to create custom chatbots using Kubernetes and OpenFaaS. I was a novice at that time and for sure it wasn’t my best experience talking in a conference, but it was challenging, me giving a talk in English outside my country, who would have imagined. As I mentioned it wasn’t my best experience. After that, I tried to prove to myself that I could do it better, so I was looking for another opportunity.

Next year, influenced by one of the organizers of O'Reilly, the one who pushed me to talk for the first time, I decided to send a talk proposal to KubeConEU 2020, and by my surprise, my talk was selected. My talk was about how to implement canary deployments using OpenFaaS and Linkerd. I remember that the creator of OpenFaaS contacted me and introduced me to the CTO of Buoyant, Buoyant is the company behind Linkerd.

Later 2020 I decided to include Linkerd in the final project of my course, and give the challenge to my students to build a basic distributed system using Kubernetes and Linkerd, I also mentioned this project to the Linkerd people, because I was moving a lot of service meshes topics Linkerd invited me to their Anchor Program to tell other what I was doing part of that was to participate on one of their Linkerd Community calls to share about our project.

At the beginning of January 2021, we presented the project to the Linkerd community with my students with the challenge to speak in another language but it was a really nice experience. I felt that we broke the language gap at that moment. A month later the Linkerd community nominated me to be the Linkerd Hero of February and by my surprise, I won.

Linkerd opened a lot of doors to be visible to the cloud native world. I really appreciate that, I love Linkerd is a really special community.

Things that I Learned:

Be ready when the moment and the opportunity comes
You won’t be successful all the time but you have to persist
Help others around to break technology frontiers
Diversity and inclusion matters
Nothing it's impossible if you are working to build it

And my final thought is:

Contribute is not just coding it could be teaching, speaking and create content for people in other languages, don’t get frustrated

Do you want to see the moment when we present the project with my students?

Here is it:

And if you like the academic side feel free to contribute to our repo:

https://github.com/sergioarmgpl/operating-systems-usac-course

Thanks, Dev.to Community, I hope you enjoy my first post.

Follow me if you liked this post :D.

Twitter: https://twitter.com/sergioarmgpl
Website: https://sergiops.xyz

Thanks to Justin Dorfman of Curiefense for reviewing this post.