Docker — одна з основних технологій у DevOps, якою також часто користуються і розробники. Цей інструмент дозволяє упаковувати застосунки в окремі ізольовані контейнери, які містять усі необхідні залежності та ресурси для запуску того чи іншого додатку.
У комʼюніті існує чимало упереджень про Docker. Це аналог віртуальних машин чи окремий інструмент? Підходить тільки для деплою мікросервісної інфраструктури чи також для інших завдань? Його можна опанувати за декілька днів, чи він вимагає комплексної експертизи? Якщо контейнер — це ізольоване середовище, чи є вразливим ПЗ, що знаходиться у ньому? А також як зберігати дані в середині контейнерів, щоб унеможливити їх втрату та правильно оптимізувати? Володимир Абрамович, DevOps Engineer у Boosters, який розвиває проєкт Promova, спростовує найпоширеніші міфи про Docker.
> Docker — це повноцінна віртуалізація
> Docker використовують тільки для деплою мікросервісних застосунків
> Опанувати Docker — просто
> Контейнери ізолюють застосунок від вразливостей
> Зупинка контейнера призводить до втрати усіх даних
МІФ №1
Docker — це повноцінна віртуалізація
При першому знайомстві з цією технологією спеціалісти дуже часто ототожнюють контейнеризацію та віртуалізацію. Важливо розуміти, що це два різні підходи до ізоляції та управління ресурсами програмного забезпечення. Docker використовує концепцію контейнеризації, тоді як віртуалізація може використовувати різні технології, такі як гіпервізори.
Контейнеризація ґрунтується на ізоляції процесів у межах операційної системи. Контейнери містять усі необхідні залежності та ресурси для виконання застосунку ділять ядро ОС з головною системою. Вони є легшими та швидшими у порівнянні з віртуальними машинами, оскільки вони не потребують повноцінної операційної системи для кожного окремого контейнера. Цей підхід дозволяє швидше розгортати застосунки та масштабувати їх через легку та повторювану ізоляцію.
Особливістю віртуалізації є ізоляція на рівні операційних систем: для цього використовуються гіпервізори, які створюють повноцінні віртуальні машини (VM). Кожна з них має власну операційну систему та зарезервовані ресурси. Завдяки цьому віртуальні машини ізолюються одна від одної та від хост-системи.
Віртуалізація може бути важчою, оскільки для кожної VM потрібна своя копія операційної системи та додаткові ресурси для гіпервізора. Технологія дозволяє використовувати різні операційні системи на одному хост-сервері, що може бути корисним у великих середовищах.
Кожна з цих технологій має свої переваги, недоліки та кейси застосування.
Обираючи між Docker та віртуалізацією, важливо врахувати конкретні потреби вашого проєкту, вартість ресурсів, вимоги до швидкодії та ізоляції.
Docker підходить у кейсах для упакування та запуску програм передбачуваним і повторюваним способом у багатьох середовищах. Якщо у вас є особливі вимоги до апаратного забезпечення, або ви розробляєте на одній апаратній платформі та потребуєте націлювання на іншу операційну систему, вам знадобиться віртуальна машина.
МІФ №2
Docker використовують тільки для деплою мікросервісних застосунків
Існує упередження, що Docker використовують лише для розгортання мікросервісних застосунків. Частка правди в цьому є, проте на практиці ця технологія — універсальний інструмент не тільки для DevOps інженерів. Нею користуються також девелопери, оскільки вона значно полегшує локальну розробку. Наприклад, використовуючи Docker, можна подивитися, як той чи інший сервіс працюватиме в різних конфігураціях. Для цього запускають декілька варіацій з різними параметрами та залежностями, тим самим локально тестуючи їх.
Також Docker полегшує автоматизацію певних систематичних задач, які запускаються з певною періодичністю. Такого роду джоби можна запакувати та запускати в контейнерах. Наприклад, так виконується автотестування платформи та застосунків Promova. Це дає змогу економити ресурс, запускати контейнери під окремі завдання, коли це потрібно, а не тримати віртуальну машину, що постійно працює.
У цього міфу є також інший бік — коли Docker вважають універсальним рішенням для всього на світі. У контейнери запаковують навіть прості скрипти на декілька рядків. Насправді ж така процедура значно довша та менш ефективна, ніж просто запустити скрипт у потрібному середовищі, встановивши пару залежностей.
МІФ №3
Опанувати Docker — просто
Коли спеціаліст навчився писати перші прості Docker-контейнери, у нього може скластися враження, що це досить легка технологія. Безперечно, на базовому рівні з нею можуть розібратися усі дотичні до технічної сфери. Фактично це базове середовище, в межах якого ти пишеш конструкцію, визначаєш певні залежності, підтягуєш необхідні файли й запускаєш свою програму.
Проте коли починаєш глибше розбиратися з Docker, розумієш, що будувати контейнери в один крок — недостатньо, потрібна додаткова експертиза. Рано чи пізно починається боротьба за те, щоби контейнер білдився максимально швидко, адже процес деплою має бути максимально оптимізованим за часом. Коли ви створюєте той самий Docker-образ декілька разів, знання того, як оптимізувати кеш-збірки, є важливим інструментом для забезпечення швидкої роботи. Багатоетапні збірки корисні кожному, хто намагався оптимізувати Dockerfiles, зберігаючи їх легкими для читання та обслуговування. Таким чином у результаті можна отримати максимально оптимізований легковісний контейнер.
Також при масштабуванні контейнеризованих додатків виникає потреба у застосуванні інструментів для оркестрації, для чого доведеться отримувати додаткову експертизу в інших технологіях — Kubernetes, AWS Fargate, Docker Swarn тощо.
МІФ №4
Контейнери ізолюють застосунок від вразливостей
Варто розуміти, що будь-яка технологія не є безпечною на 100%. Контейнер — ізольоване середовище, проте для них обов'язково треба передбачити певні заходи безпеки та налаштувати відповідний моніторинг.
Безпека контейнера полягає в тому, щоб образ контейнера, який ви запускаєте у своєму середовищі, містив лише бібліотеки, базове зображення та будь-які користувацькі біти, які ви оголошуєте у вашому Dockerfile, а не зловмисне програмне забезпечення чи відомі вразливості.
Важливим є також сканування вразливостей образу Docker, задля виявлення відомих вразливостей безпеки в пакетах, перелічених у Docker-файлі. Це дозволяє знаходити їх і виправляти перед використанням або надсиланням образу в Docker Hub або будь-який реєстр Docker. Крім того, сканування вразливостей надає користувачам бачення стану безпеки їхніх образів Docker.
МІФ №5
Зупинка контейнера призводить до втрати усіх даних
Важливо розуміти, що будь-якої миті контейнер може рестартувати: завершитися і знову запуститися з образу. При цьому є ризики, що дані будуть втрачені.
Цей факт потрібно враховувати та зробити так, щоби важливі дані не залежали від ефемерності контейнерів та були доступними одразу в декількох середовищах.
Водночас є кейси, коли певні дані недоречно зберігати на хості, наприклад, якщо у контейнері запущено застосунок, який містить тимчасові дані. Вони можуть бути видалені, та це не є критичним.
Щоби уберегти контейнер від втрати даних, є рішення — Docker volume. Простими словами це просто папка хоста, примонтована до файлової системи контейнера. Оскільки технічно вона більше не належить контейнеру, то останній можна сміливо видаляти, перестворювати заново, знову прикручувати до нього хостові папки, і з даними всередині нічого не трапиться.
