A dh 'aindeoin gu bheil fios aig a h-uile duine gu math gu bheil deuchainn air a' bhathar-bog agad cudromach agus riatanach, agus tha mòran air a bhith ga dhèanamh gu fèin-obrachail airson ùine mhòr, ann am farsaingeachd Habr cha robh aon reasabaidh ann airson a bhith a 'stèidheachadh measgachadh de thoraidhean cho measail ann an an àite seo mar (am fear as fheàrr leinn) GitLab agus JUnit . Nach lìon sinn a’ bheàrn seo!
Ro-ràdhach
An toiseach, leig dhomh beagan co-theacsa a thoirt seachad:
Leis gu bheil na tagraidhean againn uile a’ ruith air Kubernetes, beachdaichidh sinn air deuchainnean a ruith air a’ bhun-structar iomchaidh.
Airson co-chruinneachadh agus cleachdadh bidh sinn a 'cleachdadh gaoir (a thaobh co-phàirtean bun-structair, tha seo cuideachd a 'ciallachadh gu bheil Helm an sàs).
Cha tèid mi a-steach don fhiosrachadh mu chruthachadh fìor dheuchainnean: anns a ’chùis againn, bidh an neach-dèiligidh a’ sgrìobhadh na deuchainnean e fhèin, agus cha bhith sinn a ’dèanamh cinnteach ach gun tèid an cur air bhog (agus làthaireachd aithisg co-fhreagarrach san iarrtas aonaidh).
Cò ris a bhios an t-sreath choitcheann de ghnìomhan coltach?
A 'togail an tagraidh - fàgaidh sinn an tuairisgeul air an ìre seo.
Cuir an tagradh gu àite ainm air leth de bhuidheann Kubernetes agus tòisich air deuchainn.
A’ lorg artifacts agus a’ parsadh aithisgean JUnit le GitLab.
A' sguabadh às àite ainm a chaidh a chruthachadh roimhe.
A-nis - gu buileachadh!
adjustment
GitLab CI
Feuch an tòisich sinn le criomag .gitlab-ci.yaml, a tha a 'toirt cunntas air cleachdadh an tagraidh agus a' ruith dheuchainnean. Bha an liosta gu math mòr, agus mar sin chaidh a chur ris gu mionaideach le beachdan:
variables:
# объявляем версию werf, которую собираемся использовать
WERF_VERSION: "1.0 beta"
.base_deploy: &base_deploy
script:
# создаем namespace в K8s, если его нет
- kubectl --context="${WERF_KUBE_CONTEXT}" get ns ${CI_ENVIRONMENT_SLUG} || kubectl create ns ${CI_ENVIRONMENT_SLUG}
# загружаем werf и деплоим — подробнее об этом см. в документации
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#deploy-stage)
- type multiwerf && source <(multiwerf use ${WERF_VERSION})
- werf version
- type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
- werf deploy --stages-storage :local
--namespace ${CI_ENVIRONMENT_SLUG}
--set "global.commit_ref_slug=${CI_COMMIT_REF_SLUG:-''}"
# передаем переменную `run_tests`
# она будет использоваться в рендере Helm-релиза
--set "global.run_tests=${RUN_TESTS:-no}"
--set "global.env=${CI_ENVIRONMENT_SLUG}"
# изменяем timeout (бывают долгие тесты) и передаем его в релиз
--set "global.ci_timeout=${CI_TIMEOUT:-900}"
--timeout ${CI_TIMEOUT:-900}
dependencies:
- Build
.test-base: &test-base
extends: .base_deploy
before_script:
# создаем директорию для будущего отчета, исходя из $CI_COMMIT_REF_SLUG
- mkdir /mnt/tests/${CI_COMMIT_REF_SLUG} || true
# вынужденный костыль, т.к. GitLab хочет получить артефакты в своем build-dir’е
- mkdir ./tests || true
- ln -s /mnt/tests/${CI_COMMIT_REF_SLUG} ./tests/${CI_COMMIT_REF_SLUG}
after_script:
# после окончания тестов удаляем релиз вместе с Job’ом
# (и, возможно, его инфраструктурой)
- type multiwerf && source <(multiwerf use ${WERF_VERSION})
- werf version
- type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
- werf dismiss --namespace ${CI_ENVIRONMENT_SLUG} --with-namespace
# мы разрешаем падения, но вы можете сделать иначе
allow_failure: true
variables:
RUN_TESTS: 'yes'
# задаем контекст в werf
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#infrastructure)
WERF_KUBE_CONTEXT: 'admin@stage-cluster'
tags:
# используем раннер с тегом `werf-runner`
- werf-runner
artifacts:
# требуется собрать артефакт для того, чтобы его можно было увидеть
# в пайплайне и скачать — например, для более вдумчивого изучения
paths:
- ./tests/${CI_COMMIT_REF_SLUG}/*
# артефакты старше недели будут удалены
expire_in: 7 day
# важно: эти строки отвечают за парсинг отчета GitLab’ом
reports:
junit: ./tests/${CI_COMMIT_REF_SLUG}/report.xml
# для упрощения здесь показаны всего две стадии
# в реальности же у вас их будет больше — как минимум из-за деплоя
stages:
- build
- tests
build:
stage: build
script:
# сборка — снова по документации по werf
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#build-stage)
- type multiwerf && source <(multiwerf use ${WERF_VERSION})
- werf version
- type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
- werf build-and-publish --stages-storage :local
tags:
- werf-runner
except:
- schedules
run tests:
<<: *test-base
environment:
# "сама соль" именования namespace’а
# (https://docs.gitlab.com/ce/ci/variables/predefined_variables.html)
name: tests-${CI_COMMIT_REF_SLUG}
stage: tests
except:
- schedules
Kubernetes
A-nis anns an eòlaire .helm/templates cruthaichidh sinn YAML le Job - tests-job.yaml - gus deuchainnean a ruith agus na goireasan Kubernetes a dh’ fheumas e. Faic mìneachaidhean às deidh an liostadh:
Dè an seòrsa goireasan air a mhìneachadh san rèiteachadh seo? Nuair a bhios sinn ga chleachdadh, bidh sinn a’ cruthachadh àite-ainm sònraichte airson a’ phròiseict (tha seo air a chomharrachadh ann an .gitlab-ci.yaml - tests-${CI_COMMIT_REF_SLUG}) agus cuir a-mach e:
Mapa config le sgriobt deuchainn;
Dreuchd le tuairisgeul air a’ pod agus an stiùireadh ainmichte command, a tha dìreach a 'ruith nan deuchainnean;
PV agus PVC, a leigeas leat dàta deuchainn a stòradh.
Thoir aire don t-suidheachadh tòiseachaidh le if aig toiseach an fhollaiseach - a rèir sin, feumaidh faidhlichean YAML eile den chairt Helm leis an tagradh a bhith air am pasgadh a-steach air ais dealbhadh gus nach tèid an cleachdadh aig àm deuchainn. S e sin:
{{- if ne .Values.global.run_tests "yes" }}
---
я другой ямлик
{{- end }}
Ach, ma tha na deuchainnean feumach air beagan bun-structair (mar eisimpleir, Redis, RabbitMQ, Mongo, PostgreSQL ...) - faodaidh na YAMLn aca a bhith chan eil Tionndaidh dheth. Cuir a-steach iad ann an àrainneachd deuchainn cuideachd ... gan atharrachadh mar a chì thu iomchaidh, gu dearbh.
Cuairt mu dheireadh
Air sgàth tha co-chruinneachadh agus cleachdadh a’ cleachdadh werf fhathast ag obair a-mhàin air an t-seirbheisiche togail (le gitlab-runner), agus tha am pod le deuchainnean air a chuir air bhog air a’ mhaighstir, feumaidh tu eòlaire a chruthachadh /mnt/tests air a' mhaighstir, agus thoir do'n fhear-ruith e, mar eisimpleir, tro NFS. Gheibhear eisimpleir mionaideach le mìneachadh ann an Sgrìobhainnean airson K8.
Chan eil duine a’ toirmeasg co-roinn NFS a dhèanamh gu dìreach air gitlab-runner, agus an uairsin ga chuir suas ann am pods.
thuirt
Is dòcha gu bheil thu a ’faighneachd carson a nì thu a h-uile càil le bhith a’ cruthachadh Iob mas urrainn dhut dìreach sgriobt a ruith le deuchainnean gu dìreach air an ruitheadair sligean? Tha am freagairt gu math tearc ...
Feumaidh cuid de dheuchainnean faighinn chun bhun-structair (MongoDB, RabbitMQ, PostgreSQL, msaa) gus dearbhadh gu bheil iad ag obair gu ceart. Bidh sinn a’ dèanamh deuchainnean aonaichte - leis an dòigh-obrach seo, bidh e furasta a leithid de bhuidhnean a bharrachd a thoirt a-steach. A bharrachd air an seo, gheibh sinn àbhaisteach dòigh-obrach cleachdadh (eadhon ged a bhiodh tu a’ cleachdadh NFS, cur suas a bharrachd de chlàran).
thoradh air
Dè a chì sinn nuair a chuireas sinn an rèiteachadh ullaichte an sàs?
Seallaidh an t-iarrtas aonaidh geàrr-chunntasan airson deuchainnean a chaidh a ruith san loidhne-phìoban as ùire aige:
Faodar gach mearachd a bhriogadh an seo airson mion-fhiosrachadh:
NB: Mothaichidh an leughadair furachail gu bheil sinn a’ dèanamh deuchainn air tagradh NodeJS, agus anns na seallaidhean-sgrìn - .NET… Na gabh iongnadh: is e dìreach nuair a bha thu ag ullachadh an artaigil, cha deach mearachdan sam bith a lorg ann a bhith a’ dèanamh deuchainn air a’ chiad iarrtas, ach tha iad lorgadh ann an tè eile.
co-dhùnadh
Mar a chì thu, chan eil dad iom-fhillte!
Ann am prionnsapal, ma tha neach-cruinneachaidh shligean agad mu thràth agus gu bheil e ag obair, ach nach eil feum agad air Kubernetes, bidh e na obair eadhon nas sìmplidhe a bhith a’ ceangal deuchainn ris na tha air a mhìneachadh an seo. Agus anns Sgrìobhainnean GitLab CI gheibh thu eisimpleirean airson Ruby, Go, Gradle, Maven agus cuid eile.