Бұл оқиға контейнерлерді өндірістік ортада, атап айтқанда Кубернетесте қалай қолданатынымыз туралы. Мақала контейнерлерден көрсеткіштер мен журналдарды жинауға, сондай-ақ кескіндерді құруға арналған.

Біз онлайн сауда қызметтерін және B2B және B2C финтех өнімдерін әзірлейтін Exness финтех компаниясынанбыз. Біздің ҒЗТКЖ-да әртүрлі командалар бар, әзірлеу бөлімінде 100+ қызметкер бар.

Біз әзірлеушілеріміздің кодты жинауы және іске қосуы үшін платформаға жауапты топты көрсетеміз. Атап айтқанда, біз қолданбалардан көрсеткіштерді, журналдарды және оқиғаларды жинауға, сақтауға және есеп беруге жауаптымыз. Қазіргі уақытта біз өндірістік ортада шамамен үш мың Docker контейнерін басқарамыз, 50 ТБ үлкен деректер қоймасын қолдаймыз және инфрақұрылымымыздың айналасында құрылған архитектуралық шешімдерді ұсынамыз: Kubernetes, Rancher және әртүрлі қоғамдық бұлттық провайдерлер. 

Біздің мотивация

Не күйіп жатыр? Ешкім жауап бере алмайды. Ошақ қайда? Түсіну қиын. Ол қашан өртенді? Сіз біле аласыз, бірақ бірден емес. 

Неліктен кейбір контейнерлер тұрып, басқалары құлап кетті? Қай контейнер кінәлі болды? Өйткені, контейнерлердің сырты бірдей, бірақ әрқайсысының ішінде өз Neo бар.

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

Агенттер

Ішінде не болып жатқанын түсіну үшін агенттерді тікелей контейнерлерге орналастыруды шештік.

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

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

Агенттер сонымен қатар әртүрлі кескіндерді (Debian, Alpine, Centos және т.б.) қолдайтын әртүрлі оркестрлік жүйелерде жұмыс істей алатын пайдалану және техникалық қызмет көрсету үшін утилиталарды білдіреді.

Соңында, агенттер Docker файлдарын қамтитын қарапайым CI/CD дискісін қолдауы керек. Әйтпесе, кеме құлап кетеді, өйткені контейнерлер «қисық» рельстермен жеткізіле бастайды.

Құру процесі және мақсатты кескін құрылғысы

Барлығын стандартталған және басқарылатын етіп сақтау үшін стандартты құрастыру процесінің қандай да бір түрін сақтау керек. Сондықтан біз контейнерлерді контейнерлермен жинауды шештік - бұл рекурсия.

Мұнда контейнерлер тұтас контурлармен бейнеленген. Сонымен бірге олар «өмір таңқурай сияқты көрінбеуі» үшін оларға тарату жинақтарын салуды шешті. Неліктен бұл жасалды, біз төменде түсіндіреміз.
 
Нәтиже құрастыру құралы — нақты тарату нұсқаларына және нақты сценарий нұсқаларына сілтеме жасайтын нұсқаға арнайы контейнер.

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

Бұл тәсілдің несі жақсы? 

• Біріншіден, құрастыру құралдарының толық нұсқасын басқару – контейнер, сценарий және тарату нұсқаларын құрастыру. 
• Екіншіден, біз стандарттауға қол жеткіздік: шаблондарды, аралық және пайдалануға дайын кескінді бірдей етіп жасаймыз. 
• Үшіншіден, контейнерлер бізге тасымалдауға мүмкіндік береді. Бүгін біз Gitlab-ті қолданамыз, ал ертең біз TeamCity немесе Jenkins-ке ауысамыз және контейнерлерімізді дәл осылай іске қоса аламыз. 
• Төртіншіден, тәуелділікті азайту. Біз тарату жинақтарын контейнерге салғанымыз кездейсоқ емес, өйткені бұл оларды Интернеттен әр уақытта жүктеп алмауға мүмкіндік береді. 
• Бесіншіден, құрастыру жылдамдығы артты - суреттердің жергілікті көшірмелерінің болуы жүктеп алуға уақытты жоғалтпауға мүмкіндік береді, өйткені жергілікті кескін бар. 

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

Біздің құрастыру процедурасы қалай жұмыс істейді

Құрастыру бір командамен іске қосылады, процесс суретте орындалады (қызыл түспен белгіленген). Әзірлеушіде Docker файлы бар (сары түспен белгіленген), біз оны айнымалы мәндерді мәндермен ауыстырамыз. Жолда біз үстіңгі және төменгі деректемелерді қосамыз - бұл біздің агенттер. 

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

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

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

 

Бір контейнер үшін біз Docker және Kubernetes-те әртүрлі технологиялық ағаштарды аламыз:

Пайдалы жүктеме S6 бақылауымен орындалады. Коллектор мен оқиғаларға назар аударыңыз - бұл журналдар мен көрсеткіштерге жауапты біздің агенттер. Кубернеттерде олар жоқ, бірақ Докерде бар. Неліктен? 

