I’ve been using Tailscale to connect my personal devices for a while. I have it installed almost everywhere: on my laptop, my phone, my Synology NAS, etc. It is very convenient as it helps me connect to any device, from anywhere. Tailscale adds a virtual interface to your device and manages its own IP address (you’ll understand why this is important in a minute)

Tailscale automatically assigns a unique IP address to each device in your Tailscale network (known as a tailnet). This IP address is known as a Tailscale IP address and comes from the shared address space defined in RFC6598, known as Carrier-Grade NAT (CGNAT).
(source: https://tailscale.com/kb/1015/100.x-addresses)

Today, I’m taking it to the next level: I’d like to install Tailscale alongside one of my application pod and access the web interface my pod exposes, directly from my Tailscale network (aka Tailnet).

The challenge:

I’ve installed Tailscale on the VM hosting my Kubernetes cluster (it’s a 1 node cluster, just for playing). Cool, I can access the VM from any other device. However, what about the web app my pod provides? How can I access it from my Tailnet?

As mentioned before, Tailscale has its own IP addressing, using 100.x.y.z addresses : your devices are assigned an IP from this address space.

Moreover, the network interface Tailscale creates (tailscale0) is not a standard interface and Kubernetes cannot simply expose services through that interface as for any other NodePort. To do so, you need to deploy Tailscale in your Kubernetes cluster.

Let’s do that.

The options:

Tailscale offers several options to connect your cluster to your tailnet:

• Proxy: Tailscale proxies traffic to one of your Kubernetes services. Your tailnet devices can communicate with the service but not with any other Kubernetes resources. Tailscale users can reach the service using the proxy’s name.
• Sidecar: Tailscale runs as a sidecar next to a specific pod in your cluster. It lets you expose that pod on your tailnet without allowing access to any others. Tailscale users can connect to the pod using its name.
• Subnet router: A subnet router deployment exposes your entire cluster network in your tailnet. Your Tailscale devices can connect to any pod or service in your cluster, provided that applicable Kubernetes network policies and Tailscale access controls allow it.

My use-case is to expose a specific pod to my tailnet (my speedtest-tracker app frontend), the “sidecar” option is then enough for my need.
Let’s see how to configure that together.

I invite you to read my other blog about speedtest-tracker. This is the app we are going to work with today.
I’ve been using speedtest-tracker for a while, but the app is only available from within my local network for now. Let’s see how to adapt my app’s deployment definition to add the Tailscale sidecar container.

What we need:

1. An application (that’s my speedtest-tracker app that already exists)
2. To generate an auth key that will be used by the Tailscale service deployed into the cluster
3. A secret with this auth key value in my cluster, for my pod to authenticate to my Tailscale account.
4. A service account, role and role binding to configure RBAC for my deployment ( my pod will use this service account and RBAC permissions to interact with the cluster)
5. Finally, I will add the sidecar container running Tailscale alongside my speedtest-tracker app container

Generate an auth key

First, let’s generate the auth key from my Tailscale account web interface.
This is done under Settings –> Keys –> Generate auth key…

Fill out the form, and make the key reusable. Then configure the device this key applies to as ephemeral (so is your pod).
Copy the key value somewhere as we are going to need it in a moment.

Create a secret

I create my secret, here is my tailscale-secret.yaml file:

apiVersion: v1
kind: Secret
metadata:
  name: tailscale-auth
stringData:
  TS_AUTHKEY: <my key value from previous step>

I apply the configuration to my speedtest namespace:

kubectl apply -f tailscale-secret.yaml -n speedtest

Service account, role and role binding

Next step is to configure RBAC for my Tailscale deployment. I need a service account, a role and role binding. Lucky me, Tailscale doc is well written, all I need is to follow their instructions.

I create a manifest called tailscale-rbac.yaml:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: tailscale

---

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: tailscale
rules:
  - apiGroups: [""]
    resourceNames: ["tailscale-auth"]
    resources: ["secrets"]
    verbs: ["get", "update", "patch"]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tailscale
subjects:
  - kind: ServiceAccount
    name: tailscale
roleRef:
  kind: Role
  name: tailscale
  apiGroup: rbac.authorization.k8s.io

I apply the configuration to my speedtest namespace:

kubectl apply -f tailscale-rbac.yaml -n speedtest

Add the sidecar container to my deployment

Last step is to adapt my existing deployment to add the tailscale sidecar container.

Under the spec section, we need to assign the serviceAccount created previously, to the pod:

serviceAccountName: tailscale

Then I create the sidecar container as per the tailscale documentation

apiVersion: apps/v1
kind: Deployment
metadata:
  name: speedtest-tracker
spec:
  replicas: 1
  revisionHistoryLimit: 0
  selector:
    matchLabels:
      app: speedtest-tracker
  template:
    metadata:
      labels:
        app: speedtest-tracker
    spec:
      serviceAccountName: tailscale  ## <-- Add the Service Account Name
      containers:
        ##### Tailscal sidecar container definition#######
        - name: tailscale-sidecar
          image: ghcr.io/tailscale/tailscale:latest
          env:
            - name: TS_KUBE_SECRET
              value: tailscale-auth
            - name: TS_AUTHKEY
              valueFrom:
                secretKeyRef:
                  name: tailscale-auth
                  key: TS_AUTHKEY
            - name: TS_USERSPACE
              value: "false"
          securityContext:
            capabilities:
              add:
               - NET_ADMIN
        ######################

        - name: speedtest-tracker
          image: lscr.io/linuxserver/speedtest-tracker:latest
          ports:
            - containerPort: 80
          env:
            - name: PUID
              value: "1000"
            - name: PGID
              value: "1000"
            - name: DB_CONNECTION
              value: pgsql
            - name: DB_HOST
              value: postgres
            - name: DB_PORT
              value: "5432"
            - name: DB_DATABASE
              value: speedtest_tracker
            - name: DB_USERNAME
              value: speedy
            - name: DB_PASSWORD
              value: password

          volumeMounts:
            - mountPath: /config
              name: speedtest-tracker
      volumes:
        - name: speedtest-tracker
          persistentVolumeClaim:
            claimName: speedtest-tracker

I apply the configuration to my speedtest namespace:

kubectl apply -f speedtest-tracker.yaml -n speedtest

Quick check, my speedtest-tracker pod is now running with 2 containers inside:

Rancher:~/syno/speedtest # kubectl get pods -n speedtest
NAME                                READY   STATUS    RESTARTS   AGE
postgres-7958dd877c-f4d2l           1/1     Running   0          22h
speedtest-tracker-8975967cd-s2fmc   2/2     Running   0          105m

And that’s it!

I can now access my app from both networks : my local network and my tailnet.

My pod is now seen as a device in my Tailscale network and can communicate with my other machines.

Conclusion

What we’ve done is to turn our Pod into a Tailscale node by injecting a WireGuard interface into the Pod’s shared network namespace, with the help of a tailscale sidecar container. This allows encrypted traffic to flow directly to the app container without Kubernetes Services or Ingress.

This is it, I hope you enjoyed reading this blog and that you learned something new.

If so, drop a like, it’s always appreciated 😉

To go further, please visit the Tailscale official documentation that will take you through all the steps and options to configure your tailnet on Kubernetes:
https://tailscale.com/learn/managing-access-to-kubernetes-with-tailscale#sidecar-deployments

L’article Access your Kubernetes pods via Tailscale using a Sidecar container est apparu en premier sur dbi Blog.

First Day: the workshops

After a meeting at the entrance of the CERN, we went to attend the workshops:

20000 issues sous les mers – Moving Like a Fish in a Tempestuous Sea

A very interesting workshop reproducing a possible real use case:

We are given a Kubernetes infrastructure, we only have one Kubeconfig, we need to discover, debug, and fix the problems on the cluster.

A good exercise very close to real life !

Platform Engineering in the Age of AI: Secure the Software Supply Chain, Empower the Developer

Apart from the somewhat misleading title (nothing about AI in the workshop), a good overview of the possibilities of Openshift to build a self-service catalog, deploy and provision applications.

The visit of the CERN

At the end of the day a visit of one facility of the CERN was organized. For my part, I visited the Antimatter Factory. A great experience to know more about antimatter.

Second Day: the talks

The second day at the CERN auditorium was dedicated to talks.

After the keynote, we followed various talks that allowed us to learn about real life scenario of Kubernetes implementations in different environments, such as public structures, pension funds, banks, etc.

One talk focused on building an AI platform based on Kubernetes, which was very interesting. How to build a scalable and efficient infrastructure for AI workloads and how to scale up pods quickly was a very interesting subject.

Conclusion

Overall, the KCD Suisse Romande was a great event, the location at the CERN was incredible. Both workshops and talks were very interesting and confirmed that Kubernetes is now a key technology in the IT world. For a first edition of the KCD Suisse Romande, it was a great success, and I look forward to the next edition!

L’article Two days at the KCD Suisse Romande est apparu en premier sur dbi Blog.

It turns out that there is a project called Speedtest-tracker, written and maintained by Alex Justesen on GitHub that does just what I was looking for. Behind the scenes, speedtest-tracker uses the official Ookla CLI.

Speedtest Tracker is a self-hosted application that monitors the performance and uptime of your internet connection. Built using Laravel and Speedtest CLI from Ookla®, deployable with Docker.

The cool thing is that Speedtest Tracker is containerized; you can run it anywhere you want! At first, I had installed it as a Docker container on my Synology, but the NAS I own only has 1Gbps Ethernet ports, and my ISP advertises DL/UL speeds of 5 Gbps / 900 Mbps

I have a mini PC that I use for my YaK projects, which embeds a 2.5Gbps Ethernet card. I’d rather use this machine than the NAS. Even though I will not be able to test the full speed my ISP provides, at least I will be able to see if I get near 2.5Gbps, which is already a great download speed.

OK, enough talking, let’s get our hands dirty and let’s deploy Speedtest-tracker!

Your list of ingredients

Here is what you need to add to your recipe:

• A hypervisor, in my case I’m using Proxmox
• A virtual machine (on which I’m using SUSE Linux, but any distro will work just fine)
• A Kubernetes cluster. Keep it simple, install a single node RKE2
• A persistent volume: local-path provisioner does the job

I’m passing these steps here, but you can find them in my other blog dedicated to installing the YaK, if you need.

Everything is well documented on Speedtest tracker web page

There is already a community manifest available for Kubernetes, written and maintained by Maxime Moreillon.

How to install speedtest-tracker?

Installing speedtest tracker is as simple as deploying 2 yaml files:

• 1 for the postgreSQL database
• 1 for the frontend app

The PG database and the application manifests are available here.
All the credit goes to Maxime Moreillon, who wrote these manifests and made them available to the community.
All I had to do was save the files to my “speedtest” folder and adjust them to my context.

localhost:~ # cd speedtest
localhost:~/speedtest # ls -ltrh
total 8.0K
-rw-r--r-- 1 root root 1.1K Jul 29 16:29 postgres.yaml
-rw-r--r-- 1 root root 2.2K Aug  3 18:48 speedtest-tracker.yaml

My Postgres manifest

I haven’t changed a single line from Maxime Moreillon’s code. The manifest includes the PVC definition, the PostgreSQL deployment itself, and a service:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:15.1
          env:
            - name: POSTGRES_PASSWORD
              value: password
            - name: POSTGRES_DB
              value: speedtest_tracker
            - name: POSTGRES_USER
              value: speedy
          volumeMounts:
            - mountPath: /var/lib/postgresql/data
              name: postgres
      volumes:
        - name: postgres
          persistentVolumeClaim:
            claimName: postgres

---
apiVersion: v1
kind: Service
metadata:
  name: postgres
spec:
  ports:
    - port: 5432
  selector:
    app: postgres
  type: ClusterIP

My speedtest-tracker manifest

With a few adjustments from Maxime’s code to fit my needs. It comes with the PVC definition, the application deployment, and the service:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: speedtest-tracker
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: local-path  # Adjust if you're using a different StorageClass

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: speedtest-tracker
spec:
  replicas: 1
  revisionHistoryLimit: 0
  selector:
    matchLabels:
      app: speedtest-tracker
  template:
    metadata:
      labels:
        app: speedtest-tracker
    spec:
      containers:
        - name: speedtest-tracker
          image: lscr.io/linuxserver/speedtest-tracker:latest
          ports:
            - containerPort: 80
          env:
            - name: PUID
              value: "1000"
            - name: PGID
              value: "1000"
            - name: DB_CONNECTION
              value: pgsql
            - name: DB_HOST
              value: postgres
            - name: DB_PORT
              value: "5432"
            - name: DB_DATABASE
              value: speedtest_tracker
            - name: DB_USERNAME
              value: speedy
            - name: DB_PASSWORD
              value: password

########MY PERSONAL ENV VARIABLES########
            - name: APP_NAME
              value: home-speedtest-k8s
            - name: APP_KEY
              value: <generate your own app key>
            - name: DISPLAY_TIMEZONE
              value: Europe/Paris
            - name: SPEEDTEST_SERVERS
              value: "62493"
            - name: SPEEDTEST_SCHEDULE
              value: '*/30 * * * *'
            - name: PUBLIC_DASHBOARD
              value: "true"
#########################################

          volumeMounts:
            - mountPath: /config
              name: speedtest-tracker
      volumes:
        - name: speedtest-tracker
          persistentVolumeClaim:
            claimName: speedtest-tracker

---
apiVersion: v1
kind: Service
metadata:
  name: speedtest-tracker
  labels:
    app: speedtest-tracker
spec:
  selector:
    app: speedtest-tracker
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 80
      nodePort: 30080  # You can change this to any port in the 30000-32767 range

Now, generate your own APP KEY and paste the value in the placeholder in the code above (including the base64: prefix), here is how:

echo -n 'base64:'; openssl rand -base64 32;

And that’s it!
Once your manifests are ready and once you are happy with the environment variables you want (the list of env. variables is available here), you just need to create your namespace on your cluster and apply the configuration:

kubectl create ns speedtest
kubectl apply -f speedtest/postgres.yaml -n speedtest
kubectl apply -f speedtest/speedtest-racker.yaml -n speedtest

After a few seconds, your pods will come up:

localhost:~/speedtest # kubectl get pods -n speedtest
NAME                                 READY   STATUS    RESTARTS        AGE
postgres-6c8499b968-rbwlw            1/1     Running   2 (4d18h ago)   5d21h
speedtest-tracker-7997cbdc8f-64n7c   1/1     Running   0               19h

Enjoy !

If you did things right, you should be able to monitor your internet speed and display the results on a neat UI. In my case, I fire a speedtest every 30 minutes (I know, that’s overkill, but I just wanted to play a bit. I will reduce the frequency to something more reasonable, I promise )

Cool, no?

To go further

I’d love to monitor the full bandwidth my ISP advertises, but I’m limited by my hardware: my router does not support link aggregation, and it only comes with one 10G fiber-optic WAN interface + one 2.5 Gbps and two 1Gbps LAN interfaces. There is no chance I can test the full fiber-optic capacity with this hardware.

In the future, I might buy a switch that supports LACP and configure my router in bridge mode to be able to reach the full WAN bandwidth, or invest in a router that provides more high-speed interfaces. But to be honest, the investment is not really worth it.

One thing I could do however would be to enable HTTPS and add a Let’s Encrypt certificate to secure the connections to my frontend. That’s an improvement I could make soon.

L’article Monitor your ISP’s performance with Speedtest Tracker est apparu en premier sur dbi Blog.

YaK core Multi-Platform open source Automation Tool simplifies the deployment of Ansible playbooks through a clean UI and API. It offers an intuitive interface where users can upload playbooks, configure parameters, and deploy them seamlessly across various platforms, and all managed through a centralized inventory stored in a PostgreSQL database. With YaK Core, developers can focus on writing application code without worrying about infrastructure setup or management.

YaK consists of two parts: YaK Core, which is open source, and YaK Components, which can be installed on top. These YaK Components are platform-agnostic service packages (e.g., PostgreSQL, Oracle DB, MongoDB, Kubernetes, etc.), written in Ansible by experts. They provide essential operational features such as backup, patching, upgrades, and high availability. If you’d like to learn more about the available YaK components, feel free to contact us!

But that’s not all. YaK Core also lets you create your own YaK Components . Once created, your component becomes immediately available for deployment across all platforms supported by YaK Core.

In this blog, I’ll show you how easy it is to create your own YaK Component using Ansible, upload it to YaK Core, and deploy it across any supported platform.

YaK Demo platform provisioning

To get started with YaK Core Multi-Platform open source solution, visit https://yak4all.io and provision your own YaK demo environment (take 5 minutes to be ready).

Build your YaK Component

To build a YaK Component, you need to declare at least the following three files

1. playbooks/create_linux_users.yml
2. manifest.yml
3. yak_variables_specifications/basic_variables_specifications.yml

1. The Ansible Playbook

playbooks/create_linux_users.yml
This file is simply your Ansible playbook, nothing more. The only requirement is that the code uses variables, which will be exposed in the UI for configuration. The example playbook below will create a user and optionally grant them sudo privileges.

---
- name: Create Linux users
  hosts: linux_hosts
  become: true
  gather_facts: true

  tasks:
    - debug:
        var: user

    - name: Create users
      ansible.builtin.user:
        name: "{{ item.username }}"
        create_home: "{{ item.create_home | default(true) }}"
        state: present
      loop: "{{ user }}"

    - name: Add users to sudoers
      community.general.sudoers:
        name: "yak-sudoer-{{ item.username }}"
        user: "{{ item.username }}"
        commands: ALL
        state: present
      loop: "{{ user }}"
      when: item.is_sudoer
        
  post_tasks:
    - name: Update component state
      delegate_to: localhost
      yak.core.yak_component_state_update:
        component_state_name: 'deployed'
...

2. Manifest file

manifest.yml
This file contains the basic information about your component and specifies which playbooks can be executed.

name: linux_users

version:
  major: 1
  minor: 0
  patch: 0

sub_component_types:
  - display_label: Linux users
    name: create_linux_users
    features:
      - display_label: Create Linux users
        name: create_linux_users
        playbook_name: playbooks/create_linux_users.yml

    inventory_maps:
      - group_name: linux_hosts
        group_nicename: Linux hosts
        group_description: Host on which the users will be created
        group_min_hosts: 1
        group_max_hosts: 100
        type: host
        os_type: Linux

3. Variable specification file

yak_variables_specifications/basic_variables_specifications.yml
Now you can define and provide all the specifications for the variables you want to make configurable, with all the required settings .

- variableName: user
  niceName: Users to create
  dataType: array
  children:
    - variableName: username
      niceName: Username
      dataType: string
      mandatory: true
      defaultValue: yak
      isOneOffSetting: false
      usage: Name of the user to create

    - variableName: create_home
      niceName: Create Home directory
      dataType: boolean
      mandatory: true
      defaultValue: true
      isOneOffSetting: false
      usage: Tick the box if you want to create a Home directory for the user (/home/<username>)

    - variableName: is_sudoer
      niceName: Grant sudo privileges
      dataType: boolean
      mandatory: true
      defaultValue: true
      isOneOffSetting: false
      usage: Tick the box if you want to grant "ALL" privileges escalation to the user

That’s it! You now have all the necessary files for your first YaK Component. Next, create a ZIP package and upload it to your deployed YaK Demo environment.

To make things easier, I’ve created a ZIP file that you can upload directly. : create_linux_user.zip

Setup a Server

For this task, simply follow the documentation below up to Step 4: Deploy your server https://dbi-services.gitbook.io/yak-user-doc/introduction/yak-demo

Declare and deploy your Component

You’re now ready to declare and deploy your component!

1. Declare

YaK UI -> Components -> Declare -> Component_type : linux_users -> Save

2 Deploy

YaK UI -> Components -> Select LinuxUser -> Action -> Create Linux User -> Confirm

Conclusion

This component can now be deployed on any cloud platform or integrated on On-Premises environment using the YaK UI, and can also be deployed in parallel on up to 100 servers, as specified in your Manifest file.

With this solution, you can provide your colleagues with an intuitive and efficient way to work with Ansible playbooks, enhancing their overall experience .

For more Information about YaK see the blogs available here : https://www.dbi-services.com/blog/yak

L’article YaK Core – The Holy Grail for Deploying Ansible Code Everywhere est apparu en premier sur dbi Blog.

Today is my first day at the KubeCon 2025 in London. It’s 8 AM, I’m in the lobby of my hotel and I can already hear “HAProxy”, “NGINX”, “Pipeline”, and “Kubernetes” here and there. There is no doubt, I am at the right place.

When I walked to the Excel London, I didn’t know what to expect. The place is just huge. The day has not started, and I already know I should have grabbed another pair of shoes.

To give you an idea, they expect between 12 and 15 thousand people….
I’m starting to realize this event is a one-of-a-kind.

Opening session in the Auditorium, my first thought was: how are they gonna fit all these people in?
Well, the Linux Foundation organizers seem to know what they are doing…
Drum rolls, lights shade, this is not just another IT people gathering, it’s a freaking show.

The tone is set, a few welcome words from the CNCF representatives and we are already talking about LLM. This is not a surprise; Artificial Intelligence is everywhere in this Kubecon.

Christin Yen, CEO and cofounder at Honeycomb tells us about observability and the impact of application development on users. How can AI help improve user experience by monitoring response time and analyzing tons of metadata.

Followed by Vijay Samuel, Architect at Ebay enlightening us on how they are making use of AI and LLM: human comprehension is limited, and the systems we manage have become so complex and so big that sorting of logs is impossible without the help of machine learning to attach a root cause to an alert.

Andrew Randall reminds us how awesome Kubernetes is but also how intimidating it can be for novice users. There is no such thing as a simple “apt-get install kubernetes” command: willing to install a Vanilla Kubernetes? You’d have to figure it out yourself, it’s a steep learning curve before you can even deploy your first cluster.
Based on this observation and willingness to reduce the impact on developers’ productivity, Microsoft has announced a new project called Headlamp, designed to make Kubernetes easier to use and, above all, easier to adopt. It comes with an in-cluster web portal (a k8s dashboard), a unified UI for multiple remote clusters, and a “Kubernetes Desktop”.
Pretty much like what our SUSE friends have accomplished with the great SUSE Rancher ;-). Let’s see!

