Безперервна інтеграція (CI) і безперервна доставка (CD) є важливими термінами, які використовуються в DevOps і охоплюють набір практик, які дозволяють сучасним командам розробників частіше та швидше вносити зміни в код.

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

CI гарантує, що зміни коду регулярно тестуються та деплояться після їх об’єднання в спільному репозиторії (система контролю версій), щоб забезпечити їхню стабільність, тоді як CD забезпечує швидку доставку цих змін, де їх потім можна задеплоїти у середовищі.

CI/CD сприяють ефективному випуску програмного забезпечення для релізу нових високоякісних продуктів або фіч на ринок швидше, ніж будь-коли раніше.

continuous integration

Спочатку ми глибше розглянемо концепцію безперервної інтеграції.

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

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

І безперервна інтеграція (CI) дозволяє розробникам об’єднувати зміни коду в спільний білд.

За допомогою цього методу розробники можуть інтегрувати свої зміни або фіксувати код невеликими кроками, набагато частіше, можливо, навіть кілька разів на день. Кожен коміт запускатиме автоматичне збирання та тестування.

Іншими словами, після об’єднання цих змін серія автоматизованих тестів перевірить білд, щоб виявити будь-які помилки, щоб усі помилки можна було швидко виправити без порушення роботи проду.

ПЕРЕВАГИ БЕЗПЕРЕРВНОЇ ІНТЕГРАЦІЇ

Оскільки розробники часто вносять невеликі зміни, це дозволяє швидше деплоїти. Це також забезпечує швидший зворотний зв’язок, щоб розробники могли майже негайно виправляти помилки.

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

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

continuous delivery

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

ПЕРЕВАГИ БЕЗПЕРЕРВНОЇ ДОСТАВКИ (CD) ДУЖЕ ЧІТКІ І ЗРОЗУМІЛІ

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

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

Це також підвищує продуктивність, оскільки командам більше не доводиться вирішувати виснажливі завдання (як вирішення конфліктів при великій кількості пр), які натомість виконуються в пайплайнах, що дозволяє цим командам зосередитися на створенні кращих продуктів, що призводить до підвищення задоволеності клієнтів.

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

Continuous integration vs continuous delivery vs continuous deployment

У розробці програмного забезпечення процес починається з безперервної інтеграції, потім безперервна доставка будується на цьому процесі, щоб зарелізити зміни, які були об’єднані в спільний білд під час безперервної інтеграції. Це означає, що безперервна доставка дає змогу автоматизовано розгортати код від етапу розробки до етапу виробництва.

Отже, CI/CD представляють собою процес безперервної розробки, тестування та доставки нових випусків.

Безперервне розгортання (continuous delivery), яке часто плутають із безперервним постачанням (continuous deployment), насправді йде на крок далі, ніж безперервне постачання.

На цьому етапі всі зміни автоматично випускаються без будь-якого втручання людини, тоді як у безперервній доставці (continuous delivery) зміни готуються до доставки, але команда визначає, коли вони будуть задеплоєні вручну.

Підсумовуючи ці три основні поняття:

Безперервна інтеграція (CI) – короткочасні гілки, які об’єднуються в спільну гілку кілька разів на день, де серія автоматизованих тестів дає відгук про внесені зміни. Безперервна доставка (CD) – після безперервної інтеграції безперервна доставка готує програмне забезпечення до деплою; реліз на проді зазвичай виконується вручну. Безперервне розгортання – після CI та CD зміни автоматично розгортаються на проді; повністю автоматизований процес. Однак усі ці процеси повинні слідувати один за одним, а безперервна інтеграція є основою для двох інших.

CI/CD overview (ч.2)

Continuous testing Ми вже згадували, що під час CI/CD програмне забезпечення проходить низку автоматизованих тестів. Таким чином, процес CI/CD може включати такі типи тестів:

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

Юніт тести – для перевірки окремих частин програми. Ця ізольована частина бази коду називається блоком. Інтеграційні тести – оскільки юніт тести зосереджуються на окремому компоненті й, отже, самі по собі можуть бути недостатніми, інтеграційні тести гарантують правильну роботу кількох компонентів разом і перевіряють, як частини програми працюють разом як єдине ціле. Функціональні тести – ці тести перевіряють, чи функціонал працює належним чином. е2е тести – ці тести імітують роботу користувача, щоб переконатися, що реальні користувачі отримають роботу без помилок. Аксептенс тести – перевіряють поведінку програмного забезпечення під значним навантаженням, щоб забезпечити його стабільність і надійність

