Бәріңе сәлем! Менің атым Павел Агалетский. Мен Lamoda жеткізу жүйесін әзірлейтін командада топ жетекшісі ретінде жұмыс істеймін. 2018 жылы мен HighLoad++ конференциясында сөз сөйледім, бүгін мен баяндамамның стенограммасын ұсынғым келеді.

Менің тақырыбым әртүрлі орталарға жүйелер мен қызметтерді орналастырудағы біздің компанияның тәжірибесіне арналған. Біздің тарихқа дейінгі дәуірден бастап, біз барлық жүйелерді қарапайым виртуалды серверлерге орналастырған кезден бастап, Номадтан Кубернетесте орналастыруға біртіндеп көшумен аяқталды. Мен мұны не үшін жасағанымызды және бұл процесте қандай қиындықтарға тап болғанымызды айтамын.

Қолданбаларды VM жүйесіне орналастыру

3 жыл бұрын компанияның барлық жүйелері мен қызметтері кәдімгі виртуалды серверлерге орналастырылғанынан бастайық. Техникалық тұрғыдан алғанда, ол біздің жүйелеріміздің барлық коды Дженкинс көмегімен автоматты құрастыру құралдары арқылы сақталатын және жиналатын етіп ұйымдастырылған. Ansible көмегімен ол біздің нұсқаларды басқару жүйемізден виртуалды серверлерге шығарылды. Сонымен қатар, біздің компанияда болған әрбір жүйе кем дегенде 2 серверге орналастырылды: олардың біреуі басында, екіншісі құйрықта. Бұл екі жүйе барлық параметрлері, қуаты, конфигурациялары және т.б. бойынша бір-біріне мүлдем ұқсас болды. Олардың арасындағы жалғыз айырмашылық басты пайдаланушы трафигін алды, ал tail ешқашан пайдаланушы трафигін алмады.

Бұл не үшін жасалды?

Қолданбамыздың жаңа шығарылымдарын орналастырған кезде, пайдаланушылар үшін елеулі салдарларсыз үздіксіз шығуды қамтамасыз еткіміз келді. Бұған Ansible көмегімен келесі құрастырылған шығарылымның соңына дейін шығарылуына байланысты қол жеткізілді. Онда орналастыруға қатысқан адамдар бәрі жақсы екенін тексеріп, көз жеткізе алады: барлық көрсеткіштер, бөлімдер және қолданбалар жұмыс істеп тұр; қажетті сценарийлер іске қосылды. Барлығы жақсы екеніне көз жеткізгеннен кейін ғана қозғалыс ауыстырылды. Ол бұрын қалдырылған серверге бара бастады. Ал бұрын жетекші болған адам қолданушы трафигісіз қалды, бірақ біздің қосымшамыздың алдыңғы нұсқасы әлі де бар.

Сондықтан ол пайдаланушылар үшін қиындықсыз болды. Өйткені коммутация лезде болады, өйткені ол жай ғана балансизаторды ауыстырады. Теңгерімді кері ауыстыру арқылы алдыңғы нұсқаға өте оңай оралуға болады. Сондай-ақ біз қолданбаның пайдаланушы трафигін алғанға дейін өндіруге қабілетті екенін тексере аламыз, бұл өте ыңғайлы болды.

Осының бәрінде біз қандай артықшылықтарды көрдік?

1. Біріншіден, бұл жеткілікті бұл жай ғана жұмыс істейді. Мұндай орналастыру схемасы қалай жұмыс істейтінін бәрі түсінеді, өйткені көптеген адамдар әдеттегі виртуалды серверлерге орналастырған.
2. Бұл жеткілікті сенімді, орналастыру технологиясы қарапайым болғандықтан, оны мыңдаған компаниялар сынаған. Миллиондаған серверлер осылай орналастырылған. Бір нәрсені бұзу қиын.
3. Ақырында біз қол жеткізе алдық атомдық орналастырулар. Пайдаланушылар үшін ескі нұсқа мен жаңа нұсқа арасында ауысудың айтарлықтай кезеңінсіз бір уақытта орын алатын орналастырулар.

Бірақ біз мұның бәрінде бірнеше кемшіліктерді көрдік:

