Docker Swarm, Kubernetes, a Mesos yw'r fframweithiau cerddorfa cynhwysydd mwyaf poblogaidd. Yn ei sgwrs, mae Arun Gupta yn cymharu'r agweddau canlynol ar Docker, Swarm, a Kubernetes:
- Datblygiad lleol.
- Swyddogaethau lleoli.
- Cymwysiadau aml-gynhwysydd.
- Darganfod gwasanaeth.
- Graddio'r gwasanaeth.
- Tasgau rhedeg unwaith.
- Integreiddio gyda Maven.
- Diweddariad "rholio".
- Creu clwstwr cronfa ddata Couchbase.
O ganlyniad, byddwch yn dod i ddeall yn glir yr hyn sydd gan bob offeryn cerddorfaol i'w gynnig ac yn dysgu sut i ddefnyddio'r llwyfannau hyn yn effeithiol.
Arun Gupta yw'r prif dechnolegydd ar gyfer cynhyrchion ffynhonnell agored yn Amazon Web Services, sydd wedi bod yn datblygu cymunedau datblygwyr Sun, Oracle, Red Hat a Couchbase ers dros 10 mlynedd. Profiad helaeth o weithio mewn arwain timau traws-swyddogaethol yn datblygu a gweithredu strategaeth ar gyfer ymgyrchoedd a rhaglenni marchnata. Arweiniodd dimau o beirianwyr Sun, mae'n un o sylfaenwyr tîm Java EE a chreawdwr cangen yr Unol Daleithiau o Devoxx4Kids. Mae Arun Gupta yn awdur dros 2 fil o bostiadau mewn blogiau TG ac mae wedi rhoi sgyrsiau mewn mwy na 40 o wledydd.
Mae llinell 55 yn cynnwys COUCHBASE_URI sy'n pwyntio at y gwasanaeth cronfa ddata hwn, a grëwyd hefyd gan ddefnyddio ffeil ffurfweddu Kubernetes. Os edrychwch ar linell 2, gallwch weld caredig: Gwasanaeth yw'r gwasanaeth rwy'n ei greu o'r enw couchbase-service, ac mae'r un enw wedi'i restru ar linell 4. Isod mae rhai porthladdoedd.
Y llinellau allweddol yw 6 a 7. Yn y gwasanaeth rwy'n dweud, “Hei, dyma'r labeli rydw i'n edrych amdanyn nhw!”, ac nid yw'r labeli hyn yn ddim mwy nag enwau pâr amrywiol, ac mae llinell 7 yn pwyntio i'm couchbase-rs-pod cais. Y canlynol yw'r porthladdoedd sy'n darparu mynediad i'r un labeli hyn.
Ar-lein 19 rwy'n creu ReplicaSet math newydd, mae llinell 31 yn cynnwys enw'r ddelwedd, ac mae llinellau 24-27 yn pwyntio at y metadata sy'n gysylltiedig â fy nghod. Dyma'n union beth mae'r gwasanaeth yn chwilio amdano a beth ddylai'r cysylltiad gael ei wneud iddo. Ar ddiwedd y ffeil mae rhyw fath o gysylltiad rhwng llinellau 55-56 a 4, gan ddweud: “defnyddiwch y gwasanaeth hwn!”
Felly, rwy'n dechrau fy ngwasanaeth pan fydd set replica, a chan fod gan bob set replica ei phorthladd ei hun gyda'r label cyfatebol, mae wedi'i gynnwys yn y gwasanaeth. O safbwynt datblygwr, yn syml, rydych chi'n ffonio'r gwasanaeth, sydd wedyn yn defnyddio'r set o atgynyrchiadau sydd eu hangen arnoch chi.
O ganlyniad, mae gen i god WildFly sy'n cyfathrebu ag ôl-ben y gronfa ddata trwy Couchbase Service. Gallaf ddefnyddio'r frontend gyda sawl cod WildFly, sydd hefyd yn cyfathrebu â chefnlen y couchbase trwy'r gwasanaeth couchbase.
Yn ddiweddarach byddwn yn edrych ar sut mae gwasanaeth sydd wedi'i leoli y tu allan i'r clwstwr yn cyfathrebu trwy ei gyfeiriad IP ag elfennau sydd wedi'u lleoli y tu mewn i'r clwstwr ac sydd â chyfeiriad IP mewnol.
Felly, mae cynwysyddion di-wladwriaeth yn wych, ond pa mor dda yw defnyddio cynwysyddion urddasol? Gadewch i ni edrych ar y gosodiadau system ar gyfer cynwysyddion stateful, neu barhaus. Yn Docker, mae 4 agwedd wahanol ar gynllun storio data y dylech roi sylw iddynt. Y cyntaf yw Implicit Per-Container, sy'n golygu, wrth ddefnyddio cynwysyddion satateful couchbase, MySQL neu MyDB, maent i gyd yn dechrau gyda'r Blwch Tywod rhagosodedig. Hynny yw, mae popeth sy'n cael ei storio yn y gronfa ddata yn cael ei storio yn y cynhwysydd ei hun. Os bydd y cynhwysydd yn diflannu, mae'r data'n diflannu ynghyd ag ef.
Yr ail yw Penodol Per-Container, pan fyddwch yn creu storfa benodol gyda chyfaint y docwr creu gorchymyn a storio data ynddo. Mae'r trydydd dull Per-Host yn gysylltiedig â mapio storio, pan fydd popeth sy'n cael ei storio yn y cynhwysydd yn cael ei ddyblygu ar yr un pryd ar y gwesteiwr. Os bydd y cynhwysydd yn methu, bydd y data yn aros ar y gwesteiwr. Yr olaf yw defnyddio sawl gwesteiwr Aml-Gwesteiwr, sy'n ddoeth ar gam cynhyrchu gwahanol atebion. Dywedwch fod eich cynwysyddion gyda'ch cymwysiadau yn rhedeg ar y gwesteiwr, ond rydych chi am storio'ch data yn rhywle ar y Rhyngrwyd, ac ar gyfer hyn rydych chi'n defnyddio mapio awtomatig ar gyfer systemau dosbarthedig.
Mae pob un o'r dulliau hyn yn defnyddio lleoliad storio penodol. Mae Per-Container Ymhlyg ac Eglur yn storio data ar y gwesteiwr yn /var/lib/docker/volumes. Wrth ddefnyddio'r dull Per-Host, mae'r storfa wedi'i osod y tu mewn i'r cynhwysydd, ac mae'r cynhwysydd ei hun wedi'i osod ar y gwesteiwr. Ar gyfer multihosts, gellir defnyddio atebion fel Ceph, ClusterFS, NFS, ac ati.
Os bydd cynhwysydd parhaus yn methu, mae'r cyfeiriadur storio yn dod yn anhygyrch yn y ddau achos cyntaf, ond yn y ddau achos olaf cedwir mynediad. Fodd bynnag, yn yr achos cyntaf, gallwch gael mynediad i'r ystorfa trwy westeiwr Docker sy'n rhedeg ar beiriant rhithwir. Yn yr ail achos, ni fydd y data yn cael ei golli ychwaith, oherwydd eich bod wedi creu storfa benodol.
Os bydd y gwesteiwr yn methu, nid yw'r cyfeiriadur storio ar gael yn y tri achos cyntaf; yn yr achos olaf, ni amharir ar y cysylltiad â'r storfa. Yn olaf, mae'r swyddogaeth a rennir wedi'i heithrio'n llwyr i'w storio yn yr achos cyntaf ac mae'n bosibl yn y gweddill. Yn yr ail achos, gallwch rannu storfa yn dibynnu a yw'ch cronfa ddata yn cefnogi storfa ddosbarthedig ai peidio. Yn achos Per-Host, dim ond ar westeiwr penodol y mae dosbarthiad data yn bosibl, ac ar gyfer aml-host fe'i darperir trwy ehangu clwstwr.
Dylid cymryd hyn i ystyriaeth wrth greu cynwysyddion urddasol. Offeryn Docker defnyddiol arall yw'r ategyn Cyfrol, sy'n gweithio ar yr egwyddor o "batris yn bresennol, ond mae'n rhaid eu disodli." Pan ddechreuwch gynhwysydd Docker, mae'n dweud, “Hei, ar ôl i chi ddechrau cynhwysydd gyda chronfa ddata, gallwch chi storio'ch data yn y cynhwysydd hwn!” Dyma'r nodwedd ddiofyn, ond gallwch chi ei newid. Mae'r ategyn hwn yn caniatáu ichi ddefnyddio gyriant rhwydwaith neu rywbeth tebyg yn lle cronfa ddata cynhwysydd. Mae'n cynnwys gyrrwr rhagosodedig ar gyfer storio sy'n seiliedig ar westeiwr ac yn caniatáu integreiddio cynhwysydd â systemau storio allanol fel Amazon EBS, Azure Storage a disgiau Parhaus TAG.
Mae'r sleid nesaf yn dangos pensaernïaeth yr ategyn Docker Volume.
Mae'r lliw glas yn cynrychioli'r cleient Docker sy'n gysylltiedig â gwesteiwr glas y Docker, sydd â pheiriant storio Lleol sy'n darparu cynwysyddion i chi ar gyfer storio data. Mae gwyrdd yn nodi'r Cleient Ategyn a'r Daemon Ategyn, sydd hefyd wedi'u cysylltu â'r gwesteiwr. Maent yn rhoi'r cyfle i storio data mewn storfa rhwydwaith o'r math o Backend Storio sydd ei angen arnoch.
Gellir defnyddio'r ategyn Docker Volume gyda storfa Portworx. Mae'r modiwl PX-Dev mewn gwirionedd yn gynhwysydd rydych chi'n ei redeg sy'n cysylltu â'ch gwesteiwr Docker ac sy'n eich galluogi i storio data yn hawdd ar Amazon EBS.
Mae cleient Portworx yn caniatáu ichi fonitro statws amrywiol gynwysyddion storio sydd wedi'u cysylltu â'ch gwesteiwr. Os ymwelwch â'm blog, gallwch ddarllen sut i wneud y gorau o Portworx gyda Docker.
Mae'r cysyniad o storio yn Kubernetes yn debyg i Docker ac fe'i cynrychiolir gan gyfeiriaduron sy'n hygyrch i'ch cynhwysydd mewn pod. Maent yn annibynnol ar oes unrhyw gynhwysydd. Y mathau storio mwyaf cyffredin sydd ar gael yw hostPath, nfs, awsElasticBlockStore, a gsePersistentDisk. Gadewch i ni edrych ar sut mae'r siopau hyn yn gweithio yn Kubernetes. Yn nodweddiadol, mae'r broses o'u cysylltu yn cynnwys 3 cham.
Y cyntaf yw bod rhywun ar ochr y rhwydwaith, gweinyddwr fel arfer, yn darparu storfa barhaus i chi. Mae ffeil ffurfweddu PersistentVolume cyfatebol ar gyfer hyn. Nesaf, mae datblygwr y cais yn ysgrifennu ffeil ffurfweddu o'r enw PersistentVolumeClaim, neu gais storio PVC, sy'n dweud: “Mae gen i 50GB o storfa ddosbarthedig wedi'i darparu, ond er mwyn i bobl eraill ddefnyddio ei gapasiti hefyd, rwy'n dweud wrth y PVC hwn fy mod ar hyn o bryd. angen dim ond 10 GB". Yn olaf, y trydydd cam yw bod eich cais yn cael ei osod fel storfa, a bod y rhaglen sydd â'r pod, neu replica set, neu rywbeth tebyg, yn dechrau ei ddefnyddio. Mae'n bwysig cofio bod y broses hon yn cynnwys y 3 cham a grybwyllwyd ac yn scalable.
Mae'r sleid nesaf yn dangos Cynhwysydd Dyfalbarhad Kubernetes o bensaernïaeth AWS.
Y tu mewn i'r petryal brown sy'n cynrychioli clwstwr Kubernetes, mae un prif nod a dau nod gweithiwr, wedi'u nodi mewn melyn. Mae un o nodau'r gweithwyr yn cynnwys pod oren, storfa, rheolydd replica, a chynhwysydd gwyrdd Docker Couchbase. Y tu mewn i'r clwstwr, uwchben y nodau, mae petryal porffor yn dangos bod y Gwasanaeth yn hygyrch o'r tu allan. Argymhellir y bensaernïaeth hon ar gyfer storio data ar y ddyfais ei hun. Os oes angen, gallaf storio fy nata yn EBS y tu allan i'r clwstwr, fel y dangosir yn y sleid nesaf. Mae hwn yn fodel nodweddiadol ar gyfer graddio, ond mae agwedd ariannol i'w hystyried wrth ei ddefnyddio - gall storio data yn rhywle ar y rhwydwaith fod yn ddrytach nag ar westeiwr. Wrth ddewis atebion cynhwysydd, dyma un o'r dadleuon pwysfawr.
Yn union fel gyda Docker, gallwch ddefnyddio cynwysyddion Kubernetes parhaus gyda Portworx.
Dyma beth yn nherminoleg gyfredol Kubernetes 1.6 a elwir yn “StatefulSet” - ffordd o weithio gyda chymwysiadau Stateful sy'n prosesu digwyddiadau am atal y Pod a pherfformio Graceful Shutdown. Yn ein hachos ni, cronfeydd data yw ceisiadau o'r fath. Yn fy mlog gallwch ddarllen sut i greu StatefulSet yn Kubernetes gan ddefnyddio Portworx.
Gadewch i ni siarad am yr agwedd datblygu. Fel y dywedais, mae gan Docker 2 fersiwn - CE ac EE, yn yr achos cyntaf rydym yn sôn am fersiwn sefydlog o'r Argraffiad Cymunedol, sy'n cael ei ddiweddaru unwaith bob 3 mis, yn wahanol i'r fersiwn diweddaru misol o EE. Gallwch chi lawrlwytho Docker ar gyfer Mac, Linux neu Windows. Ar ôl ei osod, bydd Docker yn diweddaru'n awtomatig ac mae'n hawdd iawn cychwyn arni.
Ar gyfer Kubernetes, mae'n well gen i'r fersiwn Minikube - mae'n ffordd dda o ddechrau gyda'r platfform trwy greu clwstwr ar un nod. I greu clystyrau o sawl nod, mae'r dewis o fersiynau yn ehangach: sef kops, kube-aws (CoreOS+AWS), kube-up (hen ffasiwn). Os ydych chi'n bwriadu defnyddio Kubernetes yn seiliedig ar AWS, rwy'n argymell ymuno â'r AWS SIG, sy'n cyfarfod ar-lein bob dydd Gwener ac yn cyhoeddi amrywiaeth o ddeunyddiau diddorol ar weithio gydag AWS Kubernetes.
Gadewch i ni edrych ar sut mae Rolling Update yn cael ei berfformio ar y llwyfannau hyn. Os oes clwstwr o sawl nod, yna mae'n defnyddio fersiwn benodol o'r ddelwedd, er enghraifft, WildFly: 1. Mae diweddariad treigl yn golygu bod y fersiwn delwedd yn cael ei ddisodli yn olynol gydag un newydd ar bob nod, un ar ôl y llall.
I wneud hyn, rwy'n defnyddio'r gorchymyn diweddaru gwasanaeth docwr (enw'r gwasanaeth), lle rwy'n nodi'r fersiwn newydd o'r ddelwedd WildFly:2 a'r dull diweddaru diweddaru-parallelism 2. Mae'r rhif 2 yn golygu y bydd y system yn diweddaru 2 ddelwedd cymhwysiad ar yr un pryd, yna oedi diweddaru 10 eiliad 10s, ac ar ôl hynny bydd y 2 ddelwedd nesaf yn cael eu diweddaru ar 2 nod arall, ac ati. Darperir y mecanwaith diweddaru treigl syml hwn i chi fel rhan o Docker.
Yn Kubernetes, mae diweddariad treigl yn gweithio fel hyn. Mae'r rheolydd atgynhyrchu rc yn creu set o atgynyrchiadau o'r un fersiwn, ac mae pob pod yn y webapp-rc hwn yn cael ei ddarparu gyda label wedi'i leoli yn etcd. Pan fydd angen pod arnaf, rwy'n defnyddio'r Gwasanaeth Cymhwysiad i gael mynediad i'r ystorfa ac ati, sy'n darparu'r pod i mi gan ddefnyddio'r label penodedig.
Yn yr achos hwn, mae gennym 3 pod yn y rheolydd Dyblygiad sy'n rhedeg y cymhwysiad fersiwn WildFly 1. Wrth ddiweddaru yn y cefndir, crëir rheolydd ailadrodd arall gyda'r un enw a mynegai ar y diwedd - - xxxxx, lle mae x yn rhifau ar hap, a gyda'r un labeli. Nawr mae gan y Gwasanaeth Cais dri chod gyda'r hen fersiwn o'r cais a thri pod gyda'r fersiwn newydd yn y rheolydd Dyblygu newydd. Ar ôl hyn, mae'r hen godennau'n cael eu dileu, mae'r rheolydd atgynhyrchu gyda'r codennau newydd yn cael ei ailenwi a'i roi ar waith.
Gadewch i ni symud ymlaen at fonitro. Mae gan Docker lawer o orchmynion monitro adeiledig. Er enghraifft, mae rhyngwyneb llinell orchymyn stats cynhwysydd y docwr yn caniatáu ichi arddangos gwybodaeth am gyflwr cynwysyddion i'r consol bob eiliad - defnydd prosesydd, defnydd disg, llwyth rhwydwaith. Mae offeryn Docker Remote API yn darparu data am sut mae'r cleient yn cyfathrebu â'r gweinydd. Mae'n defnyddio gorchmynion syml, ond mae'n seiliedig ar y Docker REST API. Yn yr achos hwn, mae'r geiriau REST, Flash, Remote yn golygu'r un peth. Pan fyddwch chi'n cyfathrebu â'r gwesteiwr, mae'n API REST. Mae API Docker Remote yn caniatáu ichi gael mwy o wybodaeth am redeg cynwysyddion. Mae fy blog yn amlinellu manylion defnyddio'r monitro hwn gyda Windows Server.
Mae monitro digwyddiadau system docwyr wrth redeg clwstwr aml-westeiwr yn ei gwneud hi'n bosibl cael data am ddamwain gwesteiwr neu ddamwain cynhwysydd ar westeiwr penodol, gwasanaethau graddio, ac ati. Gan ddechrau gyda Docker 1.20, mae'n cynnwys Prometheus, sy'n ymgorffori pwyntiau terfyn mewn cymwysiadau presennol. Mae hyn yn caniatáu ichi dderbyn metrigau trwy HTTP a'u harddangos ar ddangosfyrddau.
Nodwedd fonitro arall yw cAdvisor (byr ar gyfer cynghorydd cynhwysydd). Mae'n dadansoddi ac yn darparu data defnydd adnoddau a pherfformiad o gynwysyddion rhedeg, gan ddarparu metrigau Prometheus yn syth bin. Y peth arbennig am yr offeryn hwn yw ei fod yn darparu data ar gyfer y 60 eiliad olaf yn unig. Felly, mae angen i chi allu casglu'r data hwn a'i roi mewn cronfa ddata fel y gallwch fonitro proses hirdymor. Gellir ei ddefnyddio hefyd i arddangos metrigau dangosfwrdd yn graffigol gan ddefnyddio Grafana neu Kibana. Mae gan fy mlog ddisgrifiad manwl o sut i ddefnyddio cAdvisor i fonitro cynwysyddion gan ddefnyddio dangosfwrdd Kibana.
Mae'r sleid nesaf yn dangos sut olwg sydd ar allbwn pwynt terfyn Prometheus a'r metrigau sydd ar gael i'w harddangos.
Ar y chwith isaf fe welwch fetrigau ar gyfer ceisiadau HTTP, ymatebion, ac ati, ar y dde mae eu harddangosfa graffigol.
Mae Kubernetes hefyd yn cynnwys offer monitro adeiledig. Mae'r sleid hon yn dangos clwstwr nodweddiadol sy'n cynnwys un nod meistr a thri gweithiwr.
Mae pob un o'r nodau gweithio yn cynnwys cAdvisor a lansiwyd yn awtomatig. Yn ogystal, mae Heapster, system monitro perfformiad a chasglu metrigau sy'n gydnaws â fersiwn Kubernetes 1.0.6 ac uwch. Mae Heapster yn caniatáu ichi gasglu nid yn unig fetrigau perfformiad llwythi gwaith, codennau a chynwysyddion, ond hefyd digwyddiadau a signalau eraill a gynhyrchir gan y clwstwr cyfan. I gasglu data, mae'n siarad â Kubelet pob pod, yn storio'r wybodaeth yn awtomatig yng nghronfa ddata InfluxDB, ac yn ei allbynnu fel metrigau i ddangosfwrdd Grafana. Fodd bynnag, cofiwch, os ydych chi'n defnyddio miniKube, nid yw'r nodwedd hon ar gael yn ddiofyn, felly bydd yn rhaid i chi ddefnyddio ategion ar gyfer monitro. Felly mae'r cyfan yn dibynnu ar ble rydych chi'n rhedeg y cynwysyddion a pha offer monitro y gallwch eu defnyddio yn ddiofyn a pha rai y mae angen i chi eu gosod fel ychwanegion ar wahân.
Mae'r sleid nesaf yn dangos dangosfyrddau Grafana sy'n dangos statws rhedeg fy nghynhwyswyr. Mae cryn dipyn o ddata diddorol yma. Wrth gwrs, mae yna lawer o offer monitro prosesau masnachol Docker a Kubernetes, megis SysDig, DataDog, NewRelic. Mae gan rai ohonynt gyfnod prawf am ddim o 30 mlynedd, felly gallwch geisio dod o hyd i'r un sydd fwyaf addas i chi. Yn bersonol, mae'n well gen i ddefnyddio SysDig a NewRelic, sy'n integreiddio'n dda â Kubernetes. Mae yna offer sy'n integreiddio'r un mor dda i lwyfannau Docker a Kubernetes.
Rhai hysbysebion 🙂
Diolch am aros gyda ni. Ydych chi'n hoffi ein herthyglau? Eisiau gweld cynnwys mwy diddorol? Cefnogwch ni trwy osod archeb neu argymell i ffrindiau, , analog unigryw o weinyddion lefel mynediad, a ddyfeisiwyd gennym ni ar eich cyfer chi: (ar gael gyda RAID1 a RAID10, hyd at 24 craidd a hyd at 40GB DDR4).
Dell R730xd 2 gwaith yn rhatach yng nghanolfan ddata Equinix Haen IV yn Amsterdam? Dim ond yma yn yr Iseldiroedd! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - o $99! Darllenwch am
Ffynhonnell: hab.com