У наведеній нижче піраміді тестування показано різні типи тестів, які можна запускати.

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

CI/CD pipeline

CI/CD пайплайн — це серія процесів: стягування коду з репо, збірка білда, запуск автоматизованих тестів, які супроводжують програмне забезпечення протягом життєвого циклу розробки, доставляючи вихідний код до проду.

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

Включення і налаштування CI/CD пайплайну є важливим фактором для підтримки культури DevOps, оскільки це забезпечує швидкий і ефективний випуск програмного забезпечення з мінімальним ризиком. Таким чином, побудова конвеєра CI/CD реалізує ідеали DevOps на практиці, оскільки дозволяє розробникам часто вносити зміни, щоб отримати швидкий зворотний зв’язок, що веде до появи культури співпраці, підвищення продуктивності та прозорості між командами. Ці швидкі цикли зворотного зв’язку допомагають досягти головної мети створення ефективного CI/CD пайплайну, що зменшує ризик, зазвичай пов’язаний із новими релізами.

!https://www.abtasty.com/wp-content/uploads/ci-cd-pipeline.png

Етапи CI/CD пайплайну включають:

Source: CI/CD пайплайн запускається, коли новий код закомічений в репозиторій. Build: тут розробники вносять свої нові зміни в код і компілюють їх, щоб вони могли пройти через початкову фазу тестування Test: це коли новий код перевіряється за допомогою автоматизованих тестів (наприклад, запуск юніт тестів через постійну інтеграцію). Залежно від розміру та складності програмного забезпечення цей крок може тривати від секунд до годин. На цьому етапі буде надано зворотний зв’язок, необхідний розробникам для вирішення будь-яких проблем. Deploy: це коли код розгортається в середовищі тестування або стейджингу, щоб підготувати його до фінального релізу, тобто безперервної доставки. Зазвичай білд автоматично розгортається після проходження серії автоматизованих тестів. Deploy to production: код релізиться на прод для кінцевих користувачів вручну або автоматично

CI/CD tools

Jenkins: це один із найвідоміших інструментів із відкритим кодом для CI/CD. Як розширюваний сервер автоматизації його можна використовувати як сервер CI і перетворити на центр безперервної доставки.

CircleCI: інструмент, який пропонує гнучкі середовища та тисячі готових інтеграцій; Оркестровка CI/CD у хмарі або можливість використовувати автономні ранери для додаткової гнучкості та контролю.

GitLab CI/CD: цей інструмент дозволяє оптимізувати й автоматизувати процес релізу, пропонуючи безпечні та гнучкі варіанти розгортання. GitLab також діє як єдине джерело правди для CI/CD, тому ви можете створювати, тестувати, розгортати та контролювати свій код з однієї програми.

Travis CI: це платформа CI/CD з відкритим кодом, яка допомагає розробникам швидко та легко розробляти, тестувати та розгортати код. Цей інструмент швидко налаштовується та підтримує понад 30 мов, що забезпечує велику гнучкість.

GitHub Actions: це платформа CI/CD (Continuous Integration/Continuous Deployment), яка дозволяє автоматизувати ваші тестувальні та розгортальні процеси прямо у вашому репозиторії GitHub.

❗Це не весь список – є ще багато інших інструментів які є зараз.

Docker overview

Автоматизоване тестування та Continuous Integration (CI) стали важливими компонентами процесу розробки та тестування в сучасному процесі розробки програмного забезпечення. Як наслідок, використання Docker у пайплайнах CI/CD стає все більш популярним, оскільки це дозволяє бездоганно інтегрувати автоматизоване тестування з рештою робочого процесу розробки.

Docker — це інструмент, призначений для полегшення створення, розгортання та запуску програм за допомогою контейнерів. Контейнери дозволяють розробнику упакувати програму з усіма потрібними частинами, наприклад бібліотеками та іншими залежностями, і відправити все як один пакет. Завдяки цьому контейнеру розробник може бути впевнений, що програма працюватиме на будь-якій іншій платформі – лептоп колеги який захоче використати тести в докері, сервер CІ/CD, віртуальна машина Linux. Простими словами – незалежно від будь-яких індивідуальних налаштувань лептопа, які можуть відрізнятися від лептопа, який використовувався для написання та тестування коду – ви можете запустити тести.

