დავუშვათ, გამოშვების 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 უნდა არსებობდეს Pod-ის namespace-ში და შეიცავდეს ორივე მითითებულ გასაღებს. მისი მნიშვნელობები უნდა იყენებდეს რეალური პროქსი მსმენელის პროტოკოლს, ჰოსტსა და პორტს. საჯარო აპლიკაციის მოთხოვნებისთვის, რომლებსაც ნებადართული აქვთ გამოიყენონ აუთენტიფიკაციის გარეშე საჯარო პროქსი, ააგეთ ეს URL-ები უფასო პროქსიების სიის შესაბამისი კანდიდატიდან; შეინარჩუნეთ საჭირო პირდაპირი გამონაკლისები.

დიაგრამის მნიშვნელობა იძლევა სახელს; secretKeyRef იძლევა კონტეინერის გარემოს მნიშვნელობებს. მხოლოდ HTTP_PROXY-ის export helm-ის გამშვებ shell-ში არ ამატებს ამ env სექციას Pod შაბლონს.

Secret-ის შეცვლა სიცოცხლის ციკლის ცვლილებაცაა

კონტეინერი არ აახლებს თავის გარემოს, როცა Secret-ის მონაცემები იცვლება. მოაწყვეთ განზრახული გადატვირთვა ან rollout, რათა ახლად გაშვებულმა კონტეინერებმა მიიღონ განახლებული მნიშვნელობები. მონაცემების შეცვლა იმავე Secret სახელის ქვეშ თავისთავად არ არედაქტირებს Deployment-ის Pod შაბლონს.

აპლიკაციამ უნდა დაუჭიროს მხარი არჩეულ პროქსი გარემოს ცვლადებს. Helm რეპოზიტორიაზე წვდომა და კვანძზე image-ის ჩამოტანა ცალკე მომხმარებლები არიან, რომლებიც მუშაობენ მანამ, სანამ ეს კონტეინერის გარემო შეძლებს დახმარებას.

დაკავშირებული სტატიები