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

Бид B2B болон B2C-д зориулсан онлайн худалдаа, финтек бүтээгдэхүүний үйлчилгээ хөгжүүлдэг Финтек компанийн Exness компани юм. Манай R&D нь олон төрлийн багтай, хөгжлийн хэлтэс нь 100+ ажилтантай.

Бид хөгжүүлэгчиддээ код цуглуулж, ажиллуулах платформыг хариуцдаг багийг төлөөлдөг. Ялангуяа бид програмуудаас хэмжигдэхүүн, бүртгэл, үйл явдлыг цуглуулах, хадгалах, тайлагнах үүрэгтэй. Бид одоогоор гурван мянга орчим Docker контейнерийг үйлдвэрлэлийн орчинд ажиллуулж, 50 TB-ийн том өгөгдлийн сангаа хадгалж, Кубернетес, Ранчер болон олон нийтийн үүлэн үйлчилгээ үзүүлэгч гэх мэт дэд бүтцийнхээ эргэн тойронд баригдсан архитектурын шийдлүүдийг санал болгож байна. 

Бидний урам зориг

Юу шатаж байна вэ? Хэн ч хариулж чадахгүй. Гал голомт хаана байдаг вэ? Ойлгоход хэцүү байна. Хэзээ гал гарсан бэ? Та мэдэж болно, гэхдээ тэр даруй биш. 

Яагаад зарим нь унасан байхад зарим нь зогсож байна вэ? Аль сав буруутай байсан бэ? Эцсийн эцэст, савны гадна тал нь адилхан боловч дотор нь тус бүр өөрийн гэсэн Neo-тэй байдаг.

Манай хөгжүүлэгчид бол чадварлаг залуус. Тэд компанид ашиг авчрах сайн үйлчилгээ үзүүлдэг. Гэвч хэрэглүүртэй савнууд төөрөлдсөн тохиолдолд алдаа гардаг. Нэг контейнер хэт их CPU зарцуулдаг, нөгөө нь сүлжээг хэрэглэдэг, гурав дахь нь оролт гаралтын үйлдлүүдийг ашигладаг, дөрөв дэх нь сокетуудтай юу хийх нь тодорхойгүй байдаг. Энэ бүхэн унаж, хөлөг онгоц живнэ. 

Агентууд

Дотор нь юу болж байгааг ойлгохын тулд бид агентуудыг шууд саванд хийхээр шийдсэн.

Эдгээр агентууд нь савыг бие биенээ эвдэхгүй байхаар хадгалах хөтөлбөрүүд юм. Агентууд стандартчилагдсан бөгөөд энэ нь савны үйлчилгээнд стандартчилагдсан хандлагыг бий болгодог. 

Манай тохиолдолд агентууд шошготой, тохируулсан стандарт форматаар логуудыг өгөх ёстой. Тэд мөн бизнесийн хэрэглээний үүднээс өргөтгөх боломжтой стандартчилсан хэмжүүрүүдийг бидэнд өгөх ёстой.

Агент гэдэг нь өөр өөр дүрсийг (Debian, Alpine, Centos гэх мэт) дэмждэг өөр өөр зохион байгуулалтын системд ажиллах боломжтой, ашиглалт, засвар үйлчилгээ гэсэн утгыг илэрхийлдэг.

Эцэст нь агентууд Docker файлуудыг агуулсан энгийн CI/CD-г дэмжих ёстой. Үгүй бол хөлөг онгоц нурах болно, учир нь чингэлэгүүдийг "тахир" төмөр замаар хүргэж эхэлнэ.

Процесс болон зорилтот дүрс төхөөрөмжийг бүтээх

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

Энд савнууд нь хатуу тоймоор дүрслэгдсэн байдаг. Үүний зэрэгцээ тэд "амьдрал бөөрөлзгөнө шиг санагдахгүй" байхын тулд түгээлтийн иж бүрдэл хийхээр шийджээ. Яагаад үүнийг хийсэн бэ, бид доор тайлбарлах болно.
 
Үр дүн нь бүтээх хэрэгсэл буюу тодорхой түгээлтийн хувилбарууд болон скриптийн тодорхой хувилбаруудыг иш татдаг хувилбарт зориулсан контейнер юм.

Бид үүнийг хэрхэн ашиглах вэ? Бидэнд чингэлэг агуулсан Docker Hub бий. Бид гадны хамаарлаас ангижрахын тулд үүнийг системдээ тусгадаг. Үр дүн нь шараар тэмдэглэгдсэн сав юм. Бид саванд хэрэгтэй бүх түгээлт, скриптүүдийг суулгах загвар үүсгэдэг. Үүний дараа бид ашиглахад бэлэн зургийг угсардаг: хөгжүүлэгчид түүнд код болон өөрсдийн зарим тусгай хамаарлыг оруулдаг. 

