Ang Docker Swarm, Kubernetes, ug Mesos mao ang pinakasikat nga container orchestration frameworks. Sa iyang pakigpulong, gitandi ni Arun Gupta ang mosunod nga mga aspeto sa Docker, Swarm, ug Kubernetes:
- Lokal nga kalamboan.
- Mga gimbuhaton sa pag-deploy.
- Multi-container nga mga aplikasyon.
- Pagdiskobre sa serbisyo.
- Pag-scale sa serbisyo.
- Dagan-kausa nga mga buluhaton.
- Paghiusa sa Maven.
- Pag-update sa "Rolling".
- Paghimo og Couchbase database cluster.
Ingon usa ka sangputanan, makakuha ka usa ka tin-aw nga pagsabut kung unsa ang gitanyag sa matag himan sa orkestrasyon ug mahibal-an kung giunsa paggamit kini nga mga platform nga epektibo.
Si Arun Gupta mao ang punoan nga technologist alang sa mga open-source nga mga produkto sa Amazon Web Services, nga nagpalambo sa Sun, Oracle, Red Hat ug Couchbase developer nga mga komunidad sulod sa kapin sa 10 ka tuig. Adunay daghang kasinatian nga nagtrabaho sa nanguna nga mga cross-functional team nga nagpalambo ug nagpatuman sa estratehiya alang sa mga kampanya ug programa sa pagpamaligya. Gipangunahan niya ang mga koponan sa mga inhenyero sa Sun, usa sa mga nagtukod sa Java EE team ug ang tiglalang sa sanga sa US sa Devoxx4Kids. Si Arun Gupta mao ang tagsulat sa labaw pa sa 2 ka libo nga mga post sa mga blog sa IT ug naghatag mga pakigpulong sa labaw sa 40 nga mga nasud.
Ang Linya 55 adunay COUCHBASE_URI nga nagtudlo niini nga serbisyo sa database, nga gihimo usab gamit ang Kubernetes configuration file. Kung imong tan-awon ang linya 2, makita nimo ang mabination: Ang serbisyo mao ang serbisyo nga akong gihimo nga gitawag nga couchbase-service, ug parehas nga ngalan ang gilista sa linya 4. Sa ubos ang pipila ka mga pantalan.
Ang yawe nga mga linya mao ang 6 ug 7. Sa pag-alagad moingon ko, "Uy, kini ang mga label nga akong gipangita!", Ug kini nga mga label wala'y lain gawas sa variable nga mga ngalan sa pares, ug ang linya nga 7 nagpunting sa akong couchbase-rs-pod aplikasyon. Ang mosunud mao ang mga pantalan nga naghatag access sa parehas nga mga label.
Sa linya 19 naghimo ko og bag-ong tipo nga ReplicaSet, ang linya 31 naglangkob sa ngalan sa hulagway, ug ang mga linya 24-27 nagpunting sa metadata nga nalangkit sa akong pod. Mao gyud kini ang gipangita sa serbisyo ug kung unsa ang koneksyon kinahanglan buhaton. Sa katapusan sa file adunay usa ka matang sa koneksyon tali sa mga linya 55-56 ug 4, nga nag-ingon: "gamita kini nga serbisyo!"
Busa, gisugdan nako ang akong serbisyo kung adunay replica set, ug tungod kay ang matag replika nga set adunay kaugalingon nga pantalan nga adunay katugbang nga label, gilakip kini sa serbisyo. Gikan sa punto sa panglantaw sa usa ka developer, tawagan lang nimo ang serbisyo, nga gigamit dayon ang set sa mga replika nga imong gikinahanglan.
Ingon nga resulta, ako adunay usa ka WildFly pod nga nakigsulti sa database backend pinaagi sa Couchbase Service. Magamit nako ang frontend sa daghang mga WildFly pod, nga nakigsulti usab sa backend sa couchbase pinaagi sa serbisyo sa couchbase.
Sa ulahi atong tan-awon kung giunsa ang usa ka serbisyo nga nahimutang sa gawas sa cluster nakigsulti pinaagi sa IP address niini nga adunay mga elemento nga nahimutang sa sulod sa cluster ug adunay internal nga IP address.
Busa, ang mga walay estado nga mga sudlanan maayo, apan unsa ka maayo ang paggamit sa stateful nga mga sudlanan? Atong tan-awon ang mga setting sa sistema alang sa stateful, o padayon nga mga sudlanan. Sa Docker, adunay 4 nga lainlaing mga pamaagi sa layout sa pagtipig sa datos nga kinahanglan nimong hatagan pagtagad. Ang una mao ang Implicit Per-Container, nga nagpasabot nga kung mogamit og couchbase, MySQL o MyDB satateful nga mga sudlanan, silang tanan magsugod sa default Sandbox. Kana mao, ang tanan nga gitipigan sa database gitipigan sa sudlanan mismo. Kung ang sudlanan mawala, ang data mawala uban niini.
Ang ikaduha mao ang Explicit Per-Container, kung maghimo ka usa ka piho nga pagtipig nga adunay gidaghanon sa docker paghimo og mando ug pagtipig sa datos niini. Ang ikatulo nga Per-Host nga pamaagi nalangkit sa storage mapping, kung ang tanan nga gitipigan sa sudlanan dungan nga gi-duplicate sa host. Kung mapakyas ang sudlanan, ang datos magpabilin sa host. Ang ulahi mao ang paggamit sa daghang mga host sa Multi-Host, nga gitambagan sa yugto sa produksiyon sa lainlaing mga solusyon. Ingnon ta nga ang imong mga sudlanan nga adunay imong mga aplikasyon nagdagan sa host, apan gusto nimo nga tipigan ang imong data sa usa ka lugar sa Internet, ug alang niini gigamit nimo ang awtomatikong pagmapa alang sa mga gipang-apod-apod nga mga sistema.
Ang matag usa niini nga mga pamaagi naggamit sa usa ka piho nga lokasyon sa pagtipig. Ang Implicit ug Explicit Per-Container nagtipig og datos sa host sa /var/lib/docker/volume. Kung gigamit ang pamaagi sa Per-Host, ang pagtipig gi-mount sa sulod sa sudlanan, ug ang sudlanan mismo gi-mount sa host. Alang sa mga multihost, ang mga solusyon sama sa Ceph, ClusterFS, NFS, ug uban pa mahimong magamit.
Kung mapakyas ang usa ka padayon nga sudlanan, ang direktoryo sa pagtipig mahimong dili ma-access sa una nga duha nga mga kaso, apan sa katapusan nga duha nga mga kaso ang pag-access gipadayon. Bisan pa, sa una nga kaso, mahimo nimong ma-access ang repository pinaagi sa usa ka host sa Docker nga nagdagan sa usa ka virtual machine. Sa ikaduha nga kaso, ang data dili usab mawala, tungod kay nakabuhat ka ug usa ka Explicit storage.
Kung mapakyas ang host, ang direktoryo sa pagtipig dili magamit sa una nga tulo nga mga kaso; sa katapusan nga kaso, ang koneksyon sa pagtipig dili mabalda. Sa katapusan, ang gipaambit nga function hingpit nga wala iapil alang sa pagtipig sa una nga kaso ug posible sa uban. Sa ikaduha nga kaso, mahimo nimong ipaambit ang pagtipig depende kung ang imong database nagsuporta sa giapod-apod nga pagtipig o dili. Sa kaso sa Per-Host, ang pag-apod-apod sa datos posible lamang sa usa ka gihatag nga host, ug alang sa usa ka multihost kini gihatag pinaagi sa pagpalapad sa cluster.
Kini kinahanglan nga tagdon sa paghimo sa stateful nga mga sudlanan. Ang laing mapuslanon nga himan sa Docker mao ang Volume plugin, nga naglihok sa prinsipyo sa "mga baterya nga anaa, apan kinahanglan nga pulihan." Kung magsugod ka sa usa ka sudlanan sa Docker, kini nag-ingon, "Uy, kung magsugod ka usa ka sudlanan nga adunay database, mahimo nimong tipigan ang imong data sa kini nga sudlanan!" Kini ang default nga bahin, apan mahimo nimo kini usbon. Kini nga plugin nagtugot kanimo sa paggamit sa usa ka network drive o usa ka butang nga susama imbes sa usa ka container database. Naglakip kini sa usa ka default nga drayber alang sa pagtipig nga nakabase sa host ug gitugotan ang panagsama sa sulud sa mga eksternal nga sistema sa pagtipig sama sa Amazon EBS, Azure Storage ug GCE Persistent disks.
Ang sunod nga slide nagpakita sa arkitektura sa Docker Volume plugin.
Ang asul nga kolor nagrepresentar sa kliyente sa Docker nga nakig-uban sa asul nga Docker host, nga adunay usa ka Lokal nga storage engine nga naghatag kanimo mga sulud alang sa pagtipig sa datos. Ang Green nagpaila sa Plugin Client ug Plugin Daemon, nga konektado usab sa host. Naghatag sila og oportunidad sa pagtipig sa datos sa pagtipig sa network sa matang sa Storage Backend nga imong gikinahanglan.
Ang Docker Volume plugin mahimong magamit sa pagtipig sa Portworx. Ang module sa PX-Dev sa tinuud usa ka sudlanan nga imong gipadagan nga nagkonektar sa imong host sa Docker ug gitugotan ka nga dali nga magtipig data sa Amazon EBS.
Gitugotan ka sa kliyente sa Portworx nga mamonitor ang kahimtang sa lainlaing mga sudlanan sa pagtipig nga konektado sa imong host. Kung mobisita ka sa akong blog, mabasa nimo kung giunsa ang pagpahimulos sa Portworx sa Docker.
Ang konsepto sa pagtipig sa Kubernetes susama sa Docker ug girepresentahan sa mga direktoryo nga ma-access sa imong sudlanan sa usa ka pod. Sila independente sa tibuok kinabuhi sa bisan unsang sudlanan. Ang labing kasagaran nga mga tipo sa pagtipig nga magamit mao ang hostPath, nfs, awsElasticBlockStore, ug gsePersistentDisk. Atong tan-awon kung giunsa kini nga mga tindahan sa Kubernetes. Kasagaran, ang proseso sa pagkonektar kanila naglangkob sa 3 nga mga lakang.
Ang una mao nga ang usa ka tawo sa kilid sa network, kasagaran usa ka administrador, naghatag kanimo kanunay nga pagtipig. Adunay katugbang nga PersistentVolume configuration file alang niini. Sunod, ang developer sa aplikasyon nagsulat og configuration file nga gitawag og PersistentVolumeClaim, o usa ka PVC storage request, nga nag-ingon: "Adunay 50GB nga giapod-apod nga storage nga gihatag, apan aron magamit usab sa ubang mga tawo ang kapasidad niini, gisultihan ko kini nga PVC nga ako karon. kinahanglan lang 10 GB". Sa katapusan, ang ikatulo nga lakang mao nga ang imong hangyo gi-mount ingon pagtipig, ug ang aplikasyon nga adunay pod, o replica set, o usa ka butang nga parehas, nagsugod sa paggamit niini. Importante nga hinumdoman nga kini nga proseso naglangkob sa 3 nga mga lakang nga gihisgutan ug scalable.
Ang sunod nga slide nagpakita sa Kubernetes Persistence Container sa AWS architecture.
Sulod sa brown nga rectangle nga nagrepresentar sa Kubernetes cluster, adunay usa ka master node ug duha ka worker node, nga gipakita sa yellow. Ang usa sa mga worker node adunay usa ka orange pod, storage, usa ka replica controller, ug usa ka green nga Docker Couchbase nga sudlanan. Sa sulod sa cluster, sa ibabaw sa mga node, usa ka purpura nga rektanggulo nagpakita sa Serbisyo nga ma-access gikan sa gawas. Kini nga arkitektura girekomenda alang sa pagtipig sa datos sa aparato mismo. Kung gikinahanglan, mahimo nakong tipigan ang akong data sa EBS sa gawas sa cluster, sama sa gipakita sa sunod nga slide. Kini usa ka tipikal nga modelo alang sa scaling, apan adunay usa ka pinansyal nga aspeto nga ikonsiderar kung gamiton kini - ang pagtipig sa datos sa usa ka lugar sa network mahimong mas mahal kaysa sa usa ka host. Kung nagpili mga solusyon sa containerization, kini usa sa mga bug-at nga argumento.
Sama sa Docker, mahimo nimong gamiton ang kanunay nga mga sulud sa Kubernetes nga adunay Portworx.
Mao kini ang gitawag sa kasamtangang terminolohiya sa Kubernetes 1.6 nga "StatefulSet" - usa ka paagi sa pagtrabaho uban sa Stateful nga mga aplikasyon nga nagproseso sa mga panghitabo mahitungod sa paghunong sa Pod ug paghimo sa Grasyaful Shutdown. Sa among kaso, ang ingon nga mga aplikasyon mga database. Sa akong blog mabasa nimo kung unsaon paghimo ug StatefulSet sa Kubernetes gamit ang Portworx.
Atong hisgotan ang bahin sa kalamboan. Sama sa akong giingon, ang Docker adunay 2 nga bersyon - CE ug EE, sa una nga kaso naghisgot kami bahin sa usa ka lig-on nga bersyon sa Community Edition, nga gi-update kausa matag 3 ka bulan, sukwahi sa binulan nga gi-update nga bersyon sa EE. Mahimo nimong i-download ang Docker alang sa Mac, Linux o Windows. Sa higayon nga ma-install, ang Docker awtomatikong mag-update ug kini sayon ββββkaayo nga magsugod.
Para sa mga Kubernetes, mas gusto nako ang bersyon sa Minikube - kini usa ka maayong paagi sa pagsugod sa plataporma pinaagi sa paghimo og cluster sa usa ka node. Aron makahimo og mga pungpong sa daghang mga node, ang pagpili sa mga bersyon mas lapad: kini mao ang mga kops, kube-aws (CoreOS+AWS), kube-up (karaan na). Kung nangita ka nga mogamit sa mga Kubernetes nga nakabase sa AWS, girekomenda ko ang pag-apil sa AWS SIG, nga nagkita online matag Biyernes ug nagpatik sa lainlaing makapaikag nga mga materyal sa pagtrabaho kauban ang AWS Kubernetes.
Atong tan-awon kung giunsa gihimo ang Rolling Update sa kini nga mga platform. Kung adunay usa ka pungpong sa daghang mga node, nan kini naggamit sa usa ka piho nga bersyon sa imahe, pananglitan, WildFly:1. Ang usa ka rolling update nagpasabot nga ang imahe nga bersyon sa sunod-sunod nga gipulihan sa usa ka bag-o sa matag node, sa usa ka sunod-sunod nga.
Aron mahimo kini, gigamit nako ang mando sa pag-update sa serbisyo sa docker (pangalan sa serbisyo), diin akong gipiho ang bag-ong bersyon sa WildFly: 2 nga imahe ug ang pamaagi sa pag-update update-parallelism 2. Ang numero 2 nagpasabut nga ang sistema mag-update sa 2 nga mga imahe sa aplikasyon sa samang higayon, unya usa ka 10-segundos nga paglangan sa pag-update 10s, pagkahuman ang sunod nga 2 nga mga imahe ma-update sa 2 pa nga mga node, ug uban pa. Kining yano nga rolling update nga mekanismo gihatag kanimo isip bahin sa Docker.
Sa Kubernetes, ang usa ka rolling update naglihok sama niini. Ang replication controller rc nagmugna og usa ka set sa mga replika sa parehas nga bersyon, ug ang matag pod niini nga webapp-rc gihatagan og label nga nahimutang sa etcd. Kung kinahanglan nako ang usa ka pod, gigamit nako ang Application Service aron ma-access ang etcd repository, nga naghatag kanako sa pod gamit ang gitakda nga label.
Sa kini nga kaso, kami adunay 3 pod sa Replication controller nga nagpadagan sa WildFly nga bersyon 1 nga aplikasyon. Kung nag-update sa background, lain nga replication controller ang gihimo nga adunay parehas nga ngalan ug indeks sa katapusan - - xxxxx, diin ang x mga random nga numero, ug nga adunay parehas nga mga label. Karon ang Application Service adunay tulo ka pod nga adunay daan nga bersyon sa aplikasyon ug tulo ka pod nga adunay bag-ong bersyon sa bag-ong Replication controller. Pagkahuman niini, ang mga daan nga pod gitangtang, ang replication controller nga adunay bag-ong mga pod gipangalan ug gipalihok.
Mopadayon kita sa pagmonitor. Ang Docker adunay daghang mga built-in nga mga mando sa pag-monitor. Pananglitan, ang docker container stats command line interface nagtugot kanimo sa pagpakita sa impormasyon mahitungod sa kahimtang sa mga sudlanan ngadto sa console matag segundo - paggamit sa processor, paggamit sa disk, pagkarga sa network. Ang tool sa Docker Remote API naghatag og datos kung giunsa ang pagpakigsulti sa kliyente sa server. Naggamit kini og yano nga mga sugo, apan gibase sa Docker REST API. Sa kini nga kaso, ang mga pulong nga REST, Flash, Remote nagpasabut sa parehas nga butang. Kung nakigsulti ka sa host, kini usa ka REST API. Gitugotan ka sa Docker Remote API nga makakuha dugang nga kasayuran bahin sa pagpadagan sa mga sudlanan. Ang akong blog naglatid sa mga detalye sa paggamit niini nga pagmonitor sa Windows Server.
Ang pagmonitor sa mga panghitabo sa sistema sa docker kung nagpadagan sa usa ka multi-host cluster nagpaposible nga makakuha og datos bahin sa usa ka host crash o usa ka container crash sa usa ka piho nga host, scaling services, ug uban pa. Sugod sa Docker 1.20, nag-uban kini sa Prometheus, nga nag-embed sa mga endpoint sa mga naa na nga aplikasyon. Gitugotan ka niini nga makadawat mga sukatan pinaagi sa HTTP ug ipakita kini sa mga dashboard.
Ang laing bahin sa pagmonitor mao ang cAdvisor (mubo sa container advisor). Kini nag-analisa ug naghatag og resource usage ug performance data gikan sa running containers, naghatag og Prometheus metrics sa gawas sa kahon. Ang espesyal nga butang bahin sa kini nga himan mao nga naghatag lamang kini og datos sa katapusang 60 segundos. Busa, kinahanglan nimo nga makolekta kini nga datos ug ibutang kini sa usa ka database aron mamonitor nimo ang usa ka dugay nga proseso. Mahimo usab kini gamiton aron ipakita ang mga sukatan sa dashboard sa grapiko gamit ang Grafana o Kibana. Ang akong blog adunay usa ka detalyado nga paghulagway kung giunsa paggamit ang cAdvisor aron ma-monitor ang mga sulud gamit ang dashboard sa Kibana.
Ang sunod nga slide nagpakita kung unsa ang hitsura sa Prometheus endpoint output ug ang mga sukatan nga magamit aron ipakita.
Sa ubos sa wala makita nimo ang mga sukatan para sa mga hangyo sa HTTP, mga tubag, ug uban pa, sa tuo mao ang ilang graphical nga pagpakita.
Ang Kubernetes naglakip usab sa built-in nga mga himan sa pagmonitor. Kini nga slide nagpakita sa usa ka tipikal nga cluster nga adunay usa ka master ug tulo ka worker node.
Ang matag usa sa nagtrabaho nga mga node adunay usa ka awtomatik nga gilunsad nga cAdvisor. Dugang pa, adunay Heapster, usa ka pag-monitor sa pasundayag ug sistema sa pagkolekta sa sukatan nga nahiuyon sa bersyon sa Kubernetes 1.0.6 ug mas taas pa. Gitugotan ka sa Heapster nga mangolekta dili lamang mga sukatan sa pasundayag sa mga workloads, pods ug mga sudlanan, apan usab mga panghitabo ug uban pang mga signal nga nahimo sa tibuuk nga cluster. Aron makolekta ang datos, nakigsulti kini sa Kubelet sa matag pod, awtomatiko nga gitipigan ang kasayuran sa database sa InfluxDB, ug gi-output kini ingon mga sukatan sa dashboard sa Grafana. Bisan pa, hinumdomi nga kung naggamit ka miniKube, kini nga bahin dili magamit sa default, busa kinahanglan nimo nga mogamit mga addon alang sa pag-monitor. Mao nga kini tanan nagdepende kung diin nimo gipadagan ang mga sulud ug kung unsang mga himan sa pag-monitor ang mahimo nimong gamiton nga default ug kinahanglan nimo nga i-install ingon lahi nga mga add-on.
Ang sunod nga slide nagpakita sa Grafana dashboard nga nagpakita sa running status sa akong mga sudlanan. Adunay daghang makapaikag nga datos dinhi. Siyempre, adunay daghang komersyal nga Docker ug Kubernetes nga mga himan sa pag-monitor sa proseso, sama sa SysDig, DataDog, NewRelic. Ang uban kanila adunay 30 ka tuig nga libre nga panahon sa pagsulay, aron imong sulayan ug pangitaon ang usa nga labing angay kanimo. Sa personal, mas gusto nako nga gamiton ang SysDig ug NewRelic, nga maayo ang pag-integrate sa Kubernetes. Adunay mga himan nga parehas nga gisagol sa Docker ug Kubernetes nga mga platform.
Pipila ka mga ad π
Salamat sa pagpabilin kanamo. Ganahan ka ba sa among mga artikulo? Gusto nga makakita og mas makapaikag nga sulod? Suportahi kami pinaagi sa pag-order o pagrekomenda sa mga higala, , usa ka talagsaon nga analogue sa mga entry-level server, nga giimbento namo alang kanimo: (anaa sa RAID1 ug RAID10, hangtod sa 24 ka mga core ug hangtod sa 40GB DDR4).
Dell R730xd 2 ka beses nga mas barato sa Equinix Tier IV data center sa Amsterdam? Dinhi lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - gikan sa $99! Basaha ang mahitungod sa
Source: www.habr.com