Выкарыстанне існуючага Secret для праксі-змянных у чарце Helm

Спасылайцеся на поўныя праксі-URL з Secret у шаблоне Deployment Helm 3, замест таго каб меркаваць, што зменная абалонкі стане асяроддзем кантэйнера.

Няхай у прасторы імёнаў рэлізу ўжо ёсць 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 павінен існаваць у прасторы імёнаў Pod і змяшчаць абодва згаданыя ключы. Яго значэнні павінны выкарыстоўваць пратакол, хост і порт рэальнага праксі-слухача. Для публічных запытаў праграмы, якім дазволена выкарыстоўваць публічны праксі без аўтэнтыфікацыі, будайце гэтыя URL з адпаведнага кандыдата ў спісе бясплатных праксі; захавайце ўсе патрэбныя прамыя выключэнні.

Значэнне чарты дае імя; secretKeyRef дае значэнні асяроддзя кантэйнера. Проста export HTTP_PROXY у абалонцы, якая запускае helm, не дадае гэты раздзел env у шаблон Pod.

Змена Secret — таксама змена жыццёвага цыклу

Кантэйнер не абнаўляе сваё асяроддзе пры змене даных Secret. Арганізуйце патрэбны перазапуск або rollout, каб новыя кантэйнеры атрымалі абноўленыя значэнні. Змена даных пад тым жа імем Secret сама па сабе не рэдагуе шаблон Pod у Deployment.

Праграма павінна падтрымліваць абраныя зменныя асяроддзя праксі. Доступ да рэпазіторыя Helm і загрузка вобраза вузла — асобныя спажыўцы, якія працуюць раней, чым гэтае асяроддзе кантэйнера зможа дапамагчы.

Падобныя артыкулы