Mukul SharmaandClaude Opus 5 5a008ffa08 Serve Harbor on the real domain as well
A standalone Ingress because Harbor's chart cannot express a second host:
expose.ingress.hosts.core is a single scalar, with no extraHosts like
argo-cd and no secondaryingress like jenkins. The chart's own Ingress is
untouched and keeps serving the nip.io name with its private-CA
certificate; both names reach the same backends.

The path split is load-bearing and was copied from this cluster's own
generated Ingress rather than written from memory: /api/, /service/, /v2/
and /c/ go to harbor-core, everything else to harbor-portal. harbor-core
is the API, auth and registry backend; harbor-portal is only the web UI.
Sending /v2/ to the portal breaks every image pull, and it fails looking
like an authentication problem rather than a routing one.

What this deliberately does not do is make the new name primary. Harbor
still advertises the nip.io address: externalURL is a single value handed
to docker clients in Harbor's own API responses, so the UI may redirect
there and a docker login against this hostname is issued a token endpoint
pointing at the old one. Both resolve, so it works. Moving externalURL
means moving every image reference in the cluster at the same time —
running deployments, the dockerconfigjson auths key, toolshed's registry
settings and its stored connection — which is its own change, not a line
in this one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LEsTefWWifp4ikvhHF5s6N
2026-09-17 08:44:57 +05:30
2026-08-26 04:03:34 +05:30

devops-infra-argo-config

GitOps control plane for infrastructure tooling across Meesho's Kubernetes fleet.

This repo manages ArgoCD Application resources for every infrastructure tool (Contour, VictoriaMetrics, Grafana, Kyverno, KEDA, external-secrets, Vault, etc.) deployed across ~19 clusters. It uses an App-of-Applications pattern: one parent Application per cluster renders child Applications from a appSpec[] list via a generic Helm chart.

Each environment tracks a dedicated branch — merging to that branch triggers immediate ArgoCD auto-sync with no staging gate:

Environment Branch
Production (prd) main
Staging (stg) develop
Integration (int) pre-prod

How it works

incubator/<env>/<cluster>.yaml          ← Parent Application (one per cluster)
    └── points at generic-argo-apps-chart/ + values/<env>/<cluster>-values.yaml
            └── renders one child Application per appSpec[] entry
                    └── sources charts + overrides from devops-infra-helm-charts

Directory structure

Directory Purpose
incubator/<env>/ Parent ArgoCD Application YAML, one per cluster
values/<env>/ Values files defining which tools deploy per cluster
generic-argo-apps-chart/ Helm chart that renders child Applications from appSpec[]
projects/ ArgoCD AppProject definitions (sre, sec)
external-name-service-*/ Cross-cluster DNS routing (ExternalName / MCS topology)
docs/ Agent-facing operational documentation
skills/ Parameterized agent tasks for common operations
wiki/ Architecture decisions and entity pages

Getting started

Common operations

Task Procedure
Add a tool to a cluster docs/platform/procedures/add-tool-to-cluster.md
Upgrade a chart version docs/platform/procedures/upgrade-chart-version.md
Onboard a new cluster docs/platform/procedures/add-new-cluster.md
Roll out a tool fleet-wide docs/platform/procedures/fleet-wide-tool-rollout.md
Debug sync failure docs/platform/runbooks/argocd-sync-failure.md
Debug Helm render error docs/platform/runbooks/render-failure.md
Find values inconsistencies across clusters docs/platform/runbooks/values-drift.md
Debug stuck deployment docs/platform/runbooks/deployment-stuck.md

Sister repos

  • devops-infra-helm-charts — Helm charts and custom-values.yaml overrides. Every appSpec[].chartDir and valuesDir must exist here.
  • devops-argo-config — Same pattern for service/application workloads (not infra tooling).
S
Description
No description provided
Readme
223 KiB