Greg Kroah-Hartmann (Linux maintainer, Linux Foundation) attended to discuss the Linux Kernel and how they are integrating Rust and C into it.
Today’s Linux kernel contains 34 million lines of C, and about 25000 lines of Rust code.
Rust brings more safety as it allows the kernel to “crash safely” when an error occurs and makes the code more “maintainable”. Rust can prevent a huge majority of security issues at build time, not at review time: code is simpler, reviewing is easier, fewer bugs, more fun!

Closing the keynote with a great use-case of AI, I loved it because it really demonstrated how technology can improve people’s lives and I truly believe this is what technology should be about: moving science forward, promoting education, and closing the gap between our societies. Indeed, Rob Koch from Slalom explained how AI, combined with Kubernetes, is revolutionizing the world of deaf people with AI-driven sign language interpretation and recognition.
He explained the challenges they’re facing as it is overly complicated for a machine to capture the movement of a hand when hand-signing.
Making the difference between a “P” and a “Q” is a good example of this complexity as these 2 signs are very similar in sign language and capturing the right sign highly depends on the camera’s angle of view: perspective and scaling are important. AI models need a phenomenal amount of authentic data and scenarios to be trained. Moreover, machines need to “understand” the context of the conversation, not only words.
Kubernetes is ideal for that as it provides scaling capabilities, resource optimization for video processing, and task repeatability.

