ເຄັດລັບ ແລະເຄັດລັບ Kubernetes: ກ່ຽວກັບການພັດທະນາທ້ອງຖິ່ນ ແລະ Telepresence

ພວກເຮົາຖືກຖາມຫຼາຍຂຶ້ນກ່ຽວກັບການພັດທະນາ microservices ໃນ Kubernetes. ນັກພັດທະນາ, ໂດຍສະເພາະພາສາທີ່ຖືກຕີຄວາມ, ຕ້ອງການແກ້ໄຂລະຫັດໄວໃນ IDE ທີ່ພວກເຂົາມັກແລະເບິ່ງຜົນໄດ້ຮັບໂດຍບໍ່ຕ້ອງລໍຖ້າການກໍ່ສ້າງ / ນໍາໃຊ້ - ພຽງແຕ່ກົດປຸ່ມ F5. ແລະໃນເວລາທີ່ມັນມາກັບຄໍາຮ້ອງສະຫມັກ monolithic, ມັນພຽງພໍທີ່ຈະຕິດຕັ້ງຖານຂໍ້ມູນແລະເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ໃນທ້ອງຖິ່ນ (ໃນ Docker, VirtualBox ... ), ແລະຫຼັງຈາກນັ້ນທັນທີມີຄວາມສຸກການພັດທະນາ. ດ້ວຍການຕັດຂອງ monoliths ເຂົ້າໄປໃນ microservices ແລະການມາເຖິງຂອງ Kubernetes, ດ້ວຍຮູບລັກສະນະຂອງການເພິ່ງພາອາໄສເຊິ່ງກັນແລະກັນ, ທຸກສິ່ງທຸກຢ່າງ. ມັນມີຄວາມຫຍຸ້ງຍາກຫຼາຍ. ຫຼາຍຂອງການບໍລິການຈຸລະພາກເຫຼົ່ານີ້, ບັນຫາຫຼາຍ. ເພື່ອເພີດເພີນກັບການພັດທະນາອີກເທື່ອຫນຶ່ງ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ຍົກຫຼາຍກວ່າຫນຶ່ງຫຼືສອງຕູ້ຄອນເທນເນີ Docker, ແລະບາງຄັ້ງກໍ່ມີຫຼາຍກວ່າອາຍແກັສ ... ໂດຍທົ່ວໄປແລ້ວ, ທັງຫມົດນີ້ສາມາດໃຊ້ເວລາຫຼາຍ, ເນື່ອງຈາກວ່າມັນຍັງຕ້ອງໄດ້ຮັບການຮັກສາໃຫ້ທັນສະໄຫມ. .

ໃນຊ່ວງເວລາທີ່ແຕກຕ່າງກັນພວກເຮົາໄດ້ພະຍາຍາມແກ້ໄຂບັນຫາທີ່ແຕກຕ່າງກັນ. ແລະຂ້ອຍຈະເລີ່ມຕົ້ນດ້ວຍການແກ້ໄຂທີ່ສະສົມຫຼືພຽງແຕ່ "ໄມ້ຄ້ອນເທົ້າ".

1. ໄມ້ຄ້ອນ

IDE ສ່ວນໃຫຍ່ມີຄວາມສາມາດແກ້ໄຂລະຫັດໂດຍກົງໃນເຊີບເວີໂດຍໃຊ້ FTP/SFTP. ເສັ້ນທາງນີ້ແມ່ນຈະແຈ້ງຫຼາຍແລະພວກເຮົາທັນທີຕັດສິນໃຈທີ່ຈະນໍາໃຊ້ມັນ. ໂດຍເນື້ອແທ້ແລ້ວຂອງມັນຕົ້ມລົງໄປດັ່ງຕໍ່ໄປນີ້:

