Q: How do you share Helm charts internally across multiple engineering teams?
Modern strategy for publishing and sharing internal Helm charts across engineering teams via OCI registries (ECR, Harbor, GHCR) with semantic versioning, values schema validation, and CI/CD consumption.
#Kubernetes #Helm #OCI Registry #Harbor #AWS ECR #Package Management #Artifacts
🎙️ Candidate Opening & Architectural Context
"I package charts and publish them to an internal OCI registry (such as AWS ECR, Harbor, GHCR, or Artifactory) using semantic versioning. Teams consume the charts in their CI/CD pipelines with pinned versions, and we maintain a central changelog and JSON values schema. OCI-based sharing eliminates legacy chart repository servers and leverages our existing container registry authentication and RBAC."
Advertisement
🛠️ Production Runbook & Step-by-Step Resolution
1️⃣
Packaging & Publishing Charts to Internal OCI Registries
Modern Helm 3 treats charts as standard OCI artifacts stored alongside container images:
# Package and push chart to OCI registry
helm dependency update charts/base-app
helm lint charts/base-app
helm package charts/base-app
# Authenticate and push
helm registry login harbor.internal.example.com
helm push base-app-1.4.2.tgz oci://harbor.internal.example.com/helm- Dependency & Lint Checks: Run
helm dependency updateandhelm lintto ensure dependencies and templates are validated. - Packaging: Package chart into a versioned tarball (e.g.
base-app-1.4.2.tgz). - OCI Push: Log in to the internal registry and push directly using the
oci://protocol.
2️⃣
Team Consumption, Version Pinning & Governance
How consumer teams integrate shared base charts into their deployment pipelines:
# Pull and inspect remote OCI chart
helm pull oci://harbor.internal.example.com/helm/base-app --version 1.4.2
# Deploy directly from OCI registry in CI/CD
helm upgrade --install myapp oci://harbor.internal.example.com/helm/base-app \
--version 1.4.2 -n myns -f values.yaml --create-namespace- Version Pinning: Application pipelines consume charts by specifying explicit semantic versions (e.g.,
--version 1.4.2) to prevent unexpected breaking changes. - Values Schema Enforcement: Include a
values.schema.jsonfile in the chart to validate team-provided values during client-side rendering. - Automated Release Pipelines: Use GitHub Actions / GitLab CI with semantic-release to automatically build, test, and publish chart artifacts when PRs merge to main.
💡 The Senior SRE Gold Nugget (Key Architectural Takeaway)
"Adopt Helm OCI registries (ECR, Harbor, GHCR) over legacy ChartMuseum/HTTP servers. It unifies container and chart security, simplifies access control, and enables strict semantic versioning."
⚡ 60-Second Elevator Pitch Talking Points
- Publish versioned Helm charts as OCI artifacts directly to internal registries like Harbor or AWS ECR.
- Enforce schema validation with values.schema.json and semantic versioning to protect downstream teams from breaking changes.
- Integrate chart consumption directly into application CI/CD pipelines using pinned oci:// registry URIs.
Advertisement