Tutaq ki, release namespace-də artıq app-outbound-proxy adlı Secret var. Onun http_proxy və https_proxy açarları tətbiqin tələb etdiyi tam proxy URL-lərini saxlayır.

Helm 3 diaqramı values.yaml-da yalnız həmin Secret-in adını saxlaya bilər:

outboundProxy:
  existingSecret: app-outbound-proxy

Nəzərdə tutulan container-in Deployment şablonunda açarlara istinad edin:

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

Bu, container spesifikasiyasının bir fraqmentidir. Secret Pod-un namespace-də mövcud olmalı və hər iki istinad edilən açarı saxlamalıdır. Onun dəyərləri real proxy dinləyicisinin protokolu, hostu və portundan istifadə etməlidir. Autentifikasiyasız ictimai proxy istifadə etməsinə icazə verilən ictimai tətbiq sorğuları üçün bu URL-ləri pulsuz proxy siyahısındakı uyğun namizəddən qurun; tələb olunan birbaşa istisnaları saxlayın.

Diaqram dəyəri ad verir; secretKeyRef container-in mühit dəyərlərini verir. helm-i işlədən shell-də sadəcə HTTP_PROXY export etmək bu env bölməsini Pod şablonuna əlavə etmir.

Secret-i dəyişmək də həyat dövrü dəyişikliyidir

Secret məlumatı dəyişdikdə container öz mühitini yeniləmir. Yeni başladılan container-lərin yenilənmiş dəyərləri alması üçün nəzərdə tutulan yenidən başlatmanı və ya rollout-u təşkil edin. Eyni Secret adı altında məlumatı dəyişmək özlüyündə Deployment-in Pod şablonunu redaktə etmir.

Tətbiq seçilmiş proxy mühit dəyişənlərini dəstəkləməlidir. Helm repo-suna giriş və node-un image çəkməsi bu container mühiti kömək edə bilməzdən əvvəl işləyən ayrı istehlakçılardır.

Əlaqəli məqalələr