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