1. ໃນຝັກຂອງສະພາບແວດລ້ອມການພັດທະນາ (dev/review), ກ່ອງບັນຈຸເພີ່ມເຕີມແມ່ນເປີດຕົວດ້ວຍການເຂົ້າເຖິງ SSH ແລະສົ່ງຕໍ່ລະຫັດ SSH ສາທາລະນະຂອງນັກພັດທະນາຜູ້ທີ່ຈະປະຕິບັດ / ນໍາໃຊ້ແອັບພລິເຄຊັນ.
2. ໃນຂັ້ນຕອນ init (ພາຍໃນບັນຈຸ prepare-app) ໂອນລະຫັດໄປ emptyDirເພື່ອໃຫ້ມີການເຂົ້າເຖິງລະຫັດຈາກຕົວບັນຈຸແອັບພລິເຄຊັນ ແລະເຊີບເວີ SSH.

ເພື່ອເຂົ້າໃຈການປະຕິບັດດ້ານວິຊາການຂອງໂຄງການດັ່ງກ່າວໄດ້ດີຂຶ້ນ, ຂ້າພະເຈົ້າຈະສະຫນອງຊິ້ນສ່ວນຂອງການຕັ້ງຄ່າ YAML ທີ່ກ່ຽວຂ້ອງໃນ Kubernetes.

ການຕັ້ງຄ່າ

1.1. values.yaml

ssh_pub_key:
  vasya.pupkin: <ssh public key in base64> 

ມັນເປັນ vasya.pupkin ແມ່ນຄ່າຂອງຕົວແປ ${GITLAB_USER_LOGIN}.

1.2. deployment.yaml

...
{{ if eq .Values.global.debug "yes" }}
      volumes:
      - name: ssh-pub-key
        secret:
          defaultMode: 0600
          secretName: {{ .Chart.Name }}-ssh-pub-key
      - name: app-data
        emptyDir: {}
      initContainers:
      - name: prepare-app
{{ tuple "backend" . | include "werf_container_image" | indent 8 }}
        volumeMounts:
        - name: app-data
          mountPath: /app-data
        command: ["bash", "-c", "cp -ar /app/* /app-data/" ]
{{ end }}
      containers:
{{ if eq .Values.global.debug "yes" }}
      - name: ssh
        image: corbinu/ssh-server
        volumeMounts:
        - name: ssh-pub-key
          readOnly: true
          mountPath: /root/.ssh/authorized_keys
          subPath: authorized_keys
        - name: app-data
          mountPath: /app
        ports:
        - name: ssh
          containerPort: 22
          protocol: TCP
{{ end }}
      - name: backend
        volumeMounts:
{{ if eq .Values.global.debug "yes" }}
        - name: app-data
          mountPath: /app
{{ end }}
        command: ["/usr/sbin/php-fpm7.2", "--fpm-config", "/etc/php/7.2/php-fpm.conf", "-F"]
...

1.3. secret.yaml

{{ if eq .Values.global.debug "yes" }}
apiVersion: v1
kind: Secret
metadata:
  name: {{ .Chart.Name }}-ssh-pub-key
type: Opaque
data:
  authorized_keys: "{{ first (pluck .Values.global.username .Values.ssh_pub_key) }}"
{{ end }}

ການສໍາພັດສຸດທ້າຍ

ຫຼັງຈາກນັ້ນ, ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນການໂອນ ຕ້ອງການຕົວແປ gitlab-ci.yml:

dev:
  stage: deploy
  script:
   - type multiwerf && source <(multiwerf use 1.0 beta)
   - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
   - werf deploy
     --namespace ${CI_PROJECT_NAME}-stage
     --set "global.env=stage"
     --set "global.git_rev=${CI_COMMIT_SHA}"
     --set "global.debug=yes"
     --set "global.username=${GITLAB_USER_LOGIN}"
 tags:
   - build

