"Үүлэн" эсвэл зүгээр л "үүл" програмууд нь үүлэн дэд бүтцэд ажиллахаар тусгайлан бүтээгдсэн. Тэдгээрийг ихэвчлэн саванд хийж, үүлэн платформоор удирддаг, салангид холбогдсон микро үйлчилгээний багц хэлбэрээр бүтээдэг. Ийм програмууд нь анхдагчаар бүтэлгүйтэлд бэлтгэгдсэн байдаг бөгөөд энэ нь дэд бүтцийн түвшний ноцтой доголдол гарсан ч найдвартай ажиллаж, цар хүрээг хамардаг гэсэн үг юм. Зоосны нөгөө тал нь үүл платформ нь контейнер програмуудыг автоматаар удирдах боломжтой болгохын тулд тавьдаг хязгаарлалтуудын багц (гэрээ) юм.
Үүлэн дээр суурилсан програм руу шилжих хэрэгцээ, ач холбогдлыг бүрэн мэддэг ч олон байгууллага хаанаас эхлэхээ мэдэхгүй хэвээр байна. Энэ нийтлэлд бид чингэлэгтэй програмуудыг боловсруулахдаа дагаж мөрдвөл үүлэн платформуудын боломжуудыг ухамсарлаж, мэдээллийн технологийн дэд бүтцэд ноцтой доголдол гарсан ч найдвартай ажиллагаа, хэрэглээний цар хүрээг нэмэгдүүлэх боломжийг олгох хэд хэдэн зарчмуудыг авч үзэх болно. түвшин. Энд дурдсан зарчмуудын эцсийн зорилго нь Kubernetes зэрэг үүлэн платформоор автоматаар удирдаж болох програмуудыг хэрхэн бүтээх талаар сурах явдал юм.
Програм хангамжийн дизайны зарчим
Програмчлалын ертөнцөд зарчмууд нь програм хангамжийг боловсруулахдаа дагаж мөрдөх ёстой ерөнхий дүрмийг хэлдэг. Тэдгээрийг ямар ч програмчлалын хэлтэй ажиллахад ашиглаж болно. Зарчим бүр өөрийн гэсэн зорилготой байдаг бөгөөд үүнд хүрэх арга хэрэгсэл нь ихэвчлэн загвар, практик байдаг. Өндөр чанартай програм хангамжийг бий болгох хэд хэдэн үндсэн зарчмууд байдаг бөгөөд эдгээрээс бусад бүх зүйл гардаг. Үндсэн зарчмуудын зарим жишээ энд байна:
- (Энгийн, тэнэг байгаарай) - үүнийг бүү хүндрүүл;
- (Өөрийгөө бүү давт) - өөрийгөө бүү давт;
- (Танд хэрэггүй болно) - нэн даруй шаардлагагүй зүйлийг бүү бүтээ;
- Асуудлыг салгах - үүрэг хариуцлагаа хуваалцах.
Таны харж байгаагаар эдгээр зарчмууд нь ямар нэгэн тодорхой дүрмийг тогтоодоггүй, гэхдээ олон хөгжүүлэгчдийн хуваалцдаг, байнга дурддаг практик туршлага дээр үндэслэсэн нийтлэг ойлголтуудын ангилалд багтдаг.
Үүнээс гадна байдаг – Роберт Мартины томъёолсон объект хандалтат програмчлал, дизайны эхний таван зарчмын багц. SOLID нь өргөн хүрээтэй, нээлттэй, нэмэлт зарчмуудыг багтаасан бөгөөд тэдгээрийг хамтад нь хэрэглэвэл илүү сайн програм хангамжийн системийг бий болгож, тэдгээрийг урт хугацаанд илүү сайн хадгалахад тусалдаг.
SOLID зарчмууд нь OOP-ийн талбарт хамаарах бөгөөд анги, интерфейс, удамшил гэх мэт ойлголт, ойлголтын хэлээр томъёолсон болно. Үүнтэй адилтгаж, үүлэн програмуудад зориулж хөгжлийн зарчмуудыг томъёолж болох бөгөөд энд зөвхөн үндсэн элемент нь анги биш, харин сав байх болно. Эдгээр зарчмуудыг дагаснаар та Kubernetes гэх мэт үүлэн платформуудын зорилго, зорилтод илүү нийцэх савласан програмуудыг үүсгэж болно.
Үүлэнд суурилсан савнууд: Улаан малгайт арга
Өнөөдөр бараг ямар ч програмыг харьцангуй хялбар саванд хийж болно. Гэхдээ Кубернетес шиг үүлэн платформ дээр програмуудыг үр дүнтэй автоматжуулж, зохион байгуулахын тулд нэмэлт хүчин чармайлт шаардагдана.
Доор дурдсан санаануудын үндэс нь арга зүй байв эх кодын менежментээс эхлээд масштабын загвар хүртэл вэб програмуудыг бүтээх янз бүрийн чиглэлээр ажилладаг бусад олон ажил. Тайлбарласан зарчмууд нь зөвхөн бичил үйлчилгээн дээр бүтээгдсэн, Kubernetes гэх мэт үүлэн платформд зориулагдсан контейнержүүлсэн програмуудыг хөгжүүлэхэд хамаарна. Бидний хэлэлцүүлгийн үндсэн элемент бол контейнерийн зураг бөгөөд зорилтот контейнер ажиллах хугацаа нь контейнер зохион байгуулах платформ юм. Санал болгож буй зарчмуудын зорилго нь ихэнх зохион байгуулалтын платформ дээр хуваарь гаргах, масштаблах, хянах ажлыг автоматжуулах боломжтой контейнеруудыг бий болгох явдал юм. Зарчмуудыг тодорхой дарааллаар оруулаагүй болно.
Ганц санаа тавих зарчим (SCP)
Энэ зарчим нь Ганц хариуцлагын зарчимтай олон талаараа төстэй. ) нь SOLID багцын нэг хэсэг бөгөөд объект бүр нэг үүрэг хариуцлагатай байх ёстой бөгөөд энэ хариуцлагыг ангид бүрэн багтаасан байх ёстой. SRP-ийн санаа нь хариуцлага бүр нь өөрчлөлтийн шалтгаан бөгөөд ангид өөрчлөлт хийх цорын ганц шалтгаан байх ёстой.
SCP-д бид OOP ангитай харьцуулахад савны хийсвэрлэлийн өндөр түвшин, илүү өргөн зорилгыг илэрхийлэхийн тулд "хариуцлага" гэсэн үгийн оронд "санаа тавих" гэсэн үгийг ашигладаг. Хэрэв SRP-ийн зорилго нь өөрчлөлт хийх цорын ганц шалтгаантай бол SCP-ийн ард савыг дахин ашиглах, солих боломжийг өргөжүүлэх хүсэл байдаг. SRP-г дагаж, нэг асуудлыг шийдэж, бүрэн гүйцэд хийдэг контейнер үүсгэснээр та уг контейнерийн дүрсийг өөр өөр хэрэглээний нөхцөлд дахин ашиглах боломжийг нэмэгдүүлэх болно.
SCP зарчим нь сав бүр нэг асуудлыг шийдэж, сайн хийх ёстой гэж заасан байдаг. Түүгээр ч барахгүй, чингэлэг ертөнц дэх SCP нь OOP ертөнц дэх SRP-ээс илүү хялбар байдаг, учир нь чингэлэг нь ихэвчлэн нэг процессыг явуулдаг бөгөөд ихэнх тохиолдолд энэ процесс нь нэг ажлыг шийддэг.
Хэрэв чингэлэгийн микро үйлчилгээ нь хэд хэдэн асуудлыг нэг дор шийдэх ёстой бол түүнийг нэг үүрэгт контейнер болгон хувааж, хажуугийн тэрэг болон init контейнер загваруудыг ашиглан нэг pod (чингэлэгийн платформ байршуулах нэгж) дотор нэгтгэж болно. Нэмж дурдахад, SCP нь хуучин контейнерийг (вэб сервер эсвэл мессеж брокер гэх мэт) ижил асуудлыг шийддэг боловч өргөтгөсөн функцтэй эсвэл илүү сайн масштабтай шинэ контейнерээр солиход хялбар болгодог.
Ажиглалтын өндөр зарчим (HOP)
Контейнеруудыг программыг багцлах, ажиллуулах нэгдсэн арга болгон ашиглах үед програмууд нь өөрөө хар хайрцаг мэт харагдана. Гэсэн хэдий ч хэрэв эдгээр нь үүл контейнер юм бол тэдгээр нь савны эрүүл мэндийг хянах, шаардлагатай бол зохих арга хэмжээ авахын тулд ажиллах хугацаандаа тусгай API-уудыг өгөх ёстой. Үүнгүйгээр савыг шинэчлэх, тэдгээрийн амьдралын мөчлөгийг удирдах автоматжуулалтыг нэгтгэх боломжгүй бөгөөд энэ нь эргээд програм хангамжийн системийн тогтвортой байдал, ашиглалтыг улам дордуулна.
Практикт, чингэлэгт суулгасан програм нь хамгийн багадаа янз бүрийн төрлийн эрүүл мэндийн үзлэгт зориулсан API-тай байх ёстой: амьд байдлын тест, бэлэн байдлын тест. Хэрэв програм илүү ихийг хийх гэж байгаа бол түүний төлөв байдлыг хянах өөр хэрэгслээр хангах ёстой. Жишээлбэл, Fluentd, Logstash болон бусад ижил төстэй хэрэгслүүдийг ашиглан бүртгэлийг нэгтгэхийн тулд STDERR болон STDOUT-ээр дамжуулан чухал үйл явдлуудыг бүртгэх. Мөн OpenTracing, Prometheus гэх мэт мөшгих, хэмжүүр цуглуулах сангуудтай нэгтгэх.
Ерөнхийдөө програмыг хар хайрцаг гэж үзэж болох боловч үүнийг хамгийн сайн аргаар хянаж, удирдахын тулд платформд шаардлагатай бүх API-уудаар хангагдсан байх ёстой.
Амьдралын мөчлөгийн нийцлийн зарчим (LCP)
LCP бол HOP-ийн эсрэг заалт юм. HOP нь уг контейнер нь платформд унших боломжтой API-г өгөх ёстой гэж заасан бол LCP нь програмыг платформоос мэдээлэл хүлээн авах чадвартай байхыг шаарддаг. Түүнээс гадна, сав нь зөвхөн үйл явдлыг хүлээн авахаас гадна дасан зохицох, өөрөөр хэлбэл тэдэнд хариу үйлдэл үзүүлэх ёстой. Тиймээс платформыг бичих API-ээр хангах шаардлага гэж үзэж болох зарчмын нэр.
Платформууд нь савны амьдралын мөчлөгийг удирдахад туслах янз бүрийн төрлийн үйл явдлуудтай байдаг. Гэхдээ тэдний алийг нь хүлээж авах, хэрхэн хариу үйлдэл үзүүлэх нь тухайн программаас өөрөөс нь шалтгаална.
Зарим үйл явдал бусдаасаа илүү чухал болох нь тодорхой. Жишээлбэл, хэрэв програм эвдрэлийг тэсвэрлэдэггүй бол энэ нь дохиог хүлээн авах ёстой: дуусгах (SIGTERM) мессежийг хүлээн авч, SIGTERM-ийн дараа ирдэг: kill (SIGKILL) дохиог барьж авахын тулд дуусгах горимыг аль болох хурдан эхлүүлэх хэрэгтэй.
Нэмж дурдахад PostStart, PreStop зэрэг үйл явдлууд нь програмын амьдралын мөчлөгт чухал үүрэг гүйцэтгэдэг. Жишээлбэл, програмыг ажиллуулсны дараа хүсэлтэд хариу өгөхөөс өмнө бага зэрэг халаах шаардлагатай байж магадгүй юм. Эсвэл програм унтрах үед нөөцийг ямар нэгэн тусгай аргаар гаргах ёстой.
Зургийн хувиршгүй зарчим (IIP)
Контейнерт хадгалагдсан програмууд нь өөр өөр орчинд ажиллаж байсан ч бүтээгдсэний дараа өөрчлөгдөхгүй байх ёстой гэдгийг ерөнхийд нь хүлээн зөвшөөрдөг. Энэ нь ажиллах үед өгөгдлийн хадгалалтыг гадагшлуулах (өөрөөр хэлбэл, үүнд зориулж гадны хэрэгслийг ашиглах) шаардлагатай бөгөөд орчин бүрт өвөрмөц савыг өөрчлөх, үүсгэхээс илүүтэйгээр гадаад, ажиллах цагийн тусгай тохиргоонд найдах шаардлагатай болдог. Аппликешнд ямар нэгэн өөрчлөлт хийсний дараа контейнерийн дүрсийг дахин бүтээж, ашигласан бүх орчинд байрлуулах ёстой. Дашрамд хэлэхэд, мэдээллийн технологийн системийг удирдахдаа ижил төстэй зарчмыг ашигладаг бөгөөд үүнийг серверүүд болон дэд бүтцийн өөрчлөлтгүй байх зарчим гэж нэрлэдэг.
IIP-ийн зорилго нь өөр өөр ажлын орчинд зориулж тусдаа контейнер дүрс үүсгэхээс сэргийлж, ижил дүрсийг хүрээлэн буй орчинд тохирсон тохиргооны хамт хаа сайгүй ашиглах явдал юм. Энэхүү зарчмыг дагаж мөрдөх нь үүлэн системийг автоматжуулах үүднээс програмын шинэчлэлтийг буцаах, урагшлуулах зэрэг чухал туршлагуудыг хэрэгжүүлэх боломжийг танд олгоно.
Процессын нэг удаагийн хэрэглээний зарчим (PDP)
Савны хамгийн чухал шинж чанаруудын нэг нь түүний түр зуурын шинж чанар юм: чингэлэгийн жишээг үүсгэхэд хялбар бөгөөд устгахад хялбар байдаг тул түүнийг ямар ч үед өөр жишээгээр хялбархан сольж болно. Ийм солих олон шалтгаан байж болно: үйлчилгээний чадварын шалгалт амжилтгүй болох, програмыг өргөжүүлэх, өөр хост руу шилжүүлэх, платформын нөөц шавхагдах эсвэл бусад нөхцөл байдал.
Үүний үр дүнд контейнержүүлсэн програмууд нь зарим гадаад арга хэрэгслийг ашиглан төлөвөө хадгалах эсвэл үүний тулд илүүдэлтэй дотоод тархсан схемүүдийг ашиглах ёстой. Нэмж дурдахад, програм хурдан эхэлж, хурдан унтрах ёстой бөгөөд тоног төхөөрөмжийн гэнэтийн үхэлд бэлэн байх ёстой.
Энэ зарчмыг хэрэгжүүлэхэд тусалдаг нэг арга бол савыг жижиг байлгах явдал юм. Үүлэн орчин нь контейнерийн жишээг эхлүүлэхийн тулд хостыг автоматаар сонгох боломжтой тул контейнер бага байх тусам хурдан эхлэх болно - энэ нь зүгээр л сүлжээгээр зорилтот хост руу хуулах болно.
Өөрийгөө барих зарчим (S-CP)
Энэ зарчмын дагуу угсралтын үе шатанд шаардлагатай бүх бүрэлдэхүүн хэсгүүдийг саванд хийнэ. Систем нь зөвхөн цэвэр Линукс цөмтэй гэсэн таамаглал дээр тулгуурлан уг контейнер баригдсан байх ёстой тул шаардлагатай бүх нэмэлт сангуудыг контейнерт өөрөө байрлуулах ёстой. Энэ нь мөн харгалзах програмчлалын хэлний ажиллах хугацаа, хэрэглээний платформ (шаардлагатай бол) болон контейнер програм ажиллаж байх үед шаардагдах бусад хамаарлыг агуулсан байх ёстой.
Орчноос хамаарч өөр өөр тохиргоонд үл хамаарах зүйлүүд хийгдсэн бөгөөд ажиллах үед, жишээ нь Kubernetes ConfigMap-ээр дамжуулан хангагдсан байх ёстой.
Аппликейшн нь хэд хэдэн контейнержсэн бүрэлдэхүүн хэсгүүдийг агуулж болно, тухайлбал, контейнержүүлсэн вэб програм доторх тусдаа DBMS контейнер. S-CP зарчмын дагуу эдгээр контейнеруудыг нэг дор нэгтгэх ёсгүй, харин DBMS контейнер нь мэдээллийн сангийн үйл ажиллагаанд шаардлагатай бүх зүйлийг агуулсан байх ёстой бөгөөд вэб програмын контейнер нь вэбийг ажиллуулахад шаардлагатай бүх зүйлийг агуулсан байх ёстой. програм, ижил вэб сервер . Үүний үр дүнд, ажиллах үед вэб програмын контейнер нь DBMS контейнерээс хамаарах бөгөөд шаардлагатай үед хандах болно.
Ажиллах цагийг хязгаарлах зарчим (RCP)
S-CP зарчим нь савыг хэрхэн барих, хоёртын дүрст юу агуулагдах ёстойг тодорхойлдог. Гэхдээ сав нь зөвхөн нэг шинж чанартай байдаг "хар хайрцаг" биш юм - файлын хэмжээ. Гүйцэтгэлийн явцад контейнер нь бусад хэмжигдэхүүнийг авдаг: ашигласан санах ойн хэмжээ, CPU-ийн хугацаа болон бусад системийн нөөц.
Энд RCP зарчим хэрэг болно, үүний дагуу контейнер нь системийн нөөцөд тавигдах шаардлагыг тасалж, платформ руу шилжүүлэх ёстой. Контейнер бүрийн нөөцийн профайлаар (түүнд хэр их CPU, санах ой, сүлжээ, дискний нөөц хэрэгтэй) платформ нь хуваарь болон автомат масштабыг оновчтой гүйцэтгэж, мэдээллийн технологийн багтаамжийг удирдаж, контейнерийн SLA түвшинг хадгалах боломжтой.
Аппликейшн нь савны нөөцийн шаардлагыг хангахаас гадна өөрийн хил хязгаараас хэтрэхгүй байх нь чухал юм. Үгүй бол нөөцийн хомсдол үүсэх үед платформ нь үүнийг цуцлах эсвэл шилжүүлэх шаардлагатай програмуудын жагсаалтад оруулах магадлал өндөр байдаг.
Бид үүлэнд хамгийн түрүүнд байх тухай ярихдаа бид ажлын арга барилаа ярьдаг.
Дээр бид үүлэн орчинд зориулсан өндөр чанартай контейнер програмуудыг бий болгох арга зүйн үндэс суурийг тавьсан хэд хэдэн ерөнхий зарчмуудыг томъёолсон.
Эдгээр ерөнхий зарчмуудаас гадна танд савтай ажиллах нэмэлт дэвшилтэт арга, техник хэрэгтэй болно гэдгийг анхаарна уу. Нэмж дурдахад, нөхцөл байдлаас шалтгаалан хэрэглэх (эсвэл хэрэглэхгүй байх) илүү тодорхой, цөөн хэдэн богино зөвлөмжүүд бидэнд байна:
- Зургийн хэмжээг багасгахыг хичээгээрэй: түр зуурын файлуудыг устгаж, шаардлагагүй багцуудыг бүү суулгаарай - савны хэмжээ бага байх тусам түүнийг хурдан угсарч, сүлжээгээр зорилтот хост руу хуулах болно.
- Дурын хэрэглэгчийн ID-д анхаарлаа хандуулаарай: Контейнерээ ажиллуулахдаа sudo команд эсвэл ямар нэгэн тусгай хэрэглэгчийн нэрийг бүү ашигла.
- Чухал портуудыг тэмдэглэх: Та портын дугаарыг ажиллах үед тохируулж болно, гэхдээ EXPOSE командыг ашиглан тэдгээрийг зааж өгөх нь илүү дээр юм - энэ нь бусад хүмүүс болон програмуудад таны зургийг ашиглахад хялбар болгоно.
- Тогтвортой өгөгдлийг эзлэхүүн дээр хадгалах: Савыг устгасны дараа үлдэх өгөгдлийг боть болгон бичих ёстой.
- Зургийн мета өгөгдлийг бичих: шошго, шошго, тэмдэглэгээ нь зургийг ашиглахад хялбар болгодог - бусад хөгжүүлэгчид танд талархах болно.
- Хост болон зургийг синхрончлох: Зарим чингэлэгжүүлсэн програмууд нь цаг эсвэл машины ID гэх мэт тодорхой шинж чанарууд дээр контейнерийг хосттой синк хийхийг шаарддаг.
- Эцэст нь хэлэхэд, бид танд дээр дурдсан зарчмуудыг илүү үр дүнтэй хэрэгжүүлэхэд туслах загварууд болон шилдэг туршлагуудыг хуваалцаж байна:
11-р сарын 11.00-ны XNUMX цагт
Та юу сурах вэ:
- Үл хувиршгүй Red Hat Enterprise Linux CoreOS
- OpenShift үйлчилгээний тор
- Операторын хүрээ
- Төрөлхийн хүрээ
Эх сурвалж: www.habr.com