שימוש ב-Secret קיים עבור משתני פרוקסי בתרשים Helm

הפנייה לכתובות URL מלאות של פרוקסי מ-Secret בתבנית ה-Deployment של Helm 3 במקום להניח שמשתנה מעטפת יהפוך לסביבת הקונטיינר.

נניח שמרחב השמות של הגרסה מכיל כבר 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 ולהכיל את שני המפתחות שאליהם מפנים. הערכים שלו חייבים להשתמש בפרוטוקול, במארח ובפורט של מאזין הפרוקסי בפועל. עבור בקשות ציבוריות של האפליקציה שמותר להן להשתמש בפרוקסי ציבורי ללא אימות, יש לבנות את כתובות ה-URL האלה ממועמד מתאים ברשימת הפרוקסי החינמיים; יש לשמור על כל חריגה ישירה נדרשת.

ערך התרשים מספק שם; secretKeyRef מספק את ערכי הסביבה של הקונטיינר. ייצוא של HTTP_PROXY במעטפת שמריצה את helm אינו מוסיף את מקטע ה-env הזה לתבנית Pod.

שינוי ה-Secret הוא גם שינוי במחזור החיים

קונטיינר אינו מרענן את הסביבה שלו כשנתוני ה-Secret משתנים. יש לארגן את האתחול מחדש או ה-rollout המתוכננים כך שקונטיינרים חדשים יקבלו ערכים מעודכנים. שינוי נתונים תחת אותו שם Secret אינו עורך בעצמו את תבנית ה-Pod של ה-Deployment.

האפליקציה חייבת לתמוך במשתני הסביבה של הפרוקסי שנבחרו. גישה למאגר Helm ומשיכת תמונת הצומת הם צרכנים נפרדים שפועלים לפני שסביבת הקונטיינר הזו יכולה לעזור להם.

מאמרים קשורים