Що таке деплой та для чого він потрібен

Що таке деплой

Deploy (деплой) — це процедура запуску вебсайту або програми на сервері, хостингу. Деплой дозволяє кінцевим користувачам отримати доступ до ресурсів через мережу.

Причому цією мережею може бути як інтернет, так і будь-яка локальна мережа. Все залежить від вебресурсу.

Можливо, ви стикалися з такими висловлюваннями щодо сайту, як «відправити в продакшн», «викотити», «відправити на прод» або «деплоїти». Ось це викочування сайту на хостинг і є deploy, а продакшн — готова версія сайту, з якою можуть працювати користувачі.

З англійської deploy перекладається як «розгортання».

З тим, як саме відбувається деплой, ми з вами розберемося нижче.

Для яких цілей його використовують

Без деплою програма або сайт будуть доступні лише на локальному пристрої розробника. Щоб користувачі мережі змогли взаємодіяти з вебпроєктом, його потрібно завантажити на сервер. 

Після написання та тестування готового продукту, його потрібно встановити, налаштувати та запустити на сервері, після чого ним зможе скористатися широке коло людей. Без деплою код просто лежатиме на локальному комп’ютері чи репозиторії.

Писати вебсайт відразу на сервері — не найкраще рішення. Як мінімум сервер може «впасти». До того ж це не дуже зручно, а робочим середовищем може виступати не тільки цей сервер, а й інші пристрої, що робить розгортання складним процесом.

Що саме деплоять

Деплоїти потрібно все, що працює через мережу. Сюди можна віднести вебпрограми, сайти та інші рішення. Причому, як йшлося вище, це можуть бути як послуги, що працюють у локальних мережах, так і проєкти в інтернеті. Тобто внутрішній корпоративний портал вашої компанії також колись деплоїли. І якщо він працює, то деплой пройшов успішно 🙂

Деплоїти можна не весь проєкт, а деякі його частини. Так відбувається, коли у великих продуктах різний функціонал чи над апгрейдами працюють кілька розробників. У такому разі кожну нову функцію можна деплоїти окремо від решти. Створення розподілених застосунків, які складаються з різних частин, виглядає як серія незалежних деплоїв.

Зовнішній вигляд життєвого циклу коду

Ненадовго зупинимося на тому, як відбувається розробка в ІТ-компаніях та яка роль програмного коду у життєвому циклі відведена деплою:

1. Написання коду. На цьому етапі розробник локального пристрою пише код для нового вебсайту або розширення вже існуючого.
2. Комміт. Потім код завантажується в репозиторій, наприклад GitHub, і доступ до нього отримують інші члени команди. Це називається «коммітити». Коментарі до коду можуть залишити інші розробники проєкту. Цей процес називається код-рев’ю.
3. Продакшн. Після завершення комміту ухвалюється рішення відправити код у продакшн.
4. Реліз. На цьому етапі публікується оголошення про майбутній деплой. Фінальна версія коду в репозиторії позначається певним тегом. Зміни, які будуть внесені до коду після релізу, не мають потрапити до продакшену.
5. Деплой. Код надсилають у продакшн, а користувачі отримують доступ до ресурсу на сервері.

Деплоймент покроково

Тепер розглянемо кожен етап деплою і чим він примітний.

1 Доставка коду на сервер

Код на сервер доставляють різними способами, залежно від того, як його упаковано. Іноді буває так, що код у вигляді набору файлів можна легко скопіювати на сервер. Але здебільшого його оновлюють через Git. Ще один застарілий, але в деяких випадках все ще актуальний спосіб — деплой через звичайні пакетні менеджери Linux. У наші дні зустрічається дуже рідко.

2 Оновлення бази даних

У файлах попередньої версії проєкту зазначаються зв’язки з новими шматками коду. Усі нові функції об’єднуються у структуру сервісу. Файли проєкту — загальна система, яка може функціонувати.

Крім цього, оновлена ​​версія сайту або програми зазвичай потребує змін у базі даних. Для цього запускаються скрипти міграції, які містять правила оновлення БД. Це потрібно робити до деплою чи під час нього.

3 Запуск та зупинка

У процесі деплою потрібно зупинити стару та запустити нову версію проєкту. Небажано зупиняти стару версію, проводити міграції, а потім запускати нову. Таким чином відбудеться простій у роботі проєкту (він же downtime). Призупинення може бути шкідливим для бізнес-процесів, тому топові сервіси не роблять простоїв під час деплою. 

