ໃຊ້ Secret ທີ່ມີຢູ່ແລ້ວສຳລັບຕົວແປ proxy ໃນ chart ຂອງ Helm

ອ້າງອີງ URL proxy ທີ່ຄົບຖ້ວນຈາກ Secret ໃນແມ່ແບບ Deployment ຂອງ Helm 3 ແທນທີ່ຈະສົມມຸດວ່າຕົວແປ shell ຈະກາຍເປັນສະພາບແວດລ້ອມຂອງ container.

ສົມມຸດວ່າ namespace ຂອງ release ມີ Secret ຊື່ app-outbound-proxy ຢູ່ແລ້ວ. ກຸນແຈ http_proxy ແລະ https_proxy ຂອງມັນມີ URL proxy ທີ່ຄົບຖ້ວນທີ່ແອັບພລິເຄຊັນຕ້ອງການ.

chart ຂອງ Helm 3 ສາມາດເກັບພຽງຊື່ຂອງ Secret ນັ້ນໄວ້ໃນ values.yaml:

outboundProxy:
  existingSecret: app-outbound-proxy

ໃນແມ່ແບບ Deployment ຂອງ container ທີ່ຕັ້ງໃຈໄວ້, ອ້າງອີງກຸນແຈຕ່າງໆ:

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

ນີ້ແມ່ນສ່ວນໜຶ່ງຂອງຂໍ້ກຳນົດ container. Secret ຕ້ອງຢູ່ໃນ namespace ຂອງ Pod ແລະມີກຸນແຈທັງສອງທີ່ອ້າງອີງ. ຄ່າຂອງມັນຕ້ອງໃຊ້ໂປຣໂຕຄໍ, ໂຮສ ແລະພອດຂອງຕົວຮັບຟັງ proxy ຕົວຈິງ. ສຳລັບຄຳຮ້ອງຂໍສາທາລະນະຂອງແອັບພລິເຄຊັນທີ່ໄດ້ຮັບອະນຸຍາດໃຫ້ໃຊ້ proxy ສາທາລະນະທີ່ບໍ່ມີການພິສູດຕົວຕົນ, ຈົ່ງສ້າງ URL ເຫຼົ່ານັ້ນຈາກຜູ້ສະໝັກທີ່ເໝາະສົມໃນລາຍຊື່ proxy ຟຣີ; ຮັກສາຂໍ້ຍົກເວັ້ນທາງກົງທີ່ຈຳເປັນໄວ້.

ຄ່າຂອງ chart ໃຫ້ຊື່; secretKeyRef ໃຫ້ຄ່າສະພາບແວດລ້ອມຂອງ container. ການ export HTTP_PROXY ພຽງຢ່າງດຽວໃນ shell ທີ່ຮັບ helm ບໍ່ໄດ້ເພີ່ມພາກ env ນີ້ເຂົ້າໃນແມ່ແບບ Pod.

ການປ່ຽນ Secret ກໍ່ແມ່ນການປ່ຽນວົງຈອນຊີວິດ

container ບໍ່ໄດ້ໂຫຼດສະພາບແວດລ້ອມຄືນໃໝ່ເມື່ອຂໍ້ມູນ Secret ປ່ຽນ. ຈັດການ restart ຫຼື rollout ທີ່ຕັ້ງໃຈໄວ້ ເພື່ອໃຫ້ container ທີ່ຫາກໍ່ເລີ່ມໄດ້ຮັບຄ່າທີ່ອັບເດດແລ້ວ. ການປ່ຽນຂໍ້ມູນພາຍໃຕ້ຊື່ Secret ດຽວກັນ ບໍ່ໄດ້ແກ້ແມ່ແບບ Pod ຂອງ Deployment ດ້ວຍຕົວມັນເອງ.

ແອັບພລິເຄຊັນຕ້ອງຮອງຮັບຕົວແປສະພາບແວດລ້ອມ proxy ທີ່ເລືອກ. ການເຂົ້າເຖິງບ່ອນເກັບ Helm ແລະການດຶງ image ຢູ່ node ແມ່ນຜູ້ໃຊ້ແຍກຕ່າງຫາກທີ່ເຮັດວຽກກ່ອນທີ່ສະພາບແວດລ້ອມ container ນີ້ຈະຊ່ວຍໄດ້.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