Примери за автоматизация на Devops на практика

Облачното инженерство е гъвкава дисциплина. Многото опции на DevOps инструмента и методи за интегриране обаче могат да бъдат объркващи. По-голямата сложност често означава повече трудности при автоматизирането на задачите. Програмите DevOps трябва да се развиват към подобряване на процесите. Подобренията в доставката на код ще доведат до по-голяма прозрачност в комуникацията на проекта, по-мъдро приемане на споделени ресурси и ще направят повече място за осигуряване на качеството.

В тази публикация ще разгледаме три примера за автоматизация на DevOps. Те използват Jira, Jenkins и Docker – но концепциите за работни потоци, задействани от събития, ще се преведат във всички инструменти, които използвате.

Изграждане на ресурси (и прозрачност) от работни билети

Прозрачността е ключова за отворената комуникация в екипите на DevOps. Представете си свят, в който всеки ръководител на проекти може да вижда и създава информация в удобен за бизнеса контекст. Отделянето на известно време за синхронизиране на тръбопроводите на Jenkins с JIRA, например, ще даде на PM представа в реално време за заданията за внедряване на EC2 и ще предотврати бурни бури от импулсни проверки на състоянието. Следващите стъпки ще популяризират Jira от 2D дигитална коркова дъска в интерфейс за контрол на мисията, давайки заповеди и вземайки разписки. Бихте могли да използвате подобен подход с вашите инструменти за управление на проекти и изграждане.

За да настроите автоматизацията, подгответе вашия проект Jira за търгуване на информация с Jenkins чрез webhook. Да приемем, че вашият проект е миграция на приложение и трябва многократно да предоставяте набор от AWS услуги за тестване. Вместо да качвате ръчно CloudFormation скриптове, добавете персонализирани полета в конзолата за конфигуриране на проблеми, които ще кажат на Дженкинс къде да намери тези скриптове и с какви параметри да ги снабди. След това създайте поле за състояние на компилация, което ще се контролира от актуализации от Jenkins. Проверете дали тези нови полета вече се показват във вашите билети. След това под менюто за разширена конфигурация създайте връзка с Jenkins, като включите неговия сървър във формата за конфигуриране на Webhooks. Изберете „Създаден“ и „Актуализиран“ като задействания за събития.

Сега е ред на Дженкинс. Ще го настроим да получава параметри за изграждане и да предава състояния на изграждане. Предполагаме, че тръбопроводите вече са изградени и просто трябва да ги накараме да работят с Jira webhook. За да направите това, инсталирайте следните добавки и ги конфигурирайте да се свързват с вашия акаунт в Jira, и по-конкретно, префикса на проекта за таблото за мигриране на приложения:

• Джира
• Стъпки на тръбопровода Jira
• Jira Trigger Plugin
• плъгин jira-ext

Те ще позволят на Дженкинс да слуша за подходящите актуализации от Jira, както и да изложи функционалност за комуникация със задействащия билет от компилацията.

Тъй като двете приложения вече са заключени едно в друго, актуализирайте своя конвейер, за да обработва полезния товар на Jira, и го предайте на компилацията. Напишете JQL филтър в конфигурацията на тръбопровода, така че да може да се задейства само от събития „Създаване“ и „Актуализиране“ на уеб кукичка. След това съпоставете местоположението на шаблона CloudFormation и другите параметри като персонализирани полета и се уверете, че ключът на тикета на Jira също е уловен като поле за път на атрибут на проблем. Шаблонът и параметърът CloudFormation вече са достъпни като променливи на околната среда, за да ръководят това изграждане. Също така стойността на ключа на билета е достъпна за новите функции, изложени от приставките на Jira, за изграждане на актуализации на състоянието и информация за влизане директно в билета, за да могат всички заинтересовани страни да ги видят.

Автоматизация като тази може да ви помогне да извършвате по-малко повтаряща се работа. Необходими са известни усилия, за да настроите и поддържате връзките между вашите инструменти. За да опростите досадните работни потоци и да намерите примерни проекти, не забравяйте да проверите „инструмента за автоматизация, управляван от събития“, който Puppet създава.

Оптимизирайте компилациите на Docker с динамични променливи

Docker, подобно на CloudFormation, е мощен инструмент за възстановяване на приложения и инфраструктура при поискване. Тук ще разширим силата на параметризирането в базирани на Docker компилации на тръбопроводи. В идеалния случай можете да транспортирате Docker контейнер във всякаква среда. На практика обаче ще има разлики. Може би имате различни крайни точки на база данни за разработка, тестване и производство. Ако интеграционните тестове на вашето приложение разчитат на постигане на правилната крайна точка за среда, ние можем да използваме специфични за изграждането параметри, за да поддържаме вашите Docker контейнери независими от средата.

