Docker Swarm, Kubernetes dhe Mesos janë kornizat më të njohura të orkestrimit të kontejnerëve. Në fjalimin e tij, Arun Gupta krahason aspektet e mëposhtme të Docker, Swarm dhe Kubernetes:
- Zhvillimi lokal.
- Funksionet e vendosjes.
- Aplikime me shumë kontejnerë.
- Zbulimi i shërbimit.
- Shkallëzimi i shërbimit.
- Detyrat ekzekutohen një herë.
- Integrimi me Maven.
- Përditësimi "Rolling".
- Krijimi i një grupi bazë të dhënash Couchbase.
Si rezultat, do të fitoni një kuptim të qartë të asaj që çdo mjet orkestrimi ka për të ofruar dhe do të mësoni se si t'i përdorni këto platforma në mënyrë efektive.
Arun Gupta është teknologu kryesor për produktet me burim të hapur në Amazon Web Services, i cili ka zhvilluar komunitetet e zhvilluesve Sun, Oracle, Red Hat dhe Couchbase për më shumë se 10 vjet. Ka përvojë të gjerë duke punuar në ekipe drejtuese ndër-funksionale që zhvillojnë dhe zbatojnë strategji për fushatat dhe programet e marketingut. Ai drejtoi ekipet e inxhinierëve Sun, është një nga themeluesit e ekipit Java EE dhe krijuesi i degës amerikane të Devoxx4Kids. Arun Gupta është autor i më shumë se 2 mijë postimeve në bloget e IT dhe ka mbajtur fjalime në më shumë se 40 vende.
Rreshti 55 përmban një COUCHBASE_URI që tregon këtë shërbim të bazës së të dhënave, i cili u krijua gjithashtu duke përdorur skedarin e konfigurimit Kubernetes. Nëse shikoni linjën 2, mund të shihni llojin: Shërbimi është shërbimi që po krijoj i quajtur couchbase-service, dhe i njëjti emër është renditur në rreshtin 4. Më poshtë janë disa porte.
Linjat kyçe janë 6 dhe 7. Në shërbim them, "Hej, këto janë etiketat që po kërkoj!" dhe këto etiketa nuk janë asgjë më shumë se emra të çifteve të ndryshueshme, dhe rreshti 7 tregon në couchbase-rs-pod tim aplikacion. Më poshtë janë portet që ofrojnë akses në të njëjtat etiketa.
Në rreshtin 19 krijoj një lloj të ri ReplicaSet, rreshti 31 përmban emrin e imazhit dhe rreshtat 24-27 tregojnë metadatat e lidhura me podin tim. Kjo është pikërisht ajo që kërkon shërbimi dhe me të cilën duhet të bëhet lidhja. Në fund të skedarit ka një lloj lidhjeje midis rreshtave 55-56 dhe 4, duke thënë: "përdor këtë shërbim!"
Pra, unë e nis shërbimin tim kur ka një set kopjesh, dhe duke qenë se çdo set replika ka portin e tij me etiketën përkatëse, ai përfshihet në shërbim. Nga këndvështrimi i një zhvilluesi, ju thjesht telefononi shërbimin, i cili më pas përdor grupin e kopjeve që ju nevojiten.
Si rezultat, unë kam një pod WildFly që komunikon me bazën e bazës së të dhënave përmes Shërbimit Couchbase. Mund të përdor pjesën e përparme me disa pods WildFly, të cilat gjithashtu komunikojnë me pjesën e pasme të couchbase përmes shërbimit të couchbase.
Më vonë do të shikojmë se si një shërbim i vendosur jashtë grupit komunikon përmes adresës së tij IP me elementë që ndodhen brenda grupit dhe kanë një adresë IP të brendshme.
Pra, kontejnerët pa shtetësi janë të shkëlqyera, por sa e mirë është të përdorësh kontejnerë të gjendjes? Le të shohim cilësimet e sistemit për kontejnerët e gjendjes ose të qëndrueshme. Në Docker, ekzistojnë 4 qasje të ndryshme për paraqitjen e ruajtjes së të dhënave, të cilave duhet t'i kushtoni vëmendje. E para është Implicit Per-Container, që do të thotë se kur përdorni kontejnerë të ngjeshur me couchbase, MySQL ose MyDB, të gjithë fillojnë me Sandbox të paracaktuar. Kjo do të thotë, gjithçka që ruhet në bazën e të dhënave ruhet në vetë kontejnerin. Nëse kontejneri zhduket, të dhënat zhduken së bashku me të.
E dyta është Explicit Per-Container, kur krijoni një ruajtje specifike me komandën e krijimit të vëllimit të docker dhe ruani të dhënat në të. Qasja e tretë Per-Host shoqërohet me hartën e ruajtjes, kur gjithçka e ruajtur në kontejner kopjohet njëkohësisht në host. Nëse kontejneri dështon, të dhënat do të mbeten në host. Kjo e fundit është përdorimi i disa hosteve Multi-Host, gjë që këshillohet në fazën e prodhimit të zgjidhjeve të ndryshme. Le të themi se kontejnerët tuaj me aplikacionet tuaja po funksionojnë në host, por ju dëshironi t'i ruani të dhënat tuaja diku në internet dhe për këtë përdorni hartën automatike për sistemet e shpërndara.
Secila prej këtyre metodave përdor një vend të caktuar ruajtjeje. Implicit dhe Explicit Per-Container ruajnë të dhënat në host në /var/lib/docker/volumes. Kur përdorni metodën Per-Host, ruajtja montohet brenda kontejnerit dhe vetë kontejneri montohet në host. Për multihost, mund të përdoren zgjidhje të tilla si Ceph, ClusterFS, NFS, etj.
Nëse një kontejner i vazhdueshëm dështon, drejtoria e ruajtjes bëhet e paarritshme në dy rastet e para, por në dy rastet e fundit qasja ruhet. Sidoqoftë, në rastin e parë, mund të hyni në depo përmes një hosti Docker që funksionon në një makinë virtuale. Në rastin e dytë, të dhënat nuk do të humbasin as, sepse keni krijuar një ruajtje Explicit.
Nëse hosti dështon, drejtoria e ruajtjes nuk është e disponueshme në tre rastet e para; në rastin e fundit, lidhja me hapësirën ruajtëse nuk ndërpritet. Së fundi, funksioni i përbashkët është plotësisht i përjashtuar për ruajtje në rastin e parë dhe është i mundur në pjesën tjetër. Në rastin e dytë, mund të ndani hapësirën ruajtëse në varësi të faktit nëse baza juaj e të dhënave mbështet hapësirën e shpërndarjes ose jo. Në rastin e Per-Host, shpërndarja e të dhënave është e mundur vetëm në një host të caktuar, dhe për një multihost sigurohet nga zgjerimi i grupit.
Kjo duhet të merret parasysh kur krijohen kontejnerë shtetërorë. Një tjetër mjet i dobishëm Docker është shtojca Volume, e cila funksionon në parimin e "bateritë janë të pranishme, por duhet të zëvendësohen". Kur filloni një kontejner Docker, ai thotë: "Hej, sapo të filloni një kontejner me një bazë të dhënash, mund t'i ruani të dhënat tuaja në këtë kontejner!" Ky është funksioni i paracaktuar, por ju mund ta ndryshoni atë. Kjo shtojcë ju lejon të përdorni një disk rrjeti ose diçka të ngjashme në vend të një databaze kontejneri. Ai përfshin një drejtues të paracaktuar për ruajtjen e bazuar në host dhe lejon integrimin e kontejnerëve me sistemet e ruajtjes së jashtme si Amazon EBS, Azure Storage dhe disqet GCE Persistent.
Sllajdi tjetër tregon arkitekturën e shtojcës Docker Volume.
Ngjyra blu përfaqëson klientin Docker të lidhur me hostin blu Docker, i cili ka një motor ruajtjeje lokale që ju ofron kontejnerë për ruajtjen e të dhënave. E gjelbra tregon Plugin Client dhe Plugin Daemon, të cilët janë gjithashtu të lidhur me hostin. Ato ofrojnë mundësinë për të ruajtur të dhënat në ruajtjen e rrjetit të llojit të Storage Backend që ju nevojitet.
Shtojca Docker Volume mund të përdoret me ruajtjen e Portworx. Moduli PX-Dev është në fakt një kontejner që ju drejtoni që lidhet me hostin tuaj Docker dhe ju lejon të ruani lehtësisht të dhënat në Amazon EBS.
Klienti Portworx ju lejon të monitoroni statusin e kontejnerëve të ndryshëm të ruajtjes që janë të lidhur me hostin tuaj. Nëse vizitoni blogun tim, mund të lexoni se si të përfitoni sa më shumë nga Portworx me Docker.
Koncepti i ruajtjes në Kubernetes është i ngjashëm me Docker dhe përfaqësohet nga drejtoritë që janë të aksesueshme për kontejnerin tuaj në një pod. Ato janë të pavarura nga jetëgjatësia e çdo kontejneri. Llojet më të zakonshme të ruajtjes në dispozicion janë hostPath, nfs, awsElasticBlockStore dhe gsePersistentDisk. Le të hedhim një vështrim se si funksionojnë këto dyqane në Kubernetes. Në mënyrë tipike, procesi i lidhjes së tyre përbëhet nga 3 hapa.
E para është që dikush në anën e rrjetit, zakonisht një administrator, ju ofron hapësirë ruajtëse të vazhdueshme. Ekziston një skedar konfigurimi përkatës i PersistentVolume për këtë. Më pas, zhvilluesi i aplikacionit shkruan një skedar konfigurimi të quajtur PersistentVolumeClaim, ose një kërkesë për ruajtje PVC, e cila thotë: "Unë kam 50 GB hapësirë ruajtëse të shpërndarë, por në mënyrë që njerëzit e tjerë të përdorin gjithashtu kapacitetin e tij, po i them këtij PVC që aktualisht nevojiten vetëm 10 GB". Së fundi, hapi i tretë është që kërkesa juaj të montohet si ruajtje dhe aplikacioni që ka podin, ose set replica, ose diçka të ngjashme, fillon ta përdorë atë. Është e rëndësishme të mbani mend se ky proces përbëhet nga 3 hapat e përmendur dhe është i shkallëzueshëm.
Sllajdi tjetër tregon Kubernetes Persistence Container të arkitekturës AWS.
Brenda drejtkëndëshit kafe që përfaqëson grupin Kubernetes, ka një nyje kryesore dhe dy nyje punëtore, të treguara me të verdhë. Një nga nyjet e punës përmban një pod portokalli, ruajtje, një kontrollues kopjues dhe një enë jeshile Docker Couchbase. Brenda grupit, mbi nyjet, një drejtkëndësh ngjyrë vjollce tregon Shërbimin e aksesueshëm nga jashtë. Kjo arkitekturë rekomandohet për ruajtjen e të dhënave në vetë pajisjen. Nëse është e nevojshme, mund t'i ruaj të dhënat e mia në EBS jashtë grupit, siç tregohet në rrëshqitjen tjetër. Ky është një model tipik për shkallëzimin, por duhet marrë parasysh një aspekt financiar kur e përdorni - ruajtja e të dhënave diku në rrjet mund të jetë më e shtrenjtë se sa në një host. Kur zgjidhni zgjidhjet e kontejnerizimit, ky është një nga argumentet me peshë.
Ashtu si me Docker, ju mund të përdorni kontejnerë të vazhdueshëm Kubernetes me Portworx.
Kjo është ajo që në terminologjinë aktuale të Kubernetes 1.6 quhet "StatefulSet" - një mënyrë për të punuar me aplikacionet Stateful që përpunojnë ngjarjet rreth ndalimit të Pod dhe kryerjes së Mbylljes Graceful. Në rastin tonë, aplikacione të tilla janë baza të të dhënave. Në blogun tim mund të lexoni se si të krijoni një StatefulSet në Kubernetes duke përdorur Portworx.
Le të flasim për aspektin e zhvillimit. Siç thashë, Docker ka 2 versione - CE dhe EE, në rastin e parë po flasim për një version të qëndrueshëm të Edicionit të Komunitetit, i cili përditësohet një herë në 3 muaj, në ndryshim nga versioni i përditësuar mujor i EE. Mund të shkarkoni Docker për Mac, Linux ose Windows. Pasi të instalohet, Docker do të përditësohet automatikisht dhe është shumë e lehtë për të filluar.
Për Kubernetes, unë preferoj versionin Minikube - është një mënyrë e mirë për të filluar me platformën duke krijuar një grup në një nyje të vetme. Për të krijuar grupime të disa nyjeve, zgjedhja e versioneve është më e gjerë: këto janë kops, kube-aws (CoreOS+AWS), kube-up (të vjetëruara). Nëse po kërkoni të përdorni Kubernetes me bazë AWS, ju rekomandoj t'i bashkoheni AWS SIG, i cili takohet në internet çdo të premte dhe publikon një sërë materialesh interesante për punën me AWS Kubernetes.
Le të shohim se si kryhet Përditësimi Rolling në këto platforma. Nëse ka një grup prej disa nyjeve, atëherë ai përdor një version specifik të imazhit, për shembull, WildFly:1. Një përditësim i vazhdueshëm do të thotë që versioni i imazhit zëvendësohet në mënyrë sekuenciale me një të ri në secilën nyje, njëri pas tjetrit.
Për ta bërë këtë, përdor komandën e përditësimit të shërbimit docker (emri i shërbimit), në të cilën specifikoj versionin e ri të imazhit WildFly:2 dhe metodën e përditësimit update-parallelism 2. Numri 2 do të thotë që sistemi do të përditësojë 2 imazhe aplikacioni në të njëjtën kohë, pastaj një vonesë 10 sekondash e përditësimit 10s, pas së cilës 2 imazhet e ardhshme do të përditësohen në 2 nyje të tjera, etj. Ky mekanizëm i thjeshtë përditësimi i rrotullimit ju ofrohet si pjesë e Docker.
Në Kubernetes, një përditësim i vazhdueshëm funksionon si kjo. Kontrolluesi i replikimit rc krijon një grup kopjesh të të njëjtit version dhe çdo pod në këtë webapp-rc pajiset me një etiketë të vendosur në etcd. Kur kam nevojë për një pod, unë përdor Shërbimin e Aplikimit për të hyrë në depon e etcd, e cila më siguron podin duke përdorur etiketën e specifikuar.
Në këtë rast, ne kemi 3 pods në kontrolluesin Replication që ekzekuton aplikacionin WildFly version 1. Kur përditësohet në sfond, krijohet një tjetër kontrollues replikimi me të njëjtin emër dhe indeks në fund - - xxxxx, ku x janë numra të rastit, dhe me të njëjtat etiketa. Tani Application Service ka tre pods me versionin e vjetër të aplikacionit dhe tre pods me versionin e ri në kontrolluesin e ri Replication. Pas kësaj, podet e vjetra fshihen, kontrolluesi i replikimit me podet e reja riemërtohet dhe vihet në funksion.
Le të kalojmë te monitorimi. Docker ka shumë komanda të integruara monitorimi. Për shembull, ndërfaqja e linjës komanduese të statistikave të kontejnerit docker ju lejon të shfaqni informacione për gjendjen e kontejnerëve në tastierë çdo sekondë - përdorimi i procesorit, përdorimi i diskut, ngarkesa e rrjetit. Mjeti Docker Remote API ofron të dhëna se si klienti komunikon me serverin. Ai përdor komanda të thjeshta, por bazohet në Docker REST API. Në këtë rast, fjalët REST, Flash, Remote nënkuptojnë të njëjtën gjë. Kur komunikoni me hostin, është një API REST. Docker Remote API ju lejon të merrni më shumë informacion në lidhje me drejtimin e kontejnerëve. Blogu im përshkruan detajet e përdorimit të këtij monitorimi me Windows Server.
Monitorimi i ngjarjeve të sistemit doker gjatë ekzekutimit të një grupi me shumë host bën të mundur marrjen e të dhënave në lidhje me një përplasje të hostit ose një përplasje kontejneri në një host specifik, shërbime të shkallëzimit dhe të ngjashme. Duke filluar me Docker 1.20, ai përfshin Prometheus, i cili fut pikat përfundimtare në aplikacionet ekzistuese. Kjo ju lejon të merrni metrikë përmes HTTP dhe t'i shfaqni ato në panelet e kontrollit.
Një veçori tjetër monitorimi është cAdvisor (shkurt për këshilltarin e kontejnerëve). Ai analizon dhe siguron përdorimin e burimeve dhe të dhëna të performancës nga kontejnerët që funksionojnë, duke ofruar metrikë Prometheus menjëherë. E veçanta e këtij mjeti është se ofron të dhëna vetëm për 60 sekondat e fundit. Prandaj, ju duhet të jeni në gjendje t'i grumbulloni këto të dhëna dhe t'i vendosni ato në një bazë të dhënash në mënyrë që të mund të monitoroni një proces afatgjatë. Mund të përdoret gjithashtu për të shfaqur grafikisht metrikat e pultit duke përdorur Grafana ose Kibana. Blogu im ka një përshkrim të hollësishëm se si të përdoret cAdvisor për të monitoruar kontejnerët duke përdorur pultin e Kibana.
Sllajdi tjetër tregon se si duket dalja e pikës fundore të Prometheus dhe metrikat e disponueshme për t'u shfaqur.
Në pjesën e poshtme majtas shihni matjet për kërkesat HTTP, përgjigjet, etj., në të djathtë është shfaqja e tyre grafike.
Kubernetes përfshin gjithashtu mjete të integruara monitorimi. Ky rrëshqitje tregon një grup tipik që përmban një master dhe tre nyje punëtore.
Secila prej nyjeve të punës përmban një cAdvisor të nisur automatikisht. Për më tepër, ekziston Heapster, një sistem monitorimi i performancës dhe grumbullimi i metrikës i pajtueshëm me versionin 1.0.6 dhe më të lartë të Kubernetes. Heapster ju lejon të grumbulloni jo vetëm matjet e performancës së ngarkesave të punës, pods dhe kontejnerëve, por edhe ngjarje dhe sinjale të tjera të krijuara nga i gjithë grupi. Për të mbledhur të dhëna, ai flet me Kubelet-in e çdo pod, ruan automatikisht informacionin në bazën e të dhënave InfluxDB dhe i nxjerr ato si metrikë në panelin e kontrollit Grafana. Megjithatë, mbani në mend se nëse jeni duke përdorur miniKube, kjo veçori nuk është e disponueshme si parazgjedhje, kështu që do t'ju duhet të përdorni shtesa për monitorim. Pra, gjithçka varet nga vendi ku i përdorni kontejnerët dhe cilat mjete monitorimi mund të përdorni si parazgjedhje dhe cilat duhet t'i instaloni si shtesa të veçanta.
Sllajdi tjetër tregon panelet e Grafana-s që tregojnë statusin e funksionimit të kontejnerëve të mi. Këtu ka mjaft të dhëna interesante. Sigurisht, ka shumë mjete komerciale të monitorimit të procesit Docker dhe Kubernetes, të tilla si SysDig, DataDog, NewRelic. Disa prej tyre kanë një periudhë prove falas 30-vjeçare, kështu që mund të provoni të gjeni atë që ju përshtatet më së miri. Personalisht, unë preferoj të përdor SysDig dhe NewRelic, të cilat integrohen mirë me Kubernetes. Ka mjete që integrohen po aq mirë në platformat Docker dhe Kubernetes.
Disa reklama 🙂
Faleminderit që qëndruat me ne. A ju pëlqejnë artikujt tanë? Dëshironi të shihni përmbajtje më interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar miqve, , një analog unik i serverëve të nivelit të hyrjes, i cili u shpik nga ne për ju: (e disponueshme me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40 GB DDR4).
Dell R730xd 2 herë më lirë në qendrën e të dhënave Equinix Tier IV në Amsterdam? Vetëm këtu në Holandë! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - nga 99 dollarë! Lexoni rreth
Burimi: www.habr.com