Выснова новага рэлізу праекта ў прадакшн патрабуе ўважлівага захавання балансу паміж хуткасцю разгортвання і надзейнасцю рашэння. У кампаніі Slack шануюць хуткія ітэрацыі, кароткія цыклы зваротнай сувязі, аператыўную рэакцыю на звароты карыстачоў. Акрамя таго, у кампаніі ёсць сотні праграмістаў, якія імкнуцца да максімальна магчымай прадуктыўнасці.
Аўтары матэрыялу, пераклад якога мы сёння публікуем, кажуць, што кампанія, якая імкнецца прытрымлівацца падобных каштоўнасцяў і пры гэтым расце, павінна стала ўдасканальваць сваю сістэму разгортвання праектаў. Кампаніі трэба ўкладваць сілы ў празрыстасць і надзейнасць працоўных працэсаў, робячы гэта для таго каб гэтыя працэсы адпавядалі б маштабам праекту. Тут гаворка пойдзе аб працоўных працэсах, якія склаліся ў Slack, і аб некаторых рашэннях, якія прывялі кампанію да выкарыстання ў ёй існуючай сёння сістэмы разгортвання праектаў.
Як працэсы разгортвання праектаў працуюць сёння
Кожны PR (pull request) у Slack павінен быць абавязкова падвергнуты код-рэўю і павінен паспяхова прайсці ўсе тэсты. Толькі пасля таго, як будуць выкананы гэтыя ўмовы, праграміст можа выканаць зліццё свайго кода з галінкай master праекту. Аднак разгортванне такога кода выконваецца толькі ў працоўныя гадзіны па паўночнаамерыканскім часе. У выніку мы, за кошт таго, што нашыя супрацоўнікі знаходзяцца на працоўных месцах, цалкам гатовыя да вырашэння любых нечаканых праблем.
Кожны дзень мы выконваем каля 12 запланаваных разгортванняў. У працэсе кожнага разгортвання праграміст, прызначаны галоўным па разгортванні, адказвае за выснову новай зборкі ў прадакшн. Гэта шматкрокавы працэс, які забяспечвае плыўную выснову зборкі ў працоўны рэжым. Дзякуючы такому падыходу мы можам выяўляць памылкі да таго, як яны закрануць усіх нашых карыстальнікаў. Калі памылак апынецца занадта шмат - разгортванне зборкі можна адкаціць. Калі ж нейкая асобная праблема выяўлена пасля рэлізу, для яе лёгка можна выпусціць выпраўленне.
Інтэрфейс сістэмы Checkpoint, якой карыстаюцца ў Slack для разгортвання праектаў
Працэс разгортвання новага рэлізу ў прадакшне можна ўявіць якія складаюцца з чатырох крокаў.
▍1. Стварэнне галінкі рэлізу
Кожны рэліз пачынаецца з новай галінкі рэлізу, з моманту ў нашай Git-гісторыі. Гэта дазваляе прызначаць рэлізу тэгі і дае месца, у якое можна ўносіць аператыўныя выпраўленні для памылак, знойдзеных падчас падрыхтоўкі рэлізу да выпуску ў прадакшн.
▍2. Разгортванне ў прамежкавым асяроддзі
Наступны крок працы складаецца ў разгортванні зборкі на прамежкавых (staging) серверах і ў запуску аўтаматычнага тэсту на агульную працаздольнасць праекту (smoke test). Прамежкавае асяроддзе - гэта прадакшн-акружэнне, у якое не трапляе вонкавы трафік. У гэтым асяроддзі мы праводзім дадатковае ручное тэсціраванне. Гэта дае нам дадатковую ўпэўненасць у тым, што зменены праект працуе правільна. Адных толькі аўтаматызаваных тэстаў для здабыцця падобнай упэўненасці нядосыць.
▍3. Разгортванне ў dogfood- і canary-акружэннях
Разгортванне ў прадакшне пачынаецца з dogfood-акружэння, прадстаўленага наборам хастоў, якія абслугоўваюць нашы ўнутраныя працоўныя прасторы Slack. Бо мы – вельмі актыўныя карыстачы Slack, ужыванне такога падыходу дапамагло выявіць мноства памылак на ранніх стадыях разгортвання. Пасля таго, як мы пераканаліся ў тым, што базавы функцыянал сістэмы не парушаны, выконваецца разгортванне зборкі ў canary-акружэнні. Яно ўяўляе сабой сістэмы, на якія ідзе прыкладна 2% прадакшн-трафіку.
▍4. Паступовы вывад у прадакшн
Калі паказчыкі маніторынгу новага рэлізу аказваюцца стабільнымі, і калі пасля разгортвання праекту ў canary-акружэнні мы не атрымалі скаргаў, мы працягваем паступовы пераклад прадакшн-сервераў на новы рэліз. Працэс разгортвання разбіты на наступныя этапы: 10%, 25%, 50%, 75% і 100%. У выніку мы можам павольна перадаваць прадакшн-трафік новаму рэлізу сістэмы. Пры гэтым у нас ёсць час на даследаванне сітуацыі ў выпадку выяўлення нейкіх анамалій.
▍Як быць, калі падчас разгортвання нешта пайшло не так?
Унясенне мадыфікацый у код - гэта заўсёды рызыка. Але мы спраўляемся з гэтым дзякуючы наяўнасці ў нас добра падрыхтаваных «галоўных па разгортванні», якія кіруюць працэсам вываду новага рэлізу ў прадакшн, назіраюць за паказчыкамі маніторынгу і каардынуюць працу праграмістаў, якія выпускаюць код.
У тым выпадку, калі нешта і праўда пайшло не так, мы імкнемся выявіць праблему як мага раней. Мы даследуем праблему, знаходзім PR, які выклікае памылкі, адкочваем яго, старанна аналізуем і ствараем новую зборку. Праўда, часам праблема аказваецца незаўважанай да вываду праекта ў прадакшн. У падобнай сітуацыі самае важнае - гэта аднавіць працу сэрвісу. Таму мы, да пачатку даследавання праблемы, неадкладна адкочваемся да папярэдняй працоўнай зборкі.
Будаўнічыя блокі сістэмы разгортвання
Разгледзім тэхналогіі, якія ляжаць у аснове нашай сістэмы разгортвання праектаў.
▍Хуткія разгортванні
Вышэйапісаны працоўны працэс можа здацца, у рэтраспектыве, чымсьці цалкам відавочным. Але наша сістэма разгортвання стала такой далёка не адразу.
Калі кампанія была значна менш, усё наша дадатак магло працаваць на 10 Amazon EC2-інстансах. Разгортванне праекту ў такой сітуацыі азначала ўжыванне rsync для хуткай сінхранізацыі ўсіх сервераў. Раней новы код ад прадакшна аддзяляў усяго адзін крок, прадстаўлены прамежкавым асяроддзем. Зборкі ствараліся і правяраліся ў такім асяроддзі, а потым ішлі адразу ў прадакшн. Разабрацца ў такой сістэме было вельмі проста, яна дазваляла любому праграмісту ў любы час разгарнуць напісаны ім код.
Але па меры таго, як расла колькасць нашых кліентаў, раслі і маштабы інфраструктуры, неабходнай для забеспячэння працы праекту. Хутка, улічваючы пастаянны рост сістэмы, наша мадэль разгортвання, заснаваная на адпраўцы новага кода на серверы, перастала спраўляцца са сваёй задачай. У прыватнасці, даданне кожнага новага сервера азначала павелічэнне часу, неабходнага на выкананне разгортвання. Нават стратэгіі, заснаваныя на раўналежным ужыванні rsync, маюць вызначаныя абмежаванні.
У выніку мы вырашылі гэтую праблему, перайшоўшы на цалкам раўналежную сістэму разгортвання, уладкованую не так, як старая сістэма. У прыватнасці, зараз мы не адпраўлялі код на серверы, выкарыстоўваючы скрыпт сінхранізацыі. Цяпер кожны сервер самастойна загружаў новую зборку, даведваючыся аб тым, што гэта трэба зрабіць, дзякуючы назіранню за зменай ключа Consul. Серверы загружалі код раўналежна. Гэта дазволіла нам падтрымліваць высокую хуткасць разгортвання нават у становішчы сталага росту сістэмы.
1. Прадакшн-серверы назіраюць за ключом Consul. 2. Ключ мяняецца, гэта паведамляе серверам аб тым, што ім трэба пачаць загрузку новага кода. 3. Серверы загружаюць tarball-файлы з кодам прыкладання
▍Атамарныя разгортванні
Яшчэ адным рашэннем, якое дапамагло нам дайсці да шматузроўневай сістэмы разгортвання, стала атамарнае разгортванне.
Да выкарыстання атамарных разгортванняў кожнае разгортванне магло прывесці да з'яўлення вялікай колькасці паведамленняў аб памылках. Справа ў тым, што працэс капіявання новых файлаў на прадакшн-серверы не быў атамарным. Гэта прыводзіла да існавання кароткага часавага адрэзка, калі код, у якім выклікаліся новыя функцыі, апыняўся даступным да таго, як аказваліся даступнымі самі гэтыя функцыі. Калі такі код выклікаўся, гэта прыводзіла да вяртання ўнутраных памылак. Гэта выяўлялася ў няўдалых запытах да API і ў "паламаных" вэб-старонках.
Каманда, якая займалася гэтай праблемай, вырашыла яе, увёўшы паняцце "гарачых" (hot) і "халодных" (cold) дырэкторый. Код у "гарачай" дырэкторыі адказвае за апрацоўку прадакшн-трафіку. А ў халодных дырэкторыях код, падчас працы сістэмы, толькі рыхтуецца да выкарыстання. Падчас разгортвання новы код капіюецца ў невыкарыстоўваемую "лядоўню" дырэкторыю. Затым, калі на серверы не будзе актыўных працэсаў, робіцца імгненнае пераключэнне дырэкторый.
1. Распакоўка кода прыкладання ў "халодную" дырэкторыю. 2. Пераключэнне сістэмы на "халодную" дырэкторыю, якая становіцца "гарачай" (атамарная аперацыя)
Вынікі: зрух акцэнту на надзейнасць
У 2018 годзе праект дарос да такіх маштабаў, калі вельмі хуткае разгортванне стала шкодзіць стабільнасці прадукта. У нас была вельмі прасунутая сістэма разгортвання, у якую мы ўклалі шмат сіл і часу. Нам трэба было толькі перабудаваць і ўдасканаліць працэсы арганізацыі разгортвання. Мы ператварыліся ў дастаткова буйную кампанію, распрацоўкі якой выкарыстоўваліся ва ўсім свеце для арганізацыі бесперабойнай сувязі і для рашэння важных задач. Таму ў цэнтры нашай увагі аказалася надзейнасць.
Нам трэба было зрабіць працэс разгортвання новых рэлізаў Slack больш бяспечным. Гэта неабходнасць і прывяла нас да ўдасканалення нашай сістэмы разгортвання. Уласна кажучы, вышэй мы і абмяркоўвалі гэтую вось удасканаленую сістэму. У нетрах сістэмы мы працягваем карыстацца тэхналогіямі хуткага і атамарнага разгортвання. Змянілася тое, як менавіта выконваецца разгортванне. Наша новая сістэма прызначана для паступовага выканання разгортвання новага кода на розных узроўнях, у розных асяроддзях. Цяпер мы выкарыстоўваем больш дасканалыя, чым раней, дапаможныя прылады і сродкі для маніторынгу сістэмы. Гэта дае нам магчымасць адлоўліваць і ўстараняць памылкі задоўга да таго, як яны атрымаюць шанец дабрацца да канчатковага карыстальніка.
Але мы не збіраемся спыняцца на дасягнутым. Мы ўвесь час паляпшаем гэтую сістэму, ужываючы больш дасканалыя дапаможныя прылады і сродкі аўтаматызацыі працы.
Паважаныя чытачы! Як уладкованы працэс разгортвання новых рэлізаў праектаў тамака, дзе працуеце вы?
Крыніца: habr.com