1. Өндірістік ортадан, даму ортасынан басқа, басқа орталар бар. Мысалы, qa және preproduction. Ол кезде бізде көптеген серверлер мен 60-қа жуық сервистер болды. Осы себепті қажет болды әрбір қызмет үшін оның соңғы нұсқасын сақтаңыз виртуалды машина. Сонымен қатар, егер сіз кітапханаларды жаңартқыңыз немесе жаңа тәуелділіктерді орнатқыңыз келсе, мұны барлық орталарда орындауыңыз керек. Сондай-ақ, қосымшаның келесі жаңа нұсқасын орналастыратын уақытты devops қажетті орта параметрлерін орындайтын уақытпен синхрондау қажет болды. Бұл жағдайда біздің ортамыз барлық орталарда бірден басқаша болатын жағдайға жету оңай. Мысалы, QA ортасында кітапханалардың кейбір нұсқалары болады, ал өндірістік ортада әртүрлі болады, бұл проблемаларға әкеледі.
2. Тәуелділіктерді жаңарту қиындығы сіздің өтінішіңіз. Бұл сізге емес, басқа командаға байланысты. Атап айтқанда, серверлерге қызмет көрсететін devops командасынан. Сіз оларға тиісті тапсырма беріп, не істегіңіз келетінін сипаттауыңыз керек.
3. Ол кезде біз де қолымызда бар үлкен ірі монолиттерді жеке шағын қызметтерге бөлгіміз келді, өйткені олардың саны көбейетінін түсіндік. Ол кезде бізде олардың 100-ден астамы болды.Әрбір жаңа қызмет үшін жеке жаңа виртуалды машина жасау қажет болды, оны да күтіп ұстау және орналастыру қажет болды. Сонымен қатар, сізге бір емес, кем дегенде екі көлік қажет. Мұның бәріне QA ортасы қосылды. Бұл проблемалар тудырады және жаңа жүйелерді құру мен іске қосуды қиындатады. күрделі, қымбат және ұзақ процесс.

Сондықтан біз кәдімгі виртуалды машиналарды орналастырудан біздің қолданбаларды докер контейнерінде орналастыруға көшу ыңғайлырақ деп шештік. Егер сізде докер болса, қолданбаны кластерде іске қоса алатын жүйе қажет, өйткені сіз жай ғана контейнерді көтере алмайсыз. Әдетте автоматты түрде көтерілу үшін қанша контейнер көтерілгенін қадағалағыңыз келеді. Осы себепті бізге басқару жүйесін таңдау керек болды.

Қайсысын алуға болатынын ұзақ ойладық. Өйткені, сол кезде кәдімгі виртуалды серверлерде бұл орналастыру стек біршама ескірген, өйткені оларда операциялық жүйелердің соңғы нұсқалары болмаған. Бір кезде тіпті FreeBSD болды, оны қолдау өте ыңғайлы емес. Біз мүмкіндігінше тезірек докерге көшу керек екенін түсіндік. Біздің девоптар өздерінің бар тәжірибесіне әртүрлі шешімдермен қарап, Nomad сияқты жүйені таңдады.

Nomad қызметіне ауысыңыз

Nomad – HashiCorp компаниясының өнімі. Олар сондай-ақ басқа шешімдерімен танымал:

«Консул» қызметтерді табу құралы болып табылады.

«Терраформа» - код ретінде инфрақұрылым деп аталатын конфигурация арқылы конфигурациялауға мүмкіндік беретін серверлерді басқару жүйесі.

«Қаңғыбас» виртуалды машиналарды жергілікті немесе бұлтта арнайы конфигурация файлдары арқылы орналастыруға мүмкіндік береді.

Nomad ол кезде барлық инфрақұрылымды өзгертпей-ақ тез ауысуға болатын қарапайым шешім сияқты көрінді. Сонымен қатар, оны үйрену өте оңай. Сондықтан біз оны контейнеріміз үшін сүзу жүйесі ретінде таңдадық.

Жүйені Nomad жүйесіне орналастыру үшін не қажет?

1. Ең алдымен сізге керек докер кескіні сіздің өтінішіңіз. Сіз оны құрастырып, докер кескінінің репозиторийіне орналастыруыңыз керек. Біздің жағдайда бұл артефактура - оған әртүрлі типтегі әртүрлі артефактілерді итеруге мүмкіндік беретін жүйе. Ол мұрағаттарды, докер кескіндерін, композиторлық PHP бумаларын, NPM бумаларын және т.б. сақтай алады.
2. Сондай-ақ қажет конфигурация файлы, ол Nomad-қа нені, қайда және қандай мөлшерде орналастырғыңыз келетінін айтады.

