არსებული Secret-ის გამოყენება პროქსის ცვლადებისთვის Helm დიაგრამაში
Helm 3 Deployment შაბლონში მიუთითეთ Secret-იდან მიღებულ სრულ პროქსი URL-ებზე, ნაცვლად იმისა, რომ ჩათვალოთ, თითქოს shell ცვლადი კონტეინერის გარემოდ იქცევა.
დავუშვათ, გამოშვების 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-ის ჩამოტანა ცალკე მომხმარებლები არიან, რომლებიც მუშაობენ მანამ, სანამ ეს კონტეინერის გარემო შეძლებს დახმარებას.