Претпоставимо да namespace издања већ има Secret назван app-outbound-proxy. Његови кључеви http_proxy и https_proxy садрже потпуне proxy URL-ове потребне апликацији.

Helm 3 графикон може у values.yaml да чува само назив тог Secret-а:

outboundProxy:
  existingSecret: app-outbound-proxy

У Deployment шаблону предвиђеног контејнера референцирајте кључеве:

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

Ово је део спецификације контејнера. Secret мора да постоји у namespace-у Pod-а и да садржи оба наведена кључа. Његове вредности треба да користе протокол, хост и порт стварног proxy ослушкивача. За јавне захтеве апликације којима је дозвољено коришћење јавног proxy-ја без аутентификације, градите те URL-ове из одговарајућег кандидата на листи бесплатних proxy-ја; задржите све потребне директне изузетке.

Вредност графикона даје назив; secretKeyRef даје вредности окружења контејнера. Само export HTTP_PROXY у shell-у који покреће helm не додаје овај env одељак у Pod шаблон.

Промена Secret-а је такође промена животног циклуса

Контејнер не освежава своје окружење када се подаци Secret-а промене. Организујте предвиђени рестарт или rollout тако да новопокренути контејнери добију ажуриране вредности. Промена података под истим називом Secret-а сама по себи не уређује Pod шаблон Deployment-а.

Апликација мора да подржава изабране proxy променљиве окружења. Приступ Helm репозиторијуму и повлачење слике на чвору су одвојени потрошачи који раде пре него што ово окружење контејнера може да помогне.

Повезани чланци