Ենթադրենք, թողարկման namespace-ում արդեն կա app-outbound-proxy անունով Secret։ Նրա 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-ի namespace-ում և պարունակի հիշատակված երկու բանալիները։ Նրա արժեքները պետք է օգտագործեն իրական պրոքսի լսողի արձանագրությունը, հոսթը և պորտը։ Հանրային հավելվածի հարցումների համար, որոնց թույլատրվում է օգտագործել առանց նույնականացման հանրային պրոքսի, այդ URL-երը կառուցեք անվճար պրոքսիների ցանկի համապատասխան թեկնածուից․ պահպանեք անհրաժեշտ ուղիղ բացառությունները։

Գծապատկերի արժեքը տալիս է անուն, իսկ secretKeyRef-ը՝ կոնտեյների միջավայրի արժեքները։ Միայն helm-ը գործարկող shell-ում HTTP_PROXY export անելը այս env բաժինը չի ավելացնում Pod կաղապարին։

Secret-ի փոփոխությունը նույնպես կյանքի ցիկլի փոփոխություն է

Կոնտեյները չի թարմացնում իր միջավայրը, երբ Secret-ի տվյալները փոխվում են։ Կազմակերպեք նախատեսված վերագործարկումը կամ rollout-ը, որպեսզի նոր մեկնարկած կոնտեյները ստանան թարմացված արժեքներ։ Նույն Secret անվան տակ տվյալները փոխելը ինքնին չի խմբագրում Deployment-ի Pod կաղապարը։

Հավելվածը պետք է աջակցի ընտրված պրոքսի միջավայրի փոփոխականներին։ Helm պահոցի հասանելիությունը և հանգույցի image-ի ներբեռնումը առանձին սպառողներ են, որոնք աշխատում են նախքան այս կոնտեյներ միջավայրը կկարողանա օգնել։

Առնչվող հոդվածներ