Хүлээж байгаагаар Виталий Хабаров ярилцлага өгсөн Дмитрий Столяров (), техникийн захирал, Флант компанийн үүсгэн байгуулагч. Виталий Дмитрийгээс Флант юу хийдэг талаар, Кубернетес, экосистемийн хөгжил, дэмжлэгийн талаар асуув. Бид Кубернетес яагаад хэрэгтэй байгаа, энэ нь огт хэрэгтэй эсэх талаар ярилцсан. Мөн бичил үйлчилгээ, Amazon AWS, DevOps-ийн "Би азтай байх болно" арга барил, Кубернетесийн ирээдүй, яагаад, хэзээ, хэрхэн дэлхийг эзлэх, DevOps-ийн хэтийн төлөв, инженерүүд юунд бэлдэх ёстой вэ. хялбаршуулсан болон мэдрэлийн сүлжээ бүхий гэрэлт, ойрын ирээдүй.
DevOps Deflop дээр подкаст хэлбэрээр сонсоорой - DevOps-ийн тухай орос хэл дээрх подкаст, доор нь текст хувилбар байна.
Энд, доор тэр асуулт асуудаг Express42-ын инженер.
"Флант"-ын тухай
- Сайн уу Дима. Та бол техникийн захирал""мөн үүсгэн байгуулагч. Тус компани юу хийдэг, та юунд багтдаг вэ?
Дмитрий: Гаднаас нь харахад бид бүх хүмүүст зориулж Kubernetes суулгаж, түүгээр ямар нэгэн зүйл хийдэг залуус юм шиг санагддаг. Гэхдээ энэ нь үнэн биш юм. Бид Линукстэй харьцдаг компани болж эхэлсэн боловч маш удаан хугацаанд үйлдвэрлэлийн болон өндөр ачаалалтай түлхүүр гардуулах төслүүдэд үндсэн үйл ажиллагаа явуулж байна. Ихэвчлэн бид бүхэл бүтэн дэд бүтцийг эхнээс нь барьж, дараа нь урт удаан хугацаанд хариуцдаг. Тиймээс “Флант”-ын мөнгө авдаг гол ажил нь хариуцлага хүлээх, түлхүүр гардуулах үйлдвэрлэлийг хэрэгжүүлэх.
Би техникийн захирал, компанийг үүсгэн байгуулагчдын нэг хүний хувьд үйлдвэрлэлийн хүртээмжийг нэмэгдүүлэх, үйл ажиллагааг нь хялбаршуулах, администраторуудын амьдралыг хөнгөвчлөх, хөгжүүлэгчдийн амьдралыг илүү тааламжтай болгохын тулд өдөр шөнөгүй хичээж байна. .
Кубернетесийн тухай
- Сүүлийн үед би Флант багаас маш олон тайланг харж байна Кубернетесийн тухай. Та яаж үүнд хүрсэн бэ?
Дмитрий: Би энэ талаар олон удаа ярьсан, гэхдээ би үүнийг давтахаас огт дургүйцэхгүй. Шалтгаан, үр дагавар хоёрын хооронд андуурч байгаа учраас энэ сэдвийг давтах нь зөв гэж бодож байна.
Бидэнд үнэхээр хэрэгсэл хэрэгтэй байсан. Бид маш олон асуудалтай тулгарч, тэмцэж, янз бүрийн суга таягтай даван туулж, багаж хэрэгслийн хэрэгцээг мэдэрсэн. Бид олон янзын хувилбаруудыг туулж, өөрсдийн дугуйг бүтээж, туршлага хуримтлуулсан. Аажмаар бид Docker-ыг гарч ирмэгцээ буюу 2013 онд ашиглаж эхэлсэн цэгт хүрсэн. Энэ гарч ирэх үед бид чингэлэгтэй холбоотой маш их туршлагатай байсан, бид "Docker" -ын аналогийг аль хэдийн бичсэн байсан - Python дээр өөрсдийн зарим суга таяг. Docker гарч ирснээр таягуудыг хаяж, найдвартай, олон нийтийн дэмжлэгтэй шийдлийг ашиглах боломжтой болсон.
Кубернетестэй төстэй түүхтэй. Энэ нь эрч хүчээ авч эхлэхэд - бидний хувьд энэ бол 1.2 хувилбар юм - бид аль хэдийн Shell болон Chef-ийн аль алинд нь олон тооны суга таягтай байсан бөгөөд бид ямар нэгэн байдлаар Докертой хамтран зохицуулах гэж оролдсон. Бид Rancher болон бусад янз бүрийн шийдлүүдийг нухацтай хайж байсан боловч дараа нь бүх зүйл бидний хийх байсан шиг эсвэл бүр илүү сайн хэрэгжсэн Кубернетес гарч ирэв. Үүнд гомдоллох зүйл алга.
Тийм ээ, энд ямар нэгэн төгс бус байдал байна, тэнд ямар нэгэн төгс бус байдал байна - маш олон дутагдалтай, 1.2 нь ерөнхийдөө аймшигтай, гэхдээ ... Кубернетес бол баригдаж буй барилга шиг - Та төслийг хараад ойлгоорой. сайхан байх болно. Хэрэв барилга одоо суурьтай, хоёр давхартай бол та одоохондоо нүүхгүй байх нь дээр гэдгийг ойлгож байгаа боловч програм хангамжийн хувьд ийм асуудал байхгүй - та үүнийг аль хэдийн ашиглаж болно.
Бидэнд Kubernetes-ийг ашиглах уу, үгүй юу гэж бодсон мөч байгаагүй. Бид үүнийг гарч ирэхээс нь өмнө хүлээж байсан бөгөөд өөрсдөө аналогийг бий болгохыг хичээсэн.
Кубернетесийн тухай
- Та Кубернетесийг хөгжүүлэхэд шууд оролцдог уу?
Дмитрий: Дунд зэргийн. Харин бид экосистемийг хөгжүүлэхэд оролцдог. Бид тодорхой тооны татах хүсэлтийг илгээдэг: Прометей, янз бүрийн операторууд, Хелм рүү - экосистемд. Харамсалтай нь, би бидний хийж буй бүх зүйлийг хянах боломжгүй бөгөөд би буруу байж магадгүй ч биднээс цөмд нэг ч цөөрөм байдаггүй.
- Үүний зэрэгцээ та Kubernetes-ийн эргэн тойронд олон хэрэгслүүдээ хөгжүүлдэг үү?
Дмитрий: Стратеги нь ийм: бид явж, аль хэдийн байгаа бүх зүйл рүү хүсэлт гаргадаг. Хэрэв татах хүсэлтийг тэнд хүлээж авахгүй бол бид зүгээр л өөрсдөө сэрээгээд өөрсдийн бүтээн байгуулалтыг хүлээж авах хүртэл амьдарна. Дараа нь урсгалын дээд хэсэгт хүрэхэд бид дээд талын хувилбар руу буцна.
Жишээлбэл, бид Prometheus оператортой бөгөөд бид угсралтынхаа дээд урсгал руу 5 удаа шилжиж байсан. Бидэнд ямар нэгэн функц хэрэгтэй байна, бид татах хүсэлт илгээсэн, бид үүнийг маргааш гаргах хэрэгтэй, гэхдээ бид үүнийг өмнө нь гаргахыг хүлээхийг хүсэхгүй байна. Үүний дагуу бид өөрсдөө угсарч, ямар нэг шалтгааны улмаас шаардлагатай байгаа онцлог шинж чанараараа бүх кластерууддаа угсардаг. Дараа нь, жишээ нь, тэд "Залуус аа, үүнийг илүү ерөнхий байдлаар хийцгээе" гэсэн үгсээр бидэн рүү эргүүлж, бид эсвэл өөр хэн нэгэн үүнийг дуусгаж, цаг хугацаа өнгөрөхөд дахин нэгддэг.
Бид байгаа бүх зүйлийг хөгжүүлэхийг хичээдэг. Одоохондоо байхгүй, зохион бүтээгдээгүй, зохион бүтээгдсэн, гэхдээ хэрэгжүүлэх цаг хугацаа байгаагүй олон элементүүд - бид үүнийг хийж байна. Мөн үйлдвэрлэлийн үйл явц эсвэл унадаг дугуй барихад дуртай учраас биш, харин бидэнд энэ хэрэгсэл хэрэгтэй байгаа учраас л. Бид яагаад ийм юм хийсэн юм бэ гэсэн асуулт байнга гардаг. Хариулт нь энгийн - тийм ээ, учир нь бид цаашаа явж, зарим практик асуудлыг шийдэх ёстой байсан бөгөөд бид үүнийг энэ тулагаар шийдсэн.
Зам үргэлж ийм байдаг: бид маш болгоомжтой хайж, хэрвээ талхаар троллейбус хийх талаар ямар ч шийдэл олохгүй бол бид өөрсдөө талх, троллейбус хийдэг.
Фланта хэрэгсэл
— Флант одоо нэмэлт операторууд, бүрхүүлийн операторууд, dapp/werf хэрэгслүүдтэй гэдгийг би мэднэ. Миний ойлгож байгаагаар энэ бол өөр өөр хувилгаануудын ижил хэрэгсэл юм. Flaunt дотор өөр өөр олон хэрэгслүүд байгааг би бас ойлгож байна. Энэ бол үнэн?
Дмитрий: Бидэнд GitHub дээр илүү олон зүйл бий. Одоо миний санаж байгаагаар бид бүгдэд таалагдсан Графанагийн самбар гэсэн статусын зурагтай болсон. Энэ нь Medium дээрх Kubernetes мониторингийн тухай бараг хоёр дахь нийтлэл бүрт дурдсан байдаг. Статусын зураглал гэж юу болохыг товч тайлбарлах боломжгүй - үүнд тусдаа нийтлэл хэрэгтэй, гэхдээ энэ нь цаг хугацааны явцад статусыг хянахад маш хэрэгтэй зүйл юм, учир нь Кубернетес дээр бид цаг хугацааны явцад статусыг харуулах шаардлагатай болдог. Бидэнд LogHouse бас бий - энэ нь ClickHouse дээр суурилсан зүйл бөгөөд Kubernetes дахь лог цуглуулах хар ид шид юм.
Олон тооны хэрэгслүүд! Мөн үүнээс ч их байх болно, учир нь энэ жил хэд хэдэн дотоод шийдлүүд гарах болно. Нэмэлт оператор дээр суурилсан маш том нэмэлтүүдээс Kubernetes-д зориулсан олон тооны нэмэлтүүд байдаг бөгөөд sert менежерийг хэрхэн зөв суулгах талаар - гэрчилгээ удирдах хэрэгсэл, Prometheus-ийг олон дагалдах хэрэгслээр хэрхэн зөв суулгах талаар - эдгээр нь хорин өөр зүйл юм. Өгөгдлийг экспортлож, ямар нэгэн зүйл цуглуулдаг хоёртын файлууд нь энэ Prometheus-д хамгийн гайхалтай график, анхааруулгатай байдаг. Энэ бүхэн нь кластерт суулгасан Kubernetes-ийн хэд хэдэн нэмэлт хэрэгсэл бөгөөд энгийнээс гайхалтай, боловсронгуй, автомат болж хувирдаг бөгөөд олон асуудал аль хэдийн шийдэгдсэн байдаг. Тийм ээ, бид маш их зүйлийг хийдэг.
Экосистемийн хөгжил
"Энэ хэрэгсэл, түүнийг ашиглах арга барилыг хөгжүүлэхэд энэ нь маш том хувь нэмэр гэж би бодож байна." Экосистемийн хөгжилд өөр хэн хувь нэмэр оруулахыг та ойролцоогоор тооцоолж чадах уу?
Дмитрий: ОХУ-д манай зах зээлд үйл ажиллагаа явуулдаг компаниудаас хэн ч ойрхон байдаггүй. Мэдээжийн хэрэг, энэ нь маш чанга мэдэгдэл юм, учир нь Mail болон Yandex зэрэг томоохон тоглогчид байдаг - тэд ч гэсэн Kubernetes-тэй ямар нэг зүйл хийж байгаа боловч тэд ч гэсэн биднээс хамаагүй илүү ажилладаг дэлхийн компаниудын хувь нэмэрт ойртдоггүй. Хэрэв би андуураагүй бол 80 хүний бүрэлдэхүүнтэй Флант, зөвхөн Кубернетэд 300 инженер ажилладаг Red Hat хоёрыг харьцуулахад хэцүү. Харьцуулахад хэцүү. Манай RnD хэлтэст намайг оруулаад 6 хүн бүх багажаа зүсдэг. 6 хүн, 300 улаан малгайт инженерийг харьцуулах нь ямар нэг байдлаар хэцүү байдаг.
-Гэхдээ энэ 6 хүн ч гэсэн үнэхээр хэрэгтэй, өөрөөсөө холдуулах зүйл хийж чадаж байхад практик асуудалтай тулгараад олон нийтэд шийдлийг нь өгдөг бол сонирхолтой тохиолдол. Өөрийн гэсэн Kubernetes хөгжүүлэлт, дэмжлэгийн багтай томоохон технологийн компаниудад зарчмын хувьд ижил хэрэгслийг боловсруулж болно гэдгийг би ойлгож байна. Энэ нь тэдний хувьд юуг хөгжүүлж, нийгэмд өгч болох тухай үлгэр жишээ болж, Кубернетесийг ашигладаг бүх нийгэмлэгт түлхэц өгч байна.
Дмитрий: Энэ нь магадгүй интеграторын онцлог, түүний онцлог юм. Бидэнд олон төсөл бий, олон янзын нөхцөл байдлыг харж байна. Бидний хувьд нэмүү өртөг бий болгох гол арга бол эдгээр тохиолдлуудад дүн шинжилгээ хийж, нийтлэг байдлыг олж, аль болох хямд болгох явдал юм. Бид энэ тал дээр идэвхтэй ажиллаж байна. Орос болон дэлхийн талаар ярихад надад хэцүү байгаа ч манай компанид DevOps-ийн 40 орчим инженер Кубернетес дээр ажилладаг. Орос улсад Кубернетесийг ойлгодог ижил төстэй мэргэжилтнүүдтэй олон компани байдаггүй гэж би бодохгүй байна.
Би DevOps инженерийн ажлын байрны талаархи бүх зүйлийг ойлгодог, хүн бүр бүгдийг ойлгодог бөгөөд DevOps инженерүүдийг DevOps инженерүүд гэж дууддаг, бид үүнийг хэлэлцэхгүй. Эдгээр бүх 40 гайхалтай DevOps инженерүүд өдөр бүр тулгардаг, асуудалтай тулгардаг, бид зөвхөн энэ туршлагад дүн шинжилгээ хийж, ерөнхийд нь дүгнэхийг хичээдэг. Хэрэв энэ нь бидний дотор үлдэх юм бол нэг эсвэл хоёр жилийн дараа энэ хэрэгсэл ашиггүй болно гэдгийг бид ойлгож байна, учир нь хаа нэг газар бэлэн Тула гарч ирэх болно. Энэ туршлагыг дотооддоо хуримтлуулах нь утгагүй бөгөөд энэ нь ердөө л эрчим хүч, цаг хугацааг dev/null руу урсгаж байгаа хэрэг юм. Мөн бид үүнд огт харамсдаггүй. Бид бүх зүйлийг маш их баяртайгаар нийтэлдэг бөгөөд үүнийг хэвлэн нийтлэх, хөгжүүлэх, сурталчлах, сурталчлах, ингэснээр хүмүүс үүнийг ашиглаж, туршлагаа нэмэх хэрэгтэй гэдгийг ойлгодог - тэгвэл бүх зүйл өсч, амьдардаг. Дараа нь хоёр жилийн дараа багаж нь хогийн сав руу ордоггүй. Хүч чадлаа үргэлжлүүлэх нь харамсалтай биш, учир нь хэн нэгэн таны хэрэгслийг ашиглаж байгаа нь тодорхой бөгөөд хоёр жилийн дараа бүгд үүнийг ашиглаж байна.
Энэ бол dapp/werf-тэй хийсэн бидний том стратегийн нэг хэсэг юм. Бид хэзээ хийж эхэлснээ санахгүй байна, 3 жилийн өмнө юм шиг байна. Эхэндээ энэ нь ерөнхийдөө бүрхүүл дээр байсан. Энэ бол үзэл баримтлалын супер нотолгоо байсан, бид тодорхой асуудлуудаа шийдсэн - энэ нь амжилттай болсон! Гэхдээ бүрхүүлд асуудал гардаг, үүнийг цаашид өргөжүүлэх боломжгүй, бүрхүүл дээр програмчлах нь өөр ажил юм. Бид Ruby хэлээр бичдэг зуршилтай байсан, үүний дагуу бид Ruby дээр ямар нэг зүйлийг дахин бүтээж, хөгжүүлж, хөгжүүлж, хөгжүүлж, "бид үүнийг хүсч байна, бид үүнийг хүсэхгүй байна" гэж хэлдэггүй олон нийт, олон нийттэй тулгарсан. ” гэж Руби руу хамраа эргүүлэв, энэ ямар инээдтэй юм бэ? Бид шалгах хуудасны эхний цэгийг хангахын тулд Go-д энэ бүх зүйлийг бичих хэрэгтэй гэдгийг ойлгосон. DevOps хэрэгсэл нь статик хоёртын файл байх ёстой. Go байх эсэх нь тийм ч чухал биш ч Go дээр бичигдсэн статик хоёртын хувилбар нь илүү дээр юм.
Бид эрч хүчээ зарцуулж, Go-д даппыг дахин бичиж, werf гэж нэрлэсэн. Dapp нь дэмжигдэхээ больсон, хөгжөөгүй, хамгийн сүүлийн хувилбар дээр ажиллаж байгаа боловч дээд цэгт хүрэх үнэмлэхүй шинэчлэх зам байгаа бөгөөд та үүнийг дагаж болно.
Даппыг яагаад бүтээсэн бэ?
— Дапп яагаад бүтээгдсэн, ямар асуудлыг шийдэж байгааг товчхон хэлж өгөхгүй юу?
Дмитрий: Эхний шалтгаан нь чуулган дээр байгаа. Docker олон үе шаттай чадваргүй байхад бид анхандаа бүтээхэд ноцтой асуудалтай тулгарсан тул бид өөрсдөө олон үе шаттай болгосон. Дараа нь бид зургийг цэвэрлэхэд илүү олон асуудал тулгарсан. CI/CD хийдэг хүн бүр удалгүй цуглуулсан зураг байгаа тул ямар нэгэн байдлаар хэрэггүй зүйлээ цэвэрлэж, хэрэгтэй зүйлээ үлдээх хэрэгтэй гэсэн асуудалтай тулгардаг.
Хоёр дахь шалтгаан нь байршуулалт юм. Тиймээ, Helm байдаг, гэхдээ энэ нь зөвхөн зарим асуудлыг шийддэг. Хачирхалтай нь "Хелм бол Кубернетесийн багц менежер" гэж бичсэн байдаг. Яг юу "нь". Мөн "Багц менежер" гэсэн үгс байдаг - Багц менежерээс ямар хүлээлт байдаг вэ? Бид: "Багц менежер - багцыг суулгаарай!" Бид түүнийг "Багц хүргэгдсэн" гэж хэлэхийг хүлээж байна.
Сонирхолтой нь бид: "Багцыг суулгана уу" гэж хэлээд түүнийг суулгасан гэж хариулахад тэр дөнгөж суулгацыг эхлүүлсэн нь харагдаж байна - тэр Кубернетесэд: "Энэ зүйлийг эхлүүл!" гэж зааж, эхэлсэн эсэхээс үл хамааран. , энэ нь ажиллаж байгаа эсэхээс үл хамааран Helm энэ асуудлыг огт шийддэггүй.
Helm бол зүгээр л Кубернетес рүү өгөгдөл ачаалдаг текстийн урьдчилсан боловсруулагч болох нь харагдаж байна.
Гэхдээ аливаа байршуулалтын нэг хэсэг болгон бид уг програмыг үйлдвэрлэхээр гаргасан эсэхийг мэдэхийг хүсч байна уу? Prod to prod гэдэг нь програм тийшээ нүүсэн, шинэ хувилбар нь тавигдсан, ядаж тэнд гацахгүй, зөв хариу үйлдэл үзүүлж байна гэсэн үг. Helm энэ асуудлыг ямар ч байдлаар шийддэггүй. Үүнийг шийдэхийн тулд та маш их хүчин чармайлт гаргах хэрэгтэй, учир нь та Кубернетесийг тарааж, тэнд юу болж байгааг хянах тушаал өгөх хэрэгтэй. Мөн байршуулах, цэвэрлэх, угсрахтай холбоотой маш олон ажил байдаг.
Төлөвлөгөө
Энэ жил орон нутгийн бүтээн байгуулалтыг эхлүүлнэ. Бид өмнө нь Vagrant-д байсан зүйлдээ хүрэхийг хүсч байна - бид "тэнгэрч" гэж бичиж, виртуал машинуудыг байрлуулсан. Бид Git-д төсөл байгаа цэгт хүрэхийг хүсч байна, бид тэнд "werf up" гэж бичдэг бөгөөд энэ нь орон нутгийн мини-Kub-д байрлуулсан, хөгжүүлэхэд тохиромжтой бүх лавлахуудыг холбосон энэ төслийн орон нутгийн хуулбарыг гаргаж ирдэг. . Хөгжүүлэлтийн хэлээс хамааран үүнийг өөр аргаар хийдэг боловч орон нутгийн хөгжлийг суулгасан файлуудын дор хялбархан хийх боломжтой.
Бидний хувьд дараагийн алхам бол хөгжүүлэгчдэд тав тухтай байдалд хөрөнгө оруулалт хийх. Нэг хэрэгслээр төслийг орон нутагт хурдан байршуулахын тулд түүнийг хөгжүүлж, Git-д түлхэж, дамжуулах хоолойноос хамааран үе шат эсвэл туршилтанд оруулаад дараа нь үйлдвэрлэл рүү явахдаа ижил хэрэгслийг ашиглана. Энэхүү нэгдмэл байдал, нэгдмэл байдал, дэд бүтцийг орон нутгийн орчноос борлуулалт хүртэл дахин үйлдвэрлэх чадвар нь бидний хувьд маш чухал цэг юм. Гэхдээ энэ нь хараахан ороогүй байна - бид үүнийг хийхээр төлөвлөж байна.
Гэхдээ dapp/werf-д хүрэх зам нь эхэндээ Кубернетестэй адил байсаар ирсэн. Бид асуудалтай тулгарсан, тэдгээрийг шийдвэрлэх арга замуудаар шийдсэн - бид бүрхүүл дээр, ямар ч зүйл дээр өөрсдөдөө зориулж зарим шийдлүүдийг гаргасан. Дараа нь тэд ямар нэгэн байдлаар эдгээр тойрон гарах шийдлүүдийг засч, ерөнхийлж, хоёртын хувилбар болгон нэгтгэхийг оролдсон бөгөөд бид үүнийг зүгээр л хуваалцдаг.
Энэ түүхийг бүхэлд нь аналоги байдлаар харах өөр нэг арга бий.
Кубернетес бол хөдөлгүүртэй машины хүрээ юм. Хаалга, шил, радио, гацуур мод - юу ч байхгүй. Зүгээр л хүрээ, хөдөлгүүр. Мөн Helm байдаг - энэ бол жолооны хүрд юм. Хөргөх - жолооны хүрд байдаг, гэхдээ танд жолооны зүү, жолооны тавиур, хурдны хайрцаг, дугуй хэрэгтэй бөгөөд тэдэнгүйгээр хийх боломжгүй.
Werf-ийн хувьд энэ нь Kubernetes-ийн өөр нэг бүрэлдэхүүн хэсэг юм. Зөвхөн одоо л werf-ийн альфа хувилбар дээр, жишээ нь, бид өөрсдөө хийхээс залхсан тул Helm-ийг werf дотор эмхэтгэсэн. Үүнийг хийх олон шалтгаан байгаа тул бид яагаад бүхэл бүтэн жолоогоо werf доторх тариалагчийн хамт нэгтгэсэн талаар дэлгэрэнгүй ярих болно. .
Одоо werf нь илүү нэгдсэн бүрэлдэхүүн хэсэг юм. Бид бэлэн жолооны хүрд, жолооны зүү авдаг - Би машинд тийм ч сайн биш, гэхдээ энэ бол нэлээд өргөн хүрээний асуудлыг шийдэж чадсан том блок юм. Бид өөрсдөө каталогийг үзэх шаардлагагүй, нэг хэсгийг нөгөөд нь сонгох, тэдгээрийг хэрхэн яаж холбох талаар бодох шаардлагагүй. Бид олон тооны асуудлыг нэг дор шийддэг бэлэн комбайн авдаг. Гэхдээ дотор нь ижил нээлттэй эхийн бүрэлдэхүүн хэсгүүдээс бүтээгдсэн бөгөөд угсрахад Docker, зарим функцэд Helm, бусад хэд хэдэн номын сангууд байдаг. Энэ нь CI/CD-г хайрцагнаас хурдан бөгөөд эвтэйхэн гаргаж авах нэгдсэн хэрэгсэл юм.
Кубернетесийг арчлахад хэцүү юу?
— Та Кубернетесийг ашиглаж эхэлсэн туршлагаасаа ярьж байна, энэ бол танд зориулагдсан хүрээ, хөдөлгүүр бөгөөд үүн дээр та маш олон зүйлийг өлгөх боломжтой: их бие, жолооны хүрд, дөрөөний шураг, суудал. Асуулт гарч ирнэ - Kubernetes-ийн дэмжлэг танд хэр хэцүү вэ? Та маш их туршлагатай, бусад бүх зүйлээс тусгаарлагдсан Кубернетесийг дэмжихэд хэр их цаг хугацаа, нөөцийг зарцуулдаг вэ?
Дмитрий: Энэ бол маш хэцүү асуулт бөгөөд хариулахын тулд бид дэмжлэг гэж юу болох, Кубернетесээс юу хүсч байгааг ойлгох хэрэгтэй. Магадгүй та илчилж болох уу?
- Миний мэдэж байгаагаар, миний харж байгаагаар одоо олон багууд Кубернетесийг туршиж үзэхийг хүсч байна. Хүн бүр үүнд өөрийгөө зориулж, өвдөг дээрээ тавьдаг. Хүмүүс энэ системийн нарийн төвөгтэй байдлыг тэр бүр ойлгодоггүй юм шиг санагддаг.
Дмитрий: Ийм л байна.
— Kubernetes-ийг эхнээс нь авч, суулгаж, үйлдвэрлэхэд бэлэн болгох нь хэр хэцүү вэ?
Дмитрий: Зүрх шилжүүлэн суулгах нь хэр хэцүү гэж бодож байна вэ? Энэ бол буулт хийх асуулт гэдгийг би ойлгож байна. Хусгай хэрэглэх, алдаа гаргахгүй байх нь тийм ч хэцүү биш юм. Хэрэв тэд хаана огтлох, хаана оёхыг зааж өгвөл процедур нь өөрөө төвөгтэй биш юм. Цаг хугацаа өнгөрөхөд бүх зүйл бүтнэ гэдгийг батлахад хэцүү байдаг.
Kubernetes-ийг суулгаж, ажилд оруулах нь амархан: дэгдээхэй! — суулгасан, суулгах олон арга байдаг. Гэхдээ асуудал гарвал яах вэ?
Асуулт үргэлж гарч ирдэг - бид юуг хараахан анхаарч үзээгүй вэ? Бид юу хийгээгүй байна вэ? Линуксийн аль цөмийн параметрүүдийг буруу зааж өгсөн бэ? Эзэн минь, бид тэднийг дурссан уу?! Бид Kubernetes-ийн ямар бүрэлдэхүүн хэсгүүдийг хүргэж, аль нь нийлүүлээгүй вэ? Мянга мянган асуулт урган гарч, түүнд хариулахын тулд 15-20 жилийг энэ салбарт зарцуулах хэрэгтэй.
Би энэ сэдвээр "Кубернетесийг арчлахад хэцүү юу?" Гэсэн асуудлын утгыг илчлэх сүүлийн үеийн жишээ байна. Хэсэг хугацааны өмнө бид Cilium-ийг Кубернетес дэх сүлжээ болгон хэрэгжүүлэхийг хичээх эсэх талаар нухацтай бодож үзсэн.
Cilium гэж юу болохыг тайлбарлая. Kubernetes нь сүлжээний дэд системийн олон янзын хэрэгжилттэй бөгөөд тэдгээрийн нэг нь маш гайхалтай юм - Cilium. Энэ нь ямар утгатай вэ? Цөмд хэсэг хугацааны өмнө цөмд зориулсан дэгээ бичих боломжтой болсон бөгөөд энэ нь нэг талаараа сүлжээний дэд систем болон бусад янз бүрийн дэд системүүдэд нэвтэрч, цөм дэх том хэсгүүдийг тойрч гарах боломжийг олгодог.
Линуксийн цөм нь түүхэндээ IP чиглүүлэлт, хэт шүүлтүүр, гүүр болон 15, 20, 30 жилийн настай олон төрлийн хуучин бүрэлдэхүүн хэсгүүдтэй. Ерөнхийдөө тэд ажилладаг, бүх зүйл сайхан байдаг, гэхдээ одоо тэд чингэлэг овоолж, 15 тоосгоноос бүрдсэн цамхаг шиг харагдаж, нэг хөл дээрээ зогсох нь хачирхалтай мэдрэмж төрж байна. Энэ систем нь түүхэндээ бие махбод дахь мухар олгойн гэх мэт олон нюанстай хөгжиж ирсэн. Зарим тохиолдолд гүйцэтгэлийн асуудал гардаг, жишээлбэл.
Гайхамшигтай BPF, цөмд зориулсан дэгээ бичих чадвар байдаг - залуус цөмд зориулж өөрсдийн дэгээ бичсэн. Багц нь Линуксийн цөмд орж ирдэг бөгөөд үүнийг шууд оролт дээр нь гаргаж аваад, гүүргүй, TCPгүйгээр, IP стекгүйгээр өөрсдөө боловсруулдаг - товчхондоо Линуксийн цөмд бичигдсэн бүх зүйлийг алгасаж, дараа нь нулимдаг. үүнийг саванд хийнэ.
Юу болсон бэ? Маш гайхалтай гүйцэтгэл, гайхалтай онцлогууд - зүгээр л гайхалтай! Гэхдээ бид үүнийг хараад машин бүр дээр Kubernetes API-тай холбогддог програм байдаг бөгөөд энэ API-аас хүлээн авсан өгөгдөл дээр үндэслэн C кодыг үүсгэж, цөмд ачаалдаг хоёртын файлуудыг хөрвүүлдэг бөгөөд ингэснээр эдгээр дэгээнүүд ажилладаг. цөмийн орон зайд.
Хэрэв ямар нэг зүйл буруу болвол яах вэ? Бид мэдэхгүй. Үүнийг ойлгохын тулд та энэ бүх кодыг уншиж, бүх логикийг ойлгох хэрэгтэй бөгөөд энэ нь хичнээн хэцүү байдаг нь гайхалтай юм. Гэхдээ нөгөө талаас эдгээр гүүрүүд, цэвэр шүүлтүүрүүд, ip rout байдаг - Би тэдний эх кодыг уншаагүй, манай компанид ажилладаг 40 инженер ч бас алга. Магадгүй цөөхөн хэд нь зарим хэсгийг нь ойлгодог байх.
Тэгээд ямар ялгаа байна? Эндээс харахад ip rout, Linux цөм, шинэ хэрэгсэл гарч ирэв - энэ нь ямар ялгаатай вэ, бид аль нэгийг нь ойлгохгүй байна. Гэхдээ бид шинэ зүйл ашиглахаас айдаг - яагаад? Учир нь хэрэв хэрэгсэл нь 30 жилийн настай бол 30 жилийн дотор бүх алдаанууд олдож, бүх алдаанууд дээр дэвшсэн бөгөөд та бүх зүйлийн талаар мэдэх шаардлагагүй - энэ нь хар хайрцаг шиг ажилладаг бөгөөд үргэлж ажилладаг. Аль оношилгооны халивыг аль газар наах, аль tcpdump ямар үед ажиллахыг хүн бүр мэддэг. Хүн бүр оношилгооны хэрэгслүүдийг сайн мэддэг бөгөөд Линукс цөмд энэ багц бүрэлдэхүүн хэсгүүд хэрхэн ажилладагийг ойлгодог - энэ нь хэрхэн ажилладагийг биш, харин хэрхэн ашиглахыг ойлгодог.
Гайхалтай дажгүй Cilium 30 нас хүрээгүй, хараахан хөгширөөгүй байна. Kubernetes-д ижил асуудал тулгардаг, хуулбар. Cilium-г төгс суулгасан, Kubernetes-ийг төгс суулгасан, гэхдээ үйлдвэрлэлд ямар нэг зүйл буруу болвол та ямар нэгэн чухал нөхцөл байдалд юу буруу болсныг хурдан ойлгож чадах уу?
Бид Кубернетесийг арчлахад хэцүү гэж хэлэхэд - үгүй, энэ нь маш амархан, тийм ээ, энэ нь үнэхээр хэцүү байдаг. Кубернетес бие даан маш сайн ажилладаг, гэхдээ тэрбум нюанстай.
"Би азтай байх болно" аргын тухай
- Эдгээр нюансууд бараг гарч ирэх баталгаатай компаниуд байдаг уу? Yandex гэнэт бүх үйлчилгээг Кубернетес рүү шилжүүлсэн гэж бодъё, тэнд асар их ачаалал бий болно.
Дмитрий: Үгүй ээ, энэ бол ачааллын тухай яриа биш, харин хамгийн энгийн зүйлсийн тухай юм. Жишээлбэл, бидэнд Kubernetes байгаа, бид тэнд програмыг байрлуулсан. Энэ нь ажиллаж байгааг та яаж мэдэх вэ? Аппликешн гацахгүй гэдгийг ойлгоход бэлэн хэрэгсэл байхгүй. Сэрэмжлүүлэг илгээдэг бэлэн систем байхгүй тул та эдгээр сэрэмжлүүлэг болон хуваарь бүрийг тохируулах хэрэгтэй. Мөн бид Kubernetes-ийг шинэчилж байна.
Надад Ubuntu 16.04 байгаа. Та үүнийг хуучин хувилбар гэж хэлж болно, гэхдээ энэ нь LTS учраас бид үүн дээр хэвээр байна. Systemd байдаг бөгөөд түүний нэг онцлог шинж чанар нь C бүлгийг цэвэрлэдэггүй. Кубернетес pod-уудыг ажиллуулж, C-группүүдийг үүсгэж, дараа нь подкуудыг устгаад ямар нэг байдлаар тодорхой болсон - би нарийн ширийн зүйлийг санахгүй байна, уучлаарай - системийн зүсмэлүүд хэвээр байна. Энэ нь цаг хугацаа өнгөрөхөд аливаа машин хүчтэй удааширч эхэлдэг. Энэ нь өндөр ачаалалтай холбоотой асуулт ч биш юм. Хэрэв байнгын pod-уудыг ажиллуулбал, жишээлбэл, байнга pod үүсгэдэг Cron Job байгаа бол Ubuntu 16.04-тэй машин долоо хоногийн дараа удааширч эхэлнэ. Олон тооны С бүлгүүд бий болсон тул ачаалал байнга өндөр байх болно. Энэ бол Ubuntu 16 болон Kubernetes-ийг дээр нь суулгасан хүн бүрт тулгардаг асуудал юм.
Тэр ямар нэгэн байдлаар systemd эсвэл өөр зүйлийг шинэчилдэг гэж бодъё, гэхдээ Линуксийн цөмд 4.16 хүртэл энэ нь илүү хөгжилтэй байдаг - C-бүлгийг устгах үед тэдгээр нь цөмд урсдаг бөгөөд үнэндээ устгагддаггүй. Тиймээс энэ машин дээр нэг сар ажилласны дараа зуухны санах ойн статистикийг харах боломжгүй болно. Бид файлыг гаргаж аваад програмдаа эргэлдэж, нэг файл 15 секундын турш эргэлддэг, учир нь цөм нь дотроо нэг сая C бүлгийг тоолоход маш их цаг зарцуулдаг бөгөөд тэдгээр нь устгагдсан мэт боловч үгүй - тэдгээр нь гоожиж байна. .
Энэ мэт өчүүхэн зүйл энд тэндгүй зөндөө л байна. Энэ нь аварга том компаниуд заримдаа маш хүнд ачааны дор тулгардаг асуудал биш - үгүй, энэ бол өдөр тутмын асуудал юм. Хүмүүс ийм байдлаар хэдэн сарын турш амьдарч чадна - тэд Kubernetes суулгаж, програмыг суулгасан - энэ нь ажиллах шиг байна. Олон хүмүүсийн хувьд энэ нь хэвийн үзэгдэл юм. Тэд энэ програм ямар нэг шалтгаанаар гацах болно гэдгийг мэдэхгүй, анхааруулга хүлээн авахгүй, гэхдээ энэ нь тэдний хувьд норм юм. Өмнө нь бид хяналтгүй виртуал машин дээр амьдардаг байсан бол одоо Кубернетес рүү нүүсэн, мөн хяналтгүй - ялгаа нь юу вэ?
Асуулт нь бид мөсөн дээр алхахдаа урьдчилан хэмжихгүй бол түүний зузааныг хэзээ ч мэдэхгүй. Олон хүмүүс алхаж, санаа зовдоггүй, учир нь тэд өмнө нь алхаж байсан.
Миний бодлоор аливаа системийг ажиллуулах нарийн төвөгтэй байдал нь мөсний зузаан нь бидний асуудлыг шийдвэрлэхэд хангалттай байх явдал юм. Энэ бол бидний ярьж байгаа зүйл юм.
Мэдээллийн технологийн салбарт "Би азтай байх болно" гэсэн хандлага хэтэрхий олон байх шиг байна. Олон хүмүүс азтай болно гэж найдаж програм хангамж суулгаж, програм хангамжийн санг ашигладаг. Ерөнхийдөө олон хүн азтай байдаг. Тийм учраас л ажилладаг байх.
— Миний гутранги үнэлгээнээс харахад эрсдэл өндөр, програм ажиллах ёстой үед Flaunt-аас дэмжлэг авах шаардлагатай, магадгүй Red Hat-аас дэмжлэг авах эсвэл Кубернетесэд тусгайлан зориулсан өөрийн дотоод баг хэрэгтэй болно. үүнийг татах.
Дмитрий: Объектив байдлаар ийм байна. Жижиг багийн хувьд Кубернетесийн түүхэнд бие даан орох нь хэд хэдэн эрсдэлтэй байдаг.
Бидэнд сав хэрэгтэй юу?
— Кубернетес Орост хэр өргөн тархсаныг хэлж чадах уу?
Дмитрий: Надад энэ мэдээлэл байхгүй, өөр хэнд ч байгаа гэдэгт эргэлзэхгүй байна. Бид "Кубернетес, Кубернетес" гэж хэлдэг, гэхдээ энэ асуудлыг харах өөр арга бий. Би чингэлэг хэр өргөн тархсаныг мэдэхгүй ч савны 70%-ийг Кубернетес зохион байгуулдаг гэсэн мэдээллийг интернетээс олж мэдсэн. Энэ нь дэлхий даяар нэлээд том дээж авах найдвартай эх сурвалж байсан.
Дараа нь өөр нэг асуулт - бидэнд сав хэрэгтэй юу? Миний хувийн мэдрэмж ба Flant компанийн ерөнхий байр суурь бол Кубернетес бол де факто стандарт юм.
Кубернетесээс өөр юу ч байхгүй болно.
Энэ бол дэд бүтцийн менежментийн салбарт үнэмлэхүй өөрчлөлт юм. Зүгээр л үнэмлэхүй - энэ бол Ansible, Chef, виртуал машин, Terraform. Би хуучин колхозын арга барилын тухай яриагүй. Кубернетес бол үнэмлэхүй өөрчлөгч юм, одоо зөвхөн ийм байх болно.
Үүнийг ойлгохын тулд заримд нь хэдэн жил, заримд нь хэдэн арван жил шаардагддаг нь ойлгомжтой. Kubernetes болон энэхүү шинэ дүр төрхөөс өөр зүйл байхгүй гэдэгт би эргэлзэхгүй байна: бид үйлдлийн системийг гэмтээхээ больсон, харин ашигладаг. код болгон дэд бүтэц, зөвхөн кодтой биш, харин yml-тэй - тунхаглалаар тодорхойлсон дэд бүтэц. Үргэлж ийм байх болно гэсэн мэдрэмж надад төрж байна.
- Өөрөөр хэлбэл, Кубернетес рүү хараахан шилжиж амжаагүй компаниуд үүн рүү шилжих эсвэл мартагдах болно. Би чамайг зөв ойлгосон уу?
Дмитрий: Энэ нь бас бүхэлдээ үнэн биш юм. Жишээлбэл, хэрэв бидэнд DNS сервер ажиллуулах даалгавар байгаа бол үүнийг FreeBSD 4.10 дээр ажиллуулж, 20 жилийн турш төгс ажиллах боломжтой. Зүгээр л ажилла, тэгээд л болоо. Магадгүй 20 жилийн дараа ямар нэг зүйлийг нэг удаа шинэчлэх шаардлагатай болно. Хэрэв бид эхлүүлсэн форматын програм хангамжийн тухай ярьж байгаа бөгөөд энэ нь олон жилийн турш ямар ч шинэчлэлгүйгээр, өөрчлөлтгүйгээр ажилладаг бол мэдээж Kubernetes байхгүй болно. Тэр тэнд хэрэггүй.
CI/CD-тэй холбоотой бүх зүйл - Тасралтгүй хүргэлт шаардлагатай хаана ч, хаана хувилбараа шинэчлэх, идэвхтэй өөрчлөлт хийх, алдааг тэсвэрлэх чадварыг бий болгох шаардлагатай хаана ч байсан - зөвхөн Kubernetes.
Микро үйлчилгээний тухай
- Энд надад бага зэргийн диссонанс байна. Kubernetes-тэй ажиллахын тулд танд гадаад эсвэл дотоод дэмжлэг хэрэгтэй - энэ бол эхний цэг юм. Хоёрдугаарт, бид дөнгөж бүтээн байгуулалтыг эхлүүлж байгаа үед бид жижиг стартап, бидэнд хараахан юу ч байхгүй, Kubernetes эсвэл микросервис архитектурын хөгжүүлэлт нь нарийн төвөгтэй бөгөөд үргэлж эдийн засгийн үндэслэлтэй байдаггүй. Би таны бодлыг сонирхож байна - стартапууд Kubernetes-д зориулж шууд эхнээс нь бичиж эхлэх шаардлагатай юу, эсвэл тэд цул бичээд дараа нь зөвхөн Кубернетес рүү ирж чадах уу?
Дмитрий: Сайхан асуулт. Би микро үйлчилгээний талаар ярьж байна Микроскопоор хумсаа цохих гэж оролдсон хүмүүстэй би олон удаа тааралдсан. Энэ арга нь өөрөө зөв, бид өөрсдөө дотоод программ хангамжаа ийм байдлаар зохион бүтээдэг. Гэхдээ та үүнийг хийхдээ юу хийж байгаагаа тодорхой ойлгох хэрэгтэй. Микро үйлчилгээний талаар миний хамгийн их үзэн яддаг үг бол "микро". Түүхийн хувьд энэ үг тэндээс үүссэн бөгөөд яагаад ч юм хүмүүс микро нь микрометр шиг маш жижиг, миллиметрээс бага гэж боддог. Энэ бол буруу.
Жишээлбэл, 300 хүний бичсэн цул зохиол байдаг бөгөөд бүтээн байгуулалтад оролцсон хүн бүр тэнд асуудал байгаа гэдгийг ойлгодог бөгөөд үүнийг бичил хэсгүүдэд хуваах хэрэгтэй - 10 орчим хэсэг, тус бүрийг нь 30 хүн бичдэг. хамгийн бага хувилбарт. Энэ бол чухал, шаардлагатай, сэрүүн юм. Гэхдээ маш дажгүй, авъяаслаг 3 залуу өвдөг дээрээ сөхрөн 60 бичил үйлчилгээ бичдэг стартап манайд ирэхэд би Корвалолыг хайх бүртээ.
Энэ талаар хэдэн мянган удаа ярьж байсан юм шиг санагдаж байна - бид нэг хэлбэрээр эсвэл өөр хэлбэрээр тараасан цул авсан. Энэ нь эдийн засгийн хувьд үндэслэлгүй, ерөнхийдөө бүх зүйлд маш хэцүү байдаг. Би үүнийг маш олон удаа харсан болохоор намайг үнэхээр өвтгөж байна, тиймээс би энэ тухай үргэлжлүүлэн ярьсаар байна.
Эхний асуултын хувьд, нэг талаас Кубернетесийг ашиглах нь аймшигтай, учир нь тэнд юу эвдрэх, ажиллахгүй байх нь тодорхойгүй, нөгөө талаас бүх зүйл тийшээ явах нь тодорхой байна. тэгээд Кубернетесээс өөр юу ч оршин тогтнохгүй. Хариулт - ирж буй ашиг, шийдвэрлэх боломжтой ажлуудын хэмжээг жинлэнэ. Энэ нь жингийн нэг талд байна. Нөгөөтэйгүүр, сул зогсолт эсвэл хариу өгөх хугацаа буурах, хүртээмжийн түвшин - гүйцэтгэлийн үзүүлэлтүүд буурахтай холбоотой эрсдэлүүд байдаг.
Энд байна - бид хурдан хөдөлж, Кубернетес бидэнд олон зүйлийг илүү хурдан, илүү сайн хийх боломжийг олгодог, эсвэл бид найдвартай, цаг хугацаагаар туршсан шийдлүүдийг ашигладаг, гэхдээ илүү удаан хөдөлдөг. Энэ бол компани бүрийн хийх ёстой сонголт юм. Та үүнийг ширэнгэн ойд зам гэж төсөөлж болно - та анх удаа алхахдаа могой, бар эсвэл галзуу дорготой таарч, 10 удаа алхсан бол та замыг гишгэсэн, зайлуулсан. мөчрүүд болон алхахад хялбар болно. Тэр болгонд зам улам өргөжиж байна. Дараа нь асфальтан зам, дараа нь сайхан өргөн чөлөө.
Кубернетес зогссонгүй. Дахин асуулт: Кубернетес нь нэг талаас 4-5 хоёртын систем, нөгөө талаас энэ нь бүхэл бүтэн экосистем юм. Энэ бол бидний машин дээр байдаг үйлдлийн систем юм. Энэ юу вэ? Ubuntu эсвэл Curios? Энэ бол Линуксийн цөм, нэмэлт бүрэлдэхүүн хэсгүүдийн багц юм. Энэ бүх зүйл энд, нэг хорт могойг замаас хаяж, тэнд хашаа барьсан. Кубернетес маш хурдан бөгөөд динамикаар хөгжиж байгаа бөгөөд эрсдэлийн хэмжээ, үл мэдэгдэх зүйлийн хэмжээ сар бүр буурч, үүний дагуу эдгээр масштабууд дахин тэнцвэржиж байна.
Гарааны бизнес эрхлэгч юу хийх ёстой вэ гэсэн асуултанд хариулахын тулд би хэлэх болно - Flaunt-д ирээд 150 мянган рубль төлж, түлхүүр гардуулах DevOps хялбар үйлчилгээг аваарай. Хэрэв та цөөн тооны хөгжүүлэгчидтэй жижиг стартап бол энэ нь ажиллах болно. Энэ үед асуудлаа шийдэж, цалингаа хэрхэн төлөх талаар сурах шаардлагатай өөрийн DevOps-ийг ажилд авахын оронд та бүх асуудлыг түлхүүр гардуулах шийдлийг авах болно. Тийм ээ, зарим сул талууд бий. Бид аутсорсингийн хувьд ийм оролцоотой байж, өөрчлөлтөд хурдан хариу өгөх боломжгүй. Гэхдээ бидэнд маш их туршлага, бэлэн дадлага бий. Бид ямар ч нөхцөлд үүнийг хурдан олж мэдээд ямар ч Кубернетикийг үхэгсдээс амилуулна гэдгийг бид баталж байна.
10 хүний бүрэлдэхүүнтэй багийг үйл ажиллагаандаа зориулж чадах хэмжээний гарааны бизнесүүд болон байгуулагдсан бизнесүүдэд аутсорсинг хийхийг зөвлөж байна, өөрөөр хэлбэл ямар ч утгагүй юм. Үүнийг аутсорсинг хийх нь гарцаагүй.
Amazon болон Google-ийн тухай
— Amazon эсвэл Google-ийн шийдлийн хостыг аутсорсинг гэж үзэж болох уу?
Дмитрий: Тийм ээ, мэдээжийн хэрэг, энэ нь хэд хэдэн асуудлыг шийддэг. Гэхдээ дахиад л нюансууд байна. Та үүнийг хэрхэн ашиглахаа ойлгох хэрэгтэй хэвээр байна. Жишээлбэл, Amazon AWS-ийн ажилд мянга мянган жижиг зүйл байдаг: Ачаалал тэнцвэржүүлэгчийг халаах шаардлагатай эсвэл "Залуус аа, бид замын хөдөлгөөнийг хүлээн авна, Ачаалал тэнцвэржүүлэгчийг дулаацуулаарай!" Та эдгээр нюансуудыг мэдэх хэрэгтэй.
Энэ чиглэлээр мэргэшсэн хүмүүст хандахад та бараг бүх ердийн зүйл хаагдах болно. Бид одоо 40 инженертэй, жилийн эцэс гэхэд 60 болох байх - бид энэ бүх зүйлтэй тулгарсан. Бид ямар нэг төсөл дээр дахин ийм асуудалтай тулгарсан ч бид бие биенээсээ хурдан асууж, яаж шийдэхээ мэддэг.
Магадгүй хариулт нь мэдээжийн хэрэг, зохион байгуулсан түүх нь зарим хэсгийг хөнгөвчлөх болно. Асуулт бол та эдгээр хостуудад итгэхэд бэлэн байгаа эсэх, тэд таны асуудлыг шийдэх эсэх юм. Amazon болон Google сайн ажилласан. Бидний бүх тохиолдлын хувьд - яг. Бидэнд өөр эерэг туршлага байхгүй. Бидний ажиллахыг оролдсон бусад бүх үүл нь маш олон асуудал үүсгэдэг - Ager, Орост байгаа бүх зүйл, янз бүрийн хувилбарт байгаа бүх төрлийн OpenStack: Headster, Overage - таны хүссэн бүх зүйл. Тэд бүгд таны шийдэхийг хүсэхгүй байгаа асуудлуудыг бий болгодог.
Тиймээс хариулт нь тийм ээ, гэхдээ үнэндээ боловсронгуй зохион байгуулалттай шийдлүүд тийм ч олон байдаггүй.
Кубернетес хэнд хэрэгтэй вэ?
- Гэсэн хэдий ч Кубернетес хэнд хэрэгтэй вэ? Kubernetes-д тусгайлан ирдэг ердийн Flaunt үйлчлүүлэгч болох Кубернетес рүү хэн аль хэдийн шилжих ёстой вэ?
Дмитрий: Энэ бол сонирхолтой асуулт байна, учир нь яг одоо Кубернетесийн дараа олон хүмүүс бидэн дээр ирдэг: "Залуус аа, та Кубернетес хийж байгааг бид мэднэ, бидний төлөө үүнийг хий!" Бид тэдэнд: "Ноёд оо, бид Кубернетес хийдэггүй, бид үйлдвэрлэл, түүнтэй холбоотой бүх зүйлийг хийдэг." Учир нь бүх CI/CD болон энэ түүхийг бүхэлд нь хийхгүйгээр бүтээгдэхүүн хийх нь одоогоор боломжгүй юм. Хөгжиж хөгждөг, мөлжлөгөөр мөлждөг гэсэн хуваагдлаас бүгд холдсон.
Манай үйлчлүүлэгчид өөр өөр зүйлийг хүлээж байгаа боловч хүн бүр тодорхой асуудалтай тулгардаг сайхан гайхамшгийг хүлээж байгаа бөгөөд одоо - хоп! - Кубернетес тэднийг шийдэх болно. Хүмүүс гайхамшигт итгэдэг. Тэдний оюун ухаанд тэд гайхамшиг тохиолдохгүй гэдгийг ойлгодог, гэхдээ сэтгэлдээ тэд найдаж байна - хэрэв энэ Кубернетчууд одоо бидний төлөө бүх зүйлийг шийдэх юм бол тэд энэ талаар маш их ярьдаг! Гэнэт тэр одоо - найтаах! - Мөн мөнгөн сум, найтаах! - мөн бид 100% ажиллах хугацаатай, бүх хөгжүүлэгчид үйлдвэрлэлд орсон бүх зүйлийг 50 удаа гаргах боломжтой бөгөөд энэ нь гацдаггүй. Ерөнхийдөө гайхамшиг!
Ийм хүмүүс бидэн дээр ирэхэд бид: "Уучлаарай, гэхдээ гайхамшиг гэж байдаггүй." Эрүүл байхын тулд зөв хооллож, дасгал хөдөлгөөн хийх хэрэгтэй. Найдвартай бүтээгдэхүүнтэй байхын тулд түүнийг найдвартай хийх хэрэгтэй. Тохиромжтой CI/CD-тэй болохын тулд та үүнийг ийм болгох хэрэгтэй. Энэ бол хийх ёстой маш их ажил юм.
Кубернетес хэнд хэрэгтэй вэ гэсэн асуултад хариулж байна - Кубернетес хэнд ч хэрэггүй.
Зарим хүмүүс Кубернетес хэрэгтэй гэсэн буруу ойлголттой байдаг. Хүмүүс дэд бүтцийн бүх асуудал, програмаа ажиллуулахтай холбоотой асуудлуудыг бодох, судлах, сонирхохоо болих хэрэгтэй. Тэд програмуудыг зүгээр л ажиллуулж, зүгээр л байршуулахыг хүсдэг. Тэдний хувьд Кубернетес бол "бид тэнд хэвтэж байсан" эсвэл "бид гарч чадахгүй" гэх мэт түүхийг сонсохоо болино гэсэн найдвар юм.
Техникийн захирал ихэвчлэн манайд ирдэг. Тэд түүнээс хоёр зүйлийг асуудаг: нэг талаас бидэнд онцлог шинж чанар, нөгөө талаас тогтвортой байдал. Бид танд үүнийг өөртөө авч, хийхийг санал болгож байна. Мөнгөн сум, эс тэгвээс мөнгөөр бүрсэн бол та эдгээр асуудлын талаар бодож, цаг хугацаа алдахаа болино. Энэ асуудлыг хаах онцгой хүмүүс танд байх болно.
Бидэнд эсвэл өөр хэн нэгэнд Кубернетес хэрэгтэй гэсэн үг буруу байна.
Админуудад үнэхээр Кубернетес хэрэгтэй байна, учир нь энэ нь таны тоглож, тоглож болох маш сонирхолтой тоглоом юм. Шударга байцгаая - хүн бүр тоглоомонд дуртай. Бид бүгдээрээ хаа нэгтээ хүүхэд, шинийг хараад тоглохыг хүсдэг. Зарим хүмүүсийн хувьд, тухайлбал, удирдлагад энэ нь урам хугарсан, учир нь тэд аль хэдийн хангалттай тоглож, ядарч туйлдсан тул тэд зүгээр л хүсэхгүй байна. Гэхдээ энэ нь хэнд ч бүрэн алдагдаагүй. Жишээлбэл, хэрэв би системийн удирдлага болон DevOps-ийн салбарт удаан хугацааны турш тоглоомоос залхаж байсан бол би тоглоомонд дуртай хэвээр байгаа ч шинийг худалдаж авдаг. Бүх хүмүүс ямар нэгэн байдлаар, ямар нэгэн төрлийн тоглоом хүсдэг хэвээр байна.
Үйлдвэрлэлээр тоглох шаардлагагүй. Би юу ч хийхгүй байхыг хатуу зөвлөж байна, одоо бөөнөөрөө харж байгаа зүйл: "Өө, шинэ тоглоом!" Тэд үүнийг худалдаж авахаар гүйж очоод худалдаж аваад: "Одоо үүнийг сургуульд аваачиж, бүх найзууддаа үзүүлье." Ингэж болохгүй. Би хүлцэл өчье, хүүхдүүд маань дөнгөж том болж байна, хүүхдүүдээс байнга ямар нэг зүйлийг олж хардаг, өөрөөсөө анзаардаг, дараа нь бусдад ерөнхийлдөг.
Эцсийн хариулт нь: танд Кубернетес хэрэггүй. Та асуудлаа шийдэх хэрэгтэй.
Таны хүрч чадах зүйл бол:
- бүтээгдэхүүн унахгүй;
- тэр унах гэж оролдсон ч бид энэ тухай урьдчилан мэдэж, дотор нь ямар нэгэн зүйл хийж болно;
- Бид үүнийг бизнест шаардагдах хурдаар өөрчилж чадна, бид үүнийг хялбархан хийж чадна, энэ нь бидэнд ямар ч асуудал үүсгэхгүй.
Найдвартай байдал ба динамизм/уян хатан байдал гэсэн хоёр бодит хэрэгцээ бий. Дэлхийг хөнгөвчлөх зөөлөн, ямар ч төрлийн бизнес эрхэлдэг ямар нэгэн мэдээллийн технологийн төсөл хэрэгжүүлж байгаа, үүнийг ойлгодог хүн бүр эдгээр хэрэгцээг шийдвэрлэх хэрэгтэй. Зөв хандлага, зөв ойлголт, хангалттай туршлагатай Кубернетес нь тэдгээрийг шийдвэрлэх боломжийг танд олгоно.
Сервергүй тухай
- Хэрэв та ирээдүйгээ бага зэрэг харвал дэд бүтцийн хувьд толгой өвдөхгүй байх асуудлыг шийдэхийн тулд програмыг нэвтрүүлэх хурд, програмын өөрчлөлтийн хурдыг харгалзан үзэх юм бол сервергүй гэх мэт шинэ шийдлүүд гарч ирнэ. Та энэ чиглэлд ямар нэгэн боломж, Кубернетес болон үүнтэй төстэй шийдлүүдийн хувьд аюул байгааг мэдэрч байна уу?
Дмитрий: Энд бид цаашаа хараад, ийм байх болно гэж хэлдэг зөн билэгч биш гэдгийг дахин хэлэх хэрэгтэй байна! Хэдийгээр би яг ижил зүйлийг хийсэн. Би хөл рүүгээ хараад тэнд олон асуудал байгааг олж харлаа, жишээ нь компьютерт транзистор хэрхэн ажилладаг талаар. Инээдтэй байна, тийм үү? Бид CPU-ийн зарим алдаатай тулгарч байна.
Экосистемийн бүх асуудлыг шийдэж, сервергүйг нэлээд найдвартай, хямд, үр ашигтай, тохиромжтой болго. Энд би Элон Масктай санал нэг байна, хүн төрөлхтөнд алдаа дутагдлыг тэсвэрлэх чадварыг бий болгохын тулд хоёр дахь гариг хэрэгтэй. Хэдийгээр би түүний юу хэлж байгааг мэдэхгүй ч би өөрөө Ангараг руу нисэхэд бэлэн биш, маргааш ч ийм зүйл болохгүй гэдгийг ойлгож байна.
Сервергүй бол энэ нь хүн төрөлхтний алдааг тэсвэрлэх чадвар гэх мэт үзэл суртлын хувьд зөв зүйл болох нь тодорхой байна - хоёр гаригтай байх нь нэгээс дээр юм. Гэхдээ одоо яаж хийх вэ? Хэрэв та хүчин чармайлтаа төвлөрүүлбэл нэг экспедиц илгээх нь асуудал биш юм. Хэд хэдэн экспедиц явуулж, хэдэн мянган хүн суурьшуулах нь бас бодитой гэж бодож байна. Гэхдээ хүн төрөлхтний тэн хагас нь тэнд амьдрахын тулд үүнийг бүрэн гэм бурууг тэсвэрлэх чадвартай болгох нь надад одоо боломжгүй юм шиг санагдаж байна.
Сервергүй нэг нэгээр нь: энэ нь гайхалтай, гэхдээ 2019 оны асуудлаас хол байна. 2030 он дөхөж - үүнийг харахын тулд амьдарцгаая. Бид амьдарна гэдэгт эргэлзэхгүй байна, бид гарцаагүй амьдарна (унтахын өмнө давтана), гэхдээ одоо бусад асуудлыг шийдэх хэрэгтэй. Яг л үлгэрийн одой морины Солонгонд итгэх шиг. Тиймээ, тохиолдлын хоёр хувь нь шийдэгддэг, тэд төгс шийдэгддэг, гэхдээ субъектив байдлаар сервергүй бол солонго шиг ... Миний хувьд энэ сэдэв хэтэрхий хол, ойлгомжгүй байна. Би ярихад бэлэн биш байна. 2019 онд та сервергүй нэг програм бичих боломжгүй.
Кубернетес хэрхэн хөгжих вэ
— Биднийг энэхүү гайхалтай алс ирээдүй рүү чиглэн явахад Кубернетес болон түүний эргэн тойрон дахь экосистем хэрхэн хөгжинө гэж та бодож байна вэ?
Дмитрий: Би энэ талаар маш их бодсон бөгөөд надад тодорхой хариулт байна. Эхнийх нь статустай - эцэст нь харьяалалгүй байх нь илүү хялбар байдаг. Кубернетес эхлээд үүнд илүү их хөрөнгө оруулалт хийсэн, бүх зүйл үүнээс эхэлсэн. Харьяалалгүй хүмүүс Кубернетес дээр бараг төгс ажилладаг тул гомдоллох зүйл алга. Маш олон асуудал, эс тэгвээс нюансууд байсаар байна. Тэнд байгаа бүх зүйл аль хэдийн бидний хувьд сайн ажиллаж байна, гэхдээ энэ бол бид. Энэ нь хүн бүрт үйлчлэхийн тулд дор хаяж хэдэн жил шаардлагатай. Энэ бол тооцоолсон үзүүлэлт биш, харин миний толгойноос гарсан мэдрэмж юм.
Товчхондоо, манай бүх программууд статусыг хадгалдаг тул төрийн мэдээлэл нь маш хүчтэй хөгжих ёстой, мөн байх болно; харьяалалгүй програм байхгүй. Энэ бол хуурмаг зүйл, танд үргэлж ямар нэгэн мэдээллийн сан болон өөр зүйл хэрэгтэй. Statefull бол боломжтой бүх зүйлийг засах, бүх алдааг засах, одоо тулгараад байгаа бүх асуудлыг сайжруулах явдал юм - үүнийг үрчлэх гэж нэрлэе.
Үл мэдэгдэх түвшин, шийдэгдээгүй асуудлын түвшин, ямар нэгэн зүйлтэй тулгарах магадлалын түвшин мэдэгдэхүйц буурах болно. Энэ бол чухал түүх юм. Мөн операторууд - хялбар үйлчилгээ авахын тулд удирдлагын логикийн кодчилол, хяналтын логиктой холбоотой бүх зүйл: MySQL хялбар үйлчилгээ, RabbitMQ хялбар үйлчилгээ, Memcache хялбар үйлчилгээ - ерөнхийдөө эдгээр бүх бүрэлдэхүүн хэсгүүд нь бидний ажиллахад баталгаатай байх ёстой. хайрцаг. Энэ нь зүгээр л бидний мэдээллийн баазтай болох асуудлыг шийдэж байгаа боловч бид үүнийг удирдахыг хүсэхгүй байна, эсвэл бид Кубернетесийг хүсч байна, гэхдээ бид үүнийг удирдахыг хүсэхгүй байна.
Операторыг нэг хэлбэрээр хөгжүүлэх энэ түүх ойрын хоёр жилд чухал байх болно.
Ашиглахад хялбар байдал ихээхэн нэмэгдэх ёстой гэж би бодож байна - хайрцаг нь улам бүр хар өнгөтэй болж, илүү найдвартай, илүү энгийн товчлууруудтай болно.
Би нэг удаа 80-аад оны үед Исаак Азимовтой хийсэн хуучин ярилцлагыг YouTube дээр Saturday Night Live дээр сонссон - Ургант шиг нэвтрүүлэг, зөвхөн сонирхолтой. Тэд түүнээс компьютерийн ирээдүйн талаар асуув. Ирээдүй бол радио шиг энгийн байдалд байна гэж тэр хэлэв. Радио хүлээн авагч нь анхандаа нарийн төвөгтэй зүйл байсан. Долгионыг барихын тулд та бариулыг 15 минутын турш эргүүлж, шорлогоо эргүүлж, ерөнхийдөө бүх зүйл хэрхэн ажилладагийг мэдэж, радио долгион дамжуулах физикийг ойлгох хэрэгтэй. Үүний үр дүнд радиод ганцхан товчлуур үлдсэн байв.
Одоо 2019 онд ямар радио вэ? Машинд радио хүлээн авагч нь бүх долгион, станцуудын нэрийг олдог. Үйл явцын физик нь 100 жилийн хугацаанд өөрчлөгдөөгүй ч ашиглахад хялбар болсон. Одоо, зөвхөн одоо ч биш, 1980 онд Азимовтой ярилцлага өгөхөд бүгд радио ашигладаг байсан бөгөөд энэ нь хэрхэн ажилладаг талаар хэн ч боддоггүй байв. Энэ нь үргэлж ажилладаг байсан - энэ бол өгөгдсөн зүйл.
Дараа нь Азимов компьютертэй адилхан байх болно гэж хэлэв. хэрэглэхэд хялбар байдал нэмэгдэх болно. 1980 онд та компьютерийн товчлуур дарж сургах ёстой байсан бол ирээдүйд тийм биш байх болно.
Kubernetes болон дэд бүтцийн тусламжтайгаар ашиглахад хялбар байдал асар их нэмэгдэх болно гэж би мэдэрч байна. Энэ нь миний бодлоор илт харагдаж байна - энэ нь гадаргуу дээр байрладаг.
Инженерүүдтэй юу хийх вэ?
— Тэгвэл Кубернетесийг дэмждэг инженерүүд болон системийн администраторуудад юу тохиолдох вэ?
Дмитрий: 1С гарч ирсний дараа нягтлан бодогч юу болсон бэ? Ойролцоогоор ижил. Үүнээс өмнө тэд цаасан дээр тоолж байсан - одоо хөтөлбөрт орсон. Хөдөлмөрийн бүтээмж тушаалаар өссөн ч хөдөлмөр өөрөө алга болоогүй. Өмнө нь гэрлийн чийдэнг шураглахад 10 инженер шаардлагатай байсан бол одоо нэг нь хангалттай байх болно.
Програм хангамжийн хэмжээ, даалгаврын тоо шинэ DevOps гарч ирснээс илүү хурдацтай өсч, үр ашиг нь нэмэгдэж байна гэж надад санагдаж байна. Яг одоо зах зээлд тодорхой хомсдол байгаа бөгөөд энэ нь удаан үргэлжлэх болно. Хожим нь бүх зүйл хэвийн байдалдаа эргэн орох бөгөөд үүний үр дүнд ажлын үр ашиг нэмэгдэж, сервергүй болж, Kubernetes-д нейрон залгагдсан байх бөгөөд энэ нь бүх нөөцийг яг шаардлагатай хэмжээгээр сонгох бөгөөд ерөнхийдөө ажиллах болно. бүх зүйлийг өөрөө хийх ёстой, тэр хүн зүгээр л холдож, саад болохгүй.
Гэхдээ хэн нэгэн шийдвэр гаргах шаардлагатай хэвээр байх болно. Энэ хүний ур чадвар, мэргэшлийн түвшин өндөр гэдэг нь ойлгомжтой. Өнөө үед нягтлан бодох бүртгэлийн хэлтэст 10 ажилтан гар нь ядрахгүйн тулд ном хөтөлдөг байх шаардлагагүй. Энэ нь зүгээр л шаардлагагүй юм. Олон баримт бичгийг цахим баримт бичгийн удирдлагын системээр автоматаар сканнердаж, таньдаг. Нэг ухаалаг ерөнхий нягтлан бодогч хангалттай, аль хэдийн илүү ур чадвартай, сайн ойлголттой.
Ер нь бүх салбарт ингэж явах ёстой. Машины хувьд ч мөн адил: өмнө нь нэг машин механик, гурван жолоочтой ирдэг байсан. Өнөө үед машин жолоодох нь бид бүгдээрээ өдөр бүр оролцдог энгийн үйл явц юм. Машиныг төвөгтэй зүйл гэж хэн ч боддоггүй.
DevOps эсвэл системийн инженерчлэл арилахгүй - өндөр түвшний ажил, үр ашиг нэмэгдэх болно.
— Ажил үнэхээр өснө гэсэн сонирхолтой санааг би бас сонссон.
Дмитрий: Мэдээжийн хэрэг, зуун хувь! Учир нь бидний бичсэн програм хангамжийн хэмжээ байнга өссөөр байдаг. Програм хангамжийн тусламжтайгаар бидний шийдэж буй асуудлын тоо байнга нэмэгдэж байна. Ажлын хэмжээ нэмэгдэж байна. Одоо DevOps зах зээл маш их халсан байна. Үүнийг цалингийн хүлээлтээс харж болно. Сайхан утгаараа, нарийн ширийн зүйл ярихгүйгээр X-ийг хүсдэг багачууд, 1,5X-ийг хүсдэг дундчууд, 2Х-ыг хүсдэг ахмадууд байх ёстой. Одоо, хэрэв та Москвагийн DevOps цалингийн зах зээлийг харвал бага насныхан X-ээс 3X хүртэл, ахлах нь X-ээс 3X хүртэл хүсдэг.
Энэ нь ямар үнэтэй болохыг хэн ч мэдэхгүй. Цалингийн түвшинг таны итгэл үнэмшилээр хэмждэг - бүрэн галзуугийн газар, үнэнийг хэлэхэд аймаар хэт халсан зах зээл.
Мэдээжийн хэрэг, энэ байдал тун удахгүй өөрчлөгдөх болно - зарим ханасан байдал үүсэх ёстой. Програм хангамжийн хөгжүүлэлтийн хувьд энэ нь тийм биш юм - хэдийгээр хүн бүрт хөгжүүлэгч хэрэгтэй, сайн хөгжүүлэгч хэрэгтэй ч зах зээл хэн нь ямар үнэ цэнэтэй болохыг ойлгодог - энэ салбар суурьшсан. Өнөө үед DevOps-ийн хувьд тийм биш юм.
- Миний сонссоноор одоогийн системийн администратор нэг их санаа зовох хэрэггүй, харин ур чадвараа ахиулж, маргааш илүү их ажил хийх боловч илүү өндөр мэргэшсэн байх болно гэдэгт бэлтгэх цаг болсон гэж би дүгнэсэн.
Дмитрий: Зуун хувь. Ерөнхийдөө бид 2019 онд амьдарч байгаа бөгөөд амьдралын дүрэм бол: насан туршдаа суралцах - бид амьдралынхаа туршид суралцдаг. Одоо хүн бүр үүнийг аль хэдийн мэдэж, мэдэрч байгаа юм шиг надад санагдаж байна, гэхдээ энэ нь мэдэхэд хангалтгүй юм - та үүнийг хийх хэрэгтэй. Бид өдөр бүр өөрчлөгдөх ёстой. Үүнийг хийхгүй бол эрт орой хэзээ нэгэн цагт бид мэргэжлийнхээ хажуугаар хаягдах болно.
180 градусын огцом эргэлтэнд бэлэн байгаарай. Ямар нэг зүйл эрс өөрчлөгдөж, шинэ зүйл зохион бүтээгдсэн байхыг үгүйсгэхгүй - энэ нь тохиолддог. Хоп! - Тэгээд бид одоо өөрөөр ажиллаж байна. Үүнд бэлэн байж, санаа зовохгүй байх нь чухал. Маргааш миний хийж байгаа бүх зүйл шаардлагагүй болж хувирч магадгүй - юу ч биш, би бүх насаараа суралцсан бөгөөд өөр зүйл сурахад бэлэн байна. Энэ бол асуудал биш. Ажлын аюулгүй байдлаас айх шаардлагагүй, гэхдээ та байнга шинэ зүйл сурахад бэлэн байх хэрэгтэй.
Хүсэл болон сурталчилгааны минут
-Танд ямар нэгэн хүсэл бий юу?
Дмитрий: Тийм ээ, надад хэд хэдэн хүсэл байна.
Эхний болон худалдааны - бүртгүүлэх . Эрхэм уншигч та YouTube-д орж манай сувагт бүртгүүлээрэй. Сар орчмын дараа бид видео үйлчилгээг идэвхтэй өргөжүүлж эхлэх болно. Бид Кубернетесийн тухай нээлттэй, олон төрлийн боловсролын агуулгатай байх болно: практик зүйлээс эхлээд лаборатори, онолын гүн гүнзгий зүйлс, Кубернетесийг хэрхэн ашиглах талаар. зарчим, хэв маягийн түвшин.
Хоёр дахь худалдааны хүсэл - явах мөн бид тэднээр хооллодог тул оддыг тавь. Хэрэв та бидэнд од өгөхгүй бол бид идэх юмгүй болно. Яг л компьютер тоглоомын мана шиг. Бид ямар нэг зүйл хийдэг, хийдэг, хичээдэг, хэн нэгэн эдгээр нь аймшигтай унадаг дугуй гэж хэлдэг, хэн нэгэн нь бүх зүйл буруу байна гэж хэлдэг, гэхдээ бид үргэлжлүүлж, туйлын шударга ажилладаг. Асуудлыг харж, шийдвэрлэж, туршлагаа хуваалцдаг. Тиймээс бидэнд од өгөөч, энэ нь чамаас холдохгүй, харин бидэн дээр ирэх болно, учир нь бид тэднээр хооллодог.
Гуравдугаарт, чухал, арилжааны хүсэл байхаа больсон - үлгэрт итгэхээ боль. Та бол мэргэжлийн хүмүүс. DevOps бол маш ноцтой бөгөөд хариуцлагатай мэргэжил юм. Ажлын байранд тоглохоо боль. Үүнийг танд товшоод үзээрэй, та үүнийг ойлгох болно. Таныг эмнэлэгт ирэхэд эмч тан дээр туршилт хийж байна гэж төсөөлөөд үз дээ. Энэ нь хэн нэгнийг гомдоож магадгүй гэдгийг би ойлгож байна, гэхдээ магадгүй энэ нь таны тухай биш, харин өөр хэн нэгний тухай юм. Бусдад бас боль гэж хэлээрэй. Энэ нь бид бүгдийн амьдралыг үнэхээр сүйрүүлж байна - ихэнх хүмүүс үйл ажиллагаа, админ болон DevOps-ыг дахин ямар нэг зүйл эвдсэн залуус гэж үзэж эхэлдэг. Тоглох гэж яваад, ийм байна, ийм байна гэж хүйтэн сэтгэлээр хардаггүй байснаас энэ нь ихэвчлэн “эвдэрсэн”.
Энэ нь та туршилт хийх ёсгүй гэсэн үг биш юм. Бид туршилт хийх хэрэгтэй, бид өөрсдөө хийдэг. Үнэнийг хэлэхэд бид өөрсдөө заримдаа тоглоом тоглодог - энэ нь мэдээжийн хэрэг маш муу, гэхдээ бидний хувьд хүн төрөлхтөнд харь байдаггүй. 2019 оныг үйлдвэрлэлийн тоглоом биш, нухацтай, сайтар бодож боловсруулсан туршилтуудын жил болгон зарлацгаая. Тийм байх.
- Маш их баярлалаа!
Дмитрий: Виталий, цаг гарган ярилцлага өгсөнд баярлалаа. Эрхэм уншигчид, хэрэв та гэнэт ийм байдалд хүрсэн бол маш их баярлалаа. Бид танд дор хаяж хоёр санаа авчирсан гэж найдаж байна.
Ярилцлагадаа Дмитрий верфийн асуудлыг хөндсөн. Одоо энэ бол бараг бүх асуудлыг шийддэг бүх нийтийн Швейцарийн хутга юм. Гэхдээ үргэлж тийм байгаагүй. Асаалттай наадам дээр Дмитрий Столяров танд энэ хэрэгслийн талаар дэлгэрэнгүй ярих болно. тайланд бүх зүйл байх болно: Kubernetes-ийн асуудал, далд нюансууд, эдгээр бэрхшээлийг шийдвэрлэх сонголтууд, werf-ийн одоогийн хэрэгжилтийг нарийвчлан авч үзэх болно. 27-р сарын 28, XNUMX-нд бидэнтэй нэгдээрэй, бид төгс багаж хэрэгслийг бүтээх болно.
Эх сурвалж: www.habr.com