Бул окуя өндүрүш чөйрөсүндө, атап айтканда Kubernetesте контейнерлерди кантип колдонуубуз жөнүндө. Макала контейнерлерден метрикаларды жана журналдарды чогултууга, ошондой эле сүрөттөрдү курууга арналган.

Биз B2B жана B2C үчүн онлайн соода жана финтех өнүмдөрү үчүн кызматтарды иштеп чыккан Exness финтех компаниясынанбыз. Биздин R & D көптөгөн ар кандай командалар бар, өнүктүрүү бөлүмүндө 100+ кызматкерлери бар.

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

Биздин мотивация

Эмне күйүп жатат? Эч ким жооп бере албайт. очок кайда? Муну түшүнүү кыйын. Ал качан күйүп кетти? Сиз биле аласыз, бирок дароо эмес. 

Эмне үчүн кээ бир контейнерлер туруп, башкалары кулап калды? Кайсы контейнер күнөөлүү? Анткени, контейнерлердин сырты бирдей, бирок ичинде ар биринин өзүнүн Neo бар.

Биздин иштеп чыгуучулар компетенттүү балдар. Алар компанияга пайда алып келген жакшы кызматтарды жасашат. Бирок тиркемелери бар контейнерлер адашып кеткенде каталар бар. Бир контейнер өтө көп CPU керектейт, экинчиси тармакты, үчүнчүсү киргизүү/чыгаруу операцияларын, төртүнчүсү розеткалар менен эмне кылганы такыр түшүнүксүз. Мунун баары кулап, кеме чөгүп кетет. 

агенттер

Ичинде эмне болуп жатканын түшүнүү үчүн агенттерди түздөн-түз контейнерлерге коюуну чечтик.

Бул агенттер контейнерлерди бири-бирин сындырбай турган абалда кармаган чектөөчү программалар. Агенттер стандартташтырылган жана бул контейнерлерди тейлөөгө стандартташтырылган мамиле жасоого мүмкүндүк берет. 

Биздин учурда, агенттер журналдарды стандарттуу форматта, белгиленүүчү жана дроссель менен камсыз кылышы керек. Алар ошондой эле бизнес-колдонмо көз карашы боюнча кеңейтиле турган стандартташтырылган метрика менен камсыз кылышы керек.