Voila: ນັກພັດທະນາຜູ້ທີ່ເປີດຕົວການໃຊ້ງານສາມາດເຊື່ອມຕໍ່ໂດຍຊື່ການບໍລິການ (ວິທີການອະນຸຍາດໃຫ້ເຂົ້າເຖິງ cluster ຢ່າງປອດໄພ, ພວກເຮົາບອກແລ້ວ) ຈາກ desktop ຂອງທ່ານຜ່ານ SFTP ແລະແກ້ໄຂລະຫັດໂດຍບໍ່ຕ້ອງລໍຖ້າມັນຖືກສົ່ງໄປຫາກຸ່ມ.

ນີ້​ແມ່ນ​ການ​ແກ້​ໄຂ​ທີ່​ເຮັດ​ວຽກ​ຢ່າງ​ສົມ​ບູນ​, ແຕ່​ຈາກ​ຈຸດ​ປະ​ຕິ​ບັດ​ຂອງ​ການ​ເບິ່ງ​ມັນ​ມີ​ຂໍ້​ເສຍ​ທີ່​ຈະ​ແຈ້ງ​:

• ຄວາມຕ້ອງການທີ່ຈະປັບປຸງຕາຕະລາງ Helm, ເຊິ່ງເຮັດໃຫ້ມັນຍາກທີ່ຈະອ່ານໃນອະນາຄົດ;
• ສາມາດນຳໃຊ້ໄດ້ໂດຍຜູ້ທີ່ນຳໃຊ້ການບໍລິການເທົ່ານັ້ນ;
• ທ່ານຈໍາເປັນຕ້ອງຈື່ຈໍາທີ່ຈະ synchronize ມັນກັບໄດເລກະທໍລີທ້ອງຖິ່ນດ້ວຍລະຫັດແລະຄໍາຫມັ້ນສັນຍາກັບ Git.

2. Telepresence

ໂຄງການ ການສື່ສານທາງໄກ ເປັນທີ່ຮູ້ຈັກເປັນເວລາດົນນານ, ແຕ່ພວກເຮົາ, ຍ້ອນວ່າພວກເຂົາເວົ້າວ່າ, "ບໍ່ໄດ້ພະຍາຍາມຢ່າງຈິງຈັງໃນການປະຕິບັດ." ຢ່າງໃດກໍຕາມ, ຄວາມຕ້ອງການໄດ້ເຮັດວຽກຂອງຕົນແລະໃນປັດຈຸບັນພວກເຮົາມີຄວາມຍິນດີທີ່ຈະແບ່ງປັນປະສົບການຂອງພວກເຮົາ, ເຊິ່ງອາດຈະເປັນປະໂຫຍດກັບຜູ້ອ່ານຂອງ blog ຂອງພວກເຮົາ - ໂດຍສະເພາະເນື່ອງຈາກວ່າຍັງບໍ່ທັນມີອຸປະກອນການອື່ນໆກ່ຽວກັບ Telepresence ໃນສູນກາງເທື່ອ.

ໃນສັ້ນ, ທຸກສິ່ງທຸກຢ່າງໄດ້ຫັນອອກບໍ່ເປັນຕາຢ້ານຫຼາຍ. ພວກເຮົາໄດ້ວາງການປະຕິບັດທັງຫມົດທີ່ຮຽກຮ້ອງໃຫ້ມີການປະຕິບັດຢູ່ໃນສ່ວນຂອງນັກພັດທະນາໃນໄຟລ໌ຂໍ້ຄວາມ Helm ທີ່ມີຊື່ວ່າ NOTES.txt. ດັ່ງນັ້ນ, ຫຼັງຈາກການນໍາໃຊ້ການບໍລິການກັບ Kubernetes, ຜູ້ພັດທະນາເຫັນຄໍາແນະນໍາສໍາລັບການເປີດຕົວສະພາບແວດລ້ອມ dev ທ້ອງຖິ່ນໃນບັນທຶກວຽກ GitLab:

!!! Разработка сервиса локально, в составе Kubernetes !!!

