Сайн уу! Намайг Павел Агалетский гэдэг. Би Ламода хүргэлтийн системийг хөгжүүлдэг багт багийн ахлагчаар ажилладаг. 2018 онд би HighLoad++ чуулганд оролцож илтгэл тавьсан бөгөөд өнөөдөр би илтгэлийнхээ хуулбарыг толилуулж байна.

Миний сэдэв нь манай компанийн систем, үйлчилгээг янз бүрийн орчинд байршуулах туршлагад зориулагдсан болно. Бид бүх системийг энгийн виртуал серверт байрлуулж байсан балар эртний үеэс эхлээд Номадаас аажмаар Кубернетес дэх байршуулалт руу шилжсэн. Бид яагаад үүнийг хийсэн, энэ явцад ямар бэрхшээл тулгарсныг би танд хэлье.

VM дээр програмуудыг байрлуулж байна

Одоогоос 3 жилийн өмнө компанийн бүх систем, үйлчилгээг ердийн виртуал серверт суулгасан гэдгээс эхэлье. Техникийн хувьд энэ нь манай системийн бүх кодыг jenkins ашиглан автомат угсрах хэрэгслийг ашиглан хадгалж, угсардаг байдлаар зохион байгуулагдсан. Ansible-ийг ашигласнаар үүнийг манай хувилбарын хяналтын системээс виртуал серверүүд рүү шилжүүлсэн. Түүгээр ч зогсохгүй манай компаний систем бүр дор хаяж 2 серверт байрлуулсан: тэдгээрийн нэг нь толгой дээр, хоёр дахь нь сүүл дээр. Эдгээр хоёр систем нь тохиргоо, хүч, тохиргоо гэх мэт бүх зүйлээрээ бие биетэйгээ яг адилхан байсан. Тэдний хоорондох цорын ганц ялгаа нь толгой нь хэрэглэгчийн урсгалыг хүлээн авдаг байсан бол сүүл нь хэзээ ч хэрэглэгчийн урсгалыг хүлээн авдаггүй байв.

Яагаад үүнийг хийсэн бэ?

Бид програмынхаа шинэ хувилбаруудыг ашиглахдаа хэрэглэгчдэд мэдэгдэхүйц үр дагаваргүйгээр, тасралтгүй нэвтрүүлэхийг хүссэн. Энэ нь Ansible-г ашиглан дараагийн эмхэтгэсэн хувилбарыг сүүл хүртэл нь гаргасантай холбоотой юм. Тэнд байршуулалтад оролцсон хүмүүс бүх зүйл хэвийн байгаа эсэхийг шалгаж, шалгаж болно: бүх хэмжигдэхүүн, хэсэг, програмууд ажиллаж байсан; шаардлагатай скриптүүдийг ажиллуулж байна. Тэд бүх зүйл зүгээр гэдэгт итгэсний дараа л замын хөдөлгөөнийг өөрчилсөн. Энэ нь өмнө нь сүүл байсан сервер рүү явж эхэлсэн. Өмнө нь толгойлж байсан нэг нь хэрэглэгчийн траффикгүй хэвээр байсан ч манай програмын өмнөх хувилбарыг суулгасан хэвээр байна.

Тиймээс энэ нь хэрэглэгчдэд саадгүй байсан. Учир нь энэ нь зүгээр л тэнцвэржүүлэгчийг сольж байгаа тул шилжүүлэлт нь агшин зуурт хийгддэг. Та тэнцвэржүүлэгчийг буцаан солих замаар өмнөх хувилбар руугаа маш амархан буцах боломжтой. Мөн бид энэ программыг хэрэглэгчийн урсгалыг хүлээн авахаас өмнө үйлдвэрлэх чадвартай эсэхийг шалгаж болох бөгөөд энэ нь нэлээд тохиромжтой байсан.

Энэ бүхнээс бид ямар давуу талыг олж харсан бэ?

1. Юуны өмнө энэ нь хангалттай зүгээр л ажилладаг. Ихэнх хүмүүс ердийн виртуал серверт суулгаж байсан тул ийм байршуулалтын схем хэрхэн ажилладагийг хүн бүр ойлгодог.
2. Энэ хангалттай найдвартай, байршуулах технологи нь энгийн тул олон мянган компаниуд туршиж үзсэн. Сая сая серверүүд ийм байдлаар байрлуулсан. Ямар нэг зүйлийг эвдэх хэцүү.
3. Тэгээд эцэст нь бид авч чадсан атомын байршуулалт. Хуучин хувилбар болон шинэ хувилбарын хооронд шилжих нь мэдэгдэхүйц үе шатгүйгээр хэрэглэгчдэд нэгэн зэрэг хийгддэг байршуулалт.

Гэхдээ бид энэ бүхнээс хэд хэдэн дутагдлыг олж харсан:

1. Үйлдвэрлэлийн орчин, хөгжлийн орчноос гадна өөр орчин бий. Жишээлбэл, qa болон урьдчилсан үйлдвэрлэл. Тэр үед олон сервертэй, 60-аад үйлчилгээтэй байсан. Энэ шалтгааны улмаас шаардлагатай байсан үйлчилгээ тус бүрийн хувьд хамгийн сүүлийн үеийн хувилбарыг хадгалах виртуал машин. Түүнчлэн, хэрэв та номын санг шинэчлэх эсвэл шинэ хамаарал суулгахыг хүсвэл бүх орчинд үүнийг хийх хэрэгтэй. Та мөн програмынхаа дараагийн шинэ хувилбарыг ашиглах гэж буй цагаа devops орчны шаардлагатай тохиргоог хийх цагтай синхрончлох шаардлагатай болсон. Энэ тохиолдолд бидний орчин бүх орчинд нэгэн зэрэг өөр байх нөхцөл байдалд ороход хялбар байдаг. Жишээлбэл, QA орчинд номын сангийн зарим хувилбарууд байх ба үйлдвэрлэлийн орчинд өөр өөр хувилбарууд байх бөгөөд энэ нь асуудалд хүргэдэг.
2. Хамааралтай байдлыг шинэчлэхэд бэрхшээлтэй таны өргөдөл. Энэ нь чамаас биш нөгөө багаас шалтгаална. Тухайлбал, серверүүдийг хариуцдаг devops багаас. Та тэдэнд тохирох даалгавар өгч, юу хийхийг хүсч байгаагаа тайлбарлах ёстой.
3. Тэр үед бид ч бас өөрт байгаа том том цулуудыг тус тусад нь жижиг үйлчилгээ болгон хуваах юмсан, учир нь улам олширно гэж ойлгодог байсан. Тухайн үед бид аль хэдийн 100 гаруйтай байсан.Шинэ үйлчилгээ бүрийн хувьд тусдаа шинэ виртуал машин үүсгэх шаардлагатай байсан бөгөөд үүнийг мөн засварлаж, байршуулах шаардлагатай байв. Үүнээс гадна танд нэг машин биш, хамгийн багадаа хоёр машин хэрэгтэй. Энэ бүхэнд QA орчин нэмэгдсэн. Энэ нь асуудал үүсгэж, танд шинэ систем бүтээх, ажиллуулахад хэцүү болгодог. нарийн төвөгтэй, үнэтэй, урт процесс.

Тиймээс бид ердийн виртуал машинуудыг байрлуулахаас эхлээд докер контейнерт програмуудаа байрлуулах нь илүү тохиромжтой гэж шийдсэн. Хэрэв танд докер байгаа бол та зүгээр л контейнер босгох боломжгүй тул програмыг кластерт ажиллуулж чадах систем хэрэгтэй. Ихэвчлэн та хэдэн чингэлэгийг автоматаар өргөхийн тулд өргөж байгааг хянахыг хүсдэг. Энэ шалтгааны улмаас бид хяналтын системийг сонгох шаардлагатай болсон.

Бид алийг нь авч болох талаар удаан бодсон. Баримт нь тухайн үед энгийн виртуал серверүүд дээрх суулгалтын стек нь үйлдлийн системийн хамгийн сүүлийн хувилбаргүй байсан тул зарим талаараа хоцрогдсон байсан. Хэзээ нэгэн цагт дэмжихэд тийм ч тохиромжтой биш байсан FreeBSD хүртэл байсан. Бид докер руу аль болох хурдан шилжих хэрэгтэйг ойлгосон. Манай devops өөр өөр шийдэл бүхий өөрсдийн туршлагаа судалж, Номад шиг системийг сонгосон.

Nomad руу шилжих

Nomad бол HashiCorp-ийн бүтээгдэхүүн юм. Тэд мөн бусад шийдлээрээ алдартай:

"Консул" үйлчилгээг илрүүлэх хэрэгсэл юм.

"Терраформ" - код гэж нэрлэгддэг дэд бүтцийг тохиргоогоор дамжуулан тохируулах боломжийг олгодог серверүүдийг удирдах систем.

"Тэнэмэл" Тусгай тохиргооны файлуудаар дамжуулан виртуал машинуудыг дотооддоо эсвэл үүлэн дотор байрлуулах боломжийг танд олгоно.

Номад тэр үед дэд бүтцээ бүхэлд нь өөрчлөхгүйгээр хурдан сольж болох нэлээн энгийн шийдэл мэт санагдсан. Үүнээс гадна сурахад маш хялбар байдаг. Тийм учраас бид савныхаа шүүлтүүрийн системээр үүнийг сонгосон.

Номад системээ байрлуулахад юу хэрэгтэй вэ?

1. Юуны өмнө танд хэрэгтэй докерын зураг таны өргөдөл. Та үүнийг бүтээж, докерын зургийн санд байрлуулах хэрэгтэй. Манай тохиолдолд энэ бол олдвор юм - янз бүрийн төрлийн янз бүрийн олдворуудыг оруулах боломжийг олгодог систем юм. Энэ нь архив, докерын зураг, хөгжмийн зохиолчийн PHP багц, NPM багц гэх мэт зүйлсийг хадгалах боломжтой.
2. Мөн хэрэгтэй тохиргооны файл, энэ нь Номад юуг, хаана, ямар хэмжээгээр байрлуулахыг хүсч байгаагаа хэлэх болно.