Ето как можете да маршрутизирате параметри за изграждане на тестова среда:

pipeline {
    // ...
    agent {
        dockerfile {
            filename "my-dockerfile"
            label "my-docker-label"
            args "-v DB_URL= ${env.DB_URL}" // set to 'test_db.example.com'
        }
    }
    // ...
}

Да приемем, че предаваме контролиран набор от параметри от задействащото действие в Jenkins, както в предишния пример. Изпълняваме тестов конвейер, така че Дженкинс получи крайните точки на базата данни като DB_URL=test_db.example.com от задействащото действие. Можем да получим достъп до тази стойност в нашия Jenkinsfile от обекта env.

Сега трябва да насочим стойността DB_URL към изграждането на Docker. Започваме с деклариране на строителен агент. За да увеличите максимално използването на Docker програмата на вашия екип, изтеглете персонализиран Dockerfile, като декларирате вашия персонализиран Dockerfile като ваш агент. След това трябва да предадем променливата на средата като интерполиран низ към аргументите: args “-v DB_URL= ${env.DB_URL}”. Във вашия персонализиран Dockerfile съпоставете инструкцията DB_URL ARG към инструкция ENV. Сега този URL адрес ще бъде достъпен като променлива във вашите контейнерни тестови скриптове, без изобщо да се налага да променяте файла.

Разбира се, това са видовете обичайни облачни кабели, които Relay е създаден да поддържа. Всичко, което се случва често въз основа на събития, е добро съвпадение, поради което тестването е друга област, узряла за автоматизация.

Направете рутинно тестване във вашата контейнеризирана компилация

Тестването е неподлежащ на обсъждане стълб на всяка програма за разработка на софтуер, но може да се превърне в пречка за внедряването. Екипите на DevOps често смекчават задръстванията с не толкова изчерпателен режим на тестване. Например, комбинация от функционално и модулно тестване на актуализации на API може да е достатъчна за проверка на функционалността на CRUD с минимална приемлива интеграция към локално създаден източник на данни. Можете обаче да възпроизведете всички зависимости на API и да изпълните разширим набор от тестове в рамките на еднократно задание за съставяне на докер с малко допълнителни разходи.

За този пример нека си представим, че изграждате малко приложение Node, което чете и пише в MongoDB. Ще бъде лесно да представите стека във файл за съставяне на докер. Файловете за композиране на Docker са YAML скриптове, които казват на Docker какво да инжектира в компилация на Dockerfile. В този случай ще изградим изображение на Node.js в Dockerfile и ще декларираме две услуги в нашия docker-compose.yml: услугата API и екземпляр на MondoDB. Запазете този файл за съставяне на докери и Node.js Dockerfile, за да го вградите в поддиректория integration-test в репото на проекта.

Вече можете да извършите някои проверки за надеждност, като изпълните docker-compose срещу директорията integration-test, като изпълните действията на Postman срещу локалния API и проверите MongoDB на който и порт да сте го изложили. По-важното е, че сме само на няколко кратки файла от автоматичното тестване на пълната интегрирана компилация. Създайте index.js файл с вашите тестови скриптове. Насочете вашите API извиквания и операции с бази данни към имената, които сте дали на услугите си във файла за съставяне на докери и върнете резултатите в контейнера. И накрая, създайте шел скрипт за управление на докер контейнерите и извеждане на резултатите от теста. Сега можете автоматично да задействате тестовете в други CI/CD тръбопроводи, да ги контролирате версиите и да добавяте повече услуги или тестове, докато бизнес логиката се развива.

Бързо внедряване на работни потоци, управлявани от събития

Както можете да видите, вашите работни потоци са по-ефективни, когато изградите достатъчно режийни разходи, за да намалите поведението, предизвикано от събития. Видяхме как динамичното оркестриране на компилации на Docker от Jira може да започне разширяеми програми за тестване в Jenkins. Добър принцип за оптимизация, който трябва да разгледате сега, е итерацията. Някои от тези интеграции може да работят или да не работят за вашите нужди. Възможността да сменяте и пренасочвате услугите си, без да изключвате тръбопроводите, поддържа работните ви процеси на DevOps протичащи.

„Relay by Puppet“ се стреми да управлява това вместо вас чрез автоматизиране на модулни работни процеси, управлявани от събития. Ако една интеграция престане да отговаря на вашите нужди, можете да размените инструменти или да пренасочите работния процес и да автоматизирате вашата DevOps среда.