Uzi ekzistantan Secret por proksaj variabloj en Helm-diagramo

Referencu plenajn proksajn URL-ojn el Secret en la Helm 3 Deployment-ŝablono anstataŭ supozi, ke ŝela variablo fariĝas uja medio.

Supozu, ke la eldona nomspaco jam havas Secret nomatan app-outbound-proxy. Ĝiaj ŝlosiloj http_proxy kaj https_proxy enhavas la plenajn proksajn URL-ojn, kiujn la aplikaĵo bezonas.

Helm 3-diagramo povas teni nur la nomon de tiu Secret en values.yaml:

outboundProxy:
  existingSecret: app-outbound-proxy

En la Deployment-ŝablono de la celata ujo, referencu la ŝlosilojn:

env:
  - name: HTTP_PROXY
    valueFrom:
      secretKeyRef:
        name: {{ .Values.outboundProxy.existingSecret | quote }}
        key: http_proxy
  - name: HTTPS_PROXY
    valueFrom:
      secretKeyRef:
        name: {{ .Values.outboundProxy.existingSecret | quote }}
        key: https_proxy

Ĉi tio estas fragmento de uja specifikaĵo. La Secret devas ekzisti en la nomspaco de la Pod kaj enhavi ambaŭ referencitajn ŝlosilojn. Ĝiaj valoroj devas uzi la protokolon, gastigan nomon kaj pordon de la reala proksa aŭskultanto. Por publikaj aplikaĵpetoj rajtigitaj uzi publikan prokson sen aŭtentigo, konstruu tiujn URL-ojn el taŭga kandidato en la listo de senpagaj proksoj; konservu ĉiujn necesajn rektajn esceptojn.

La diagrama valoro donas nomon; secretKeyRef donas la mediajn valorojn de la ujo. Nur eksporti HTTP_PROXY en la ŝelo, kiu ruliĝas helm, ne aldonas ĉi tiun env-sekcion al Pod-ŝablono.

Ŝanĝi la Secret estas ankaŭ vivcikla ŝanĝo

Ujo ne refreŝigas sian medion, kiam la datumoj de Secret ŝanĝiĝas. Organizu la celatan restarton aŭ rollout tiel, ke ĵus lanĉitaj ujoj ricevu ĝisdatigitajn valorojn. Ŝanĝi datumojn sub la sama Secret-nomo mem ne redaktas la Pod-ŝablonon de la Deployment.

La aplikaĵo devas subteni la elektitajn proksajn mediajn variablojn. Aliro al la Helm-deponejo kaj la bildeltiro de la nodo estas apartaj konsumantoj, kiuj funkcias antaŭ ol ĉi tiu uja medio povas helpi.

Rilataj artikoloj