Docker — це програмне забезпечення, яке дає можливість ізольовано встановити необхідну ОС (операційну систему), версію JavaScript, налаштувати змінні оточення, встановити різні залежності і дати доступ тільки за певних умов. При цьому дану програму абсолютно не буде хвилювати, що відбувається навколо.

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

1. Консистентність середовища: Docker дозволяє розробникам та тестувальникам використовувати контейнери, що забезпечують однакове середовище на різних машинах. Це зменшує “воно працює у мене” проблеми, які часто виникають, коли код працює в одному середовищі, але збої виникають в іншому.
2. Ізоляція залежностей: Кожен Docker контейнер ізолює своє програмне середовище від інших. Це означає, що ви можете мати різні проекти з різними залежностями на одній і тій же машині без конфліктів.
3. Швидке розгортання: Docker контейнери можуть бути швидко розгорнуті та знищені, що робить їх ідеальними для автоматизованого тестування. Це дозволяє автоматично створювати та видаляти тестові середовища, не витрачаючи час на їх налаштування та очищення.
4. Відтворюваність тестів: З Docker, ви можете з легкістю відтворити тести, оскільки кожен контейнер може бути налаштований точно так, як на лептопі (середовищі автора) – тому що внутрішня структура (ОС, налаштування і версія ноди, залежності). Це означає, що результати тестів є більш надійними та повторюваними.
5. Підтримка мікросервісної архітектури: Docker особливо корисний для тестування мікросервісів, оскільки кожен мікросервіс може бути запущений у своєму власному контейнері, імітуючи реальні умови розгортання.
6. Інтеграція з CI/CD: Docker легко інтегрується з інструментами неперервної інтеграції та неперервного розгортання (CI/CD), такими як Jenkins, GitLab CI, Github Actions, що дозволяє автоматизувати процеси тестування та розгортання.
7. Економія ресурсів: Використання контейнерів може бути більш ефективним з точки зору ресурсів, ніж використання окремих віртуальних машин для кожного тестового середовища, оскільки контейнери ділять ядро ОС і значною мірою використовують менше ресурсів
8. Підвищена мобільність: Завдяки Docker, розробники та тестувальники можуть легко переміщати середовища між різними машинами та облачними платформами, що забезпечує гнучкість та мобільність проекту.
9. Контроль версій для середовищ: Docker дозволяє використовувати версіонування для середовищ, як і для коду. Це означає, що ви можете легко відстежувати зміни у середовищі та відновлювати попередні версії при потребі.

Завдяки цим перевагам, Docker є незамінним інструментом у сучасному процесі тестування та розробки програмного забезпечення.

Docker vs VM

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

Контейнери: плюси і мінуси

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

плюси:

Швидкість Оскільки контейнери легкі та включають лише програмне забезпечення високого рівня, їх дуже швидко модифікувати та повторювати. Надійна екосистема Більшість систем виконання контейнерів пропонують розміщене загальнодоступне сховище готових контейнерів. Ці сховища контейнерів містять багато популярних програмних програм, таких як бази даних або системи обміну повідомленнями, і їх можна миттєво завантажити та виконати, заощаджуючи час для команд розробників мінуси

Експлойти спільного хосту (shared host) Усі контейнери використовують ту саму базову апаратну систему нижче рівня операційної системи, можливо, експлойт в одному контейнері може вийти з контейнера та вплинути на спільне обладнання. Більшість популярних середовищ виконання контейнерів мають загальнодоступні сховища попередньо зібраних контейнерів. Використання одного з цих загальнодоступних зображень становить загрозу безпеці, оскільки вони можуть містити експлойти або можуть бути вразливими до викрадення зловмисниками.

Провайдери контейнерів

Docker є найпопулярнішим і широко використовуваним середовищем виконання контейнерів. Docker Hub — це гігантське загальнодоступне сховище популярних контейнерних програмних програм. Контейнери на Docker Hub можна миттєво завантажити та розгорнути в локальному середовищі виконання Docker.

