فرض کنید فضای نام انتشار از قبل Secretی به نام app-outbound-proxy دارد. کلیدهای http_proxy و https_proxy آن نشانی‌های کامل پراکسی مورد نیاز برنامه را در خود دارند.

یک نمودار Helm 3 می‌تواند فقط نام همان Secret را در values.yaml نگه دارد:

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 وجود داشته باشد و هر دو کلید ارجاع‌شده را در خود داشته باشد. مقادیر آن باید پروتکل، میزبان و درگاه شنونده واقعی پراکسی را به کار ببرد. برای درخواست‌های عمومی برنامه که مجاز به استفاده از پراکسی عمومی بدون احراز هویت هستند، آن نشانی‌ها را از نامزد مناسب در فهرست پراکسی رایگان بسازید؛ استثناهای مستقیم لازم را نگه دارید.

مقدار نمودار یک نام فراهم می‌کند؛ secretKeyRef مقادیر محیط کانتینر را فراهم می‌کند. صرفاً export کردن HTTP_PROXY در پوسته‌ای که helm را اجرا می‌کند، این بخش env را به قالب Pod اضافه نمی‌کند.

تغییر Secret نیز تغییری در چرخه عمر است

کانتینر هنگام تغییر داده‌های Secret محیط خود را تازه نمی‌کند. راه‌اندازی مجدد یا rollout مورد نظر را ترتیب دهید تا کانتینرهای تازه‌شروع‌شده مقادیر به‌روزشده را بگیرند. تغییر داده‌ها زیر همان نام Secret، به‌خودی‌خود قالب Pod در Deployment را ویرایش نمی‌کند.

برنامه باید متغیرهای محیط پراکسی انتخاب‌شده را پشتیبانی کند. دسترسی به مخزن Helm و کشیدن ایمیج در گره، مصرف‌کنندگانی جداگانه‌اند که پیش از آنکه این محیط کانتینر بتواند کمکی کند اجرا می‌شوند.

مقالات مرتبط