Nomad-ийн тухай ярихад энэ нь HCL хэлийг мэдээллийн файлын формат болгон ашигладаг HashiCorp тохиргооны хэл. Энэ бол үйлчилгээгээ Nomad-ийн хэллэгээр тайлбарлах боломжийг олгодог Yaml-ийн дээд багц юм.

Энэ нь та хичнээн контейнер байрлуулахыг хүсч байгаагаа хэлэх боломжийг олгодог, байршуулах явцад аль дүрсээс янз бүрийн параметрүүдийг дамжуулах боломжтой. Тиймээс та энэ файлыг Nomad-д өгч, түүний дагуу савыг үйлдвэрлэлд нэвтрүүлдэг.

Манай тохиолдолд үйлчилгээ бүрийн хувьд яг ижил HCL файлуудыг бичих нь тийм ч тохиромжтой биш гэдгийг бид ойлгосон, учир нь маш олон үйлчилгээ байдаг бөгөөд заримдаа та тэдгээрийг шинэчлэхийг хүсдэг. Нэг үйлчилгээг нэг тохиолдолд биш, харин өөр өөр үйлчилгээнд ашигладаг. Жишээлбэл, бидний үйлдвэрлэлд байгаа нэг систем нь үйлдвэрлэлд 100 гаруй төхөөрөмжтэй байдаг. Эдгээр нь ижил зургуудаас ажилладаг боловч тохиргооны тохиргоо болон тохиргооны файлуудаараа ялгаатай.

Тиймээс бид бүх тохиргооны файлуудаа нэг нийтлэг агуулахад хадгалах нь тохиромжтой гэж шийдсэн. Ингэснээр тэд харагдахуйц байсан: тэдгээрийг арчлахад хялбар байсан бөгөөд бид ямар системтэй болохыг харж болно. Шаардлагатай бол ямар нэг зүйлийг шинэчлэх эсвэл өөрчлөхөд хялбар байдаг. Шинэ систем нэмэх нь тийм ч хэцүү биш - та зөвхөн шинэ директор дотор тохиргооны файл үүсгэх хэрэгтэй. Дотор нь дараах файлууд байдаг: манай үйлчилгээний тайлбарыг агуулсан service.hcl болон үйлдвэрлэлд ашиглаж буй энэ үйлчилгээг тохируулах боломжийг олгодог зарим env файлууд.

Гэсэн хэдий ч манай зарим системийг нэг хувь биш, хэд хэдэн хэлбэрээр үйлдвэрлэдэг. Тиймээс бид тохиргоог цэвэр хэлбэрээр нь биш, харин загвар хэлбэрээр нь хадгалах нь бидэнд тохиромжтой гэж шийдсэн. Тэгээд бид сонгосон Жинжа 2. Энэ форматаар бид үйлчилгээний тохиргоо болон түүнд шаардлагатай env файлуудыг хоёуланг нь хадгалдаг.

Нэмж дурдахад бид бүх төслүүдэд нийтлэг байдаг байршуулах скриптийг агуулахад байршуулсан бөгөөд энэ нь танд үйлчилгээгээ үйлдвэрлэлд, хүссэн орчинд, хүссэн зорилтот түвшинд нэвтрүүлэх, ашиглах боломжийг олгодог. Бид HCL тохиргоогоо загвар болгон хувиргасан тохиолдолд урьд нь ердийн Nomad тохиргоо байсан HCL файл энэ тохиолдолд арай өөр харагдаж эхэлсэн.

Өөрөөр хэлбэл, бид зарим тохиргооны байршлын хувьсагчдыг env файл эсвэл бусад эх сурвалжаас авсан хувьсагчдаас оруулсан хувьсагчаар сольсон. Нэмж дурдахад бид HCL файлуудыг динамикаар цуглуулах боломжтой болсон, өөрөөр хэлбэл бид зөвхөн энгийн хувьсагчийн оруулгыг ашиглах боломжтой болсон. Жинжа нь гогцоо болон нөхцөлийг дэмждэг тул та тэнд тохиргооны файл үүсгэж болох бөгөөд энэ нь таны программыг яг хаана байрлуулахаас хамаарч өөрчлөгддөг.

Жишээлбэл, та үйлчилгээгээ үйлдвэрлэлийн өмнөх болон үйлдвэрлэлд нэвтрүүлэхийг хүсч байна. Урьдчилан үйлдвэрлэлд та cron скрипт ажиллуулахыг хүсэхгүй байна, гэхдээ зүгээр л энэ үйлчилгээг ажиллаж байгаа эсэхийг шалгахын тулд тусдаа домэйн дээр үзэхийг хүсч байна гэж бодъё. Үйлчилгээг ашиглаж буй хэн бүхэнд энэ үйл явц маш энгийн бөгөөд ил тод харагдаж байна. Та хийх ёстой зүйл бол deploy.sh файлыг ажиллуулж, аль үйлчилгээ, аль зорилтыг ашиглахыг хүсч байгаагаа зааж өгөх явдал юм. Жишээлбэл, та тодорхой системийг Орос, Беларусь эсвэл Казахстанд байрлуулахыг хүсч байна. Үүнийг хийхийн тулд параметрүүдийн аль нэгийг нь өөрчлөхөд л та зөв тохиргооны файлтай болно.

