Якщо ви новачок у 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 and MIT
Travis CI: MIT
CruiseControl: 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
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+
Так виглядає DevOps-пайплайн із додаванням засобів контролю вихідного коду.
Інструмент CI/CD може автоматизувати процеси перевірки, отримання вихідного коду та співробітництва між членами. Не погано? Але як зробити з цього працюючий додаток, щоб мільярди людей могли його використати та оцінити?
Крок 3: Створення інструменту автоматизації збирання
Чудово! Ви можете перевіряти код та вносити зміни до системи контролю вихідного коду, а також запрошувати своїх друзів до співпраці у розробці. Але ви ще не створили програму. Щоб зробити веб-додаток, його потрібно скомпілювати і упаковати в пакетний формат, що розгортається, або запустити у вигляді виконуваного файлу. (Зверніть увагу, що мова програмування, що інтерпретується, такий як JavaScript або PHP, не потребує компіляції).
Скористайтеся інструментом автоматизації збирання. Незалежно від того, який інструмент автоматизації збірки ви вирішите використовувати, всі вони мають одну й ту саму мету: зібрати вихідний код в який-небудь бажаний формат і автоматизувати завдання з очищення, компіляції, тестування та розгортання у певному середовищі. Інструменти для складання будуть відрізнятися в залежності від вашої мови програмування, але деякі загальні варіанти з відкритим вихідним кодом.
Назва
Ліцензія
Мова програмування
Maven
Apache 2.0
Java
Мураха
Apache 2.0
Java
Градуй
Apache 2.0
Java
Базела
Apache 2.0
Java
зробити
GNU
N / A
хрюкати
MIT
JavaScript
Gulp
MIT
JavaScript
Будівельник
Apache
рубін
Граблі
MIT
рубін
AAP
GNU
Python
SCONS
MIT
Python
BitBake
GPLv2
Python
торт
MIT
C#
ASDF
Expat (MIT)
LISP
Cabal
BSD
Haskell
Здорово! Ви можете помістити файли конфігурації інструменту автоматизації складання в систему керування вихідним кодом і дозволити вашому інструменту CI/CD зібрати все докупи.
Все добре, чи не так? Але де розгорнути вашу програму?
Крок 4: Сервер для веб-застосунків
Поки що у вас є упакований файл, який може бути як виконуваним, так і встановлюваним. Для того, щоб будь-яка програма була дійсно корисною, вона повинна надавати якусь службу або інтерфейс, але вам потрібен контейнер для розміщення вашої програми.
Сервер для веб-додатків є саме таким контейнером. Сервер забезпечує середовище, в якому може бути визначена логіка пакета, що розгортається. Також сервер надає інтерфейс та пропонує веб-сервіси, відкриваючи сокети для зовнішнього світу. Вам потрібний HTTP-сервер, а також деяке середовище (наприклад, віртуальна машина) для встановлення. А поки що, давайте припустимо, що ви дізнаєтеся про це далі (хоча я розповім про контейнери нижче).
Існує кілька серверів для веб-застосунків з відкритим вихідним кодом.
Назва
Ліцензія
Мова програмування
Tomcat
Apache 2.0
Java
Jetty
Apache 2.0
Java
WildFly
GNU Lesser Public
Java
Скляна риба
CDDL & GNU Less Public
Java
Django
3-Clause BSD
Python
Торнадо
Apache 2.0
Python
Гунікорн
MIT
Python
Python
MIT
Python
Rails
MIT
рубін
Node.js
MIT
Javascript
Ваш DevOps-пайплайн майже готовий до використання. Хороша робота!
Хоча на цьому можна зупинитися та займатися інтеграцією самостійно, якість коду – важлива річ для розробника додатків, і про це потрібно турбуватися.
Крок 5: Покриття тестування коду
Реалізація тестів може бути ще однією громіздкою вимогою, але розробники повинні ловити будь-які помилки у додатку на ранній стадії та покращувати якість коду, щоб гарантувати, що кінцеві користувачі будуть задоволені. На щастя, існує безліч інструментів з відкритим вихідним кодом для тестування вашого коду та формування рекомендацій щодо покращення його якості. Ще краще те, що більшість інструментів CI/CD можуть підключатися до цих інструментів та автоматизувати процес.
Тестування коду складається з двох частин: фреймворки для тестування коду, які допомагають писати та запускати тести, а також інструменти для формування пропозицій, які допомагають покращити якість коду.
Системи тестування коду
Назва
Ліцензія
Мова програмування
Юніт
Eclipse Public License
Java
EasyMock
Apache
Java
Мокіто
MIT
Java
PowerMock
Apache 2.0
Java
Пітест
MIT
Python
Гіпотеза
Mozilla
Python
Токс
MIT
Python
Системи рекомендацій щодо покращення коду
Назва
Ліцензія
Мова програмування
Покриття
GNU
Java
CodeCover
Eclipse Public (EPL)
Java
Coverage.py
Apache 2.0
Python
Емма
Common Public License
Java
JaCoCo
Eclipse Public License
Java
Гіпотеза
Mozilla
Python
Токс
MIT
Python
жасмин
MIT
JavaScript
Карма
MIT
JavaScript
кава мокко
MIT
JavaScript
є
MIT
JavaScript
Зверніть увагу, що більшість інструментів і фреймворків, згаданих вище, написані для Java, Python і JavaScript, оскільки C++ та C# є пропрієтарними мовами програмування (хоча GCC має відкритий вихідний код).
Тепер, коли ви реалізували інструменти покриття коду тестами, ваш DevOps-пайплайн має бути схожим на діаграму, показану на початку цього посібника.
Додаткові кроки
контейнери
Як я вже казав, ви можете розміщувати свій сервер на віртуальній машині чи сервері, але контейнери є популярним рішенням.
Що таке контейнери? Коротке пояснення полягає в тому, що віртуальна машина потребує величезного обсягу пам'яті операційної системи, що перевищує розмір програми, тоді як контейнеру потрібно лише кілька бібліотек і конфігурацій для запуску програми. Очевидно, що у віртуальної машини все ще існують важливі сфери застосування, але контейнер - це легке рішення для хостингу програми, у тому числі сервера додатків.
Хоча існують інші варіанти контейнерів, найбільш популярними є Docker і Kubernetes.
Docker: Apache 2.0
Kubernetes: Apache 2.0
Проміжні засоби автоматизації
Наш DevOps-пайплайн в основному орієнтований на спільне створення та розгортання додатків, але є безліч інших речей, які можна зробити за допомогою DevOps-інструментів. Однією з них є використання інструментів Infrastructure as Code (IaC), які також відомі як засоби проміжної автоматизації. Ці інструменти допомагають автоматизувати інсталяцію, керування та інші завдання для проміжного програмного забезпечення. Так, наприклад, інструмент автоматизації може вилучати програми на зразок сервера веб-додатків, бази даних та інструменту моніторингу, з правильними конфігураціями та розгортати їх на сервері програм.
Ось кілька інструментів проміжної автоматизації з відкритим кодом:
Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache або GPL
Дізнайтеся подробиці, як отримати затребувану професію з нуля або Level Up за навичками та зарплатою, пройшовши платні онлайн-курси SkillFactory:
- (12 місяців)
ще курси
- (12 тижнів)
- (12 місяців)
- (9 місяців)
- (9 місяців)
Корисне
Джерело: habr.com