Skip to content

Migrating from Workers

Workers were removed from ConfigHub in v0.10.0. Every Worker was deleted, a Worker's credentials are refused, and a process that connected as one can no longer connect. The cub worker commands, the cub-worker image and the Worker parts of the SDK are gone.

What a Worker did is now done by other things:

Each section below replaces one kind of Worker. Where a Worker had an Organization role, give the service account the same role, so it can do what the Worker did. A role cannot be higher than your own, so an Organization admin may need to create the service account.

A Worker running the standard functions

A Worker started with cub worker run (or the cub-worker image) served the standard functions, such as set-image, get-replicas or yq. ConfigHub runs all of these itself, so nothing replaces the Worker. Run functions without --worker, and stop the old process:

cub function do --space my-space --unit my-app get-replicas

A Worker serving functions of your own

A process that served functions of your own becomes a function bot on a Channel, running as a service account. External functions shows the change to main, from worker.NewConnector to channel.NewConnector, and how to deploy it. Point each Trigger and Invocation that named the Worker at the Channel:

cub trigger update --space my-space --patch my-trigger --channel my-space/my-bot --enable
cub invocation update --space my-space --patch my-invocation --channel my-space/my-bot

A Trigger that named a Worker lost it when the Worker was deleted and may have been disabled then; --enable turns it back on.

argobot running as a Worker

argobot 0.1 connected as a Worker, and the cluster usually also had a server Worker (often named server-worker or argo-self) whose ID and secret Argo CD or Flux used to pull from ConfigHub's OCI registry. Both move to one service account: Argo CD pulls with a token of it, and current argobot runs as it with a key and listens on a Channel.

The commands use my-cluster for the Space that holds the cluster's Target and my-target for the Target.

1. Create the service account, its key and its pull token. The key's private half is written to ~/.confighub/keys/argo-my-cluster.jwk. The token is printed once; keep it for step 3.

cub serviceaccount create argo-my-cluster --org-role editor
cub serviceaccount key add argo-my-cluster --generate argo-my-cluster
cub serviceaccount token create argo-my-cluster --description "Argo CD, my-cluster"

2. Create argobot's Channel. argobot claims the Channel to receive events. No role includes Claim, so the Channel grants it to the service account:

docker run --rm ghcr.io/confighub/argobot:v0.2.8 --print-subscriptions \
  | cub channel create argobot --space my-cluster \
      --subscriptions - --permission Claim:serviceaccount:argo-my-cluster

3. Switch Argo CD's pull credential to the token. Find the repo-creds Secret for the ConfigHub registry and set its username and password. Argo CD uses it at its next pull.

kubectl -n argocd get secret -l argocd.argoproj.io/secret-type=repo-creds
kubectl -n argocd patch secret <secret-name> --type merge \
  -p '{"stringData":{"username":"token","password":"<token from step 1>"}}'

Under Flux, set the same username and password in the Secret each OCIRepository names in secretRef.

4. Move argobot to the service account. Add the key to argobot's Secret, then roll the Deployment to the current image with the Channel and Target, dropping the Worker variables. Pausing the rollout makes all of it one change, so kubectl -n argobot rollout undo deploy/argobot reverts it, and the old pod keeps running until the new one is ready.

kubectl -n argobot patch secret argobot-secrets --type merge -p "$(jq -n \
  --arg key "$(cat ~/.confighub/keys/argo-my-cluster.jwk)" \
  '{stringData: {CONFIGHUB_AUTH_PRIVATE_KEY: $key}}')"
kubectl -n argobot rollout pause deploy/argobot
kubectl -n argobot set env deploy/argobot --from=secret/argobot-secrets --keys=CONFIGHUB_AUTH_PRIVATE_KEY
kubectl -n argobot set env deploy/argobot \
  CONFIGHUB_CHANNEL=my-cluster/argobot CONFIGHUB_TARGET=my-cluster/my-target \
  CONFIGHUB_WORKER_ID- CONFIGHUB_WORKER_SECRET-
kubectl -n argobot set image deploy/argobot argobot=ghcr.io/confighub/argobot:v0.2.8
kubectl -n argobot rollout resume deploy/argobot
kubectl -n argobot rollout status deploy/argobot

5. Check. cub channel get argobot --space my-cluster shows argobot holding the Channel, and Argo CD's Applications keep syncing.

A server Worker that Argo CD or Flux pulls with

Without argobot, a cluster usually had only a server Worker (often named server-worker or argo-self), whose ID and secret Argo CD or Flux used to pull from ConfigHub's OCI registry. Its replacement is a service account with the viewer role, which lets it pull every Release in the Organization, and a long-lived token.

1. Create the service account and its token. The token is printed once.

cub serviceaccount create argo-my-cluster --org-role viewer
cub serviceaccount token create argo-my-cluster --description "Argo CD, my-cluster"

2. Switch Argo CD's pull credential to the token. Argo CD uses it at its next pull.

kubectl -n argocd get secret -l argocd.argoproj.io/secret-type=repo-creds
kubectl -n argocd patch secret <secret-name> --type merge \
  -p '{"stringData":{"username":"token","password":"<token from step 1>"}}'

Under Flux, set the same username and password in the Secret each OCIRepository names in secretRef.

To limit the service account to one Target's Releases instead, create it without a role and grant it View and ViewChildren on the Target, as Integrating with GitOps operators describes.

A Worker used as an identity for cub or scripts

A script, a CI job or cub auth login --as-worker that used a Worker's CONFIGHUB_WORKER_ID and CONFIGHUB_WORKER_SECRET moves to a service account with a key. The commands use my-bot for the service account.

Create the service account and its key, and log in with it. The key's private half is written to ~/.confighub/keys/my-bot.jwk.

cub serviceaccount create my-bot --org-role editor
cub serviceaccount key add my-bot --generate my-bot
cub auth login --private-key=my-bot

In CI, put the contents of the key file in CONFIGHUB_AUTH_PRIVATE_KEY, set CONFIGHUB_URL to the server, and run cub auth login --private-key.