Nomad үйлчилгээ аль хэдийн таны кластерт нэвтэрсэн үед иймэрхүү харагдах болно.

Нэгдүгээрт, танд гаднаас ямар нэгэн тэнцвэржүүлэгч хэрэгтэй бөгөөд энэ нь хэрэглэгчийн бүх урсгалыг хүлээн авах болно. Энэ нь Консултай хамтран ажиллаж, тодорхой домэйн нэртэй тохирох үйлчилгээ хаана, ямар зангилаа, ямар IP хаяг дээр байгааг олж мэдэх болно. Консул дахь үйлчилгээ нь Номадаас ирдэг. Эдгээр нь нэг компанийн бүтээгдэхүүн учраас хоорондоо нэлээд холбоотой байдаг. Nomad нь Консулын дотор эхлүүлсэн бүх үйлчилгээгээ хайрцагнаас нь бүртгэж чадна гэж бид хэлж чадна.

Таны ачааллын тэнцвэржүүлэгч аль үйлчилгээ рүү траффик илгээхийг мэдсэний дараа үүнийг тохирох контейнер эсвэл таны програмд ​​тохирох олон контейнер руу дамжуулдаг. Мэдээжийн хэрэг, аюулгүй байдлын талаар бодох хэрэгтэй. Хэдийгээр бүх үйлчилгээ нь ижил виртуал машин дээр контейнерт ажилладаг ч энэ нь ихэвчлэн аливаа үйлчилгээнээс бусад үйлчилгээ рүү үнэгүй нэвтрэхээс урьдчилан сэргийлэхийг шаарддаг. Бид үүнийг сегментчилснээр хүрсэн. Үйлчилгээ бүр өөрийн гэсэн виртуал сүлжээнд нээгдсэн бөгөөд үүнд чиглүүлэлтийн дүрэм, бусад систем, үйлчилгээнд нэвтрэхийг зөвшөөрөх/тагнуулах дүрмийг тусгасан болно. Тэдгээрийг энэ кластер дотор болон гадна талд байрлуулж болно. Жишээлбэл, хэрэв та үйлчилгээг тодорхой мэдээллийн санд холбохоос сэргийлэхийг хүсвэл үүнийг сүлжээний түвшний сегментчлэлээр хийж болно. Өөрөөр хэлбэл, алдаатай байсан ч та туршилтын орчноос үйлдвэрлэлийн мэдээллийн сан руугаа санамсаргүйгээр холбогдож чадахгүй.

Хүний нөөцийн хувьд шилжилтийн явцад ямар их зардал гарсан бэ?

Компанийг бүхэлд нь Номад руу шилжүүлэхэд ойролцоогоор 5-6 сар зарцуулсан. Бид үйлчилгээ тус бүрээр нүүсэн боловч нэлээд хурдацтай байсан. Баг бүр үйлчилгээнд зориулж өөрийн савыг бий болгох ёстой байв.

Бид баг бүр өөрийн системийн докерын зургийг бие даан хариуцдаг ийм арга барилыг хэрэгжүүлсэн. DevOps нь байршуулахад шаардлагатай ерөнхий дэд бүтцийг, өөрөөр хэлбэл кластерийг өөрөө дэмжих, CI системийг дэмжих гэх мэтээр хангадаг. Тэр үед бид 60 гаруй системийг Номад руу шилжүүлсэн бөгөөд энэ нь 2 мянга орчим контейнер байсан.

Devops нь байршуулалт, сервертэй холбоотой бүх зүйлийн ерөнхий дэд бүтцийг хариуцдаг. Мөн хөгжүүлэлтийн баг бүр нь эргээд өөрийн системд зориулж савыг хэрэгжүүлэх үүрэгтэй, учир нь энэ нь тухайн саванд юу хэрэгтэйг мэддэг баг юм.

Номадыг орхих болсон шалтгаанууд

Nomad болон docker ашиглан байршуулалтад шилжсэнээр бид ямар давуу талыг олж авсан бэ?

