Kubernetes-ის რჩევები და ხრიკები: ადგილობრივი განვითარებისა და ტელეყოფის შესახებ

ჩვენ სულ უფრო ხშირად გვეკითხებიან Kubernetes-ში მიკროსერვისების განვითარების შესახებ. დეველოპერებს, განსაკუთრებით ინტერპრეტირებული ენების, სურთ სწრაფად შეასწორონ კოდი მათ საყვარელ IDE-ში და ნახონ შედეგი build/deployment-ის მოლოდინის გარეშე - უბრალოდ F5-ზე დაჭერით. და რაც შეეხება მონოლითურ აპლიკაციას, საკმარისი იყო ლოკალურად დააინსტალიროთ მონაცემთა ბაზა და ვებ სერვერი (Docker-ში, VirtualBox...) და შემდეგ დაუყოვნებლივ ისიამოვნოთ განვითარებით. მონოლითების მიკროსერვისებად დაჭრით და კუბერნეტის მოსვლასთან ერთად, ერთმანეთზე დამოკიდებულების გამოჩენით, ყველაფერი ცოტა გართულდა. რაც მეტია ეს მიკროსერვისი, მით მეტი პრობლემაა. განვითარებით ხელახლა სარგებლობისთვის საჭიროა დოკერის ერთ ან ორზე მეტი კონტეინერის აწევა, ზოგჯერ კი ათზე მეტი... ზოგადად, ამ ყველაფერს შეიძლება საკმაოდ დიდი დრო დასჭირდეს, რადგან მას ასევე სჭირდება განახლება. .

სხვადასხვა დროს ჩვენ ვცდილობდით პრობლემის სხვადასხვა გადაწყვეტას. და დავიწყებ დაგროვილი გადაჭრით ან უბრალოდ "ყავარჯნებით".

1. ხელჯოხები

IDE-ების უმეტესობას აქვს შესაძლებლობა შეცვალონ კოდი პირდაპირ სერვერზე FTP/SFTP გამოყენებით. ეს გზა ძალიან აშკარაა და ჩვენ მაშინვე გადავწყვიტეთ მისი გამოყენება. მისი არსი ემყარება შემდეგს:

1. დეველოპერული გარემოს განყოფილებაში (დევ/მიმოხილვა) იხსნება დამატებითი კონტეინერი SSH წვდომით და დეველოპერის საჯარო SSH გასაღების გადამისამართებით, რომელიც განახორციელებს აპლიკაციას/განათავსებს.
2. საწყის ეტაპზე (კონტეინერის შიგნით prepare-app) გადაიტანეთ კოდი emptyDirრომ ჰქონდეს წვდომა კოდზე განაცხადის კონტეინერებიდან და SSH სერვერიდან.

ასეთი სქემის ტექნიკური განხორციელების უკეთ გასაგებად, მე შემოგთავაზებთ ჩართული YAML კონფიგურაციების ფრაგმენტებს Kubernetes-ში.

კონფიგურაციები

1.1. ღირებულებები.yaml

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

აქ vasya.pupkin არის ცვლადის მნიშვნელობა ${GITLAB_USER_LOGIN}.

1.2. განლაგება.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. საიდუმლო.იამლი

