فرض کریں کہ 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 الگ صارفین ہیں جو اس کنٹینر ماحول کے مدد کرنے سے پہلے چلتے ہیں۔

متعلقہ مضامین