Ако не сте запознати с DevOps, разгледайте това ръководство за изграждане на първия ви конвейер от пет стъпки.
DevOps се превърна в стандартно решение за коригиране на бавни, прекъснати или повредени процеси на разработка на софтуер. Проблемът е, че ако сте нов в DevOps и не знаете откъде да започнете, тогава може да не разбирате тези техники. Тази статия ще се фокусира върху дефинирането на конвейер DevOps и също така ще предложи инструкции как да го създадете в пет стъпки. Въпреки че този урок не е изчерпателен, той трябва да ви даде основа, за да започнете и да разширите знанията си в бъдеще. Но да започнем с историята.
Моето DevOps пътуване
Преди това работих за облачния екип на Citi Group, разработвайки уеб приложение Infrastructure-as-a-Service (IaaS) за управление на облачната инфраструктура на Citi, но винаги съм се интересувал от това как да направя процеса на разработка по-ефективен и да донеса положителна културна промяна към екипа за разработка. Намерих отговора в книга, препоръчана от Грег Лавандър, технически директор на Citi за облачна архитектура и инфраструктура. Книгата се казва "Проектът Феникс" () и обяснява принципите на DevOps, докато се чете като роман.
Таблицата на гърба на книгата показва колко често различни компании внедряват своите системи в среда на освобождаване:
Amazon: 23 000 на ден
Google: 5 на ден
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 Pipeline
Ако попитате няколко души „Какво е 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 и се превърна в де факто стандарт.
И така, какво е Дженкинс? Мислете за него като за някакво магическо универсално дистанционно управление, което може да общува и организира различни услуги и инструменти. Сам по себе си CI/CD инструмент като Jenkins е безполезен, но става по-мощен, когато се свързва с различни инструменти и услуги.
Jenkins е само един от многото CI/CD инструменти с отворен код, които можете да използвате, за да изградите своя конвейер DevOps.
Дженкинс: Creative Commons и MIT
Травис CI: MIT
Круизконтрол: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU
Ето как изглеждат процесите на DevOps с CI/CD инструмент:
Имате CI/CD инструмент, работещ на вашия локален хост, но в момента не можете да направите много. Нека да преминем към следващата стъпка в нашето DevOps пътуване.
Стъпка 2: Управление на системи за контрол на изходния код
Най-добрият (и вероятно най-лесният) начин да тествате дали вашият CI/CD инструмент може да направи магия е да се интегрирате с инструмент за контрол на изходния код (SCM). Защо ви е необходим контрол на източника? Да приемем, че разработвате приложение. Всеки път, когато създавате приложение, вие програмирате, независимо дали използвате Java, Python, C++, Go, Ruby, JavaScript или някой от безброй езици за програмиране. Кодът, който пишете, се нарича изходен код. В началото, особено когато работите сами, вероятно е добре да поставите всичко в локална директория. Но тъй като проектът става по-голям и вие каните други хора да участват, имате нужда от начин да избягвате конфликти, като същевременно споделяте модификациите ефективно. Нуждаете се и от начин за възстановяване на предишни версии, защото създаването на резервни копия и копирането/поставянето в тях вече е остаряло. Вие (и вашите съотборници) се нуждаете от нещо по-добро.
Това е мястото, където контролът на изходния код става почти необходимост. Този инструмент съхранява вашия код в хранилища, следи версиите и координира работата на участниците в проекта.
Въпреки че има много инструменти за контрол на изходния код, Git е стандартът и с право. Силно препоръчвам да използвате Git, въпреки че има и други опции с отворен код, ако желаете.
Git: GPLv2 и LGPL v2.1
Subversion: Apache 2.0
Система за едновременни версии (CVS): GNU
Веста: LGPL
Mercurial: GNU GPL v2+
Ето как изглежда конвейерът DevOps с добавянето на контроли на изходния код.
CI/CD инструмент може да автоматизира процесите на проверка, придобиване на изходен код и сътрудничество между членовете. Не е зле? Но как да го превърнете в работещо приложение, така че милиарди хора да могат да го използват и оценят?
Стъпка 3: Създайте инструмент за автоматизация на изграждане
Страхотен! Можете да проверите кода и да направите промени в системата за контрол на изходния код, както и да поканите приятелите си да допринесат за разработката. Но все още не сте създали приложение. За да създадете уеб приложение, то трябва да бъде компилирано и пакетирано във формат за разгръщане на пакет или да се изпълнява като изпълним файл. (Имайте предвид, че интерпретиран език за програмиране като JavaScript или PHP не е необходимо да се компилира.)
Използвайте инструмент за автоматизация на изграждането. Независимо кой инструмент за автоматизация на изграждане изберете да използвате, всички те споделят една и съща цел: да изградят изходния код в някакъв желан формат и да автоматизират задачата за почистване, компилиране, тестване и внедряване в конкретна среда. Инструментите за изграждане ще варират в зависимост от езика ви за програмиране, но ето някои често срещани опции с отворен код.
Име
Разрешително
Програмен език
Maven
Apache 2.0
Ява
Мравка
Apache 2.0
Ява
Gradle
Apache 2.0
Ява
Bazel
Apache 2.0
Ява
правя
GNU
N / A
грухтене
MIT
JavaScript
Глътка
MIT
JavaScript
Строител
Apache
Рубин
гребло
MIT
Рубин
AAP
GNU
Питон
SCons
MIT
Питон
bitbake
GPLv2
Питон
торта
MIT
C#
ASDF
Експат (MIT)
LISP
пълен
BSD
Haskell
Страхотен! Можете да поставите конфигурационните файлове на инструмента за автоматизиране на изграждането в контрола на източника и да оставите вашия CI/CD инструмент да събере всичко заедно.
Всичко е наред, нали? Но къде да разположите вашето приложение?
Стъпка 4: Сървър за уеб приложения
Досега имате пакетиран файл, който може да бъде изпълним или инсталируем. За да бъде всяко приложение наистина полезно, то трябва да предоставя някакъв вид услуга или интерфейс, но имате нужда от контейнер, който да хоства вашето приложение.
Сървърът за уеб приложения е точно такъв контейнер. Сървърът осигурява среда, в която може да се дефинира логиката на пакета, който се разполага. Сървърът също така предоставя интерфейс и предлага уеб услуги чрез отваряне на сокети към външния свят. Имате нужда от HTTP сървър, както и някаква среда (като виртуална машина), за да го настроите. Засега нека приемем, че сте научили повече за това (въпреки че ще разгледам контейнерите по-долу).
Има няколко сървъра за уеб приложения с отворен код.
Име
Разрешително
Програмен език
Tomcat
Apache 2.0
Ява
кей
Apache 2.0
Ява
WildFly
GNU Lesser Public
Ява
Стъклена риба
CDDL & GNU По-малко публичен
Ява
Django
3-ClauseBSD
Питон
Торнадо
Apache 2.0
Питон
гунорог
MIT
Питон
Питон
MIT
Питон
Релси
MIT
Рубин
Node.js
MIT
Javascript
Вашият конвейер DevOps е почти готов за използване. Добра работа!
Въпреки че можете да спрете дотук и да направите интеграцията сами, качеството на кода е важно нещо, за което трябва да се тревожи разработчикът на приложение.
Стъпка 5: Покритие за тестване на код
Внедряването на тестове може да бъде друго тромаво изискване, но разработчиците трябва да уловят всички грешки в приложението рано и да подобрят качеството на кода, за да гарантират, че крайните потребители са доволни. За щастие има много налични инструменти с отворен код, за да тествате вашия код и да правите препоръки за подобряване на качеството му. Още по-добре, повечето CI/CD инструменти могат да се включат в тези инструменти и да автоматизират процеса.
Тестването на код се състои от две части: рамки за тестване на код, които ви помагат да пишете и изпълнявате тестове, и инструменти за предложения, които помагат за подобряване на качеството на кода.
Системи за тестване на код
Име
Разрешително
Програмен език
JUnit
Обществен лиценз за затъмнение
Ява
Лесна подигравка
Apache
Ява
Мокито
MIT
Ява
powermock
Apache 2.0
Ява
Питест
MIT
Питон
хипотеза
Mozilla
Питон
токс
MIT
Питон
Системи за препоръки за подобряване на кода
Име
Разрешително
Програмен език
Обхват
GNU
Ява
кодово покритие
Eclipse Public (EPL)
Ява
Coverage.py
Apache 2.0
Питон
Ема
Общ публичен лиценз
Ява
JaCoCo
Обществен лиценз за затъмнение
Ява
хипотеза
Mozilla
Питон
токс
MIT
Питон
жасмин
MIT
JavaScript
Карма
MIT
JavaScript
мока
MIT
JavaScript
има
MIT
JavaScript
Обърнете внимание, че повечето от споменатите по-горе инструменти и рамки са написани за Java, Python и JavaScript, тъй като C++ и C# са патентовани езици за програмиране (въпреки че GCC е с отворен код).
Сега, след като внедрихте инструменти за покритие на код, вашият конвейер DevOps трябва да изглежда подобно на диаграмата, показана в началото на този урок.
Допълнителни стъпки
Контейнери
Както казах преди, можете да хоствате вашия сървър във виртуална машина или сървър, но контейнерите са популярно решение.
Какво представляват контейнерите? Краткото обяснение е, че една виртуална машина се нуждае от огромно количество памет на операционната система, повече от размера на приложение, докато контейнерът се нуждае само от няколко библиотеки и конфигурации, за да стартира приложение. Очевидно все още има важни приложения за виртуална машина, но контейнерът е леко решение за хостване на приложение, включително сървър на приложения.
Докато съществуват други опции за контейнери, Docker и Kubernetes са най-популярните.
Докер: Apache 2.0
Kubernetes: Apache 2.0
Средства за междинна автоматизация
Нашата линия за DevOps е фокусирана основно върху съвместно създаване и внедряване на приложения, но има много други неща, които можете да правите с инструментите на DevOps. Едно от тях е използването на инструменти за инфраструктура като код (IaC), които също са известни като инструменти за автоматизация на междинен софтуер. Тези инструменти помагат за автоматизиране на инсталирането, управлението и други задачи за междинен софтуер. Така например инструмент за автоматизация може да извлече приложения като сървър за уеб приложения, база данни и инструмент за наблюдение с правилните конфигурации и да ги разположи на сървър за приложения.
Ето някои инструменти за автоматизация на мидълуер с отворен код:
Ansible: GNU Public
SaltStack: Apache 2.0
Главен готвач: Apache 2.0
Puppet: Apache или GPL
Разберете подробности за това как да получите търсена професия от нулата или Level Up по отношение на умения и заплата, като завършите платени онлайн курсове SkillFactory:
- (12 месеца)
повече курсове
- (12 седмици)
- (12 месеца)
- (9 месеца)
- (9 месеца)
полезен
Източник: www.habr.com