1. Бид тэгш нөхцөлөөр хангасан бүх орчинд зориулагдсан. Хөгжүүлэлт, QA орчин, урьдчилсан үйлдвэрлэл, үйлдвэрлэлд ижил төрлийн контейнерийн зургуудыг ижил хамааралтайгаар ашигладаг. Үүний дагуу, та өмнө нь орон нутагт эсвэл туршилтын орчинд туршиж үзсэн зүйл биш үйлдвэрлэлд гарах боломж бараг байхгүй.
2. Бид бас хангалттай гэдгийг олж мэдсэн шинэ үйлчилгээ нэмэхэд хялбар. Байршуулах үүднээс авч үзвэл аливаа шинэ системийг маш энгийнээр ажиллуулдаг. Тохиргоог хадгалдаг репозитор руу ороод, тэнд өөрийн системийн өөр тохиргоо нэмээд л бэлэн боллоо. Та devops-аас нэмэлт хүчин чармайлтгүйгээр системээ үйлдвэрлэлд нэвтрүүлэх боломжтой.
3. мэдээлэл тохиргооны файлууд нэг нийтлэг репозитор хянагдаж байгаа нь тогтоогдсон. Бид виртуал сервер ашиглан системээ байршуулах үед тохиргоонууд нь нэг репозитортой байсан Ansible-г ашиглаж байсан. Гэсэн хэдий ч ихэнх хөгжүүлэгчдийн хувьд энэ нь ажиллахад арай илүү хэцүү байсан. Энд үйлчилгээг нэвтрүүлэхийн тулд нэмэх шаардлагатай тохиргоо болон кодын хэмжээ хамаагүй бага болсон. Дээрээс нь хөгжүүлэгчид үүнийг засах эсвэл өөрчлөхөд маш хялбар байдаг. Жишээлбэл, Nomad-ийн шинэ хувилбар руу шилжих тохиолдолд тэд нэг газар байрлах бүх үйлдлийн файлуудыг авч, бөөнөөр нь шинэчлэх боломжтой.

Гэхдээ бид хэд хэдэн сул талуудтай тулгарсан:

Бид болох нь тогтоогдсон саадгүй байршуулалтад хүрч чадсангүй Номадын хувьд. Янз бүрийн нөхцөлд чингэлэг гаргах үед энэ нь ажиллаж байж болох бөгөөд Номад үүнийг хөдөлгөөнийг хүлээн авахад бэлэн чингэлэг гэж ойлгосон. Энэ нь түүний доторх програмыг эхлүүлэх боломж гарахаас өмнө болсон. Энэ шалтгааны улмаас систем нь богино хугацаанд 500 алдаа гаргаж эхэлсэн, учир нь түүнийг хүлээж авахад хараахан бэлэн болоогүй чингэлэг рүү хөдөлгөөн орж эхэлсэн.

Бид заримтай нь тааралдсан намаг гэхэд. Хамгийн гол алдаа нь хэрэв танд олон систем, контейнер байгаа бол Nomad том кластерыг тийм ч сайн зохицуулдаггүй. Та Nomad кластерт багтсан серверүүдийн аль нэгийг нь засвар үйлчилгээнд гаргахыг хүсвэл кластер тийм ч сайн биш, задрах магадлал нэлээд өндөр байна. Жишээлбэл, зарим савнууд унаж, өсөхгүй байж болно - хэрэв таны үйлдвэрлэлийн бүх систем Nomad-ийн удирддаг кластерт байрладаг бол энэ нь танд маш их зардал гарах болно.

Тиймээс бид цаашид хаашаа явах вэ гэдгээ бодохоор шийдсэн. Тэр үед бид юунд хүрэхийг хүсч байгаагаа илүү их ухамсарласан. Тухайлбал: бид найдвартай байдал, Nomad-ийн өгсөнөөс арай илүү функц, илүү боловсронгуй, тогтвортой системийг хүсч байна.

Үүнтэй холбогдуулан бидний сонголт Кубернетес дээр бууж, кластеруудыг эхлүүлэх хамгийн алдартай платформ болжээ. Ялангуяа манай савны хэмжээ, тоо хангалттай том байсан. Ийм зорилгоор Кубернетес нь бидний харж болох хамгийн тохиромжтой систем юм шиг санагдлаа.

Кубернетес рүү шилжих

Би Кубернетесийн үндсэн ойлголтууд болон тэдгээр нь Номадаас юугаараа ялгаатай болохыг бага зэрэг хэлье.

Юуны өмнө Кубернетес дэх хамгийн үндсэн ойлголт бол pod гэсэн ойлголт юм. Pod үргэлж хамт ажилладаг нэг буюу хэд хэдэн савны бүлэг юм. Тэд үргэлж нэг виртуал машин дээр ажилладаг шиг ажилладаг. Тэд өөр өөр портууд дээр IP 127.0.0.1-ээр дамжуулан бие биедээ хандах боломжтой.

Танд nginx болон php-fpm - сонгодог схемээс бүрдсэн PHP програм байгаа гэж бодъё. Та nginx болон php-fpm контейнеруудыг үргэлж хамт байлгахыг хүсэх байх. Кубернетес нь тэдгээрийг нэг нийтлэг pod гэж тайлбарласнаар үүнд хүрэх боломжийг олгодог. Энэ бол бид Номадтай хамт авч чадаагүй зүйл юм.

Хоёр дахь ойлголт нь байршуулалт. Бодит байдал нь хонхорцог өөрөө түр зуурын зүйл бөгөөд энэ нь эхэлж, алга болдог. Та эхлээд өмнөх бүх контейнеруудаа устгаад дараа нь шинэ хувилбаруудаа нэг дор гаргах уу, эсвэл тэдгээрийг аажмаар гаргах уу? Энэ бол байршуулах үзэл баримтлалыг хариуцдаг үйл явц юм. Энэ нь таны подволкуудыг хэрхэн байрлуулах, ямар хэмжээгээр, хэрхэн шинэчлэх талаар тайлбарладаг.

