Mi sugestas vin legi la transskribon de la raporto de Aleksandro Sigaĉev Servo-Malkovro en distribuitaj sistemoj uzante Konsulo kiel ekzemplon.
Service Discovery estis kreita por ke je minimuma kosto vi povu konekti novan aplikaĵon al nia ekzistanta medio. Uzante Service Discovery, ni povas maksimume apartigi aŭ docker-ujon aŭ virtualan servon de la medio en kiu ĝi funkcias.
Mi bonvenigas ĉiujn! Mi estas Aleksandr Sigaĉev, mi laboras ĉe Inventos. Kaj hodiaŭ mi prezentos al vi tian koncepton kiel Service Discovery. Ni rigardu Service Discovery uzante Consul kiel ekzemplon.
Kiajn problemojn Solvas Service Discovery? Service Discovery estis kreita por ke je minimuma kosto vi povu konekti novan aplikaĵon al nia ekzistanta medio. Uzante Service Discovery, ni povas maksimume apartigi aŭ docker-ujon aŭ virtualan servon de la medio en kiu ĝi funkcias.
Kiel ĝi aspektas? En klasika ekzemplo en la reto, ĉi tiu estas la antaŭa finaĵo, kiu akceptas la peton de la uzanto. Poste ĝi direktas ĝin al la backend. En ĉi tiu ekzemplo, ĉi tiu ŝarĝo-balancilo ekvilibrigas du backends.
Ĉi tie ni vidas, ke ni lanĉas trian okazon de la aplikaĵo. Sekve, kiam la aplikaĵo komenciĝas, ĝi registras ĉe Service Discovery. Service Discovery sciigas ŝarĝbalancilon. Ŝarĝbalancilo ŝanĝas sian agordon aŭtomate kaj la nova backend ekfunkcias. Tiamaniere, backends povas esti aldonitaj, aŭ, male, ekskluditaj de laboro.
Kion alian konvenas fari kun Service Discovery? Service Discovery povas stoki nginx-agordojn, atestilojn kaj liston de aktivaj backend-serviloj.
Service Discovery ankaŭ permesas vin detekti misfunkciadojn kaj detekti misfunkciadojn. Kio estas la eblaj skemoj por detekti fiaskojn?
- Ĉi tiu aplikaĵo, kiun ni disvolvis, aŭtomate sciigas al Service Discovery, ke ĝi ankoraŭ funkcias.
- Service Discovery, siaflanke, sondas la aplikaĵon pri havebleco.
- Aŭ ni uzas triapartan skripton aŭ aplikaĵon, kiu kontrolas nian aplikaĵon pri havebleco kaj sciigas al Service Discovery, ke ĉio estas bona kaj povas funkcii, aŭ, male, ke ĉio estas malbona kaj ĉi tiu kazo de la aplikaĵo devas esti ekskludita de ekvilibro.
Ĉiu el la skemoj povas esti uzata depende de kia programaro ni uzas. Ekzemple, ni ĵus komencis evoluigi novan projekton, tiam ni povas facile provizi skemon kiam nia aplikaĵo sciigas Service Discovery. Aŭ ni povas konekti tiun Service Discovery kontrolas.
Se ni heredis la aplikaĵon aŭ estis evoluigitaj de iu alia, tiam la tria opcio taŭgas kiam ni skribas pritraktilon, kaj ĉio ĉi eniras nian laboron aŭtomate.
Ĉi tio estas unu ekzemplo. Ŝarĝbalancilo en la formo de nginx estas rekomencita. Ĉi tio estas laŭvola ilo, kiu estas provizita per Consul. Ĉi tio estas konsul-ŝablono. Ni priskribas la regulon. Ni diras, ke ni uzas ŝablonon (Golang Template Engine). Kiam okazas eventoj, kiam sciigoj, ke ŝanĝoj okazis, ĝi estas regenerita kaj la "reŝargi" komando estas sendita al Service Discovery. La plej simpla ekzemplo estas kiam nginx estas reagordita per evento kaj rekomencita.
Kio estas Konsulo?
-
Antaŭ ĉio, ĉi tio estas Service Discovery.
-
Ĝi havas havebleckontrolan mekanismon - Sankontrolo.
-
Ĝi ankaŭ havas KV-Butikon.
-
Kaj ĝi baziĝas sur la kapablo uzi Multi Datacenter.
Por kio ĉio ĉi povas esti uzata? En la KV Store ni povas stoki ekzemplojn agordojn. Sankontrolo ni povas kontroli la lokan servon kaj sciigi. Multi Datacenter estas uzata tiel ke servomapo povas esti konstruita. Ekzemple, Amazon havas plurajn zonojn kaj vojigas trafikon en la plej optimuma maniero, por ke ne estu nenecesaj petoj inter datumcentroj, kiuj estas ŝargitaj aparte de loka trafiko kaj, sekve, havas malpli da latencia.
Ni komprenu iomete pri la terminoj uzataj en Consul.
- Konsulo estas servo skribita en Go. Unu el la avantaĝoj de Go-programo estas 1 binara dosiero, kiun vi ĵus elŝutas. Lanĉite de ie ajn kaj vi ne havas dependecojn.
- Tiam, uzante la klavojn, ni povas komenci ĉi tiun servon aŭ en klienta reĝimo aŭ en servila reĝimo.
- Ankaŭ, la atributo "datumcentro" permesas vin agordi flagon, al kiu datumcentro apartenas ĉi tiu servilo.
- Interkonsento - bazita sur la flosa protokolo. Se iu interesiĝas, vi povas legi pli pri tio en la retejo de Konsulo. Ĉi tio estas protokolo, kiu permesas vin determini la gvidanton kaj determini, kiu mono estas konsiderata valida kaj alirebla.
- Klaĉo estas protokolo kiu ebligas interagadon inter nodoj. Krome, ĉi tiu sistemo estas malcentralizita. Ene de unu datumcentro, ĉiuj nodoj komunikas kun siaj najbaroj. Kaj, sekve, informoj pri la nuna stato estas transdonitaj unu al la alia. Ni povas diri, ke tio estas klaĉo inter najbaroj.
- LAN Gossip - loka datuma interŝanĝo inter najbaroj ene de la sama datumcentro.
- WAN Gossip - uzata kiam ni bezonas sinkronigi informojn inter du datumcentroj. Informoj fluas inter nodoj kiuj estas markitaj kiel servilo.
- RPC - permesas al vi plenumi petojn per kliento sur servilo.
Priskribo de RPC. Ni diru, ke Konsulo funkcias kiel kliento sur virtuala maŝino aŭ fizika servilo. Ni kontaktas lin loke. Kaj tiam la loka kliento petas informojn de la servilo kaj estas sinkronigita. Depende de la agordoj, informoj povas esti prenitaj de la loka kaŝmemoro, aŭ povas esti sinkronigitaj kun la gvidanto, kun la servila mastro.
Ĉi tiuj du skemoj havas ambaŭ avantaĝojn kaj malavantaĝojn. Se ni laboras kun loka kaŝmemoro, tiam ĝi estas rapida. Se ni laboras kun datumoj stokitaj en la servilo, ĝi prenas pli longe, sed ni ricevas pli gravajn informojn.
Se vi prezentas ĉi tion grafike, tiam ĉi tiu estas la bildo de la retejo. Ni vidas, ke ni havas tri majstrojn kurantajn. Unu estas markita per asterisko kiel gvidanto. En ĉi tiu ekzemplo, estas tri klientoj kiuj interŝanĝas informojn loke unu kun la alia per UDP/TCP. Kaj informoj inter datumcentroj estas transdonitaj inter serviloj. Ĉi tie klientoj interagas unu kun la alia loke.
Kiun API provizas Konsulo? Por akiri informojn, Konsulo havas du specojn de API.
Ĉi tio estas la DNS-API. Defaŭlte, Consul funkcias per haveno 8600. Ni povas agordi peton-proxiadon kaj disponigi aliron per loka rezolucio, per loka DNS. Ni povas demandi per domajno kaj ricevi IP-adresinformojn kiel respondo.
HTTP API - aŭ ni povas loke peti informojn pri specifa servo sur haveno 8500 kaj ricevi JSON-respondon, kian IP havas la servilo, kian gastiganton, kian havenon estas registrita. Kaj pliaj informoj povas esti transdonitaj per ĵetono.
Kion vi bezonas por administri Konsulo?
En la unua opcio, en programista reĝimo ni indikas la flagon, ke ĉi tio estas programista reĝimo. Agento komenciĝas kiel servilo. Kaj ĝi plenumas la tutan funkcion sendepende sur unu maŝino. Por la unua komenco necesas konvena, rapida kaj preskaŭ neniuj aldonaj agordoj.
La dua reĝimo estas lanĉo en produktado. Ĉi tie komenci fariĝas iom komplika. Se ni ne havas ajnan version de la konsulo, tiam ni devas alporti la unuan maŝinon en bootstrap, t.e. ĉi tiun maŝinon, kiu prenos la respondecojn de la gvidanto. Ni levas ĝin, tiam ni levas la duan okazon de la servilo, pasante al ĝi informojn, kie troviĝas nia mastro. Ni levas la trian. Post kiam ni havas tri maŝinojn, ni rekomencas ĝin en normala reĝimo sur la unua maŝino de la kuranta botostrap. La datumoj estas sinkronigitaj kaj la komenca areto jam estas supren.
Oni rekomendas ruli tri ĝis sep okazojn en servila reĝimo. Ĉi tio estas pro la fakto, ke se la nombro da serviloj kreskas, tiam la tempo por sinkronigi informojn inter ili pliiĝas. La nombro da nodoj devas esti nepara por certigi kvorumon.
Kiel estas provizitaj Sankontroloj? Ni skribas kontrolan regulon en la formo de Json en la agorda dosierujo de Konsulo. La unua opcio estas la havebleco de la domajno google.com en ĉi tiu ekzemplo. Kaj ni diras, ke ĉi tiu kontrolo devas esti farita je intervaloj de 30 sekundoj. Tiel ni kontrolas, ke nia nodo havas aliron al la ekstera reto.
La dua eblo estas kontroli vin mem. Ni uzas regulan buklon por voki localhost sur la specifita haveno je intervaloj de 10 sekundoj.
Ĉi tiuj ĉekoj estas resumitaj kaj senditaj al Service Discovery. Surbaze de havebleco, ĉi tiuj nodoj estas aŭ ekskluditaj aŭ aperas en la listo de disponeblaj kaj ĝuste laborantaj maŝinoj.
Konsulo ankaŭ disponigas UI-interfacon, kiu estas lanĉita kun aparta flago kaj estos havebla sur la maŝino. Ĉi tio ebligas al vi vidi informojn kaj vi ankaŭ povas fari kelkajn ŝanĝojn.
En ĉi tiu ekzemplo, la langeto "Servo" estas malfermita. Estas montrite ke tri servoj funkcias, unu el ili estas Konsulo. Nombro de kontroloj faritaj. Kaj estas tri datumcentroj, en kiuj troviĝas la maŝinoj.
Ĉi tio estas ekzemplo de la langeto Nodoj. Ni vidas, ke ili havas kunmetitajn nomojn implikantajn datumcentrojn. Ĝi ankaŭ montras, kiuj servoj funkcias, t.e. ni vidas, ke neniuj etikedoj estas fiksitaj. Ĉi tiuj aldonaj etikedoj povas provizi iujn informojn, kiujn la programisto povas uzi por specifi pliajn parametrojn.
Vi ankaŭ povas transdoni informojn al Konsulo pri la stato de diskoj kaj averaĝa ŝarĝo.
Viaj demandoj
Demando: Ni havas docker-ujon, kiel uzi ĝin kun Consul?
Respondo: Estas pluraj aliroj por docker-ujo. Unu el la plej oftaj estas uzi trian docker-ujon respondecan pri registrado. Ĉe ekfunkciigo, docker-ingo estas transdonita al ĝi. Ĉiuj kontenregistrado kaj malpublikigokazaĵoj estas registritaj en Konsulo.
Demando: Do Konsulo mem lanĉas la docker-ujon?
Respondo: Ne. Ni prizorgas docker-ujon. Kaj dum agordado ni indikas - aŭskultu tian kaj tian ingon. Ĉi tio estas proksimume la sama kiel kiel ni laboras kun atestilo, kiam ni alŝutas informojn pri kie kaj kion ni havas.
Demando: Rezultas, ke ene de la Docker-ujo, kiun ni provas konekti al Service Discovery, devus esti ia logiko, kiu povas sendi datumojn al Konsulo?
Respondo: Ne vere. Kiam ĝi komenciĝas, ni pasas variablojn tra la mediovariablo. Ni diru servonomo, servo haveno. La registro aŭskultas ĉi tiujn informojn kaj enigas ĝin en Konsulo.
Demando: Mi havas alian demandon pri la UI. Ni deplojis la UI, ekzemple, sur produktadservilo. Kio pri sekureco? Kie estas la datumoj stokitaj? Ĉu eblas iel amasigi datumojn?
Respondo: En la UI estas datumoj de la datumbazo kaj de Service Discovery. Ni mem fiksas pasvortojn en la agordojn.
Demando: Ĉu tio povas esti publikigita en la interreto?
Respondo: Defaŭlte, Konsulo komenciĝas ĉe localhost. Por publikigi en la Interreto, vi devos instali ian prokurilon. Ni respondecas pri niaj propraj sekurecaj reguloj.
Demando: Ĉu ĝi provizas historiajn datumojn el la skatolo? Estas interese rigardi la statistikojn pri Sankontroloj. Vi ankaŭ povas diagnozi problemojn se la servilo ofte malsukcesas.
Respondo: Mi ne certas, ke tie estas detaloj de ĉekoj.
Demando: La nuna stato ne tiom gravas kiel la dinamiko.
Respondo: Por analizo - jes.
Demando: Ĉu estas pli bone ne uzi Service Discovery for Consul docker?
Respondo: Mi ne rekomendus uzi ĝin. La celo de la raporto estas enkonduki kia tia koncepto ekzistas. Historie, ĝi faris sian vojon, laŭ mi, al la 1-a versio. Nun ekzistas pli kompletaj solvoj, ekzemple Kubernetes, kiu havas ĉion ĉi sub la kapuĉo. Kiel parto de Kubernetes Service Discovery estas pli malalta ol Ktp. Sed mi ne konas ĝin tiel kiel mi estas kun Konsulo. Tial, mi decidis fari Service Discovery uzante Konsulo kiel ekzemplon.
Demando: Ĉu la skemo kun ĉefservilo ne malrapidigas la komencon de la aplikaĵo entute? Kaj kiel Konsulo determinas novan gvidanton, se ĉi tiu mensogas?
Respondo: Ili havas tutan protokolon priskribita. Se vi interesiĝas, vi povas legi ĝin.
Demando: Konsulo agas kiel plenrajta servilo por ni kaj ĉiuj petoj flugas tra ĝi?
Respondo: Ĝi ne funkcias kiel plenrajta servilo, sed transprenas specifan zonon. Ĝi kutime finiĝas per servo.konsulo. Kaj tiam ni antaŭeniras logike. Ni ne uzas domajnajn nomojn en produktado, sed prefere la internan infrastrukturon, kiu kutime estas kaŝita malantaŭ servila kaŝmemoro se ni laboras uzante DNS.
Demando: Tio estas, se ni volas aliri la datumbazon, tiam ĉiukaze ni tiros Konsulon por trovi ĉi tiun datumbazon unue, ĉu ne?
Respondo: Jes. Se ni laboras uzante DNS, tiam ĝi funkcias same kiel sen Konsulo kiam ni uzas DNS-nomojn. Kutime, modernaj aplikoj ne tiras la domajnan nomon en ĉiu peto, ĉar ni instalis konekti, ĉio funkcias kaj en proksima estonteco ni praktike ne uzas ĝin. Se konekti estas rompita, do jes, ni denove demandas kie estas nia bazo kaj iras al ĝi.
— Hashicorp uzanta babilejo: Konsulo, Nomado, Terraform
PS Pri sankontroloj. Konsulo, kiel Kubernetes, uzas la saman sistemon por kontroli la postviveblecon de servo bazita sur kodstatuso.
200 OK for healthy
503 Service Unavailable for unhealthyFontoj:
fonto: www.habr.com