Після зупинки/запуску сервіс розпочне роботу вже з новими функціями та оновленнями.

Автоматизація деплою

Чим швидше кінцевий користувач продукту отримуватиме оновлення та доопрацювання сервісу, тим краще для всіх. Та й весь процес деплою займає пристойну кількість часу та ресурсів. До того ж виникає можливість помилок при впровадженні нової версії. 

Тому deploy краще автоматизувати — для цього існує три способи. Який із них обрати — залежить від розмірів вашого проєкту, його бюджету та технологій, які в ньому використовуються:

1. Використовувати утиліти та надбудови, які написані певними мовами програмування. Головна проблема такого способу — прив’язка до конкретної мови.
2. За допомогою системи керування конфігураціями, які використовуються для автоматизації налаштування та розгортання ПЗ. Прикладами можуть бути Ansible або сервіс для вебпрограм Heroku. Такий спосіб добре підійде для деплою на керовані сервери.
3. З використанням платформ, здатних керувати контейнерами — систем оркестрації, найвідоміша з яких — Kubernetes.

Запуск деплою можна також автоматизувати. Для цього нам знадобиться Continuous Delivery або «безперервна доставка» — підхід, коли оновлення ПЗ відбувається з більшою частотою та меншими «порціями». 

Такий підхід непросто впровадити, підійде він далеко не для всіх проєктів, але якщо вже вдалося — про деплой можна забути, оскільки проходить він автоматично. Але варто зазначити, що з таким підходом дуже важливо мати якісний моніторинг помилок та систему оповіщення. А то всіляке буває.

Zero Downtime Deployment для уникнення простою

Як ми вже говорили раніше, перерв між зупинкою старої версії проєкту та запуском нової в ідеалі бути не повинно. Під час таких простоїв користувачі не мають доступу до сайту, а для великих бізнесів це втрата прибутку. Тим більше, великі проєкти деплояться досить довго. 

Саме тому великі проєкти використовують підхід Zero Downtime Deployment чи «деплой без простоїв». Такий метод дозволяє запустити нову версію сайту ще до зупинки старої, а це означає, що певний момент працюють обидві версії. 

Цей процес автоматизований, та спеціальні технології відстежують той момент, коли нова версія вже повноцінно запустилася. Тільки після цього відключається стара версія. 

Що потрібно для успішного Zero Downtime Deployment:

• Спеціальний балансувальник має перемикати трафік між двома версіями проєкту. Також непогано було б мати відразу два сервери.
• Найпростіше зробити деплой без зупинки в системі оркестрації, наприклад вищезгаданому Kubernetes.
• Для безперервної роботи необхідна висока культура написання коду. Дуже важливо стежити за дотриманням зворотної сумісності та всіма інтерфейсами.
• Останній пункт випливає із попереднього. База даних має бути зворотньо-сумісною між різними версіями сайту. Міграції в жодному разі не можна відкочувати, а таблиці та колонки — змінювати та видаляти.

Zero Downtime Deployment — ​​об’ємна тема, гідна окремої статті. Можливо, у майбутньому ми до неї повернемось.

Інструменти для Deploy

Інструментів для успішного деплою існує досить багато, і щоб було простіше розібратися, ми розділимо їх на три категорії:

• Інструменти для керування артефактами
• Інструменти для керування конфігураціями
• Інструменти для деплою

Управління артефактами

Артефакти — штучно створені елементи програми. Для їхнього управління існує велика кількість інструментів — JFrog Artifactory, Nexus Sonatype та інші. Давайте коротко розглянемо найпопулярніші.

JFrog Artifactory. Умовно безплатний менеджер сховища, який вважається одним із найпопулярніших у світі. Інструмент виступає як проксі між засобами для збирання та зовнішнім середовищем. Artifactory здатний кешувати віддалені артефакти, що прибирає необхідність їх повторного завантаження.

Apache Archiva. Менеджер репозиторію артефактів для великих проєктів. За заявами компанії-власника, добре взаємодіє з такими інструментами, як Maven, Continuum, ANT.

Nexus Sonatype. Репозиторій артефактів, що працює з проєктами, написаними всіма популярними мовами — C/C++, C#, Go, Java, JavaScript, Kotlin, PHP, Ruby, Python… Усього більше двох десятків. З приємного — безкоштовна версія досить функціональна, її цілком може вистачити для більшості проєктів.