Біз Nomad туралы айтатын болсақ, ол HCL тілін ақпараттық файл пішімі ретінде пайдаланады, ол білдіреді HashiCorp конфигурация тілі. Бұл қызметіңізді Nomad терминдерінде сипаттауға мүмкіндік беретін Yaml қосымшасы.

Ол сізге қанша контейнерді орналастырғыңыз келетінін, оларды орналастыру кезінде әртүрлі параметрлерді қандай кескіндерден өткізу керектігін айтуға мүмкіндік береді. Осылайша сіз бұл файлды Nomad-қа бересіз және ол контейнерлерді соған сәйкес өндіріске қосады.

Біздің жағдайда біз әр қызмет үшін мүлдем бірдей HCL файлдарын жазу өте ыңғайлы болмайтынын түсіндік, өйткені көптеген қызметтер бар және кейде оларды жаңартқыңыз келеді. Бір қызмет бір инстанцияда емес, әртүрлі әртүрлі қызметтерде орналастырылады. Мысалы, бізде өндірісте бар жүйелердің бірінде өндірісте 100-ден астам дана бар. Олар бірдей кескіндерден жұмыс істейді, бірақ конфигурация параметрлері мен конфигурация файлдарында ерекшеленеді.

Сондықтан біз барлық конфигурация файлдарын орналастыру үшін бір ортақ репозиторийде сақтау бізге ыңғайлы деп шештік. Осылайша олар көрінді: оларға техникалық қызмет көрсету оңай және бізде қандай жүйелер бар екенін көре алдық. Қажет болса, бір нәрсені жаңарту немесе өзгерту оңай. Жаңа жүйені қосу да қиын емес - тек жаңа каталог ішінде конфигурация файлын жасау керек. Оның ішінде келесі файлдар бар: қызметіміздің сипаттамасын қамтитын service.hcl және өндірісте қолданылатын осы қызметті конфигурациялауға мүмкіндік беретін кейбір env файлдары.

Дегенмен, біздің кейбір жүйелеріміз өндірісте бір данада емес, бірден бірнеше нұсқада орналастырылған. Сондықтан біз конфигурацияларды таза түрде емес, үлгі түрінде сақтау бізге ыңғайлы деп шештік. Ал біз таңдадық джинжа 2. Бұл пішімде біз қызметтің конфигурацияларын да, оған қажетті env файлдарын да сақтаймыз.

Сонымен қатар, біз репозиторийге барлық жобаларға ортақ орналастыру сценарийін орналастырдық, ол сізге қызметіңізді өндіріске, қажетті ортаға, қажетті мақсатқа енгізуге және орналастыруға мүмкіндік береді. HCL конфигурациясын үлгіге айналдырған жағдайда, бұрын әдеттегі Nomad конфигурациясы болған HCL файлы бұл жағдайда сәл басқаша көріне бастады.

Яғни, кейбір конфигурациялау орны айнымалы мәндерін env файлдарынан немесе басқа көздерден алынған айнымалы кірістірулермен ауыстырдық. Сонымен қатар, біз HCL файлдарын динамикалық түрде жинауға мүмкіндік алдық, яғни біз қарапайым айнымалы кірістірулерді ғана емес пайдалана аламыз. Джинджа циклдар мен шарттарды қолдайтындықтан, сіз сол жерде конфигурация файлдарын жасай аласыз, олар қолданбаларды нақты қай жерде орналастыратыныңызға байланысты өзгереді.

Мысалы, сіз өзіңіздің қызметіңізді өндіріске дейінгі және өндіріске қолданғыңыз келеді. Алдын ала өндірісте сіз cron сценарийлерін іске қосқыңыз келмейді, бірақ оның жұмыс істеп тұрғанына көз жеткізу үшін қызметті бөлек доменде көргіңіз келеді делік. Қызметті қолданатын кез келген адам үшін процесс өте қарапайым және ашық болып көрінеді. Бар болғаны deploy.sh файлын орындап, қандай қызметті орналастырғыңыз келетінін және қандай мақсатқа бағыттағыңыз келетінін көрсетіңіз. Мысалы, сіз белгілі бір жүйені Ресейге, Белоруссияға немесе Қазақстанға орналастырғыңыз келеді. Мұны істеу үшін жай ғана параметрлердің бірін өзгертіңіз, сонда сізде дұрыс конфигурация файлы болады.