Энэ аргын сайн тал нь юу вэ? 

• Нэгдүгээрт, бүтээх хэрэгслийн бүрэн хувилбарыг хянах - контейнер, скрипт, түгээлтийн хувилбаруудыг бүтээх. 
• Хоёрдугаарт, бид стандартчилалд хүрсэн: бид загвар, завсрын болон ашиглахад бэлэн зургийг ижил аргаар бүтээдэг. 
• Гуравдугаарт, чингэлэг нь бидэнд зөөвөрлөх боломжийг олгодог. Өнөөдөр бид Gitlab-ийг ашигладаг бөгөөд маргааш бид TeamCity эсвэл Jenkins руу шилжиж, контейнеруудаа ижил аргаар ажиллуулах боломжтой болно. 
• Дөрөвдүгээрт, хараат байдлыг багасгах. Бид түгээлтийн иж бүрдлийг саванд хийсэн нь тохиолдлын хэрэг биш байсан, учир нь энэ нь биднийг интернетээс байнга татаж авахаас зайлсхийх боломжийг олгодог. 
• Тавдугаарт, бүтээх хурд нэмэгдсэн - зургийн орон нутгийн хуулбар байгаа нь орон нутгийн зураг байгаа тул татаж авахад цаг алдахаас зайлсхийх боломжийг олгодог. 

Өөрөөр хэлбэл, бид хяналттай, уян хатан угсралтын процесст хүрсэн. Бүрэн хувилбартай сав барихдаа бид ижил хэрэгслийг ашигладаг. 

Бидний бүтээх журам хэрхэн ажилладаг

Угсралтыг нэг тушаалаар эхлүүлж, процессыг зурган дээр гүйцэтгэдэг (улаан өнгөөр ​​тодруулсан). Хөгжүүлэгч нь Docker файлтай (шараар тодруулсан), бид үүнийг хувьсагчдыг утгуудаар сольж өгдөг. Замдаа бид толгой ба хөлийг нэмдэг - эдгээр нь бидний төлөөлөгч юм. 

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

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

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

 

Нэг контейнерын хувьд бид Docker болон Kubernetes-д өөр өөр процессын модыг авдаг:

Ачааллыг S6-ийн хяналтан дор гүйцэтгэдэг. Коллектор болон үйл явдлуудад анхаарлаа хандуулаарай - эдгээр нь бүртгэл, хэмжигдэхүүнийг хариуцдаг манай агентууд юм. Kubernetes-д байхгүй ч Докерт байдаг. Яагаад? 

Хэрэв бид "под" (цаашид - Kubernetes pod) -ийн тодорхойлолтыг харвал үйл явдлын контейнер нь хэмжигдэхүүн болон лог цуглуулах функцийг гүйцэтгэдэг тусдаа цуглуулагч контейнертэй pod-д хийгдэж байгааг харах болно. Бид Kubernetes-ийн чадавхийг ашиглаж болно: контейнеруудыг нэг pod, нэг процесс болон/эсвэл сүлжээний орон зайд ажиллуулах. Үнэн хэрэгтээ төлөөлөгчдөө танилцуулж, зарим үүргийг гүйцэтгээрэй. Хэрэв ижил контейнерыг Docker-д ажиллуулбал энэ нь гаралттай ижил чадамжийг хүлээн авах болно, өөрөөр хэлбэл агентууд дотооддоо нээгдэх тул бүртгэл, хэмжигдэхүүнийг хүргэх боломжтой болно. 

Хэмжилт ба бүртгэл

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

Хоёрдахь тал бол бүртгэлийн хэмжээг хязгаарлах явдал юм. Хэрэв хэд хэдэн контейнерт бүртгэлийн хэмжээ огцом нэмэгдвэл (програм нь гогцоонд стек-мөрийг гаргадаг) CPU, холбооны суваг, бүртгэл боловсруулах системийн ачаалал нэмэгдэх бөгөөд энэ нь хостын үйл ажиллагаанд нөлөөлдөг. хост дээр бүхэлд нь болон бусад савнууд, дараа нь заримдаа энэ нь хостыг "унахад" хүргэдэг. 

Гурав дахь тал нь хайрцагнаас аль болох олон хэмжигдэхүүн цуглуулах аргыг дэмжих шаардлагатай байна. Файлуудыг унших, Prometheus-endpoint-ийн санал асуулга авахаас эхлээд програмын тусгай протоколуудыг ашиглах хүртэл.

