Alternative Registration Agent

A custom agent built on the eclipse-cfm/cfm framework. It connects to a NATS message broker, listens for orchestration tasks of type registration-activity, and processes alternative registration deployments.

The purpose of this is to show how to replace the default registration agent with a custom one. Note that it is currently not possible to run two agents with the same activity type.

Once this agent is deployed, the default registration agent should be removed to avoid race conditions.

Note that this is just for demonstration purposes and does not have any practical use or value!

TL;DR – how to deploy

Perform the following steps in sequence, assuming you have JAD up and running:

docker build -t reg-agent:latest .
kind load docker-image reg-agent:latest --name jad
kubectl apply -f agent.registration.yaml

The agent doesn't actually do anything, other than printing a log line when it receives a task.

How it works

The agent is structured around three layers:

• cmd/server/main.go — entry point. Starts the agent and blocks until a shutdown signal (SIGTERM/SIGINT) is received.
• launcher/launcher.go — wires up the CFM NATS agent with its configuration, resolves dependencies (HTTP client), and hands control to the framework.
• activity/activity.go — implements the business logic. On ProcessDeploy, it logs the activity's OID and returns a completed result. ProcessDispose is a no-op.

The agent registers itself on NATS under the service name cfm.agent.registration and handles activities of type registration-activity.

Configuration

The agent reads its configuration from a file named agent.registration.env (YAML) mounted at /etc/appname/ in Kubernetes. The following keys are supported:

Key	Description	Example
uri	NATS server URI	nats://localhost:4222
bucket	NATS JetStream bucket name	cfm-bucket
stream	NATS JetStream stream name	cfm-stream

Building the Docker image

The Dockerfile uses a two-stage build: a Go builder stage compiles the binary, and a distroless runtime image runs it.

docker build -t reg-agent:latest .

To verify that the image was created:

docker images reg-agent

Deploying to Kubernetes

The file agent.registration.yaml contains a Deployment and a ConfigMap for the edc-v namespace. This namespace was already created by JAD.

Prerequisites:

• The edc-v namespace exists in the cluster.
• A telemetry-config ConfigMap is already present in the namespace (created by JAD).
• A NATS instance is reachable at nats.edc-v.svc.cluster.local:4222.
• The image reg-agent:latest is available to the cluster (e.g. loaded into a local registry or KinD).

Loading the image into a local cluster (KinD example):

kind load docker-image reg-agent:latest --name jad

Apply the manifest:

kubectl apply -f agent.registration.yaml

Verify the deployment:

kubectl -n edc-v get pods -l app=cfm-registration-agent
kubectl -n edc-v logs -l app=cfm-registration-agent

Registering the agent with the orchestrator

This is not necessary, because the activity type registration-activity is already registered by the orchestrator. However, it is not possible to run multiple agents with the same activity type in parallel. To avoid any race conditions, the existing registration-agent should be removed from the cluster before deploying this alternative agent.