Getting Started with openCenter-gitops-base :: openCenter Community Documentation

Getting Started with openCenter-gitops-base

Purpose: For platform engineers new to openCenter, shows how to deploy your first platform service (cert-manager) end-to-end using FluxCD GitOps, covering repository structure, configuration, and verification.

This tutorial uses the current community repo onboarding pattern. For the broader decision flow and other deployment models, see ../operations/service-deployment-patterns.md[Service Deployment Patterns] and ../operations/helm-service-onboarding.md[Helm Service Onboarding].

The cluster-repo examples below use a common consumer layout where service activation lives under applications/overlays/<cluster>/services/. If your cluster repository uses a different root, apply the same resource split under the equivalent paths in that repo.

What You’ll Accomplish

By the end of this tutorial, you will: - Understand the openCenter-gitops-base repository structure - Deploy cert-manager to a Kubernetes cluster using FluxCD - Verify the deployment is working correctly - Know where to go next for more advanced tasks

Time: 30-45 minutes

Prerequisites

Before starting, ensure you have:

Kubernetes cluster (v1.28+) with kubectl access
FluxCD (v2.7.0+) installed and bootstrapped on your cluster
Git installed locally
Git access to your cluster repository using the authentication method your organization supports
Basic knowledge of:
Kubernetes concepts (pods, deployments, namespaces)
Git workflows (clone, commit, push)
YAML syntax

Verify your setup:

# Check kubectl access
kubectl cluster-info

# Check Flux is installed
flux check

# Verify Flux version
flux version

Expected output shows Flux v2.7.0+ and all components ready.

Step 1: Understand the Repository Structure

The openCenter-gitops-base repository contains platform services deployed via GitOps. Each service follows a consistent pattern.

Navigate to the cert-manager service:

cd applications/base/services/cert-manager/
ls -la

You’ll usually see: - namespace.yaml - Creates the cert-manager namespace - source.yaml - Defines the Helm chart source - helmrelease.yaml - Configures the deployment - helm-values/ - Contains Helm values files - kustomization.yaml - Ties everything together

Key insight: Many services in openCenter follow this base pattern, even though some services add extra stages or supporting manifests.

Step 2: Examine the HelmRelease Configuration

Open helmrelease.yaml and look at the key sections:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: cert-manager
  namespace: cert-manager
spec:
  interval: 5m                    # Reconcile every 5 minutes
  timeout: 10m                    # Allow 10 minutes for operations
  driftDetection:
    mode: enabled                 # Detect manual changes
  install:
    remediation:
      retries: 3                  # Retry failed installs 3 times
  chart:
    spec:
      chart: cert-manager
      version: v<chart-version>   # Pinned version
      sourceRef:
        kind: HelmRepository
        name: jetstack
  valuesFrom:
    - kind: Secret
      name: cert-manager-values-base
      valuesKey: values.yaml

What this means: - FluxCD checks every 5 minutes if cert-manager matches the desired state - If you manually change something in the cluster, Flux detects it (drift detection) - Installation failures retry automatically 3 times - Configuration comes from a Kubernetes Secret (generated from files)

Step 3: Review the Kustomization

Open kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
    - namespace.yaml
    - source.yaml
    - helmrelease.yaml
secretGenerator:
    - name: cert-manager-values-base
      namespace: cert-manager
      files:
        - values.yaml=helm-values/values-v<version>.yaml

What this does: - Applies namespace, source, and helmrelease in order - Generates a Secret from helm-values/values-v<version>.yaml - The Secret is named cert-manager-values-base (referenced in HelmRelease)

Key insight: Helm values are stored as files in Git, then converted to Secrets by Kustomize. This keeps configuration version-controlled.

Step 4: Create a GitRepository Source

FluxCD needs to know where to find the openCenter service source you want to consume. Create a GitRepository resource in your cluster repo.

In your cluster repository create the source in the directory that holds shared Flux source objects. In the common layout used in these examples, that is applications/overlays/<cluster>/services/sources/.

Create opencenter-cert-manager-community.yaml:

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: opencenter-cert-manager-community
  namespace: flux-system
spec:
  interval: 15m
  url: https://github.com/opencenter-cloud/openCenter-gitops-base
  ref:
    tag: <release-tag>

Register it from the matching source kustomization.yaml in your cluster repo. In the common layout used here, that file is applications/overlays/<cluster>/services/sources/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ./opencenter-cert-manager-community.yaml

Commit and push:

git add applications/overlays/<cluster>/services/sources/opencenter-cert-manager-community.yaml
git add applications/overlays/<cluster>/services/sources/kustomization.yaml
git commit -m "Add cert-manager GitRepository source"
git push

Wait for Flux to reconcile:

flux reconcile source git opencenter-cert-manager-community -n flux-system

Verify the source:

kubectl get gitrepository -n flux-system opencenter-cert-manager-community

Expected: READY column shows True.

Step 5: Create a Kustomization to Deploy cert-manager

Now tell FluxCD to deploy cert-manager from the base repository.

In your cluster overlay create the install Kustomization in the directory that holds service activation objects. In the common layout used here, that file is applications/overlays/<cluster>/services/fluxcd/cert-manager.yaml:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: cert-manager-base
  namespace: flux-system