End of the keynote, it’s time for me to wander the corridors of the KubeCon and visit the booths.
All the big tech players are there of course…. but dozens of open source projects that we use daily within our infrastructures are represented and have a booth. It’s great to see that Open Source solutions are everywhere and everybody’s using them. I feel like a kid in a candy shop!

Alright, let’s “get some swag”. There are enough tee shirts, stickers, and other cool gadgets at this KubeCon for me to fill a massive suitcase, but I will try to be reasonable. Everyone has something to propose: hats, backpacks, tote bags, stickers, keyrings, lego sets. It’s too tempting, let’s see how long I can refrain from taking it all.

Visiting the RedHat stand:
I met with Stevan Le Meur, a developer at RedHat and we had a great exchange on what RedHat does with regards to Kubernetes. Stevan specializes in bootable containers and invited me to take a closer look at what bootc and podman can achieve.
The occasion for me to talk about our YaK project. Why not consider bootable containers with the YaK in a future release?
That’s clearly a topic we can discuss during our next roadmap meeting, let’s see if we add it to the list of upcoming features…

Walking down the hallway, I passed by the Linux Foundation booth where the topic being discussed was the certification exams.
For those interested in the CKA (Certified Kubernetes Administrator) exam, know that a new version has just been released.
This new version is a bit more difficult than the previous one, the passing score is still 66% and the format has not changed: it is still a proctored hands-on lab exam.