Nomad қызметі кластеріңізге әлдеқашан орналастырылған кезде, ол келесідей көрінеді.

Біріншіден, сізге барлық пайдаланушы трафигін қабылдайтын сыртта қандай да бір баланстауыш қажет. Ол Консулмен бірлесіп жұмыс істейді және одан белгілі бір домендік атқа сәйкес келетін нақты қызмет қай жерде, қандай түйінде, қандай IP мекенжайында орналасқанын анықтайды. Консулдағы қызметтер Nomad-тың өзінен келеді. Бұл бір компанияның өнімдері болғандықтан, олар бір-бірімен тығыз байланысты. «Nomad» өз ішінде іске қосылған барлық қызметтерді Консулдың ішінде тіркей алады деп айта аламыз.

Функционалды жүктемені теңестіруші трафикті қай қызметке жіберу керектігін білгенде, ол оны сәйкес контейнерге немесе қолданбаңызға сәйкес келетін бірнеше контейнерге жібереді. Әрине, қауіпсіздік туралы да ойлану керек. Барлық қызметтер контейнерлерде бірдей виртуалды машиналарда жұмыс істейтініне қарамастан, бұл әдетте кез келген қызметтен басқа кез келген қызметке тегін кіруді болдырмауды талап етеді. Біз бұған сегменттеу арқылы қол жеткіздік. Әрбір қызмет өзінің виртуалды желісінде іске қосылды, онда маршруттау ережелері мен басқа жүйелер мен қызметтерге кіруге рұқсат беру/тартпау ережелері белгіленген. Олар осы кластердің ішінде де, оның сыртында да орналасуы мүмкін. Мысалы, қызметтің белгілі бір дерекқорға қосылуын болдырғыңыз келсе, мұны желі деңгейіндегі сегменттеу арқылы жасауға болады. Яғни, қате болса да сынақ ортасынан өндірістік дерекқорға кездейсоқ қосыла алмайсыз.

Өтпелі кезең бізге адам ресурстары тұрғысынан қаншаға түсті?

Бүкіл компанияның Nomad-қа ауысуы шамамен 5-6 айға созылды. Біз қызмет көрсету негізінде көштік, бірақ өте жылдам қарқынмен. Әрбір команда қызметтер үшін өз контейнерлерін жасау керек болды.

Біз әрбір команда өз жүйелерінің докерлік кескіндеріне дербес жауапты болатындай тәсілді қабылдадық. Devops орналастыру үшін қажетті жалпы инфрақұрылымды қамтамасыз етеді, яғни кластердің өзін қолдауды, CI жүйесін қолдауды және т.б. Сол кезде бізде Nomad-қа 60-тан астам жүйе көшті, бұл шамамен 2 мың контейнерді құрады.

Devops орналастыруға және серверлерге қатысты барлығының жалпы инфрақұрылымына жауап береді. Әр әзірлеу тобы, өз кезегінде, белгілі бір жүйеге арналған контейнерлерді енгізуге жауап береді, өйткені ол белгілі бір контейнерде не қажет екенін білетін команда.

Nomad-тан бас тартудың себептері

Nomad және docker қолданбаларын пайдаланып орналастыруға көшу арқылы біз қандай артықшылықтарға қол жеткіздік?

