release 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 pull ఈ కంటైనర్ వాతావరణం సహాయపడే ముందు నడిచే వేర్వేరు వినియోగదారులు.

సంబంధిత వ్యాసాలు