{{ 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: დეველოპერს, რომელმაც დაიწყო განლაგება, შეუძლია დაუკავშირდეს სერვისის სახელით (როგორ უსაფრთხოდ მიანიჭოს წვდომა კლასტერზე, ჩვენ უკვე ვუთხარით) თქვენი დესკტოპიდან SFTP-ის საშუალებით და დაარედაქტირეთ კოდი კლასტერში მის მიწოდების მოლოდინის გარეშე.

ეს არის სრულიად სამუშაო გადაწყვეტა, მაგრამ განხორციელების თვალსაზრისით მას აქვს აშკარა უარყოფითი მხარეები:

• Helm სქემის დახვეწის აუცილებლობა, რაც ართულებს მომავალში კითხვას;
• შეიძლება გამოიყენოს მხოლოდ ის, ვინც განათავსა სერვისი;
• თქვენ უნდა დაიმახსოვროთ, რომ შემდეგ სინქრონიზაცია მოახდინოთ ადგილობრივ დირექტორიასთან კოდით და ჩააბაროთ იგი Git-ზე.

2. ტელეარსება

პროექტი ტელეპრესენს საკმაოდ დიდი ხანია ცნობილია, მაგრამ ჩვენ, როგორც ამბობენ, "პრაქტიკაში სერიოზულად არ გამოგვეცადა". თუმცა, მოთხოვნამ თავისი საქმე შეასრულა და ახლა ჩვენ მოხარული ვართ გაგიზიაროთ ჩვენი გამოცდილება, რაც შეიძლება სასარგებლო იყოს ჩვენი ბლოგის მკითხველებისთვის - მით უმეტეს, რომ ტელეპრესენსის შესახებ სხვა მასალები ჯერ არ ყოფილა ჰაბზე.

მოკლედ, ყველაფერი არც ისე საშინელი აღმოჩნდა. ჩვენ განვათავსეთ ყველა ქმედება, რომელიც საჭიროებს შესრულებას დეველოპერის მხრიდან Helm chart ტექსტურ ფაილში, სახელწოდებით NOTES.txt. ამრიგად, Kubernetes-ზე სერვისის განლაგების შემდეგ, დეველოპერი ხედავს ინსტრუქციებს ადგილობრივი დეველოპერის გარემოს გაშვებისთვის 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-თან

გაშვებისას (ზემოთ ინსტრუქციებში მითითებული ბოლო ბრძანების გამოყენებით), ჩვენ ვაყენებთ:

• სახელთა სივრცე, რომელშიც მიკროსერვისი მუშაობს;
• განლაგების და კონტეინერის სახელები, რომლებშიც გვინდა შეღწევა.

დარჩენილი არგუმენტები არჩევითია. თუ ჩვენი სერვისი ურთიერთქმედებს Kubernetes API-სთან და მასზე სერვისის ანგარიში შეიქმნა, ჩვენ უნდა დავამონტაჟოთ სერთიფიკატები/ტოკენები ჩვენს სამუშაო მაგიდაზე. ამისათვის გამოიყენეთ ვარიანტი --mount=true (ან --mount=/dst_path), რომელიც დაამონტაჟებს ფესვს (/) Kubernetes კონტეინერიდან ჩვენს სამუშაო მაგიდაზე. ამის შემდეგ, ჩვენ შეგვიძლია (დამოკიდებულია OS-დან და როგორ არის აპლიკაცია გაშვებული) გამოვიყენოთ კლასტერიდან „გასაღებები“.

პირველ რიგში, მოდით შევხედოთ აპლიკაციის გაშვების ყველაზე უნივერსალურ ვარიანტს - Docker კონტეინერში. ამისათვის ჩვენ გამოვიყენებთ გასაღებს --docker-run და დააინსტალირეთ დირექტორია კოდით კონტეინერში: -v `pwd`:/app

გთხოვთ გაითვალისწინოთ, რომ ეს ითვალისწინებს გაშვებას პროექტის დირექტორიადან. განაცხადის კოდი დამონტაჟდება დირექტორიაში /app კონტეინერში.

შემდეგი: -v /tmp/app/var/run/secrets:/var/run/secrets — სერთიფიკატის/ჟეტონის მქონე დირექტორია კონტეინერში ჩასართავად.

ამ ოფციას ბოლოს მოჰყვება სურათი, რომელშიც აპლიკაცია იმუშავებს. NB: სურათის აგებისას უნდა მიუთითოთ CMD ან ENTRYPOINT!

კონკრეტულად რა მოხდება შემდეგ?

• Kubernetes-ში, მითითებული განლაგებისთვის, ასლების რაოდენობა შეიცვლება 0-მდე. ამის ნაცვლად, ამოქმედდება ახალი Deployment - შემცვლელი კონტეინერით. backend.
• დესკტოპზე 2 კონტეინერი ამოქმედდება: პირველი Telepresence-ით (ის კუბერნეტესიდან/კუბერნეტის პროქსის მოთხოვნით), მეორე აპლიკაციის შემუშავებით.
• თუ ჩვენ შევასრულებთ აპლიკაციის კონტეინერს, მაშინ Helm-ის მიერ განლაგების დროს გადაცემული ყველა ENV ცვლადი ხელმისაწვდომი იქნება ჩვენთვის და ასევე ხელმისაწვდომი იქნება ყველა სერვისი. რჩება მხოლოდ კოდის რედაქტირება თქვენს საყვარელ IDE-ში და ისიამოვნეთ შედეგით.
• სამუშაოს დასასრულს, თქვენ უბრალოდ უნდა დახუროთ ტერმინალი, რომელშიც Telepresence მუშაობს (შეასრულეთ სესია Ctrl+C-ით) - Docker კონტეინერები გაჩერდება სამუშაო მაგიდაზე, ხოლო Kubernetes-ში ყველაფერი დაუბრუნდება საწყის მდგომარეობას. რჩება მხოლოდ ჩადენა, MR-ის გაცემა და მისი გადაცემა განხილვის/შერწყმის/… (დამოკიდებულია თქვენი სამუშაო პროცესებიდან).

თუ არ გვინდა აპლიკაციის გაშვება Docker კონტეინერში - მაგალითად, ჩვენ ვვითარდებით არა 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 ყველა გარემოს ცვლადი ხელმისაწვდომი იქნება მიმდინარე ტერმინალში, ამიტომ აპლიკაცია მასში უნდა ამოქმედდეს.

NB: მაგალითად, PHP-ის გამოყენებისას უნდა გახსოვდეთ, რომ გამორთოთ სხვადასხვა op_cache, apc და სხვა ამაჩქარებლები განვითარებისთვის - წინააღმდეგ შემთხვევაში კოდის რედაქტირება არ გამოიწვევს სასურველ შედეგს.

შედეგები

ადგილობრივი განვითარება Kubernetes-თან არის პრობლემა, რომლის გადაწყვეტაც იზრდება ამ პლატფორმის გავრცელების პროპორციულად. დეველოპერებისგან (ჩვენი კლიენტებისგან) შესაბამისი მოთხოვნების მიღებით, ჩვენ დავიწყეთ მათი გადაჭრა პირველი ხელმისაწვდომი საშუალებებით, რაც, თუმცა, გრძელვადიან პერსპექტივაში არ დაამტკიცა. საბედნიეროდ, ეს აშკარა გახდა არა მხოლოდ ახლა და არა მხოლოდ ჩვენთვის, ამიტომ მსოფლიოში უკვე გამოჩნდა უფრო შესაფერისი საშუალებები და მათგან ყველაზე ცნობილია Telepresence (სხვათა შორის, არსებობს ასევე ხარაჩო Google-ისგან). მისი გამოყენების ჩვენი გამოცდილება ჯერ არც ისე დიდია, მაგრამ უკვე გვაძლევს საფუძველს, რომ ვურჩიოთ ის ჩვენს "მაღაზიაში კოლეგებს" - სცადეთ!

PS

სხვა K8s რჩევებისა და ხრიკების სერიიდან:

• «Kubernetes-ის რჩევები და ხრიკები: მორგებული შეცდომების გვერდები NGINX Ingress-ში";
• «კლასტერში გაშვებული რესურსების გადაცემა Helm 2 მენეჯმენტზე";
• «ვებ აპლიკაციაში კვანძების განაწილებისა და ჩატვირთვის შესახებ";
• «დეველოპერის საიტებზე წვდომა";
• «ჩატვირთვის დაჩქარება დიდი მონაცემთა ბაზებისთვის".

წყარო: www.habr.com