* Настройка окружения
* * Должен быть доступ до кластера через VPN
* * На локальном ПК установлен kubectl ( https://kubernetes.io/docs/tasks/tools/install-kubectl/ )
* * Получить config-файл для kubectl (скопировать в ~/.kube/config)
* * На локальном ПК установлен telepresence ( https://www.telepresence.io/reference/install )
* * Должен быть установлен Docker
* * Необходим доступ уровня reporter или выше к репозиторию https://gitlab.site.com/group/app
* * Необходимо залогинится в registry с логином/паролем от GitLab (делается один раз):

#########################################################################
docker login registry.site.com
#########################################################################

* Запуск окружения

#########################################################################
telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name  }}:backend --mount=/tmp/app --docker-run -v `pwd`:/app -v /tmp/app/var/run/secrets:/var/run/secrets -ti registry.site.com/group/app/backend:v8
#########################################################################

ພວກ​ເຮົາ​ຈະ​ບໍ່​ໄດ້​ຢູ່​ໃນ​ລະ​ອຽດ​ກ່ຽວ​ກັບ​ຂັ້ນ​ຕອນ​ທີ່​ອະ​ທິ​ບາຍ​ໃນ​ຄໍາ​ແນະ​ນໍາ​ນີ້ ... ຍົກ​ເວັ້ນ​ຂອງ​ຄັ້ງ​ສຸດ​ທ້າຍ​. ຈະເກີດຫຍັງຂຶ້ນໃນລະຫວ່າງການເປີດຕົວ Telepresence?

ເຮັດວຽກກັບ Telepresence

ເມື່ອເລີ່ມຕົ້ນ (ໃຊ້ຄໍາສັ່ງສຸດທ້າຍທີ່ລະບຸໄວ້ໃນຄໍາແນະນໍາຂ້າງເທິງ), ພວກເຮົາກໍານົດ:

• namespace ທີ່ microservice ກໍາລັງແລ່ນ;
• ຊື່ຂອງການນໍາໃຊ້ແລະບັນຈຸທີ່ພວກເຮົາຕ້ອງການທີ່ຈະເຈາະ.

ການໂຕ້ຖຽງທີ່ຍັງເຫຼືອແມ່ນທາງເລືອກ. ຖ້າການບໍລິການຂອງພວກເຮົາພົວພັນກັບ ແລະສໍາລັບ Kubernetes API ສ້າງບັນຊີບໍລິການ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ mount ໃບຢັ້ງຢືນ / tokens ໃນ desktop ຂອງພວກເຮົາ. ເພື່ອເຮັດສິ່ງນີ້, ໃຊ້ທາງເລືອກ --mount=true (ຫຼື --mount=/dst_path), ເຊິ່ງຈະຕິດຮາກ (/) ຈາກຖັງ Kubernetes ໄປຫາ desktop ຂອງພວກເຮົາ. ຫຼັງຈາກນີ້, ພວກເຮົາສາມາດ (ຂຶ້ນກັບ OS ແລະວິທີການເປີດຕົວແອັບພລິເຄຊັນ) ໃຊ້ "ກະແຈ" ຈາກກຸ່ມ.

ທໍາອິດ, ໃຫ້ເບິ່ງທາງເລືອກທົ່ວໄປທີ່ສຸດສໍາລັບການແລ່ນຄໍາຮ້ອງສະຫມັກ - ໃນ Docker container. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຈະນໍາໃຊ້ທີ່ສໍາຄັນ --docker-run ແລະຕິດໄດເລກະທໍລີດ້ວຍລະຫັດໃສ່ໃນບັນຈຸ: -v `pwd`:/app

ກະ​ລຸ​ນາ​ສັງ​ເກດ​ວ່າ​ນີ້​ສົມ​ມຸດ​ວ່າ​ແລ່ນ​ຈາກ​ລະ​ບົບ​ໂຄງ​ການ​. ລະຫັດແອັບພລິເຄຊັນຈະຖືກຕິດຕັ້ງຢູ່ໃນໄດເລກະທໍລີ /app ໃນຖັງ.

