Օգտագործել գոյություն ունեցող Secret-ը Helm գծապատկերում պրոքսի փոփոխականների համար
Helm 3 Deployment կաղապարում հղվեք Secret-ից ստացվող ամբողջական պրոքսի URL-երին՝ փոխարենը ենթադրելու, որ shell փոփոխականը կդառնա կոնտեյների միջավայր։
Ենթադրենք, թողարկման 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-ի ներբեռնումը առանձին սպառողներ են, որոնք աշխատում են նախքան այս կոնտեյներ միջավայրը կկարողանա օգնել։