Біріншіден, кішкене теория. Не болды ?
Қарапайым сөзбен айтқанда, бұл құжат әзірлеушілер мен DevOps инженерлеріне заманауи қолданбаларды әзірлеу кезінде жиі кездесетін мәселелер мен тәжірибелер туралы ақпарат беру арқылы SaaS қосымшаларын әзірлеуді жеңілдетуге арналған.
Құжатты Heroku платформасының әзірлеушілері жасаған.
Он екі факторлы қолданбаны кез келген бағдарламалау тілінде жазылған және қолдау қызметтерінің кез келген комбинациясын (деректер базалары, хабарламалар кезегі, кэштер және т.б.) пайдаланатын қолданбаларға қолдануға болады.
Бұл әдістемеге негізделген факторлар туралы қысқаша:
- Код базасы – Нұсқаларды басқаруда бақыланатын бір кодтық база – бірнеше орналастыру
- Тәуелділіктер – Тәуелділіктерді анық жариялаңыз және оқшаулаңыз
- Конфигурация – Конфигурацияны орындау уақытында сақтаңыз
- Бекіту қызметтері – Қосылатын модульдер ресурстары ретінде қолдау қызметтерін қарастырыңыз
- Құру, босату, жүгіру – Құрастыру және орындау кезеңдерін қатаң бөліңіз
- Процестер – Қолданбаны бір немесе бірнеше азаматтығы жоқ процестер ретінде іске қосыңыз
- Портты байланыстыру – Портты байланыстыру арқылы қызметтерді экспорттау
- Параллелизм – Процесстер арқылы қолданбаны масштабтаңыз
- Бір реттік – Жылдам іске қосу және таза өшіру арқылы сенімділікті барынша арттырыңыз
- Қолданбаны әзірлеу/операция паритеті – Әзірлеу, сахналау және өндіріс орталарыңызды мүмкіндігінше ұқсас ұстаңыз
- Тіркеу – Журналды оқиғалар ағыны ретінде қараңыз
- Әкімшілік тапсырмалар – Ad hoc процестерін пайдаланып әкімшілік/басқару тапсырмаларын орындаңыз
12 фактор туралы қосымша ақпаратты келесі ресурстардан ала аласыз:
- - міндетті түрде оқу керек
- — ресми аударма
- - жақсарту мақсатында 12 факторға жаңаша көзқарас.
Көк-жасыл орналастыру дегеніміз не?
Көк-Жасыл орналастыру – қолданбаны жеткізу әдісі өнім соңғы клиент өз тарапынан ешқандай өзгерістерді көрмейтіндей етіп. Басқаша айтқанда, нөлге тең қолданбаны қолдану үзіліс.
BG Deploy классикалық схемасы төмендегі суретте көрсетілгенге ұқсайды.
- Бастапқыда коды, қолданбасы, жобасы бірдей 2 физикалық сервер және маршрутизатор (балансер) бар.
- Маршрутизатор бастапқыда барлық сұрауларды серверлердің біріне бағыттайды (жасыл).
- Қайта шығару қажет болған кезде бүкіл жоба басқа серверде жаңартылады (көк), ол қазір ешқандай сұрауларды өңдемейді.
- Код қосылғаннан кейін көк сервер толығымен жаңартылды, маршрутизаторға ауысу пәрмені беріледі жасыл туралы көк сервер.
- Енді барлық клиенттер жұмыс істейтін кодтың нәтижесін көреді көк сервер
- Біраз уақытқа, жасыл сервер сәтсіз орналастыру жағдайында сақтық көшірме ретінде қызмет етеді көк сервер және қателер мен қателер болған жағдайда, маршрутизатор пайдаланушы ағынын кері ауыстырады жасыл ескі тұрақты нұсқасы бар сервер және жаңа код қайта қарауға және тестілеуге жіберіледі.
- Ал процестің соңында ол дәл осылай жаңартылады жасыл сервер. Және оны жаңартқаннан кейін маршрутизатор сұрау ағынын қайтадан ауыстырады жасыл сервер.
Мұның бәрі өте жақсы көрінеді және бір қарағанда, онымен ешқандай проблемалар болмауы керек.
Бірақ біз қазіргі әлемде өмір сүріп жатқандықтан, классикалық схемада көрсетілген физикалық ауысу опциясы бізге сәйкес келмейді. Әзірге ақпаратты жазып алыңыз, біз оған кейінірек ораламыз.
Жаман және жақсы кеңес
Жауапкершіліктен бас тарту: Төмендегі мысалдар мен пайдаланатын утилиталарды/әдістемелерді көрсетеді, сіз ұқсас функциялары бар кез келген баламаларды пайдалана аласыз.
Мысалдардың көпшілігі бір жолмен веб-әзірлеумен (бұл күтпеген жағдай), PHP және Docker-пен қиылысады.
Төмендегі параграфтар нақты мысалдар арқылы факторларды пайдаланудың қарапайым практикалық сипаттамасын береді; осы тақырып бойынша қосымша теорияны алғыңыз келсе, бастапқы дереккөзге жоғарыдағы сілтемелерді орындаңыз.
1. Код базасы
Файлдарды серверлерге бір-бірден жүктеп салу үшін FTP және FileZilla пайдаланыңыз, кодты өндірістік серверден басқа жерде сақтамаңыз.
Жобада әрқашан бір кодтық база болуы керек, яғни барлық код біреуден келеді жүру репозиторий. Серверлер (өндіріс, кезең, сынақ1, сынақ2...) бір жалпы репозиторийдің тармақтарынан алынған кодты пайдаланады. Осылайша біз кодтың сәйкестігіне қол жеткіземіз.
2. Тәуелділіктер
Қалталардағы барлық кітапханаларды тікелей жобаның түбіріне жүктеп алыңыз. Жаңа кодты кітапхананың ағымдағы нұсқасы бар қалтаға тасымалдау арқылы жаңартуларды жасаңыз. Барлық қажетті утилиталарды тағы 20 қызмет жұмыс істейтін хост серверіне тікелей орнатыңыз.
Жобада әрқашан тәуелділіктердің анық түсінікті тізімі болуы керек (тәуелділіктер арқылы мен қоршаған ортаны да айтамын). Барлық тәуелділіктер нақты анықталған және оқшауланған болуы керек.
Мысал ретінде алайық композитор и Докер.
композитор — PHP-де кітапханаларды орнатуға мүмкіндік беретін пакет менеджері. Композитор нұсқаларды қатаң немесе еркін көрсетуге және оларды нақты анықтауға мүмкіндік береді. Серверде 20 түрлі жоба болуы мүмкін және әрқайсысында басқалардан тәуелсіз пакеттер мен кітапханалардың жеке тізімі болады.
Докер — қолданба жұмыс істейтін ортаны анықтауға және оқшаулауға мүмкіндік беретін утилита. Тиісінше, композитор сияқты, бірақ егжей-тегжейлі, біз қолданбаның немен жұмыс істейтінін анықтай аламыз. Арнайы PHP нұсқасын таңдаңыз, қосымша ештеңе қоспай, жобаның жұмыс істеуі үшін қажет пакеттерді ғана орнатыңыз. Ең бастысы, хост машинасының және басқа жобалардың пакеттері мен ортасына кедергі келтірместен. Яғни, Docker арқылы жұмыс істейтін сервердегі барлық жобалар пакеттердің кез келген жиынтығын және мүлдем басқа ортаны пайдалана алады.
3. Конфигурация
Конфигурацияларды тікелей кодта тұрақтылар ретінде сақтаңыз. Сынақ сервері үшін бөлек константалар, өндіріс үшін бөлек. Ортаға байланысты қолданбаның жұмысын if else конструкцияларын пайдаланып жобаның бизнес логикасына тікелей байланыстырыңыз.
Конфигурациялар - бұл жобаны орналастырудың ерекшеленуінің жалғыз жолы. Ең дұрысы, конфигурациялар орта айнымалылары (env vars) арқылы өтуі керек.
Яғни, .config.prod .config.local бірнеше конфигурация файлдарын сақтасаңыз да және оларды орналастыру кезінде .config деп өзгертсеңіз де (қолданба деректерді оқитын негізгі конфигурация) - бұл дұрыс тәсіл болмайды, өйткені бұл жағдайда конфигурациялардағы ақпарат барлық қолданбаларды әзірлеушілер үшін жалпыға қолжетімді болады және өндіріс серверіндегі деректер бұзылады. Барлық конфигурациялар тікелей орналастыру жүйесінде (CI/CD) сақталуы және орналастыру кезінде белгілі бір ортаға қажетті әртүрлі мәндері бар әртүрлі орталар үшін жасалуы керек.
4. Үшінші тарап қызметтері
Қоршаған ортаға қатаң байланысты болыңыз, белгілі бір орталарда бірдей қызметтер үшін әртүрлі қосылымдарды пайдаланыңыз.
Шындығында, бұл нүкте конфигурациялар туралы тармақпен қатты сәйкес келеді, өйткені бұл тармақсыз қалыпты конфигурация деректерін жасау мүмкін емес және жалпы конфигурациялау мүмкіндігі ештеңеге дейін төмендейді.
Кезек серверлері, дерекқорлар, кэштеу қызметтері сияқты сыртқы қызметтерге барлық қосылымдар жергілікті орта үшін де, үшінші тарап/өндірістік орта үшін де бірдей болуы керек. Басқаша айтқанда, кез келген уақытта қосылым жолын өзгерту арқылы мен №1 базаға қоңырауларды қолданба кодын өзгертпей №2 базаға ауыстыра аламын. Немесе алға қарай, мысал ретінде, қызметті масштабтау кезінде қосымша кэш сервері үшін қосылымды арнайы жолмен көрсетудің қажеті жоқ.
5. Құру, шығару, орындау
Серверде кодтың соңғы нұсқасы ғана болсын, шығарылымды кері қайтару мүмкіндігі жоқ. Дискідегі орынды толтырудың қажеті жоқ. Қателікпен кодты өндіріске шығара аламын деп ойлайтын кез келген адам нашар бағдарламашы!
Орналастырудың барлық кезеңдері бір-бірінен бөлінуі керек.
Қайта оралуға мүмкіндік бар. Қателер туындаған жағдайда ескі нұсқаны қалпына келтіру үшін жылдам қол жеткізуде сақталған қолданбаның ескі көшірмелерімен (қазірдің өзінде жиналған және шайқасқа дайын) шығарылымдар жасаңыз. Яғни, шартты түрде қалта бар шығарылымдар және қалта ағымдағы, және сәтті орналастыру және қалтаны жинағаннан кейін ағымдағы ішінде орналасқан жаңа шығарылымға символдық сілтеме арқылы байланыстырылады шығарылымдар шығарылым нөмірінің шартты атауымен.
Міне, біз Көк-Жасыл орналастыруды есте сақтаймыз, ол сізге кодтар арасында ауысуға ғана емес, сонымен қатар барлық ресурстарды және тіпті бәрін кері айналдыру мүмкіндігі бар орталар арасында ауысуға мүмкіндік береді.
6. Процестер
Қолданба күйінің деректерін тікелей қолданбаның өзінде сақтаңыз. Сеанстарды қолданбаның жедел жадында пайдаланыңыз. Үшінші тарап қызметтері арасында мүмкіндігінше көп бөлісуді пайдаланыңыз. Қолданбада тек бір процесс болуы мүмкін екеніне сеніңіз және масштабтауға рұқсат бермеңіз.
Сеанстарға қатысты деректерді тек үшінші тарап қызметтері (memcached, redis) басқаратын кэште сақтаңыз, сондықтан сізде іске қосылған 20 қолданба процесі болса да, олардың кез келгені кэшке кіргеннен кейін клиентпен жұмыс істеуді жалғастыра алады. пайдаланушы басқа процесте қолданбамен жұмыс істеген сол күй. Осы тәсілмен сіз үшінші тарап қызметтерінің қанша көшірмелерін пайдалансаңыз да, бәрі қалыпты және деректерге қол жеткізуде қиындықсыз жұмыс істейтіні белгілі болды.
7. Портты байланыстыру
Тек веб-сервер үшінші тарап қызметтерімен қалай жұмыс істеу керектігін білуі керек. Немесе жақсырақ, үшінші тарап қызметтерін тікелей веб-сервер ішіне орнатыңыз. Мысалы, Apache-де РНР модулі ретінде.
Сіздің барлық қызметтеріңіз кейбір мекенжайлар мен порттарға (localgost:5432, localhost:3000, nginx:80, php-fpm:9000) кіру арқылы бір-біріне қолжетімді болуы керек, яғни nginx-тен мен php-fpm және postgres және php-fpm-ден postgres және nginx-ке дейін және іс жүзінде әрбір қызметтен басқа қызметке қол жеткізе аламын. Осылайша, қызметтің өміршеңдігі басқа қызметтің өміршеңдігімен байланысты емес.
8. Параллелизм
Бір процесспен жұмыс істеңіз, әйтпесе бірнеше процесс бір-бірімен үйлесе алмайды!
Масштабтау үшін орын қалдырыңыз. Docker swarm бұл үшін тамаша.
Docker Swarm - әртүрлі машиналар мен бір машинадағы контейнерлер шоғыры арасындағы контейнерлер кластерлерін жасауға және басқаруға арналған құрал.
Swarm көмегімен мен әрбір процеске қанша ресурстар бөлетінімді және сол қызметтің қанша процесін іске қосатынымды анықтай аламын және берілген портта деректерді қабылдайтын ішкі теңгергіш оны процестерге автоматты түрде прокси-серверлейді. Осылайша, сервердегі жүктеме ұлғайғанын көріп, мен қосымша процестерді қоса аламын, осылайша белгілі бір процестерге жүктемені азайта аламын.
9. Бір реттік
Процестермен және деректермен жұмыс істеу үшін кезектерді пайдаланбаңыз. Бір процесті жою бүкіл қолданбаға әсер етуі керек. Бір қызмет істен шықса, бәрі де істен шығады.
Әрбір процесс пен қызметті кез келген уақытта өшіруге болады және бұл басқа қызметтерге әсер етпеуі керек (әрине, бұл қызмет басқа қызмет үшін қолжетімсіз болады дегенді білдірмейді, бірақ осыдан кейін басқа қызмет өшірілмейді). Барлық процестерді ақырын аяқтау керек, осылайша олар тоқтатылған кезде ешбір деректер бүлінбейді және жүйе оны келесі рет қосқанда дұрыс жұмыс істейді. То есть даже в случае аварийного завершения, данные не должны пострадать (тут подойдет механизм транзакций, запросы в бд работают только группами, и если хоть один запрос из группы не выполнился или выполнился с ошибкой, то не никакой другой запрос из группы в итоге не выполняется шынында).
10. Қолданбаларды әзірлеу/операция паритеті
Өндіріс, қойылым және қолданбаның жергілікті нұсқасы әртүрлі болуы керек. Өндірісте біз Yii Lite негізін, ал жергілікті Yii қолданамыз, сондықтан ол өндірісте жылдамырақ жұмыс істейді!
Шындығында, барлық орналастырулар және кодпен жұмыс бірдей дерлік ортада болуы керек (біз физикалық жабдық туралы айтып отырған жоқпыз). Сондай-ақ, кез келген әзірлеуші қызметкер қажет болған жағдайда кодты өндіріске енгізе алуы керек, бірақ арнайы күштің арқасында қосымшаны өндіріске көтере алатын кейбір арнайы оқытылған devops бөлімі емес.
Доккер де осыған көмектеседі. Егер барлық алдыңғы нүктелер сақталса, докерді пайдалану ортаны өндірісте де, жергілікті машинада да бір немесе екі пәрменді енгізу процесіне әкеледі.
11. Журналдар
Біз файлдар мен дерекқорларға журналдарды жазамыз! Біз файлдар мен дерекқорларды журналдардан тазаламаймыз. 9000 Пета байты бар қатты диск сатып алайық және бұл жақсы.
Барлық журналдар оқиғалар ағыны ретінде қарастырылуы керек. Қолданбаның өзі журналдарды өңдеуге қатыспауы керек. Журналдар stdout жүйесіне шығарылуы немесе udp сияқты хаттама арқылы жіберілуі керек, осылайша журналдармен жұмыс істеу қолданбаға ешқандай қиындық тудырмайды. graylog бұл үшін жақсы. Барлық журналдарды udp арқылы қабылдайтын Graylog (бұл хаттама пакеттің сәтті қабылданғаны туралы жауапты күтуді қажет етпейді) қолданбаға ешқандай кедергі жасамайды және тек журналдарды құрылымдау және өңдеумен айналысады. Қолданба логикасы мұндай тәсілдермен жұмыс істеу үшін өзгермейді.
12. Әкімшілік міндеттері
Деректерді, дерекқорларды және т.б. жаңарту үшін API ішінде бөлек жасалған соңғы нүктені пайдаланыңыз, оны қатарынан 2 рет орындау барлығының қайталануына әкеледі. Бірақ сіз ақымақ емессіз, сіз екі рет баспайсыз және бізге көшіру қажет емес.
Барлық басқару тапсырмалары шығарылым деңгейінде барлық код сияқты бірдей ортада орындалуы керек. Яғни, егер бізге мәліметтер базасының құрылымын өзгерту қажет болса, онда біз оны бағандардың атауларын өзгерту және кейбір визуалды дерекқорды басқару құралдары арқылы жаңаларын қосу арқылы қолмен жасамаймыз. Мұндай нәрселер үшін біз барлық жерде және барлық орталарда ортақ және түсінікті нәтижемен бірдей орындалатын жеке сценарийлерді - тасымалдауларды жасаймыз. Жобаны деректермен толтыру сияқты барлық басқа тапсырмалар үшін ұқсас әдістемелер қолданылуы керек.
PHP, Laravel, Laradock, Docker-Compose тілдерінде іске асыру мысалы
PS Барлық мысалдар MacOS жүйесінде жасалған. Олардың көпшілігі Linux үшін де қолайлы. Windows пайдаланушылары, мені кешіріңіз, бірақ мен Windows-пен ұзақ уақыт жұмыс істемедім.
Біздің компьютерде PHP нұсқасы орнатылмаған және мүлде ештеңе болмаған жағдайды елестетіп көрейік.
Docker және docker-compose бағдарламаларының соңғы нұсқаларын орнатыңыз. (мұны интернеттен табуға болады)
docker -v &&
docker-compose -v
1. Біз қойдық
git clone https://github.com/Laradock/laradock.git &&
ls
Ларадокқа келетін болсақ, бұл өте керемет нәрсе, оның құрамында көптеген контейнерлер мен көмекші заттар бар. Бірақ мен Ларадокты артық болғандықтан өндірісте өзгертулерсіз пайдалануды ұсынбаймын. Ларадоктағы мысалдар негізінде өзіңіздің контейнерлеріңізді жасаған дұрыс, бұл әлдеқайда оңтайландырылған болады, өйткені ешкімге бір уақытта барлық нәрсе қажет емес.
2. Біздің қолданбаны іске қосу үшін Laradock бағдарламасын конфигурациялаңыз.
cd laradock &&
cp env-example .env
2.1. Кейбір редакторда habr каталогын (ларадок клондалған ата-аналық қалта) ашыңыз. (Менің PHPStorm жағдайда)
Бұл кезеңде біз жобаға тек атау береміз.
2.2. Жұмыс кеңістігінің кескінін іске қосыңыз. (Сіздің жағдайда, кескіндерді құруға біраз уақыт қажет)
Жұмыс кеңістігі – әзірлеушінің тапсырмасы бойынша фреймворкпен жұмыс істеу үшін арнайы дайындалған кескін.
Біз контейнердің ішіне кіреміз
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Laravel орнату
composer create-project --prefer-dist laravel/laravel application
2.4. Орнатқаннан кейін жоба бар каталогтың жасалғанын тексеріп, құрастыруды өлтіреміз.
ls
exit
docker-compose down
2.5. PHPStorm-қа оралайық және .env файлында laravel қолданбасына дұрыс жолды орнатайық.
3. Барлық кодты Git-ке қосыңыз.
Ол үшін Github (немесе кез келген басқа жерде) репозиторийін жасаймыз. Терминалдағы habr каталогына өтіп, келесі кодты орындаймыз.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
Барлығы тәртіпте екенін тексерейік.
Ыңғайлы болу үшін мен Git үшін кейбір көрнекі интерфейсті пайдалануды ұсынамын, менің жағдайда бұл . (мына сілтеме сілтемесі бар)
4. Іске кірісейік!
Бастамас бұрын, 80 және 443 порттарында ештеңе ілулі тұрмағанына көз жеткізіңіз.
docker-compose up -d nginx php-fpm
Осылайша, біздің жоба 3 бөлек қызметтен тұрады:
- nginx - веб-сервер
- php-fpm - веб-серверден сұрауларды қабылдауға арналған php
- жұмыс кеңістігі - әзірлеушілерге арналған php
Қазіргі уақытта біз 4 ұпайдың 12-іне сәйкес келетін қосымшаны жасадық, атап айтқанда:
1. Код базасы — барлық код бір репозиторийде (шағын ескерту: laravel жобасына докерді қосу дұрыс болуы мүмкін, бірақ бұл маңызды емес).
2. Тәуелділіктер - Біздің барлық тәуелділіктер application/composer.json ішінде және әрбір контейнердің әрбір Docker файлында анық жазылған.
3. Бекіту қызметтері — Қызметтердің әрқайсысы (php-fom, nigx, жұмыс кеңістігі) жеке өмір сүреді және сырттан қосылған және бір қызметпен жұмыс істегенде екіншісіне әсер етпейді.
4. Процестер — әрбір қызмет бір процесс. Қызметтердің әрқайсысы ішкі күйін сақтамайды.
5. Портты байланыстыру
docker ps
Көріп отырғанымыздай, әрбір қызмет өз портында жұмыс істейді және барлық басқа қызметтерге қол жетімді.
6. Параллелизм
Docker бізге бір қызметтердің бірнеше процестерін олардың арасындағы жүктемені автоматты түрде теңестіру арқылы шығаруға мүмкіндік береді.
Контейнерлерді тоқтатып, жалаушадан өткізейік --масштаб
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Көріп отырғанымыздай, php-fpm контейнерінің көшірмелері жасалды. Бұл контейнермен жұмыс істеуде бізге ештеңені өзгерту қажет емес. Біз оған 9000 портында қол жеткізуді жалғастырамыз және Docker біз үшін контейнерлер арасындағы жүктемені реттейді.
7. Бір реттік - әрбір контейнерді екіншісіне зиян келтірмей өлтіруге болады. Контейнерді тоқтату немесе қайта іске қосу келесі іске қосу кезінде қолданбаның жұмысына әсер етпейді. Әрбір контейнерді кез келген уақытта көтеруге болады.
8. Қолданбаны әзірлеу/операция паритеті - біздің барлық ортамыз бірдей. Жүйені өндірістегі серверде іске қосу арқылы пәрмендеріңізде ештеңені өзгерту қажет болмайды. Барлығы бірдей Docker негізінде құрылады.
9. Тіркеу — осы контейнерлердегі барлық журналдар ағынға өтеді және Docker консолінде көрінеді. (бұл жағдайда, шын мәнінде, басқа үйде жасалған контейнерлерде, егер сіз оған қамқорлық жасамасаңыз, бұлай болмауы мүмкін)
docker-compose logs -f
Бірақ PHP және Nginx-тегі Әдепкі мәндер файлға журналдарды жазады. 12 факторды қанағаттандыру үшін қажет ажыратыңыз журналдарды әрбір контейнердің конфигурацияларында бөлек файлға жазу.
Docker сонымен қатар журналдарды тек stdout-қа ғана емес, жоғарыда айтқан graylog сияқты нәрселерге де жіберу мүмкіндігін береді. Graylog ішінде біз журналдарды өз қалауымызша басқара аламыз және біздің қолданба мұны ешбір жағдайда байқамайды.
10. Әкімшілік тапсырмалар — 12 факторлық қосымшаны жасаушылар қалағандай, қолөнер құралының арқасында әкімшіліктің барлық тапсырмалары laravel арқылы шешіледі.
Мысал ретінде мен кейбір командалардың қалай орындалатынын көрсетемін.
Біз контейнерге кіреміз.
docker-compose exec workspace bash
php artisan list
Енді біз кез келген команданы пайдалана аламыз. (мәліметтер базасын және кэшті конфигурацияламағанымызды ескеріңіз, сондықтан командалардың жартысы дұрыс орындалмайды, өйткені олар кэшпен және дерекқормен жұмыс істеуге арналған).
11. Конфигурациялар және 12. Құру, босату, жүгіру
Мен бұл бөлімді көк-жасыл орналастыруға арнағым келді, бірақ бұл мақала үшін тым ауқымды болып шықты. Мен бұл туралы бөлек мақала жазамын.
Бір сөзбен айтқанда, тұжырымдама CI/CD жүйелеріне негізделген Дженкинс и Gitlab CI. Екеуінде де белгілі бір ортамен байланысты орта айнымалы мәндерін орнатуға болады. Тиісінше, бұл жағдайда с тармағы орындалады Конфигурациялар.
Және мәселе туралы Құру, босату, жүгіру аты бар кіріктірілген функциялар арқылы шешіледі Құбыр.
Құбыр құрастыру, шығару және орындау кезеңдерін ерекшелеп, орналастыру процесін көптеген кезеңдерге бөлуге мүмкіндік береді. Сондай-ақ, Pipeline бағдарламасында сақтық көшірмелерді және шын мәнінде кез келген нәрсені жасай аласыз. Бұл шексіз әлеуеті бар құрал.
Қолданба коды мына жерде .
Осы репозиторийді клондау кезінде ішкі модульді инициализациялауды ұмытпаңыз.
PS: Бұл тәсілдердің барлығын кез келген басқа утилиталармен және бағдарламалау тілдерімен қолдануға болады. Ең бастысы, мәні ерекшеленбейді.
Ақпарат көзі: www.habr.com