RKT вимовляється як “Ракета”, – це контейнерна система, орієнтована на безпеку. Контейнери RKT не дозволяють використовувати незахищені функції контейнера, якщо користувач явно не ввімкне незахищені функції. Контейнери RKT спрямовані на вирішення проблем безпеки, що лежать в основі перехресного зараження, через які страждають інші системи виконання контейнерів.

Віртуальні машини: плюси і мінуси

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

плюси:

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

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

мінуси:

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

Обсяг памʼяті для зберігання Віртуальні машини можуть займати багато місця для зберігання. Вони можуть швидко зрости до кількох гігабайт. Це може призвести до проблем з нестачею дискового простору на хост-машині віртуальних машин.

Провайдери віртуальних машин

Virtualbox — це безкоштовна система емуляції архітектури x86 з відкритим кодом, що належить Oracle. Virtualbox — одна з найпопулярніших і визнаних платформ віртуальних машин з екосистемою додаткових інструментів, які допомагають розробляти та розповсюджувати образи віртуальних машин.

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

Встановлення Docker Desktop

Встановлення Docker Desktop включає кілька основних кроків. Ось як це зазвичай відбувається:

Завантаження програмного забезпечення:

• Перейдіть на офіційний сайт Docker за адресою docker.com.
• Виберіть версію Docker Desktop, що відповідає вашій операційній системі (Windows, macOS).
• Завантажте інсталяційний файл.

Інсталяція Docker Desktop:

• Запустіть завантажений інсталяційний файл.
• Слідуйте інструкціям помічника встановлення. На цьому етапі може знадобитися підтвердити дозволи адміністратора або прийняти умови ліцензії.
• Виберіть необхідні параметри встановлення. Коли з’явиться відповідний запит, переконайтеся, що параметр «Використовувати WSL 2 замість Hyper-V» на сторінці конфігурації вибрано.

Перезавантаження системи (за потреби):

Після встановлення може знадобитися перезавантажити комп’ютер, особливо якщо ви встановлюєте Docker на Windows.

Запуск і налаштування Docker Desktop:

• Запустіть Docker Desktop через ярлик на робочому столі або через меню програм.
• Windows:

• Після запуску може з’явитися вікно з вимогою ввійти в Docker Hub або створити новий обліковий запис.

❗якщо немає акаунту – нижче в списку є лінк на інструкцію

• Mac:
• зажимаємо на клавіатурі комбінацію command+space і вводимо docker
• Налаштуйте додаткові параметри, такі як кількість виділених ресурсів (ОЗУ, ЦПУ) та загальні папки.
• як виглядає вікно Docker desktop

Перевірка інсталяції:

• Відкрийте термінал або командний рядок.
• Виконайте команду docker --version для перевірки успішного встановлення.

• Можна також спробувати запустити тестовий контейнер, використовуючи команду docker run hello-world.

Ці кроки можуть трохи відрізнятися залежно від вашої операційної системи і конкретних вимог до налаштування. Для отримання докладної інформації та пошагових інструкцій можна перейти до офіційної документації Docker по встановленню.

Dockerfile

Dockerfile

Dockerfile – це текстовий файл, який містить всі команди, необхідні для збирання образу Docker. Кожен рядок у Dockerfile є командою, яку Docker використовує під час створення образу. Ось основні аспекти використання Dockerfile та декілька прикладів:

1. Вказівка базового образу (FROM): Ця команда визначає базовий образ, від якого буде створюватися ваш образ. Наприклад, FROM ubuntu:20.04 вказує на створення образу на базі Ubuntu 20.04.
2. Встановлення змінних середовища (ENV): Команда ENV встановлює змінні середовища в образі. Наприклад, ENV MY_VARIABLE my_value встановлює змінну середовища MY_VARIABLE.
3. Запуск команд (RUN): RUN виконує команди в новому шарі образу та виводить результати. Це часто використовується для встановлення пакетів. Наприклад, RUN npm install.
4. Копіювання файлів та директорій (COPY та ADD): COPY і ADD використовуються для копіювання файлів і директорій з локальної системи до файлової системи образу. COPY є більш простою і прямою командою, в той час як ADD має додаткові можливості, такі як розпакування архівів.
5. Вказівка портів (EXPOSE): EXPOSE інформує Docker, що контейнер слухає певні порти під час запуску. Наприклад, EXPOSE 80 вказує, що контейнер буде слухати порт 80.
6. Запуск команди під час запуску контейнера (CMD та ENTRYPOINT): CMD визначає команду, що виконується за замовчуванням, коли контейнер запускається. ENTRYPOINT конфігурує контейнер для запуску як виконуваного файлу.

