Би Inventos-ийн Александр Сигачевын "Docker + Gitlab CI-тэй хөгжүүлэлт ба туршилтын үйл явц" тайлангийн хуулбарыг уншихыг санал болгож байна.
Docker + Gitlab CI дээр суурилсан хөгжүүлэлт, туршилтын үйл явцыг дөнгөж хэрэгжүүлж эхэлж байгаа хүмүүс ихэвчлэн үндсэн асуултуудыг асуудаг. Хаанаас эхлэх вэ? Хэрхэн зохион байгуулах вэ? Хэрхэн тест хийх вэ?
Энэхүү тайлан нь Docker болон Gitlab CI-г ашиглан хөгжүүлэлт, туршилтын үйл явцын талаар тодорхой бүтэцтэй ярьдаг тул сайн байна. Тайлан нь өөрөө 2017 оных. Энэхүү илтгэлээс та үндэс суурь, арга зүй, санаа, хэрэглээний туршлагаас суралцах боломжтой гэж бодож байна.
Хэнд хамаатай юм бэ, муурны доор уу.
Намайг Александр Сигачев гэдэг. Би Inventos-д ажилладаг. Би танд Docker-ийг ашигласан туршлага болон компаний төслүүд дээр хэрхэн аажмаар хэрэгжүүлж байгаа талаар ярих болно.
Илтгэлийн сэдэв: Docker болон Gitlab CI ашиглан хөгжүүлэлтийн процесс.
Энэ бол миний Докерын тухай хоёр дахь яриа юм. Эхний тайланг гаргах үед бид Docker in Development програмыг зөвхөн хөгжүүлэгч машинууд дээр ашигласан. Docker ашигласан ажилчдын тоо ойролцоогоор 2-3 хүн байсан. Аажмаар туршлага хуримтлуулж, жаахан урагшиллаа. Манай холбоос .
Энэ тайланд юу байх вэ? Бид ямар тармуур цуглуулсан, ямар асуудлыг шийдсэн талаар туршлагаа хуваалцах болно. Энэ нь хаа сайгүй үзэсгэлэнтэй биш байсан ч цааш явах боломжийг олгосон.
Бидний уриа бол бидний гарт хүрч болох бүх зүйлийг холбоно.
Бид ямар асуудлыг шийдэж байна вэ?
Компанид хэд хэдэн баг байх үед программист нь хуваалцсан нөөц юм. Программистыг нэг төслөөс сугалж, өөр төсөлд хэсэг хугацаагаар өгөх үе шатууд байдаг.
Программист хурдан ойлгохын тулд төслийн эх кодыг татаж аваад орчинг аль болох хурдан эхлүүлэх шаардлагатай бөгөөд энэ нь түүнд энэ төслийн асуудлыг шийдвэрлэхэд шилжих боломжийг олгоно.
Ихэвчлэн хэрэв та эхнээс нь эхлүүлбэл төсөлд баримт бичиг бага байдаг. Хэрхэн тохируулах тухай мэдээллийг зөвхөн хуучин хүмүүс л авах боломжтой. Ажилчид ганц хоёр хоногийн дотор ажлын байраа өөрсдөө засдаг. Үүнийг хурдасгахын тулд бид Docker ашигласан.
Дараагийн шалтгаан нь Хөгжил дэх тохиргооны стандартчилал юм. Миний туршлагаас харахад хөгжүүлэгчид үргэлж санаачлагатай байдаг. Тав дахь тохиолдол бүрт захиалгат домэйн ордог, жишээлбэл, vasya.dev. Түүний хажууд petya.dev нэртэй хөрш Петя сууж байна. Тэд энэ домэйн нэрийг ашиглан вэбсайт эсвэл системийн зарим бүрэлдэхүүн хэсгийг боловсруулдаг.
Систем томорч, эдгээр домэйн нэрүүд тохиргоонд орж эхлэх үед Хөгжлийн орчны зөрчил үүсч, сайтын замыг дахин бичнэ.
Өгөгдлийн сангийн тохиргоонд мөн адил зүйл тохиолддог. Хэн нэгэн аюулгүй байдлын талаар санаа зовдоггүй бөгөөд хоосон root нууц үгээр ажилладаг. Суулгах шатанд MySQL хэн нэгнээс нууц үг асуухад нууц үг нь 123 болж хувирсан. Өгөгдлийн сангийн тохиргоо хөгжүүлэгчийн амлалтаас хамааран байнга өөрчлөгдөж байдаг. Хэн нэгэн залруулсан, хэн нэгэн тохиргоог засаагүй байна. Бид ямар нэгэн туршилтын тохиргоо хийх үед заль мэх байсан .gitignore хөгжүүлэгч бүр мэдээллийн баазыг суулгах шаардлагатай болсон. Энэ нь эхлэхэд хэцүү болгосон. Энэ нь бусад зүйлсийн дунд мэдээллийн сангийн талаар санах хэрэгтэй. Өгөгдлийн санг эхлүүлэх, нууц үг оруулах, хэрэглэгч бүртгүүлэх, хүснэгт үүсгэх гэх мэт.
Өөр нэг асуудал бол номын сангийн янз бүрийн хувилбарууд юм. Хөгжүүлэгч өөр өөр төслүүдтэй ажилладаг нь ихэвчлэн тохиолддог. Таван жилийн өмнө (2017 оноос - ред. тэмдэглэл) эхэлсэн Legacy төсөл бий. Эхлэх үед бид MySQL 5.5-аас эхэлсэн. Мөн MySQL-ийн илүү орчин үеийн хувилбаруудыг, жишээлбэл 5.7 ба түүнээс дээш хувилбарыг хэрэгжүүлэхийг хичээдэг орчин үеийн төслүүд байдаг (2017 онд - ред. тэмдэглэл)
MySQL-тэй ажилладаг хэн бүхэн эдгээр сангууд нь хамаарлыг авчирдаг гэдгийг мэддэг. 2 баазыг хамтад нь ажиллуулах нь нэлээд асуудалтай байдаг. Наад зах нь хуучин үйлчлүүлэгчид шинэ мэдээллийн сантай холбогдоход бэрхшээлтэй байдаг. Энэ нь эргээд хэд хэдэн асуудал үүсгэдэг.
Дараагийн асуудал бол хөгжүүлэгч орон нутгийн машин дээр ажиллахдаа дотоод нөөц, локал файл, локал RAM ашигладаг. Асуудлын шийдлийг боловсруулах үеийн бүх харилцан үйлчлэл нь нэг машин дээр ажилладаг гэсэн үндсэн дээр явагддаг. Жишээ нь бид Үйлдвэрлэл 3-т backend серверүүдтэй бөгөөд хөгжүүлэгч нь файлуудыг үндсэн директорт хадгалдаг бөгөөд тэндээс nginx хүсэлтэд хариу өгөхийн тулд файлуудыг авдаг. Ийм код үйлдвэрлэлд ороход энэ файл 3 серверийн аль нэгэнд байгаа болох нь тогтоогдсон.
Микро үйлчилгээний чиглэл одоо хөгжиж байна. Бид том програмуудаа өөр хоорондоо харилцан үйлчлэлцдэг зарим жижиг бүрэлдэхүүн хэсгүүдэд хуваах үед. Энэ нь танд тодорхой багц даалгаврын технологийг сонгох боломжийг олгодог. Энэ нь мөн хөгжүүлэгчдийн хооронд ажил, үүрэг хариуцлагыг хуваалцах боломжийг олгодог.
JS дээр хөгжиж буй Frondend-хөгжүүлэгч нь Backend дээр бараг ямар ч нөлөө үзүүлэхгүй. Backend хөгжүүлэгч нь эргээд манай тохиолдолд Ruby on Rails-ийг хөгжүүлдэг бөгөөд Фронденд саад болохгүй. Харилцааг API ашиглан гүйцэтгэдэг.
Урамшууллын хувьд бид Докерын тусламжтайгаар 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 дээр сонсоход бэлэн болно гэдгийг харуулж байна. Сүүлийн тушаал нь манай програмыг шууд ажиллуулдаг тушаал юм. Хэрэв бид төсөл эхлүүлэх командыг гүйцэтгэх юм бол програм нь заасан тушаалыг ажиллуулж, ажиллуулахыг оролдох болно.
Энэ бол docker-compose файлын хамгийн бага жишээ юм. Энэ тохиолдолд бид хоёр савны хооронд холболт байгааг харуулж байна. Энэ нь мэдээллийн сангийн үйлчилгээ болон вэб үйлчилгээнд шууд ордог. Манай вэб програмууд ихэнх тохиолдолд өгөгдөл хадгалахын тулд ямар нэгэн мэдээллийн сан шаарддаг. Бид MySQL-г ашиглаж байгаа тул жишээ нь MySQL-д байгаа боловч өөр мэдээллийн санг (PostgreSQL, Redis) ашиглахад юу ч саад болохгүй.
Бид MySQL 5.7.14-ийн зургийг Docker hub-ийн албан ёсны эх сурвалжаас ямар ч өөрчлөлтгүйгээр авдаг. Бид вэб програмыг хариуцах зургийг одоогийн лавлахаас цуглуулдаг. Энэ нь анхны нээлтийн үеэр бидэнд зориулж зураг цуглуулдаг. Дараа нь бидний энд гүйцэтгэж байгаа командыг ажиллуулна. Хэрэв бид буцаж очвол Puma-аар дамжуулан эхлүүлэх команд тодорхойлогдсон болохыг харах болно. Puma бол Ruby хэл дээр бичигдсэн үйлчилгээ юм. Хоёр дахь тохиолдолд бид дарж бичнэ. Энэ тушаал нь бидний хэрэгцээ, даалгавараас хамааран дур зоргоороо байж болно.
Мөн бид хөгжүүлэгчийн хост машин дээрх портыг контейнер порт дээрх 3000-аас 3000 хүртэл дамжуулах шаардлагатайг тайлбарлаж байна. Энэ нь Docker-д шууд суулгагдсан iptables болон түүний механизмыг ашиглан автоматаар хийгддэг.
Хөгжүүлэгч нь өмнөх шигээ ямар ч боломжтой IP хаяг руу хандах боломжтой, жишээлбэл, 127.0.0.1 нь машины дотоод эсвэл гадаад IP хаяг юм.
Сүүлийн мөрөнд вэб контейнер нь db контейнерээс хамаарна гэж бичсэн байна. Бид вэб контейнерийн эхлэлийг дуудах үед docker-compose эхлээд бидний мэдээллийн санг эхлүүлнэ. Мэдээллийн сангийн эхэнд аль хэдийн (үнэндээ контейнерыг ажиллуулсны дараа! Энэ нь мэдээллийн сангийн бэлэн байдлын баталгаа биш юм) програмыг эхлүүлэх болно, бидний backend.
Энэ нь өгөгдлийн сан ажиллахгүй үед алдаа гарахаас зайлсхийж, өгөгдлийн сангийн контейнерыг зогсоох үед нөөцийг хэмнэж, бусад төслүүдийн нөөцийг чөлөөлдөг.
Төсөл дээр өгөгдлийн сангийн докержуулалтыг ашиглах боломжийг бидэнд олгодог зүйл. Бид бүх хөгжүүлэгчдэд MySQL-ийн хувилбарыг засдаг. Энэ нь хувилбаруудын зөрүү, синтакс, тохиргоо, үндсэн тохиргоог өөрчлөх үед гарч болох зарим алдаанаас зайлсхийдэг. Энэ нь өгөгдлийн сангийн нийтлэг хостын нэр, нэвтрэх нэр, нууц үгийг зааж өгөх боломжийг танд олгоно. Бид өмнө нь байсан тохиргооны файлуудын нэр, зөрчилдөөний амьтны хүрээлэнгээс холдож байна.
Бидэнд Хөгжлийн орчинд илүү оновчтой тохиргоог ашиглах боломж байгаа бөгөөд энэ нь анхдагч тохиргооноос ялгаатай. MySQL нь анхдагчаар сул машинуудад тохируулагдсан байдаг бөгөөд түүний гүйцэтгэл нь маш муу байдаг.
Docker нь хүссэн хувилбарынхаа Python, Ruby, NodeJS, PHP орчуулагчийг ашиглах боломжийг олгодог. Бид ямар нэгэн хувилбарын менежер ашиглах хэрэгцээ шаардлагаас ангижрах болно. Өмнө нь Ruby нь төслөөс хамааран хувилбарыг өөрчлөх боломжийг олгодог rpm багцыг ашигладаг байсан. Энэ нь мөн Docker контейнерийн ачаар кодыг хялбархан шилжүүлж, хамаарлын хамт хувилбар болгох боломжийг олгодог. Бид орчуулагч болон кодын аль алиных нь хувилбарыг ойлгоход асуудалгүй. Хувилбарыг шинэчлэхийн тулд хуучин савыг буулгаж, шинэ савыг дээшлүүлнэ. Хэрэв ямар нэг зүйл буруу болвол бид шинэ савыг буулгаж, хуучин савыг дээшлүүлж болно.
Зургийг бүтээсний дараа Хөгжлийн болон Үйлдвэрлэлийн аль алинд нь савнууд ижил байх болно. Энэ нь ялангуяа том хэмжээний суурилуулалтын хувьд үнэн юм.
Frontend дээр бид JavaScipt болон NodeJS ашигладаг.
Одоо бидэнд ReacJS дээрх хамгийн сүүлийн төсөл байна. Хөгжүүлэгч нь саванд байгаа бүх зүйлийг ажиллуулж, халуун дахин ачааллыг ашиглан хөгжүүлсэн.
Дараа нь JavaScipt угсралтын ажлыг эхлүүлж, статик болгон хөрвүүлсэн кодыг nginx хэмнэх нөөцөөр дамжуулан өгнө.
Энд би сүүлийн төслийнхөө схемийг өгсөн.
Ямар ажлуудыг шийдсэн бэ? Бид хөдөлгөөнт төхөөрөмжүүдтэй харилцах системийг бий болгох шаардлагатай болсон. Тэд өгөгдөл хүлээн авдаг. Нэг боломж бол энэ төхөөрөмж рүү түлхэх мэдэгдэл илгээх явдал юм.
Үүний тулд бид юу хийсэн бэ?
Бид JS дээрх админ хэсэг, Ruby on Rails доорх REST интерфэйсээр ажилладаг арын хэсэг зэрэг программд хуваагдсан. Backend нь мэдээллийн сантай харилцдаг. Үүсгэсэн үр дүнг үйлчлүүлэгчид өгдөг. Админ самбар нь REST интерфэйсээр дамжуулан backend болон мэдээллийн сантай харилцдаг.
Бид бас түлхэх мэдэгдэл илгээх шаардлагатай болсон. Үүнээс өмнө бид гар утасны платформд мэдэгдэл хүргэх үүрэгтэй механизмыг хэрэгжүүлсэн төсөлтэй байсан.
Бид дараах схемийг боловсруулсан: хөтөчийн оператор админ самбартай харилцдаг, админ самбар нь арын хэсэгтэй харилцдаг, даалгавар бол Push мэдэгдэл илгээх явдал юм.
Түлхэх мэдэгдэл нь NodeJS-д хэрэгжсэн өөр бүрэлдэхүүн хэсэгтэй харилцан үйлчилдэг.
Дараалал үүсгэж, дараа нь тэдгээрийн механизмын дагуу мэдэгдлийг илгээдэг.
Энд хоёр мэдээллийн санг зурсан. Одоогийн байдлаар бид Docker-ийн тусламжтайгаар бие биенээсээ хамааралгүй 2 бие даасан мэдээллийн санг ашиглаж байна. Нэмж дурдахад тэдгээр нь нийтлэг виртуал сүлжээтэй бөгөөд физик өгөгдөл нь хөгжүүлэгчийн машин дээрх өөр өөр директоруудад хадгалагддаг.
Үүнтэй адил боловч тоогоор. Энэ бол кодыг дахин ашиглах нь чухал юм.
Хэрэв бид өмнө нь номын сан хэлбэрээр кодыг дахин ашиглах талаар ярьсан бол энэ жишээнд Push мэдэгдэлд хариу өгөх үйлчилгээг бүрэн сервер болгон дахин ашиглаж байна. Энэ нь API өгдөг. Мөн бидний шинэ хөгжил үүнтэй аль хэдийн харилцаж байна.
Тэр үед бид NodeJS-ийн 4-р хувилбарыг ашиглаж байсан. Одоо (2017 онд - ред. тэмдэглэл) сүүлийн үеийн хөгжүүлэлтүүдэд бид NodeJS-ийн 7 хувилбарыг ашиглаж байна. Номын сангийн шинэ хувилбаруудыг оруулах шинэ бүрэлдэхүүн хэсгүүдэд ямар ч асуудал байхгүй.
Шаардлагатай бол Push мэдэгдлийн үйлчилгээнээс NodeJS хувилбарыг дахин засварлаж, өсгөж болно.
Хэрэв бид API нийцтэй байдлыг хангаж чадвал үүнийг өмнө нь ашиглаж байсан бусад төслүүдээр солих боломжтой болно.
Docker нэмэхэд юу хэрэгтэй вэ? Бид шаардлагатай хамаарлыг тодорхойлсон Dockerfile-г өөрийн агуулахдаа нэмдэг. Энэ жишээнд бүрэлдэхүүн хэсгүүдийг логикоор задалсан. Энэ нь backend хөгжүүлэгчийн хамгийн бага багц юм.
Шинэ төсөл үүсгэхдээ бид Dockerfile үүсгэж, хүссэн экосистемийг (Python, Ruby, NodeJS) дүрсэлдэг. Docker-compose-д энэ нь шаардлагатай хамаарлыг тодорхойлдог - мэдээллийн бааз. Бидэнд ийм хувилбарын мэдээллийн сан хэрэгтэй, тэнд тэнд мэдээлэл хадгалдаг гэж тайлбарладаг.
Бид статикаар үйлчлэхийн тулд nginx-тэй тусдаа гурав дахь савыг ашигладаг. Зураг оруулах боломжтой. Backend нь тэдгээрийг урьдчилан бэлтгэсэн эзлэхүүнд оруулдаг бөгөөд энэ нь мөн статикийг өгдөг nginx-тэй саванд суурилуулсан байдаг.
Nginx, mysql тохиргоог хадгалахын тулд бид шаардлагатай тохиргоог хадгалдаг Docker хавтас нэмсэн. Хөгжүүлэгч өөрийн машин дээр репозиторын git клон хийх үед түүнд орон нутгийн хөгжилд бэлэн төсөл бэлэн болсон байна. Ямар порт эсвэл ямар тохиргоог ашиглах талаар асуулт байхгүй.
Дараа нь бид хэд хэдэн бүрэлдэхүүн хэсэгтэй: админ, мэдээлэл-API, түлхэх мэдэгдэл.
Энэ бүхнийг эхлүүлэхийн тулд бид өөр репозитор үүсгэсэн бөгөөд үүнийг бид dockerized-app гэж нэрлэсэн. Одоогоор бид бүрэлдэхүүн хэсэг бүрийн өмнө хэд хэдэн агуулах ашиглаж байна. Тэд зүгээр л логикийн хувьд өөр өөр байдаг - GitLab дээр энэ нь хавтас мэт харагддаг, харин хөгжүүлэгчийн машин дээр тодорхой төсөлд зориулсан хавтас юм. Нэг түвшний доошоо бүрэлдэхүүн хэсгүүдийг нэгтгэх болно.
Энэ бол зөвхөн dockerized-app-н агуулгын жишээ юм. Бид мөн бүх бүрэлдэхүүн хэсгүүдийн харилцан үйлчлэлд шаардлагатай тохиргоог бөглөх Docker лавлахыг энд авчирдаг. Төслийг хэрхэн ажиллуулах талаар товч тайлбарласан README.md байдаг.
Энд бид хоёр docker-compose файлыг ашигласан. Үүнийг алхам алхмаар гүйх боломжтой болгохын тулд хийдэг. Хөгжүүлэгч нь цөмтэй ажиллах үед түүнд түлхэх мэдэгдэл шаардлагагүй, тэр зүгээр л docker-compose файлыг ажиллуулж, үүний дагуу нөөцийг хадгалдаг.
Хэрэв түлхэх мэдэгдлүүдтэй нэгтгэх шаардлагатай бол 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 эсвэл бидний хүссэн бүх зүйл дээр докерыг root болгохын тулд хоосон нууц үгийг тохируулах хэрэгтэй гэж хэлж болно.
Санамсаргүй нууц үг үүсгэх сонголт байдаг. Бидэнд хэрэглэгч хэрэгтэй, хэрэглэгчийн нууц үг, мэдээллийн сан үүсгэх хэрэгтэй гэж ярьдаг.
Төсөлдөө бид эхлүүлэх үүрэгтэй Dockerfile-ийг бага зэрэг нэгтгэсэн. Тэнд бид үүнийг зөвхөн програмын ашигладаг хэрэглэгчийн эрхийн өргөтгөл болгох үүднээс өөрсдийн хэрэгцээнд тохируулан зассан. Энэ нь дараа нь програмын консолоос мэдээллийн сан үүсгэх боломжийг бидэнд олгосон. Ruby програмууд нь мэдээллийн санг үүсгэх, өөрчлөх, устгах командтай байдаг.
Энэ бол github.com дээр MySQL-ийн тодорхой хувилбар ямар харагддагийн жишээ юм. Та 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 Runner-ийг ажиллуулах боломжийг олгодог бөгөөд энэ нь зүгээр л бүх даалгаврыг эмх замбараагүй байдлаар авч, ажиллуулах болно.
Бид байшингүй болохын тулд төслийнхээ бүлгийг нэг Gitlab Runner-ээр хязгаарласан бөгөөд энэ нь бидний эзлэхүүнийг асуудалгүй даван туулж байна.
Бид nginx-proxy-г тусдаа эхлүүлэх скрипт рүү шилжүүлж, доторх бүх төслүүдийн сүлжээг нэмсэн.
Манай төсөл нэг сүлжээтэй, тэнцвэржүүлэгч нь төслийн нэрээр хэд хэдэн тортой. Энэ нь цаашид домэйн нэрээр прокси хийх боломжтой.
Бидний хүсэлтүүд 80-р порт дээрх домэйнээр дамжин ирдэг бөгөөд энэ домэйнд үйлчилдэг контейнер бүлэгт шийдэгддэг.
Өөр ямар асуудал байсан бэ? Энэ нь бүх контейнер анхдагчаар root хэлбэрээр ажилладаг. Энэ нь системийн үндсэн хосттой тэгш бус үндэс юм.
Гэсэн хэдий ч, хэрэв та контейнер руу орвол энэ нь root байх бөгөөд бидний энэ саванд үүсгэсэн файл root эрхийг авна.
Хэрэв хөгжүүлэгч контейнер руу орж, файл үүсгэх зарим тушаалуудыг хийж, дараа нь контейнерийг орхисон бол түүний ажлын директорт хандах эрхгүй файл байна.
Үүнийг хэрхэн шийдвэрлэх вэ? Та контейнерт байх хэрэглэгчдийг нэмж болно.
Хэрэглэгчийг нэмэхэд ямар асуудал гарсан бэ?
Хэрэглэгч үүсгэх үед бид ихэвчлэн ижил бүлгийн ID (UID) болон хэрэглэгчийн ID (GID) байдаггүй.
Контейнер дээрх энэ асуудлыг шийдэхийн тулд бид ID 1000-тай хэрэглэгчдийг ашигладаг.
Манай тохиолдолд энэ нь бараг бүх хөгжүүлэгчид Ubuntu үйлдлийн системийг ашигладагтай давхцсан. Мөн Ubuntu дээр анхны хэрэглэгч 1000 ID-тай.
Бидэнд төлөвлөгөө бий юу?
Docker баримт бичгийг уншина уу. Төсөл идэвхтэй хөгжиж, баримт бичиг өөрчлөгдөж байна. Хоёр, гурван сарын өмнө хүлээн авсан мэдээлэл аажмаар хуучирч байна.
Бидний шийдсэн зарим асуудлыг стандарт хэрэгслээр шийдсэн байх магадлалтай.
Тиймээс би найрал хөгжим рүү шууд очихын тулд цаашаа явмаар байна.
Үүний нэг жишээ бол хайрцагнаас гарч ирдэг Docker Swarm хэмээх Docker-ийн суурилуулсан механизм юм. Би Docker Swarm технологи дээр суурилсан үйлдвэрлэлд ямар нэгэн зүйл ажиллуулахыг хүсч байна.
Түрс шахах сав нь гуалинтай ажиллахад тохиромжгүй болгодог. Одоо логууд тусгаарлагдсан байна. Тэд савнууд дээр тараагдсан байдаг. Даалгавруудын нэг нь вэб интерфэйсээр дамжуулан бүртгэлд хялбар нэвтрэх боломжийг олгох явдал юм.
Эх сурвалж: www.habr.com