ຕໍ່ໄປ: -v /tmp/app/var/run/secrets:/var/run/secrets — ເພື່ອຕິດໄດເລກະທໍລີດ້ວຍໃບຮັບຮອງ/ໂທເຄັນເຂົ້າໄປໃນຖັງ.

ທາງເລືອກນີ້ສຸດທ້າຍແມ່ນປະຕິບັດຕາມຮູບພາບທີ່ແອັບພລິເຄຊັນຈະດໍາເນີນການ. NB: ເມື່ອສ້າງຮູບພາບ, ທ່ານຕ້ອງລະບຸ CMD ຫຼື ENTRYPOINT!

ຈະເກີດຫຍັງຂຶ້ນແນ່ນອນຕໍ່ໄປ?

• ໃນ Kubernetes, ສໍາລັບການຕິດຕັ້ງທີ່ລະບຸໄວ້, ຈໍານວນຂອງ replicas ຈະຖືກປ່ຽນເປັນ 0. ແທນທີ່ຈະ, ການຈັດວາງໃຫມ່ຈະເປີດຕົວ - ມີຕົວບັນຈຸທົດແທນ. backend.
• 2 containers ຈະເປີດຕົວໃນ desktop: ທໍາອິດກັບ Telepresence (ມັນຈະ proxy ຮ້ອງຂໍຈາກ / ກັບ Kubernetes), ອັນທີສອງກັບຄໍາຮ້ອງສະຫມັກໄດ້ຖືກພັດທະນາ.
• ຖ້າພວກເຮົາປະຕິບັດເຂົ້າໄປໃນຖັງທີ່ມີຄໍາຮ້ອງສະຫມັກ, ຫຼັງຈາກນັ້ນຕົວແປ ENV ທັງຫມົດທີ່ໂອນໂດຍ Helm ໃນລະຫວ່າງການນໍາໄປໃຊ້ຈະມີໃຫ້ພວກເຮົາ, ແລະການບໍລິການທັງຫມົດຈະມີຢູ່. ສິ່ງທີ່ຍັງເຫຼືອແມ່ນການແກ້ໄຂລະຫັດໃນ IDE ທີ່ທ່ານມັກແລະເພີດເພີນກັບຜົນໄດ້ຮັບ.
• ໃນຕອນທ້າຍຂອງການເຮັດວຽກ, ທ່ານພຽງແຕ່ຕ້ອງການປິດ terminal ທີ່ Telepresence ກໍາລັງເຮັດວຽກ (ຢຸດເຊດຊັນດ້ວຍ Ctrl+C) - Docker containers ຈະຢຸດຢູ່ໃນ desktop, ແລະໃນ Kubernetes ທຸກສິ່ງທຸກຢ່າງຈະກັບຄືນສູ່ສະພາບເບື້ອງຕົ້ນຂອງມັນ. ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນຄໍາຫມັ້ນສັນຍາ, ອອກ MR ແລະໂອນໃຫ້ການທົບທວນຄືນ / merge / ... (ຂຶ້ນກັບ workflows ຂອງທ່ານ).

ຖ້າພວກເຮົາບໍ່ຕ້ອງການໃຊ້ແອັບພລິເຄຊັນໃນ Docker container - ຕົວຢ່າງ, ພວກເຮົາພັດທະນາບໍ່ໄດ້ຢູ່ໃນ PHP, ແຕ່ໃນ Go, ແລະຍັງສ້າງມັນຢູ່ໃນທ້ອງຖິ່ນ - ການເປີດຕົວ Telepresence ຈະງ່າຍດາຍກວ່າ:

telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name  }}:backend --mount=true