Приклад Dockerfile:

# Використання базового образу Ubuntu
FROM ubuntu:20.04

# створення папки
RUN mkdir -p app

# Встановлення змінних середовища
ENV APP_HOME /app

# Копіювання файлів проекту
COPY . .

#видалення файлів які не потрібні в контейнері
RUN rm package-lock.json && rm -rf node_modules

# Вказівка робочої директорії
WORKDIR app

# Встановлення необхідних пакетів in package.json
RUN npm install

# Відкриття порту 8080
EXPOSE 8080

# Виконання Node.js скрипта
CMD [ "npm", "start" ]

Цей Dockerfile створює образ на базі Ubuntu 20.04, встановлює node та необхідні залежності, копіює файли проекту у контейнер, відкриває порт 8080 і запускає скрипт.

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

Docker Image

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

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

Це шаблон лише для читання, який містить інструкції для створення контейнера Docker. Імеджі Docker зберігаються в реджістрі Docker, наприклад Docker Hub, загальнодоступному сховищі образів Docker.

Щоб створити Docker імедж, використовується Dockerfile у якому описані інструкції зі створення образу. Після конфігурації конфігів в Dockerfile можна використовувати команду docker build для створення Docker імеджу. Потім отриманий імедж можна відправити до реєстру Docker, наприклад Docker Hub, щоб інші могли використовувати його.

build

docker build [OPTIONS] PATH | URL | -

Команда docker build створює імейдж Docker із файлу Docker і «контексту». Контекст білда — це набір файлів, розташованих у вказаному ШЛЯХУ або URL-адресі. Процес збирання може посилатися на будь-який файл у контексті. Наприклад, ваша збірка може використовувати інструкцію COPY для посилання на файл у контексті.

Параметр URL-адреси може посилатися на три типи ресурсів: сховища Git, попередньо запаковані контексти архівів і файли простого тексту.

URL-адреси Git приймають конфігурацію контексту у своєму розділі фрагментів, розділених двокрапкою (:). Перша частина представляє посилання, яке Git перевірить, і може бути гілкою, тегом або посиланням. Друга частина представляє підкаталог всередині репозиторію, який використовуватиметься як контекст збірки.

Наприклад, виконайте цю команду, щоб використовувати папку під назвою docker у контейнері гілки:

docker build <https://github.com/docker/rootfs.git#container:docker>

image

• команда яка дозволяє переглянути усі імейджі на машині

docker images

REPOSITORY                TAG                 IMAGE ID            CREATED             SIZE
<none>                    <none>              77af4d6b9913        19 hours ago        1.089 GB
committ                   latest              b6fa739cedf5        19 hours ago        1.089 GB
<none>                    <none>              78a85c484f71        19 hours ago        1.089 GB
docker                    latest              30557a29d5ab        20 hours ago        1.089 GB
<none>                    <none>              5ed6274db6ce        24 hours ago        1.089 GB
postgres                  9                   746b819f315e        4 days ago          213.4 MB
postgres                  9.3                 746b819f315e        4 days ago          213.4 MB
postgres                  9.3.5               746b819f315e        4 days ago          213.4 MB
postgres                  latest              746b819f315e        4 days ago          213.4 MB

запуск за параметром назви імейджу

docker images java

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
java                8                   308e519aac60        6 days ago          824.5 MB
java                7                   493d82594c15        3 months ago        656.3 MB
java                latest              2711b1d6f3aa        5 months ago        603.9 MB

Якщо передати параметри REPOSITORY, і TAG, буде показано лише імейджі, які відповідають цьому репозиторію та тегу. Щоб знайти всі локальні зображення в репозиторії “java” з тегом “8”, можна використовувати такі параметри:

docker images java:8

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
java                8                   308e519aac60        6 days ago          824.5 MB

якщо нічого не буде підпадати під ці параметри то і результати будуть відсутні

docker images java:0

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

Docker Container. Docker Hub. Docker Compose

Docker Container

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