Гурав дахь ойлголт нь үйлчилгээ. Таны үйлчилгээ нь үнэндээ таны систем бөгөөд энэ нь тодорхой хэмжээний траффик хүлээн авч, дараа нь таны үйлчилгээнд тохирох нэг буюу хэд хэдэн pods руу дамжуулдаг. Өөрөөр хэлбэл, ийм, ийм нэртэй ийм үйлчилгээнд ирж буй бүх урсгалыг эдгээр тодорхой pods руу илгээх ёстой гэж хэлэх боломжийг танд олгоно. Үүний зэрэгцээ энэ нь танд замын хөдөлгөөний тэнцвэржүүлэх боломжийг олгодог. Өөрөөр хэлбэл, та өөрийн аппликешны хоёр pod-ийг ажиллуулж болох бөгөөд ирж буй бүх урсгал энэ үйлчилгээтэй холбоотой подкуудын хооронд жигд тэнцвэртэй байх болно.

Мөн дөрөв дэх үндсэн ойлголт нь Ingress. Энэ бол Kubernetes кластер дээр ажилладаг үйлчилгээ юм. Энэ нь бүх хүсэлтийг хүлээн авдаг гадаад ачааллын тэнцвэржүүлэгчийн үүрэг гүйцэтгэдэг. Kubernetes API ашиглан Ingress эдгээр хүсэлтийг хаашаа илгээхийг тодорхойлох боломжтой. Түүнээс гадна тэр үүнийг маш уян хатан байдлаар хийдэг. Та энэ хост болон ийм URL руу илгээсэн бүх хүсэлтийг энэ үйлчилгээ рүү илгээсэн гэж хэлж болно. Энэ хост болон өөр URL руу ирж буй эдгээр хүсэлтийг өөр үйлчилгээ рүү илгээдэг.

Аппликэйшн боловсруулдаг хүний ​​хувьд хамгийн гайхалтай зүйл бол та өөрөө бүгдийг нь удирдах чадвартай байдаг. Ingress тохиргоог хийснээр та ийм API руу ирж буй бүх урсгалыг, жишээлбэл, Go дээр бичигдсэн тусдаа контейнер руу илгээх боломжтой. Гэхдээ ижил домэйнд ирж байгаа энэ урсгалыг өөр URL руу PHP дээр бичсэн контейнерууд руу илгээх ёстой бөгөөд тэнд логик нь маш их байдаг, гэхдээ тэдгээр нь тийм ч хурдан биш юм.

Хэрэв бид энэ бүх ойлголтыг Номадтай харьцуулж үзвэл эхний гурван ойлголт бүгд нийлээд Үйлчилгээ гэж хэлж болно. Мөн сүүлийн ойлголт Номад өөрөө байхгүй. Бид гадаад тэнцвэржүүлэгчийг ашигласан: энэ нь haproxy, nginx, nginx+ гэх мэт байж болно. Кубын хувьд энэ нэмэлт ойлголтыг тусад нь оруулах шаардлагагүй. Гэсэн хэдий ч, хэрэв та Ingress-ийг дотооддоо харвал энэ нь nginx, haproxy эсвэл traefik боловч Kubernetes-д суурилагдсан байдаг.

Миний тайлбарласан бүх ойлголтууд нь үнэндээ Кубернетес кластерт байдаг нөөц юм. Тэдгээрийг шоо хэлбэрээр дүрслэхийн тулд yaml форматыг ашигладаг бөгөөд энэ нь Nomad-ийн хувьд HCL файлуудаас илүү уншигдах бөгөөд танил юм. Гэхдээ бүтцийн хувьд тэд жишээлбэл, хонхорцогтой ижил зүйлийг дүрсэлдэг. Тэд хэлэхдээ - Би тэнд ийм, ийм ийм зурагтай, тийм, тийм хэмжээгээр ийм ийм хонхорцог байрлуулмаар байна.

Нэмж дурдахад бид бие даасан нөөц бүрийг өөрийн гараар бий болгохыг хүсэхгүй байгаагаа ойлгосон: байршуулалт, үйлчилгээ, нэвтрэлт гэх мэт. Үүний оронд бид бүх шаардлагатай нөөцийн хамаарлыг зөв дарааллаар гараар дахин үүсгэх шаардлагагүй болохын тулд байршуулах явцад систем тус бүрийг Kubernetes-ээр тайлбарлахыг хүссэн. Үүнийг хийх боломжийг бидэнд олгосон системээр Helm сонгосон.

Helm дахь үндсэн ойлголтууд

