Мен Inventos компаниясынан Александр Сигачевтің «Docker + Gitlab CI көмегімен әзірлеу және тестілеу процесі» баяндамасының стенограммасын оқуды ұсынамын.
Docker + Gitlab CI негізінде әзірлеу және тестілеу процесін енді ғана жүзеге асыра бастағандар жиі негізгі сұрақтарды қояды. Неден бастау керек? Қалай ұйымдастыру керек? Қалай сынауға болады?
Бұл есеп жақсы, өйткені ол Docker және Gitlab CI көмегімен әзірлеу және тестілеу процесі туралы құрылымдық түрде әңгімелейді. Есептің өзі 2017 жылғы. Менің ойымша, бұл баяндамадан сіз негіздерді, әдістемені, идеяны, пайдалану тәжірибесін білуге болады.
Кімге бәрібір, мысықтың астында өтінемін.
Менің атым Александр Сигачев. Мен Inventos компаниясында жұмыс істеймін. Мен сізге Docker-ті пайдалану тәжірибем туралы және оны компаниядағы жобаларға қалай біртіндеп енгізіп жатқанымыз туралы айтып беремін.
Презентация тақырыбы: Docker және Gitlab CI көмегімен әзірлеу процесі.
Бұл менің Docker туралы екінші әңгімем. Бірінші есеп беру кезінде біз тек әзірлеуші машиналарында Docker-ті әзірлеуде қолдандық. Docker пайдаланған қызметкерлер саны шамамен 2-3 адам болды. Бірте-бірте тәжірибе жинақталып, біраз алға жылжыдық. Біздің сілтеме .
Бұл есепте не болады? Біз қандай тырма жинағанымыз, қандай мәселелерді шешкеніміз туралы тәжірибемізбен бөлісеміз. Барлық жерде әдемі емес еді, бірақ әрі қарай жүруге мүмкіндік берді.
Біздің ұранымыз: қолымыздан келгеннің бәрін орнату.
Біз қандай мәселелерді шешіп жатырмыз?
Компанияда бірнеше команда болған кезде, бағдарламашы ортақ ресурс болып табылады. Бағдарламашыны бір жобадан шығарып, біраз уақытқа басқа жобаға тапсыратын кезеңдері бар.
Бағдарламашы тез түсіну үшін жобаның бастапқы кодын жүктеп алып, ортаны мүмкіндігінше тезірек іске қосу керек, бұл оған осы жобаның мәселелерін одан әрі шешуге мүмкіндік береді.
Әдетте, егер сіз нөлден бастасаңыз, жобада құжаттама аз болады. Орнату жолы туралы ақпарат тек ескі адамдар үшін қолжетімді. Қызметкерлер жұмыс орнын бір-екі күнде өз бетінше орнатады. Мұны жылдамдату үшін біз Docker қолдандық.
Келесі себеп - әзірлеудегі параметрлерді стандарттау. Менің тәжірибемде әзірлеушілер әрқашан бастама көтереді. Әрбір бесінші жағдайда пайдаланушы домені енгізіледі, мысалы, vasya.dev. Оның қасында көрші Петя отыр, оның домені petya.dev. Олар осы домен атауын пайдаланып веб-сайтты немесе жүйенің кейбір құрамдас бөлігін әзірлейді.
Жүйе өсіп, бұл домен атаулары конфигурацияларға кіре бастағанда, әзірлеу ортасының қайшылығы туындап, торап жолы қайта жазылады.
Дерекқор параметрлерімен де солай болады. Біреу қауіпсіздікпен алаңдамайды және бос түбірлік құпия сөзбен жұмыс істейді. Орнату кезеңінде MySQL біреуден құпия сөз сұрады және құпия сөз 123 болып шықты. Дерекқор конфигурациясы әзірлеушінің міндеттемесіне байланысты үнемі өзгеріп отырады. Біреу түзетті, біреу конфигурацияны түзетпеді. Біз қандай да бір сынақ конфигурациясын шығарған кезде айлалар болды .gitignore және әрбір әзірлеуші дерекқорды орнатуы керек болды. Бұл бастауды қиындатты. Басқа нәрселермен қатар, деректер қоры туралы есте сақтау қажет. Мәліметтер базасы инициализациялануы керек, пароль енгізілуі керек, пайдаланушы тіркелуі керек, кесте құрылуы керек және т.б.
Тағы бір мәселе - кітапханалардың әртүрлі нұсқалары. Әзірлеуші әртүрлі жобалармен жұмыс істейтіні жиі кездеседі. Бес жыл бұрын (2017 жылдан бастап – ред. ескертпе) басталған Legacy жобасы бар. Іске қосу кезінде біз MySQL 5.5-тен бастадық. Сондай-ақ қазіргі заманғы жобалар бар, оларда біз MySQL-тің неғұрлым заманауи нұсқаларын енгізуге тырысамыз, мысалы, 5.7 немесе одан жоғары (2017 жылы – ред. ескертпе)
MySQL-пен жұмыс істейтін кез келген адам бұл кітапханалардың өзімен бірге тәуелділіктерді әкелетінін біледі. Екі базаны бірге іске қосу өте қиын. Кем дегенде, ескі клиенттердің жаңа дерекқорға қосылуы қиын. Бұл өз кезегінде бірнеше проблемаларды тудырады.
Келесі мәселе - әзірлеуші жергілікті машинада жұмыс істегенде, ол жергілікті ресурстарды, жергілікті файлдарды, жергілікті жедел жадты пайдаланады. Мәселелердің шешімін әзірлеу кезіндегі барлық өзара әрекеттесу оның бір машинада жұмыс істеуі шеңберінде жүзеге асырылады. Мысал ретінде бізде 3-өндірістегі сервер серверлері бар және әзірлеуші файлдарды түбірлік каталогқа сақтайды және сол жерден nginx сұрауға жауап беру үшін файлдарды алады. Мұндай код Өндіріске түскенде, файл 3 сервердің бірінде бар екені белгілі болды.
Қазір микросервистердің бағыты дамып келеді. Үлкен қолданбаларымызды бір-бірімен әрекеттесетін кейбір шағын құрамдастарға бөлгенде. Бұл тапсырмалардың белгілі бір дестесі үшін технологияларды таңдауға мүмкіндік береді. Ол сондай-ақ әзірлеушілер арасында жұмыс пен жауапкершілікті бөлісуге мүмкіндік береді.
JS жүйесінде дамып келе жатқан Frondend-әзірлеуші Backend-ке дерлік әсер етпейді. Backend әзірлеушісі, өз кезегінде, біздің жағдайда, Ruby on Rails әзірлейді және Фрондендке кедергі жасамайды. Өзара әрекеттесу API арқылы жүзеге асырылады.
Бонус ретінде, Docker көмегімен біз Staging жүйесінде ресурстарды қайта өңдей алдық. Әрбір жоба өзінің ерекшеліктеріне байланысты белгілі бір параметрлерді қажет етті. Физикалық тұрғыдан не виртуалды серверді бөліп, оларды бөлек конфигурациялау қажет болды, не айнымалы ортаның қандай да бір түрін ортақ пайдалану керек болды және кітапханалардың нұсқасына байланысты жобалар бір-біріне әсер етуі мүмкін.
Құралдар. Біз нені пайдаланамыз?
- Докердің өзі. Dockerfile бір қолданбаның тәуелділіктерін сипаттайды.
- Docker-compose - бұл бірнеше Docker қолданбаларын біріктіретін жинақ.
- Біз бастапқы кодты сақтау үшін GitLab пайдаланамыз.
- Біз жүйені біріктіру үшін GitLab-CI қолданамыз.
Есеп екі бөлімнен тұрады.
Бірінші бөлімде Docker әзірлеушілер машиналарында қалай іске қосылғаны туралы айтылады.
Екінші бөлімде GitLab-пен қалай әрекеттесетініміз, сынақтарды қалай жүргізетініміз және Staging бағдарламасына қалай шығатынымыз туралы айтылады.
Docker – қажетті құрамдастарды сипаттауға мүмкіндік беретін (декларативті тәсілді қолдана отырып) технология. Бұл Dockerfile мысалы. Бұл жерде біз ресми Ruby:2.3.0 Docker кескінінен мұрагер екенімізді мәлімдейміз. Онда орнатылған Ruby 2.3 нұсқасы бар. Біз қажетті құрастыру кітапханаларын және NodeJS орнатамыз. Біз каталогты жасайтынымызды сипаттаймыз /app. Қолданба каталогын жұмыс каталогы ретінде орнатыңыз. Бұл каталогта біз қажетті минималды Gemfile және Gemfile.lock файлдарын орналастырамыз. Содан кейін біз осы тәуелділік кескінін орнататын жобаларды жасаймыз. Біз контейнер 3000 сыртқы портында тыңдауға дайын болатынын көрсетеміз. Соңғы пәрмен біздің қолданбаны тікелей іске қосатын пәрмен болып табылады. Жобаны бастау командасын орындасақ, қолданба көрсетілген пәрменді іске қосып, іске қосуға тырысады.
Бұл докер-құрастыру файлының минималды мысалы. Бұл жағдайда біз екі контейнер арасында байланыс бар екенін көрсетеміз. Бұл дерекқор қызметі мен веб-қызметіне тікелей кіреді. Біздің веб-қосымшалар көп жағдайда деректерді сақтау үшін сервер ретінде дерекқордың қандай да бір түрін қажет етеді. Біз MySQL-ті қолданып жатқандықтан, мысал MySQL-де - бірақ басқа дерекқорды (PostgreSQL, Redis) пайдалануымызға ештеңе кедергі келтірмейді.
Docker хабының ресми көзінен MySQL 5.7.14 кескінін өзгертусіз аламыз. Ағымдағы каталогтан веб-қосымшамызға жауап беретін кескінді жинаймыз. Ол бірінші іске қосу кезінде біз үшін сурет жинайды. Содан кейін ол біз осы жерде орындап жатқан пәрменді іске қосады. Егер біз кері оралсақ, Puma арқылы іске қосу пәрмені анықталғанын көреміз. Puma - Ruby тілінде жазылған қызмет. Екінші жағдайда біз бас тартамыз. Бұл пәрмен біздің қажеттіліктерімізге немесе тапсырмаларымызға байланысты ерікті болуы мүмкін.
Біз сондай-ақ әзірлеушінің хост машинасындағы портты контейнер портындағы 3000-нан 3000-ға дейін жіберу керек екенін сипаттаймыз. Бұл тікелей Docker ішіне енгізілген iptables және оның механизмі арқылы автоматты түрде орындалады.
Әзірлеуші сондай-ақ бұрынғыдай кез келген қолжетімді IP мекенжайына қол жеткізе алады, мысалы, 127.0.0.1 құрылғының жергілікті немесе сыртқы IP мекенжайы болып табылады.
Соңғы жолда веб-контейнер db контейнеріне байланысты екенін айтады. Біз веб-контейнердің басын шақырған кезде, docker-compose біз үшін алдымен дерекқорды бастайды. Қазірдің өзінде дерекқордың басында (шын мәнінде, контейнер іске қосылғаннан кейін! Бұл дерекқордың дайындығына кепілдік бермейді) қосымшаны, біздің бэкендімізді іске қосады.
Бұл дерекқор ашылмаған кезде қателерді болдырмайды және дерекқор контейнерін тоқтатқанда ресурстарды сақтайды, осылайша басқа жобалар үшін ресурстарды босатады.
Жобада дерекқорды докеризациялау бізге не береді. Біз барлық әзірлеушілер үшін MySQL нұсқасын түзетеміз. Бұл нұсқалар әр түрлі болғанда, синтаксис, конфигурация, әдепкі параметрлер өзгерген кезде туындауы мүмкін кейбір қателерді болдырмайды. Бұл мәліметтер базасының жалпы хост атын, логинді, парольді көрсетуге мүмкіндік береді. Біз бұрын болған конфигурация файлдарындағы атаулар мен қақтығыстар зоопаркінен алыстап жатырмыз.
Әзірлеу ортасы үшін әдепкіден ерекшеленетін оңтайлы конфигурацияны пайдалану мүмкіндігіміз бар. MySQL әдепкі бойынша әлсіз машиналар үшін конфигурацияланған және қораптан тыс оның өнімділігі өте нашар.
Docker сізге қажет нұсқаның Python, Ruby, NodeJS, PHP интерпретаторын пайдалануға мүмкіндік береді. Біз нұсқа менеджерінің қандай да бір түрін пайдалану қажеттілігінен құтыламыз. Бұрын Ruby жобаға байланысты нұсқаны өзгертуге мүмкіндік беретін rpm бумасын пайдаланған. Сондай-ақ, ол Docker контейнерінің арқасында кодты біркелкі тасымалдауға және оны тәуелділіктермен бірге нұсқасына беруге мүмкіндік береді. Бізде интерпретатордың да, кодтың да нұсқасын түсіну қиын емес. Нұсқаны жаңарту үшін ескі контейнерді түсіріп, жаңа контейнерді көтеріңіз. Егер бірдеңе дұрыс болмаса, жаңа контейнерді түсіріп, ескі контейнерді көтере аламыз.
Кескінді құрастырғаннан кейін әзірлеудегі де, өндірудегі де контейнерлер бірдей болады. Бұл әсіресе үлкен қондырғыларға қатысты.
Frontend жүйесінде JavaScipt және NodeJS пайдаланамыз.
Енді бізде ReacJS-тегі соңғы жоба бар. Әзірлеуші контейнердегі барлық нәрсені іске қосты және ыстық қайта жүктеу арқылы әзірледі.
Содан кейін JavaScipt құрастыру тапсырмасы іске қосылады және статикаға жинақталған код nginx ресурстарын үнемдеу арқылы беріледі.
Мұнда мен соңғы жобамыздың схемасын бердім.
Қандай міндеттер шешілді? Бізге мобильді құрылғылар өзара әрекеттесетін жүйені құру қажет болды. Олар деректерді алады. Мүмкіндіктердің бірі - бұл құрылғыға push хабарландыруларын жіберу.
Бұл үшін не істедік?
Біз қолданбаға келесідей компоненттерді бөлдік: JS жүйесіндегі әкімші бөлігі, Ruby on Rails астындағы REST интерфейсі арқылы жұмыс істейтін сервер. Сервер дерекқормен өзара әрекеттеседі. Жасалған нәтиже клиентке беріледі. Әкімші тақтасы сервермен және дерекқормен REST интерфейсі арқылы әрекеттеседі.
Бізде push хабарландыруларын жіберу қажет болды. Бұған дейін бізде мобильді платформаларға хабарландыруларды жеткізуге жауап беретін механизмді жүзеге асырған жоба болды.
Біз келесі схеманы әзірледік: браузердің операторы басқару панелімен әрекеттеседі, басқару тақтасы сервермен әрекеттеседі, тапсырма Push хабарландыруларын жіберу болып табылады.
Push хабарландырулары NodeJS жүйесінде енгізілген басқа құрамдаспен әрекеттеседі.
Кезектер құрастырылады, содан кейін олардың механизміне сәйкес хабарламалар жіберіледі.
Мұнда екі деректер базасы салынған. Қазіргі уақытта Docker көмегімен біз бір-бірімен ешқандай байланысы жоқ 2 тәуелсіз мәліметтер қорын қолданамыз. Сонымен қатар, олардың ортақ виртуалды желісі бар және физикалық деректер әзірлеушінің машинасында әртүрлі каталогтарда сақталады.
Дәл солай, бірақ сандарда. Бұл жерде кодты қайта пайдалану маңызды.
Егер бұрын біз кітапханалар түріндегі кодты қайта пайдалану туралы айтқан болсақ, онда бұл мысалда Push хабарландыруларына жауап беретін қызметіміз толық сервер ретінде қайта пайдаланылады. Ол API ұсынады. Біздің жаңа дамуымыз қазірдің өзінде онымен өзара әрекеттеседі.
Ол кезде біз NodeJS 4 нұсқасын қолдандық. Қазір (2017 жылы – ред. ескертпе) соңғы әзірлемелерде біз NodeJS 7 нұсқасын қолданамыз. Кітапханалардың жаңа нұсқаларын тарту үшін жаңа құрамдастарда ешқандай проблема жоқ.
Қажет болса, Push хабарландыру қызметінен NodeJS нұсқасын қайта өңдеуге және көтеруге болады.
Егер API үйлесімділігін сақтай алсақ, оны бұрын қолданылған басқа жобалармен ауыстыруға болады.
Docker қосу үшін не қажет? Біз репозиторийге қажетті тәуелділіктерді сипаттайтын Dockerfile қосамыз. Бұл мысалда компоненттер логикалық түрде бөлінген. Бұл сервер әзірлеушісінің ең аз жинағы.
Жаңа жобаны құру кезінде біз Dockerfile жасаймыз, қажетті экожүйені сипаттаймыз (Python, Ruby, NodeJS). Docker-compose-де ол қажетті тәуелділікті – мәліметтер базасын сипаттайды. Бізге осындай және осындай нұсқалардың деректер базасы қажет екенін сипаттаймыз, деректерді сол жерде және сол жерде сақтаймыз.
Біз статикалық қызмет көрсету үшін nginx бар бөлек үшінші контейнерді қолданамыз. Суреттерді жүктеуге болады. Backend оларды алдын ала дайындалған көлемге қояды, ол сонымен қатар статикалықты беретін nginx бар контейнерге орнатылады.
Nginx, MySQL конфигурациясын сақтау үшін біз қажетті конфигурацияларды сақтайтын Docker қалтасын қостық. Әзірлеуші өз машинасында репозиторийдің гит клонын жасағанда, оның жергілікті дамуға дайын жобасы бар. Қандай портты немесе қандай параметрлерді қолдану керектігі туралы сұрақ жоқ.
Әрі қарай, бізде бірнеше компоненттер бар: admin, inform-API, push хабарландырулары.
Осының бәрін бастау үшін біз тағы бір репозиторий жасадық, оны біз dockerized-app деп атадық. Қазіргі уақытта біз әр компоненттің алдында бірнеше репозиторийлерді қолданамыз. Олар жай ғана логикалық түрде ерекшеленеді - GitLab-та ол қалтаға ұқсайды, бірақ әзірлеушінің машинасында белгілі бір жобаға арналған қалта. Бір деңгей төмен - біріктірілетін құрамдас бөліктер.
Бұл dockerized-app мазмұнының мысалы. Біз сонымен қатар Docker каталогын осында әкелеміз, онда біз барлық компоненттердің өзара әрекеттесуі үшін қажетті конфигурацияларды толтырамыз. Жобаны іске қосу жолын қысқаша сипаттайтын README.md бар.
Мұнда біз екі докер құрастыратын файлды қолдандық. Бұл қадамдармен жүгіру үшін жасалады. Әзірлеуші ядромен жұмыс істегенде, оған push хабарландырулары қажет емес, ол жай ғана докер-композиттік файлды іске қосады және сәйкесінше ресурс сақталады.
Push хабарландыруларымен біріктіру қажет болса, docker-compose.yaml және docker-compose-push.yaml іске қосылады.
docker-compose.yaml және docker-compose-push.yaml қалтада болғандықтан, жалғыз виртуалды желі автоматты түрде жасалады.
Компоненттерге сипаттама. Бұл құрамдастарды жинауға жауап беретін жетілдірілген файл. Бұл жерде таңқаларлық не бар? Мұнда біз баланстауыш компонентін енгіземіз.
Бұл nginx іске қосатын дайын Docker кескіні және Docker ұяшығын тыңдайтын қолданба. Динамикалық, контейнерлер қосулы және өшірілгендіктен, ол nginx конфигурациясын қалпына келтіреді. Біз үшінші деңгейлі домен атаулары бойынша компоненттерді өңдеуді таратамыз.
Әзірлеу ортасы үшін біз .dev доменін қолданамыз - api.informer.dev. .dev домені бар қолданбалар әзірлеушінің жергілікті құрылғысында қолжетімді.
Әрі қарай конфигурациялар әр жобаға тасымалданады және барлық жобалар бір уақытта бірге іске қосылады.
Графикалық түрде клиент біздің браузеріміз немесе балансизаторға сұраныс жасайтын қандай да бір құрал болып табылады.
Домен атауын теңестіруші қай контейнермен байланысу керектігін анықтайды.
Бұл әкімшіге JS беретін nginx болуы мүмкін. Бұл API беретін nginx немесе кескінді жүктеп салу түрінде nginxке берілетін статикалық файлдар болуы мүмкін.
Диаграмма контейнерлердің виртуалды желі арқылы қосылғанын және проксидің артында жасырылғанын көрсетеді.
Әзірлеушінің машинасында сіз IP-ді біле отырып, контейнерге қол жеткізе аласыз, бірақ біз оны қолданбаймыз. Тікелей қол жеткізудің іс жүзінде қажеті жоқ.
Қолданбаңызды докеризациялау үшін қандай мысалды қарау керек? Менің ойымша, жақсы мысал - MySQL үшін ресми докер кескіні.
Бұл өте қиын. Көптеген нұсқалар бар. Бірақ оның функционалдығы одан әрі даму процесінде туындауы мүмкін көптеген қажеттіліктерді жабуға мүмкіндік береді. Егер сіз уақытты өткізіп, барлығының өзара әрекеттесетінін анықтасаңыз, онда сізде өзін-өзі жүзеге асыруда қиындықтар болмайды деп ойлаймын.
Hub.docker.com әдетте github.com сілтемелерін қамтиды, ол тікелей кескінді өзіңіз құра алатын бастапқы деректерді қамтиды.
Әрі қарай бұл репозиторийде бастапқы инициализацияға және қолданбаны іске қосуды одан әрі өңдеуге жауап беретін docker-endpoint.sh сценарийі бар.
Сондай-ақ, бұл мысалда ортаның айнымалы мәндерін пайдаланып конфигурациялау мүмкіндігі бар. Жалғыз контейнерді іске қосқанда немесе docker-compose арқылы қоршаған ортаның айнымалы мәнін анықтау арқылы біз MySQL жүйесінде немесе біз қалаған кез келген нәрсені түбірлеу үшін докер үшін бос құпия сөзді орнатуымыз керек деп айта аламыз.
Кездейсоқ құпия сөзді жасау мүмкіндігі бар. Бізге пайдаланушы керек, пайдаланушыға пароль қою керек, мәліметтер базасын жасау керек дейміз.
Біздің жобаларымызда біз инициализацияға жауап беретін Dockerfile файлын аздап біріктірдік. Онда біз оны қолданба пайдаланатын пайдаланушы құқықтарының кеңейтімі ғана ету үшін өз қажеттіліктерімізге түзеттік. Бұл бізге кейінірек қолданба консолінен жай ғана дерекқор жасауға мүмкіндік берді. Ruby қолданбаларында дерекқорды құру, өзгерту және жою пәрмені бар.
Бұл MySQL нақты нұсқасы github.com сайтында қалай көрінетінінің мысалы. Dockerfile файлын ашып, онда орнатудың қалай жүріп жатқанын көруге болады.
docker-endpoint.sh - кіру нүктесіне жауапты сценарий. Бастапқы инициализация кезінде кейбір дайындық қадамдары қажет және бұл әрекеттердің барлығы инициализация сценарийінде ғана орындалады.
Екінші бөлімге көшейік.
Бастапқы кодтарды сақтау үшін gitlab бағдарламасына көштік. Бұл визуалды интерфейсі бар жеткілікті қуатты жүйе.
Gitlab компоненттерінің бірі Gitlab CI болып табылады. Ол кейінірек кодты жеткізу жүйесін ұйымдастыру немесе автоматты тестілеуді іске қосу үшін пайдаланылатын пәрмендер тізбегін сипаттауға мүмкіндік береді.
Gitlab CI 2 әңгімесі - Ruby Russia клубының репортажы - өте егжей-тегжейлі және ол сізді қызықтыратын шығар.
Енді Gitlab CI іске қосу үшін не қажет екенін қарастырамыз. Gitlab CI іске қосу үшін бізге тек .gitlab-ci.yml файлын жобаның түбіріне қою керек.
Мұнда біз сынақ, орналастыру сияқты күйлер тізбегін орындағымыз келетінін сипаттаймыз.
Біз қолданбаны құру үшін тікелей docker-compose шақыратын сценарийлерді орындаймыз. Бұл жай ғана серверлік мысал.
Әрі қарай, дерекқорды өзгерту және сынақтарды орындау үшін тасымалдауды іске қосу керек деп айтамыз.
Егер сценарийлер дұрыс орындалса және қате кодын қайтармаса, жүйе орналастырудың екінші кезеңіне өтеді.
Орналастыру кезеңі қазіргі уақытта сахналау үшін жүзеге асырылуда. Біз нөлдік тоқтау уақытын қайта іске қосуды ұйымдастырмадық.
Біз барлық контейнерлерді күштеп сөндіреміз, содан кейін сынақ кезінде бірінші кезеңде жиналған барлық контейнерлерді қайтадан көтереміз.
Әзірлеушілер жазған дерекқор тасымалдауларының ағымдағы орта айнымалысы үшін іске қосылып жатырмыз.
Бұл тек негізгі филиалға қатысты деген ескерту бар.
Басқа филиалдарды өзгерту кезінде орындалмайды.
Филиалдар бойынша шығаруды ұйымдастыруға болады.
Мұны әрі қарай ұйымдастыру үшін бізге Gitlab Runner орнату керек.
Бұл утилита Голанг тілінде жазылған. Бұл ешқандай тәуелділікті қажет етпейтін Голанг әлемінде кең таралған жалғыз файл.
Іске қосу кезінде біз Gitlab Runner бағдарламасын тіркейміз.
Біз Gitlab веб-интерфейсіндегі кілтті аламыз.
Содан кейін пәрмен жолындағы инициализация командасын шақырамыз.
Gitlab Runner бағдарламасын интерактивті түрде орнату (Shell, Docker, VirtualBox, SSH)
Gitlab Runner бағдарламасындағы код .gitlab-ci.yml параметріне байланысты әрбір тапсырмада орындалады.
Веб-интерфейстегі Gitlab-те оның көрнекі түрде қалай көрінеді. GItlab CI қосылғаннан кейін бізде қазіргі уақытта құрастыру күйін көрсететін жалауша бар.
Біз 4 минут бұрын барлық сынақтардан өткен және ешқандай қиындық тудырмаған міндеттеме жасалғанын көріп отырмыз.
Біз құрылыстарды мұқият қарастыра аламыз. Мұнда біз екі мемлекеттің өтіп кеткенін көреміз. Сынақ күйі және орналастыру күйі.
Егер біз белгілі бір құрылымды шертсек, онда .gitlab-ci.yml сәйкес процесте іске қосылған командалардың консольдық шығысы болады.
Біздің өнім тарихымыз осылай көрінеді. Табысты талпыныстар болғанын көріп отырмыз. Сынақтар жіберілген кезде ол келесі қадамға өтпейді және кезең коды жаңартылмайды.
Докерді енгізген кезде біз сахналауда қандай тапсырмаларды шештік? Біздің жүйе құрамдас бөліктерден тұрады және бізде бүкіл жүйе емес, репозиторийде жаңартылған құрамдастардың бір бөлігі ғана қайта іске қосу қажет болды.
Ол үшін барлығын бөлек қалталарға бөлшектеу керек болды.
Осы әрекетті орындағаннан кейін бізде Docker-compose бағдарламасының әрбір әке үшін жеке желі кеңістігін жасайтындығы және көршінің құрамдастарын көрмейтіндігі туралы мәселе туындады.
Айналу үшін біз Docker жүйесінде желіні қолмен жасадық. Docker-compose бағдарламасында сіз осы жоба үшін осындай желіні пайдаланасыз деп жазылған.
Осылайша, осы тордан басталатын әрбір компонент жүйенің басқа бөліктеріндегі құрамдастарды көреді.
Келесі мәселе - бірнеше жобалар бойынша кезеңді бөлу.
Мұның бәрі әдемі және өндіріске мүмкіндігінше жақын болуы үшін WEB-тің барлық жерінде қолданылатын 80 немесе 443 портын қолданған дұрыс.
Біз оны қалай шештік? Біз барлық ірі жобаларға бір Gitlab Runner тағайындадық.
Gitlab бірнеше бөлінген Gitlab жүгірушілерін іске қосуға мүмкіндік береді, олар жай ғана барлық тапсырмаларды ретсіз ретпен қабылдайды және оларды іске қосады.
Бізде үй болмауы үшін біз жобаларымыздың тобын бір Gitlab Runner-мен шектедік, ол біздің көлемдерімізбен еш қиындықсыз күреседі.
Біз nginx-проксиді бөлек іске қосу сценарийіне көшірдік және ондағы барлық жобалар үшін торларды қостық.
Біздің жобада бір тор бар, ал балансизаторда жоба атаулары бойынша бірнеше торлар бар. Ол одан әрі домен атаулары бойынша прокси жасай алады.
Біздің сұрауларымыз 80 портындағы домен арқылы келеді және осы доменге қызмет көрсететін контейнерлер тобына шешіледі.
Басқа қандай проблемалар болды? Бұл барлық контейнерлер әдепкі бойынша түбір ретінде іске қосылады. Бұл жүйенің түбірлік хостына тең емес түбір.
Дегенмен, контейнерге кірсеңіз, ол түбір болады және біз осы контейнерде жасайтын файл түбірлік құқықтарды алады.
Егер әзірлеуші контейнерге кіріп, сол жерде файлдарды жасайтын кейбір пәрмендерді жасаса, содан кейін контейнерден шығып кетсе, оның жұмыс каталогында оған қол жеткізе алмайтын файл бар.
Оны қалай шешуге болады? Контейнерде болатын пайдаланушыларды қосуға болады.
Пайдаланушыны қосқанда қандай мәселелер туындады?
Пайдаланушыны жасау кезінде бізде жиі топ идентификаторы (UID) және пайдаланушы идентификаторы (GID) болмайды.
Контейнердегі бұл мәселені шешу үшін біз ID 1000 пайдаланушыларды пайдаланамыз.
Біздің жағдайда бұл барлық дерлік әзірлеушілер Ubuntu ОЖ-ны қолданатын фактімен сәйкес келді. Ал Ubuntu-да бірінші пайдаланушының идентификаторы 1000.
Жоспарларымыз бар ма?
Docker құжаттамасын оқыңыз. Жоба белсенді дамуда, құжаттама өзгеруде. Осыдан екі-үш ай бұрын алынған деректер қазірдің өзінде баяу ескіріп жатыр.
Біз шешкен мәселелердің кейбірі стандартты құралдармен шешілген болуы мүмкін.
Сондықтан мен оркестрге тікелей бару үшін одан әрі барғым келеді.
Бір мысал - қораптан шыққан Docker Swarm деп аталатын Docker-тің кірістірілген механизмі. Мен Docker Swarm технологиясына негізделген өндірісте бір нәрсені іске қосқым келеді.
Уылдырық шашатын контейнерлер бөренелермен жұмыс істеуді ыңғайсыз етеді. Қазір журналдар оқшауланған. Олар контейнерлерге шашырайды. Тапсырмалардың бірі - веб-интерфейс арқылы журналдарға ыңғайлы қол жеткізу.
Ақпарат көзі: www.habr.com