🥇Kubernetes គន្លឹះ និងល្បិច៖ អំពីការអភិវឌ្ឍន៍ក្នុងស្រុក និង Telepresence

យើងត្រូវបានគេសួរកាន់តែខ្លាំងឡើងអំពីការអភិវឌ្ឍសេវាមីក្រូនៅក្នុង Kubernetes។ អ្នកអភិវឌ្ឍន៍ ជាពិសេសភាសាដែលបានបកប្រែចង់កែកូដយ៉ាងឆាប់រហ័សនៅក្នុង IDE ដែលពួកគេចូលចិត្ត ហើយឃើញលទ្ធផលដោយមិនចាំបាច់រង់ចាំការស្ថាបនា/ដាក់ឱ្យប្រើប្រាស់នោះទេ ដោយគ្រាន់តែចុច F5។ ហើយនៅពេលដែលវាមកដល់កម្មវិធី monolithic វាគ្រប់គ្រាន់ក្នុងការដំឡើងមូលដ្ឋានទិន្នន័យ និងម៉ាស៊ីនមេបណ្តាញ (នៅក្នុង Docker, VirtualBox...) ហើយបន្ទាប់មករីករាយនឹងការអភិវឌ្ឍន៍ភ្លាមៗ។ ជាមួយនឹងការកាត់ monoliths ចូលទៅក្នុង microservices និងការមកដល់នៃ Kubernetes ជាមួយនឹងរូបរាងនៃភាពអាស្រ័យគ្នាទៅវិញទៅមក អ្វីគ្រប់យ៉ាង វាកាន់តែពិបាកបន្តិច. សេវាមីក្រូទាំងនេះកាន់តែច្រើន បញ្ហាកាន់តែច្រើន។ ដើម្បីរីករាយនឹងការអភិវឌ្ឍន៍ម្តងទៀត អ្នកត្រូវលើកធុង Docker ច្រើនជាងមួយ ឬពីរ ហើយជួនកាលលើសពីដប់មួយ... ជាទូទៅ អ្វីៗទាំងអស់នេះអាចចំណាយពេលច្រើនណាស់ ព្រោះវាក៏ត្រូវរក្សាឱ្យទាន់សម័យផងដែរ។ .

នៅពេលផ្សេងគ្នា យើងបានព្យាយាមដំណោះស្រាយផ្សេងគ្នាចំពោះបញ្ហា។ ហើយខ្ញុំនឹងចាប់ផ្តើមជាមួយនឹងការដោះស្រាយដែលបានប្រមូលផ្តុំឬជាសាមញ្ញទៅនឹង "ឈើច្រត់"។

1. ឈើច្រត់

IDE ភាគច្រើនមានសមត្ថភាពក្នុងការកែសម្រួលកូដដោយផ្ទាល់នៅលើម៉ាស៊ីនមេដោយប្រើ FTP/SFTP ។ ផ្លូវនេះគឺច្បាស់ណាស់ ហើយយើងក៏សម្រេចចិត្តប្រើវាភ្លាមៗ។ ខ្លឹមសាររបស់វាមានដូចខាងក្រោម៖

នៅក្នុងផ្នែកនៃបរិស្ថានអភិវឌ្ឍន៍ (dev/review) កុងតឺន័របន្ថែមមួយត្រូវបានបើកដំណើរការជាមួយនឹងការចូលប្រើ SSH និងបញ្ជូនបន្តនូវ SSH key សាធារណៈរបស់អ្នកអភិវឌ្ឍន៍ដែលនឹងប្រព្រឹត្ត/ដាក់ឱ្យប្រើប្រាស់កម្មវិធី។
នៅដំណាក់កាលដំបូង (នៅក្នុងធុង prepare-app) ផ្ទេរលេខកូដទៅ emptyDirដើម្បីមានសិទ្ធិចូលប្រើកូដពីធុងកម្មវិធី និងម៉ាស៊ីនមេ SSH ។

ដើម្បីយល់កាន់តែច្បាស់អំពីការអនុវត្តបច្ចេកទេសនៃគ្រោងការណ៍បែបនេះ ខ្ញុំនឹងផ្តល់នូវបំណែកនៃការកំណត់រចនាសម្ព័ន្ធ YAML ដែលពាក់ព័ន្ធនៅក្នុង Kubernetes ។

ការកំណត់រចនាសម្ព័ន្ធ

១.១. values.yaml

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

វាគឺជាការ vasya.pupkin គឺជាតម្លៃនៃអថេរ ${GITLAB_USER_LOGIN}.

១.២. 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"]
...

១.៣. 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៖ អ្នកអភិវឌ្ឍន៍ដែលបានចាប់ផ្ដើមការដាក់ពង្រាយអាចតភ្ជាប់តាមឈ្មោះសេវា (របៀបផ្ដល់សិទ្ធិចូលប្រើចង្កោមដោយសុវត្ថិភាព។ យើងបានប្រាប់រួចហើយ) ពីផ្ទៃតុរបស់អ្នកតាមរយៈ SFTP ហើយកែសម្រួលកូដដោយមិនរង់ចាំវាត្រូវបានបញ្ជូនទៅក្រុម។