Удирдагч нь багц менежер Кубернетесийн хувьд. Энэ нь програмчлалын хэл дээрх багц менежерүүд хэрхэн ажилладагтай маш төстэй юм. Эдгээр нь жишээлбэл, deployment nginx, deployment php-fpm, config for Ingress, configmaps (энэ нь таны системд env болон бусад параметрүүдийг тохируулах боломжийг олгодог байгууллага) үйлчилгээг дараах хэлбэрээр хадгалах боломжийг танд олгоно. график гэж нэрлэдэг. Үүний зэрэгцээ Helm Кубернетесийн орой дээр гүйдэг. Өөрөөр хэлбэл, энэ нь хажуу тийшээ зогсох ямар нэгэн систем биш, харин куб дотор эхлүүлсэн өөр нэг үйлчилгээ юм. Та консолын командаар дамжуулан API-ээр нь харьцдаг. Тохиромжтой, гоо үзэсгэлэн нь жолооны хүрд эвдэрсэн ч, эсвэл та үүнийг кластераас салгасан ч таны үйлчилгээ алга болохгүй, учир нь жолоо нь зөвхөн системийг эхлүүлэхэд л үйлчилдэг. Дараа нь Кубернетес өөрөө үйлчилгээний гүйцэтгэл, төлөв байдлыг хариуцдаг.

Бид ч үүнийг ойлгосон загварчлал, бид өмнө нь jinja-г тохиргоондоо оруулах замаар өөрсдөө хийхээс өөр аргагүй байсан нь жолооны гол шинж чанаруудын нэг юм. Таны системд зориулж бүтээсэн бүх тохиргоонууд нь jinja-тай бага зэрэг төстэй загвар хэлбэрээр хадгалагддаг, гэхдээ үнэндээ Kubernetes шиг helm бичигдсэн Go хэлний загварчлалыг ашигладаг.

Helm бидэнд хэд хэдэн ухагдахууныг нэмж оруулав.

Chart - энэ бол таны үйлчилгээний тодорхойлолт юм. Бусад багц менежерүүдэд үүнийг багц, багц эсвэл ижил төстэй зүйл гэж нэрлэдэг. Энд үүнийг график гэж нэрлэдэг.

утгууд загваруудаас тохиргоогоо бүтээхэд ашиглахыг хүсэж буй хувьсагчууд юм.

Хувилбарын. Дэлгэц ашиглан байршуулсан үйлчилгээ нь хувилбарын нэмэгдүүлсэн хувилбарыг хүлээн авдаг. Helm өмнөх хувилбарт үйлчилгээний тохиргоо ямар байсныг, өмнөх хувилбар гэх мэтийг санаж байна. Тиймээс, хэрэв та буцаах шаардлагатай бол өмнөх хувилбар руу чиглүүлж, эргүүлэн дуудах командыг ажиллуулна уу. Таны репозитор дахь тохирох тохиргоог буцаах үед боломжгүй байсан ч helm энэ нь юу байсныг санаж, таны системийг өмнөх хувилбарт байсан төлөв рүү буцаах болно.

Бид helm ашиглах тохиолдолд Kubernetes-ийн ердийн тохиргоонууд нь хувьсагч, функцийг ашиглах, нөхцөлт мэдэгдлийг ашиглах боломжтой загвар болж хувирдаг. Ингэснээр та орчноос хамаарч үйлчилгээний тохиргоогоо цуглуулах боломжтой.

Практик дээр бид Номадтай хийсэн ажлаас арай өөрөөр хийхээр шийдсэн. Хэрэв Nomad-д манай үйлчилгээг ашиглахад шаардлагатай байршуулалтын тохиргоо болон n-хувьсагч хоёулаа нэг репозиторид хадгалагдсан бол энд бид тэдгээрийг хоёр тусдаа хадгалах газарт хуваахаар шийдсэн. “Deploy” репозитор нь зөвхөн байршуулахад шаардлагатай n-хувьсагчдыг, “helm” репозитор нь тохиргоо эсвэл диаграммуудыг хадгалдаг.

Энэ нь бидэнд юу өгсөн бэ?

Хэдийгээр бид тохиргооны файлд үнэхээр эмзэг өгөгдөл хадгалдаггүй. Жишээлбэл, мэдээллийн сангийн нууц үг. Тэдгээрийг Кубернетес-д нууц хэлбэрээр хадгалдаг боловч хүн бүрт хандахыг хүсэхгүй байгаа зарим зүйл байсаар байна. Тиймээс "байршуулах" репозитор руу хандах хандалт илүү хязгаарлагдмал бөгөөд "дуулга" хадгалах газар нь үйлчилгээний тодорхойлолтыг агуулдаг. Ийм учраас илүү өргөн хүрээний хүмүүс үүнийг аюулгүйгээр ашиглах боломжтой.

Бид зөвхөн үйлдвэрлэл төдийгүй бусад орчинтой тул энэхүү тусгаарлалтын ачаар бид зөвхөн үйлдвэрлэлд төдийгүй, жишээлбэл, QA орчинд үйлчилгээг нэвтрүүлэхийн тулд жолооны графикаа дахин ашиглах боломжтой. Тэр ч байтугай тэдгээрийг ашиглан орон нутагт байршуулах Миникубе - энэ бол Kubernetes-ийг орон нутагт ажиллуулахад зориулагдсан зүйл юм.