1. біз тең жағдайларды қамтамасыз етті барлық орталар үшін. Әзірлеуде, QA ортасында, алдын ала өндіруде, өндірісте бірдей тәуелділіктермен бірдей контейнер кескіндері пайдаланылады. Тиісінше, сізде өндірісте аяқталатын нәрсе бұрын жергілікті немесе сынақ ортаңызда сыналған нәрсе емес екеніне іс жүзінде ешқандай мүмкіндігіңіз жоқ.
2. Оның да жеткілікті екенін анықтадық жаңа қызметті қосу оңай. Орналастыру тұрғысынан кез келген жаңа жүйелер өте қарапайым іске қосылады. Тек конфигурацияларды сақтайтын репозиторийге өтіңіз, сонда жүйеңізге басқа конфигурация қосыңыз, сонда бәрі дайын. Сіз devops қосымша күш-жігерінсіз жүйеңізді өндіріске орналастыра аласыз.
3. Барлық конфигурация файлдары бір ортақ репозиторийде қарауда болып шықты. Жүйелерімізді виртуалды серверлер арқылы орналастырған кезде біз конфигурациялары бір репозиторийде болатын Ansible қолданбасын пайдаландық. Дегенмен, көптеген әзірлеушілер үшін бұл жұмыс істеу қиынырақ болды. Мұнда қызметті қолдану үшін қосу қажет конфигурациялар мен кодтардың көлемі әлдеқайда аз болды. Оған қоса, әзірлеушілер оны түзету немесе өзгерту өте оңай. Мысалы, Nomad-тың жаңа нұсқасына ауысқан жағдайда, олар бір жерде орналасқан барлық операциялық файлдарды алып, жаппай жаңарта алады.

Бірақ біз бірнеше кемшіліктерге тап болдық:

Біз екені белгілі болды үздіксіз орналастыруға қол жеткізе алмады Nomad жағдайында. Контейнерлерді әртүрлі жағдайларда шығарған кезде ол жұмыс істеп тұрған болып шығуы мүмкін және Nomad оны трафикті қабылдауға дайын контейнер ретінде қабылдады. Бұл оның ішіндегі қолданба іске қосылмай тұрып болды. Осы себепті жүйе қысқа уақыт ішінде 500 қате шығара бастады, өйткені трафик оны қабылдауға әлі дайын емес контейнерге бара бастады.

Кейбірін кездестірдік батпақтармен. Ең маңызды қате, егер сізде көптеген жүйелер мен контейнерлер болса, Nomad үлкен кластерді жақсы өңдемейді. Nomad кластеріне енгізілген серверлердің бірін техникалық қызмет көрсету үшін шығарып алғыңыз келгенде, кластердің өзін жақсы сезінбеу және ыдырап кету ықтималдығы өте жоғары. Кейбір контейнерлер, мысалы, құлап, көтерілмеуі мүмкін - егер сіздің барлық өндірістік жүйелеріңіз Nomad басқаратын кластерде орналасса, бұл сізге кейінірек қымбатқа түседі.

Сондықтан біз бұдан әрі қайда бару керектігін ойластырдық. Сол кезде біз нені қалайтынымызды түсіндік. Атап айтқанда: біз сенімділікті, Nomad ұсынғаннан сәл көбірек функцияларды және неғұрлым жетілген, тұрақты жүйені қалаймыз.

Осыған байланысты біздің таңдауымыз кластерлерді іске қосудың ең танымал платформасы ретінде Kubernetes-ке түсті. Әсіресе, біздің контейнерлердің көлемі мен саны жеткілікті үлкен болғанын ескерсек. Осындай мақсаттар үшін Кубернетес біз қарай алатын ең қолайлы жүйе болып көрінді.

Кубернетеске көшу

Мен Кубернетестің негізгі ұғымдары және олардың Nomad-тен айырмашылығы туралы аздап айтып беремін.

Біріншіден, Кубернетестегі ең негізгі ұғым - под концепциясы. Под әрқашан бірге жүретін бір немесе бірнеше контейнерлер тобы. Және олар әрқашан бір виртуалды машинада жұмыс істегендей жұмыс істейді. Олар әртүрлі порттарда IP 127.0.0.1 арқылы бір-біріне қол жетімді.

Сізде nginx және php-fpm - классикалық схемадан тұратын PHP қосымшасы бар деп есептейік. Сірә, сіз nginx және php-fpm контейнерлерін әрқашан бірге сақтағыңыз келеді. Кубернетес мұны бір жалпы подколь ретінде сипаттау арқылы қол жеткізуге мүмкіндік береді. Дәл осыны біз Nomad-пен ала алмадық.

Екінші тұжырымдама орналастыру. Шындығында, қабықтың өзі уақытша нәрсе, ол басталады және жоғалады. Алдымен барлық алдыңғы контейнерлерді жойып, жаңа нұсқаларды бірден іске қосқыңыз келе ме, әлде оларды біртіндеп шығарғыңыз келе ме? Бұл орналастыру тұжырымдамасы үшін жауап беретін процесс. Ол подкасттарды қалай орналастыратыныңызды, қандай мөлшерде және оларды қалай жаңарту керектігін сипаттайды.

