Стварэнне першага ланцужка DevOps за пяць крокаў для пачаткоўцаў.
DevOps стаў панацэяй для занадта павольных, раз'яднаных і іншых праблемных працэсаў распрацоўкі. Але патрэбныя мінімальныя спазнанні ў DevOps. Тут будзе разгледжаны такія паняцці, як ланцужок DevOps і як стварыць яе за пяць крокаў. Гэта не поўнае кіраўніцтва, а толькі "рыба", якую можна пашыраць. Пачнём з гісторыі.
Маё знаёмства з DevOps
Калісьці я працаваў з аблокамі ў Citi Group і распрацоўваў вэб-дадатак IaaS, каб кіраваць хмарнай інфраструктурай Citi, але мне заўсёды было цікава, як можна аптымізаваць ланцужок распрацоўкі і палепшыць культуру сярод распрацоўшчыкаў. Грег Лавендэр, наш тэхдырэктар па хмарнай архітэктуры і інфраструктуры, параіў мне кнігу . Яна выдатна тлумачыць прынцыпы DevOps, пры гэтым чытаецца як раман.
У табліцы на абарачэнні паказана, як часта кампаніі выкочваюць новыя версіі:
Як Amazon, Google і Netflix паспяваюць столькі выкочваць? А ўсё проста: яны зразумелі, як стварыць амаль ідэальны ланцужок DevOps.
У нас у Citi усё было зусім не так, пакуль мы не перайшлі на DevOps. Тады ў маёй каманды былі розныя асяроддзі, але пастаўку на сервер распрацоўкі мы рабілі ўручную. Ва ўсіх распрацоўшчыкаў быў доступ толькі да аднаго сервера распрацоўкі на базе IBM WebSphere Application Server Community Edition. Пры адначасовай спробе пастаўкі сервер "падаў", а нам даводзілася кожны раз "хваравіта" дамаўляцца паміж сабой. А яшчэ ў нас было недастатковае пакрыццё кода тэстамі, працаёмкі ручны працэс пастаўкі і ніякай магчымасці адсочваць пастаўку кода з дапамогай па некаторай задачы ці патрабаванню кліента.
Было зразумела, што трэба тэрмінова нешта рабіць, і я знайшоў калегу-аднадумцу. Мы вырашылі разам стварыць першы ланцужок DevOps - ён наладзіў віртуальную машыну і сервер прыкладанняў Tomcat, а я заняўся Jenkins, інтэграцыяй з Atlassian Jira і BitBucket, а таксама і пакрыццём кода тэстамі. Праект быў паспяховым: мы цалкам аўтаматызавалі ланцужок распрацоўкі, дамагліся амаль 100% бесперабойнай працы сервера распрацоўкі, маглі адсочваць і паляпшаць пакрыццё кода тэстамі, а галінку Git можна было прывязаць да пастаўкі і задачы Jira. І амаль усе прылады, якімі мы будавалі ланцужок DevOps, былі адчыненым зыходным кодам.
Па факце, ланцужок быў спрошчаным, бо мы нават не ўжывалі пашыраныя канфігурацыі з дапамогай Jenkins ці Ansible. Але ў нас усё атрымалася. Магчыма, гэтае следства прынцыпу (ён жа правіла 80/20).
Кароткае апісанне ланцужка DevOps і CI/CD
У DevOps ёсць розныя азначэнні. DevOps, як і Agile, уключае ў сябе розныя дысцыпліны. Але большасць пагодзяцца з наступным вызначэннем: DevOps - гэта метад, або жыццёвы цыкл, распрацоўкі ПЗ, галоўны прынцып якога - стварэнне культуры, дзе распрацоўшчыкі і іншыя супрацоўнікі "на адной хвалі", ручная праца аўтаматызаваны, кожны займаюцца тым, што лепш за ўсё ўмее, узрастае частата паставак, павялічваецца прадуктыўнасць працы, павялічваецца гнуткасць.
І хоць адных толькі прылад нядосыць для стварэння асяроддзя DevOps, без іх не абыйсціся. Найважнейшым з іх з'яўляецца бесперапынная інтэграцыя і бесперапынная пастаўка (CI/CD). У ланцужку для кожнага асяроддзя ёсць розныя этапы (напрыклад, DEV (распрацоўка), INT (інтэграцыя), TST (тэставанне), QA (кантроль якасці), UAT (прымачнае тэсціраванне карыстальнікамі), STG (падрыхтоўка), PROD (выкарыстанне)), ручныя задачы аўтаматызаваны, распрацоўшчыкі могуць рабіць якасны код, робяць яго пастаўку і могуць лёгка перабудоўвацца.
Дадзеная нататка апісвае, як за пяць крокаў стварыць ланцужок DevOps, як паказана на малюнку ніжэй, з дапамогай прылад з адчыненым зыходным кодам.
Пяройдзем да справы.
Крок 1: Платформа CI/CD
Перш за ўсё вам патрэбен прылада CI/CD. Jenkins – гэта адчыненая прылада CI/CD напісаны на Java з ліцэнзіяй MIT, з якога пачалася папулярызацыя руху DevOps і які дэ-факта стаў стандартам для CICD.
А што такое Jenkins? Прадстаўце, што ў вас ёсць чароўны пульт кіравання для самых розных сэрвісаў і прылад. Сама па сабе прылада CI/CD, тыпу Jenkins, бескарысны, але з рознымі прыладамі і сэрвісамі ён становіцца ўсемагутным.
Акрамя Jenkins ёсць мноства іншых адчыненых прылад, выбірайце любы.
Вось як выглядае працэс DevOps з прыладай CI/CD
У вас у localhost ёсць прылада CI/CD, але рабіць пакуль асоба няма чаго. Пяройдзем да наступнага кроку.
Крок 2: кіраванне версіямі
Лепшы (і, мабыць, самы просты) спосаб праверыць магію прылады CI/CD – інтэграваць яго з прыладай кантролю версій (source control management, SCM). Навошта патрэбен кантроль версій? Дапусцім вы робіце прыкладанне. Вы пішаце яго на Java, Python, C++, Go, Ruby, JavaScript ці на любой іншай мове, якіх вагон і маленькая каляска. Тое, што вы пішаце, завецца зыходным кодам. Спачатку, асабліва калі вы працуеце ў адзіночку, можна захоўваць усё ў лакальны каталог. Але калі праект разрастаецца і да яго далучаецца больш людзей, вам патрэбен спосаб дзяліцца зменамі ў кодзе, але пры гэтым пазбегнуць канфліктаў пры зліцці змен. А яшчэ вам трэба неяк аднаўляць папярэднія версіі без выкарыстання рэзервовых дзід і ўжыванні метаду copy-paste для файлаў з кодам.
І тут без SCM нікуды. SCM захоўвае код у рэпазітарах, кіруе яго версіямі і каардынуе яго сярод распрацоўшчыкаў.
Інструментаў SCM нямала, але стандартам дэ-факта заслужана стаў Git. Я раю выкарыстоўваць менавіта яго, але ёсць і іншыя варыянты.
Вось як выглядае пайплайн DevOps пасля дадання SCM.
Інструмент CI/CD можа аўтаматызаваць загрузку і выгрузку зыходнага кода і сумесную працу ў камандзе. Не дрэнна? Але як зараз з гэтага зрабіць працоўнае прыкладанне, каханае мільярдамі карыстачоў?
Крок 3: інструмент аўтаматызацыі зборкі
Усё ідзе як трэба. Вы можаце выгружаць код і фіксаваць змены ў сістэме кантролю версій, а таксама запрасіць сяброў папрацаваць з вамі. Але прыкладанні ў вас пакуль няма. Каб гэта было вэб-прыкладанне, яго трэба скампіляваць і змясціць у пакет для пастаўкі або запусціць як выкананы файл. (Інтэрпрэтаваная мова праграмавання, накшталт JavaScript ці PHP, кампіляваць не трэба.)
Ужывайце прыладу аўтаматызацыі зборкі. Які б інструмент вы ні выбралі, ён будзе збіраць код у патрэбным фармаце і аўтаматызаваць ачыстку, кампіляцыю, тэсціраванне і пастаўку. Прылады зборкі бываюць розныя ў залежнасці ад мовы, але звычайна выкарыстоўваюцца наступныя варыянты з адчыненым кодам.
Выдатна! Зараз уставім файлы канфігурацыі прылады аўтаматызацыі зборкі ў сістэму кантролю версій, каб прылада CI/CD іх сабраў.
Здаецца, усё нармальна. Але куды зараз усё гэта выкаціць?
Крок 4: сервер вэб-прыкладанняў
Такім чынам, у вас ёсць запакаваны файл, які можна выконваць або выкочваць. Каб прыкладанне сапраўды прыносіла карысць, у яго павінен быць нейкі сэрвіс або інтэрфейс, але вам трэба недзе гэта ўсё размясціць.
Вэб-дадатак можна размясціць на серверы вэб-прыкладанняў. Сервер прыкладанняў забяспечвае асяроддзе, дзе можна выканаць праграмную логіку з пакета, выканаць адмалёўку інтэрфейсу і адкрыць web-сэрвісы праз сокет. Вам патрэбен HTTP-сервер і некалькі іншых асяродкаў (віртуальная машына, напрыклад), каб усталяваць сервер прыкладанняў. Пакуль давайце ўявім, што вы разбіраецеся са ўсім гэтым падчас (хоць пра кантэйнеры я распавяду ніжэй).
Ёсць некалькі адкрытых сервераў вэб-прыкладанняў.
У нас ужо атрымаўся амаль працоўны ланцужок DevOps. Выдатная праца!
У прынцыпе, тут можна спыніцца, далей вы зладзіцеся самі, але варта яшчэ распавесці аб якасці кода.
Крок 5: Тэставое пакрыццё
Тэставанне адымае шмат часу і сіл, але лепш адразу знайсці памылкі і палепшыць код, каб парадаваць канчатковых карыстальнікаў. Для гэтай мэты ёсць шмат адчыненых прылад, якія не толькі пратэстуюць код, а яшчэ і параяць, як яго палепшыць. Большасць прылад CI/CD могуць падлучацца да гэтых прылад і аўтаматызаваць працэс.
Тэставанне падзелена на дзве часткі: фрэймворкі тэсціравання, каб пісаць і выконваць тэсты, і інструменты з падказкамі па павышэнні якасці кода.
Фрэймворкі тэсціравання
Інструменты з падказкамі па якасці
Большасць гэтых прылад і фрэймворкаў напісаны для Java, Python і JavaScript, таму што C++ і C# - прапрыетарныя (хоць у GCC адчынены зыходны код).
Інструменты тэставага пакрыцця мы прымянілі, і зараз пайплайн DevOps павінен выглядаць, як на малюнку ў пачатку кіраўніцтва.
Дадатковыя крокі
кантэйнеры
Як я ўжо казаў, сервер прыкладанняў можна размясціць на віртуальнай машыне ці серверы, але кантэйнеры больш папулярныя.
? Сцісла, у віртуальнай машыне аперацыйная сістэма часцей за ўсё займае больш месцы, чым прыкладанне, а кантэйнеру звычайна дастаткова некалькіх бібліятэк і канфігурацыі. У некаторых выпадках без віртуальных машын не абысціся, але кантэйнер месціць прыкладанне разам з серверам без лішніх выдаткаў.
Для кантэйнераў звычайна бяруць Docker і Kubernetes, хаця ёсць і іншыя варыянты.
Пачытайце артыкулы аб Docker і Kubernetes на :
Інструменты аўтаматызацыі прамежкавага ПЗ
Наш ланцужок DevOps арыентавана на сумесную зборку і пастаўку дадатку, але з інструментамі DevOps можна рабіць і іншыя цікавыя штукі. Напрыклад, выкарыстоўваць прылады "інфраструктура як код" (IaC), якія яшчэ завуцца прыладамі аўтаматызацыі прамежкавага ПА. Гэтыя прылады дапамагаюць аўтаматызаваць усталёўку, кіраванне і іншыя задачы для прамежкавага ПА. Напрыклад, прылада аўтаматызацыі можа браць прыкладанні (сервер вэб-прыкладанняў, базу дадзеных, прылады маніторынгу) з правільнымі канфігурацыямі і выкочваць іх на сервер прыкладанняў.
Вось некалькі варыянтаў адчыненых прылад аўтаматызацыі прамежкавага ПА:
Падрабязнасці ў артыкулах на :
І што зараз?
Гэта толькі вярхушка айсберга. Ланцужок DevOps можа значна больш. Пачніце з прылады CI/CD і даведайцеся, што яшчэ можна аўтаматызаваць, каб спрасціць сабе працу. Не забудзьцеся пра для эфектыўнай сумеснай працы.
Вось яшчэ некалькі добрых артыкулаў аб DevOps для пачаткоўцаў:
А яшчэ можна інтэграваць DevOps з адчыненымі прыладамі для agile:
Крыніца: habr.com