Birinchidan, bir oz nazariya. Nima bo'ldi ?
Oddiy so'zlar bilan aytganda, ushbu hujjat SaaS ilovalarini ishlab chiqishni soddalashtirish uchun ishlab chiqilgan bo'lib, ishlab chiquvchilar va DevOps muhandislarini zamonaviy ilovalarni ishlab chiqishda eng ko'p uchraydigan muammolar va amaliyotlar haqida xabardor qilish orqali yordam beradi.
Hujjat Heroku platformasi ishlab chiquvchilari tomonidan yaratilgan.
O'n ikki faktorli ilova har qanday dasturlash tilida yozilgan va har qanday qo'llab-quvvatlash xizmatlari (ma'lumotlar bazalari, xabarlar navbatlari, keshlar va boshqalar) kombinatsiyasidan foydalangan holda qo'llanilishi mumkin.
Ushbu metodologiya asos bo'lgan omillar haqida qisqacha:
- Kod bazasi – Versiya boshqaruvida kuzatilgan bitta kod bazasi – bir nechta joylashtirish
- Bog'liqlar - Bog'liqlarni aniq e'lon qiling va ajratib oling
- Konfiguratsiya - Ish vaqtida konfiguratsiyani saqlang
- Qo'llab-quvvatlash xizmatlari – Qo‘llab-quvvatlash xizmatlarini plagin manbalari sifatida ko‘rib chiqing
- Qurish, ozod qilish, chopish – Yig‘ish va bajarish bosqichlarini qat’iy ajrating
- Jarayonlar – Ilovani bir yoki bir nechta fuqaroligi bo‘lmagan jarayonlar sifatida ishga tushiring
- Port bog'lash – Port bog'lash orqali xizmatlarni eksport qilish
- Parallelizm – Jarayonlar yordamida ilovangizni masshtablashtiring
- Bir martalik foydalanish - Tez ishga tushirish va toza o'chirish bilan ishonchlilikni maksimal darajada oshiring
- Ilovalarni ishlab chiqish/operatsiya pariteti – Rivojlanish, sahnalashtirish va ishlab chiqarish muhitlarini iloji boricha bir xilda saqlang
- Jurnal yozish – Jurnalni voqealar oqimi sifatida ko'ring
- Ma'muriyat vazifalari – Ad hoc jarayonlardan foydalangan holda boshqaruv/boshqaruv vazifalarini bajarish
Quyidagi manbalardan 12 ta omil haqida ko'proq ma'lumot olishingiz mumkin:
- - o'qish kerak
- - rasmiy tarjima
- - ularni yaxshilash maqsadida 12 ta omilga yangicha qarash.
Moviy-yashil joylashtirish nima?
Moviy-yashil joylashtirish - bu dasturni etkazib berish usuli Ishlab chiqarish oxirgi mijoz o'z tomonida hech qanday o'zgarishlarni ko'rmaydigan tarzda. Boshqacha qilib aytganda, nol bilan dasturni joylashtirish ishlamasligi.
Klassik BG Deploy sxemasi quyidagi rasmda ko'rsatilgandek ko'rinadi.
- Boshida mutlaqo bir xil kod, dastur, loyihaga ega bo'lgan 2 ta jismoniy server mavjud va yo'riqnoma (balansator) mavjud.
- Router dastlab barcha so'rovlarni serverlardan biriga yo'naltiradi (yashil rangda).
- Qayta chiqarishingiz kerak bo'lganda, butun loyiha boshqa serverda yangilanadi (ko'k), hozirda hech qanday so'rovni qayta ishlamayapti.
- Kod yoqilgandan keyin ko'k server to'liq yangilanadi, routerga o'tish buyrug'i beriladi yashil rangda haqida ko'k server.
- Endi barcha mijozlar ishlaydigan kodning natijasini ko'rishadi ko'k server.
- Bir muddat, yashil rangda server muvaffaqiyatsiz joylashtirilgan taqdirda zaxira nusxasi sifatida xizmat qiladi ko'k server va nosozliklar va xatolar bo'lsa, router foydalanuvchi oqimini qayta o'zgartiradi yashil rangda server eski barqaror versiyasiga ega va yangi kod qayta ko'rib chiqish va sinov uchun yuboriladi.
- Jarayon oxirida esa xuddi shu tarzda yangilanadi yashil rangda server. Va uni yangilagandan so'ng, marshrutizator so'rovlar oqimini qayta o'zgartiradi yashil rangda server.
Bularning barchasi juda yaxshi ko'rinadi va birinchi qarashda u bilan hech qanday muammo bo'lmasligi kerak.
Ammo biz zamonaviy dunyoda yashayotganimiz sababli, klassik sxemada ko'rsatilgan jismoniy o'tish varianti bizga mos kelmaydi. Hozircha ma'lumotni yozib oling, keyinroq qaytamiz.
Yaxshi va yomon maslahat
Masʼuliyatdan voz kechish: Quyidagi misollar men foydalanadigan yordamchi dasturlar/uslublarni ko'rsatadi, siz shunga o'xshash funktsiyalarga ega har qanday muqobillardan foydalanishingiz mumkin.
Ko'pgina misollar u yoki bu tarzda veb-ishlab chiqish bilan kesishadi (bu ajablanib), PHP va Docker bilan.
Quyidagi paragraflar aniq misollar yordamida omillardan foydalanishning oddiy amaliy tavsifini beradi; agar siz ushbu mavzu bo'yicha ko'proq nazariyani olishni istasangiz, asl manbaga yuqoridagi havolalarga amal qiling.
1. Kod bazasi
Fayllarni serverlarga birma-bir yuklash uchun FTP va FileZilla dan foydalaning, kodni ishlab chiqarish serveridan boshqa joyda saqlamang.
Loyiha har doim bitta kod bazasiga ega bo'lishi kerak, ya'ni barcha kod bittadan keladi borib ombori. Serverlar (ishlab chiqarish, bosqichma-bosqich, test1, test2...) bitta umumiy ombor filiallari kodidan foydalanadi. Shunday qilib, biz kod izchilligiga erishamiz.
2. Bog‘liqliklar
Papkalardagi barcha kutubxonalarni to'g'ridan-to'g'ri loyihaning ildiziga yuklab oling. Yangi kodni kutubxonaning joriy versiyasiga ega papkaga o'tkazish orqali yangilanishlarni amalga oshiring. Barcha kerakli yordamchi dasturlarni to'g'ridan-to'g'ri yana 20 ta xizmat ishlayotgan xost-serverga o'rnating.
Loyiha har doim aniq tushunarli bog'liqlik ro'yxatiga ega bo'lishi kerak (bog'liqlar deganda men atrof-muhitni ham nazarda tutaman). Barcha bog'liqliklar aniq belgilanishi va izolyatsiya qilinishi kerak.
Misol tariqasida olaylik yaratmoq и Docker.
yaratmoq — PHP da kutubxonalarni oʻrnatish imkonini beruvchi paket menejeri. Composer sizga versiyalarni qat'iy yoki erkin tarzda belgilash va ularni aniq belgilash imkonini beradi. Serverda 20 xil loyiha bo'lishi mumkin va ularning har biri boshqasidan mustaqil ravishda paketlar va kutubxonalarning shaxsiy ro'yxatiga ega bo'ladi.
Docker — ilova ishlaydigan muhitni aniqlash va ajratish imkonini beruvchi yordamchi dastur. Shunga ko'ra, xuddi kompozitor bilan bo'lgani kabi, lekin batafsilroq, biz dastur nima bilan ishlashini aniqlashimiz mumkin. PHP ning ma'lum bir versiyasini tanlang, qo'shimcha hech narsa qo'shmasdan faqat loyiha ishlashi uchun zarur bo'lgan paketlarni o'rnating. Va eng muhimi, xost mashinasi va boshqa loyihalarning paketlari va muhitiga aralashmasdan. Ya'ni, Docker orqali ishlaydigan serverdagi barcha loyihalar mutlaqo har qanday paketlar to'plamidan va butunlay boshqa muhitdan foydalanishi mumkin.
3. Konfiguratsiya
Konfiguratsiyalarni to'g'ridan-to'g'ri kodda doimiylar sifatida saqlang. Sinov serveri uchun alohida konstantalar, ishlab chiqarish uchun alohida. If else konstruktsiyalaridan foydalanib, ilovaning ishlashini atrof-muhitga qarab to'g'ridan-to'g'ri loyihaning biznes mantig'iga bog'lang.
Konfiguratsiya - bu loyihani joylashtirishning farqlanishining yagona yo'li. Ideal holda, konfiguratsiyalar muhit o'zgaruvchilari (env vars) orqali o'tkazilishi kerak.
Ya'ni, agar siz bir nechta konfiguratsiya fayllarini saqlasangiz ham .config.prod .config.local va ularni joylashtirish vaqtida .config (ilova ma'lumotlarni o'qiydigan asosiy konfiguratsiya) ga o'zgartirsangiz ham - bu to'g'ri yondashuv bo'lmaydi, chunki bu holda konfiguratsiyalardagi ma'lumotlar barcha dastur ishlab chiquvchilari uchun ochiq bo'ladi va ishlab chiqarish serveridagi ma'lumotlar buziladi. Barcha konfiguratsiyalar to'g'ridan-to'g'ri joylashtirish tizimida (CI/CD) saqlanishi va joylashtirish vaqtida ma'lum bir muhit uchun zarur bo'lgan turli qiymatlarga ega bo'lgan turli muhitlar uchun yaratilishi kerak.
4. Uchinchi tomon xizmatlari
Atrof-muhitga qat'iy bog'langan bo'ling, muayyan muhitda bir xil xizmatlar uchun turli ulanishlardan foydalaning.
Aslida, bu nuqta konfiguratsiyalar haqidagi fikrga juda mos keladi, chunki bu nuqtasiz oddiy konfiguratsiya ma'lumotlarini yaratish mumkin emas va umuman, sozlash qobiliyati hech narsaga tushib qolmaydi.
Navbat serverlari, maʼlumotlar bazalari, keshlash xizmatlari kabi tashqi xizmatlarga barcha ulanishlar ham mahalliy muhit, ham uchinchi tomon/ishlab chiqarish muhiti uchun bir xil boʻlishi kerak. Boshqacha qilib aytadigan bo'lsak, istalgan vaqtda ulanish qatorini o'zgartirish orqali men №1 bazaga qo'ng'iroqlarni ilova kodini o'zgartirmasdan №2 bazaga almashtirishim mumkin. Yoki oldinga qarab, misol tariqasida, xizmatni masshtablashtirganda, qo'shimcha kesh-server uchun ulanishni maxsus tarzda belgilashingiz shart emas.
5. Qurilish, chiqarish, bajarish
Serverda kodning faqat oxirgi versiyasiga ega bo'ling, relizni qaytarib olish imkoniyati yo'q. Diskdagi bo'sh joyni to'ldirishga hojat yo'q. Kimki xato bilan kodni ishlab chiqarishga chiqarishi mumkin deb o'ylagan kishi yomon dasturchidir!
Joylashtirishning barcha bosqichlari bir-biridan ajratilgan bo'lishi kerak.
Orqaga qaytish imkoniyati bor. Ilovaning tez kirishda saqlangan eski nusxalari (allaqachon yig'ilgan va jangga tayyor) bilan relizlar yarating, shunda xatolar yuzaga kelganda eski versiyani tiklashingiz mumkin. Ya'ni, shartli ravishda papka mavjud chiqaradi va papka hozirgi, va papkani muvaffaqiyatli joylashtirish va yig'ishdan so'ng hozirgi ichida joylashgan yangi nashrga ramziy havola bilan bog'langan chiqaradi chiqarish raqamining shartli nomi bilan.
Bu erda biz Blue-Green deploymentni eslaymiz, bu sizga nafaqat kodlar o'rtasida almashish, balki barcha resurslar va hatto hamma narsani orqaga qaytarish qobiliyatiga ega muhitlar o'rtasida almashish imkonini beradi.
6. Jarayonlar
Ilova holati ma'lumotlarini bevosita ilovaning o'zida saqlang. Ilovaning RAMdagi seanslardan foydalaning. Uchinchi tomon xizmatlari o'rtasida imkon qadar ko'proq almashishdan foydalaning. Ilova faqat bitta jarayonga ega bo'lishi mumkinligiga ishoning va masshtabni o'zgartirishga ruxsat bermang.
Seanslarga kelsak, ma'lumotlarni faqat uchinchi tomon xizmatlari (memcached, redis) tomonidan boshqariladigan keshda saqlang, shuning uchun sizda 20 ta dastur jarayoni ishlayotgan bo'lsa ham, ulardan har biri keshga kirgan holda mijoz bilan ishlashni davom ettirishi mumkin. foydalanuvchi boshqa jarayonda dastur bilan ishlagan holat. Ushbu yondashuv bilan ma'lum bo'lishicha, siz uchinchi tomon xizmatlarining qancha nusxasidan foydalansangiz ham, hamma narsa normal ishlaydi va ma'lumotlarga kirishda muammosiz ishlaydi.
7. Portni ulash
Faqat veb-server uchinchi tomon xizmatlari bilan qanday ishlashni bilishi kerak. Yaxshisi, uchinchi tomon xizmatlarini to'g'ridan-to'g'ri veb-server ichiga o'rnating. Masalan, Apache-da PHP moduli sifatida.
Sizning barcha xizmatlaringiz ba'zi bir manzil va portga (localgost:5432, localhost:3000, nginx:80, php-fpm:9000) kirish orqali bir-biringiz uchun ochiq bo'lishi kerak, ya'ni nginx'dan men ham php-fpm, ham postgres va php-fpm dan postgres va nginxgacha va aslida har bir xizmatdan boshqa xizmatga kirishim mumkin. Shunday qilib, xizmatning hayotiyligi boshqa xizmatning hayotiyligiga bog'liq emas.
8. Parallellik
Bitta jarayon bilan ishlang, aks holda bir nechta jarayonlar bir-biri bilan kelisha olmaydi!
O'lchov uchun joy qoldiring. Docker to'dasi buning uchun juda yaxshi.
Docker Swarm - bu turli xil mashinalar va bir xil mashinadagi konteynerlar to'plami o'rtasida konteynerlar klasterlarini yaratish va boshqarish uchun vosita.
Swarm-dan foydalanib, men har bir jarayonga qancha resurslar ajratishimni va bir xil xizmatning qancha jarayonini ishga tushirishimni aniqlay olaman va ma'lum bir portda ma'lumotlarni qabul qiluvchi ichki muvozanatlashtiruvchi uni avtomatik ravishda jarayonlarga proksi-server qiladi. Shunday qilib, serverdagi yuk ko'payganini ko'rib, men ko'proq jarayonlarni qo'shishim mumkin va shu bilan ma'lum jarayonlarga yukni kamaytiradi.
9. Bir martalik foydalanish
Jarayonlar va ma'lumotlar bilan ishlash uchun navbatlardan foydalanmang. Bitta jarayonni o'ldirish butun dasturga ta'sir qilishi kerak. Agar bitta xizmat ishlamay qolsa, hamma narsa buziladi.
Har bir jarayon va xizmat istalgan vaqtda o'chirilishi mumkin va bu boshqa xizmatlarga ta'sir qilmasligi kerak (albatta, bu xizmat boshqa xizmat uchun mavjud emasligini anglatmaydi, lekin bundan keyin boshqa xizmat o'chmaydi). Barcha jarayonlar ehtiyotkorlik bilan tugatilishi kerak, shunda ular tugatilganda hech qanday ma'lumotlar buzilmaydi va keyingi safar yoqilganda tizim to'g'ri ishlaydi. То есть даже в случае аварийного завершения, данные не должны пострадать (тут подойдет механизм транзакций, запросы в бд работают только группами, и если хоть один запрос из группы не выполнился или выполнился с ошибкой, то не никакой другой запрос из группы в итоге не выполняется aslida).
10. Ilovani ishlab chiqish/operatsiya pariteti
Ilovaning ishlab chiqarish, sahnalashtirish va mahalliy versiyasi boshqacha bo'lishi kerak. Ishlab chiqarishda biz Yii Lite ramkasidan foydalanamiz va mahalliy Yii, shuning uchun u ishlab chiqarishda tezroq ishlaydi!
Aslida, barcha joylashtirishlar va kod bilan ishlash deyarli bir xil muhitda bo'lishi kerak (biz jismoniy apparat haqida gapirmayapmiz). Bundan tashqari, har qanday ishlab chiquvchi xodim, agar kerak bo'lsa, kodni ishlab chiqarishga o'rnatishi kerak, balki maxsus o'qitilgan devops bo'limi emas, balki faqat maxsus kuch tufayli dasturni ishlab chiqarishga ko'tarishi mumkin.
Docker ham bu borada bizga yordam beradi. Agar oldingi barcha fikrlar kuzatilsa, docker-dan foydalanish muhitni ishlab chiqarishda ham, mahalliy mashinada ham bir yoki ikkita buyruqni kiritish jarayoniga olib keladi.
11. Jurnallar
Biz fayllar va ma'lumotlar bazalariga jurnallar yozamiz! Biz fayllar va ma'lumotlar bazalarini jurnallardan tozalamaymiz. Keling, 9000 Peta baytga ega qattiq disk sotib olaylik va bu yaxshi.
Barcha jurnallar voqealar oqimi sifatida ko'rib chiqilishi kerak. Ilovaning o'zi jurnallarni qayta ishlashda ishtirok etmasligi kerak. Jurnallar stdout-ga chiqarilishi yoki udp kabi protokol orqali yuborilishi kerak, shunda jurnallar bilan ishlash dastur uchun hech qanday muammo tug'dirmaydi. Buning uchun graylog yaxshi. Graylog barcha jurnallarni udp orqali qabul qiladi (ushbu protokol paketni muvaffaqiyatli qabul qilish to'g'risida javob kutishni talab qilmaydi) hech qanday tarzda dasturga xalaqit bermaydi va faqat jurnallarni tuzish va qayta ishlash bilan shug'ullanadi. Bunday yondashuvlar bilan ishlash uchun dastur mantig'i o'zgarmaydi.
12. Boshqaruvning vazifalari
Ma'lumotlar, ma'lumotlar bazalari va hokazolarni yangilash uchun APIda alohida yaratilgan so'nggi nuqtadan foydalaning, uni ketma-ket 2 marta bajarish hamma narsaning takrorlanishiga olib keladi. Lekin siz ahmoq emassiz, siz ikki marta bosmaysiz va biz migratsiyaga muhtoj emasmiz.
Barcha boshqaruv vazifalari barcha kodlar bilan bir xil muhitda, reliz darajasida bajarilishi kerak. Ya'ni, agar biz ma'lumotlar bazasi strukturasini o'zgartirishimiz kerak bo'lsa, unda biz ustunlar nomlarini o'zgartirish va ma'lumotlar bazasini boshqarishning ba'zi vizual vositalari orqali yangilarini qo'shish orqali buni qo'lda qilmaymiz. Bunday narsalar uchun biz alohida skriptlar - migratsiyalarni yaratamiz, ular hamma joyda va barcha muhitlarda umumiy va tushunarli natija bilan bir xil tarzda bajariladi. Loyihani ma'lumotlar bilan to'ldirish kabi barcha boshqa vazifalar uchun shunga o'xshash metodologiyalardan foydalanish kerak.
PHP, Laravel, Laradock, Docker-Compose dasturlarida amalga oshirish misollari
P.S Barcha misollar MacOS da yaratilgan. Ularning aksariyati Linux uchun ham mos keladi. Windows foydalanuvchilari, meni kechiring, lekin men Windows bilan uzoq vaqt ishlamadim.
Keling, bizning shaxsiy kompyuterimizda PHP ning hech qanday versiyasi o'rnatilmagan va umuman hech narsa bo'lmagan vaziyatni tasavvur qilaylik.
Docker va docker-compose ning so'nggi versiyalarini o'rnating. (buni Internetda topish mumkin)
docker -v &&
docker-compose -v
1. Qo'ying
git clone https://github.com/Laradock/laradock.git &&
ls
Laradokga kelsak, aytamanki, bu juda ajoyib narsa, unda juda ko'p idishlar va yordamchi narsalar mavjud. Ammo men Laradokni ishlab chiqarishda o'zgartirishlarsiz foydalanishni tavsiya etmayman, chunki uning ortiqchaligi. Laradokdagi misollar asosida o'z konteynerlaringizni yaratganingiz ma'qul, bu yanada optimallashtirilgan bo'ladi, chunki u erda bo'lgan hamma narsa bir vaqtning o'zida hech kimga kerak emas.
2. Laradockni ilovamizni ishga tushirish uchun sozlang.
cd laradock &&
cp env-example .env
2.1. Ba'zi muharrirda habr katalogini (laradock klonlangan asosiy papka) oching. (Mening PHPStorm ishimda)
Ushbu bosqichda biz loyihaga faqat nom beramiz.
2.2. Ish maydoni tasvirini ishga tushiring. (Sizning holingizda, tasvirlarni yaratish uchun biroz vaqt kerak bo'ladi)
Ish maydoni - bu dasturchi nomidan ramka bilan ishlash uchun maxsus tayyorlangan rasm.
Foydalanish orqali biz konteyner ichiga kiramiz
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Laravelni o'rnatish
composer create-project --prefer-dist laravel/laravel application
2.4. O'rnatishdan so'ng biz loyiha bilan katalog yaratilgan yoki yo'qligini tekshiramiz va kompozitsiyani o'chiramiz.
ls
exit
docker-compose down
2.5. Keling, PHPStorm-ga qaytaylik va .env faylida laravel ilovamizga to'g'ri yo'lni o'rnatamiz.
3. Git-ga barcha kodlarni qo'shing.
Buning uchun biz Github-da (yoki boshqa joyda) ombor yaratamiz. Terminaldagi habr katalogiga o'tamiz va quyidagi kodni bajaramiz.
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
Keling, hamma narsa tartibda yoki yo'qligini tekshirib ko'raylik.
Qulaylik uchun men Git uchun ba'zi vizual interfeysdan foydalanishni tavsiya qilaman, mening holimda bu . (bu erda havola havolasi)
4. Keling, ishga tushamiz!
Boshlashdan oldin, 80 va 443 portlarida hech narsa osilganligiga ishonch hosil qiling.
docker-compose up -d nginx php-fpm
Shunday qilib, bizning loyihamiz 3 ta alohida xizmatdan iborat:
- nginx - veb-server
- php-fpm - php veb-serverdan so'rovlarni qabul qilish uchun
- ish maydoni - ishlab chiquvchilar uchun php
Ayni paytda biz 4 balldan 12 ballga javob beradigan ilova yaratdik, xususan:
1. Kod bazasi — barcha kodlar bitta omborda (kichik eslatma: laravel loyihasiga docker qo'shish to'g'ri bo'lishi mumkin, ammo bu muhim emas).
2. Bog'liqlar - Bizning barcha bog'liqliklarimiz application/composer.json va har bir konteynerning har bir Docker faylida aniq yozilgan.
3. Qo'llab-quvvatlash xizmatlari — Xizmatlarning har biri (php-fom, nigx, ish maydoni) o'z hayotini yashaydi va tashqaridan ulanadi va bir xizmat bilan ishlashda ikkinchisiga ta'sir qilmaydi.
4. Jarayonlar — har bir xizmat bitta jarayon. Xizmatlarning har biri ichki holatni saqlamaydi.
5. Port bog'lash
docker ps
Ko'rib turganimizdek, har bir xizmat o'z portida ishlaydi va boshqa barcha xizmatlar uchun ochiqdir.
6. Parallelizm
Docker bizga bir xil xizmatlarning bir nechta jarayonlarini ular o'rtasida avtomatik yuk muvozanatini yaratishga imkon beradi.
Keling, konteynerlarni to'xtatib, ularni bayroqdan o'tkazamiz --miqyosi
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Ko'rib turganimizdek, php-fpm konteynerining nusxalari yaratilgan. Ushbu konteyner bilan ishlashda hech narsani o'zgartirishimiz shart emas. Shuningdek, biz unga 9000 portida kirishda davom etamiz va Docker biz uchun konteynerlar orasidagi yukni tartibga soladi.
7. Bir martalik foydalanish - har bir konteyner boshqasiga zarar bermasdan o'ldirilishi mumkin. Konteynerni to'xtatish yoki qayta ishga tushirish keyingi ishga tushirish vaqtida dasturning ishlashiga ta'sir qilmaydi. Har bir konteyner istalgan vaqtda ko'tarilishi mumkin.
8. Ilovalarni ishlab chiqish/operatsiya pariteti - bizning barcha muhitlarimiz bir xil. Tizimni ishlab chiqarishdagi serverda ishga tushirish orqali siz buyruqlaringizda biror narsani o'zgartirishingiz shart emas. Hammasi xuddi shu tarzda Docker-ga asoslanadi.
9. Jurnal yozish — bu konteynerlardagi barcha jurnallar oqimga o‘tadi va Docker konsolida ko‘rinadi. (bu holda, aslida, boshqa uy qurilishi idishlari bilan, agar siz unga g'amxo'rlik qilmasangiz, bunday bo'lmasligi mumkin)
docker-compose logs -f
Biroq, PHP va Nginx-dagi standart qiymatlar faylga jurnallarni ham yozishi mumkin. 12 ta omilni qondirish uchun bu zarur o'chiring har bir konteynerning konfiguratsiyasidagi faylga jurnallarni alohida yozish.
Docker shuningdek, jurnallarni nafaqat stdout-ga, balki yuqorida aytib o'tgan graylog kabi narsalarga ham yuborish imkoniyatini beradi. Greylog ichida esa biz jurnallarni xohlagancha boshqarishimiz mumkin va bizning ilovamiz buni hech qanday tarzda sezmaydi.
10. Ma'muriyat vazifalari — 12 faktorli ilovani yaratuvchilar xohlaganidek, hunarmand vositasi tufayli barcha ma'muriyat vazifalari laravel tomonidan hal qilinadi.
Misol tariqasida, men ba'zi buyruqlar qanday bajarilishini ko'rsataman.
Biz konteynerga kiramiz.
docker-compose exec workspace bash
php artisan list
Endi biz istalgan buyruqdan foydalanishimiz mumkin. (iltimos, biz ma'lumotlar bazasi va keshni sozlamaganimizni unutmang, shuning uchun buyruqlarning yarmi to'g'ri bajarilmaydi, chunki ular kesh va ma'lumotlar bazasi bilan ishlashga mo'ljallangan).
11. Konfiguratsiya va 12. Qurish, ozod qilish, chopish
Men ushbu qismni Blue-Green Deploymentga bag'ishlamoqchi edim, ammo bu maqola uchun juda keng bo'lib chiqdi. Bu haqda alohida maqola yozaman.
Xulosa qilib aytganda, kontseptsiya CI/CD tizimlariga asoslangan Jenkins и Gitlab CI. Ikkalasida ham ma'lum bir muhit bilan bog'liq muhit o'zgaruvchilarini o'rnatishingiz mumkin. Shunga ko'ra, bu vaziyatda c nuqtasi bajariladi Konfiguratsiyalar.
Va mavzu haqida Qurish, ozod qilish, chopish nomi bilan o'rnatilgan funktsiyalar orqali hal qilinadi quvuri.
quvuri montaj qilish, chiqarish va bajarish bosqichlarini ta'kidlab, joylashtirish jarayonini ko'p bosqichlarga bo'lish imkonini beradi. Shuningdek, Pipeline-da siz zaxira nusxalarini yaratishingiz mumkin va haqiqatan ham hamma narsa. Bu cheksiz imkoniyatlarga ega vositadir.
Ilova kodi quyidagi manzilda .
Ushbu omborni klonlashda submodulni ishga tushirishni unutmang.
P.S.: Ushbu yondashuvlarning barchasi boshqa har qanday yordamchi dasturlar va dasturlash tillari bilan ishlatilishi mumkin. Asosiysi, mohiyat bir-biridan farq qilmaydi.
Manba: www.habr.com