Automate Skupper networks seamlessly with Ansible

June 2, 2025
Fernando Giorgetti
Related topics:
Automation and managementHybrid CloudIntegrationKubernetes
Related products:
Red Hat Service Interconnect

Skupper version 2.0 has landed and it's bringing a shiny new Ansible collection with it, now available on Ansible Galaxy.

This isn't just another update, it's a toolkit that empowers you to define and manage Skupper networks with ease, no matter where they run—Kubernetes, Podman, Docker, or bare-metal Linux.

Declarative power at your fingertips

Skupper 2.0 redefines how virtual application networks (VANs) come to life. At its core is a sleek, declarative approach powered by a fresh set of Kubernetes Custom Resource Definitions (CRDs). Think of it as a blueprint for your network: you describe what you want, and Skupper makes it happen.

These CRDs aren't just for Kubernetes users. They work just as seamlessly outside the Kubernetes ecosystem, delivering a unified, platform-agnostic way to declare and deploy your Skupper network.

Linking sites

To build a VAN across multiple Skupper sites, you have to generate an AccessToken from one site—ideally a public or accessible hub—and share it with another.

That token is the golden key that locks the sites into the same network, forging a secure, reliable mutual transport layer security (mTLS) Skupper link to the VAN.

Although this process is quite simple and easy to perform manually, when your environment scales, you will need some sort of automation to help you keep your VAN linked and resources updated.

New Ansible collection

The skupper.v2 Ansible collection introduces the final components needed to define your entire VAN in a scalable and streamlined way, saving significant time and ensuring reliable, consistent VAN configurations across all your sites.

Hands-on with a Skupper VAN

In order to demonstrate its power, we are going to create a VAN that connects a simple front-end application that runs on a local minikube cluster with a back-end microservice running on another namespace within the same minikube cluster.

Note

This is just a minimal scenario for an easy and local evaluation, which is why we are running the two applications within the same cluster. It is based on Skupper's Hello World Example, shown in Figure 1. But these workloads can also be deployed across multiple, independent clusters.

Hello World scenario used in this example
Figure 1: Skupper Hello World Example configuration.

Prerequisites

For this scenario, you will need:

ansible-galaxy collection install skupper.v2
python -m pip install kubernetes PyYAML

How it works

The goal here is to demonstrate how to set up a Skupper network using Ansible in order to connect Kubernetes applications that are initially unable to reach each other.

Here is the playbook.yaml content that we will use for that:

---
- name: Skupper V2 Hello World Example using Ansible
  hosts: localhost
  connection: local
  tasks:
    - name: Create Kubernetes namespaces west and east
      kubernetes.core.k8s:
        name: "{{ item }}"
        api_version: v1
        kind: Namespace
        state: present
        kubeconfig: "{{ lookup('env', 'KUBECONFIG') }}"
      loop:
        - west
        - east
    - name: Install cluster scoped Skupper 2.0.0 into Kubernetes
      kubernetes.core.k8s:
        state: present
        definition: "{{ lookup('url', 'https://github.com/skupperproject/skupper/releases/download/2.0.0/skupper-cluster-scope.yaml', split_lines=False) }}"
        kubeconfig: "{{ lookup('env', 'KUBECONFIG') }}"
    - name: Create resources on west namespace
      skupper.v2.resource:
        path: "{{ item }}"
        namespace: west
        kubeconfig: "{{ lookup('env', 'KUBECONFIG') }}"
      loop:
        - https://raw.githubusercontent.com/skupperproject/skupper-example-yaml/refs/heads/v2/west/site.yaml
        - https://raw.githubusercontent.com/skupperproject/skupper-example-yaml/refs/heads/v2/west/listener.yaml
        - https://raw.githubusercontent.com/skupperproject/skupper-example-yaml/refs/heads/v2/west/frontend.yaml
    - name: Create resources on east namespace
      skupper.v2.resource:
        path: "{{ item }}"
        namespace: east
        kubeconfig: "{{ lookup('env', 'KUBECONFIG') }}"
      loop:
        - https://raw.githubusercontent.com/skupperproject/skupper-example-yaml/refs/heads/v2/east/site.yaml
        - https://raw.githubusercontent.com/skupperproject/skupper-example-yaml/refs/heads/v2/east/connector.yaml
        - https://raw.githubusercontent.com/skupperproject/skupper-example-yaml/refs/heads/v2/east/backend.yaml
    - name: Generate an AccessToken to the west namespace
      skupper.v2.token:
        name: west-grant
        namespace: west
        kubeconfig: "{{ lookup('env', 'KUBECONFIG') }}"
      register: result
    
    - name: Create AccessToken on east namespace to establish a link to the west site
      skupper.v2.resource:
        def: "{{ result.token }}"
        namespace: east
        kubeconfig: "{{ lookup('env', 'KUBECONFIG') }}"

Important

This playbook relies on the KUBECONFIG environment variable to be properly set.

Here is a breakdown of the tasks performed by the playbook.yaml:

  1. Create west and east namespaces.
  2. Install Skupper 2.0.0 at cluster scope (the operator runs in the skupper namespace).
  3. Create the Skupper and workload resources on west namespace.
  4. Create the Skupper and workload resources on east namespace.
  5. Generate an AccessToken to the west namespace.
  6. Create AccessToken on east namespace to establish a Link to the west site.

Important

Steps 5 and 6 solve the scalability issue mentioned above when linking sites to form your VAN.

Note

In this example, we're using a single playbook, assuming the Ansible control node can access both the west and east sites. However, this won't always be the case. You can adapt it as needed for flexibility, such as by using inventory files to define the hosts (representing your clusters or namespaces) or groups you’ll manage through your playbooks from a specific control node.

 

Run the example

Follow these steps to run the example scenario:

  1. Open a terminal and set the KUBECONFIG environment variable to make sure you’re using the appropriate Kubernetes cluster.

Warning

This example will create and update workloads within 3 namespaces on your Kubernetes cluster:

  • skupper
  • west
  • east

In case any of these namespaces exist in your cluster, do not proceed to avoid impacts to running applications.

  1. Save the playbook.yaml above to an appropriate location in your file system.

  2. Run the Ansible playbook:

    ansible-playbook -i localhost, playbook.yaml

  3. Verify that the front-end application is working:

    kubectl -n west port-forward deployment/frontend 8080
  4. Open your browser and go to http://localhost:8080.
  5. Test the front-end application.

To clean things up, you can delete the: west, east, and skupper namespaces:

kubectl delete namespace west east skupper

Summary

Skupper simplifies the connection of your applications using secure mTLS links between Skupper sites, eliminating the need for network modifications.

This new version standardizes the virtual application network definition, enabling you to declare your VAN in advance, precisely specifying what is exposed internally within the VAN and where each workload will be consumed.

The skupper.v2 Ansible collection streamlines the definition of Skupper resources, regardless of the target platform for your Skupper site, offering a highly convenient mechanism to link sites—regardless of VAN size— while reducing significant effort and maintaining consistency across your VAN.