Good resources to practice before the exam: killer.sh (https://killer.sh/) , and the great environments and training material provided by KodeKloud (https://kodekloud.com/)

That’s enough reading for today.

L’article My journey to KubeCon 2025 est apparu en premier sur dbi Blog.

However, the diversification of processor architectures adds a new level of complexity to the creation of container images. Indeed, the construction has to cope with different instruction sets.

Docker buildx, the solution for building multi-architecture images

For the YaK project, we want to make amd64 (x86) and arm64 images available using GitLab CI/CD.

In order to create a build compatible with several architectures, I had to use “docker buildx” in my .gitlab-ci.yml file:

build:
  image: docker:latest
  stage: build
  services:
    - docker:dind
  before_script:
    - docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
    - docker buildx create --name yakbuilder --use
  script:
    - docker buildx build --pull --builder=yakbuilder --platform linux/amd64,linux/arm64 -t [IMG]:[TAG] --push .

How it works:

• In the "before_script" section , I initialize a QEMU container to emulate ARM architecture and to create a buildx context using the QEMU container
• In the "script" section itself, instead of a simple “docker build”, I use the "docker buildx build" command
• I also pass the buildx context created in the "before_script" with the --builder flag
• Finally, I add the list of architectures required for the build with the --platform flag

Build Result

With this method, the build is slower. That’s normal as several images are created (one per architecture) instead of just one.

The result can be seen in the GitLab container registry:

Now, below the image tag, a small “index” label is shown. This refers to the fact that several images are available for this tag. During the image pull, the container engine will choose the image version corresponding to its architecture.

Conclusion

With buildx and QEMU in GitLab CI/CD, building multi-architecture images is easy. You can manage different processor architectures and meet the needs of a wide range of users and ensure the compatibility of your container images.

L’article Building multi-architecture images with GitLab CI/CD est apparu en premier sur dbi Blog.

Step 1: Backup AWX on the old infrastructure

To back up AWX on the old infrastructure, we’ll use the AWXBackup resource provided by the AWX Operator. This will capture all necessary configurations, including credentials, job templates, and database data.

• Create the AWXBackup resource

apiVersion: awx.ansible.com/v1beta1
kind: AWXBackup
metadata:
  name: awx-backup
  namespace: <namespace-awx>
spec:
  deployment_name: <awx-instance-name>

• Apply the backup configuration

kubectl apply -f awxbackup.yaml

• Verify the backup
  Check the status of the AWXBackup resource to ensure the backup is complete

kubectl get awxbackup -n <namespace-awx>

• Access the backup data
  AWXBackup creates a PVC to store the backup data. We need to retrieve it.

kubectl get pvc -n <namespace-awx>

• Mount the backup PVC
  Create a temporary pod to access the backup files

apiVersion: v1
kind: Pod
metadata:
  name: awx-backup-access
  namespace: <namespace-awx>
spec:
  containers:
  - name: backup-container
    image: busybox:latest
    command: ["/bin/sh", "-c", "sleep 3600"]
    volumeMounts:
    - mountPath: /backup-data
      name: awx-backup-pvc
  volumes:
  - name: awx-backup-pvc
    persistentVolumeClaim:
      claimName: <awx-backup-pvc>

• Compress the backup
  Once inside the pod, go to the backup directory and archive the latest directory

kubectl exec -it awx-backup-access -n <namespace-awx> -- /bin/sh
cd /backup-data
ls -l
## Find the latest directory
tar -czvf /awx_backup.tar.gz <latest-directory>

• Copy the archive locally
  Use kubectl cp to copy the archive from the pod to your local machine

kubectl cp <namespace-awx>/awx-backup-access:/backup-data/awx_backup.tar.gz ./awx_backup.tar.gz

• Clean up the temporary pod
  Once the backup is copied, delete the temporary pod

kubectl delete pod awx-backup-access -n <namespace-awx>

• Recover the decryption key for secret keys

kubectl get secrets -n <namespace-awx> <awx-instance-name>-secret-key -o jsonpath='{.data.secret_key}' && echo;

Save the base 64 encrypted key, we will need it for during the restoring step.

Step 2: Setup the new AWX instance

On the new infrastructure, we first need to install AWX via the AWX Operator.

• Install the AWX Operator
  For this step follow the official documentation of AWX Operator
  Maybe you will need to deploy AWX using a local repository, you can read my other article: Deploy awx-operator with Helm using images from a local registry

• Verify the AWX deployment
  Check that the new AWX instance is up and running

kubectl get awx -n <new-namespace-awx>

Step 3: Backup AWX on the new infrastructure

Next, we need to create an AWXBackup on the new infrastructure.

• Create an AWXBackup for the backup data
  Create the awxbackup.yaml file:

apiVersion: awx.ansible.com/v1beta1
kind: AWXBackup
metadata:
  name: awx-backup-migration
  namespace: <namespace-awx>
spec:
  deployment_name: <awx-instance-name>

• Apply the backup configuration

kubectl apply -f awxbackup.yaml

• Verify the backup
  Check the status of the AWXBackup resource to ensure the backup is complete

kubectl get awxbackup -n <namespace-awx>

• Identify the backup PVC

kubectl get pvc -n <namespace-awx>

Step 4: Transfer and restore the backup on the new infrastructure

Now that the new AWX is set up, we’ll transfer the backup data and restore it.

• Transfer the backup archive
  Copy the awx_backup.tar.gz file to the new infrastructure by uploading it to the new backup PVC using a temporary pod

• Create a temporary pod to restore data
  Create the awx-restore-access.yaml file

apiVersion: v1
kind: Pod
metadata:
  name: awx-backup-restore
  namespace: <new-namespace-awx>
spec:
  containers:
  - name: restore-container
    image: busybox:latest
    command: ["/bin/sh", "-c", "sleep 3600"]
    volumeMounts:
    - mountPath: /backup-data
      name: awx-backup-pvc
  volumes:
  - name: awx-backup-pvc
    persistentVolumeClaim:
      claimName: <pvc-for-awx-backup>

kubectl apply -f awx-restore-access.yaml

• Use kubectl cp to upload the archive to the pod

kubectl cp ./awx-backup-migration.tar.gz <namespace-awx>/awx-restore-access:/awx_backup.tar.gz

• Replace the data from archive
  Inside the pod, extract the archive

kubectl exec -it awx-backup-restore -n <new-namespace-awx> -- /bin/sh
cd /backup-data
ls -l
## Find the latest directory

rm -rf /backup-data/<latest-backup-directory>/{tower.db,awx-objects}
cd
tar -xzvf /awx_backup.tar.gz

cp backup-data/<backup-directory-from-tar.gz>/tower.db /backup-data/<latest-backup-directory>/.
cp backup-data/<backup-directory-from-tar.gz>/awx-objects /backup-data/<latest-backup-directory>/.

vi /backup-data/<latest-backup-directory>/secret.yml
## Replace the value of the variable
## secrets:
##   secretKeySecret:
##     data: {secret_key: ###insert here the base64 of the decryption key recover at the end of the Step 1### }

• Create the AWXRestore resource
  Create an AWXRestore resource to apply the backup

apiVersion: awx.ansible.com/v1beta1
kind: AWXRestore
metadata:
  name: awx-backup-restore
  namespace: <new-namespace-awx>
spec:
  deployment_name: <awx-instance-name>
  backup_name: awx-backup-migration
  no_log: false
  force_drop_db: true

• Apply the AWXRestore

kubectl apply -f awxrestore.yaml

• Monitor the restoration
  Ensure the restoration completes successfully

kubectl get awxrestore -n <new-namespace-awx>

Step 5: Log in to the new infrastructure AWX

• You can log in as admin (the password will be that of the old infrastructure)
• Explore the various AWX resources and check that everything has been migrated correctly
• Run a template job to validate correct operation

Conclusion

By following this procedure, we’ve successfully migrated an AWX instance across two isolated Kubernetes clusters while maintaining full fidelity of the AWX credentials and configurations.

L’article Migrating AWX from one Kubernetes cluster to another: A custom approach est apparu en premier sur dbi Blog.

In this blog, I will share with you how to do the installation of this solution step by step. Let’s remember the architecture.

Deploy kubernetes Plug-in

Firstly, download the Kubernetes Plugin, download the version 2.0.00 from the Kubernetes plug-in download page in the Electronic Product Distribution site.

Once downloaded, publish the plug-in by putting the zip file in the following location:

$HOME_CTM/ctm_em/AUTO_DEPLOY

Generate an API Token

Basically, the API Token will be used later in the next step. In fact, we need to set up access to Control-M to register the Control-M/Agents, for sure, this step should be done by a Control-M Administrator.

I assume that you know what is an API Token, and how to generate it, below are the steps quickly.

To generate the API Token, go to the Control-M UI -> Configuration, from the drop-down list, select API Tokens.

The API Token tab appears, click Add Token.

To generate the API Token, fill the following:

• The Token Name field.
• The Roles field, remove or select the roles that you want to associate with the API Token (by default all roles are selected, which is not recommended).
• Expiration Date, select Indefinitely from the drop-down list.

Click on Generate button.

Prepare the Control-M Agent deployment

I recommend to deploy the agent using the Helm shared by BMC! It is easy to configure and to maintain in a Kubernetes cluster.

First of all, add a repository named controlm to contain the helm charts of the Control-M/Agent that is obtained from the Control-M Repository by running the following:

helm repo add controlm https://controlm-charts.s3.us-west-2.amazonaws.com/

Then, ensure that the Control-M repository is listed as one of your repositories by running the following command line:

helm repo list

You can also list the charts within the new controlm repo by running the following command:

helm search repo controlm

Create the namespace, by executing the following:

kubectl create namespace ctmagt

Control-M Agent deployment

To deploy the Control-M Agent you should execute the Helm Install inside your kubernetes cluster:

helm install ctm-dbi controlm/controlm-agent --version 9.21.200 \
--set server.name=dbitest --set server.host=dbitest --set server.port=7005 --set server.ip=XX.XX.XX.XX \
--set api.endpoint=https://dbitest.x.com:8446/automation-api \
--set api.token=b2XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX== \
--set pvc.storageClass=dbistorage

Adapt the command line to your environment!

Check the pod status on the namespace (ctmagt) just created, once the agents pods are ready, check if they appear in Control-M -> Configuration.

By default, two pods should be created, two agents deployed. Sometimes agents are not available directly, don’t hesitate to disable and enable them.

Conclusion

Finally, we have two Control-M agents deployed on Kubernetes.

In the next blog we will see how to create the connection profile, and how to create Control-M jobs to execute Kubernetes jobs.

L’article Control-M for Kubernetes – Installation est apparu en premier sur dbi Blog.

To implement Control-M for Kubernetes you will need to verify and prepare some prerequisites, like check access, compatibility with OS, persistent storage, memory, firewall, aso.

The compatibility between Control-M components has been shown in the previous blog.

Access

First of all, the following access should be delivered to the expert(s) to allow a smooth implementation of Control-M for Kubernetes:

• Full admin access to Control-M UI
• Access on the servers hosting the Control-M Server and Control-M EM
• Sudo to Control-M EM user, and Control-M/Server user
• Access to OpenShift or Kubernetes cluster
• A valid account to access BMC Support Central / Electronic Product Distribution to download Control-M plugins.

Compatibility

Additionally to the Control-M components compatibility, the Control-M Automation API Command Line Interface (CLI) will not be available on the following platforms as they do not support a secure version of Node.js:

• Amazon Linux 2
• SUSE Linux 12
• Red Hat 7
• Oracle Linux 7
• CentOS 7

Please be sure that you are on a version compatible with the Control-M Automation API CLI.

Persistent Storage

Prepare a persistent Storage that will be used by Control-M Agents for storage on OpenShift or Kubernetes cluster. Basically, the persistent volume ensures that job data and Agent state are kept during pod restarts.

BMC recommends that you run multiple Agents on separate nodes in the namespace. The default is two Agents.

To support multiple Agents, the storage class (and underlying storage technology) must support ReadWriteMany access mode. The recommended storage size is minimum 5Gi per agent (by default 10Gi).

If NFS Storage Class is used, ensure that the UID and GID, which are Storage Class parameters for dynamic provisioning, are set to the following values:

• UID=1000  
• GID=0

Memory

By default, there could be some limitation in your cluster, please review the limitations on pods/containers memory.

For example, via the OpenShift console, adapt the maximum memory authorized to allow 2Gi of memory, which is the default value of Helm Control-M Agent installation.

Firewall

Some rules need to be configured on Firewall level, to authorize the agent to reach out to Control-M. The list of ports depends on your organization, in mine the ports opened where 7005-7015 + 13075.

There is no need to open the Firewall from server to agent, or to configure any ingress, as it uses the cluster API entry point.

When all prerequisites are ready, you can move forward to publish Plug-In, get the API Token, prepare and deploy the Control-M agent on Kubernetes. These steps will be shared in the next blog so stay connected

For further reading, please find all blogs around Control-M, and Kubernetes.

L’article Control-M for Kubernetes – Preparation est apparu en premier sur dbi Blog.

Control-M for Kubernetes enables you to execute Control-M job(s) to run one or more pods to completion in a Kubernetes cluster. This enables you to integrate Control-M capabilities, such as advanced scheduling criteria, status monitoring, and SLA management.

In fact, my story with Control-M began before Kubernetes existed, today, as a Control-M and Kubernetes expert I will be able to help you to understand and implement Control-M for Kubernetes. This first blog will be more a quick overview on these technologies and understand the implementation.

To be honest, you will need at least intermediate level on Control-M and Kubernetes to implement smoothly this solution. If you want to know more about Docker and Kubernetes, I would recommend this training.

Control-M Overview

Control-M is a workload automation solution that enables you to automate the scheduling and processing the business workflows across various platforms and applications from a single point of control. Nowadays, those platforms and application could be on VM, Kubernetes cluster, Cloud, etc.

Today, Control-M allow you to execute jobs in almost every platform, but what is a job?

A job is an execution unit, each job needs specific run information to be executed, such as scheduling criteria, post processing actions, and also job dependencies as shown in the following:

On “legacy” systems, a job could be a script or command, that is executed at the operating system level. On Kubernetes, a job take another role, which allow you at the end to deploy pods in Kubernetes. Let’s get a quick overview on Kubernetes and understand pods

Kubernetes Overview

Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. The smallest unit of a Kubernetes application is a pod!

A Kubernetes pod is a collection of one or more Linux containers. Any given pod can be composed of multiple, tightly coupled containers or just a single container.

Control-M for Kubernetes Overview

Now, we understood Control-M jobs and Kubernetes pods, let see how those will be connected.

The following diagram demonstrates how the components of Control-M for Kubernetes are incorporated into a Kubernetes cluster and how they enable you to run one or more pods to completion.

In this example, two Control-M/Agents are deployed as cluster pods.

This setup has the following main features:

• The Agent pods run as a StatefulSet, so that the hostname is identified consistently across pod restarts. This enables Control-M/Server to identify the Control-M/Agent continuously and consistently.
• Agent pods use a persistent volume, so that job data and the Control-M/Agent state are kept during pod restarts.
• The Agents belong to a host group, to ensure high availability and load balancing between the Agents.
• Agent to Server communication is set up as a persistent connection that is initiated by the Agent. This prevents the exposure of the Kubernetes cluster to outside connections.
• The Kubernetes plug-in adds a Kubernetes-type job to Control-M, which enables you to run one or more pods to completion in the Application namespace.

But how it works? which component allow us to create a pod inside Kubernetes?

In fact, it is mainly the role of the plug-in, which is responsible for the following stages in the execution of the Kubernetes-type job in Control-M:

• Starts a Kubernetes job entity that runs one or more Application pods in the Application namespace in the Kubernetes cluster.
• From Control-M, monitors the status of the job in Kubernetes until it ends when the Application pods finish running.
• Captures the pod logs for display in the Control-M job output.
• Deletes the Kubernetes job entity to free cluster resources.

Compatibility

Kubernetes

Control-M for Kubernetes is a generic solution for all Kubernetes-based container platforms. The following platforms were tested by BMC:

• RedHat OpenShift
• Amazon Elastic Kubernetes Service (EKS)
• Azure Kubernetes Service (AKS)

Supported versions of Kubernetes: 1.26-1.29

Control-M

Before any action on your system, please insure that you have at least the following versions:

Take a look on the versions that should be installed to implement Control-M for Kubernetes:

Conclusion

We saw together what is Control-M, OpenShift, a quick overview on how Control-M for Kubernetes will be installed, how it will work in general, and the compatibility between all versions!

In the next blog, we will start the implementation of Control-M for Kubernetes.

In the meantime, to enrich your knowledge and be ready for the next step, here are some dbi services blogs around Control-M and Kubernetes.

L’article Control-M for Kubernetes – Overview est apparu en premier sur dbi Blog.