Створення першого ланцюжка 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