Supozoni se namespace-i i publikimit ka tashmë një Secret të quajtur app-outbound-proxy. Çelësat e tij http_proxy dhe https_proxy përmbajnë URL-të e plota të proxy-t që kërkon aplikacioni.

Një chart Helm 3 mund të mbajë vetëm emrin e atij Secret në values.yaml:

outboundProxy:
  existingSecret: app-outbound-proxy

Në shabllonin Deployment të kontejnerit të synuar, referojuni çelësave:

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

Ky është një fragment i specifikimit të kontejnerit. Secret duhet të ekzistojë në namespace-in e Pod-it dhe të përmbajë të dy çelësat e referuar. Vlerat e tij duhet të përdorin protokollin, hostin dhe portën e dëgjuesit real të proxy-t. Për kërkesat publike të aplikacionit që lejohen të përdorin një proxy publik pa autentikim, ndërtoni ato URL nga një kandidat i përshtatshëm në listën e proxy-ve falas; mbani çdo përjashtim të drejtpërdrejtë të nevojshëm.

Vlera e chart-it siguron një emër; secretKeyRef siguron vlerat e mjedisit të kontejnerit. Vetëm eksportimi i HTTP_PROXY në shell-in që ekzekuton helm nuk e shton këtë seksion env në një shabllon Pod.

Ndryshimi i Secret është gjithashtu një ndryshim i ciklit të jetës

Një kontejner nuk e rifreskon mjedisin e tij kur ndryshojnë të dhënat e Secret. Organizoni rindezjen ose rollout-in e synuar që kontejnerët e sapondezur të marrin vlerat e përditësuara. Ndryshimi i të dhënave nën të njëjtin emër Secret nuk e redakton vetë shabllonin Pod të Deployment.

Aplikacioni duhet të mbështesë variablat e mjedisit të proxy-t të zgjedhura. Qasja në depon Helm dhe tërheqja e imazhit në nyje janë konsumatorë të veçantë që ekzekutohen para se ky mjedis kontejneri të mund të ndihmojë.

Artikuj të ngjashëm