Създаване на първата 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 и който фактически стана стандарт за CI/CD.
Какво е Jenkins? Представете си, че имате магически контролер за различни услуги и инструменти. Сам по себе си, инструментът CI/CD, като Jenkins, е безполезен, но с различни инструменти и услуги става всемогъщ.
Освен Jenkins, има много други отворени инструменти, изберете който пожелаете.
Ето как изглежда процесът на DevOps с инструмент за CI/CD
Имате инструмент за 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: сървър за уеб приложения
Имате опакован файл, който може да се изпълнява или разпространява. За да е наистина полезно приложението, то трябва да има някаква услуга или интерфейс, но трябва да го сложите някъде.
Веб приложението може да бъде разположено на сървър за приложения. Сървърът на приложения осигурява среда, където може да се изпълни програмната логика от пакета, да се извърши рендеринг на интерфейса и да се отворят уеб услуги през сокет. Нужен ви е 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
