Men Inventos'dan Aleksandr Sigachevning "Docker + Gitlab CI bilan ishlab chiqish va sinov jarayoni" hisobotining transkriptini o'qishni taklif qilaman.
Docker + Gitlab CI asosida ishlab chiqish va sinov jarayonini endigina amalga oshirishni boshlaganlar ko'pincha asosiy savollarni berishadi. Qayerdan boshlash kerak? Qanday tashkil qilish kerak? Qanday sinovdan o'tish kerak?
Ushbu hisobot yaxshi, chunki u Docker va Gitlab CI yordamida ishlab chiqish va sinov jarayoni haqida tuzilgan tarzda gapiradi. Hisobotning o'zi 2017 yilga tegishli. O'ylaymanki, ushbu hisobotdan siz asoslar, metodologiya, g'oya, foydalanish tajribasini o'rganishingiz mumkin.
Kimga g'amxo'rlik qiladi, iltimos, mushuk ostida.
Mening ismim Aleksandr Sigachev. Men Inventosda ishlayman. Men sizga Docker-dan foydalanish tajribam va uni kompaniyadagi loyihalarda bosqichma-bosqich amalga oshirayotganimiz haqida aytib beraman.
Taqdimot mavzusi: Docker va Gitlab CI yordamida ishlab chiqish jarayoni.
Bu mening Docker haqidagi ikkinchi suhbatim. Birinchi hisobot paytida biz Docker-dan faqat ishlab chiquvchi mashinalarda foydalanardik. Docker-dan foydalangan xodimlar soni taxminan 2-3 kishi edi. Asta-sekin tajriba to'planib, biroz uzoqlashdik. Bizning havola .
Ushbu hisobotda nima bo'ladi? Biz qanday rake to'plaganimiz, qanday muammolarni hal qilganimiz haqida tajribamiz bilan o'rtoqlashamiz. Hamma joyda emas, balki go'zal edi, lekin harakat qilish imkonini berdi.
Bizning shiorimiz: qo'limizdan kelgan hamma narsani dock.
Biz qanday muammolarni hal qilyapmiz?
Agar kompaniyada bir nechta jamoalar mavjud bo'lsa, dasturchi umumiy manbadir. Dasturchi bir loyihadan chetlashtirilib, bir muddat boshqa loyihaga topshiriladigan bosqichlar mavjud.
Dasturchi tezda tushunishi uchun u loyihaning manba kodini yuklab olishi va atrof-muhitni imkon qadar tezroq ishga tushirishi kerak, bu esa unga ushbu loyihaning muammolarini hal qilishda davom etishiga imkon beradi.
Odatda, agar siz noldan boshlasangiz, loyihada juda kam hujjatlar mavjud. Qanday qilib sozlash haqida ma'lumot faqat eski odamlar uchun mavjud. Xodimlar bir yoki ikki kun ichida o'z ish joyini mustaqil ravishda tashkil qiladi. Buni tezlashtirish uchun biz Docker-dan foydalandik.
Keyingi sabab - Rivojlanishda sozlamalarni standartlashtirish. Mening tajribamga ko'ra, ishlab chiquvchilar doimo tashabbus ko'rsatadilar. Har beshinchi holatda maxsus domen kiritiladi, masalan, vasya.dev. Uning yonida uning qo'shnisi Petya o'tiradi, uning domeni petya.dev. Ular ushbu domen nomidan foydalangan holda veb-sayt yoki tizimning ba'zi komponentlarini ishlab chiqadilar.
Tizim o'sib ulg'ayganida va ushbu domen nomlari konfiguratsiyaga kira boshlaganda, rivojlanish muhiti ziddiyati yuzaga keladi va sayt yo'li qayta yoziladi.
Xuddi shu narsa ma'lumotlar bazasi sozlamalari bilan sodir bo'ladi. Kimdir xavfsizlik bilan bezovta qilmaydi va bo'sh ildiz paroli bilan ishlaydi. O'rnatish bosqichida MySQL kimdandir parol so'radi va parol 123 bo'lib chiqdi. Ko'pincha ma'lumotlar bazasi konfiguratsiyasi ishlab chiquvchining majburiyatiga qarab doimiy ravishda o'zgarib turadi. Kimdir tuzatdi, kimdir konfiguratsiyani tuzatmadi. Sinov konfiguratsiyasini o'chirib qo'yganimizda hiyla-nayranglar bo'ldi .gitignore va har bir ishlab chiquvchi ma'lumotlar bazasini o'rnatishi kerak edi. Bu boshlashni qiyinlashtirdi. Boshqa narsalar qatorida ma'lumotlar bazasi haqida eslash kerak. Ma'lumotlar bazasini ishga tushirish, parolni kiritish, foydalanuvchi ro'yxatdan o'tish, jadval yaratish va hokazo.
Yana bir muammo - kutubxonalarning turli versiyalari. Ko'pincha ishlab chiquvchi turli loyihalar bilan ishlaydi. Besh yil oldin (2017 yildan - tahr. eslatma) boshlangan Legacy loyihasi bor. Ishga tushirish vaqtida biz MySQL 5.5 dan boshladik. Shuningdek, biz MySQL-ning zamonaviyroq versiyalarini, masalan, 5.7 yoki undan kattaroq versiyalarini amalga oshirishga harakat qiladigan zamonaviy loyihalar mavjud (2017 yilda - tahr. eslatma)
MySQL bilan ishlaydigan har bir kishi bu kutubxonalar o'zlari bilan bog'liqliklarni olib kelishini biladi. Ikkita bazani birgalikda ishlatish juda muammoli. Hech bo'lmaganda, eski mijozlar yangi ma'lumotlar bazasiga ulanishda muammoli. Bu o'z navbatida bir qator muammolarni keltirib chiqaradi.
Keyingi muammo - ishlab chiquvchi mahalliy mashinada ishlaganda, u mahalliy resurslardan, mahalliy fayllardan, mahalliy operativ xotiradan foydalanadi. Muammolarni hal qilishda barcha o'zaro ta'sirlar bitta mashinada ishlashi doirasida amalga oshiriladi. Masalan, bizda 3-ishlab chiqarishda backend serverlari mavjud bo'lsa va ishlab chiquvchi fayllarni ildiz katalogiga saqlaydi va u erdan nginx so'rovga javob berish uchun fayllarni oladi. Bunday kod ishlab chiqarishga tushganda, fayl 3 ta serverdan birida mavjudligi ma'lum bo'ladi.
Hozirda mikroservislar yo'nalishi rivojlanmoqda. Katta ilovalarimizni bir-biri bilan o'zaro ta'sir qiladigan ba'zi kichik qismlarga ajratganimizda. Bu sizga muayyan vazifalar to'plami uchun texnologiyalarni tanlash imkonini beradi. Bundan tashqari, ishlab chiquvchilar o'rtasida ish va mas'uliyatni taqsimlash imkonini beradi.
JS-da ishlab chiqilgan Frondend-ishlab chiqaruvchisi Backend-ga deyarli ta'sir qilmaydi. Backend ishlab chiqaruvchisi, o'z navbatida, bizning holatlarimizda Ruby on Rails-ni ishlab chiqadi va Frondendga xalaqit bermaydi. O'zaro ta'sir API yordamida amalga oshiriladi.
Bonus sifatida, Docker yordamida biz Staging-da resurslarni qayta ishlashga muvaffaq bo'ldik. Har bir loyiha, o'ziga xos xususiyatlaridan kelib chiqqan holda, ma'lum sozlamalarni talab qildi. Jismoniy jihatdan, virtual serverni ajratish va ularni alohida sozlash yoki kutubxonalar versiyasiga qarab bir-biriga ta'sir qilishi mumkin bo'lgan o'zgaruvchan muhit va loyihalarni baham ko'rish kerak edi.
Asboblar. Biz nimadan foydalanamiz?
- Dockerning o'zi. Dockerfile bitta ilovaning bog'liqligini tavsiflaydi.
- Docker-compose - bu bizning bir nechta Docker ilovalarimizni birlashtiradigan to'plam.
- Biz manba kodini saqlash uchun GitLab dan foydalanamiz.
- Biz tizim integratsiyasi uchun GitLab-CI dan foydalanamiz.
Hisobot ikki qismdan iborat.
Birinchi qismda Docker qanday ishlab chiquvchilar mashinalarida ishga tushirilganligi haqida so'z boradi.
Ikkinchi bo'limda GitLab bilan qanday ishlashimiz, testlarni qanday o'tkazishimiz va Stagingga qanday o'tishimiz haqida so'z boradi.
Docker - bu zarur komponentlarni tavsiflash imkonini beruvchi (deklarativ yondashuvdan foydalangan holda) texnologiya. Bu Dockerfile misolidir. Bu erda biz rasmiy Ruby:2.3.0 Docker tasviridan meros qolganimizni e'lon qilamiz. Unda Ruby 2.3 versiyasi o'rnatilgan. Biz kerakli qurilish kutubxonalarini va NodeJS ni o'rnatamiz. Biz katalog yaratganimizni tasvirlaymiz /app. Ilova katalogini ishchi katalog sifatida o'rnating. Ushbu katalogga biz kerakli minimal Gemfile va Gemfile.lock ni joylashtiramiz. Keyin biz ushbu qaramlik tasvirini o'rnatadigan loyihalarni quramiz. Biz konteyner tashqi port 3000da tinglashga tayyor bo'lishini bildiramiz. Oxirgi buyruq bizning ilovamizni bevosita ishga tushiradigan buyruqdir. Agar loyihani ishga tushirish buyrug'ini bajarsak, dastur belgilangan buyruqni ishga tushirishga va ishga tushirishga harakat qiladi.
Bu docker-compose faylining minimal namunasidir. Bu holda biz ikkita konteyner o'rtasida aloqa mavjudligini ko'rsatamiz. Bu to'g'ridan-to'g'ri ma'lumotlar bazasi xizmati va veb-xizmatiga kiradi. Bizning veb-ilovalarimiz ko'p hollarda ma'lumotlarni saqlash uchun backend sifatida ma'lumotlar bazasini talab qiladi. Biz MySQL-dan foydalanayotganimiz sababli, misol MySQL-da - lekin boshqa ma'lumotlar bazasidan (PostgreSQL, Redis) foydalanishga hech narsa to'sqinlik qilmaydi.
Biz Docker uyasidan rasmiy manbadan MySQL 5.7.14 tasvirini o'zgartirmasdan olamiz. Biz veb-ilovamiz uchun javobgar bo'lgan rasmni joriy katalogdan yig'amiz. U birinchi ishga tushirish vaqtida biz uchun rasm to'playdi. Keyin u biz bu yerda bajarayotgan buyruqni ishga tushiradi. Agar orqaga qaytsak, Puma orqali ishga tushirish buyrug'i aniqlanganligini ko'ramiz. Puma - bu Ruby tilida yozilgan xizmat. Ikkinchi holda, biz bekor qilamiz. Bu buyruq bizning ehtiyojlarimiz yoki vazifalarimizga qarab o'zboshimchalik bilan bo'lishi mumkin.
Shuningdek, biz ishlab chiquvchi kompyuterimizdagi portni konteyner portidagi 3000 dan 3000 gacha yo'naltirishimiz kerakligini tasvirlaymiz. Bu to'g'ridan-to'g'ri Docker-ga o'rnatilgan iptables va uning mexanizmi yordamida avtomatik ravishda amalga oshiriladi.
Ishlab chiquvchi, avvalgidek, istalgan mavjud IP-manzilga kirishi mumkin, masalan, 127.0.0.1 - bu mashinaning mahalliy yoki tashqi IP-manzili.
Oxirgi satrda veb-konteyner JB konteyneriga bog'liqligini aytadi. Veb-konteynerning boshlanishini chaqirganimizda, docker-compose birinchi navbatda biz uchun ma'lumotlar bazasini ishga tushiradi. Ma'lumotlar bazasi boshida allaqachon (aslida, konteyner ishga tushirilgandan so'ng! Bu ma'lumotlar bazasi tayyorligiga kafolat bermaydi) dasturni ishga tushiradi, bizning backend.
Bu ma'lumotlar bazasi ko'tarilmaganda xatolardan qochadi va biz ma'lumotlar bazasi konteynerini to'xtatganimizda resurslarni tejaydi va shu bilan boshqa loyihalar uchun resurslarni bo'shatadi.
Loyihada ma'lumotlar bazasini dokerlashtirishdan foydalanish bizga nima beradi. Biz barcha ishlab chiquvchilar uchun MySQL versiyasini tuzatamiz. Bu versiyalar farq qilganda, sintaksis, konfiguratsiya, standart sozlamalar o'zgarganda yuzaga kelishi mumkin bo'lgan ba'zi xatolardan qochadi. Bu sizga ma'lumotlar bazasi, login, parol uchun umumiy xost nomini belgilash imkonini beradi. Biz ilgari mavjud bo'lgan konfiguratsiya fayllaridagi nomlar va ziddiyatlar hayvonot bog'idan uzoqlashmoqdamiz.
Rivojlanish muhiti uchun bizda standartdan farq qiladigan yanada maqbul konfiguratsiyadan foydalanish imkoniyati mavjud. MySQL sukut bo'yicha zaif mashinalar uchun sozlangan va uning ishlashi juda yomon.
Docker sizga kerakli versiyaning Python, Ruby, NodeJS, PHP tarjimonidan foydalanish imkonini beradi. Biz qandaydir versiya boshqaruvchisidan foydalanish zaruratidan xalos bo'lamiz. Ilgari Ruby loyihaga qarab versiyani o'zgartirish imkonini beruvchi rpm paketidan foydalangan. Shuningdek, u Docker konteyneri tufayli kodni muammosiz ko'chirish va uni bog'liqliklar bilan birga versiyalash imkonini beradi. Tarjimon va kodning versiyasini tushunishda bizda hech qanday muammo yo'q. Versiyani yangilash uchun eski idishni pastga tushiring va yangi idishni ko'taring. Agar biror narsa noto'g'ri bo'lsa, biz yangi idishni tushirishimiz, eski idishni ko'tarishimiz mumkin.
Tasvirni yaratgandan so'ng, ishlab chiqarish va ishlab chiqarishdagi konteynerlar bir xil bo'ladi. Bu, ayniqsa, katta o'rnatish uchun to'g'ri keladi.
Frontend-da biz JavaScipt va NodeJS-dan foydalanamiz.
Endi bizda ReacJS bo'yicha so'nggi loyiha bor. Ishlab chiquvchi konteynerdagi hamma narsani ishga tushirdi va hot-reload yordamida ishlab chiqdi.
Keyinchalik, JavaScipt yig'ish vazifasi ishga tushiriladi va nginx resurslarini tejash orqali statikaga tuzilgan kod beriladi.
Bu erda men oxirgi loyihamizning sxemasini berdim.
Qanday vazifalar hal qilindi? Bizga mobil qurilmalar o'zaro ta'sir qiladigan tizimni yaratish kerak edi. Ular ma'lumotlarni qabul qilishadi. Imkoniyatlardan biri bu qurilmaga push-bildirishnomalarni yuborishdir.
Buning uchun nima qildik?
Biz dasturga quyidagi komponentlarni ajratdik: JS da administrator qismi, Ruby on Rails ostida REST interfeysi orqali ishlaydigan backend. Backend ma'lumotlar bazasi bilan o'zaro ta'sir qiladi. Yaratilgan natija mijozga beriladi. Administrator paneli REST interfeysi orqali backend va ma'lumotlar bazasi bilan o'zaro ishlaydi.
Shuningdek, biz push-bildirishnomalarni yuborishimiz kerak edi. Bungacha bizda mobil platformalarga bildirishnomalarni yetkazib berish uchun mas’ul bo‘lgan mexanizmni joriy qilgan loyihamiz bor edi.
Biz quyidagi sxemani ishlab chiqdik: brauzer operatori administrator paneli bilan o'zaro ishlaydi, boshqaruv paneli backend bilan o'zaro ishlaydi, vazifa Push bildirishnomalarini yuborishdir.
Push-bildirishnomalar NodeJS-da amalga oshirilgan boshqa komponent bilan o'zaro ta'sir qiladi.
Navbatlar quriladi va keyin ularning mexanizmiga muvofiq bildirishnomalar yuboriladi.
Bu erda ikkita ma'lumotlar bazasi chizilgan. Hozirgi vaqtda Docker yordamida biz bir-biriga hech qanday aloqasi bo'lmagan 2 ta mustaqil ma'lumotlar bazasidan foydalanamiz. Bundan tashqari, ular umumiy virtual tarmoqqa ega va jismoniy ma'lumotlar ishlab chiquvchining mashinasida turli kataloglarda saqlanadi.
Xuddi shu, lekin raqamlarda. Bu erda kodni qayta ishlatish muhim ahamiyatga ega.
Agar ilgari biz kutubxonalar ko'rinishidagi kodni qayta ishlatish haqida gapirgan bo'lsak, unda bu misolda Push bildirishnomalariga javob beradigan xizmatimiz to'liq server sifatida qayta ishlatiladi. U API taqdim etadi. Va bizning yangi ishlanmamiz allaqachon u bilan o'zaro aloqada.
O'sha paytda biz NodeJS ning 4-versiyasidan foydalanardik. Endi (2017 yilda - tahr. eslatma) so'nggi ishlanmalarda biz NodeJS ning 7-versiyasidan foydalanamiz. Kutubxonalarning yangi versiyalarini jalb qilish uchun yangi komponentlarda hech qanday muammo yo'q.
Agar kerak bo'lsa, Push xabarnomasi xizmatidan NodeJS versiyasini qayta ko'rib chiqishingiz va oshirishingiz mumkin.
Va agar biz API muvofiqligini saqlab qola olsak, uni ilgari ishlatilgan boshqa loyihalar bilan almashtirish mumkin bo'ladi.
Docker qo'shish uchun nima kerak? Biz omborimizga kerakli bog'liqliklarni tavsiflovchi Dockerfile qo'shamiz. Ushbu misolda komponentlar mantiqiy ravishda ajratilgan. Bu backend dasturchining minimal to'plami.
Yangi loyiha yaratishda biz Dockerfile yaratamiz, kerakli ekotizimni (Python, Ruby, NodeJS) tavsiflaymiz. Docker-compose-da u kerakli bog'liqlikni - ma'lumotlar bazasini tavsiflaydi. Biz shunday va shunga o'xshash versiyaning ma'lumotlar bazasiga muhtojmiz, ma'lumotlarni u erda va u erda saqlang.
Statikga xizmat qilish uchun biz nginx bilan alohida uchinchi konteynerdan foydalanamiz. Rasmlarni yuklash imkoniyati mavjud. Backend ularni oldindan tayyorlangan hajmga qo'yadi, u ham nginx bilan konteynerga o'rnatiladi, bu esa statikni beradi.
Nginx, MySQL konfiguratsiyasini saqlash uchun biz kerakli konfiguratsiyalarni saqlaydigan Docker papkasini qo'shdik. Ishlab chiquvchi o'z mashinasida omborning git klonini qilsa, u allaqachon mahalliy rivojlanish uchun tayyor loyihaga ega bo'ladi. Qaysi port yoki qanday sozlamalar qo'llanilishi haqida hech qanday savol yo'q.
Keyinchalik, bizda bir nechta komponentlar mavjud: administrator, inform-API, push-bildirishnomalar.
Bularning barchasini boshlash uchun biz dockerized-app deb nomlangan yana bir ombor yaratdik. Ayni paytda biz har bir komponentdan oldin bir nechta omborlardan foydalanamiz. Ular shunchaki mantiqan farq qiladi - GitLab-da u papkaga o'xshaydi, lekin ishlab chiquvchining mashinasida ma'lum bir loyiha uchun papka. Bir daraja pastga - birlashtiriladigan komponentlar.
Bu faqat dockerized-app tarkibiga misol. Shuningdek, biz Docker katalogini bu erga keltiramiz, unda biz barcha komponentlarning o'zaro ta'siri uchun zarur bo'lgan konfiguratsiyalarni to'ldiramiz. Loyihani qanday ishga tushirishni qisqacha tavsiflovchi README.md mavjud.
Bu erda biz ikkita docker-compose faylini qo'lladik. Bu bosqichma-bosqich yugurish imkoniyatiga ega bo'lish uchun amalga oshiriladi. Ishlab chiquvchi yadro bilan ishlaganda, unga push-bildirishnomalar kerak emas, u shunchaki docker-compose faylini ishga tushiradi va shunga mos ravishda resurs saqlanadi.
Agar push bildirishnomalari bilan integratsiya qilish zarurati tug'ilsa, docker-compose.yaml va docker-compose-push.yaml ishga tushiriladi.
Docker-compose.yaml va docker-compose-push.yaml jildda bo'lgani uchun avtomatik ravishda bitta virtual tarmoq yaratiladi.
Komponentlarning tavsifi. Bu komponentlarni yig'ish uchun mas'ul bo'lgan yanada rivojlangan fayl. Bu erda nima diqqatga sazovor? Bu erda biz muvozanatlashtiruvchi komponentni kiritamiz.
Bu nginx bilan ishlaydigan tayyor Docker tasviri va Docker soketida tinglovchi ilova. Dinamik, konteynerlar yoqilgan va o'chirilganligi sababli, u nginx konfiguratsiyasini qayta tiklaydi. Biz komponentlar bilan ishlashni uchinchi darajali domen nomlari bo'yicha taqsimlaymiz.
Rivojlanish muhiti uchun biz .dev domenidan foydalanamiz - api.informer.dev. .dev domeniga ega ilovalar ishlab chiquvchining mahalliy mashinasida mavjud.
Bundan tashqari, konfiguratsiyalar har bir loyihaga o'tkaziladi va barcha loyihalar bir vaqtning o'zida birgalikda ishga tushiriladi.
Grafik jihatdan, mijoz bizning brauzerimiz yoki balanslovchiga so'rovlar yuboradigan ba'zi vosita ekanligi ayon bo'ldi.
Domen nomi balanschisi qaysi konteyner bilan bog'lanishni aniqlaydi.
Bu nginx bo'lishi mumkin, bu administratorga JS beradi. Bu nginx bo'lishi mumkin, bu API beradi, yoki nginx-ga tasvir yuklash shaklida beriladigan statik fayllar.
Diagramma shuni ko'rsatadiki, konteynerlar virtual tarmoq orqali ulangan va proksi-server orqasida yashiringan.
Ishlab chiqaruvchining mashinasida siz IP-ni bilgan holda konteynerga kirishingiz mumkin, lekin printsipial jihatdan biz bundan foydalanmaymiz. To'g'ridan-to'g'ri kirishga deyarli ehtiyoj yo'q.
Ilovangizni dokerizatsiya qilish uchun qaysi misolni ko'rish kerak? Menimcha, yaxshi misol MySQL uchun rasmiy docker tasviridir.
Bu juda qiyin. Ko'p versiyalar mavjud. Ammo uning funksionalligi keyingi rivojlanish jarayonida yuzaga kelishi mumkin bo'lgan ko'plab ehtiyojlarni qondirishga imkon beradi. Agar siz vaqt sarflasangiz va bularning barchasi qanday o'zaro ta'sir qilishini aniqlasangiz, menimcha, o'zingizni amalga oshirishda sizda hech qanday muammo bo'lmaydi.
Hub.docker.com odatda github.com ga havolalarni o'z ichiga oladi, u to'g'ridan-to'g'ri tasvirni o'zingiz yaratishingiz mumkin bo'lgan xom ma'lumotlarni o'z ichiga oladi.
Bundan tashqari, ushbu omborda docker-endpoint.sh skripti mavjud bo'lib, u dastlabki ishga tushirish va dasturni ishga tushirishni keyingi qayta ishlash uchun javobgardir.
Shuningdek, ushbu misolda muhit o'zgaruvchilari yordamida sozlash imkoniyati mavjud. Bitta konteynerni ishga tushirishda yoki docker-compose orqali muhit o'zgaruvchisini aniqlash orqali biz docker MySQL-da ildiz otishi uchun bo'sh parol o'rnatishimiz kerakligini yoki biz xohlagan narsani aytishimiz mumkin.
Tasodifiy parol yaratish imkoniyati mavjud. Bizga foydalanuvchi kerak, foydalanuvchiga parol qo‘yish kerak, ma’lumotlar bazasi yaratish kerak deymiz.
Loyihalarimizda biz ishga tushirish uchun mas'ul bo'lgan Dockerfile-ni biroz birlashtirdik. U erda biz uni faqat ilova foydalanadigan foydalanuvchi huquqlarining kengaytmasi qilish uchun o'z ehtiyojlarimizga moslashtirdik. Bu bizga keyinchalik dastur konsolidan oddiygina ma'lumotlar bazasini yaratishga imkon berdi. Ruby ilovalarida ma'lumotlar bazalarini yaratish, o'zgartirish va o'chirish buyrug'i mavjud.
Bu github.com saytida MySQL-ning o'ziga xos versiyasi qanday ko'rinishiga misoldir. Siz Dockerfile-ni ochib, u erda o'rnatish qanday ketayotganini ko'rishingiz mumkin.
docker-endpoint.sh - kirish nuqtasi uchun mas'ul bo'lgan skript. Dastlabki ishga tushirish vaqtida ba'zi tayyorgarlik bosqichlari talab qilinadi va bu harakatlar faqat ishga tushirish skriptida amalga oshiriladi.
Keling, ikkinchi qismga o'tamiz.
Manba kodlarini saqlash uchun biz gitlab-ga o'tdik. Bu vizual interfeysga ega bo'lgan juda kuchli tizim.
Gitlab komponentlaridan biri Gitlab CI hisoblanadi. Bu sizga keyinchalik kodni yetkazib berish tizimini tashkil qilish yoki avtomatik sinovni o'tkazish uchun foydalaniladigan buyruqlar ketma-ketligini tasvirlash imkonini beradi.
Gitlab CI 2 suhbati - Ruby Russia klubidan reportaj - juda batafsil va ehtimol sizni qiziqtiradi.
Endi biz Gitlab CI-ni faollashtirish uchun nima kerakligini ko'rib chiqamiz. Gitlab CI ni ishga tushirish uchun biz faqat .gitlab-ci.yml faylini loyihaning ildiziga qo'yishimiz kerak.
Bu erda biz sinov, joylashtirish kabi holatlar ketma-ketligini bajarishni xohlayotganimizni tasvirlaymiz.
Biz ilovamizni yaratish uchun bevosita docker-compose chaqiruvchi skriptlarni bajaramiz. Bu shunchaki backend misoli.
Keyinchalik, ma'lumotlar bazasini o'zgartirish va testlarni o'tkazish uchun migratsiyani amalga oshirish kerakligini aytamiz.
Agar skriptlar to'g'ri bajarilgan bo'lsa va xato kodini qaytarmasa, tizim joylashtirishning ikkinchi bosqichiga o'tadi.
Joylashtirish bosqichi hozirda sahnalashtirish uchun amalga oshirilmoqda. Biz nol ishlamay qolgan qayta ishga tushirishni tashkil qilmadik.
Biz barcha idishlarni majburan o'chiramiz va keyin sinov paytida birinchi bosqichda yig'ilgan barcha idishlarni yana ko'taramiz.
Biz joriy muhit o'zgaruvchisi uchun ishlab chiquvchilar tomonidan yozilgan ma'lumotlar bazasini ko'chirish uchun ishlayapmiz.
Bu faqat asosiy filialga tegishli ekanligi haqida eslatma mavjud.
Boshqa filiallarni o'zgartirganda bajarilmaydi.
Filiallar bo'yicha ishlab chiqarishni tashkil qilish mumkin.
Buni yanada tartibga solish uchun biz Gitlab Runner-ni o'rnatishimiz kerak.
Ushbu yordamchi dastur Golang tilida yozilgan. Bu Golang dunyosida keng tarqalgan bo'lib, hech qanday bog'liqlikni talab qilmaydigan yagona fayldir.
Ishga tushganda biz Gitlab Runner-ni ro'yxatdan o'tkazamiz.
Biz kalitni Gitlab veb-interfeysida olamiz.
Keyin buyruq satrida ishga tushirish buyrug'ini chaqiramiz.
Gitlab Runner-ni interaktiv tarzda sozlash (Shell, Docker, VirtualBox, SSH)
Gitlab Runner-dagi kod .gitlab-ci.yml sozlamasiga qarab har bir topshiriqda bajariladi.
Veb-interfeysda Gitlab-da qanday ko'rinishda. GItlab CI-ni ulaganimizdan so'ng, bizda hozirda qurilish holatini ko'rsatadigan bayroq mavjud.
Ko'ryapmizki, 4 daqiqa oldin majburiyat qilingan, u barcha sinovlardan o'tgan va hech qanday muammo tug'dirmagan.
Qurilishlarni batafsil ko'rib chiqishimiz mumkin. Bu erda biz ikki davlat allaqachon o'tganligini ko'ramiz. Sahnalashtirishda sinov holati va joylashtirish holati.
Agar biz ma'lum bir tuzilishni bossak, u holda .gitlab-ci.yml ga muvofiq jarayonda bajarilgan buyruqlarning konsol chiqishi bo'ladi.
Bizning mahsulot tariximiz shunday ko'rinadi. Muvaffaqiyatli urinishlar bo'lganini ko'ramiz. Sinovlar topshirilganda, u keyingi bosqichga o'tmaydi va bosqich kodi yangilanmaydi.
Docker-ni amalga oshirganimizda biz sahnalashtirishda qanday vazifalarni hal qildik? Bizning tizimimiz komponentlardan iborat va biz butun tizimni emas, balki omborda yangilangan komponentlarning faqat bir qismini qayta ishga tushirishimiz kerak edi.
Buning uchun biz hamma narsani alohida papkalarga maydalashimiz kerak edi.
Buni amalga oshirganimizdan so'ng, Docker-compose har bir dada uchun o'z tarmoq maydonini yaratishi va qo'shni komponentlarini ko'rmasligi bilan bog'liq muammoga duch keldik.
O'tish uchun biz Docker-da tarmoqni qo'lda yaratdik. Docker-compose-da siz ushbu loyiha uchun bunday tarmoqdan foydalanasiz deb yozilgan.
Shunday qilib, ushbu to'r bilan boshlangan har bir komponent tizimning boshqa qismlaridagi komponentlarni ko'radi.
Keyingi masala sahnalashtirishni bir nechta loyihalarga bo'lishdir.
Bularning barchasi chiroyli ko'rinishi va ishlab chiqarishga imkon qadar yaqin bo'lishi uchun WEB-ning hamma joyida qo'llaniladigan 80 yoki 443 portidan foydalanish yaxshidir.
Biz buni qanday hal qildik? Biz barcha yirik loyihalarga bitta Gitlab Runnerni tayinladik.
Gitlab sizga bir nechta taqsimlangan Gitlab Runners dasturini ishga tushirish imkonini beradi, ular shunchaki barcha vazifalarni tartibsiz tarzda o'z zimmasiga oladi va ularni boshqaradi.
Uyimiz yo'qligi uchun biz loyihalarimiz guruhini bitta Gitlab Runner bilan chekladik, u bizning hajmlarimiz bilan muammosiz kurashadi.
Biz nginx-proksini alohida ishga tushirish skriptiga o'tkazdik va undagi barcha loyihalar uchun panjara qo'shdik.
Bizning loyihamiz bitta panjaraga ega va balanslashtirgichda loyiha nomlari bo'yicha bir nechta panjara mavjud. U yana domen nomlari bo'yicha proksi-serverni amalga oshirishi mumkin.
Bizning so'rovlarimiz 80-portdagi domen orqali keladi va ushbu domenga xizmat ko'rsatadigan konteyner guruhiga hal qilinadi.
Yana qanday muammolar bor edi? Bu barcha konteynerlar sukut bo'yicha root sifatida ishlaydi. Bu tizimning ildiz xostiga teng bo'lmagan ildiz.
Biroq, agar siz konteynerga kirsangiz, u root bo'ladi va biz ushbu konteynerda yaratgan fayl ildiz huquqlarini oladi.
Agar ishlab chiquvchi konteynerga kirgan bo'lsa va u erda fayllarni yaratadigan ba'zi buyruqlarni bajargan bo'lsa, keyin konteynerni tark etgan bo'lsa, unda uning ishchi katalogida u kirish huquqiga ega bo'lmagan fayl mavjud.
Buni qanday hal qilish mumkin? Siz konteynerda bo'ladigan foydalanuvchilarni qo'shishingiz mumkin.
Foydalanuvchini qo'shganimizda qanday muammolar paydo bo'ldi?
Foydalanuvchi yaratishda bizda ko'pincha bir xil guruh identifikatori (UID) va foydalanuvchi identifikatori (GID) bo'lmaydi.
Konteynerdagi ushbu muammoni hal qilish uchun biz ID 1000 foydalanuvchilardan foydalanamiz.
Bizning holatda, bu deyarli barcha ishlab chiquvchilar Ubuntu OS dan foydalanishiga to'g'ri keldi. Ubuntuda esa birinchi foydalanuvchi 1000 identifikatoriga ega.
Bizning rejalarimiz bormi?
Docker hujjatlarini o'qing. Loyiha faol rivojlanmoqda, hujjatlar o'zgarib bormoqda. Ikki-uch oy oldin olingan ma'lumotlar asta-sekin eskirib bormoqda.
Biz hal qilgan ba'zi muammolar allaqachon standart vositalar yordamida hal qilingan.
Shuning uchun men to'g'ridan-to'g'ri orkestrga borish uchun oldinga borishni xohlayman.
Bitta misol Dockerning o'rnatilgan Docker Swarm deb nomlangan mexanizmi bo'lib, u qutidan chiqadi. Men Docker Swarm texnologiyasi asosida ishlab chiqarishda biror narsa ishga tushirishni xohlayman.
Yumurtlama konteynerlari jurnallar bilan ishlashni noqulay qiladi. Endi jurnallar izolyatsiya qilingan. Ular konteynerlar bo'ylab tarqalib ketgan. Vazifalardan biri veb-interfeys orqali jurnallarga qulay kirishni ta'minlashdir.
Manba: www.habr.com