Контейнер Docker — це виконання Docker імейджу. Це закрите середовище, яке об’єднує код і всі його залежності в єдиний портативний пакет. Це легкий і самодостатній об’єкт, який містить усе необхідне для запуску програми/тестів.

На аплікейшн рівні контейнери служать абстракцією, абсолютно не знаючи про операційну систему або файли хоста. Натомість вони використовують середовище, надане Docker Desktop, яке включає базову операційну систему та всі залежності, необхідні для виконання програми.

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

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

Тобто це ізольоване середовище від ОС, де можна виконати дії без впливу на ОС.

Docker Hub

Docker Hub — це сервіс, який розробляється і підтримується командою Docker для пошуку та обміну імейджами контейнерів.

Це найбільше у світі сховище імейджів контейнерів із різним складом, включаючи спільноти розробників контейнерів, проекти з відкритим кодом і незалежні постачальники програмного забезпечення (ISV), які створюють і розповсюджують свій код у контейнерах.

Інструкція з створення акаунту

https://docs.docker.com/docker-id

це коротка інструкція по створенню і налаштуванню доступу до докер хабу.

❗без акаунту неможливо скачати імейдж з докер хабу і використовувати.

Docker Compose

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

Compose працює в будь-якому середовищі: прода, дев, тест, тестування, і на усіх відомих CI провайдерах. Він також містить команди для керування всім lifecycle вашої програми:

Запуск, зупинка та відновлення сервісів Перегляд статусу запущених сервісів Робота з логами запущених сервісів

version: '3'
services:
  web:
    image: apache
    build: ./webapp
    container_name: apache
    restart: always
    # we can see the server running at "localhost:8080"
    ports:
      - "8080:80"

  e2e:
    image: cypress
    build: ./e2e
    container_name: cypress
    depends_on:
      - web
    # note: inside e2e container, the network allows accessing
    # "web" host under name "web"
    # so "curl http://web" would return whatever the webserver
    # in the "web" container is cooking
    # see https://docs.docker.com/compose/networking/
    environment:
      - CYPRESS_baseUrl=http://web
    command: npx cypress run
    # mount the host directory e2e/cypress and the file e2e/cypress.config.js as
    # volumes within the container
    # this means that:
    #  1. anything that Cypress writes to these folders (e.g., screenshots,
    #     videos) appears also on the Docker host's filesystem
    #  2. any change that the developer applies to Cypress files on the host
    #     machine immediately takes effect within the e2e container (no docker
    #     rebuild required).
    volumes:
      - ./e2e/cypress:/app/cypress
      - ./e2e/cypress.config.js:/app/cypress.config.js

cypress images

cypress/base

• https://hub.docker.com/r/cypress/base

Docker імедж, які містять усі залежності операційної системи, необхідні для запуску Cypress, але НЕ сам Cypress і без попередньо встановлених браузерів.

Якщо потрібна специфічна версія ноди або ОС – то це можна знайти за тегом

cypress/browsers

• https://hub.docker.com/r/cypress/browsers

Docker імедж з усіма залежностями операційної системи та деякими попередньо встановленими браузерами, але НЕ сам Cypress.

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

cypress/included

• https://hub.docker.com/r/cypress/included

Docker імедж із залежностями операційної системи та Cypress, встановленими глобально, і браузерами.

Імеджі позначаються тегами згідно встановленої версії Cypress та версій браузерів; їх має бути достатньо для запуску тестів Cypress в headless режимі або в інтерактивному режимі за допомогою однієї команди Docker, наступна стаття про це.

Запуск локальних Cypress тестів за допомогою докеру

У цьому розділі ми будемо використовувати cypress/included (останньою версією cypress/included є 13.6.0 на момент написання конспекту) і в деяких прикладах і скріншотах версія 12.8.1 . Цей Docker імедж постачається з усіма залежностями операційної системи, встановленним Cypress і браузерами, Chrome, Firefox, Edge, встановленими глобально Існує кілька способів запуску тестів Cypress у контейнерах Docker. Одним із способів є запуск за допомогою наступної команди з кореня вашого проекту:

docker run -it -v $PWD:/e2e -w /e2e cypress/included:13.6.0

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

Огляд команди запуску:

• docker run – запуск докер контейнеру
• -it – параметр вказує, що контейнер повинен працювати в інтерактивному режимі.
• -v – для створення простору для зберігання всередині контейнера.
• $PWD – монтує поточний робочий каталог (представлений змінною “$PWD”)
• приклад використання команди pwd

