Skip to content

Quick start

This guide installs the Sites platform into an existing Kubernetes cluster. It assumes that cluster access, storage, routing, and external secrets are ready. Read cluster prerequisites before a production install.

1. Select the release and namespace

Choose the chart release you have approved, then create an environment values file. Review the chart defaults with helm show values:

CHART_VERSION="2.7.1" # Replace with the release you have approved.
helm show values oci://eccr.ecmwf.int/sites-oss/ecmwf-sites \
  --version "${CHART_VERSION}"

Save the required overrides in a values file outside the repository. Render the chart with that file and review the output before installation:

helm template sites oci://eccr.ecmwf.int/sites-oss/ecmwf-sites \
  --version "${CHART_VERSION}" \
  -f /secure/path/values.yaml -n sites-stage

Check the public host, TLS Secret, storage classes, NetworkPolicy namespaces, image tag, identity provider, and integrations.

2. Create application and image-pull Secrets

Create the application Secrets in the release namespace before the workloads start:

  • oidc-secrets with OIDC_CLIENT_ID and OIDC_CLIENT_SECRET
  • sites-secrets with SESSION_SECRET_KEY (required, 32 bytes or more) and HUB_MASTER_TOKEN, plus the secret keys for the integrations you enable

HUB_MASTER_TOKEN is optional at install. Without it, the platform runs and browser sign-in works, but the Hub API rejects every bearer master token. Generate one from the Hub settings page after the install, or set it here for automation. See secrets and integrations.

The standard platform images use the sites-oss project in the ECMWF container registry (ECCR). Confirm that cluster nodes can pull them. If an image repository requires authentication, create a pull Secret in the release namespace and set serviceAccount.imagePullSecretName.

Use your secrets manager or another approved Secret delivery method. See secrets and integrations. Do not put real credentials in a committed values file.

3. Provision TLS for routing

When routing.tls.enabled is true, routing.tls.secretName tells the selected routing resource which TLS Secret to use. It does not create the Secret and it is not used by the application:

  • In Ingress mode, the Secret is in the release namespace and is referenced by the master Ingress.
  • For a Gateway created by the chart, the Secret is in the release namespace and is referenced by the HTTPS listener.
  • For an existing Gateway, the chart does not use this value. The Gateway owner must configure the listener certificate in the Gateway namespace.

Use cert-manager or another approved certificate process to create and renew the Secret. The certificate process can create it after the Helm release is installed. See routing and networking for controller-specific annotation settings.

4. Install the chart

helm upgrade --install sites oci://eccr.ecmwf.int/sites-oss/ecmwf-sites \
  --version "${CHART_VERSION}" \
  -f /secure/path/values.yaml -n sites-stage --create-namespace

Helm installs the Site Custom Resource Definition (CRD) on the first chart install. Use a distinct release name and namespace for each environment.

5. Check the rollout

kubectl -n sites-stage get pods
kubectl -n sites-stage get deployments
kubectl -n sites-stage get cronjobs
kubectl -n sites-stage get pvc
kubectl -n sites-stage rollout status deployment/sites-hub
kubectl -n sites-stage rollout status deployment/sites-operator

Then check that the Hub loads at https://<routing.host>/hub/, sign-in works, and a test site can be created and reached. Check the Hub and Operator logs if a workload does not become ready.

Next steps