Да предположим, че пространството от имена на изданието вече има Secret с име app-outbound-proxy. Ключовете му http_proxy и https_proxy съдържат пълните прокси URL адреси, нужни на приложението.

Диаграма Helm 3 може да пази само името на този Secret във values.yaml:

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 трябва да съществува в пространството от имена на Pod и да съдържа и двата посочени ключа. Стойностите му трябва да използват протокола, хоста и порта на действителния прокси слушател. За публични заявки на приложението, на които е разрешено да използват публично прокси без удостоверяване, изградете тези URL адреси от подходящ кандидат в списъка с безплатни проксита; запазете всички необходими директни изключения.

Стойността на диаграмата дава име; secretKeyRef дава стойностите на средата на контейнера. Самото export на HTTP_PROXY в обвивката, която изпълнява helm, не добавя този раздел env към шаблон на Pod.

Промяната на Secret е също промяна в жизнения цикъл

Контейнерът не обновява средата си при промяна на данните в Secret. Организирайте предвиденото рестартиране или rollout, така че новостартираните контейнери да получат обновени стойности. Промяната на данни под същото име на Secret сама по себе си не редактира шаблона на Pod в Deployment.

Приложението трябва да поддържа избраните прокси променливи на средата. Достъпът до хранилището на Helm и изтеглянето на образа от възела са отделни потребители, които работят преди тази среда на контейнера да може да помогне.

Подобни статии