Mai 27 ym mhrif neuadd cynhadledd DevOpsConf 2019, a gynhaliwyd fel rhan o'r ŵyl , fel rhan o'r adran “Cyflenwi Parhaus”, rhoddwyd adroddiad “werf - our tool for CI/CD in Kubernetes”. Mae'n sôn am y rheini problemau a heriau y mae pawb yn eu hwynebu wrth anfon i Kubernetes, yn ogystal ag am arlliwiau na fyddant efallai'n amlwg ar unwaith. Wrth ddadansoddi atebion posibl, rydym yn dangos sut mae hyn yn cael ei weithredu mewn teclyn Ffynhonnell Agored .
Ers y cyflwyniad, mae ein cyfleustodau (a elwid gynt yn dapp) wedi cyrraedd carreg filltir hanesyddol o 1000 o sêr ar GitHub - rydym yn gobeithio y bydd ei gymuned gynyddol o ddefnyddwyr yn gwneud bywyd yn haws i lawer o beirianwyr DevOps.
Felly, gadewch i ni gyflwyno (~47 munud, llawer mwy addysgiadol na'r erthygl) a'r prif ddyfyniad ohono ar ffurf testun. Ewch!
Dosbarthu cod i Kubernetes
Ni fydd y sgwrs am werff mwyach, ond am CI/CD yn Kubernetes, gan awgrymu bod ein meddalwedd wedi'i becynnu mewn cynwysyddion Docker (Siaradais am hyn yn ), a bydd K8s yn cael ei ddefnyddio i'w redeg wrth gynhyrchu (mwy am hyn yn ).
Sut olwg sydd ar ddosbarthu yn Kubernetes?
- Mae ystorfa Git gyda'r cod a chyfarwyddiadau ar gyfer ei adeiladu. Mae'r cais wedi'i ymgorffori mewn delwedd Docker a'i gyhoeddi yng Nghofrestrfa'r Docwyr.
- Mae'r un ystorfa hefyd yn cynnwys cyfarwyddiadau ar sut i ddefnyddio a rhedeg y rhaglen. Ar y cam defnyddio, anfonir y cyfarwyddiadau hyn at Kubernetes, sy'n derbyn y ddelwedd a ddymunir o'r gofrestrfa ac yn ei lansio.
- Hefyd, mae profion fel arfer. Gellir gwneud rhai o'r rhain wrth gyhoeddi delwedd. Gallwch hefyd (gan ddilyn yr un cyfarwyddiadau) ddefnyddio copi o'r cais (mewn gofod enw K8s ar wahân neu glwstwr ar wahân) a rhedeg profion yno.
- Yn olaf, mae angen system CI arnoch sy'n derbyn digwyddiadau gan Git (neu gliciau botwm) ac yn galw'r holl gamau dynodedig: adeiladu, cyhoeddi, defnyddio, profi.
Mae ychydig o nodiadau pwysig yma:
- Oherwydd mae gennym ni seilwaith digyfnewid (seilwaith digyfnewid), delwedd y cais a ddefnyddir ym mhob cam (llwyfannu, cynhyrchu, ac ati), rhaid cael un. Siaradais am hyn yn fanylach a chydag enghreifftiau. .
- Oherwydd ein bod yn dilyn y seilwaith fel dull cod (IaC), y cod cais, dylai cyfarwyddiadau ar gyfer cydosod a lansio ei fod yn union mewn un ystorfa. Am ragor o wybodaeth am hyn, gweler .
- Cadwyn ddosbarthu (cyflenwi) rydym fel arfer yn ei weld fel hyn: cafodd y cais ei ymgynnull, ei brofi, ei ryddhau (cam rhyddhau) a dyna ni - mae danfoniad wedi digwydd. Ond mewn gwirionedd, mae'r defnyddiwr yn cael yr hyn y gwnaethoch chi ei gyflwyno, dim yna pan wnaethoch chi ei gyflwyno i gynhyrchu, a phan oedd yn gallu mynd yno a'r cynhyrchiad hwn yn gweithio. Felly rwy'n credu bod y gadwyn gyflenwi yn dod i ben dim ond ar y cam gweithredu (rhedeg), neu'n fwy manwl gywir, hyd yn oed ar hyn o bryd pan gafodd y cod ei dynnu o'r cynhyrchiad (gan ei ddisodli ag un newydd).
Gadewch i ni ddychwelyd at y cynllun cyflawni uchod yn Kubernetes: fe'i dyfeisiwyd nid yn unig gennym ni, ond yn llythrennol gan bawb a ddeliodd â'r broblem hon. Mewn gwirionedd, gelwir y patrwm hwn bellach yn GitOps (gallwch ddarllen mwy am y term a'r syniadau y tu ôl iddo ). Gadewch i ni edrych ar gamau'r cynllun.
Cam adeiladu
Mae'n ymddangos y gallwch chi siarad am adeiladu delweddau Docker yn 2019, pan fydd pawb yn gwybod sut i ysgrifennu Dockerfiles a rhedeg docker build?... Dyma'r arlliwiau yr hoffwn roi sylw iddynt:
- Pwysau delwedd materion, felly defnyddiwch i adael yn y ddelwedd dim ond y cais sy'n wirioneddol angenrheidiol ar gyfer y llawdriniaeth.
- Nifer yr haenau rhaid ei leihau trwy gyfuno cadwyni o
RUN- gorchmynion yn ôl ystyr. - Fodd bynnag, mae hyn yn ychwanegu problemau dadfygio, oherwydd pan fydd y cynulliad yn damwain, mae'n rhaid ichi ddod o hyd i'r gorchymyn cywir o'r gadwyn a achosodd y broblem.
- Cyflymder Cynulliad bwysig oherwydd rydym am gyflwyno newidiadau yn gyflym a gweld y canlyniadau. Er enghraifft, nid ydych chi am ailadeiladu dibyniaethau mewn llyfrgelloedd iaith bob tro y byddwch chi'n adeiladu cymhwysiad.
- Yn aml o un storfa Git sydd ei angen arnoch chi llawer o ddelweddau, y gellir eu datrys gan set o Dockerfiles (neu gamau a enwir mewn un ffeil) a sgript Bash gyda'u cydosodiad dilyniannol.
Dim ond blaen y mynydd iâ y mae pawb yn ei wynebu oedd hyn. Ond mae problemau eraill, yn arbennig:
- Yn aml yn y gwasanaeth mae angen rhywbeth arnom mownt (er enghraifft, cadwch ganlyniad gorchymyn fel apt mewn cyfeiriadur trydydd parti).
- Rydyn ni eisiau Ateb yn lle ysgrifennu mewn cragen.
- Rydyn ni eisiau adeiladu heb Docker (pam mae angen peiriant rhithwir ychwanegol arnom lle mae angen i ni ffurfweddu popeth ar gyfer hyn, pan fydd gennym eisoes glwstwr Kubernetes lle gallwn redeg cynwysyddion?).
- Cynulliad cyfochrog, y gellir eu deall mewn gwahanol ffyrdd: gwahanol orchmynion o'r Dockerfile (os defnyddir aml-gam), mae sawl un yn ymrwymo o'r un ystorfa, sawl Dockerfiles.
- Cynulliad wedi'i ddosbarthu: Rydyn ni eisiau casglu pethau mewn codennau sy'n "effemeral" oherwydd mae eu storfa'n diflannu, sy'n golygu bod angen ei storio yn rhywle ar wahân.
- Yn olaf, enwais binacl dyheadau awtomatig: Byddai'n ddelfrydol mynd i'r ystorfa, teipio rhywfaint o orchymyn a chael delwedd barod, wedi'i ymgynnull gyda dealltwriaeth o sut a beth i'w wneud yn gywir. Fodd bynnag, nid wyf yn bersonol yn siŵr y gellir rhagweld yr holl arlliwiau fel hyn.
A dyma'r prosiectau:
- — adeiladwr o Docker Inc (sydd eisoes wedi'i integreiddio i fersiynau cyfredol o Docker), sy'n ceisio datrys yr holl broblemau hyn;
- - adeiladwr o Google sy'n eich galluogi i adeiladu heb Docker;
- — Ymgais CNCF i wneud hud awtomatig ac, yn benodol, datrysiad diddorol gydag ad-daliad ar gyfer haenau;
- a chriw o gyfleustodau eraill, megis , ...
...ac edrychwch faint o sêr sydd ganddyn nhw ar GitHub. Hynny yw, ar y naill law, docker build yn bodoli ac yn gallu gwneud rhywbeth, ond mewn gwirionedd nid yw'r mater wedi'i ddatrys yn llwyr - prawf o hyn yw datblygiad cyfochrog casglwyr amgen, y mae pob un ohonynt yn datrys rhyw ran o'r problemau.
Cymanfa yn werff
Felly dyma ni'n cyrraedd (gynt fel dapp) — Cyfleustodau ffynhonnell agored gan y cwmni yn y Fflint, yr ydym wedi bod yn ei wneud ers blynyddoedd lawer. Dechreuodd y cyfan 5 mlynedd yn ôl gyda sgriptiau Bash a wnaeth optimeiddio cydosod Dockerfiles, ac am y 3 blynedd diwethaf mae datblygiad llawn wedi'i wneud o fewn fframwaith un prosiect gyda'i ystorfa Git ei hun. (yn gyntaf yn Ruby, ac yna i Go, ac ar yr un pryd wedi'i ailenwi). Pa faterion cydosod sy'n cael eu datrys mewn werff?
Mae'r problemau sydd wedi'u lliwio'n las eisoes wedi'u rhoi ar waith, gwnaed y gwaith adeiladu cyfochrog o fewn yr un gwesteiwr, a bwriedir cwblhau'r materion a amlygwyd mewn melyn erbyn diwedd yr haf.
Cyfnod cyhoeddi yn y gofrestrfa (cyhoeddi)
Deialon ni docker push... - beth allai fod yn anodd am uwchlwytho delwedd i'r gofrestrfa? Ac yna mae'r cwestiwn yn codi: "Pa dag ddylwn i ei roi ar y ddelwedd?" Mae'n codi am y rheswm sydd gennym ni Llif Gitflow (neu strategaeth Git arall) a Kubernetes, ac mae'r diwydiant yn ceisio sicrhau bod yr hyn sy'n digwydd yn Kubernetes yn dilyn yr hyn sy'n digwydd yn Git. Wedi'r cyfan, Git yw ein hunig ffynhonnell gwirionedd.
Beth sydd mor anodd am hyn? Sicrhau atgynhyrchu: o ymrwymiad yn Git, yr hwn sydd ddigyfnewid o ran ei natur (digyfnewid), i ddelw Dociwr, yr hwn a ddylai gael ei gadw yr un.
Mae hefyd yn bwysig i ni pennu tarddiad, oherwydd ein bod am ddeall o ba ymrwymiad y cais yn rhedeg yn Kubernetes ei adeiladu (yna gallwn wneud diffs a phethau tebyg).
Strategaethau Tagio
Mae'r un cyntaf yn syml tag git. Mae gennym gofrestrfa gyda delwedd wedi'i thagio fel 1.0. Mae gan Kubernetes lwyfan a chynhyrchiad, lle mae'r ddelwedd hon yn cael ei huwchlwytho. Yn Git rydym yn gwneud ymrwymiadau ac ar ryw adeg rydym yn tagio 2.0. Rydyn ni'n ei gasglu yn unol â'r cyfarwyddiadau o'r ystorfa ac yn ei roi yn y gofrestrfa gyda'r tag 2.0. Rydyn ni'n ei gyflwyno i'r llwyfan ac, os yw popeth yn iawn, yna i'r cynhyrchiad.
Y broblem gyda'r dull hwn yw ein bod yn rhoi'r tag yn gyntaf, a dim ond wedyn y byddwn yn ei brofi a'i gyflwyno. Pam? Yn gyntaf, mae'n afresymegol: rydym yn cyhoeddi fersiwn o feddalwedd nad ydym hyd yn oed wedi'i phrofi eto (ni allwn wneud fel arall, oherwydd er mwyn gwirio, mae angen i ni roi tag). Yn ail, nid yw'r llwybr hwn yn gydnaws â Gitflow.
Yr ail opsiwn yw git ymrwymo + tag. Mae gan y brif gangen dag 1.0; ar ei gyfer yn registry - delwedd a ddefnyddir i gynhyrchu. Yn ogystal, mae gan glwstwr Kubernetes ragolwg a chyfuchliniau llwyfannu. Nesaf rydym yn dilyn Gitflow: yn y brif gangen ar gyfer datblygu (develop) rydym yn gwneud nodweddion newydd, gan arwain at ymrwymiad gyda'r dynodwr #c1. Rydym yn ei gasglu a'i gyhoeddi yn y gofrestr gan ddefnyddio'r dynodwr hwn (#c1). Gyda'r un dynodwr rydym yn cyflwyno i rhagolwg. Gwnawn yr un peth ag ymrwymiadau #c2 и #c3.
Pan wnaethom sylweddoli bod digon o nodweddion, rydym yn dechrau sefydlogi popeth. Creu cangen yn Git release_1.1 (ar y gwaelod #c3 o develop). Nid oes angen casglu'r datganiad hwn, oherwydd ... gwnaed hyn yn y cam blaenorol. Felly, yn syml, gallwn ei gyflwyno i lwyfannu. Rydyn ni'n trwsio chwilod i mewn #c4 ac yn yr un modd cyflwyno i lwyfannu. Ar yr un pryd, mae datblygiad ar y gweill yn develop, o ble y cymerir newidiadau o bryd i'w gilydd release_1.1. Ar ryw adeg, rydyn ni'n cael ymrwymiad yn cael ei lunio a'i uwchlwytho i lwyfannu, rydyn ni'n hapus ag ef (#c25).
Yna rydyn ni'n uno (gyda chyflymu ymlaen) y gangen rhyddhau (release_1.1) mewn meistr. Rydyn ni'n rhoi tag gyda'r fersiwn newydd ar yr ymrwymiad hwn (1.1). Ond mae'r ddelwedd hon eisoes wedi'i chasglu yn y gofrestrfa, felly er mwyn peidio â'i chasglu eto, rydym yn syml yn ychwanegu ail dag i'r ddelwedd bresennol (bellach mae ganddo dagiau yn y gofrestrfa #c25 и 1.1). Ar ôl hynny, rydym yn ei gyflwyno i gynhyrchu.
Mae anfantais mai dim ond un ddelwedd sy'n cael ei huwchlwytho i lwyfannu (#c25), ac wrth gynhyrchu mae'n fath o wahanol (1.1), ond gwyddom mai'r un ddelwedd o'r gofrestrfa yw'r rhain “yn gorfforol”.
Yr anfantais wirioneddol yw nad oes unrhyw gefnogaeth i ymrwymiadau uno, mae'n rhaid i chi wneud yn gyflym-ymlaen.
Gallwn fynd ymhellach a gwneud tric... Edrychwn ar enghraifft o Dockerfile syml:
FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb
FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/publicGadewch i ni adeiladu ffeil ohono yn unol â'r egwyddor ganlynol:
- SHA256 o ddynodwyr y delweddau a ddefnyddiwyd (
ruby:2.3иnginx:alpine), sy'n wiriadau o'u cynnwys; - pob tîm (
RUN,CMDac yn y blaen.); - SHA256 o ffeiliau a ychwanegwyd.
... a chymryd y checksum (SHA256 eto) o ffeil o'r fath. hwn llofnod popeth sy'n diffinio cynnwys delwedd y Docker.
Gadewch i ni fynd yn ôl at y diagram a yn lle ymrwymo byddwn yn defnyddio llofnodion o'r fath, h.y. delweddau tag gyda llofnodion.
Nawr, pan fo angen, er enghraifft, i uno newidiadau o ryddhad i feistr, gallwn wneud ymrwymiad uno go iawn: bydd ganddo ddynodwr gwahanol, ond yr un llofnod. Gyda'r un dynodwr byddwn yn cyflwyno'r ddelwedd i'r cynhyrchiad.
Yr anfantais yw nawr ni fydd yn bosibl penderfynu pa fath o ymrwymiad ei gwthio i gynhyrchu - checksums dim ond yn gweithio i un cyfeiriad. Mae'r broblem hon yn cael ei datrys gan haen ychwanegol gyda metadata - byddaf yn dweud mwy wrthych yn nes ymlaen.
Tagio yn werff
Yn werf aethon ni ymhellach fyth ac rydym yn paratoi i wneud gwaith adeiladu gwasgaredig gyda storfa nad yw'n cael ei storio ar un peiriant... Felly, rydyn ni'n adeiladu dau fath o ddelweddau Docker, rydyn ni'n eu galw cam и image.
Mae ystorfa werf Git yn storio cyfarwyddiadau adeiladu-benodol sy'n disgrifio gwahanol gamau'r adeiladu (cyn Gosod, gosod, cyn Gosod, setup). Rydym yn casglu'r ddelwedd cam cyntaf gyda llofnod a ddiffinnir fel siec y camau cyntaf. Yna rydym yn ychwanegu'r cod ffynhonnell, ar gyfer y ddelwedd cam newydd rydym yn cyfrifo ei swm siec... Mae'r gweithrediadau hyn yn cael eu hailadrodd ar gyfer pob cam, ac o ganlyniad rydym yn cael set o ddelweddau llwyfan. Yna rydym yn gwneud y ddelwedd derfynol, sydd hefyd yn cynnwys metadata am ei darddiad. Ac rydym yn tagio'r ddelwedd hon mewn gwahanol ffyrdd (manylion yn ddiweddarach).
Tybiwch ar ôl hyn mae ymrwymiad newydd yn ymddangos lle mai dim ond cod y cais sydd wedi'i newid. Beth fydd yn digwydd? Ar gyfer newidiadau cod, bydd darn yn cael ei greu a bydd delwedd llwyfan newydd yn cael ei baratoi. Bydd ei lofnod yn cael ei bennu fel siec yr hen ddelwedd lwyfan a'r darn newydd. Bydd delwedd derfynol newydd yn cael ei ffurfio o'r ddelwedd hon. Bydd ymddygiad tebyg yn digwydd gyda newidiadau mewn cyfnodau eraill.
Felly, mae delweddau llwyfan yn storfa y gellir ei storio'n ddosbarthedig, ac mae'r delweddau sydd eisoes wedi'u creu ohono yn cael eu huwchlwytho i Gofrestrfa'r Docwyr.
Glanhau'r gofrestrfa
Nid ydym yn sôn am ddileu haenau a oedd yn parhau i fod yn hongian ar ôl dileu tagiau - mae hon yn nodwedd safonol o'r Gofrestrfa Dociwr ei hun. Rydyn ni'n siarad am sefyllfa pan fydd llawer o dagiau Docker yn cronni ac rydyn ni'n deall nad oes angen rhai ohonyn nhw mwyach, ond maen nhw'n cymryd lle (a / neu rydyn ni'n talu amdano).
Beth yw'r strategaethau glanhau?
- Allwch chi wneud dim byd peidiwch â glanhau. Weithiau mae'n haws talu ychydig am le ychwanegol nag i ddatrys pentwr enfawr o dagiau. Ond dim ond hyd at bwynt penodol y mae hyn yn gweithio.
- Ailosod llawn. Os byddwch yn dileu pob delwedd ac yn ailadeiladu dim ond y rhai presennol yn y system CI, gall problem godi. Os caiff y cynhwysydd ei ailgychwyn wrth gynhyrchu, bydd delwedd newydd yn cael ei llwytho ar ei gyfer - un nad yw wedi'i phrofi eto gan unrhyw un. Mae hyn yn lladd y syniad o seilwaith digyfnewid.
- Glas-wyrdd. Dechreuodd un gofrestrfa orlifo - rydyn ni'n uwchlwytho delweddau i un arall. Yr un broblem ag yn y dull blaenorol: ar ba bwynt y gallwch chi glirio'r gofrestr sydd wedi dechrau gorlifo?
- Erbyn amser. Dileu pob delwedd sy'n hŷn nag 1 mis? Ond yn bendant fe fydd yna wasanaeth sydd heb ei ddiweddaru ers mis...
- Gyda llaw penderfynu beth y gellir ei ddileu eisoes.
Mae dau opsiwn gwirioneddol hyfyw: peidiwch â glanhau neu gyfuniad o laswyrdd + â llaw. Yn yr achos olaf, rydym yn sôn am y canlynol: pan fyddwch chi'n deall ei bod hi'n bryd glanhau'r gofrestrfa, rydych chi'n creu un newydd ac yn ychwanegu'r holl ddelweddau newydd ato dros gyfnod o fis, er enghraifft. Ac ar ôl mis, gwelwch pa godennau yn Kubernetes sy'n dal i ddefnyddio'r hen gofrestrfa, a'u trosglwyddo hefyd i'r gofrestrfa newydd.
Beth ydyn ni wedi dod iddo werff? Rydym yn casglu:
- Pen Git: pob tag, pob cangen - gan dybio bod angen popeth sydd wedi'i dagio yn Git yn y delweddau (ac os na, yna mae angen i ni ei ddileu yn Git ei hun);
- pob cod sy'n cael ei bwmpio allan i Kubernetes ar hyn o bryd;
- hen ReplicaSets (yr hyn a ryddhawyd yn ddiweddar), ac rydym hefyd yn bwriadu sganio datganiadau Helm a dewis y delweddau diweddaraf yno.
... a gwnewch restr wen o'r set hon - rhestr o ddelweddau na fyddwn yn eu dileu. Rydyn ni'n glanhau popeth arall, ac ar ôl hynny rydyn ni'n dod o hyd i ddelweddau llwyfan amddifad ac yn eu dileu hefyd.
Defnyddio llwyfan
Datganiad dibynadwy
Y pwynt cyntaf yr hoffwn dynnu sylw ato yn y defnydd yw cyflwyno'r cyfluniad adnoddau wedi'i ddiweddaru, a ddatganwyd yn ddatganiadol. Mae dogfen wreiddiol YAML sy'n disgrifio adnoddau Kubernetes bob amser yn wahanol iawn i'r canlyniad sy'n rhedeg mewn gwirionedd yn y clwstwr. Oherwydd bod Kubernetes yn ychwanegu at y ffurfweddiad:
- dynodwyr;
- gwybodaeth gwasanaeth;
- llawer o werthoedd rhagosodedig;
- adran gyda statws cyfredol;
- newidiadau a wnaed fel rhan o'r bachyn gwe derbyn;
- canlyniad gwaith rheolwyr amrywiol (a'r trefnydd).
Felly, pan fydd ffurfweddiad adnodd newydd yn ymddangos (newydd), ni allwn gymryd a throsysgrifo'r cyfluniad cyfredol, “byw” gydag ef (yn byw). I wneud hyn bydd yn rhaid i ni gymharu newydd gyda'r cyfluniad cymhwysol diwethaf (diwethaf-gymhwysol) a rholio ymlaen yn byw wedi derbyn clwt.
Gelwir y dull hwn Cyfuniad 2-ffordd. Fe'i defnyddir, er enghraifft, yn Helm.
Mae yna hefyd Cyfuniad 3-ffordd, sy'n wahanol yn hynny o beth:
- cymharu diwethaf-gymhwysol и newydd, edrychwn ar yr hyn a ddilewyd;
- cymharu newydd и yn byw, edrychwn ar yr hyn sydd wedi ei ychwanegu neu ei newid;
- y clwt cryno yn cael ei gymhwyso i yn byw.
Rydyn ni'n defnyddio 1000+ o gymwysiadau gyda Helm, felly rydyn ni'n byw gyda chyfuniad 2 ffordd mewn gwirionedd. Fodd bynnag, mae ganddo nifer o broblemau yr ydym wedi'u datrys gyda'n clytiau, sy'n helpu Helm i weithio'n normal.
Statws cyflwyno go iawn
Ar ôl i'n system CI gynhyrchu cyfluniad newydd ar gyfer Kubernetes yn seiliedig ar y digwyddiad nesaf, mae'n ei drosglwyddo i'w ddefnyddio (gwneud cais) i glwstwr - defnyddio Helm neu kubectl apply. Nesaf, mae'r uno N-way a ddisgrifiwyd eisoes yn digwydd, y mae API Kubernetes yn ymateb yn gymeradwy i'r system CI, a hynny i'w ddefnyddiwr.
Fodd bynnag, mae problem enfawr: wedi'r cyfan nid yw cais llwyddiannus yn golygu ei gyflwyno'n llwyddiannus. Os yw Kubernetes yn deall pa newidiadau y mae angen eu cymhwyso a'u cymhwyso, nid ydym yn gwybod beth fydd y canlyniad o hyd. Er enghraifft, efallai y bydd diweddaru ac ailgychwyn codennau yn y frontend yn llwyddiannus, ond nid yn y backend, a byddwn yn cael fersiynau gwahanol o'r delweddau cymhwysiad rhedeg.
I wneud popeth yn gywir, mae angen dolen ychwanegol ar y cynllun hwn - traciwr arbennig a fydd yn derbyn gwybodaeth statws o API Kubernetes a'i drosglwyddo i'w ddadansoddi ymhellach o gyflwr go iawn pethau. Fe wnaethon ni greu llyfrgell Ffynhonnell Agored yn Go - (gweler ei gyhoeddiad ), sy'n datrys y broblem hon ac sy'n cael ei adeiladu i werff.
Mae ymddygiad y traciwr hwn ar lefel werff wedi'i ffurfweddu gan ddefnyddio anodiadau a roddir ar Deployments neu StatefulSets. Prif anodiad - fail-mode - yn deall yr ystyron canlynol:
-
IgnoreAndContinueDeployProcess— rydym yn anwybyddu problemau cyflwyno'r gydran hon ac yn parhau â'r defnydd; -
FailWholeDeployProcessImmediately— mae gwall yn y gydran hon yn atal y broses leoli; -
HopeUntilEndOfDeployProcess— rydym yn gobeithio y bydd y gydran hon yn gweithio erbyn diwedd y defnydd.
Er enghraifft, y cyfuniad hwn o adnoddau a gwerthoedd anodi fail-mode:
Pan fyddwn yn defnyddio am y tro cyntaf, efallai na fydd y gronfa ddata (MongoDB) yn barod eto - bydd Deployments yn methu. Ond gallwch chi aros am y foment iddo ddechrau, a bydd y defnydd yn dal i ddigwydd.
Mae dau anodiad arall ar gyfer kubedog mewn werff:
-
failures-allowed-per-replica— nifer y cwympiadau a ganiateir ar gyfer pob atgynhyrchiad; -
show-logs-until— yn rheoli'r foment y bydd werff yn dangos (mewn stdout) boncyffion o'r holl godennau sydd wedi'u cyflwyno. Y rhagosodiad ywPodIsReady(i anwybyddu negeseuon mae'n debyg nad ydyn ni eu heisiau pan fydd traffig yn dechrau dod i'r pod), ond mae gwerthoedd hefyd yn ddilys:ControllerIsReadyиEndOfDeploy.
Beth arall ydym ni ei eisiau o leoli?
Yn ogystal â’r ddau bwynt a ddisgrifiwyd eisoes, hoffem:
- i weld boncyffion - a dim ond y rhai angenrheidiol, ac nid popeth yn olynol;
- trac cynnydd, oherwydd os yw'r swydd yn hongian "yn dawel" am sawl munud, mae'n bwysig deall beth sy'n digwydd yno;
- иметь Dychweliad awtomatig rhag ofn i rywbeth fynd o'i le (ac felly mae'n hanfodol gwybod gwir statws y lleoliad). Rhaid i'r cyflwyniad fod yn atomig: naill ai mae'n mynd drwodd i'r diwedd, neu mae popeth yn dychwelyd i'w gyflwr blaenorol.
Canlyniadau
I ni fel cwmni, mae gweithredu'r holl naws a ddisgrifir ar wahanol gamau cyflwyno (adeiladu, cyhoeddi, defnyddio), system CI a chyfleustodau yn ddigon .
Yn lle casgliad:
Gyda chymorth werff, rydym wedi gwneud cynnydd da wrth ddatrys nifer fawr o broblemau i beirianwyr DevOps a byddem yn falch pe bai'r gymuned ehangach o leiaf yn rhoi cynnig ar y cyfleustodau hwn ar waith. Bydd yn haws cael canlyniad da gyda'n gilydd.
Fideos a sleidiau
Fideo o'r perfformiad (~47 munud):
Cyflwyniad yr adroddiad:
PS
Adroddiadau eraill am Kubernetes ar ein blog:
- «» (Dmitry Stolyarov; Ebrill 27, 2019 ar “Streic”);
- «» (Andrey Polovov; Ebrill 8, 2019 ar Saint HighLoad ++);
- «» (Dmitry Stolyarov; Tachwedd 8, 2018 ar HighLoad++);
- «» (Dmitry Stolyarov; Mai 28, 2018 yn RootConf);
- «» (Dmitry Stolyarov; Tachwedd 7, 2017 ar HighLoad++);
- «» (Dmitry Stolyarov; Mehefin 6, 2017 yn RootConf).
Ffynhonnell: hab.com