मान लें कि 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 अलग उपभोक्ता हैं जो इस कंटेनर परिवेश के मदद करने से पहले चलते हैं।

संबंधित लेख