Мен сизге Inventos компаниясынан Александр Сигачевдун "Docker + Gitlab CI менен иштеп чыгуу жана тестирлөө процесси" баяндамасынын стенограммасын окууну сунуштайм.
Docker + Gitlab CI негизинде иштеп чыгуу жана тестирлөө процессин жаңыдан ишке ашыра баштагандар көбүнчө негизги суроолорду беришет. Эмнеден баштасам? Кантип уюштуруу керек? Кантип сыноо керек?
Бул отчет жакшы, анткени ал Docker жана Gitlab CI аркылуу иштеп чыгуу жана тестирлөө процесси жөнүндө структуралаштырылган түрдө айтылат. Отчеттун өзү 2017-жылга таандык. Бул баяндамадан сиз негиздерин, методологиясын, идеясын жана колдонуу тажрыйбасын ала аласыз деп ойлойм.
Кимге кызык, мышыктын астында сураныч.
Менин атым Александр Сигачев. Мен Inventos компаниясында иштейм. Мен сизге Dockerди колдонуу тажрыйбам жана аны компаниядагы долбоорлорго акырындык менен кантип ишке ашырып жаткандыгым жөнүндө айтып берем.
Докладдын темасы: Докер жана Gitlab CI аркылуу иштеп чыгуу процесси.
Бул менин Докер жөнүндө экинчи баяндамам. Биринчи отчеттун учурунда биз Докерди иштеп чыгуучу машиналарда Иштеп чыгууда гана колдондук. Докерди колдонгон кызматкерлердин саны болжол менен 2-3 адамды түзгөн. Акырындык менен тажрыйба топтолуп, бир аз алдыга жылдык. Биздин шилтеме .
Бул отчетто эмне болот? Кандай тырмоолорду чогултканыбыз, кандай көйгөйлөрдү чечкенибиз тууралуу тажрыйбабыз менен бөлүшөбүз. Бул бардык жерде сулуу эмес болчу, бирок ал бизге мындан ары да өтүүгө мүмкүндүк берди.
Биздин ураан: колубузга келгендин баарын докерлештирүү.
Биз кандай көйгөйлөрдү чечип жатабыз?
Компаниянын бир нече командасы болгондо, программист жалпы ресурс болуп саналат. Программист бир долбоордон сууруп чыгып, бир нече убакытка башка долбоорго берилген этаптар бар.
Программист тез түшүнүшү үчүн, ал долбоордун баштапкы кодун жүктөп алып, бул долбоордун көйгөйлөрүн чечүүдө андан ары алга илгерилетүүгө мүмкүндүк берүүчү чөйрөнү мүмкүн болушунча тезирээк ишке киргизиши керек.
Адатта, эгер сиз нөлдөн баштасаңыз, долбоордо аз документтер бар. Аны кантип орнотуу керектиги жөнүндө эски адамдар гана маалыматка ээ. Кызматкерлер жумуш ордун өз алдынча бир-эки күндүн ичинде түзүшөт. Муну тездетүү үчүн биз Dockerди колдондук.
Кийинки себеп - Иштеп чыгууда орнотууларды стандартташтыруу. Менин тажрыйбам боюнча, иштеп чыгуучулар дайыма демилгени колго алышат. Ар бир бешинчи учурда, колдонуучунун домени киргизилет, мисалы vasya.dev. Менин жанымда менин кошунам Петя отурат, анын домени petya.dev. Алар веб-сайтты же бул домендик аталышты колдонуу менен системанын бир бөлүгүн иштеп чыгышат.
Система чоңоюп, бул домендик аталыштар конфигурацияга кошула баштаганда, Өнүгүү чөйрөлөрүндө конфликт пайда болуп, сайттын жолу кайра жазылат.
Ошол эле нерсе базанын орнотуулары менен болот. Кээ бир адамдар коопсуздук менен убара болушпайт жана бош сырсөз менен иштешет. Орнотуу стадиясында MySQL кимдир бирөөдөн сырсөз сураган жана сырсөз 123 болуп чыкты. Көп учурда маалымат базасынын конфигурациясы иштеп чыгуучунун милдеттенмесине жараша тынымсыз өзгөрүп турган. Бирөө оңдоду, бирөө конфигурацияны оңдогон жок. Сыноо конфигурациясын киргизгенде айла-амалдар болду .gitignore жана ар бир иштеп чыгуучу маалымат базасын орнотуу керек болчу. Бул баштоо процессин кыйындаткан. Башка нерселердин арасында, сиз маалымат базасы жөнүндө эстен чыгарбоо керек. Маалымат базасы инициализацияланышы керек, сырсөз катталышы керек, колдонуучу катталышы керек, белги түзүлүшү керек ж.б.у.с.
Дагы бир көйгөй - китепканалардын ар кандай версиялары. Көп учурда иштеп чыгуучу ар кандай долбоорлордо иштейт. Мындан беш жыл мурун башталган Legacy долбоору бар (2017-жылдан баштап – редактордун эскертүүсү). Башында биз MySQL 5.5 менен баштадык. Биз MySQLдин заманбап версияларын ишке ашырууга аракет кылып жаткан заманбап долбоорлор да бар, мисалы 5.7 же андан жогору (2017-жылы - редактордун эскертүүсү)
MySQL менен иштеген ар бир адам бул китепканалар көз карандылыктарды алып жүрөрүн билет. 2 маалымат базасын чогуу иштетүү абдан көйгөйлүү. Жок дегенде эски кардарларды жаңы маалымат базасына туташтыруу көйгөйлүү. Бул өз кезегинде бир катар көйгөйлөрдү жаратат.
Кийинки көйгөй - иштеп чыгуучу локалдык машинада иштегенде, ал жергиликтүү ресурстарды, локалдык файлдарды, жергиликтүү оперативдүү эстутумду колдонот. Маселелерди чечүүнүн жолун иштеп чыгуу учурундагы бардык өз ара аракеттенүү ал бир машинада иштөөнүн алкагында ишке ашырылат. Мисалы, бизде 3-өндүрүштүн серверлери бар жана иштеп чыгуучу файлдарды түпкү каталогго сактайт жана ал жерден nginx сурамга жооп берүү үчүн файлдарды алат. Мындай код өндүрүшкө киргенде, файл 3 сервердин биринде бар экени белгилүү болот.
Учурда микросервис багыты өнүгүп жатат. Биз чоң тиркемелерибизди бири-бири менен өз ара аракеттенүүчү кээ бир кичинекей компоненттерге бөлгөндө. Бул белгилүү бир тапшырма стек үчүн технологияларды тандоого мүмкүндүк берет. Бул ошондой эле иштеп чыгуучулардын ортосунда ишти жана жоопкерчилик чөйрөсүн бөлүштүрүүгө мүмкүндүк берет.
JSде өнүгүп жаткан фронтондук иштеп чыгуучу бэкендге дээрлик эч кандай таасир этпейт. Backend иштеп чыгуучу, өз кезегинде, иштеп чыгат, биздин учурда, Ruby on Rails жана Frondend кийлигишпейт. Өз ара аракеттенүү API аркылуу ишке ашырылат.
Бонус катары, Dockerдин жардамы менен биз Staging боюнча ресурстарды кайра иштете алдык. Ар бир долбоор өзүнүн өзгөчөлүктөрүнөн улам белгилүү бир орнотууларды талап кылган. Физикалык жактан, виртуалдык серверди бөлүп, аларды өзүнчө конфигурациялоо же кандайдыр бир өзгөрмө чөйрөнү бөлүү жана китепканалардын версиясына жараша долбоорлор бири-бирине таасир этиши керек болчу.
Куралдар. Биз эмнени колдонобуз?
- Докер өзү. Dockerfile бир колдонмонун көз карандылыгын сүрөттөйт.
- Docker-compose бул биздин бир нече Docker тиркемелерибизди бириктирген таңгак.
- Булак кодун сактоо үчүн биз GitLab колдонобуз.
- Биз системаны интеграциялоо үчүн GitLab-CI колдонобуз.
Доклад эки бөлүктөн турат.
Биринчи бөлүк Докерди иштеп чыгуучулардын машиналарында кантип иштетүү керектигин айтып берет.
Экинчи бөлүктө GitLab менен кантип иштешүү керек, биз тесттерди кантип өткөрөбүз жана Stagingге кантип чыгабыз.
Docker - бул керектүү компоненттерди сүрөттөө үчүн (декларативдик ыкманы колдонуу менен) технология. Бул Dockerfile үлгүсү. Бул жерде биз Ruby:2.3.0 расмий Докер сүрөтүнөн мурастап жатканыбызды билдиребиз. Ал орнотулган Ruby 2.3 версиясын камтыйт. Биз керектүү жыйнак китепканаларын жана NodeJS орнотобуз. Биз каталогду түзүп жатканыбызды сүрөттөйбүз /app. Биз колдонмо каталогун жумушчу каталог катары дайындайбыз. Бул каталогго биз керектүү минималдуу Gemfile жана Gemfile.lock жайгаштырабыз. Андан кийин биз бул көз карандылыктын сүрөтүн орното турган долбоорлорду курабыз. Контейнер 3000 тышкы портун угууга даяр болорун көрсөтөбүз. Акыркы буйрук биздин тиркемени түздөн-түз ишке киргизген буйрук. Эгерде биз долбоорду ишке ашыруу буйругун аткарсак, тиркеме көрсөтүлгөн буйрукту иштетүүгө жана иштетүүгө аракет кылат.
Бул докер-түзүүчү файлдын минималдуу мисалы. Бул учурда биз эки контейнердин ортосунда байланыш бар экенин көрсөтөбүз. Бул түздөн-түз маалымат базасы кызматына жана веб кызматына кирет. Биздин веб-тиркемелер көбүнчө маалыматтарды сактоо үчүн сервер катары кандайдыр бир маалымат базасын талап кылат. Биз MySQLди колдонгондуктан, мисал MySQL менен - бирок башка маалымат базасын (PostgreSQL, Redis) колдонууга эч нерсе тоскоол болбойт.
Биз MySQL 5.7.14 сүрөтүн Docker хабынан расмий булактан өзгөртүүсүз алабыз. Учурдагы каталогдон биздин веб тиркеме үчүн жооптуу болгон сүрөттү чогултабыз. Биринчи учуруу учурунда ал биз үчүн сүрөт чогултат. Андан кийин бул жерде биз аткарып жаткан команданы иштетет. Артка кайрылсак, ишке киргизүү буйругу Puma аркылуу аныкталганын көрөбүз. Puma - Ruby тилинде жазылган кызмат. Экинчи учурда биз жокко чыгарабыз. Бул буйрук биздин муктаждыктарыбызга же милдеттерибизге жараша каалагандай болушу мүмкүн.
Биз ошондой эле биздин иштеп чыгуучунун хост машинабыздагы портту 3000ден 3000 контейнер портуна багытташыбыз керек экенин сүрөттөйбүз. Бул түздөн-түз Dockerге орнотулган iptables жана өзүнүн механизми аркылуу автоматтык түрдө аткарылат.
Иштеп чыгуучу, мурункудай эле, каалаган жеткиликтүү IP дарекке, мисалы, машинанын 127.0.0.1 жергиликтүү же тышкы IP дарегине кире алат.
Акыркы сапта веб-контейнер дб контейнеринен көз каранды экенин айтат. Биз веб-контейнерди ишке чакырганда, docker-compose биринчи биз үчүн маалымат базасын ишке киргизет. Азыртадан эле маалымат базасы башталганда (чындыгында, контейнер ишке киргизилгенден кийин! Бул базанын даярдыгына кепилдик бербейт) ал биздин тиркемени, биздин бэкэндди ишке киргизет.
Бул маалымат базасы иштебей калганда каталарды болтурбоого мүмкүндүк берет жана маалымат базасы контейнерин токтоткондо ресурстарды үнөмдөөгө мүмкүндүк берет, ошону менен башка долбоорлор үчүн ресурстарды бошотот.
Докерлештирүүнү долбоордо колдонуу бизге эмне берет? Биз бардык иштеп чыгуучулар үчүн MySQL версиясын жаздырабыз. Бул версиялар айырмаланганда, синтаксис, конфигурация жана демейки жөндөөлөр өзгөргөндө пайда болушу мүмкүн болгон кээ бир каталардан качууга мүмкүндүк берет. Бул маалымат базасы үчүн жалпы хост атын, логинди, паролду көрсөтүүгө мүмкүндүк берет. Биз мурун болгон конфигурация файлдарындагы аттар жана конфликттер зоопаркынан алыстап жатабыз.
Бизде Өнүгүү чөйрөсү үчүн оптималдуу конфигурацияны колдонуу мүмкүнчүлүгү бар, ал демейкиден айырмаланат. MySQL алсыз машиналар үчүн демейки боюнча конфигурацияланган жана кутудан тышкары анын иштеши өтө төмөн.
Docker сиз каалаган версиянын Python, Ruby, NodeJS, PHP котормочусун колдонууга мүмкүндүк берет. Биз кандайдыр бир версия менеджерин колдонуу зарылдыгынан арылабыз. Мурда Ruby үчүн rpm пакети колдонулган, ал долбоорго жараша версияны өзгөртүүгө мүмкүндүк берген. Docker контейнеринин аркасында бул сизге кодду оңой көчүрүүгө жана аны көз карандылыктар менен бирге версиялоого мүмкүндүк берет. Бизде котормочунун да, коддун да версиясын түшүнүүдө көйгөй жок. Версияны жаңыртуу үчүн эски контейнерди түшүрүп, жаңы контейнерди көтөрүш керек. Бир нерсе туура эмес болуп калса, жаңы контейнерди түшүрүп, эски контейнерди көтөрө алабыз.
Сүрөттү кургандан кийин, Өнүктүрүүдөгү жана Өндүрүштөгү контейнерлер бирдей болот. Бул өзгөчө ири орнотуулар үчүн чыныгы болуп саналат.
Frontendде биз JavaScipt жана NodeJS колдонобуз.
Азыр бизде ReacJS боюнча акыркы долбоор бар. Иштеп чыгуучу контейнердеги бардыгын ишке киргизди жана ысык кайра жүктөө аркылуу иштеп чыкты.
Андан кийин, JavaScipt чогултуу тапшырмасы ишке киргизилет жана статикалык чогултулган код ресурстарды үнөмдөө менен nginx аркылуу жөнөтүлөт.
Бул жерде мен биздин акыркы долбоордун диаграммасын бердим.
Кандай көйгөйлөрдү чечтиңиз? Бизде мобилдик түзмөктөр менен иштеше турган системаны куруу керек болчу. Алар маалыматтарды алышат. Мүмкүнчүлүктөрдүн бири бул түзмөккө push эскертмелерин жөнөтүү.
Бул үчүн биз эмне кылдык?
Биз тиркемени төмөнкү компоненттерге бөлдүк: JSдеги администратор бөлүк, Ruby on Rails астындагы REST интерфейси аркылуу иштеген сервер. Backend маалымат базасы менен өз ара аракеттенет. Алынган натыйжа кардарга берилет. Администратор панели REST интерфейси аркылуу сервер жана маалымат базасы менен иштешет.
Бизде Push эскертмелерин жөнөтүү керек болчу. Буга чейин бизде мобилдик платформаларга билдирүүлөрдү жеткирүү үчүн жооптуу болгон механизм ишке ашырылган долбоор бар болчу.
Биз төмөнкү схеманы иштеп чыктык: браузерден келген оператор администратор панели менен иштешет, администратор панели бэкэнд менен иштешет, тапшырма Push эскертмелерин жөнөтүү.
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 папкасын коштук, анда биз керектүү конфигурацияларды сактайбыз. Иштеп чыгуучу өзүнүн машинасында репозиторийдин гит клонун жасаганда, анын жергиликтүү өнүгүүгө даяр долбоору бар. Кайсы порт же кайсы орнотууларды колдонуу керектиги жөнүндө эч кандай суроо жок.
Кийинки бизде бир нече компоненттер бар: администратор, маалымат-API, push эскертмелери.
Мунун баарын ишке киргизүү үчүн биз dockerized-app деп аталган дагы бир репозиторий түздүк. Учурда биз ар бир компонент үчүн бир нече репозиторийлерди колдонобуз. Алар жөн гана логикалык жактан айырмаланат - GitLabда ал папкага окшош, бирок иштеп чыгуучунун машинасында ал белгилүү бир долбоор үчүн папкадай көрүнөт. Бир деңгээл төмөндө бириктириле турган компоненттери болуп саналат.
Бул dockerized-app мазмунунун мисалы. Ошондой эле бул жерде Docker каталогун жайгаштырабыз, анда биз бардык компоненттердин өз ара аракеттешүүсү үчүн керектүү конфигурацияларды толтурабыз. Долбоорду кантип ишке киргизүүнү кыскача сүрөттөгөн README.md бар.
Бул жерде биз эки докер-түзүүчү файлды колдондук. Бул этап-этабы менен ишке киргизүү үчүн жасалат. Иштеп чыгуучу ядро менен иштегенде, ага Push эскертмелери керек эмес, ал жөн гана docker-compose файлын ишке киргизет жана ошого жараша ресурстар сакталат.
Push эскертмелери менен интеграцияга муктаждык бар болсо, анда docker-compose.yaml жана docker-compose-push.yaml ишке киргизилет.
docker-compose.yaml жана docker-compose-push.yaml папкада болгондуктан, автоматтык түрдө бирдиктүү виртуалдык тармак түзүлөт.
Компоненттердин сүрөттөлүшү. Бул компоненттерди чогултуу үчүн жооптуу бир кыйла өркүндөтүлгөн файл. Бул жерде эмне таң калыштуу? Бул жерде биз баланстоочу компонентти киргизебиз.
Бул nginx иштеткен даяр Докер сүрөтү жана Docker розеткасын угуучу тиркеме. Динамикалык, контейнерлер күйгүзүлүп жана өчүрүлгөн сайын, nginx конфигурациясы калыбына келтирилет. Биз үчүнчү деңгээлдеги домендик аталыштарды колдонуу менен компоненттер менен иштөөнү бөлүштүрөбүз.
Өнүгүү чөйрөсү үчүн биз .dev доменин колдонобуз - api.informer.dev. .dev домени бар тиркемелер иштеп чыгуучунун жергиликтүү машинасында жеткиликтүү.
Андан кийин конфигурациялар ар бир долбоорго өткөрүлүп берилет жана бардык долбоорлор бир эле учурда чогуу ишке киргизилет.
Эгерде биз аны графикалык түрдө сүрөттөп көрсөк, кардар биздин браузер же биз баланстоочуга суроо-талаптарды жасай турган кандайдыр бир курал экени көрүнүп турат.
Баланстоочу домендик аталыштын негизинде кайсы контейнерге кирүү керек экендигин аныктайт.
Бул администратор панелине JS камсыз кылган nginx болушу мүмкүн. Муну API камсыз кылган nginx же сүрөттөрдү жүктөө түрүндө nginx тарабынан берилген статикалык файлдар жасаса болот.
Диаграмма контейнерлер виртуалдык тармакка туташып, проксидин артына катылганын көрсөтүп турат.
Иштеп чыгуучунун машинасында сиз IPди билип контейнерге кире аласыз, бирок биз муну колдонбойбуз. Түз байланыштын дээрлик кереги жок.
Колдонмумду докерлештирүү үчүн кандай мисалды карашым керек? Менин оюмча, жакшы мисал MySQL үчүн расмий докер сүрөтү болуп саналат.
Бул абдан татаал. Көптөгөн версиялары бар. Бирок анын функционалдуулугу андан ары өнүктүрүү процессинде пайда болушу мүмкүн болгон көптөгөн муктаждыктарды жабууга мүмкүндүк берет. Эгер сиз убакытты бөлүп, мунун баары кантип өз ара аракеттенишерин түшүнсөңүз, анда мен аны өзүңүз ишке ашырууда эч кандай көйгөй болбойт деп ойлойм.
Hub.docker.com адатта github.com сайтына шилтемелерди камтыйт, анда чийки маалыматтар түз берилет, андан сиз өзүңүз сүрөт түзө аласыз.
Андан ары бул репозиторийде docker-endpoint.sh скрипти бар, ал баштапкы инициализацияга жана тиркемени ишке киргизүүнү андан ары иштетүүгө жооп берет.
Ошондой эле бул мисалда чөйрө өзгөрмөлөрүнүн жардамы менен конфигурациялоо мүмкүнчүлүгү бар. Бир контейнерди иштеткенде же докер-түзүү аркылуу чөйрө өзгөрмөсүн аныктоо менен, биз MySQLде же каалаган нерсебизде root үчүн докер үчүн бош сырсөздү коюшубуз керек деп айта алабыз.
Кокус сырсөздү түзүү мүмкүнчүлүгү бар. Колдонуучу керек дейбиз, колдонуучуга сырсөз коюшубуз керек, маалымат базасын түзүшүбүз керек.
Долбоорлорубузда биз инициализацияга жооптуу болгон 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 файлын коюшубуз керек.
Бул жерде биз сыноо, жайылтуу сыяктуу мамлекеттердин ырааттуулугун аткаргыбыз келет деп сүрөттөйбүз.
Биз түздөн-түз биздин тиркеменин докер түзүүчү түзүмүн чакырган скрипттерди аткарабыз. Бул жөн гана backend мисалы.
Андан кийин биз маалымат базасын өзгөртүү жана тесттерди жүргүзүү үчүн миграцияны жүргүзүү керек деп айтабыз.
Эгерде скрипттер туура аткарылса жана ката кодун кайтарбаса, анда система жайылтуунун экинчи этабына өтөт.
Жайгаштыруу баскычы учурда сахналаштыруу үчүн ишке ашырылууда. Биз үзгүлтүксүз кайра иштетүүнү уюштурган жокпуз.
Биз бардык контейнерлерди күч менен өчүрөбүз, анан сыноо учурунда биринчи этапта чогултулган бардык контейнерлерди кайра көтөрөбүз.
Келгиле, учурдагы өзгөрмө чөйрө үчүн иштеп чыгуучулар тарабынан жазылган маалыматтар базасынын миграциясын иштетели.
Бул мастер бутагына гана колдонулушу керек деген эскертүү бар.
Башка бутактарды алмаштырганда иштебейт.
Бутактарды бойлото жайылтууларды уюштурууга болот.
Муну андан ары уюштуруу үчүн 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-проксиди өзүнчө ишке киргизүү скриптине көчүрдүк жана андагы бардык долбоорлордун торлорун жаздык.
Биздин долбоордо бир тор бар, ал эми балансизатордо долбоордун аталыштарына негизделген бир нече торлор бар. Ал домендик аталыштар боюнча прокси кыла алат.
Биздин суроо-талаптар 80-порттогу домен аркылуу келет жана бул доменди тейлеген контейнерлер тобуна чечилет.
Дагы кандай көйгөйлөр бар эле? Бул бардык контейнерлер демейки боюнча тамыр катары иштейт. Бул системанын тамыры бирдей эмес түпкү ээси.
Бирок, эгер сиз контейнерге кирсеңиз, ал тамыр болот жана биз бул контейнерде түзгөн файл тамыр укуктарын алат.
Эгерде иштеп чыгуучу контейнерге кирип, ал жерде файлдарды түзгөн буйруктарды жасаса, андан кийин контейнерден чыгып кетсе, анда анын жумушчу каталогунда анын кире албаган файлы бар.
бул кантип чечилет? Сиз контейнерде боло турган колдонуучуларды кошо аласыз.
Колдонуучуну кошкондо кандай көйгөйлөр пайда болду?
Колдонуучуну түзүүдө топ ID (UID) жана колдонуучу ID (GID) көп учурда дал келбейт.
Контейнерде бул көйгөйдү чечүү үчүн биз ID 1000 колдонуучуларды колдонобуз.
Биздин учурда, бул дээрлик бардык иштеп чыгуучулар Ubuntu OS колдоно тургандыгы менен дал келди. Ал эми Ubuntu OSде биринчи колдонуучу ID 1000ге ээ.
Бизде пландар барбы?
Docker документтерин кайра окуп чыгыңыз. Долбоор жигердүү өнүгүп жатат, документтер өзгөрүүдө. Эки-үч ай мурун алынган маалыматтар акырындап эскирип баратат.
Биз чечкен кээ бир көйгөйлөр стандарттуу каражаттар менен чечилген болушу мүмкүн.
Мен чындап эле оркестрге өткүм келет.
Бир мисал - кутудан чыккан Докердин Docker Swarm деп аталган орнотулган механизми. Мен Docker Swarm технологиясына негизделген өндүрүштө бир нерсени ишке киргизгим келет.
Урутканын контейнерлери журналдар менен иштөөнү ыңгайсыз кылат. Азыр журналдар изоляцияланган. Алар контейнерлерге чачылат. Милдеттердин бири - веб-интерфейс аркылуу журналдарга ыңгайлуу кирүү.
Source: www.habr.com