Ако сте новак в DevOps, погледнете това ръководство за създаване на вашия първи конвейер от пет стъпки.
DevOps се е наложил като стандартно решение за подобряване на бавни, разединени или неработещи процеси в разработката на софтуер. Проблемът е, че ако сте новак в DevOps и не знаете откъде да започнете, може да нямате разбиране за тези методи. В тази статия ще говорим за дефиницията на DevOps конвейера, както и ще предложим ръководство за създаването му в пет стъпки. Въпреки че това ръководство не е изчерпателно, то трябва да ви предостави основа, за да започнете вашето пътуване и да разширите знанията си в бъдеще. Но нека започнем с историята.
Моето пътуване в DevOps
Преди това работих в облачния екип на Citi Group, разработвайки уеб приложение Infrastructure-as-a-Service (IaaS) за управление на облачната инфраструктура на Citi, но винаги съм се интересувал как да направя процеса на развитие по-ефективен и да внеса положителни културни промени в екипа от разработчици. Отговорът намерих в книга, препоръчана от Грег Лавендер (Greg Lavender), техническия директор на Citi по облачна архитектура и инфраструктура. Книгата се казваше „Проектът Феникс“ (), и в нея се обясняват принципите на DevOps, като се чете като роман.
В таблицата на обратната страна на книгата е показано колко често различни компании разгръщат своите системи в среда за пускане на версии:
Amazon: 23 000 на ден
Google: 5 500 на ден
Netflix: 500 на ден
Facebook: Веднъж на ден
Twitter: 3 пъти седмично
Типична компания: Веднъж на 9 месеца
Как е възможно Amazon, Google и Netflix да имат толкова високи честоти? Всичко това е, защото тези компании са измислили как да създадат практически идеален DevOps конвейер.
Бяхме далеч от това, докато не внедрихме DevOps в Citi. Тогава в екипа ми имаше различни среди, но разгръщането на сървъра за разработка беше напълно ръчно. Всички разработчици имаха достъп само до един сървър за разработка, базиран на IBM WebSphere Application Server Community Edition. Проблемът беше, че сървърът се изключваше всеки път, когато няколко потребители се опитваха да извършат разгръщане едновременно, така че разработчиците трябваше да си съобщават намеренията, което беше доста болезнено. Освен това имаше проблеми с ниското покритие на тестовете на кода, обемистите процеси на ръчно разгръщане и липсата на възможност за проследяване на разгръщането на кода, свързано с определена задача или потребителска история.
Разбрах, че трябва да направя нещо, и намерих колега-единомишленик. Решихме да работим заедно по създаването на първоначален DevOps конвейер – той инсталира виртуална машина и сървър за приложения Tomcat, докато аз работех по Jenkins, интегрирах Atlassian Jira и BitBucket, а също така работех върху покритието на тестовете на кода. Този страничен проект беше много успешен: почти напълно автоматизирахме много от процесите, постигнахме почти 100% работоспособност на нашия сървър за разработка, осигурихме проследяване и подобрихме покритие на тестовете на кода, а също така добавихме възможността да свързваме клонове в Git с задачи в Jira или разгръщане. Повечето инструменти, които използвахме за изграждане на нашия DevOps конвейер, бяха с отворен код.
Сега разбирам колко прост беше нашият DevOps пайплайн: не използвахме разширения като Jenkins files или Ansible. Въпреки това, този прост конвейер работеше добре, вероятно благодарение на принципа на Парето (известен още като правило 80/20).
Кратко въведение в DevOps и пайплайн CI/CD
Ако питате няколко души: „Какво е DevOps?“, вероятно ще получите няколко различни отговора. DevOps, подобно на Agile, се е развивал, за да обхване множество различни дисциплини, но повечето хора ще се съгласят с някои основни неща: DevOps е практика за разработка на софтуер или жизнен цикъл на разработка на софтуер (SDLC), централният принцип на която е промяната на културата, в която разработчиците и недевелоперите съществуват в среда, в която:
Операциите, които преди се извършваха ръчно, са автоматизирани;
Всеки прави това, което умее най-добре;
Броят на внедренията за определен период от време се увеличава; Пропускната способност се увеличава;
Гъвкавостта на разработката се повишава.
Въпреки че наличието на правилните софтуерни инструменти не е единственото, необходимо за създаване на DevOps среда, някои инструменти са задължителни. Ключов инструмент е непрекъснатата интеграция и непрекъснатото разгръщане (CI/CD). В този конвейер средите имат различни стадии (например, DEV, INT, TST, QA, UAT, STG, PROD), много операции са автоматизирани и разработчиците могат да пишат висококачествен код, да постигат гъвкавост в разработката и висока честота на разгръщания.
В тази статия се описва петстепенен подход за изграждане на DevOps конвейер, подобен на показания на следващата диаграма, с използване на инструменти с отворен код.
Стъпка 1: Методите CI/CD
Първото нещо, от което се нуждаете, е инструмент за CI/CD. Jenkins, инструмент с отворен код, базиран на Java и разпространяван под лиценз MIT, е средството, което популяризира DevOps и стана стандарт де факто.
И така, какво е Jenkins? Помислете за него като за магически универсален дистанционен контрол, който може да комуникира с различни услуги и инструменти и да ги организира. Сам по себе си инструментът CI/CD, такъв като Jenkins, е безполезен, но става по-мощен, когато се свързва с различни инструменти и услуги.
Jenkins е само един от многото инструменти с отворен код за CI/CD, които можете да използвате за изграждане на DevOps пайплайн.
Jenkins: Creative Commons и MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU
Ето как изглеждат DevOps процесите с инструмента CI/CD:
Имате инструмент CI/CD, работещ на вашия localhost, но в момента не можете да направите много. Нека преминем към следващия етап от пътуването в света на DevOps.
Стъпка 2: Управление на системите за контрол на изходния код
Най-добрият (и вероятно най-лесният) начин да проверите дали вашият CI/CD инструмент може да направи магия, е да интегрирате инструмента за контрол на изходния код (SCM). Защо ви е нужен контрол над изходния код? Да предположим, че разработвате приложение. Всеки път, когато изграждате приложение, вие програмирате, независимо дали използвате Java, Python, C++, Go, Ruby, JavaScript или някой от многото други програмни езици. Кода, който пишете, се нарича изходен код. В началото, особено когато работите сами, вероятно е възможно да поставите всичко в локална директория. Но когато проектът стане по-голям и поканите други хора да участват, ви е нужен начин да предотвратите конфликти при ефективен обмен на модификации. Също така ви е необходим начин за възстановяване на предишни версии, защото създаването на резервни копия и копирането/поставянето в тях вече е остаряло. Нуждаете се (и вашите колеги) от нещо по-добро.
Тук инструментът за контрол на изходния код става практически необходимост. Този инструмент съхранява вашия код в репозитории, проследява версиите и координира работата на участниците в проекта.
Макар че има много инструменти за контрол на изходния код, Git е стандартът и това е вярно. Настоятелно препоръчвам да използвате Git, въпреки че, ако искате, има и други опции с отворен код.
Git: GPLv2 и LGPL v2.1
Subversion: Apache 2.0
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+
Така изглежда DevOps пайплайн с добавяне на инструменти за контрол на изходния код.
CI/CD инструментът може да автоматизира процесите по проверка, получаване на изходен код и сътрудничество между членовете. Не звучи зле? Но как да направим от това работещо приложение, от което милиарди хора да могат да се възползват и оценят?
Стъпка 3: Създаване на инструмент за автоматизация на сборката
Отлично! Можете да проверявате кода и да извършвате промени в системата за контрол на версиите, а също така да каните приятелите си да се присъединят към разработката. Но все още не сте създали приложение. За да създадете уеб приложение, то трябва да бъде компилирано и опаковано в разпространяем пакетен формат или да бъде стартирано като изпълним файл. (Обърнете внимание, че интерпретируемият език за програмиране, като JavaScript или PHP, не се нуждае от компилация).
Използвайте инструмента за автоматизация на сборката. Независимо от инструмента за автоматизация на сборката, който решите да използвате, всички те имат една и съща цел: да съберат изходния код в желан формат и да автоматизират задачите по почистване, компилиране, тестване и разполагане в определена среда. Инструментите за сборка ще се различават в зависимост от вашия език за програмиране, но ето някои общи варианти с отворен код.
Име
Лиценз
Език за програмиране
Maven
Apache 2.0
Java
Ant
Apache 2.0
Java
Gradle
Apache 2.0
Java
Bazel
Apache 2.0
Java
Make
GNU
N/A
Grunt
MIT
JavaScript
Gulp
MIT
JavaScript
Buildr
Apache
Ruby
Rake
MIT
Ruby
A-A-P
GNU
Python
SCons
MIT
Python
BitBake
GPLv2
Python
Cake
MIT
C#
ASDF
Expat (MIT)
LISP
Cabal
BSD
Страхотно! Можете да поставите файловете за конфигурация на инструмента за автоматизация на сборката в системата за управление на изходния код и да позволите на инструмента CI/CD да ги събере.
Всичко е наред, нали? Но къде да разположите приложението си?
Стъпка 4: Сървър за уеб приложения
Засега имате опакован файл, който може да бъде изпълним или инсталационен. За да бъде приложението действително полезно, то трябва да предоставя някаква услуга или интерфейс, но имате нужда от контейнер, за да го хоствате.
Сървърът за уеб приложения е именно такъв контейнер. Сървърът предоставя среда, в която може да бъде дефинирана логиката на разпространяемия пакет. Също така, той предоставя интерфейс и предлага уеб услуги, отваряйки сокети за външния свят. Необходим ви е HTTP сървър, както и някаква среда (например виртуална машина) за неговото инсталиране. А засега, нека предположим, че ще научите повече за това по-късно (въпреки че ще разкажа за контейнерите по-долу).
Съществуват няколко сървъра за уеб приложения с отворен код.
Tomcat
Име
Лиценз
Език за програмиране
Jetty
Apache 2.0
Java
WildFly
Apache 2.0
Java
GNU Lesser Public
GlassFish
Java
CDDL & GNU Less Public
3-Clause BSD
Java
Django
Gunicorn
Python
Торнадо
Apache 2.0
Python
Rails
MIT
Python
Python
MIT
Python
Javascript
MIT
Ruby
Node.js
MIT
Вашият DevOps пайплайн почти е готов за ползване. Добра работа!
Вашият DevOps пайплайн почти е готов за ползване. Добра работа!
Въпреки че може да спрете тук и да се заемете с интеграцията сами, качеството на кода е важен аспект за разработчика на приложения и трябва да бъде в центъра на вниманието.
Стъпка 5: Покритие на тестовете на кода
Имплементирането на тестове може да бъде още едно обременяващо изискване, но разработчиците трябва да улавят всички грешки в приложението на ранния етап и да подобряват качеството на кода, за да гарантират, че крайният потребител ще бъде доволен. За щастие, съществуват много инструменти с отворен код за тестване на кода ви и генериране на препоръки за подобряване на неговото качество. Дори по-добре, повечето инструменти CI/CD могат да се свързват с тези инструменти и да автоматизират процеса.
Тестването на кода се състои от две части: рамки за тестване на кода, които помагат за писане и изпълнение на тестове, а също и инструменти за генериране на предложения, които помагат за подобряване на качеството на кода.
Системи за тестване на код
Име
Лиценз
Език за програмиране
JUnit
Eclipse Public License
Java
EasyMock
Apache
Java
Mockito
MIT
Java
PowerMock
Apache 2.0
Java
Pytest
MIT
Python
Hypothesis
Mozilla
Python
Tox
MIT
Python
Системи за препоръки за подобряване на кода
Име
Лиценз
Език за програмиране
Cobertura
GNU
Java
CodeCover
Eclipse Public (EPL)
Java
Coverage.py
Apache 2.0
Python
Emma
Common Public License
Java
JaCoCo
Eclipse Public License
Java
Hypothesis
Mozilla
Python
Tox
MIT
Python
Jasmine
MIT
JavaScript
Karma
MIT
JavaScript
Mocha
MIT
JavaScript
Jest
MIT
JavaScript
Обърнете внимание, че повечето от инструментите и рамките, изброени по-горе, са написани за Java, Python и JavaScript, тъй като C++ и C# са собственически езици за програмиране (въпреки че GCC е с отворен код).
Сега, когато сте реализирали инструментите за покритие на кода с тестове, вашият DevOps пайплайн трябва да изглежда като диаграмата, показана в началото на това ръководство.
Допълнителни стъпки
Контейнери
Както вече казах, можете да хоствате своя сървър на виртуална машина или сървър, но контейнерите са популярно решение.
Какво са контейнерите? Краткото обяснение е, че виртуалната машина изисква огромно количество памет на операционната система, надхвърляща размера на приложението, докато контейнерът се нуждае само от няколко библиотеки и конфигурации, за да стартира приложението. Очевидно е, че виртуалната машина все още има важни приложения, но контейнерът е леко решение за хостинг на приложение, включително сървъри за приложения.
Въпреки че съществуват и други варианти на контейнери, най-популярни са Docker и Kubernetes.
Docker: Apache 2.0
Kubernetes: Apache 2.0
Средства за автоматизация на междинно ниво
Нашият DevOps pipeline е основно насочен към съвместното създаване и внедряване на приложения, но има много други неща, които могат да се правят с инструменти за DevOps. Една от тях е използването на инструменти за Инфраструктура като Код (IaC), които също са известни като средства за междинна автоматизация. Тези инструменти помагат за автоматизиране на инсталирането, управлението и други задачи за междинен софтуер. Например, инструмент за автоматизация може да извлече приложения като сървър за уеб приложения, база данни и инструмент за мониторинг, с правилните конфигурации и да ги внедри на приложен сървър.
Ето няколко инструмента за междинна автоматизация с отворен код:
Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache или GPL
Научете повече за това как да получите търсена професия от нулата или да напреднете по отношение на умения и заплата, като преминете платени онлайн курсове в SkillFactory:
- (12 месеца)
още курсове
- (12 седмици)
- (12 месеца)
- (9 месеца)
- (9 месеца)
Полезно
Източник: habr.com
