لنفترض أن مساحة أسماء الإصدار تحتوي بالفعل على Secret باسم app-outbound-proxy. ويحمل المفتاحان http_proxy وhttps_proxy عناوين URL الكاملة للوكيل التي يحتاجها التطبيق.

يمكن لمخطط 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 يوفر قيم بيئة الحاوية. ومجرد تصدير HTTP_PROXY في الصدفة التي تشغّل helm لا يضيف قسم env هذا إلى قالب Pod.

تغيير Secret تغيير في دورة الحياة أيضًا

لا تحدّث الحاوية بيئتها عند تغيّر بيانات Secret. رتّب إعادة التشغيل أو النشر المقصودة كي تتلقى الحاويات الجديدة القيم المحدّثة. وتغيير البيانات تحت الاسم نفسه لـ Secret لا يعدّل بحد ذاته قالب Pod في Deployment.

يجب أن يدعم التطبيق متغيرات بيئة الوكيل المختارة. والوصول إلى مستودع Helm وسحب صورة العقدة مستهلكان منفصلان يعملان قبل أن تفيدهما بيئة الحاوية هذه.

مقالات ذات صلة