ຖ້າແອັບພລິເຄຊັນເຂົ້າເຖິງ Kubernetes API, ທ່ານຈະຈໍາເປັນຕ້ອງໄດ້ຕິດຕັ້ງລະບົບລະຫັດ (https://www.telepresence.io/howto/volumes). ມີຜົນປະໂຫຍດສໍາລັບ Linux ຮາກ:

proot -b $TELEPRESENCE_ROOT/var/run/secrets/:/var/run/secrets bash

ຫຼັງຈາກເປີດຕົວ Telepresence ໂດຍບໍ່ມີທາງເລືອກ --docker-run ຕົວແປສະພາບແວດລ້ອມທັງຫມົດຈະມີຢູ່ໃນ terminal ປະຈຸບັນ, ດັ່ງນັ້ນແອັບພລິເຄຊັນຕ້ອງຖືກເປີດຕົວໃນມັນ.

NB: ເມື່ອໃຊ້, ຕົວຢ່າງ, PHP, ທ່ານຕ້ອງຈື່ຈໍາທີ່ຈະປິດການໃຊ້ງານ op_cache ຕ່າງໆ, apc ແລະຕົວເລັ່ງອື່ນໆສໍາລັບການພັດທະນາ - ຖ້າບໍ່ດັ່ງນັ້ນການແກ້ໄຂລະຫັດຈະບໍ່ນໍາໄປສູ່ຜົນໄດ້ຮັບທີ່ຕ້ອງການ.

ຜົນໄດ້ຮັບ

ການພັດທະນາທ້ອງຖິ່ນກັບ Kubernetes ແມ່ນບັນຫາທີ່ການແກ້ໄຂແມ່ນການຂະຫຍາຍຕົວໃນອັດຕາສ່ວນຂອງການແຜ່ກະຈາຍຂອງເວທີນີ້. ໄດ້ຮັບການຮ້ອງຂໍທີ່ກ່ຽວຂ້ອງຈາກນັກພັດທະນາ (ຈາກລູກຄ້າຂອງພວກເຮົາ), ພວກເຮົາເລີ່ມແກ້ໄຂພວກມັນດ້ວຍວິທີທໍາອິດທີ່ມີຢູ່, ເຊິ່ງ, ແນວໃດກໍ່ຕາມ, ບໍ່ໄດ້ພິສູດຕົວເອງໃນໄລຍະຍາວ. ໂຊກດີ, ນີ້ໄດ້ກາຍເປັນທີ່ຊັດເຈນບໍ່ພຽງແຕ່ໃນປັດຈຸບັນແລະບໍ່ພຽງແຕ່ສໍາລັບພວກເຮົາ, ສະນັ້ນວິທີການທີ່ເຫມາະສົມຫຼາຍໄດ້ປາກົດຢູ່ໃນໂລກ, ແລະ Telepresence ແມ່ນມີຊື່ສຽງທີ່ສຸດ (ໂດຍວິທີທາງການ, ຍັງມີ. skaffold ຈາກ Google). ປະສົບການຂອງພວກເຮົາໃນການນໍາໃຊ້ມັນຍັງບໍ່ທັນດີຫຼາຍ, ແຕ່ມັນເຮັດໃຫ້ພວກເຮົາມີເຫດຜົນທີ່ຈະແນະນໍາໃຫ້ "ເພື່ອນຮ່ວມງານໃນຮ້ານ" ຂອງພວກເຮົາ - ລອງມັນ!

PS

ອື່ນໆຈາກຊຸດເຄັດລັບ ແລະເຄັດລັບຂອງ K8s:

• «ຄຳແນະນຳ ແລະເຄັດລັບ Kubernetes: ໜ້າຂໍ້ຜິດພາດແບບກຳນົດເອງໃນ NGINX Ingress"
• «ການໂອນຊັບພະຍາກອນທີ່ເຮັດວຽກຢູ່ໃນກຸ່ມໄປຫາການຈັດການ Helm 2"
• «ກ່ຽວກັບການຈັດສັນ node ແລະການໂຫຼດໃນແອັບພລິເຄຊັນເວັບ"
• «ການເຂົ້າເຖິງເວັບໄຊທ໌ dev"
• «ເລັ່ງ bootstrap ສໍາລັບຖານຂໍ້ມູນຂະຫນາດໃຫຍ່".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com