Үшінші ұғым қызмет көрсету. Сіздің қызметіңіз шын мәнінде сіздің жүйеңіз болып табылады, ол біраз трафикті қабылдайды, содан кейін оны қызметіңізге сәйкес бір немесе бірнеше подкасттарға жібереді. Яғни, ол осындай және осындай атаумен осындай қызметке түсетін барлық трафикті осы нақты подкасттарға жіберу керек деп айтуға мүмкіндік береді. Сонымен бірге ол сізге трафикті теңестіруді қамтамасыз етеді. Яғни, сіз қолданбаңыздың екі қосқышын іске қоса аласыз және барлық кіріс трафик осы қызметке қатысты бөлімшелер арасында біркелкі теңестіріледі.

Ал төртінші негізгі ұғым Кіріс. Бұл Kubernetes кластерінде жұмыс істейтін қызмет. Ол барлық сұрауларды қабылдайтын сыртқы жүктеме теңестірушісі ретінде әрекет етеді. Kubernetes API көмегімен Ingress бұл сұраулардың қайда жіберілетінін анықтай алады. Оның үстіне, ол мұны өте икемді түрде жасайды. Осы хостқа және осындай URL мекенжайына барлық сұраулар осы қызметке жіберіледі деп айта аласыз. Осы хостқа және басқа URL мекенжайына келетін бұл сұраулар басқа қызметке жіберіледі.

Қолданбаны әзірлеуші ​​адамның көзқарасы бойынша ең керемет нәрсе - сіз оның бәрін өзіңіз басқара аласыз. Ingress конфигурациясын орнату арқылы сіз осындай және осындай API-ге келетін барлық трафикті, мысалы, Go ішінде жазылған бөлек контейнерлерге жібере аласыз. Бірақ сол доменге келетін, бірақ басқа URL мекенжайына келетін бұл трафикті PHP тілінде жазылған контейнерлерге жіберу керек, мұнда логика көп, бірақ олар өте жылдам емес.

Осы ұғымдардың барлығын Nomadпен салыстыратын болсақ, алғашқы үш ұғымның барлығы бірге Қызмет деп айта аламыз. Ал соңғы ұғым Nomadтың өзінде жоқ. Біз сыртқы теңгерімді пайдаландық: ол haproxy, nginx, nginx+ және т.б. болуы мүмкін. Текше жағдайында бұл қосымша ұғымды бөлек енгізудің қажеті жоқ. Дегенмен, егер сіз Ingress ішінен қарасаңыз, ол nginx, haproxy немесе traefik болып табылады, бірақ Кубернетеске салынған.

Мен сипаттаған барлық тұжырымдамалар, шын мәнінде, Kubernetes кластерінде бар ресурстар. Оларды текшеде сипаттау үшін Nomad жағдайында HCL файлдарына қарағанда оқылатын және таныс yaml пішімі пайдаланылады. Бірақ құрылымдық жағынан олар бірдей нәрсені сипаттайды, мысалы, pod. Олар былай дейді: «Мен анау-мынау бейнелері бар, осындай-мұнша мөлшерде, анау-мынау пұтқаларды орналастырғым келеді.

Сонымен қатар, біз әрбір жеке ресурсты қолмен жасағымыз келмейтінін түсіндік: орналастыру, қызметтер, кіру және т.б. Оның орнына, біз барлық қажетті ресурс тәуелділіктерін дұрыс ретпен қолмен қайта жасаудың қажеті болмас үшін орналастыру кезінде Кубернетес тұрғысынан әрбір жүйемізді сипаттағымыз келді. Бізге мұны істеуге мүмкіндік беретін жүйе ретінде Helm таңдалды.

Helm тіліндегі негізгі түсініктер