នេះគឺជាដំណោះស្រាយដែលដំណើរការទាំងស្រុង ប៉ុន្តែតាមទស្សនៈនៃការអនុវត្ត វាមានគុណវិបត្តិជាក់ស្តែង៖

តម្រូវការក្នុងការកែលម្អតារាង Helm ដែលធ្វើឱ្យវាពិបាកក្នុងការអាននាពេលអនាគត។
អាចប្រើបានតែដោយអ្នកដែលបានដាក់ពង្រាយសេវាកម្មតែប៉ុណ្ណោះ។
អ្នកត្រូវចាំថាធ្វើសមកាលកម្មវាជាមួយថតមូលដ្ឋានជាមួយកូដ ហើយផ្ទេរវាទៅ Git ។

2. Telepresence

គម្រោង តេលេហ្វ្រេនសិន ត្រូវបានគេស្គាល់ជាយូរមកហើយ ប៉ុន្តែយើងដូចជាពួកគេនិយាយថា "មិនបានចូលរួមដើម្បីសាកល្បងវាយ៉ាងខ្លាំងក្នុងការអនុវត្តទេ"។ ទោះជាយ៉ាងណាក៏ដោយ តម្រូវការបានបំពេញការងាររបស់ខ្លួន ហើយឥឡូវនេះ យើងរីករាយក្នុងការចែករំលែកបទពិសោធន៍របស់យើង ដែលប្រហែលជាមានប្រយោជន៍សម្រាប់អ្នកអានប្លក់របស់យើង ជាពិសេសចាប់តាំងពីមិនទាន់មានឯកសារផ្សេងទៀតអំពី Telepresence នៅលើមជ្ឈមណ្ឌលនៅឡើយ។

សរុបមក អ្វីៗបានប្រែទៅជាមិនគួរឱ្យខ្លាចនោះទេ។ យើងបានដាក់សកម្មភាពទាំងអស់ដែលតម្រូវឱ្យប្រតិបត្តិលើផ្នែកនៃអ្នកអភិវឌ្ឍន៍នៅក្នុងឯកសារអត្ថបទគំនូសតាង Helm ដែលហៅថា 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

នៅពេលចាប់ផ្តើម (ដោយប្រើពាក្យបញ្ជាចុងក្រោយដែលបានបញ្ជាក់នៅក្នុងការណែនាំខាងលើ) យើងកំណត់:

namespace ដែល microservice កំពុងដំណើរការ;
ឈ្មោះនៃការដាក់ពង្រាយ និងកុងតឺន័រដែលយើងចង់ជ្រាបចូល។

អាគុយម៉ង់ដែលនៅសល់គឺស្រេចចិត្ត។ ប្រសិនបើសេវាកម្មរបស់យើងធ្វើអន្តរកម្មជាមួយ និងសម្រាប់ Kubernetes API គណនីសេវាកម្មត្រូវបានបង្កើតឡើងយើងត្រូវភ្ជាប់វិញ្ញាបនបត្រ/ថូខឹននៅលើផ្ទៃតុរបស់យើង។ ដើម្បីធ្វើដូចនេះសូមប្រើជម្រើស --mount=true (ឬ --mount=/dst_path) ដែលនឹងម៉ោនឫស (/) ពីកុងតឺន័រ Kubernetes ទៅកាន់ផ្ទៃតុរបស់យើង។ បន្ទាប់ពីនេះ យើងអាច (អាស្រ័យលើ OS និងរបៀបដែលកម្មវិធីត្រូវបានដាក់ឱ្យដំណើរការ) ប្រើ "កូនសោ" ពីចង្កោម។

ជាដំបូង សូមក្រឡេកមើលជម្រើសសកលបំផុតសម្រាប់ការដំណើរការកម្មវិធី - នៅក្នុង Docker container។ ដើម្បីធ្វើដូចនេះយើងនឹងប្រើគន្លឹះ --docker-run ហើយភ្ជាប់ថតជាមួយលេខកូដទៅក្នុងកុងតឺន័រ៖ -v `pwd`:/app

សូមចំណាំថាវាសន្មត់ថាដំណើរការពីថតគម្រោង។ លេខកូដកម្មវិធីនឹងត្រូវបានម៉ោននៅក្នុងថត /app នៅក្នុងធុងមួយ។

បន្ទាប់: -v /tmp/app/var/run/secrets:/var/run/secrets - ដើម្បីភ្ជាប់ថតជាមួយវិញ្ញាបនបត្រ/សញ្ញាសម្ងាត់ទៅក្នុងកុងតឺន័រ។

ជម្រើសនេះត្រូវតាមពីក្រោយដោយរូបភាពដែលកម្មវិធីនឹងដំណើរការ។ NB៖ នៅពេលបង្កើតរូបភាព អ្នកត្រូវតែបញ្ជាក់ CMD ឬ ENTRYPOINT!

តើនឹងមានអ្វីកើតឡើងបន្ទាប់ទៀត?

