Kubernetes'те микросервистерди өнүктүрүү жөнүндө бизден көбүрөөк сурашат. Айрыкча чечмеленген тилдерди иштеп чыгуучулар өздөрүнүн сүйүктүү IDEиндеги кодду тез оңдоону жана түзүүнү/жайгаштырууну күтпөстөн жыйынтыкты көрүүнү каалашат - жөн гана F5 баскычын басуу. Ал эми монолиттүү тиркемеге келгенде, маалымат базасын жана веб-серверди (Docker, VirtualBoxта...) локалдык түрдө орнотуу жетиштүү болду, андан кийин дароо өнүгүүдөн ырахат алыңыз. Монолиттердин микросервистерге кесилиши жана Кубернеттердин келиши менен бири-бирине көз карандылыктын пайда болушу менен баары . Бул микросервистердин саны канчалык көп болсо, ошончолук көйгөйлөр көбөйөт. Кайра иштеп чыгуудан ырахат алуу үчүн бир же экиден ашык, кээде ондон ашык Docker контейнерин көтөрүшүңүз керек... Жалпысынан мунун баары бир топ убакытты талап кылышы мүмкүн, анткени аны да жаңыртып туруу керек. .
Ар кайсы убакта биз көйгөйдү чечүүнүн ар кандай жолдорун сынап көрдүк. Ал эми топтолгон чечүү жолдору же жөн эле "балдак" менен баштайм.
1. Балдак
Көпчүлүк IDE FTP/SFTP аркылуу түз серверде кодду түзөтүү мүмкүнчүлүгүнө ээ. Бул жол абдан ачык жана биз дароо аны колдонууну чечтик. Анын маңызы төмөнкүдөй:
- Өнүктүрүү чөйрөлөрүнүн капчыгында (иштеп чыгуу/карап чыгуу) кошумча контейнер SSH мүмкүнчүлүгү менен ишке киргизилет жана колдонмону ишке ашыра турган/жайгаша турган иштеп чыгуучунун ачык SSH ачкычын жөнөтөт.
- Баштапкы этапта (контейнердин ичинде
prepare-app) кодду жөнөтүңүзemptyDirколдонмо контейнерлеринен жана SSH серверинен кодго жетүү үчүн.
Мындай схеманын техникалык ишке ашырылышын жакшыраак түшүнүү үчүн, мен Kubernetes'те тартылган YAML конфигурацияларынын фрагменттерин берем.
Конфигурациялар
1.1. баалуулуктар.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 }}
Акыркы тийүү
Андан кийин гана өткөрүп берүү гана калды :
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 жөнүндө башка материалдар жок болгондуктан.
Кыскасы, баары анча деле коркунучтуу эмес болуп чыкты. Биз иштеп чыгуучу тарабынан аткарылышын талап кылган бардык аракеттерди 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 менен иштөө
Ишке киргизүүдө (жогоруда көрсөтүлгөн нускамада көрсөтүлгөн акыркы буйрукту колдонуу менен), биз төмөнкүлөрдү орнотобуз:
- микросервис иштеп жаткан аттар мейкиндиги;
- жайгаштыруунун жана биз киргиси келген контейнердин аттары.
Калган аргументтер милдеттүү эмес. Биздин кызмат 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гө өзгөртүлөт. Анын ордуна, алмаштыруучу контейнер менен жаңы Жайгаштыруу ишке киргизилет.
backend. - Иш тактасында 2 контейнер ишке киргизилет: биринчиси Telepresence менен (ал Kubernetesтен/кубернетеске прокси сурамдарды берет), экинчиси иштелип жаткан тиркеме менен.
- Эгер биз колдонмо менен контейнерге киргизсек, анда Helm тарабынан жайылтуу учурунда берилген бардык ENV өзгөрмөлөрү бизге жеткиликтүү болот жана бардык кызматтар да жеткиликтүү болот. Сүйүктүү IDEдеги кодду түзөтүп, натыйжадан ырахат алуу гана калды.
- Жумуштун аягында сиз жөн гана Telepresence иштеп жаткан терминалды жабышыңыз керек (сеансты Ctrl+C менен токтотуу) - Докер контейнерлери иш тактасында токтойт, ал эми Kubernetesте баары баштапкы абалына кайтып келет. Болгону, МРди тапшыруу, чыгаруу жана аны карап чыгууга/бириктирүүгө/… (иш процесстериңизге жараша) өткөрүп берүү гана калды.
Эгерде биз тиркемени 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 кеңештер жана ыкмалар сериясынан башка:
- «";
- «";
- «";
- «";
- ««.
Source: www.habr.com