Руль пакет менеджері Кубернетес үшін. Бұл бағдарламалау тілдеріндегі пакет менеджерлерінің жұмысына өте ұқсас. Олар, мысалы, орналастыру nginx, php-fpm орналастыру, кіріс конфигурациясы, конфигматика (бұл жүйе үшін env және басқа параметрлерді орнатуға мүмкіндік беретін нысан) со- диаграммалар деп аталады. Сонымен бірге Хельм Кубернетестің үстінде жүреді. Яғни, бұл жүйенің бір түрі емес, текше ішінде іске қосылған басқа қызмет. Сіз онымен оның API арқылы консоль пәрмені арқылы әрекеттесесіз. Оның ыңғайлылығы мен сұлулығы, руль сынып қалса немесе оны кластерден алып тастасаңыз да, сіздің қызметтеріңіз жойылмайды, өйткені руль негізінен жүйені іске қосу үшін қызмет етеді. Содан кейін Кубернетестің өзі қызметтердің өнімділігі мен күйіне жауап береді.

Біз де соны аңғардық шаблондау, біз бұрын конфигурацияларымызға джинджаны енгізу арқылы өзіміз жасауға мәжбүр болған , рульдің негізгі ерекшеліктерінің бірі. Жүйелеріңіз үшін жасаған барлық конфигурациялар джинджаға сәл ұқсас, бірақ шын мәнінде Кубернетес сияқты руль жазылған Go тілінің шаблонын қолдана отырып, шаблондар түрінде штурвалда сақталады.

Helm біз үшін тағы бірнеше ұғымдарды қосады.

кесте - бұл сіздің қызметіңіздің сипаттамасы. Басқа пакет менеджерлерінде ол бума, бума немесе ұқсас нәрсе деп аталады. Мұнда ол диаграмма деп аталады.

Құндылықтар үлгілерден конфигурацияларды құру үшін пайдаланғыңыз келетін айнымалылар.

босату. Әр жолы руль арқылы орналастырылған қызмет шығарылымның қосымша нұсқасын алады. Helm алдыңғы шығарылымдағы қызмет конфигурациясы қандай болғанын, оның алдындағы шығарылымды және т.б. Сондықтан, егер кері қайтару қажет болса, оны алдыңғы шығарылым нұсқасына бағыттап, рульге кері шақыру пәрменін орындаңыз. Репозиторийдегі сәйкес конфигурация кері қайтару кезінде қол жетімді болмаса да, helm оның не болғанын әлі есте сақтайды және жүйеңізді алдыңғы шығарылымдағы күйге қайтарады.

Біз рульді пайдаланған жағдайда, Kubernetes үшін әдеттегі конфигурациялар айнымалыларды, функцияларды қолдануға және шартты мәлімдемелерді қолдануға болатын үлгілерге айналады. Осылайша сіз ортаға байланысты қызмет конфигурациясын жинай аласыз.

Іс жүзінде біз Nomad-пен жұмыс істегеннен гөрі басқаша әрекет етуді шештік. Егер Nomad бағдарламасында қызметімізді орналастыру үшін қажет орналастыру конфигурациялары мен n-айнымалы мәндері бір репозиторийде сақталған болса, мұнда біз оларды екі бөлек репозиторийге бөлуді шештік. «Орналастыру» репозиторийі орналастыру үшін қажет n-айнымалы мәндерді ғана сақтайды, ал «тұғыр» репозиторийі конфигурацияларды немесе диаграммаларды сақтайды.

Бұл бізге не берді?

Біз конфигурация файлдарында шынымен құпия деректерді сақтамайтынымызға қарамастан. Мысалы, дерекқорларға арналған құпия сөздер. Олар Кубернетеде құпия ретінде сақталады, бірақ соған қарамастан, біз бәріне қол жеткізуді қаламайтын кейбір нәрселер бар. Сондықтан, «орналастыру» репозиторийіне қол жеткізу шектелген және «руль» репозиторийінде жай ғана қызмет сипаттамасы бар. Осы себепті оған адамдардың кең ауқымы қауіпсіз қол жеткізе алады.

Бізде тек өндіріс қана емес, сонымен қатар басқа орталар да болғандықтан, осы бөлудің арқасында біз қызметтерді тек өндіріске ғана емес, сонымен қатар, мысалы, QA ортасына орналастыру үшін басқару диаграммаларын қайта пайдалана аламыз. Тіпті оларды жергілікті түрде қолдану үшін Миникубе - бұл Kubernetes-ті жергілікті түрде басқаруға арналған нәрсе.

