Helm চার্টে প্রক্সি ভেরিয়েবলের জন্য বিদ্যমান Secret ব্যবহার করুন

shell ভেরিয়েবল container এনভায়রনমেন্ট হয়ে যাবে বলে ধরে নেওয়ার বদলে Helm 3 Deployment টেমপ্লেটে Secret থেকে সম্পূর্ণ প্রক্সি URL উল্লেখ করুন।

ধরা যাক, release namespace-এ আগে থেকেই app-outbound-proxy নামের একটি Secret আছে। এর http_proxy এবং https_proxy কী-তে অ্যাপ্লিকেশনের প্রয়োজনীয় সম্পূর্ণ প্রক্সি URL রয়েছে।

একটি Helm 3 চার্ট values.yaml-এ কেবল সেই Secret-এর নাম রাখতে পারে:

outboundProxy:
  existingSecret: app-outbound-proxy

নির্ধারিত container-এর 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

এটি container-spec-এর একটি অংশ। Secret-টি Pod-এর namespace-এ থাকতে হবে এবং উল্লেখিত দুটি কী-ই রাখতে হবে। এর মানে প্রকৃত প্রক্সি লিসেনারের প্রোটোকল, হোস্ট ও পোর্ট ব্যবহার করতে হবে। যে পাবলিক অ্যাপ্লিকেশন অনুরোধগুলোকে প্রমাণীকরণহীন পাবলিক প্রক্সি ব্যবহারের অনুমতি আছে, সেই URL-গুলো বিনামূল্যে প্রক্সি তালিকা-র উপযুক্ত প্রার্থী থেকে তৈরি করুন; প্রয়োজনীয় সরাসরি ব্যতিক্রমগুলো রেখে দিন।

চার্টের মান একটি নাম দেয়; secretKeyRef container-এর এনভায়রনমেন্ট মান দেয়। helm চালানো shell-এ শুধু HTTP_PROXY export করলে এই env অংশটি Pod টেমপ্লেটে যোগ হয় না।

Secret বদলানোও একটি জীবনচক্র পরিবর্তন

Secret-এর ডেটা বদলালে container তার এনভায়রনমেন্ট রিফ্রেশ করে না। নতুন চালু হওয়া container যাতে হালনাগাদ মান পায়, সেইমতো পরিকল্পিত restart বা rollout ব্যবস্থা করুন। একই Secret নামের অধীনে ডেটা বদলালে তা নিজে থেকে Deployment-এর Pod টেমপ্লেট সম্পাদনা করে না।

অ্যাপ্লিকেশনকে নির্বাচিত প্রক্সি এনভায়রনমেন্ট ভেরিয়েবল সমর্থন করতে হবে। Helm রিপোজিটরি অ্যাক্সেস ও নোডের image pull আলাদা ভোক্তা, যারা এই container এনভায়রনমেন্ট সহায়ক হওয়ার আগেই চলে।

সম্পর্কিত নিবন্ধ