spec:
  interval: 5m
  sourceRef:
    kind: GitRepository
    name: opencenter-cert-manager-community
  path: ./applications/base/services/cert-manager
  prune: true
  targetNamespace: cert-manager
  healthChecks:
    - apiVersion: helm.toolkit.fluxcd.io/v2
      kind: HelmRelease
      name: cert-manager
      namespace: cert-manager

Register it from the matching services/fluxcd/kustomization.yaml in your cluster repo. In the common layout used here, that file is applications/overlays/<cluster>/services/fluxcd/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ./cert-manager.yaml

If services/fluxcd/kustomization.yaml does not include cert-manager.yaml, Flux will not apply the install Kustomization.

Commit and push:

git add applications/overlays/<cluster>/services/fluxcd/cert-manager.yaml
git add applications/overlays/<cluster>/services/fluxcd/kustomization.yaml
git commit -m "Deploy cert-manager from base repository"
git push

Trigger reconciliation:

flux reconcile kustomization cert-manager-base -n flux-system

Step 6: Watch the Deployment

FluxCD will now deploy cert-manager. Watch the progress:

# Watch the Kustomization
flux get kustomizations cert-manager-base

# Watch the HelmRelease
flux get helmreleases -n cert-manager

# Watch pods being created
kubectl get pods -n cert-manager -w

What’s happening: . Flux creates the cert-manager namespace . Flux creates the HelmRepository source (Jetstack) . Flux generates the values Secret from the file . Flux creates the HelmRelease . Helm-controller installs cert-manager chart . Pods start running

This takes 2-5 minutes.

Step 7: Verify cert-manager is Working

Once pods are running, verify cert-manager is functional:

# Check all pods are ready
kubectl get pods -n cert-manager

# Check cert-manager webhook is responding
kubectl get validatingwebhookconfigurations cert-manager-webhook

# Check CRDs are installed
kubectl get crds | grep cert-manager

Expected output: - 3 pods running: cert-manager, cert-manager-cainjector, cert-manager-webhook - Webhook configuration exists - Multiple CRDs like certificates.cert-manager.io, issuers.cert-manager.io

Test certificate issuance:

Create a test self-signed issuer:

kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: test-selfsigned
  namespace: cert-manager
spec:
  selfSigned: {}
EOF

Create a test certificate:

kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: test-cert
  namespace: cert-manager
spec:
  secretName: test-cert-tls
  issuerRef:
    name: test-selfsigned
  dnsNames:
    - test.example.com
EOF

Verify the certificate was issued:

kubectl get certificate -n cert-manager test-cert

Expected: READY column shows True within 30 seconds.

Check the secret was created:

kubectl get secret -n cert-manager test-cert-tls

Expected: Secret exists with tls.crt and tls.key data.

Clean up test resources:

kubectl delete certificate -n cert-manager test-cert
kubectl delete issuer -n cert-manager test-selfsigned
kubectl delete secret -n cert-manager test-cert-tls

Step 8: Understand What You’ve Built

Congratulations! You’ve deployed cert-manager using the openCenter GitOps pattern. Here’s what you accomplished:

GitOps Workflow: - Configuration lives in Git (single source of truth) - FluxCD continuously reconciles cluster state with Git - Changes are made via Git commits, not kubectl commands - Drift detection prevents manual changes from persisting

Repository Model: - Base repository (openCenter-gitops-base): Hardened service configurations - Cluster repository: Cluster-specific Flux wiring, overrides, and local manifests - Private enterprise repository: Optional private source, image, and values rewrites layered on top of base - FluxCD: Automated deployment and reconciliation

Declarative Management: - HelmRelease defines desired state - Flux ensures actual state matches desired state - Automatic retries on failures - Health checks verify deployment success

Check Your Work

Before moving on, verify:

GitRepository opencenter-cert-manager-community shows READY=True
Kustomization cert-manager-base shows READY=True
HelmRelease cert-manager shows READY=True
All cert-manager pods are Running
Test certificate was issued successfully
You understand the GitOps workflow

Troubleshooting:

If something isn’t working:

# Check Flux logs
flux logs --level=error

# Check specific resource status
flux get sources git
flux get kustomizations
flux get helmreleases -A

# Describe resources for details
kubectl describe gitrepository -n flux-system opencenter-cert-manager-community
kubectl describe kustomization -n flux-system cert-manager-base
kubectl describe helmrelease -n cert-manager cert-manager

Next Steps

Now that you’ve deployed your first service, explore these topics:

Customize Configuration: - ../operations/configure-helm-values.md[Configure Helm Values] - Override base values for your cluster - ../operations/manage-secrets.md[Manage Secrets with SOPS] - Encrypt sensitive configuration

Deploy More Services: - ../operations/add-helm-service-to-community-repo.md[Add a Helm Service to the Community Repo] - Add a new shared Helm-based service to the community repo - ../../README.md#available-applications[Available Applications] - Browse available services and versions

Advanced Topics: - ../operations/configure-gateway.md[Configure Gateway API] - Set up ingress routing - ../operations/setup-observability.md[Setup Observability] - Deploy monitoring stack - ../operations/troubleshoot-flux.md[Troubleshoot Flux] - Debug reconciliation issues

Understand the Architecture: - ../concepts/gitops-workflow.md[GitOps Workflow] - How FluxCD manages deployments - ../concepts/three-tier-values.md[Base, Override, and Enterprise Values] - Why we use this layering model - ../concepts/architecture.md[Architecture Overview] - System design decisions