Хамгийн сүүлчийн зүйл бол нөөцийн хэрэглээг багасгах явдал юм.

Бид Telegraf нэртэй нээлттэй эхийн Go шийдлийг сонгосон. Энэ нь 140 гаруй төрлийн оролтын суваг (оролтын залгаасууд) болон 30 төрлийн гаралтын сувгуудыг (гаралтын залгаасууд) дэмждэг бүх нийтийн холбогч юм. Бид үүнийг эцэслэн боловсруулсан бөгөөд одоо бид үүнийг Кубернетес ашиглан хэрхэн ашиглахаа жишээ болгон танд хэлэх болно. 

Хөгжүүлэгч ажлын ачааллыг байршуулж, Kubernetes pod үүсгэх хүсэлтийг хүлээн авлаа гэж бодъё. Энэ үед Цуглуулагч нэртэй контейнер нь под тус бүрт автоматаар үүсгэгддэг (бид мутацийн вэб дэгээ ашигладаг). Цуглуулагч бол манай төлөөлөгч. Эхэндээ энэ контейнер нь Prometheus болон лог цуглуулах системтэй ажиллахаар өөрийгөө тохируулдаг.

• Үүнийг хийхийн тулд энэ нь pod annotations ашигладаг бөгөөд агуулгаасаа хамааран Prometheus төгсгөлийн цэгийг үүсгэдэг; 
• Тавцангийн тодорхойлолт болон савны тусгай тохиргоонд үндэслэн логийг хэрхэн хүргэхийг шийддэг.

Бид Docker API-ээр дамжуулан логуудыг цуглуулдаг: хөгжүүлэгчид тэдгээрийг stdout эсвэл stderr-д оруулахад л хангалттай бөгөөд Цуглуулагч үүнийг цэгцлэх болно. Хост хэт ачааллаас сэргийлэхийн тулд бүртгэлийг хэсэг хэсгээр нь хэсэгчлэн цуглуулдаг. 

Хэмжилтийг контейнер доторх ажлын ачааллын тохиолдлууд (процессууд) дээр цуглуулдаг. Бүх зүйл хаяглагдсан: нэрийн орон зай, доор гэх мэт, дараа нь Prometheus формат руу хөрвүүлэгдэж, цуглуулах боломжтой болно (логуудаас бусад). Бид мөн Кафка руу бүртгэл, хэмжигдэхүүн, үйл явдлуудыг илгээж, цаашилбал:

• Бүртгэлийг Graylog (харааны шинжилгээнд зориулж) авах боломжтой;
• Лог, хэмжүүр, үйл явдлуудыг урт хугацааны хадгалах зорилгоор Clickhouse руу илгээдэг.

AWS дээр бүх зүйл яг адилхан ажилладаг, зөвхөн бид Graylog-г Кафкагаар Cloudwatch-ээр сольдог. Бид тэнд логуудыг илгээдэг бөгөөд бүх зүйл маш тохиромжтой: тэд аль кластер, контейнерт хамаарах нь шууд тодорхой болно. Google Stackdriver-ийн хувьд ч мөн адил. Өөрөөр хэлбэл, манай схем Кафкатай газар дээр нь болон үүлэн дээр ажилладаг. 

Хэрэв бидэнд хонхорцог бүхий Кубернетес байхгүй бол схем нь арай илүү төвөгтэй боловч ижил зарчмаар ажилладаг.

Үүнтэй ижил процессуудыг савны дотор гүйцэтгэдэг бөгөөд тэдгээрийг S6 ашиглан зохион байгуулдаг. Бүх ижил процессууд нэг контейнер дотор явагдаж байна.

Үүний үр дүнд,

Бид лог болон хэмжигдэхүүнүүдийг цуглуулах, хүргэх сонголт бүхий зураг бүтээх, эхлүүлэх бүрэн шийдлийг бий болгосон.

• Бид зураг цуглуулах стандартчилсан арга барилыг боловсруулж, үүн дээр үндэслэн CI загваруудыг боловсруулсан;
• Мэдээлэл цуглуулах агентууд нь бидний Telegraf өргөтгөл юм. Бид тэдгээрийг үйлдвэрлэлд сайн туршиж үзсэн;
• Бид мутацын вэб дэгээг ашиглан савнууд дахь агентуудтай савыг хэрэгжүүлэх; 
• Kubernetes/Rancher экосистемд нэгдсэн;
• Бид өөр өөр зохион байгуулалтын системд ижил контейнеруудыг ажиллуулж, бидний хүлээж буй үр дүнд хүрч чадна;
• Бүрэн динамик савны удирдлагын тохиргоог үүсгэсэн. 

Хамтран зохиогч: Илья Прудников

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