ניצן אַ פֿאַרהאַנדענעם Secret פֿאַר פּראָקסי וואַריאַבלען אין אַ Helm טשאַרט

לאָמיר זאָגן אַז דער release namespace האָט שוין אַ Secret מיטן נאָמען app-outbound-proxy. זײַנע שליסלען 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 מוז זײַן אין דעם namespace פֿון דעם Pod און אַנטהאַלטן ביידע דערמאָנטע שליסלען. זײַנע ווערטן מוזן ניצן דעם פּראָטאָקאָל, האָסט און פּאָרט פֿון דעם טאַקע פּראָקסי צוהערער. פֿאַר עפֿנטלעכע אַפּלאַקיישאַן בקשות וואָס מעגן ניצן אַן עפֿנטלעכן פּראָקסי אָן אויטענטיפֿיקאַציע, בויט די URL־ן פֿון אַ פּאַסיקן קאַנדידאַט אין דער ליסטע פֿון פֿרייע פּראָקסיס; האַלט אויף יעדערער נייטיקער דירעקטער אויסנאַם.

דער טשאַרט ווערט גיט אַ נאָמען; secretKeyRef גיט די סבֿיבֿה ווערטן פֿון דעם קאָנטיינער. בלויז exportירן HTTP_PROXY אין דער שעל וואָס פֿירט helm לייגט נישט צו דעם env אָפּטייל צו אַ Pod מוסטער.

פֿאַרבייטן דעם Secret איז אויך אַ לעבנס־ציקל פֿאַרבייט

אַ קאָנטיינער דערהײַנטיקט נישט זײַן סבֿיבֿה ווען די Secret דאַטן פֿאַרבייטן זיך. אָרדנט דעם געמיינטן נייעם אָנהייב אָדער rollout אַזוי אַז נײַ אָנגעהויבענע קאָנטיינערס באַקומען דערהײַנטיקטע ווערטן. פֿאַרבייטן דאַטן אונטער דעם זעלבן Secret נאָמען רעדאַגירט נישט פֿון זיך אַליין די Pod מוסטער פֿון דעם Deployment.

די אַפּלאַקיישאַן מוז שטיצן די אויסגעקליבענע פּראָקסי סבֿיבֿה וואַריאַבלען. צוטריט צו דעם Helm אוצר און ציען דאָס image אויפֿן נאָד זײַנען באַזונדערע באַניצער וואָס לויפֿן פֿריִער ווי די קאָנטיינער סבֿיבֿה קען העלפֿן.