នៅក្នុង Kubernetes សម្រាប់ការដាក់ឱ្យប្រើប្រាស់ដែលបានបញ្ជាក់ ចំនួននៃការចម្លងនឹងត្រូវបានប្តូរទៅជា 0។ ជំនួសមកវិញ ការដាក់ឱ្យប្រើប្រាស់ថ្មីនឹងត្រូវបានដាក់ឱ្យដំណើរការ - ជាមួយនឹងកុងតឺន័រជំនួស backend.
ធុង 2 នឹងបើកដំណើរការលើផ្ទៃតុ៖ ទីមួយជាមួយ Telepresence (វានឹងស្នើសុំប្រូកស៊ីពី/ទៅ Kubernetes) ទីពីរជាមួយនឹងកម្មវិធីដែលកំពុងត្រូវបានបង្កើត។
ប្រសិនបើយើងប្រតិបត្តិទៅក្នុងកុងតឺន័រជាមួយនឹងកម្មវិធី នោះអថេរ ENV ទាំងអស់ដែលបានផ្ទេរដោយ Helm កំឡុងពេលដាក់ពង្រាយនឹងមានសម្រាប់ពួកយើង ហើយសេវាកម្មទាំងអស់ក៏នឹងមានផងដែរ។ អ្វីដែលនៅសល់គឺការកែសម្រួលកូដនៅក្នុង IDE ដែលអ្នកចូលចិត្ត ហើយរីករាយនឹងលទ្ធផល។
នៅចុងបញ្ចប់នៃការងារ អ្នកគ្រាន់តែត្រូវបិទស្ថានីយដែល Telepresence កំពុងដំណើរការ (បញ្ចប់វគ្គដោយប្រើ Ctrl+C) - Docker containers នឹងឈប់នៅលើផ្ទៃតុ ហើយនៅក្នុង Kubernetes អ្វីៗនឹងត្រលប់ទៅសភាពដើមវិញ។ អ្វីដែលនៅសល់គឺការប្តេជ្ញាចិត្ត ចេញ MR ហើយផ្ទេរវាទៅពិនិត្យ/បញ្ចូល/… (អាស្រ័យលើលំហូរការងាររបស់អ្នក)។

ប្រសិនបើយើងមិនចង់ដំណើរការកម្មវិធីនៅក្នុង 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)។ មានឧបករណ៍ប្រើប្រាស់សម្រាប់លីនុច ឫស:

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

បន្ទាប់ពីបើកដំណើរការ Telepresence ដោយគ្មានជម្រើស --docker-run អថេរបរិស្ថានទាំងអស់នឹងមាននៅក្នុងស្ថានីយបច្ចុប្បន្ន ដូច្នេះកម្មវិធីត្រូវតែបើកដំណើរការនៅក្នុងវា។

NB៖ នៅពេលប្រើឧទាហរណ៍ PHP អ្នកត្រូវតែចងចាំដើម្បីបិទ op_cache, apc និងឧបករណ៍បង្កើនល្បឿនផ្សេងៗសម្រាប់ការអភិវឌ្ឍន៍ - បើមិនដូច្នេះទេការកែសម្រួលកូដនឹងមិននាំទៅរកលទ្ធផលដែលចង់បានទេ។

លទ្ធផល

ការអភិវឌ្ឍន៍ក្នុងតំបន់ជាមួយ Kubernetes គឺជាបញ្ហាដែលដំណោះស្រាយកំពុងកើនឡើងសមាមាត្រទៅនឹងការរីករាលដាលនៃវេទិកានេះ។ ដោយទទួលបានសំណើដែលពាក់ព័ន្ធពីអ្នកអភិវឌ្ឍន៍ (ពីអតិថិជនរបស់យើង) យើងបានចាប់ផ្តើមដោះស្រាយវាជាមួយនឹងមធ្យោបាយដែលអាចរកបានដំបូង ដែលទោះជាយ៉ាងណា វាមិនបានបង្ហាញឱ្យឃើញពីខ្លួនឯងក្នុងរយៈពេលយូរនោះទេ។ ជាសំណាងល្អ នេះបានក្លាយជាជាក់ស្តែងមិនត្រឹមតែឥឡូវនេះ និងមិនត្រឹមតែសម្រាប់យើងប៉ុណ្ណោះទេ ដូច្នេះមធ្យោបាយដែលសមរម្យជាងនេះ បានបង្ហាញខ្លួននៅក្នុងពិភពលោករួចហើយ ហើយ Telepresence គឺល្បីល្បាញបំផុតក្នុងចំណោមពួកគេ (ដោយវិធីនេះ ក៏មានផងដែរ skaffold ពី Google) ។ បទពិសោធន៍របស់យើងក្នុងការប្រើប្រាស់វាមិនទាន់អស្ចារ្យនៅឡើយទេ ប៉ុន្តែវាផ្តល់ហេតុផលដល់យើងក្នុងការណែនាំវាដល់ "មិត្តរួមការងារនៅក្នុងហាង" របស់យើង - សាកល្បងវា!

PS

ផ្សេងទៀតពីស៊េរីគន្លឹះ និងល្បិច K8s៖

ប្រភព: www.habr.com

គន្លឹះ និងល្បិច Kubernetes៖ អំពីការអភិវឌ្ឍន៍ក្នុងស្រុក និង Telepresence