• :/e2e – мапає поточну папку на папку /e2e всередині контейнера.
• -w /e2e – встановлює робочий каталог всередині контейнера на “/e2e”.
• cypress/included:13.6.0 визначає Docker імедж для використання в контейнері. У цьому випадку це образ “”cypress/included”, який містить Cypress та інші залежності, попередньо встановлені у версії 13.6.0

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

Використовуючи певний тег зображення, наприклад «cypress/included:12.8.1», ви гарантуєте, що ваша програма завжди використовує ту саму версію зображення. Це може допомогти запобігти неочікуваній поведінці та полегшити вирішення будь-яких проблем, що виникають.

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

Після запуску команди run докер десктоп автоматично знайде і почне завантаження необхідної версії на локальну машину

Як показано на скріншоті, система намагається знайти Cypress імедж. Спочатку він перевіряє, чи не завантажено у вашу систему. Якщо його не знайдено, система спробує завантажити образ із Docker Hub.

Після успішного завантаження автоматично докер запустить виконання тестів в headless режимі в дефолтному браузері Electron

Можна перевірити запущені контейнери командою

docker ps -a

На скріншоті видно дані контейнера ID, назву, статус

Запуск тестів Cypress на певних версіях браузера може знадобитися для забезпечення сумісності кросбраузерності. По дефолту Cypress запускає тести у браузері Electron, але якщо ви хочете запустити тести Cypress у браузерах Chrome і Firefox за допомогою образу Docker, виконайте наведені нижче потрібно передати параметр —browser для команди

docker run -it -v $PWD:/e2e -w /e2e cypress/included:12.8.1 --browser firefox
docker run -it -v $PWD:/e2e -w /e2e cypress/included:12.8.1 --browser chrome

Результат виконання тестів в докері такий самий як і запуск локально

playwright images

Докер імеджі для playwright знаходяться в реджістрі microsoft artifact registry

Playwright Microsoft

• https://mcr.microsoft.com/en-us/product/playwright/about

По дефолту Docker імедж використовуватиме користувача root для запуску браузерів. Це вимкне Chromium sandbox, яка недоступна з root. Якщо ви запускаєте перевірений код (наприклад, е2е тести) і хочете уникнути клопоту з керуванням окремим користувачем, то можна і користувача root використовувати.

docker run -it --rm --ipc=host mcr.microsoft.com/playwright:v1.40.0-jammy /bin/bash

❗Під час використання Chrome браузера рекомендується використовувати параметр –ipc=host. Без цього параметра в Chrome може закінчитися пам’ять.

❗якщо є потреба в запуску тестів на різних версіях ОС то потрібно змінювати тег для докер імеджу

• Ubuntu 22.04 LTS (Jammy Jellyfish), image tags include jammy
• Ubuntu 20.04 LTS (Focal Fossa), image tags include focal

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

Під час запуску в контейнері є можливість передати усі параметри по запуску тестів які доступні для playwright

Command line

• https://playwright.dev/docs/test-cli

Запуск локальних Playwright тестів за допомогою докеру

• Для завантаження тестів які є локально можна використовувати таку ж команду як для Cypress тестів

docker run -v $PWD:/e2e -w /e2e — rm -it mcr.microsoft.com/playwright:v1.40.0-focal
it - працювати в інтерактивному режимі.

• v – для створення простору для зберігання всередині контейнера.
• w – встановлює робочий каталог всередині контейнера на “/e2e”.
• ipc=host – параметр для запуску різних браузерів

Підсумки

На цій лекції розглянули основні підходи для пришвидшення релізів і отримання фібдеку по коду, впровадження автоматизованого тестування в пайплайни. Розглняули основні прнинципи технології докер. Налаштування і запуск тестів всередині докер контейнерів.

Додаткові матеріали

Overview of Docker Desktop

• https://docs.docker.com/desktop/

Containers vs. virtual machines

• https://www.atlassian.com/microservices/cloud-computing/containers-vs-vms

docker

• https://hub.docker.com/

cypress/included

• https://hub.docker.com/r/cypress/included

cypress/browsers

• https://hub.docker.com/r/cypress/browsers

Playwright

• https://mcr.microsoft.com/en-us/product/playwright/tags