Долбоордун жаңы чыгарылышын өндүрүшкө киргизүү жайылтуу ылдамдыгы менен чечимдин ишенимдүүлүгүнүн ортосундагы кылдат балансты талап кылат. Slack тез итерацияларды, кыска кайтарым циклдерин жана колдонуучунун суроо-талаптарына ыкчам жооп берүүнү баалайт. Мындан тышкары, компания мүмкүн болушунча жемиштүү болууга умтулган жүздөгөн программисттерге ээ.
Котормосу бүгүн биз жарыялап жаткан материалдын авторлору мындай баалуулуктарды карманууга умтулуп, ошол эле учурда өсүп жаткан компания долбоорлорду жайылтуу системасын дайыма өркүндөтүп турушу керек дешет. Компания бул процесстердин долбоордун масштабына дал келүүсүн камсыз кылуу үчүн иш процесстеринин айкындуулугуна жана ишенимдүүлүгүнө инвестициялоосу керек. Бул жерде биз Slack'те иштелип чыккан иш процесстери жана компанияны бүгүнкү күндө иштеп жаткан долбоорду жайылтуу системасын колдонууга алып келген кээ бир чечимдер жөнүндө сүйлөшөбүз.
Бүгүнкү күндө долбоорду жайылтуу процесстери кантип иштейт
Slack'теги ар бир PR (тартуу өтүнүчү) кодду карап чыгууга тийиш жана бардык сыноолордон ийгиликтүү өтүшү керек. Бул шарттар аткарылгандан кийин гана программист өзүнүн кодун долбоордун башкы бутагына бириктире алат. Бирок, бул код Түндүк Америка убактысы боюнча иш сааттарында гана жайгаштырылат. Жыйынтыгында биздин кызматкерлер өз жумуш орундарында болгондуктан, күтүлбөгөн көйгөйлөрдү чечүүгө толук даярбыз.
Кун сайын пландуу 12ге жакын жу-муштарды аткарабыз. Ар бир жайгаштыруу учурунда, жайылтуу жетекчиси катары дайындалган программист жаңы түзүлүштү өндүрүшкө киргизүү үчүн жооптуу. Бул монтаждын өндүрүшкө бир калыпта киришин камсыз кылган көп баскычтуу процесс. Бул ыкманын аркасында биз каталарды бардык колдонуучуларыбызга таасир эте электе аныктай алабыз. Эгерде өтө көп каталар болсо, жыйынды жайылтуу артка кайтарылышы мүмкүн. Эгер белгилүү бир маселе чыгарылгандан кийин табылса, аны оңой эле оңдоого болот.
Долбоорлорду жайылтуу үчүн Slackте колдонулган Checkpoint системасынын интерфейси
Өндүрүшкө жаңы релизди жайылтуу процесси төрт кадамдан турат деп ойлосо болот.
▍1. Чыгаруу бутагын түзүү
Ар бир релиз жаңы релиз бутагы менен башталат, бул биздин Гит тарыхыбыздагы пункт. Бул релизге тегдерди дайындоого мүмкүндүк берет жана релизди өндүрүшкө чыгарууга даярдоо процессинде табылган мүчүлүштүктөрдү түз ободо оңдоого мүмкүнчүлүк берет.
▍2. Этаптуу чөйрөдө жайылтуу
Кийинки кадам - бул ассамблеяны стационардык серверлерге жайгаштыруу жана долбоордун жалпы иштеши үчүн автоматтык тестти жүргүзүү (түтүн сыноо). Сценарий чөйрөсү тышкы трафикти албаган өндүрүш чөйрөсү. Бул чөйрөдө биз кошумча кол менен тестирлөө жүргүзөбүз. Бул бизге өзгөртүлгөн долбоор туура иштегенине кошумча ишеним берет. Бул ишеним деңгээлин камсыз кылуу үчүн жалгыз автоматташтырылган тесттер жетишсиз.
▍3. Doodfood жана канарей чөйрөлөрүндө жайылтуу
Өндүрүшкө жайылтуу биздин ички Slack иш мейкиндиктерибизге кызмат кылган хосттордун топтому менен сунушталган сыноо чөйрөсүнөн башталат. Биз абдан активдүү Slack колдонуучуларыбыз болгондуктан, бул ыкманы колдонуу бизге жайылтуунун башында көптөгөн мүчүлүштүктөрдү табууга жардам берди. Системанын негизги функционалдуулугу бузулбаганына ынанганыбыздан кийин, жыйын канар чөйрөсүндө жайгаштырылат. Бул өндүрүш трафигинин болжол менен 2% түзгөн системаларды билдирет.
▍4. Акырындык менен өндүрүшкө чыгаруу
Эгерде жаңы чыгарылыштын мониторингинин көрсөткүчтөрү туруктуу болуп чыкса жана долбоорду канар чөйрөсүндө жайылткандан кийин биз эч кандай даттанууларды албасак, анда биз өндүрүш серверлерин акырындык менен жаңы релизге которууну улантабыз. Жайгаштыруу процесси төмөнкү этаптарга бөлүнөт: 10%, 25%, 50%, 75% жана 100%. Натыйжада, биз акырындык менен өндүрүш трафигин системанын жаңы релизине өткөрө алабыз. Ошол эле учурда кандайдыр бир аномалиялар аныкталса, жагдайды иликтөөгө үлгүрөбүз.
▍Эгер жайылтуу учурунда бир нерсе туура эмес болуп калсачы?
Кодго өзгөртүүлөрдү киргизүү ар дайым коркунучтуу. Бирок биз муну өндүрүшкө жаңы релизди киргизүү процессин башкарган, мониторинг көрсөткүчтөрүн көзөмөлдөгөн жана код чыгаруучу программисттердин ишин координациялаган жакшы үйрөтүлгөн “орнотуу лидерлеринин” болушунун аркасында жеңебиз.
Эгер чындап эле бир нерсе туура эмес болуп кетсе, биз көйгөйдү мүмкүн болушунча эрте аныктоого аракет кылабыз. Биз көйгөйдү иликтейбиз, каталарды жаратып жаткан PRды табабыз, аны артка жылдырып, кылдат талдап, жаңы түзүлүштү түзөбүз. Ырас, кээде долбоор өндүрүшкө кирмейинче маселе байкалбай калат. Мындай кырдаалда эң негизгиси кызматты калыбына келтирүү болуп саналат. Ошондуктан, биз көйгөйдү иликтөөнү баштоодон мурун, биз дароо мурунку жумушчу түзүлүшкө кайтып келебиз.
Жайгаштыруу системасынын курулуш блоктору
Келгиле, биздин долбоорду жайылтуу системасынын негизинде жаткан технологияларды карап көрөлү.
▍Ыкчам жайгаштыруу
Жогоруда сүрөттөлгөн иш процесси артка көз чаптырганда, бир аз айкын сезилиши мүмкүн. Бирок биздин жайгаштыруу системасы дароо эле ушундай болуп калган жок.
Компания бир топ кичине болгондо, биздин бардык тиркеме 10 Amazon EC2 инстанциясында иштей алмак. Мындай кырдаалда долбоорду жайылтуу бардык серверлерди тез синхрондоштуруу үчүн rsyncти колдонууну билдирген. Буга чейин жаңы код өндүрүштөн бир гана кадам алыс болчу, аны сахналаштыруу чөйрөсү көрсөткөн. Ассамблеялар ушундай шартта түзүлүп, сыноодон өтүп, анан түз өндүрүшкө өтүштү. Мындай системаны түшүнүү абдан оңой болгон, ал каалаган программистке өзү жазган кодду каалаган убакта жайгаштырууга мүмкүндүк берген.
Бирок биздин кардарлардын саны өскөн сайын долбоорду колдоо үчүн зарыл болгон инфраструктуранын масштабы өстү. Көп өтпөй, системанын тынымсыз өсүшүн эске алуу менен, серверлерге жаңы кодду түртүүгө негизделген жайылтуу моделибиз мындан ары өз ишин аткарбай калды. Тактап айтканда, ар бир жаңы серверди кошуу жайгаштырууну аяктоо үчүн талап кылынган убакытты көбөйтүүнү билдирет. Ал тургай, rsyncти параллелдүү колдонууга негизделген стратегиялар да белгилүү чектөөлөргө ээ.
Биз бул маселени толугу менен параллелдүү жайгаштыруу системасына өтүү менен чечтик, ал эски системадан башкача иштелип чыккан. Тактап айтканда, азыр биз синхрондоштуруу скриптинин жардамы менен серверлерге код жөнөткөн жокпуз. Эми ар бир сервер жаңы ассамблеяны Консул ачкычынын өзгөрүшүнө байкоо жүргүзүү аркылуу жасоо керек экенин билип, өз алдынча жүктөп алды. Серверлер кодду параллелдүү жүктөштү. Бул системанын тынымсыз өсүшү чөйрөсүндө да жайылтуунун жогорку ылдамдыгын сактоого мүмкүндүк берди.
1. Өндүрүш серверлери Консул ачкычын көзөмөлдөйт. 2. Негизги өзгөртүүлөр, бул серверлерге жаңы кодду жүктөй башташы керек экенин айтат. 3. Серверлер tarball файлдарын тиркеме коду менен жүктөп алышат
▍Атомдук жайгаштыруу
Бизге көп баскычтуу жайгаштыруу системасына жетүүгө жардам берген дагы бир чечим атомдук жайгаштыруу болду.
Атомдук жайгаштырууларды колдонуудан мурун, ар бир жайгаштыруу көп сандагы ката билдирүүлөрүнө алып келиши мүмкүн. Чындыгында, жаңы файлдарды өндүрүш серверлерине көчүрүү процесси атомдук болгон эмес. Бул функциялардын өзү жеткиликтүү болгонго чейин жаңы функцияларды чакырган код жеткиликтүү болгон кыска убакыттын терезесине алып келди. Мындай код чакырылганда, ал ички каталарды кайтарып берди. Бул ишке ашпай калган API сурамдарында жана бузулган веб-баракчаларда көрүнгөн.
Бул маселенин үстүндө иштеген топ аны “ысык” жана “муздак” каталогдор түшүнүгүн киргизүү менен чечти. Ысык каталогдогу код өндүрүш трафигин иштетүү үчүн жооптуу. Ал эми "муздак" каталогдордо код, система иштеп жатканда, колдонууга гана даярдалып жатат. Жайгаштыруу учурунда жаңы код колдонулбаган муздак каталогго көчүрүлөт. Андан кийин, серверде активдүү процесстер жок болгондо, заматта каталогду которуу ишке ашырылат.
1. Колдонмонун кодун “муздак” каталогго ачуу. 2. Системаны "ысык" болуп калган "муздак" каталогго которуу (атомдук операция)
Натыйжалар: ишенимдүүлүккө басым жасоо
2018-жылы долбоор абдан тез жайылтуу буюмдун туруктуулугуна зыян келтире баштаган ушунчалык масштабда өстү. Бизде абдан өнүккөн жайылтуу системасы бар болчу, ага биз көп убакыт жана күч жумшадык. Бизге керек болгон нерсе – кайра куруу жана жайылтуу процесстерибизди жакшыртуу. Биз бүткүл дүйнө жүзү боюнча үзгүлтүксүз байланышты уюштуруу жана маанилүү маселелерди чечүү үчүн колдонулуп келе жаткан бир топ чоң компанияга айландык. Ошондуктан ишенимдүүлүк биздин көңүлүбүздүн борборунда болду.
Биз жаңы Slack релиздерин жайылтуу процессин коопсузураак кылышыбыз керек болчу. Бул муктаждык бизди жайгаштыруу системабызды жакшыртууга алып келди. Негизи бул жакшыртылган системаны жогоруда талкууладык. Системанын тереңинде биз тез жана атомдук жайгаштыруу технологияларын колдонууну улантып жатабыз. Жайгаштыруу ыкмасы өзгөрдү. Биздин жаңы система акырындык менен жаңы кодду ар кандай деңгээлде, ар кандай чөйрөдө жайылтуу үчүн иштелип чыккан. Биз азыр мурункуга караганда өркүндөтүлгөн колдоо куралдарын жана системаны көзөмөлдөө куралдарын колдонобуз. Бул бизге каталарды акыркы колдонуучуга жетүү мүмкүнчүлүгүнө ээ боло электе кармап, оңдоо мүмкүнчүлүгүн берет.
Бирок биз муну менен токтоп калбайбыз. Биз бул системаны тынымсыз өркүндөтүп, бир кыйла өркүндөтүлгөн көмөкчү куралдарды жана жумушту автоматташтыруу куралдарын колдонуп жатабыз.
Урматтуу окурмандар! Сиз иштеген жерде жаңы долбоордун релиздерин жайылтуу процесси кандай иштейт?
Source: www.habr.com