Агенттер ошондой эле ар кандай сүрөттөрдү (Debian, Alpine, Centos ж.

Акырында, агенттер Docker файлдарын камтыган жөнөкөй CI/CDди колдошу керек. Болбосо, кеме кулап калат, анткени контейнерлер "ийри" рельстер боюнча жеткириле баштайт.

Build жараяны жана максаттуу сүрөт түзмөк

Баарын стандартташтырылган жана башкара алгыдай кылуу үчүн, кандайдыр бир стандарттуу куруу процессин аткаруу керек. Ошондуктан, биз контейнерлерди контейнерлер менен чогултууну чечтик - бул рекурсия.

Бул жерде контейнерлер катуу контурлар менен берилген. Ошол эле учурда, алар "жашоо малинадай көрүнбөйт" деп аларга бөлүштүрүү комплекттерин коюуну чечишти. Бул эмне үчүн жасалган, биз төмөндө түшүндүрөбүз.
 
Натыйжада куруу куралы — белгилүү бир бөлүштүрүү версияларына жана конкреттүү скрипт версияларына шилтеме берген версияга тиешелүү контейнер.

Биз аны кантип колдоно алабыз? Бизде контейнерди камтыган Docker Hub бар. Тышкы көз карандылыктан арылуу үчүн аны системабыздын ичинде чагылдырабыз. Натыйжада сары менен белгиленген идиш пайда болот. Биз контейнерге керектүү бардык дистрибуцияларды жана скрипттерди орнотуу үчүн шаблон түзөбүз. Андан кийин биз колдонууга даяр сүрөттү чогултабыз: иштеп чыгуучулар ага кодду жана айрым өзгөчө көз карандылыктарды киргизишет. 

Бул ыкманын эмнеси жакшы? 

• Биринчиден, куруу куралдарынын толук версиясын башкаруу - контейнерди куруу, скрипт жана бөлүштүрүү версиялары. 
• Экинчиден, биз стандартташтырууга жетиштик: шаблондорду, орто жана колдонууга даяр образды ушундай эле жол менен түзөбүз. 
• Үчүнчүдөн, контейнерлер бизге көчмө мүмкүнчүлүк берет. Бүгүн биз Gitlabди колдонобуз, эртең TeamCity же Дженкинске которулабыз жана контейнерлерибизди ушундай эле иштете алабыз. 
• Төртүнчүдөн, көз карандылыкты азайтуу. Бөлүштүрүүчү комплекттерди контейнерге койгонубуз бекеринен болгон жок, анткени бул бизге аларды ар дайым Интернеттен жүктөөдөн качууга мүмкүндүк берет. 
• Бешинчиден, куруу ылдамдыгы жогорулады - сүрөттөрдүн жергиликтүү көчүрмөлөрүнүн болушу жергиликтүү сүрөт бар болгондуктан, жүктөө үчүн убакытты текке кетирбөөгө мүмкүндүк берет. 

Башкача айтканда, биз контролдонуучу жана ийкемдүү чогултуу процессине жетиштик. Толук версиясы бар контейнерлерди куруу үчүн биз ошол эле куралдарды колдонобуз. 

Биздин куруу процедурасы кандай иштейт

Чогултуу бир команда менен ишке киргизилет, процесс сүрөттө (кызыл менен белгиленген) аткарылат. Иштеп чыгуучунун Докер файлы бар (сары менен белгиленген), биз аны өзгөрмөлөрдү маанилерге алмаштырып, көрсөтөбүз. Жолдо биз баш жана колонтитулдарды кошобуз - бул биздин агенттер. 

Header тиешелүү сүрөттөрдөн бөлүштүрүүнү кошот. Ал эми төмөнкү колонтитул ичиндеги кызматтарыбызды орнотот, жумуш жүгүн, журналды жана башка агенттерди ишке киргизүүнү конфигурациялайт, кирүү чекитинин ордуна ж.б.у.с. 

Көзөмөлчү орнотобузбу деп көпкө ойлондук. Акырында ал бизге керек деп чечтик. Биз S6 тандап алган. Жетекчи контейнерди башкарууну камсыз кылат: эгерде негизги процесс бузулуп калса, ага туташууга мүмкүндүк берет жана контейнерди кайра жаратпастан кол менен башкарууну камсыз кылат. Журналдар жана метрикалар контейнердин ичинде иштеп жаткан процесстер. Аларды да кандайдыр бир жол менен көзөмөлдөш керек, биз муну жетекчинин жардамы менен жасайбыз. Акыр-аягы, S6 үй-тиричилик, сигналдарды иштетүү жана башка милдеттерди аткарат.

Биз ар кандай оркестрдик системаларды колдонгондуктан, куруу жана иштетүүдөн кийин, контейнер кандай чөйрөдө экенин түшүнүп, кырдаалга жараша иш-аракет кылышы керек. Мисалы:
Бул бизге бир образды түзүүгө жана аны ар кандай оркестрдик системаларда иштетүүгө мүмкүндүк берет жана бул оркестрдик системанын өзгөчөлүктөрүн эске алуу менен ишке киргизилет.

 

Бир эле контейнер үчүн биз Docker жана Kubernetesте ар кандай процесс дарактарды алабыз:

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

Эгерде биз "поддун" (мындан ары - Kubernetes pod) спецификациясын карай турган болсок, окуялар контейнери метрика жана журналдарды чогултуу функциясын аткарган өзүнчө коллектордук контейнерге ээ поддондо аткарылганын көрөбүз. Биз Kubernetes мүмкүнчүлүктөрүн колдоно алабыз: контейнерлерди бир поддондо, бир процессте жана/же тармак мейкиндигинде иштетүү. Чындыгында агенттериңизди тааныштырып, кээ бир функцияларды аткарыңыз. Жана эгерде ошол эле контейнер Dockerде ишке киргизилсе, анда ал чыгаруу сыяктуу бардык мүмкүнчүлүктөрдү алат, башкача айтканда, ал журналдарды жана метрикаларды жеткире алат, анткени агенттер ички ишке киргизилет. 

Метрикалар жана журналдар

Метрикаларды жана журналдарды жеткирүү татаал иш. Анын чечиминин бир нече аспектилери бар.
Инфраструктура журналдарды массалык түрдө жеткирүү үчүн эмес, пайдалуу жүктү аткаруу үчүн түзүлгөн. Башкача айтканда, бул процесс минималдуу контейнер ресурстук талаптар менен аткарылышы керек. Биз иштеп чыгуучуларыбызга жардам берүүгө аракет кылабыз: "Docker Hub контейнерин алыңыз, аны иштетиңиз, ошондо биз журналдарды жеткире алабыз." 

Экинчи аспект - журналдардын көлөмүн чектөө. Эгерде журналдардын көлөмүнүн өсүшү бир нече контейнерде пайда болсо (тиркеме циклде стек-изди чыгарат), CPU, байланыш каналдары жана журналдарды иштетүү тутумундагы жүк көбөйөт жана бул хосттун иштөөсүнө таасир этет. бүт жана башка контейнерлер, анда кээде бул хосттун "жыгылышына" алып келет. 

Үчүнчү аспект - бул кутудан мүмкүн болушунча көп метрикалык чогултуу ыкмаларын колдоо керек. Файлдарды окуудан жана Prometheus-endpoint менен сурамжылоодон баштап, колдонмонун атайын протоколдорун колдонууга чейин.

Ал эми акыркы аспект ресурс керектөөсүн минималдаштыруу болуп саналат.

Биз Telegraf деп аталган ачык булактуу Go чечимин тандадык. Бул киргизүү каналдарынын 140тан ашык түрүн (киргизүү плагиндери) жана чыгаруу каналдарынын 30 түрүн (чыгаруу плагиндери) колдогон универсалдуу туташтыргыч. Биз аны аягына чыгардык жана азыр биз мисал катары Kubernetes аркылуу аны кантип колдонорубузду айтып беребиз. 

Дейли, иштеп чыгуучу жумуш жүгүн жайгаштырды жана Kubernetes подкаст түзүү өтүнүчүн алат. Бул учурда, ар бир поддон үчүн автоматтык түрдө Коллектор деп аталган контейнер түзүлөт (биз мутация вебхукту колдонобуз). Коллекционер биздин агент. Башында бул контейнер Prometheus жана журналдарды чогултуу системасы менен иштөө үчүн өзүн конфигурациялайт.

• Бул үчүн ал подк аннотацияларды колдонот жана анын мазмунуна жараша, айталы, Прометейдин акыркы чекитинин түзүлүшү; 
• Подгондун спецификациясына жана контейнердин конкреттүү жөндөөлөрүнө таянып, ал журналдарды кантип жеткирүүнү чечет.

Биз журналдарды Docker API аркылуу чогултабыз: иштеп чыгуучулар аларды stdout же stderrге коюшу керек, жана Коллектор аны иргейт. Журналдар хосттун ашыкча жүктөлүшүнө жол бербөө үчүн бир аз кечигүү менен бөлүктөргө чогултулат. 

Метрикалар контейнерлердеги жумуш жүктөө инстанцияларында (процесстеринде) чогултулат. Баары белгиленет: аттар мейкиндиги, асты жана башкалар, андан кийин Prometheus форматына айландырылат - жана чогултуу үчүн жеткиликтүү болот (журналдардан тышкары). Биз ошондой эле журналдарды, көрсөткүчтөрдү жана окуяларды Кафкага жана андан ары жөнөтөбүз:

• Журналдар Graylog (визуалдык талдоо үчүн);
• Журналдар, көрсөткүчтөр, окуялар Clickhouse'га узак мөөнөттүү сактоо үчүн жөнөтүлөт.

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

Эгерде бизде кубернеттердин кабыктары жок болсо, схема бир аз татаалыраак, бирок ал ошол эле принциптерде иштейт.

Ошол эле процесстер контейнердин ичинде аткарылат, алар S6 аркылуу уюштурулат. Ошол эле процесстер бир контейнердин ичинде жүрүп жатат.

Жыйынтыгында

Биз логдорду жана метрикаларды чогултуу жана жеткирүү жолдору менен сүрөттөрдү куруу жана ишке киргизүү үчүн толук чечимди түздүк:

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

Авторлош: Илья Прудников

Source: www.habr.com