Хадгалах газар болгонд бид үйлчилгээ тус бүрийн тусдаа лавлах хэсгүүдийг үлдээсэн. Өөрөөр хэлбэл, лавлах бүр дотор харгалзах графиктай холбоотой загварууд байдаг бөгөөд манай системийг ажиллуулахын тулд ашиглах шаардлагатай нөөцүүдийг тайлбарласан байдаг. Бид "байршуулах" хадгалах санд зөвхөн envs үлдээсэн. Энэ тохиолдолд бид jinja ашиглан загварчлалыг ашиглаагүй, учир нь helm өөрөө загварчлалыг хайрцагнаас гаргаж өгдөг - энэ бол түүний үндсэн функцүүдийн нэг юм.

Бид байршуулах скриптийг үлдээсэн - deploy.sh нь жолооны тусламжтайгаар байрлуулах ажлыг хялбарчилж, стандартчилдаг. Тиймээс байршуулахыг хүссэн хүн бүрийн хувьд байршуулах интерфейс нь Nomad-ээр дамжуулан байршуулахтай яг адилхан харагдаж байна. Үүнтэй ижил deploy.sh, таны үйлчилгээний нэр, хаана байрлуулахыг хүсэж байна. Энэ нь жолоодлогыг дотооддоо эхлүүлэхэд хүргэдэг. Энэ нь эргээд загваруудаас тохиргоог цуглуулж, шаардлагатай утгын файлуудыг оруулж, дараа нь Кубернетес рүү ажиллуулдаг.

үр дүн нь

Kubernetes үйлчилгээ нь Номадаас илүү төвөгтэй юм шиг санагддаг.

Эндээс гарах урсгал Ingress руу ирдэг. Энэ бол зүгээр л урд хянагч бөгөөд бүх хүсэлтийг хүлээн авч, дараа нь хүсэлтийн өгөгдөлд тохирох үйлчилгээ рүү илгээдэг. Энэ нь таны программын тайлбарт багтсан тохиргоон дээр тулгуурлан тодорхойлж, хөгжүүлэгчид өөрсдөө тохируулдаг. Энэ үйлчилгээ нь өөрийн хонхорцог руу, өөрөөр хэлбэл тодорхой чингэлэг рүү хүсэлт илгээж, энэ үйлчилгээнд хамаарах бүх чингэлэг хоорондын ирж буй урсгалыг тэнцвэржүүлдэг. Мэдээжийн хэрэг, бид сүлжээний түвшинд аюулгүй байдлын талаар хаашаа ч явах ёсгүй гэдгийг мартаж болохгүй. Тиймээс сегментчилэл нь шошго дээр суурилсан Kubernetes кластерт ажилладаг. Бүх үйлчилгээнүүд нь кластер доторх эсвэл гаднах тодорхой гадаад/дотоод нөөцөд хандах эрхтэй холбоотой тодорхой шошготой байдаг.

Шилжилтийг хийх явцад бид Кубернетес дээр бидний өмнө нь ашиглаж байсан Nomad-ийн бүх боломжууд байгааг олж харлаа, мөн түүнчлэн маш олон шинэ зүйлийг нэмсэн. Үүнийг залгаасуудаар, мөн үнэндээ захиалгат нөөцийн төрлөөр дамжуулан өргөжүүлж болно. Өөрөөр хэлбэл, танд зөвхөн Кубернетестэй цуг ирдэг зүйлийг ашиглах биш, харин таны нөөцийг унших өөрийн нөөц, үйлчилгээг бий болгох боломжтой. Энэ нь танд Kubernetes-ийг дахин суулгахгүйгээр, өөрчлөлт хийх шаардлагагүйгээр системийг өргөжүүлэх нэмэлт сонголтуудыг олгоно.

Ийм хэрэглээний жишээ бол манай Кубернетес кластер дотор ажилладаг Prometheus юм. Энэ нь тодорхой үйлчилгээнээс хэмжигдэхүүнийг цуглуулж эхлэхийн тулд үйлчилгээний тайлбарт үйлчилгээний монитор гэж нэрлэгддэг нэмэлт төрлийн нөөцийг нэмэх шаардлагатай. Prometheus нь Kubernetes-д ашиглалтад орсноор тусгай нөөцийн төрлийг уншиж чаддаг тул шинэ системээс хэмжүүрүүдийг автоматаар цуглуулж эхэлдэг. Энэ нь нэлээд тохиромжтой.

Бидний Kubernetes-д анхны байршуулалт 2018 оны 3000-р сард болсон. Мөн энэ хугацаанд бид үүнтэй холбоотой ямар ч асуудал тулгараагүй. Энэ нь мэдэгдэхүйц алдаагүйгээр нэлээд тогтвортой ажилладаг. Үүнээс гадна бид үүнийг улам өргөжүүлэх боломжтой. Өнөөдөр бидэнд хангалттай боломжууд байгаа бөгөөд бид Кубернетесийн хөгжлийн хурдад үнэхээр дуртай. Одоогоор Кубернетес хотод XNUMX гаруй чингэлэг байна. Кластер нь хэд хэдэн зангилаа эзэлдэг. Үүний зэрэгцээ энэ нь үйлчлэх боломжтой, тогтвортой, маш их хяналттай байдаг.

Эх сурвалж: www.habr.com