Управління конфігурацією

Управління конфігурацією дозволяє різним версіям проєкту бути сумісними протягом усього циклу життя. 

Розглянемо кілька інструментів, які допоможуть правильно керувати конфігураціями.

Ansible. Система керування конфігураціями створена за допомогою Python. Цей інструмент відрізняється від інших відсутністю стану. Раніше аналогічні рішення були спрямовані на управління станом зміни. Після запуску та отримання необхідної конфігурації такий інструмент спробує виправити нинішню конфігурацію проєкту. При новому підході є лише компоненти з відсутністю стану, а нові версії коду є артефактами, які змінюють існуючі.

Інші переваги Ansible — це відкритий вихідний код, можливість тестування управління конфігураціями (адже це теж код, який потрібно тестувати) за допомогою фреймворку Molecule, використання мови серіалізації YAML (простіший і зрозуміліший, ніж JSON або XML).

З мінусів — сервер повинен працювати тільки під Unix/Linux, хоча всі робочі станції можуть бути на Windows. Але така конфігурація використовується і системами-конкурентами, наведеними нижче. Отже, тут без варіантів — потрібно опановувати Linux.

OpsCode Chef. Інструмент для більш класичних застосунків (без відсутності станів), що не вирішує завдання stateless-застосунків або проєктів у хмарі. Проєкт був дуже популярним ще років 10 тому, але розвиток хмарних технологій значно знизив його популярність. Як DSL використовує Ruby.

Puppet. Менш популярний, ніж попередні два. Непогано підійде для провізіонування та роботи з апаратною частиною, але підтримка роботи з управлінням конфігураціями сучасних вебзастосунків тут відсутня. Мовою конфігурації виступає PuppetDSL — своя власна мова, яку потрібно опанувати додатково. Як і «шеф-кухар», був непоганий для 2013-го, але 2023-го це скоріше флоп, ніж топ. 

Saltstack. Як і Ansible — система керування конфігураціями з відкритим вихідним кодом, написана на Python. Також використовує простий у засвоєнні YAML.

Saltstack та Ansible стрімко набирають популярність, тоді як Chef і Puppet скоріше переходять у нішевий сегмент застарілих програм. Але обирати вам.

Інструменти для деплою

Terraform. ПЗ з відкритим вихідним кодом, яке допоможе описати інфраструктуру проєкту у вигляді коду — від мережевих компонентів до образів сервера та зовнішніх хмарних сервісів. Проєкт існує з 2014 року, і за цей час обріс корисними плагінами та досить великою спільнотою. Terraform здатний підтримувати будь-яке оточення — локальне, хмарне, ваш варіант. 

У Terraform використовується JSON та власна декларативна мова конфігурації HCL. В останніх версіях HCL представлено більшість логічних функцій і класів, як і в інших популярних мовах програмування, що дозволяє розробнику швидко і зручно розібратися з Terraform.

AWS CloudFormation. Головний мінус системи — вона працює тільки для Amazon, творінням якого є. Відповідно, якщо ви створюєте застосунок на AWS — для решти він не підходить. З іншого боку, Terraform також працює з AWS Web Services.

Jenkins. Складно говорити про депло і не згадати про сервер автоматизації Jenkins. Написаний на Java, працює з Windows, Mac OS та Unix-системами. Легко та швидко встановлюється та налаштовується, товаришує із багатьма інструментами CI/CD. Ледве не стандарт для інструментів безперервної інтеграції, хоч і без можливості керування версіями і з ненайноваторським інтерфейсом. Ну і як не згадати маскота Jenkins з логотипу платформи — милого британського дворецького, який періодично стає героєм мемів і фотожаб, які створюють поціновувачі.

Висновок

Деплой — логічний етап розвитку будь-якого вебсайту або застосунку, який має серверну частину та користувачів, які отримують до нього доступ зі своїх локальних пристроїв. Без деплою доступу до вашого продукту ніхто з них не отримає.

Процес деплою часто буває непростим, але існує багато інструментів, які дозволяють автоматизувати запуск проєкту на сервері і полегшити життя розробникам, а також впроваджувати нові версії проєкту без його зупинки і простоїв. Так що опановуйте теорію, розбирайтеся з інструментами та удачі з деплоєм. Вона вам знадобиться 😉