Да претпоставиме дека namespace на изданието веќе има Secret со име app-outbound-proxy. Неговите клучеви http_proxy и https_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-от и да ги содржи двата наведени клуча. Неговите вредности треба да ги користат протоколот, домаќинот и портата на вистинскиот прокси слушател. За јавни барања на приложението на кои им е дозволено да користат јавен прокси без автентикација, градете ги тие URL-а од соодветен кандидат во списокот на бесплатни проксија; задржете ги сите потребни директни исклучоци.

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

Менувањето на Secret е исто така промена во животниот циклус

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

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

Поврзани статии