Егер біз «под» (бұдан әрі – Kubernetes pod) спецификациясына қарасақ, оқиғалар контейнері метрика мен журналдарды жинау функциясын орындайтын бөлек коллекторлық контейнері бар подводта орындалатынын көреміз. Біз Kubernetes мүмкіндіктерін пайдалана аламыз: контейнерлерді бір блокта, бір процесте және/немесе желі кеңістігінде іске қосу. Іс жүзінде агенттеріңізді таныстырыңыз және кейбір функцияларды орындаңыз. Егер бірдей контейнер Docker-де іске қосылса, ол шығыс сияқты барлық мүмкіндіктерді алады, яғни ол журналдар мен көрсеткіштерді жеткізе алады, өйткені агенттер ішкі іске қосылады. 

Көрсеткіштер және журналдар

Көрсеткіштер мен журналдарды жеткізу күрделі тапсырма болып табылады. Оның шешімінің бірнеше аспектілері бар.
Инфрақұрылым журналдарды жаппай жеткізу үшін емес, пайдалы жүктемені орындау үшін жасалған. Яғни, бұл процесс ең аз контейнерлік ресурстар талаптарымен орындалуы керек. Біз әзірлеушілерімізге көмектесуге тырысамыз: «Docker Hub контейнерін алыңыз, оны іске қосыңыз және біз журналдарды жеткізе аламыз». 

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

Үшінші аспект - бұл қораптан мүмкіндігінше көп метрика жинау әдістерін қолдау қажет. Файлдарды оқу және Prometheus-соңғы нүктесін сұраудан қолданбаға арнайы хаттамаларды пайдалануға дейін.

Ал соңғы аспект - ресурстарды тұтынуды барынша азайту.

Біз Telegraf деп аталатын ашық бастапқы Go шешімін таңдадық. Бұл кіріс арналарының 140-тан астам түрін (кіріс плагиндері) және шығыс арналарының 30 түрін (шығыс плагиндері) қолдайтын әмбебап қосқыш. Біз оны аяқтадық, енді оны мысал ретінде Kubernetes көмегімен қалай қолданатынымызды айтамыз. 

Әзірлеуші ​​жұмыс жүктемесін орналастырады және Kubernetes подкаст жасау туралы сұрауды алды делік. Осы кезде әрбір подвод үшін Коллектор деп аталатын контейнер автоматты түрде жасалады (біз мутация веб-хукін қолданамыз). Коллектор - біздің агент. Бастапқыда бұл контейнер Prometheus және журнал жинау жүйесімен жұмыс істеу үшін өзін конфигурациялайды.

• Ол үшін подк аннотацияларды пайдаланады және оның мазмұнына қарай, айталық, Прометейдің соңғы нүктесін жасайды; 
• Қондырғы спецификациясына және арнайы контейнер параметрлеріне сүйене отырып, ол журналдарды жеткізу жолын шешеді.

Біз журналдарды Docker API арқылы жинаймыз: әзірлеушілер оларды stdout немесе stderr ішіне қоюы керек, ал Коллектор оны сұрыптайды. Мүмкін хосттың шамадан тыс жүктелуінің алдын алу үшін журналдар біраз кідіріспен бөліктерде жиналады. 

Көрсеткіштер контейнерлердегі жұмыс жүктемесі даналары (процестер) бойынша жиналады. Барлығы тегтелген: аттар кеңістігі, астында және т.б., содан кейін Prometheus пішіміне түрлендіріледі - және жинау үшін қолжетімді болады (журналдардан басқа). Біз сонымен қатар журналдарды, көрсеткіштерді және оқиғаларды Кафкаға және одан әрі жібереміз:

• Журналдар Graylog тілінде қол жетімді (визуалды талдау үшін);
• Журналдар, көрсеткіштер, оқиғалар ұзақ мерзімді сақтау үшін Clickhouse бағдарламасына жіберіледі.

AWS-те барлығы бірдей жұмыс істейді, тек біз Graylog-ті Кафка-мен Cloudwatch-пен ауыстырамыз. Біз журналдарды сол жерге жібереміз, бәрі өте ыңғайлы: олардың қай кластерге және контейнерге жататындығы бірден анық болады. Google Stackdriver үшін де солай. Яғни, біздің схемамыз Кафкамен жергілікті жерде де, бұлтта да жұмыс істейді. 

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

Дәл осындай процестер контейнер ішінде орындалады, олар S6 көмегімен реттеледі. Барлық бірдей процестер бір контейнерде орындалады.

Нәтижесінде,

Біз журналдар мен көрсеткіштерді жинау және жеткізу опциялары бар кескіндерді құру және іске қосу үшін толық шешім жасадық:

• Біз кескіндерді жинаудың стандартталған тәсілін әзірледік және оның негізінде CI үлгілерін әзірледік;
• Деректерді жинау агенттері біздің Telegraf кеңейтімдері болып табылады. Біз оларды өндірісте жақсы сынадық;
• Біз контейнерлердегі агенттері бар контейнерлерді іске асыру үшін мутация веб-хукін пайдаланамыз; 
• Kubernetes/Rancher экожүйесіне біріктірілген;
• Біз бірдей контейнерлерді әртүрлі оркестрлік жүйелерде орындап, күткен нәтижені аламыз;
• Толық динамикалық контейнерді басқару конфигурациясын жасады. 

Бірлескен автор: Илья Прудников

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