Skip to main content

Platform Images

The platform is distributed as container images from a source registry. You mirror those images into your own registry (the one your Kubernetes cluster pulls from), then point the Helm chart at it with global.imageRegistry. The target can be any standard OCI registry, for example Amazon ECR, Azure Container Registry, Google Artifact Registry, Harbor, or an on-prem registry.

The source registry is a standard OCI registry, so you authenticate with a plain docker login and copy with any standard tool (docker, skopeo, crane). No cloud provider CLI or account is required to pull, which matters when your clusters do not run on the same cloud as the source.

You mirror once per release. Your cluster then pulls only from your own registry, with no runtime dependency on the source.

Populating your own registry with an eager one-time mirror, the flow this page describes, is how platform images are distributed.

What Connamara provides

ItemPurpose
Source registry hostWhere images are pulled from for the mirror step.
Image list and release tagThe repositories to mirror and the version tag to deploy.
Pull tokenA read-only token to authenticate to the source registry for the one-time mirror.

Images to mirror for a runtime deployment:

ImageRole
conncentric/orchestratorControl plane
conncentric/adapterData plane
conncentric/portalWeb UI
conncentric/essentials-distributionInstaller (applies the base configuration)

The conncentric/sdk image is only needed if you build custom plugins; it is not part of a runtime deployment.

Step 1: Authenticate

Log in to the source registry with the token Connamara provided, and to your own target registry with its normal credentials. Use docker, skopeo, or crane:

echo "<pull-token>" | skopeo login --username <username> --password-stdin <source-registry-host>

docker login <source-registry-host> and crane auth login <source-registry-host> take the same token. Because the source speaks standard OCI, this is the only login step: there is no cloud CLI token exchange.

Step 2: Mirror the images into your registry

Copy each image from the source to your registry, preserving the tag.

When to use which tool: skopeo and crane copy registry-to-registry without a local Docker daemon (best for CI pipelines). docker pull/tag/push is fine on a workstation that already runs Docker.

SRC=<source-registry-host> # e.g. ghcr.io/connamara
DST=<your-registry-host> # e.g. myacr.azurecr.io, or <region>-docker.pkg.dev/<project>
TAG=<release-tag> # e.g. 1.4.0

for img in orchestrator adapter portal essentials-distribution; do
skopeo copy --all \
"docker://$SRC/conncentric/$img:$TAG" \
"docker://$DST/conncentric/$img:$TAG"
done

crane equivalent: crane copy "$SRC/conncentric/$img:$TAG" "$DST/conncentric/$img:$TAG".

The Helm chart is published as an OCI artifact alongside the images. Copy it the same way:

skopeo copy --all \
"docker://$SRC/conncentric/charts/conncentric:$TAG" \
"docker://$DST/conncentric/charts/conncentric:$TAG"

Before deploying, confirm an image landed in your registry at the expected tag:

skopeo inspect "docker://$DST/conncentric/orchestrator:$TAG"

Step 3: Create the image pull secret

Your cluster needs credentials to pull from your registry. Create a pull secret in the target namespace:

kubectl create secret docker-registry conncentric-pull \
--docker-server=<your-registry-host> \
--docker-username=<user> \
--docker-password=<pass> \
-n conncentric

Then reference it from your Helm values so every pod mounts it:

global:
imagePullSecrets:
- conncentric-pull # a Secret name (string), not a { name: ... } object

Without this, the images exist in your registry but the cluster cannot authenticate to pull them, and pods stay in ImagePullBackOff.

Step 4: Point the chart at your registry

Set the registry to yours and pin the release tag in your Helm values:

global:
imageRegistry: "<your-registry-host>"
orchestrator: { image: { tag: "<release-tag>" } }
adapter: { image: { tag: "<release-tag>" } }
portal: { image: { tag: "<release-tag>" } }
installer: { image: { tag: "<release-tag>" } }

Then deploy following the Production Deployment Runbook.

See also