Helm ચાર્ટમાં પ્રોક્સી ચલો માટે હાલનું Secret વાપરો

shell ચલ કન્ટેનર પર્યાવરણ બની જશે એમ ધારવાને બદલે Helm 3 Deployment નમૂનામાં Secret માંથી સંપૂર્ણ પ્રોક્સી URL નો સંદર્ભ લો.

ધારો કે release namespace માં પહેલેથી app-outbound-proxy નામનું Secret છે. તેની 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 Pod ના namespace માં હોવું જોઈએ અને સંદર્ભિત બંને કી ધરાવવી જોઈએ. તેની કિંમતોમાં વાસ્તવિક પ્રોક્સી શ્રોતાના પ્રોટોકોલ, હોસ્ટ અને પોર્ટ વાપરવા જોઈએ. જે જાહેર એપ્લિકેશન વિનંતીઓને પ્રમાણીકરણ વગરની જાહેર પ્રોક્સી વાપરવાની પરવાનગી છે, તે URL મફત પ્રોક્સી સૂચિમાંના યોગ્ય ઉમેદવારમાંથી બનાવો; જરૂરી સીધા અપવાદો રાખો.

ચાર્ટની કિંમત નામ આપે છે; secretKeyRef કન્ટેનરની પર્યાવરણ કિંમતો આપે છે. helm ચલાવતા shell માં ફક્ત HTTP_PROXY export કરવાથી આ env વિભાગ Pod નમૂનામાં ઉમેરાતો નથી.

Secret બદલવું પણ જીવનચક્રનો ફેરફાર છે

Secret નો ડેટા બદલાય ત્યારે કન્ટેનર પોતાનું પર્યાવરણ તાજું કરતું નથી. નવા શરૂ થયેલા કન્ટેનરને અદ્યતન કિંમતો મળે તે માટે ઇચ્છિત restart અથવા rollout ગોઠવો. એક જ Secret નામ હેઠળ ડેટા બદલવાથી તે પોતે Deployment ના Pod નમૂનાને સંપાદિત કરતું નથી.

એપ્લિકેશને પસંદ કરેલા પ્રોક્સી પર્યાવરણ ચલોને સમર્થન આપવું જોઈએ. Helm રિપોઝિટરીનો ઍક્સેસ અને નોડનું image pull અલગ ગ્રાહકો છે જે આ કન્ટેનર પર્યાવરણ મદદ કરી શકે તે પહેલાં ચાલે છે.

સંબંધિત લેખો