RIT 2019 көрмесінде біздің әріптесіміз Александр Коротков жасады CIAN-да әзірлеуді автоматтандыру туралы: өмір мен жұмысты жеңілдету үшін біз жеке Integro платформасын қолданамыз. Ол тапсырмалардың өмірлік циклін бақылайды, әзірлеушілерді әдеттегі операциялардан босатады және өндірістегі қателер санын айтарлықтай азайтады. Бұл жазбада біз Александрдың есебін толықтырамыз және қарапайым сценарийлерден ашық бастапқы өнімдерді өз платформамыз арқылы біріктіруге қалай өткенімізді және біздің жеке автоматтандыру тобымыз не істейтінін айтамыз.
Нөлдік деңгей
«Нөлдік деңгей деген нәрсе жоқ, мен ондай нәрсені білмеймін»
«Кунг-фу панда» фильмінен Мастер Шифу
CIAN-да автоматтандыру компания құрылғаннан кейін 14 жылдан кейін басталды. Ол кезде әзірлеу тобында 35 адам болды. Сену қиын, солай ма? Әрине, автоматтандыру қандай да бір түрде болды, бірақ үздіксіз интеграция мен кодты жеткізудің жеке бағыты 2015 жылы қалыптаса бастады.
Ол кезде бізде Linux/Windows серверлерінде орналастырылған Python, C# және PHP-дің үлкен монолиті болды. Бұл құбыжықты қолдану үшін бізде қолмен орындалатын сценарийлер жинағы болды. Сондай-ақ, монолитті құрастыру болды, ол бұтақтарды біріктіру, ақауларды түзету және «құрылыстағы басқа тапсырмалар жиынтығымен» қайта құру кезінде жанжалдарға байланысты ауырсыну мен азап әкелді. Жеңілдетілген процесс келесідей болды:
Біз бұған риза емеспіз және қайталанатын, автоматтандырылған және басқарылатын құрастыру және орналастыру процесін құрғымыз келді. Ол үшін бізге CI/CD жүйесі қажет болды және біз Teamcity-тің тегін нұсқасы мен Дженкинстің тегін нұсқасын таңдадық, өйткені біз олармен жұмыс істедік және функциялар жиынтығы бойынша екеуіміз де сәйкес келдік. Біз жаңа өнім ретінде Teamcity-ті таңдадық. Ол кезде біз микросервис архитектурасын әлі пайдаланбаған едік және көптеген тапсырмалар мен жобаларды күткен жоқпыз.
Біз өз жүйеміз туралы идеяға келеміз
Teamcity-ті енгізу қолмен жұмыстың бір бөлігін ғана алып тастады: тарту сұрауларын жасау, Jira-дағы мәртебе бойынша мәселелерді жылжыту және шығарылатын мәселелерді таңдау қалды. 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
- Қоян MQ
- Apache Ignite
- Камунда (ендірілген)
- Графана + Графит + Прометей + Джегер + ЭЛК
- Web UI: React (CSR) + MobX
- SSO: пернетақта
Integro ерте нұсқасының монолиті түріндегі мұрамыз болса да, біз микросервистерді әзірлеу принципін ұстанамыз. Әрбір микросервис өзінің Docker контейнерінде жұмыс істейді және қызметтер HTTP сұраулары және RabbitMQ хабарлары арқылы бір-бірімен байланысады. Микросервистер бір-бірін Консул арқылы табады және SSO (Keycloak, OAuth 2/OpenID Connect) арқылы авторизациядан өтіп, оған сұрау салады.
Нақты өмірлік мысал ретінде келесі қадамдардан тұратын Дженкинспен әрекеттесуді қарастырыңыз:
- Жұмыс процесін басқару микросервисі (бұдан әрі - Ағын микросервисі) Дженкинстегі құрастыруды іске қосқысы келеді. Мұны істеу үшін ол Дженкинспен (бұдан әрі Дженкинс микросервисі) біріктіру үшін микросервистің IP:PORT мекенжайын табу үшін Консулды пайдаланады және оған Дженкинстегі құрастыруды бастау үшін асинхронды сұрау жібереді.
- Сұрауды алғаннан кейін Дженкинс микросервисі жұмыс идентификаторын жасайды және оған жауап береді, содан кейін оны жұмыс нәтижесін анықтау үшін пайдалануға болады. Сонымен бірге ол Дженкинстегі құрастыруды REST API шақыруы арқылы іске қосады.
- Дженкинс құрастыруды орындайды және аяқталғаннан кейін Дженкинс микросервисіне орындау нәтижелерімен веб-хук жібереді.
- Jenkins микросервисі веб-хукты алып, сұрауды өңдеудің аяқталғаны туралы хабарламаны жасайды және оған орындау нәтижелерін тіркейді. Жасалған хабарлама RabbitMQ кезегіне жіберіледі.
- RabbitMQ арқылы жарияланған хабар Flow микросервисіне жетеді, ол сұраудан және алынған хабардан жұмыс идентификаторын сәйкестендіру арқылы өз тапсырмасын өңдеу нәтижесі туралы біледі.
Қазір бізде 30-ға жуық микросервис бар, оларды бірнеше топқа бөлуге болады:
- Конфигурацияны басқару.
- Ақпарат және пайдаланушылармен өзара әрекеттесу (мессенджерлер, пошта).
- Бастапқы кодпен жұмыс.
- Орналастыру құралдарымен интеграция (дженкинс, номад, консул және т.б.).
- Бақылау (шығарылымдар, қателер және т.б.).
- Веб утилиталары (тест орталарын басқаруға арналған UI, статистиканы жинау және т.б.).
- Тапсырма трекерлерімен және ұқсас жүйелермен интеграция.
- Әртүрлі тапсырмалар үшін жұмыс процесін басқару.
Жұмыс процесі тапсырмалары
Integro тапсырманың өмірлік цикліне қатысты әрекеттерді автоматтандырады. Жеңілдетілген тілмен айтқанда, тапсырманың өмірлік циклі Jira-дағы тапсырманың жұмыс процесі ретінде түсініледі. Біздің әзірлеу процестерінде жобаға, тапсырма түріне және белгілі бір тапсырмада таңдалған опцияларға байланысты жұмыс үрдісінің бірнеше нұсқалары бар.
Біз жиі қолданатын жұмыс процесін қарастырайық:
Диаграммада беріліс ауысуды Integro автоматты түрде шақыратынын көрсетеді, ал адам фигурасы ауысуды адам қолмен шақыратынын көрсетеді. Осы жұмыс процесінде тапсырма қабылдай алатын бірнеше жолды қарастырайық.
Канар сынақтарынсыз DEV+BETA толық қолмен тестілеу (әдетте біз монолитті осылай шығарамыз):
Басқа өтпелі комбинациялар болуы мүмкін. Кейде мәселе шешілетін жолды Jira ішіндегі опциялар арқылы таңдауға болады.
Тапсырма қозғалысы
Тапсырма «DEV Testing + Canary Tests» жұмыс процесі арқылы өткенде орындалатын негізгі қадамдарды қарастырайық:
1. Әзірлеуші немесе ПМ тапсырманы жасайды.
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 микросервис).
9. Дженкинс канарей режимінде (әдетте 1-3 дана) Nomad арқылы орналастыру тапсырмасын іске қосады және шығаруды бақылау қызметіне (DeployWatch микросервис) орналастыру туралы хабарлайды.
10. DeployWatch микросервисі қате фонын жинайды және қажет болса, оған әрекет етеді. Қате фоны асып кетсе (фондық норма автоматты түрде есептеледі), әзірлеушілерге Notify микросервисі арқылы хабарланады. Егер 5 минуттан кейін әзірлеуші жауап бермесе (Қайтару немесе Қалу түймешігін басыңыз), онда канарей даналарының автоматты кері қайтарылуы іске қосылады. Егер фон асып кетпесе, әзірлеуші тапсырманы Өндіріске орналастыруды қолмен іске қосуы керек (UI ішіндегі түймені басу арқылы). Егер 60 минут ішінде әзірлеуші Өндіріске орналастыруды іске қоспаса, қауіпсіздік мақсатында канарей даналары да кері қайтарылады.
11. Өндіріске орналастыруды іске қосқаннан кейін:
- Тапсырма Өндіріс күйіне ауыстырылды (Jira микросервис).
- Jenkins микросервисі орналастыру процесін бастайды және DeployWatch микросервисіне орналастыру туралы хабарлайды.
- DeployWatch микросервисі Өндірістегі барлық контейнерлердің жаңартылғанын тексереді (барлығы жаңартылмаған жағдайлар болды).
- Notify микросервисі арқылы Өндіріске орналастыру нәтижелері туралы хабарлама жіберіледі.
12. Қате микросервис әрекеті анықталса, әзірлеушілерге тапсырманы өндірістен кері қайтаруды бастау үшін 30 минут уақыты болады. Осы уақыттан кейін тапсырма автоматты түрде мастерге (Git микросервисіне) біріктіріледі.
13. Негізгіге сәтті біріктірілгеннен кейін тапсырма күйі Жабық (Jira микросервисі) күйіне өзгертіледі.
Диаграмма өзін толығымен егжей-тегжейлі көрсетпейді (шын мәнінде одан да көп қадамдар бар), бірақ ол процестерге интеграция дәрежесін бағалауға мүмкіндік береді. Біз бұл схеманы идеалды деп санамаймыз және автоматты шығару және орналастыруды қолдау процестерін жетілдіреміз.
Ары қарай не
Бізде автоматтандыруды дамыту бойынша үлкен жоспарлар бар, мысалы, монолитті шығару кезінде қолмен жасалатын операцияларды жою, автоматты орналастыру кезінде бақылауды жақсарту және әзірлеушілермен өзара әрекеттесуді жақсарту.
Бірақ әзірше осы жерден тоқталайық. Біз автоматтандыруды шолуда көптеген тақырыптарды үстірт қарастырдық, кейбіреулері мүлдем қозғалмады, сондықтан біз сұрақтарға жауап беруге қуаныштымыз. Біз нені егжей-тегжейлі қамту керектігі туралы ұсыныстарды күтеміз, түсініктемелерде жазыңыз.
Ақпарат көзі: www.habr.com