Почећемо наш блог са публикацијама заснованим на најновијим говорима нашег техничког директора (Дмитриј Стољаров). Сви су се одвијали 2016. године на разним стручним догађајима и били су посвећени теми ДевОпс и Доцкер. Већ имамо један видео са састанка Доцкер Москва у канцеларији Бадоо-а Онлине. Нове ће бити пропраћене чланцима који преносе суштину извештаја. Тако…
31. маја на конференцији , одржаног у оквиру фестивала „Руске интернет технологије” (РИТ++ 2016), секција „Континуирано увођење и имплементација” отворена је извештајем „Најбоље праксе континуиране испоруке са Доцкер-ом”. Сажео је и систематизовао најбоље праксе за изградњу процеса континуалне испоруке (ЦД) користећи Доцкер и друге производе отвореног кода. Са овим решењима радимо у производњи, што нам омогућава да се ослонимо на практично искуство.
Ако имате прилику да проведете сат времена , препоручујемо да га погледате у целости. Иначе, испод је главни резиме у текстуалном облику.
Континуирана испорука уз Доцкер
Под Континуирана достава разумемо ланац догађаја услед којих код апликације из Гит репозиторија прво долази у производњу, а затим завршава у архиви. Она изгледа овако: Гит → Буилд → Тест → Релеасе → Операте.
Већи део извештаја је посвећен фази израде (састављање апликације), а укратко се дотичу теме издавања и рада. Говорићемо о проблемима и обрасцима који вам омогућавају да их решите, а специфичне имплементације ових образаца могу бити различите.
Зашто је Доцкер уопште потребан овде? Није узалуд одлучили да разговарамо о праксама континуиране испоруке у контексту овог алата отвореног кода. Иако је цео извештај посвећен његовој употреби, многи разлози се откривају када се разматра главни образац увођења кода апликације.
Главни образац представљања
Дакле, када уведемо нове верзије апликације, сигурно смо суочени са проблем застоја, генерисан током пребацивања производног сервера. Саобраћај са старе верзије апликације на нову не може се одмах пребацити: прво морамо да се уверимо да је нова верзија не само успешно преузета, већ и „загрејана“ (тј. потпуно спремна за испуњавање захтева).
Тако ће неко време обе верзије апликације (стара и нова) радити истовремено. Што аутоматски доводи до сукоб заједничких ресурса: мрежа, систем датотека, ИПЦ, итд. Са Доцкер-ом, овај проблем се лако решава покретањем различитих верзија апликације у одвојеним контејнерима, за које је загарантована изолација ресурса у оквиру истог хоста (сервер/виртуелна машина). Наравно, можете проћи са неким триковима без изолације уопште, али ако постоји готов и згодан алат, онда постоји супротан разлог - да га не занемарите.
Контејнеризација пружа многе друге предности када се примени. Свака апликација зависи од специфична верзија (или опсег верзија) тумач, доступност модула/проширења итд., као и њихове верзије. И то се односи не само на непосредно извршно окружење, већ и на цело окружење, укључујући системски софтвер и његову верзију (до коришћене Линук дистрибуције). Због чињенице да контејнери садрже не само код апликације, већ и унапред инсталиран системски и апликативни софтвер потребних верзија, можете заборавити на проблеме са зависностима.
Хајде да генерализујемо главни образац увођења нове верзије узимајући у обзир следеће факторе:
- У почетку, стара верзија апликације ради у првом контејнеру.
- Нова верзија се затим разваљује и „загрева“ у другом контејнеру. Важно је напоменути да сама ова нова верзија може да носи не само ажурирани код апликације, већ и било коју од њених зависности, као и системске компоненте (на пример, нову верзију ОпенССЛ-а или целу дистрибуцију).
- Када је нова верзија потпуно спремна за испоруку захтева, саобраћај се пребацује са првог контејнера на други.
- Стара верзија се сада може зауставити.
Овај приступ постављања различитих верзија апликације у одвојене контејнере пружа још једну погодност - брзо враћање уназад на стару верзију (на крају крајева, довољно је пребацити саобраћај на жељени контејнер).
Последња прва препорука звучи као нешто чему чак ни капетан није могао да замери: „[када организујете континуирану испоруку са Доцкер-ом] Користите Доцкер [и разумети шта даје]" Запамтите, ово није сребрни метак који ће решити сваки проблем, већ алат који пружа дивну основу.
Репродуцибилност
Под „поновљивошћу“ подразумевамо генерализован скуп проблема са којима се сусрећу при раду са апликацијама. Говоримо о таквим случајевима:
- Скрипте које проверава одељење за квалитет за постављање морају бити тачно репродуковане у производњи.
- Апликације се објављују на серверима који могу да примају пакете са различитих огледала спремишта (током времена се ажурирају, а са њима и верзије инсталираних апликација).
- “Локално ми све функционише!” (...и програмерима није дозвољено да уђу у производњу.)
- Треба проверити нешто у старој (архивираној) верзији.
- ...
Њихова општа суштина се своди на то да је неопходна пуна усклађеност коришћених окружења (као и одсуство људског фактора). Како можемо гарантовати поновљивост? Направите Доцкер слике на основу кода из Гита, а затим их користити за било који задатак: на тест локацијама, у производњи, на локалним машинама програмера... Истовремено је важно минимизирати радње које се изводе после састављање слике: што је једноставније, мања је вероватноћа да постоје грешке.
Инфраструктура је код
Ако инфраструктурни захтеви (доступност серверског софтвера, његове верзије, итд.) нису формализовани и „програмирани“, онда увођење било које надоградње апликације може довести до катастрофалних последица. На пример, у стагингу сте већ прешли на ПХП 7.0 и сходно томе преписали код - онда ће његово појављивање у производњи са неким старим ПХП-ом (5.5) сигурно некога изненадити. Можда нећете заборавити на велику промену у верзији тумача, али „ђаво је у детаљима“: изненађење може бити у мањем ажурирању било које зависности.
Приступ решавању овог проблема је познат као ИаЦ (Инфраструктура као код, „инфраструктура као код“) и укључује складиштење захтева инфраструктуре заједно са кодом апликације. Користећи га, програмери и стручњаци за ДевОпс могу да раде са истим Гит репозиторијумом апликације, али на различитим његовим деловима. Из овог кода се у Гиту креира Доцкер слика у којој се апликација поставља узимајући у обзир све специфичности инфраструктуре. Једноставно речено, скрипте (правила) за склапање слика треба да буду у истом спремишту са изворним кодом и спојене заједно.
У случају архитектуре вишеслојне апликације – на пример, постоји нгинк, који стоји испред апликације која већ ради унутар Доцкер контејнера – Доцкер слике морају бити креиране из кода у Гиту за сваки слој. Тада ће прва слика садржати апликацију са интерпретатором и другим „блиским“ зависностима, а друга слика ће садржати узводни нгинк.
Доцкер слике, комуникација са Гитом
Све Доцкер слике прикупљене из Гит-а делимо у две категорије: привремене и пуштене. Привремене слике означене именом гране у Гиту, могу се заменити следећим урезивањем и пуштају се само за преглед (не за производњу). Ово је њихова кључна разлика од оних у издању: никад не знате који је конкретан урезивање у њима.
Има смисла сакупљати у привремене слике: главну грану (можете је аутоматски пренети на засебну локацију да бисте стално видели тренутну верзију мастер), гране са издањима, гране специфичних иновација.
Након што преглед привремених слика дође до потребе за преводом у продукцију, програмери стављају одређену ознаку. Аутоматски се прикупља по ознаци ослободи слику (његова ознака одговара ознаци из Гит-а) и преноси се на инсценацију. Ако га успешно верификује одељење за квалитет, иде у производњу.
дапп
Све што је описано (увођење, склапање слике, накнадно одржавање) може се имплементирати независно коришћењем Басх скрипти и других „импровизованих“ алата. Али ако то урадите, онда ће у неком тренутку имплементација довести до велике сложености и лоше контроле. Схватајући ово, дошли смо да креирамо сопствени специјализовани услужни програм Воркфлов за прављење ЦИ/ЦД-а - дапп.
Његов изворни код је написан у Руби-у, отвореног кода и објављен на . Нажалост, документација је тренутно најслабија тачка алата, али радимо на томе. И ми ћемо писати и причати о дапп-у више пута, јер... Искрено једва чекамо да поделимо његове могућности са целом заинтересованом заједницом, али у међувремену пошаљите своје проблеме и захтеве за повлачење и/или пратите развој пројекта на ГитХуб-у.
Ажурирано 13. августа 2019: тренутно пројекат дапп преименован у , његов код је потпуно преписан у Го, а његова документација је значајно побољшана.
Кубернетес
Још један готов алат отвореног кода који је већ добио значајно признање у професионалном окружењу је Кубернетес, Доцкер кластер за управљање. Тема његове употребе у раду пројеката изграђених на Доцкер-у је ван оквира извештаја, па је презентација ограничена на преглед неких занимљивих карактеристика.
За увођење, Кубернетес нуди:
- сонда спремности — провера спремности нове верзије апликације (за пребацивање саобраћаја на њу);
- роллинг упдате - секвенцијално ажурирање слике у групи контејнера (гашење, ажурирање, припрема за покретање, пребацивање саобраћаја);
- синхроно ажурирање - ажурирање слике у кластеру са другачијим приступом: прво на половини контејнера, затим на остатку;
- цанари релеасес - лансирање нове слике на ограниченом (малом) броју контејнера за праћење аномалија.
Пошто Континуирана испорука није само издавање нове верзије, Кубернетес има низ могућности за накнадно одржавање инфраструктуре: уграђено праћење и евидентирање за све контејнере, аутоматско скалирање, итд. Све ово већ ради и само чека да се исправно имплементацију у своје процесе.
Коначне препоруке
- Користите Доцкер.
- Креирајте Доцкер слике апликација за све ваше потребе.
- Придржавајте се принципа „Инфраструктура је код“.
- Повежите Гит са Доцкер-ом.
- Регулишите редослед увођења.
- Користите готову платформу (Кубернетес или неку другу).
Видео снимци и слајдови
Видео са наступа (око сат времена) (сами извештај почиње од 5. минута - пратите линк да играте од овог тренутка).
Презентација извештаја:
ПС
Остали извештаји о овој теми на нашем блогу:
- «» (Дмитриј Стољаров; 27. мај 2019. на ДевОпсЦонф-у);
- «» (Дмитриј Стољаров; 8. новембар 2018. на ХигхЛоад++);
- «» (Дмитриј Стољаров; 7. новембар 2017. на ХигхЛоад++);
- «» (Дмитриј Стољаров; 6. јун 2017. на РоотЦонф-у).
Извор: ввв.хабр.цом