«Бұлтты жергілікті» немесе жай «бұлттық» қолданбалар бұлтты инфрақұрылымдарда жұмыс істеу үшін арнайы жасалған. Олар әдетте контейнерлерде оралған, өз кезегінде бұлттық платформа арқылы басқарылатын еркін байланысқан микросервистердің жиынтығы ретінде құрастырылады. Мұндай қолданбалар әдепкі бойынша істен шығуға дайын, яғни олар сенімді жұмыс істейді және инфрақұрылым деңгейіндегі елеулі ақаулар болған жағдайда да ауқымды болады. Монетаның екінші жағы - бұлт платформасы контейнерлік қосымшаларды автоматты түрде басқара алу үшін енгізетін шектеулер (келісімшарттар) жиынтығы.
Бұлтқа негізделген қолданбаларға көшудің қажеттілігі мен маңыздылығын толық түсінгенімен, көптеген ұйымдар әлі де неден бастау керектігін білмейді. Бұл мақалада біз контейнерлік қосымшаларды әзірлеу кезінде сақталса, бұлтты платформалардың әлеуетін іске асыруға және АТ-инфрақұрылымында елеулі ақаулар болған жағдайда да сенімді жұмыс істеуге және қосымшалардың масштабтауына қол жеткізуге мүмкіндік беретін бірқатар принциптерді қарастырамыз. деңгейі. Мұнда баяндалған принциптердің түпкі мақсаты - Kubernetes сияқты бұлттық платформалар арқылы автоматты түрде басқарылатын қолданбаларды жасауды үйрену.
Бағдарламалық қамтамасыз етуді жобалау принциптері
Бағдарламалау әлемінде принциптер бағдарламалық жасақтаманы әзірлеу кезінде сақталуы керек жалпы ережелерге сілтеме жасайды. Оларды кез келген программалау тілімен жұмыс істегенде пайдалануға болады. Әрбір принциптің өз мақсаттары бар, оған жету құралдары әдетте үлгілер мен тәжірибелер болып табылады. Сондай-ақ жоғары сапалы бағдарламалық жасақтаманы жасаудың бірқатар іргелі принциптері бар, олардан басқалардың бәрі шығады. Мұнда негізгі принциптердің кейбір мысалдары берілген:
- (Қарапайым, ақымақ болсын) – оны қиындатпа;
- (Don not again) – өзіңізді қайталамау;
- (Сізге бұл қажет емес) - бірден қажет емес нәрсені жасамаңыз;
- Мәселелерді бөлу – жауапкершілікті бөлісу.
Көріп отырғаныңыздай, бұл принциптер ешқандай нақты ережелерді белгілемейді, бірақ көптеген әзірлеушілер бөлісетін және олар үнемі сілтеме жасайтын практикалық тәжірибеге негізделген жалпы мағыналы ойлар деп аталатын санатқа жатады.
Сонымен қатар, бар – Роберт Мартин тұжырымдаған объектілі-бағытталған бағдарламалау мен дизайнның алғашқы бес қағидасының жиынтығы. 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) хабарларын және оның тоқтату тәртібін мүмкіндігінше тез бастау керек: өлтіру (SIGKILL).
Сонымен қатар, PostStart және PreStop сияқты оқиғалар қолданбаның өмірлік циклі үшін маңызды болуы мүмкін. Мысалы, қолданбаны іске қосқаннан кейін ол сұрауларға жауап беру үшін біраз қыздыру уақытын қажет етуі мүмкін. Немесе қолданба өшірілген кезде ресурстарды қандай да бір ерекше жолмен босатуы керек.
Суреттің өзгермейтіндігі принципі (IIP)
Контейнерленген қолданбалар әртүрлі орталарда іске қосылса да, құрастырылғаннан кейін өзгеріссіз қалуы жалпы қабылданған. Бұл орындалу уақытында деректерді сақтауды сыртқа шығару (басқаша айтқанда, бұл үшін сыртқы құралдарды пайдалану) және әрбір орта үшін бірегей контейнерлерді өзгерту немесе жасау емес, сыртқы, орындау уақытына тән конфигурацияларға сүйену қажеттілігін қажет етеді. Қолданбаға кез келген өзгертулерден кейін контейнер кескіні қайта құрылып, пайдаланылатын барлық орталарға орналастырылуы керек. Айтпақшы, АТ жүйелерін басқару кезінде серверлер мен инфрақұрылымның өзгермейтіндігі принципі ретінде белгілі ұқсас принцип қолданылады.
IIP мақсаты әртүрлі орындалу орталары үшін бөлек контейнер кескіндерін жасауды болдырмау және бірдей кескінді барлық жерде сәйкес ортаға тән конфигурациямен бірге пайдалану болып табылады. Бұл принципті ұстану бұлтты жүйелерді автоматтандыру тұрғысынан қолданбаларды жаңартуды кері қайтару және алға жылжыту сияқты маңызды тәжірибелерді жүзеге асыруға мүмкіндік береді.
Процесті бір рет пайдалану принципі (PDP)
Контейнердің ең маңызды сипаттамаларының бірі оның уақытшалығы: контейнер данасын жасау оңай және жою оңай, сондықтан оны кез келген уақытта басқа данамен оңай ауыстыруға болады. Мұндай ауыстырудың көптеген себептері болуы мүмкін: жұмысқа қабілеттілік сынағының сәтсіздігі, қолданбаны масштабтау, басқа хостқа жіберу, платформа ресурстарының таусылуы немесе басқа жағдайлар.
Нәтижесінде, контейнерлік қолданбалар кейбір сыртқы құралдарды пайдалана отырып, өз күйін сақтауы керек немесе бұл үшін артықшылығы бар ішкі бөлінген схемаларды пайдалануы керек. Сонымен қатар, қолданба тез басталып, тез жабылуы керек және кенеттен өлімге әкелетін аппараттық ақауларға дайын болуы керек.
Бұл принципті жүзеге асыруға көмектесетін тәжірибелердің бірі - контейнерлерді кішкентай ұстау. Бұлтты орталар контейнер данасын іске қосу үшін хостты автоматты түрде таңдай алады, сондықтан контейнер неғұрлым кішірек болса, соғұрлым ол тезірек іске қосылады - ол жай ғана желі арқылы мақсатты хостқа жылдамырақ көшіріледі.
Өзін-өзі ұстау принципі (S-CP)
Осы принципке сәйкес, құрастыру кезеңінде барлық қажетті компоненттер контейнерге кіреді. Контейнер жүйеде тек таза Linux ядросы бар деген болжамға негізделуі керек, сондықтан барлық қажетті қосымша кітапханалар контейнердің өзінде орналастырылуы керек. Ол сондай-ақ сәйкес бағдарламалау тіліне арналған орындалу уақыты, қолданба платформасы (қажет болса) және контейнер қолданбасы іске қосылған кезде қажет болатын басқа тәуелділіктер сияқты нәрселерді қамтуы керек.
Ерекшеліктер ортадан ортаға өзгеретін конфигурациялар үшін жасалады және орындау уақытында қамтамасыз етілуі керек, мысалы, Kubernetes ConfigMap арқылы.
Бағдарлама бірнеше контейнерлік құрамдастарды қамтуы мүмкін, мысалы, контейнерленген веб-бағдарламадағы бөлек ДҚБЖ контейнері. S-CP принципіне сәйкес, бұл контейнерлер бір жерге біріктірілмеуі керек, бірақ ДҚБЖ контейнерінде деректер қорының жұмыс істеуі үшін қажет нәрсенің барлығын қамтитындай етіп жасалуы керек, ал веб-қосымшалар контейнерінде вебтің жұмыс істеуі үшін қажеттінің бәрі бар. қолданба, сол веб-сервер . Нәтижесінде, орындалу уақытында веб-бағдарлама контейнері ДҚБЖ контейнеріне тәуелді болады және қажет болған жағдайда оған қол жеткізе алады.
Орындау уақытын шектеу принципі (RCP)
S-CP принципі контейнерді қалай құрастыру керектігін және екілік кескінде не болуы керектігін анықтайды. Бірақ контейнер тек бір ғана сипаттамасы бар «қара жәшік» емес - файл өлшемі. Орындау кезінде контейнер басқа өлшемдерді қабылдайды: пайдаланылған жад көлемі, процессор уақыты және басқа жүйелік ресурстар.
Және бұл жерде RCP принципі ыңғайлы, оған сәйкес контейнер жүйелік ресурстарға қойылатын талаптарын ажыратып, оларды платформаға жіберуі керек. Әрбір контейнердің ресурс профильдерімен (оған қанша CPU, жад, желі және диск ресурстары қажет) платформа жоспарлау мен автомасштабтауды оңтайлы орындай алады, АТ сыйымдылығын басқара алады және контейнерлер үшін SLA деңгейлерін сақтай алады.
Контейнердің ресурс талаптарын қанағаттандырумен қатар, қолданбаның өз шекарасынан шықпауы да маңызды. Әйтпесе, ресурс тапшылығы орын алған кезде, платформа оны тоқтатылуы немесе тасымалдануы қажет қолданбалар тізіміне қосуы ықтимал.
Біріншіден бұлт болу туралы айтқанда, біз жұмыс істеу тәсілі туралы айтамыз.
Жоғарыда біз бұлтты орталар үшін жоғары сапалы контейнерлік қосымшаларды құрудың әдістемелік негізін белгілейтін бірқатар жалпы принциптерді тұжырымдадық.
Назар аударыңыз, бұл жалпы принциптерден басқа, сізге контейнерлермен жұмыс істеудің қосымша жетілдірілген әдістері мен әдістері де қажет болады. Сонымен қатар, бізде нақтырақ және жағдайға байланысты қолданылуы (немесе қолданбауы) қажет бірнеше қысқа ұсыныстар бар:
- Суреттердің өлшемін азайтуға тырысыңыз: уақытша файлдарды жойыңыз және қажет емес пакеттерді орнатпаңыз - контейнер өлшемі неғұрлым аз болса, ол соғұрлым тезірек жиналып, желі арқылы мақсатты хостқа көшіріледі.
- Ерікті пайдаланушы идентификаторларына назар аударыңыз: контейнерлерді іске қосу үшін sudo пәрменін немесе кез келген арнайы пайдаланушы идентификаторын пайдаланбаңыз.
- Маңызды порттарды белгілеу: порт нөмірлерін орындау уақытында орнатуға болады, бірақ оларды EXPOSE пәрменін пайдаланып көрсеткен дұрыс – бұл басқа адамдар мен бағдарламалардың суреттеріңізді пайдалануын жеңілдетеді.
- Тұрақты деректерді томдарда сақтау: Контейнер жойылғаннан кейін қалуы керек деректер томдарға жазылуы керек.
- Кескіннің метадеректерін жазыңыз: тегтер, белгілер және аннотациялар кескіндерді пайдалануды жеңілдетеді - басқа әзірлеушілер сізге алғыс білдіреді.
- Хост пен кескіндерді синхрондау: Кейбір контейнерлік қолданбалар контейнерді уақыт немесе машина идентификаторы сияқты белгілі бір атрибуттар бойынша хостпен синхрондауды талап етеді.
- Қорытындылай келе, жоғарыда аталған қағидаларды тиімдірек жүзеге асыруға көмектесетін үлгілер мен озық тәжірибелермен бөлісеміз:
11 маусым сағат 11.00
Нені үйренесіз:
- Өзгермейтін Red Hat Enterprise Linux CoreOS
- OpenShift қызмет көрсету торы
- Оператор шеңбері
- Кнативті шеңбер
Ақпарат көзі: www.habr.com