Mukul SharmaandClaude Opus 5
f703f0b55a
Each of these now answers on <name>.infra.deployshed.com alongside the nip.io name it already had. Both are kept on purpose: nothing that currently references the old name breaks, and the new one can be proved before anything depends on it. Removing nip.io is a separate step, and a larger one, because Harbor's name is embedded in every running app's image reference. TLS covers the real domain only. Let's Encrypt cannot issue for nip.io — it is not on the public suffix list and every *.nip.io certificate shares one rate limit — so a tls block naming both would request one certificate spanning them and receive nothing for either. Each tls block therefore lists exactly the one new hostname, which is why they are written out rather than derived from the host list beside them. The charts disagree about how to express a second host, so each is done the way its own chart supports: gitea, grafana, vault, victoria-metrics-single take host lists, so the new name joins the existing one on a single Ingress. jenkins' primary ingress accepts exactly one hostName, so the new name goes on secondaryingress — a whole second Ingress object at the same backend. paths must be set explicitly there; left at the chart's default of [] it renders zero routes and the hostname answers nothing. argo-cd takes extraHosts natively, but its ingress.tls is a boolean bound to one fixed secret covering every host at once. Turning it on would request a certificate including nip.io and fail, and there is no extraTls to scope it. So ArgoCD gains the hostname now and its certificate when nip.io goes. Harbor is untouched here. It has no multi-host mechanism at all, so its second hostname needs a standalone Ingress, and its externalURL is what docker clients are handed — both deserve their own change rather than riding along with a hostname tidy-up. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LEsTefWWifp4ikvhHF5s6N
devops-infra-helm-charts
This branch (main) is part of the restructuring process for the gcp-devops-admin repository, aimed at organizing helmcharts of all infrastructure tools and their corresponding value files. The purpose of this repository is to centralize and manage these resources efficiently.
Directory Structure
helm-templates
This directory is intended for caching or forking helm charts locally. If there's a need to modify or customize any helm chart, it can be done here. Otherwise, the charts will be used directly from the provider.
helm-overrides
The helm-overrides folder stores custom values files for helm charts. These files can be used to override the default values provided by the helm charts, whether they are forked or used directly from the provider.
cluster_name
Each tool within the repository may have different values based on the specific clusters. This directory is used to manage configurations and values tailored to different clusters.
manifests
The manifests directory contains manifest files that need to be applied only once. Examples include service-to-service configurations, storage classes, and any other manifest-related files necessary for the operation of the infrastructure tools.
Additional Notes
Please ensure that all changes made to this branch align with the restructuring objectives and follow the best practices for managing helm charts and infrastructure-related configurations.
For any questions or concerns, please reach out to the designated repository maintainers.