Әрбір репозиторийдің ішінде біз әр қызмет үшін бөлек каталогтарға бөлім қалдырдық. Яғни, әрбір каталогтың ішінде сәйкес диаграммаға қатысты және жүйемізді іске қосу үшін орналастыру қажет ресурстарды сипаттайтын үлгілер бар. Біз «орналастыру» репозиторийінде тек env файлдарын қалдырдық. Бұл жағдайда біз джинджа көмегімен үлгілеуді пайдаланбадық, өйткені helm өзі қораптан тыс шаблонды қамтамасыз етеді - бұл оның негізгі функцияларының бірі.

Біз орналастыру сценарийін қалдырдық - deploy.sh, ол руль арқылы орналастыру үшін іске қосуды жеңілдетеді және стандарттайды. Сонымен, орналастыруды қалайтын кез келген адам үшін орналастыру интерфейсі Nomad арқылы орналастыру кезіндегідей көрінеді. Сол deploy.sh, қызметіңіздің атауы және оны орналастырғыңыз келетін жер. Бұл рульдің ішкі іске қосылуына әкеледі. Ол, өз кезегінде, шаблондардан конфигурацияларды жинайды, оларға қажетті мәндер файлдарын енгізеді, содан кейін оларды Kubernetes ішіне іске қосады.

қорытындылар

Kubernetes қызметі Nomadқа қарағанда күрделірек сияқты.

Мұнда шығыс трафик Ингреске келеді. Бұл барлық сұрауларды қабылдайтын және кейіннен оларды сұрау деректеріне сәйкес қызметтерге жіберетін алдыңғы контроллер. Ол оларды рульдегі қолданбаңыздың сипаттамасының бөлігі болып табылатын және әзірлеушілер өздері орнатқан конфигурациялар негізінде анықтайды. Бұл қызмет осы қызметке жататын барлық контейнерлер арасындағы кіріс трафикті теңестіре отырып, сұрауларды өз бөлімшелеріне, яғни нақты контейнерлерге жібереді. Және, әрине, біз желі деңгейінде қауіпсіздіктен ешқайда кетпеуіміз керек екенін ұмытпауымыз керек. Сондықтан сегменттеу тегтерге негізделген Kubernetes кластерінде жұмыс істейді. Барлық қызметтерде қызметтердің кластердің ішіндегі немесе сыртындағы белгілі бір сыртқы/ішкі ресурстарға қатынасу құқықтары байланыстырылған белгілі тегтері бар.

Біз көшу кезінде біз Кубернетестің біз бұрын пайдаланған Nomad мүмкіндіктерінің барлығына ие екенін, сонымен қатар көптеген жаңа нәрселерді қосқанын көрдік. Оны плагиндер арқылы және шын мәнінде реттелетін ресурс түрлері арқылы кеңейтуге болады. Яғни, сізде Kubernetes-пен бірге келетін нәрсені пайдалану ғана емес, сонымен қатар сіздің ресурсыңызды оқитын жеке ресурс пен қызметті жасау мүмкіндігі бар. Бұл Kubernetes қолданбасын қайта орнатусыз және өзгертулерді қажет етпей-ақ жүйеңізді кеңейтудің қосымша мүмкіндіктерін береді.

Мұндай пайдаланудың мысалы - Kubernetes кластерінде жұмыс істейтін Prometheus. Ол белгілі бір қызметтен көрсеткіштерді жинауды бастау үшін қызмет сипаттамасына ресурстың қосымша түрін, қызмет мониторы деп аталатынын қосуымыз керек. Prometheus, Kubernetes-те іске қосылған кезде реттелетін ресурс түрін оқи алатындығына байланысты, жаңа жүйеден метрикаларды жинауды автоматты түрде бастайды. Бұл өте ыңғайлы.

Біз Кубернетеске бірінші рет 2018 жылдың наурыз айында орналастырдық. Осы уақыт ішінде біз онымен ешқашан қиындық көрмедік. Ол айтарлықтай қателерсіз өте тұрақты жұмыс істейді. Сонымен қатар, біз оны одан әрі кеңейте аламыз. Бүгін бізде оның мүмкіндіктері жеткілікті және бізге Кубернетестің даму қарқыны өте ұнайды. Қазіргі уақытта Кубернетесте 3000-нан астам контейнер бар. Кластер бірнеше түйіндерді алады. Сонымен қатар, ол қызмет көрсетуге жарамды, тұрақты және өте басқарылады.

Ақпарат көзі: www.habr.com