Demagun bertsioaren izen-espazioak baduela app-outbound-proxy izeneko Secret bat. Bere http_proxy eta https_proxy giltzek aplikazioak behar dituen proxy URL osoak dituzte.

Helm 3 diagrama batek Secret horren izena soilik gorde dezake values.yaml fitxategian:

outboundProxy:
  existingSecret: app-outbound-proxy

Helburuko edukiontziaren Deployment txantiloian, erreferentzia itzazu giltzak:

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

Hau edukiontziaren zehaztapenaren zati bat da. Secret-ak Podaren izen-espazioan egon behar du, eta erreferentziatutako bi giltzak eduki. Bere balioek benetako proxy entzulearen protokoloa, ostalaria eta ataka erabili behar dituzte. Autentifikaziorik gabeko proxy publiko bat erabiltzea baimenduta dagoen aplikazioaren eskaera publikoetarako, eraiki URL horiek proxy doakoen zerrendako hautagai egoki batetik; atxiki beharrezkoak diren zuzeneko salbuespenak.

Diagramaren balioak izena ematen du; secretKeyRef-ek edukiontziaren ingurune-balioak ematen ditu. helm exekutatzen duen shell-ean HTTP_PROXY exportatzeak soilik ez du env atal hau Pod txantiloi batera gehitzen.

Secret aldatzea ere bizi-zikloaren aldaketa da

Edukiontzi batek ez du bere ingurunea freskatzen Secret datuak aldatzen direnean. Antolatu aurreikusitako berrabiaraztea edo rollout-a, hasiberritutako edukiontziek balio eguneratuak jaso ditzaten. Secret izen beraren pean datuak aldatzeak, bere horretan, ez du Deployment-aren Pod txantiloia editzen.

Aplikazioak aukeratutako proxy ingurune-aldagaiak onartu behar ditu. Helm biltegirako sarbidea eta nodoaren irudiaren jaitsiera bereiziak dira, edukiontzi-ingurune honek lagundu baino lehen exekutatzen diren kontsumitzaileak.

Erlazionatutako artikuluak