RIT 2019да биздин кесиптешибиз Александр Коротков жасаган CIANдагы өнүгүүнү автоматташтыруу жөнүндө: жашоону жана ишти жөнөкөйлөтүү үчүн биз өзүбүздүн Integro платформабызды колдонобуз. Ал тапшырмалардын жашоо циклине көз салат, иштеп чыгуучуларды күнүмдүк операциялардан бошотот жана өндүрүштөгү мүчүлүштүктөрдүн санын олуттуу кыскартат. Бул постто биз Александрдын отчетун толуктап, жөнөкөй скрипттерден кантип ачык булактуу өнүмдөрдү өз платформабыз аркылуу айкалыштырууга өткөнүбүздү жана биздин өзүнчө автоматташтыруу тобубуз эмне кылып жатканын айтып беребиз.
Нөл деңгээл
"Нөл деңгээл деген нерсе жок, мен андай нерсени билбейм"
"Кунг-фу панда" тасмасынан Мастер Шифу
CIANдагы автоматташтыруу компания негизделгенден 14 жыл өткөндөн кийин башталган. Ал кезде иштеп чыгуучу бригадада 35 адам болгон. Ишенүү кыйын, туурабы? Албетте, автоматташтыруу кандайдыр бир түрдө болгон, бирок үзгүлтүксүз интеграция жана кодду жеткирүү үчүн өзүнчө багыт 2015-жылы калыптана баштаган.
Ошол кезде бизде Linux/Windows серверлеринде орнотулган Python, C# жана PHPдин чоң монолиттери бар болчу. Бул желмогузду жайгаштыруу үчүн биз кол менен иштеткен бир катар скрипттерге ээ болдук. Ошондой эле бутактарды бириктирүү, кемчиликтерди оңдоо жана «курулушта ар кандай тапшырмалар менен» кайра куруудагы чыр-чатактардан улам кайгы жана азап алып келген монолиттин жыйыны болду. Жөнөкөйлөтүлгөн процесс төмөнкүдөй көрүндү:
Биз буга ыраазы болгон жокпуз жана биз кайталануучу, автоматташтырылган жана башкара ала турган куруу жана жайылтуу процессин кургубуз келди. Бул үчүн бизге CI/CD системасы керек болчу жана биз Teamcity'тин акысыз версиясын жана Дженкинстин акысыз версиясын тандап алдык, анткени биз алар менен иштешип, функциялардын жыйындысы боюнча экөөбүзгө тең туура келген. Биз Teamcity'ди акыркы продукт катары тандадык. Ал убакта биз микросервис архитектурасын колдоно элек болчубуз жана көп сандагы тапшырмаларды жана долбоорлорду күткөн эмеспиз.
Биз өзүбүздүн системабыздын идеясына келдик
Teamcity программасын ишке ашыруу кол ишинин бир бөлүгүн гана алып салды: Тартуу өтүнүчтөрүн түзүү, Жирадагы статустар боюнча маселелерди жылдыруу жана чыгаруу үчүн маселелерди тандоо. Teamcity системасы мындан ары муну көтөрө албайт. Андан ары автоматташтыруунун жолун тандап алуу керек эле. Биз Teamcity скрипттери менен иштөө же үчүнчү тараптын автоматташтыруу системаларына өтүү жолдорун карап чыктык. Бирок акыры биз өзүбүздүн чечимибиз менен камсыз кыла турган максималдуу ийкемдүүлүк керек деп чечтик. Integro деп аталган ички автоматташтыруу системасынын биринчи версиясы ушундайча пайда болгон.
Teamcity куруу жана жайылтуу процесстерин ишке киргизүү деңгээлинде автоматташтыруу менен алектенет, ал эми Integro иштеп чыгуу процесстерин жогорку деңгээлдеги автоматташтырууга басым жасады. Bitbucket'те байланышкан баштапкы кодду иштетүү менен Jiraдагы маселелер менен ишти айкалыштыруу керек болчу. Бул этапта Integro ар кандай типтеги тапшырмалар менен иштөө үчүн өзүнүн иш процесстерине ээ боло баштады.
Бизнес процесстеринде автоматташтыруунун көбөйүшүнө байланыштуу Teamcityде долбоорлордун жана чуркоолордун саны көбөйдү. Ошентип, жаңы көйгөй келип чыкты: бир акысыз Teamcity инстанциясы жетишсиз болду (3 агент жана 100 долбоор), биз дагы бир инстанцияны (дагы 3 агент жана 100 долбоор), анан башкасын коштук. Натыйжада, биз башкаруу кыйын болгон бир нече кластердик системага ээ болдук:
4-инстанция боюнча маселе көтөрүлгөндө, биз мындан ары мындай жашай албасыбызды түшүндүк, анткени 4 инстанцияны колдоонун жалпы чыгымдары эч кандай чектерде болбой калды. Акы төлөнүүчү Teamcity сатып алуу же бекер Дженкинсти тандоо жөнүндө суроо пайда болду. Биз инстанциялар жана автоматташтыруу пландары боюнча эсептөөлөрдү жүргүзүп, Дженкинсте жашайбыз деп чечтик. Бир нече жумадан кийин биз Дженкинске өтүп, бир нече Teamcity инстанцияларын сактоо менен байланышкан баш ооруну жок кылдык. Ошондуктан, биз Integroну өнүктүрүүгө жана Дженкинсти өзүбүзгө ылайыкташтырууга көңүл бура алдык.
Негизги автоматташтыруунун өсүшү менен (Тартуу суроо-талаптарын автоматтык түрдө түзүү, Коддун камтылышын чогултуу жана жарыялоо жана башка текшерүүлөр түрүндө) мүмкүн болушунча кол менен чыгаруудан баш тартып, бул ишти роботторго берүүгө катуу каалоо бар. Мындан тышкары, компания тез-тез чыгарууну талап кылган компаниянын ичиндеги микросервистерге жана бири-биринен өзүнчө көчүп баштады. Ошентип, биз акырындык менен микросервисибиздин автоматтык түрдө чыгарылышына келдик (биз процесстин татаалдыгынан улам монолитти кол менен чыгарып жатабыз). Бирок, адаттагыдай эле, жаңы татаалдык пайда болду.
Биз тестирлөө автоматташтырылган
Чыгарууларды автоматташтыруудан улам, айрым тестирлөө этаптарын өткөрүп жиберүүнүн эсебинен иштеп чыгуу процесстери тездеди. Ал эми бул сапаттын убактылуу жоголушуна алып келди. Бул анча-мынча угулат, бирок релиздерди тездетүү менен бирге, продукт иштеп чыгуу методологиясын өзгөртүү керек болчу. Тестти автоматташтыруу, чыгарылган код жана андагы мүчүлүштүктөр үчүн иштеп чыгуучунун жеке жоопкерчилигин (бул жерде сөз акчалай айып эмес, “ойду башына кабыл алуу” жөнүндө болуп жатат), ошондой эле чечим кабыл алуу жөнүндө ойлонуу керек болчу. автоматтык жайгаштыруу аркылуу тапшырманы чыгаруу/бошотпоо.
Сапат көйгөйлөрүн жоюп, биз эки маанилүү чечимге келдик: биз канарлык тестирлөө жүргүзө баштадык жана ката фонуна анын ашыкча жооп берүүсү менен автоматтык түрдө мониторингди киргиздик. Биринчи чечим код толугу менен өндүрүшкө чыгарылганга чейин ачык каталарды табууга мүмкүндүк берди, экинчиси өндүрүштөгү көйгөйлөргө жооп берүү убактысын кыскартты. Каталар, албетте, болот, бирок биз убактыбыздын жана күчүбүздүн көбүн аларды оңдоого эмес, аларды азайтууга жумшайбыз.
Автоматташтыруу командасы
Учурда бизде 130 иштеп чыгуучу штат бар жана биз улантып жатабыз . Үзгүлтүксүз интеграция жана кодду жеткирүү боюнча команда (мындан ары Жайгаштыруу жана интеграциялоо же DI командасы) 7 адамдан турат жана 2 багытта иштейт: Integro автоматташтырылган платформасын жана DevOps иштеп чыгуу.
DevOps CIAN сайтынын Dev/Beta чөйрөсү, Integro чөйрөсү үчүн жооп берет, иштеп чыгуучуларга көйгөйлөрдү чечүүгө жардам берет жана чөйрөлөрдү масштабдаштырууга жаңы ыкмаларды иштеп чыгат. Integro өнүктүрүү багыты Integro өзүнө да, ага тиешелүү кызматтарга да тиешелүү, мисалы, Jenkins, Jira, Confluence үчүн плагиндер, ошондой эле өнүктүрүү топтору үчүн көмөкчү утилиталарды жана тиркемелерди иштеп чыгат.
DI командасы Архитектураны, китепканаларды жана өнүктүрүү ыкмаларын иштеп чыгуучу Platform командасы менен биргелешип иштейт. Ошол эле учурда, CIAN ичиндеги ар бир иштеп чыгуучу автоматташтырууга салым кошо алат, мисалы, команданын муктаждыктарына ылайыктуу микроавтоматташтыруу жасай алат же автоматташтырууну дагы жакшыраак кылуу боюнча сонун идея менен бөлүшө алат.
CIANдагы автоматташтырылган катмар торт
Автоматташтырууга катышкан бардык системаларды бир нече катмарга бөлүүгө болот:
- Тышкы системалар (Jira, Bitbucket ж.б.). Алар менен иштеп чыгуу топтору иштешет.
- Integro платформасы. Көпчүлүк учурда, иштеп чыгуучулар аны менен түздөн-түз иштебейт, бирок бул бардык автоматташтырууну камсыз кылат.
- Жеткирүү, оркестрлөө жана ачылыш кызматтары (мисалы, Jeknins, Consul, Nomad). Алардын жардамы менен биз серверлерге кодду жайгаштырабыз жана кызматтардын бири-бири менен иштешин камсыздайбыз.
- Физикалык катмар (серверлер, ОС, тиешелүү программалык камсыздоо). Биздин код ушул деңгээлде иштейт. Бул физикалык сервер же виртуалдык сервер (LXC, KVM, Docker) болушу мүмкүн.
Бул концепциянын негизинде биз DI командасынын ичиндеги жоопкерчилик чөйрөлөрүн бөлүштүрөбүз. Биринчи эки деңгээл Integro өнүктүрүү багытынын жоопкерчилиги чөйрөсүндө, ал эми акыркы эки деңгээл DevOps жоопкерчилигинин чөйрөсүндө. Бул бөлүнүү милдеттерге көңүл бурууга мүмкүндүк берет жана өз ара аракеттенүүгө тоскоолдук кылбайт, анткени биз бири-бирибизге жакынбыз жана дайыма билим жана тажрыйба алмашып турабыз.
Бүтүлбөгөн
Келгиле, Integroге көңүл буралы жана технологиялык стектен баштайлы:
- CentOS 7
- Docker + Nomad + Consul + Vault
- Java 11 (эски Integro монолит Java 8де калат)
- Spring Boot 2.X + Spring Cloud Config
- PostgreSql 11
- Rabbit MQ
- Apache Ignite
- Камунда (киргизилген)
- Grafana + Graphite + Prometheus + Jaeger + ELK
- Веб UI: React (CSR) + MobX
- SSO: Keycloak
Интегронун алгачкы версиясынын монолит түрүндөгү мурасыбыз болсо да, биз микросервисти өнүктүрүү принцибин карманабыз. Ар бир микросервис өзүнүн Docker контейнеринде иштейт жана кызматтар HTTP сурамдары жана RabbitMQ билдирүүлөрү аркылуу бири-бири менен байланышат. Микросервистер бири-бирин Консул аркылуу табышат жана SSO (Keycloak, OAuth 2/OpenID Connect) аркылуу авторизациядан өтүп, ага өтүнүч жөнөтүшөт.
Чыныгы жашоодон мисал катары, төмөнкү кадамдардан турган Дженкинс менен өз ара аракеттенүүнү карап көрөлү:
- Иш агымын башкаруу микросервиси (мындан ары - Flow микросервиси) Дженкинсте түзүүнү иштетүүнү каалайт. Бул үчүн, ал Jenkins менен интеграциялоо үчүн микросервистин IP: PORT'ун табуу үчүн Консулду колдонот (мындан ары Дженкинс микросервиси деп аталат) жана ага Дженкинсте курууну баштоо үчүн асинхрондук өтүнүч жөнөтөт.
- Сурам алгандан кийин, Дженкинс микросервиси жумуштун идентификаторун түзүп, жооп берет, андан кийин иштин жыйынтыгын аныктоо үчүн колдонулушу мүмкүн. Ошол эле учурда, ал REST API чалуу аркылуу Дженкинсте курууну ишке киргизет.
- Дженкинс курууну ишке ашырат жана аяктагандан кийин Женкинс микросервисине аткаруу натыйжалары менен вебхук жөнөтөт.
- Jenkins микросервиси вебхукту кабыл алып, суроо-талапты иштеп чыгуу аяктагандыгы жөнүндө билдирүүнү жаратат жана ага аткаруунун натыйжаларын тиркейт. Түзүлгөн билдирүү RabbitMQ кезегине жөнөтүлөт.
- RabbitMQ аркылуу жарыяланган билдирүү Flow микросервисине жетет, ал суроо-талаптагы Job ID менен кабыл алынган билдирүүгө дал келүү аркылуу өзүнүн тапшырмасын иштетүүнүн натыйжасы жөнүндө билип алат.
Азыр бизде 30га жакын микросервис бар, аларды бир нече топко бөлүүгө болот:
- Конфигурацияны башкаруу.
- Маалымат жана колдонуучулар менен өз ара аракеттенүү (мессенджерлер, почта).
- Булак коду менен иштөө.
- Жайгаштыруу куралдары менен интеграция (jenkins, nomad, consul, ж.б.).
- Мониторинг (релиздер, каталар ж.б.).
- Веб-утилиталар (сыноо чөйрөсүн башкаруу, статистиканы чогултуу ж.б. үчүн UI).
- Тапшырма трекерлери жана ушул сыяктуу системалар менен интеграция.
- Ар кандай тапшырмалар үчүн иштөө процессин башкаруу.
Жумуш процессинин тапшырмалары
Integro тапшырманын жашоо циклине байланыштуу иш-аракеттерди автоматташтырат. Жөнөкөйлөтүлгөн сөз менен айтканда, тапшырманын жашоо цикли Jiraдагы тапшырманын иштөө процесси катары түшүнүлөт. Биздин иштеп чыгуу процесстеринде долбоорго, тапшырманын түрүнө жана белгилүү бир тапшырмада тандалган варианттарга жараша бир нече иш процесстери бар.
Биз көбүнчө колдонгон иш процессин карап көрөлү:
Диаграммада тиштүү өтүү Integro тарабынан автоматтык түрдө чакырыла тургандыгын көрсөтүп турат, ал эми адам фигура өткөөл адам тарабынан кол менен чакырыларын көрсөтүп турат. Келгиле, бул иш процессинде тапшырма ала турган бир нече жолдорду карап көрөлү.
Канар сыноолору жок DEV+BETA боюнча толук кол менен тестирлөө (көбүнчө биз монолитти ушундайча чыгарабыз):
Башка өткөөл комбинациялар болушу мүмкүн. Кээде маселе чыга турган жол Jiraдагы опциялар аркылуу тандалып алынышы мүмкүн.
Тапшырма кыймылы
Келгиле, тапшырма "DEV Testing + Canary Tests" иш процесси аркылуу өткөндө аткарылуучу негизги кадамдарды карап көрөлү:
1. Иштеп чыгуучу же PM тапшырманы түзөт.
2. Иштеп чыгуучу тапшырманы ишке алат. Аяктагандан кийин, ал IN REVIEW статусуна өтөт.
3. Jira Jira микросервисине Webhook жөнөтөт (Jira менен интеграция үчүн жооптуу).
4. Jira микросервиси иш процессин баштоо үчүн Flow кызматына (иш аткарылган ички иш процесстерине жооптуу) суроо-талап жөнөтөт.
5. Flow кызматынын ичинде:
- Тапшырмага кароочулар дайындалган (Колдонуучулар жөнүндө бардыгын билген микросервис + Jira микросервиси).
- Source микросервиси аркылуу (ал репозиторийлер жана филиалдар жөнүндө билет, бирок коддун өзү менен иштебейт) биздин чыгарылыштын бутагын камтыган репозиторийлерди издөө жүргүзүлөт (издөөнү жөнөкөйлөтүү үчүн филиалдын аталышы маселе менен дал келет) Жирадагы номер). Көбүнчө тапшырманын бир репозиторийде бир гана бутагы болот; бул жайгаштыруу кезегин башкарууну жеңилдетет жана репозиторийлердин ортосундагы байланышты азайтат.
- Ар бир табылган бутак үчүн төмөнкү аракеттердин ырааттуулугу аткарылат:
i) Башкы филиалды жаңылоо (код менен иштөө үчүн Git микросервиси).
ii) Филиалга иштеп чыгуучу тарабынан өзгөртүүлөр бөгөттөлгөн (Bitbucket микросервиси).
iii) Бул филиал үчүн Тартуу өтүнүчү түзүлдү (Bitbucket микросервиси).
iv) Жаңы тартуу өтүнүчү жөнүндө билдирүү иштеп чыгуучунун чаттарына жөнөтүлөт (билдирмелер менен иштөө үчүн микросервиске кабарлаңыз).
v) DEV (Дженкинс менен иштөө үчүн Дженкинс микросервиси) боюнча тапшырмаларды куруу, сыноо жана жайылтуу башталат.
vi) Эгерде бардык мурунку кадамдар ийгиликтүү аяктаса, анда Integro өзүнүн жактыруусун тартуу өтүнүчүнө (Bitbucket микросервисине) коет. - Integro дайындалган кароочулардан тартуу өтүнүчүндө жактырууну күтөт.
- Бардык керектүү уруксаттар алынгандан кийин (анын ичинде автоматташтырылган тесттер оңдон өткөн), Integro тапшырманы Test on Dev (Jira microservice) статусуна өткөрүп берет.
6. Сыноочулар тапшырманы сынашат. Эгерде көйгөйлөр жок болсо, анда тапшырма Курууга даяр статусуна которулат.
7. Integro тапшырманы чыгарууга даяр экенин "көрөт" жана аны канар режиминде жайылта баштайт (Дженкинс микросервис). Чыгарууга даярдыгы эрежелердин жыйындысы менен аныкталат. Мисалы, тапшырма талап кылынган статуста, башка тапшырмаларда кулпулар жок, учурда бул микросервистин жигердүү жүктөөлөрү жок ж.б.
8. Тапшырма Canary статусуна которулат (Jira microservice).
9. Дженкинс Nomad аркылуу канар режиминде (көбүнчө 1-3 инстанция) жайылтуу тапшырмасын ишке киргизет жана релизге мониторинг жүргүзүү кызматына (DeployWatch микросервиси) жайылтуу жөнүндө кабарлайт.
10. DeployWatch микросервиси ката фонун чогултат жана зарыл болсо, ага жооп берет. Ката фону ашып кетсе (фондук норма автоматтык түрдө эсептелет), иштеп чыгуучуларга Notify микросервиси аркылуу кабарланат. Эгерде 5 мүнөттөн кийин иштеп чыгуучу жооп бербесе (Кайра кайтаруу же Калууну чыкылдатыңыз), анда канарлык инстанцияларды автоматтык түрдө артка кайтаруу ишке киргизилет. Эгерде фон ашпаса, анда иштеп чыгуучу Өндүрүшкө тапшырманы жайгаштырууну кол менен ишке киргизиши керек (UI'деги баскычты чыкылдатуу менен). Эгерде 60 мүнөттүн ичинде иштеп чыгуучу Өндүрүшкө жайылтууну баштабаса, анда коопсуздук себептеринен улам канария инстанциялары да артка кайтарылат.
11. Өндүрүшкө киргизүүнү ишке киргизгенден кийин:
- Тапшырма Өндүрүш статусуна которулат (Jira микросервис).
- Jenkins микросервиси жайылтуу процессин баштайт жана DeployWatch микросервисине жайгаштыруу жөнүндө кабарлайт.
- DeployWatch микросервиси өндүрүштөгү бардык контейнерлердин жаңыртылганын текшерет (баары жаңыланбаган учурлар болгон).
- Notify микросервиси аркылуу Өндүрүшкө жайылтуунун натыйжалары жөнүндө билдирүү жөнөтүлөт.
12. Микросервистин туура эмес жүрүм-туруму аныкталса, иштеп чыгуучуларга Өндүрүштөн тапшырманы артка кайтарып баштоо үчүн 30 мүнөт убакыт берилет. Бул убакыттан кийин, тапшырма автоматтык түрдө мастерге (Git микросервисине) бириктирилет.
13. Мастерге ийгиликтүү кошулгандан кийин тапшырма статусу Жабык (Jira микросервиси) болуп өзгөрөт.
Диаграмма өзүн толугу менен деталдаштырбайт (чындыгында андан да көп кадамдар бар), бирок ал процесстерге интеграциянын даражасын баалоого мүмкүндүк берет. Биз бул схеманы идеалдуу деп эсептебейбиз жана автоматтык чыгаруу жана жайылтууну колдоо процесстерин өркүндөтүп жатабыз.
кийинкиси эмне
Бизде автоматташтырууну өнүктүрүү боюнча чоң пландар бар, мисалы, монолит чыгаруу учурунда кол менен иштөөнү жокко чыгаруу, автоматтык түрдө жайылтуу учурунда мониторингди жакшыртуу жана иштеп чыгуучулар менен өз ара аракеттенүүнү жакшыртуу.
Бирок, келгиле, азыр ушул жерден токтойлу. Биз автоматташтырылган серепте көптөгөн темаларды үстүртөн карадык, кээ бирлери такыр козголбойт, андыктан суроолорго жооп берүүгө кубанычтабыз. Эмнени кенен чагылдыруу боюнча сунуштарды күтөбүз, комментарийге жазыңыз.
Source: www.habr.com