Używanie istniejącego Secret dla zmiennych proxy w wykresie Helm

Odwołuj się do pełnych adresów URL proxy z Secret w szablonie Deployment Helm 3, zamiast zakładać, że zmienna powłoki stanie się środowiskiem kontenera.

Załóżmy, że przestrzeń nazw wydania ma już Secret o nazwie app-outbound-proxy. Jego klucze http_proxy i https_proxy zawierają pełne adresy URL proxy potrzebne aplikacji.

Wykres Helm 3 może przechowywać w values.yaml tylko nazwę tego Secret:

outboundProxy:
  existingSecret: app-outbound-proxy

W szablonie Deployment docelowego kontenera odwołaj się do kluczy:

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

To fragment specyfikacji kontenera. Secret musi istnieć w przestrzeni nazw Poda i zawierać oba wskazane klucze. Jego wartości muszą używać protokołu, hosta i portu rzeczywistego nasłuchu proxy. Dla publicznych żądań aplikacji, którym wolno korzystać z publicznego proxy bez uwierzytelniania, buduj te adresy URL z odpowiedniego kandydata z listy darmowych proxy; zachowaj wszelkie wymagane wyjątki bezpośrednie.

Wartość wykresu dostarcza nazwę; secretKeyRef dostarcza wartości środowiska kontenera. Samo wyeksportowanie HTTP_PROXY w powłoce uruchamiającej helm nie dodaje tej sekcji env do szablonu Poda.

Zmiana Secret to także zmiana cyklu życia

Kontener nie odświeża swojego środowiska, gdy zmieniają się dane Secret. Zorganizuj zamierzony restart lub rollout, aby nowo uruchomione kontenery otrzymały zaktualizowane wartości. Zmiana danych pod tą samą nazwą Secret sama w sobie nie edytuje szablonu Poda w Deployment.

Aplikacja musi obsługiwać wybrane zmienne środowiskowe proxy. Dostęp do repozytorium Helm i pobieranie obrazu na węźle to odrębni konsumenci działający, zanim to środowisko kontenera będzie mogło pomóc.

Powiązane artykuły