Контейнеризація — механізм, що часто застосовується на практиці. Наприклад, при пошуку по headhunter ви знайдете на поточний день 477 вакансій, де згадується Docker. Тому не зайвим буде ознайомитися з тим, що це таке. Сподіваюся, цей невеликий огляд допоможе сформувати першу виставу. Ну і підкріпить його додатковими матеріалами, на кшталт курсів на Udemy.
Вступ
У цьому невеликому огляді хочеться торкнутися такої теми, як контейнеризація. І розпочати треба з розуміння того, що таке взагалі контейнеризація. Відповідно до вікіпедії " Контейнеризація " - це віртуалізація на рівні операційної системи (тобто НЕ апаратна), при якій ядро операційної системи підтримує кілька ізольованих екземплярів простору користувача замість одного. " Простір користувачаЦе дозволяє позбавитися від накладних витрат на емуляцію віртуального обладнання та запуску повноцінного екземпляра операційної системи. Можна сказати, що це "легковажна" віртуалізація. Ядро (kernel) - центральна частина ОС, що забезпечує програмам координований доступ до ресурсів комп'ютера, таких як процесорний час, пам'ять, зовнішнє апаратне забезпечення, зовнішній пристрій введення та виведення інформації. Також зазвичай ядро надає послуги файлової системи та мережевих протоколів. Загалом це серце всієї системи. Як додаткова інформація може бути корисно ознайомитися з матеріалом " таким як процесорний час, пам'ять, зовнішнє апаратне забезпечення, зовнішній пристрій введення та виведення інформації. Також зазвичай ядро надає послуги файлової системи та мережевих протоколів. Загалом це серце всієї системи. Як додаткова інформація може бути корисно ознайомитися з матеріалом " таким як процесорний час, пам'ять, зовнішнє апаратне забезпечення, зовнішній пристрій введення та виведення інформації. Також зазвичай ядро надає послуги файлової системи та мережевих протоколів. Загалом це серце всієї системи. Як додаткова інформація може бути корисно ознайомитися з матеріалом "Загальні відомості про контейнери ”. І ще пару слів, щоб вступ був повним. У нас тепер є розуміння, що в операційній системі є ядро. Воно забезпечує ізольованість екземплярів просторів користувачів. У цьому контексті Ви можете зустріти такий термін як “cgroups ” . називається саме той самий механізм ядра Linux, який дозволяє цього досягти, тому можна сказати, що шлях контейнеризації почався з Linux систем, однак, починаючи з Windows 10 також з'явилася підтримка контейнеризації, для роботи з віртуалізацією необхідно в BIOS комп'ютера налаштувати підтримку віртуалізації. Як це залежить від комп'ютера, наприклад, це може виглядати так:
На Windows це можна перевірити у різний спосіб. Наприклад, можна завантажити спеціальну утиліту з сайту Microsoft: Hardware-Assisted Virtualization Detection Tool . Ну і варто згадати ще одне важливе поняття – гіпервізор. Гіпервізор (Hypervisor) - це монітор віртуальних машин, програма для забезпечення паралельного виконання кількох операційних систем на тому самому комп'ютері. Гіпервізор забезпечує ізоляцію операційних систем один від одного, розділяє між запущеними ОС ресурсами. Одним з таких гіпервізорів є Oracle VirtualBox .
Docker
Отже, що таке віртуалізація – зрозуміло. Але як цим скористатися? І тут нам на допомогу приходить Docker. Docker — програмне забезпечення для автоматизації розгортання та керування програмами в середовищах з підтримкою контейнеризації. Варто почати з того, що Docker представлений таким поняттям, як Docker Engine. І почати варто з офіційного сайту докера та розділу " Docker Overview ".
У документації сказано, що докер складається з:
Докер-сервер, який називається Docker Daemon process (dockerd).
Інтерфейс командного рядка, він CLI (docker).
REST API, який описує те, як програми можуть "розмовляти" з deamon і давати йому вказівки, що робити.
Перш, ніж ми перейдемо до подальшого занурення, встановимо докер, тобто встановимо докер демона. На сайті Docker є інструкція по встановленню " Docker для Windows ". Цікаво, що Docker має свої системні вимоги. І якщо у Вас, як і у мене, стара Windows, наприклад Windows 7, необхідно використовувати Docker Toolbox.
Docker Toolbox
Для встановлення Docker на старі машини, що не підходять під системні вимоги. На сайті так і написано "Legacy Desktop Solution". Перейдемо на сторінку " Docker Toolbox " та скачаємо його. Важить такий набір близько 211 мегабайт. Встановимо в комплектації за замовчуванням, тобто просто покірно погоджуватися з усім, не переставляючи прапори. Після встановлення перевіримо, що все гаразд. Надалі нашим полем бою буде командний рядок. Рекомендую не використовувати командний рядок Windows, тому що з ним можуть бути неочевидні проблеми. Краще використовувати bash shell. На Windows рекомендований спосіб отримання його - встановити собі систему контролю версій git, все одно вона знадобиться. Тому що "у комплекті" з ним буде і потрібний нам bash. Для цього огляду я використовуватиму саме git bash. Також bash можна поставити разом з CYGWIN . Запустимо bash або git bash. Переконаємося, що у нас встановилася докер машина, вона Docker Machine: docker-machine -version Що таке ця Docker Machine? Docker Machine - це утиліта для керування докеризованими хостами (це такі хости, на яких встановлено Docker Engine). Якщо ми виконаємо відразу після встановлення Docket Toolbox перегляд докер-машин за допомогою команди docker-machine ls, то побачимо порожній список:
Давайте створимо нову машину. Для цього нам знадобиться виконати команду create : docker-machine create -- driver virtualbox codegym: Ми побачимо лог створення докер машини:
Тут цікаво нам таке. Що за Boot2Docker? Це мінімалістичний дистрибутив Linux для запуску Docker Engine (адже ми розуміємо, що Docker працює завдяки засобам віртуалізації Linux, а в Windows необхідний механізм з'явився тільки починаючи з Windows 10). Цей дистрибутив заснований на дистрибутиві " Tiny Core Linux ". Також згадується про VirtualBox VM. Це тому, що ми вказали --driver virtualbox. Було створено нову віртуальну машину в VirtualBox з образу Boot2Docker. Після створення ми можемо запустити VirtualBox (бо VirtualBox встановлюється разом з Docker Toolbox) і побачити створену віртуальну машину для докер машини:
Після створення нам запропонують виконати команду " docker-machine env ", щоб отримати змінні середовища, які потрібно налаштувати для підключення до докеру машини:
Після виконання цієї команди за допомогою docker-machine ми підключаємося до віддаленого докеризованого хоста (в даному випадку віртуального, розміщеного на Virtual Box) і можемо виконувати команди docker у себе локально так, ніби виконували їх на віддаленому хості. Для перевірки можемо виконати команду " docker info ". У випадку, якщо підключення до докеру машини не встановлено, ми отримаємо помилку. А якщо все добре – інформацію про докер на докер машині. Тепер час розібратися з тим, як взагалі працює докер і як його використовувати.
Docker Containers
Отже, ми маємо докер. Що таке взагалі цей докер? Зрозуміти це нам допоможе документація Docker та розділ " Get started ". У вступній частині цього розділу розповідається про концепцію докера ( Docker Concepts ). Там вказано, що докер — це платформа для розробки, налагодження та запуску програм у контейнерах. Тому головне для докера це контейнери. Навіть якщо ви подивитеся на логотип докера – це кит, який тримає на своїй спині контейнери. Але що таке контейнер? Далі у розділі " Images and Containers " говориться, що контейнер - це запущений екземпляр Image. А Image - це виконуємо "пакет", який містить все необхідне для програми (код, оточення, бібліотеки, налаштування тощо). Тепер спробуймо це самі. На сайті Docker'Docker samples ", в якому є " Docker for Beginners ". Приклади звідси мені здаються цікавішими. Отже, ми раптом захотіли ознайомитися з Alpine Linux і можемо це зробити за допомогою контейнерів докера. Щоб отримати образ, ми повинні його "витягнути" або " витягнути". Тому виконуємо команду docker pull :docker pull apline
Як ми бачимо, ми звідкись скачуємо. За замовчуванням докер дивиться на свій репозиторій у мережі https://hub.docker.com . Після успішного отримання ми можемо перевірити список доступних образів, виконавши команду docker images :
Тепер у нас є образ apline. Так як контейнер - запущений екземпляр image, то давайте запустимо цей образ. Виконаємо запуск контейнера за допомогою команди docker run alpine. Як бачимо, нічого не сталося. Якщо ми виконаємо команду docker psдля виведення всіх активних контейнерів, теж нічого не отримаємо. Але якщо ми виконаємо docker ps -aто побачимо всі контейнери:
Справа в тому, що ми запустабо докер не в інтерактивному режимі. Тому він виконав команду і зупинився. Команда була – відкриття терміналу. Давайте виконаємо те саме, але в інтерактивному режимі (з прапором -it ):
Як видно, подолавши одну помилку і скориставшись підказкою, ми потрапабо на контейнер і можемо в ньому працювати! Щоб вийти з контейнера, не припиняючи його роботу, можна натиснути Ctrl + p + q. Якщо виконати тепер docker ps, то побачимо один активний контейнер. Щоб зайти на вже запущений контейнер, виконаємо команду docker exec :
Відмінний опис того, як це все відбувається, рекомендую прочитати в описі докер семпла: " 1.0 Running your first container ". Він мені подобається за те, що там все написано дуже доступно та зрозуміло. Якщо коротко перефразувати, ми підключені за допомогою docker-machine до віртуальної машини, на якій запущений Docker Daemon. За допомогою CLI REST API ми просимо запустити alpine образ. Докер його знаходить і тому не скачує. Докер створює новий контейнер і запускає в цьому контейнері вказану команду. І все це, звісно, добре. Але навіщо це все? І тут нам треба розібратися, як взагалі докер створює image. А створює він їх на основі докерфайлу (dockerfile).
Dockerfile
Як сказано в Dockerfile reference , докерфайл - це текстовий файл, в якому вказані всі команди для отримання зображення. Насправді всі образи, які ми отримуємо (навіть Alpine, з прикладу вище) створювалися з докерфайлу. Давайте зберемо свій образ із Java додатком. І для початку нам знадобиться це Java додаток. Пропоную скористатися системою складання Gradle, детальніше про яку можна прочитати в короткому огляді: " Коротке знайомство з Gradle ". Допоможе нам у створенні проекту " Gradle Build init plugin ". Виконаємо створення нової програми Java за допомогою Gradle: gradle init --type java-application Ця команда створює заготівлю Java проекту. Це standalone додаток, а нам хотілося б створити веб-додаток. Видалимо класи App та AppTest (їх згенерував автоматично Gradle Build Init Plugin). Щоб швидко створити веб-додаток скористаємося tutorial'ом від Gradle: " Building Java Web Applications ". Відповідно до tutorial виконаємо:
Відкриємо білд скрипт build.gradle і поправимо його, згідно з розділом: " Add a Gradle build file ".
plugins {
id 'war'
id 'org.gretty' version '2.2.0'}
Цікаво, що Gretty не бачить помилку в HelloServlet, яка описана вище. Це доводить, що у різному оточенні додаток себе може по-різному. Gretty може працювати там, де звичайний standalone сервер видасть помилку. Залишилося перевірити, що програма працює правильно. Виконаємо:gradle appRun
Якщо все добре, то командою gradle warзберемо архів з розширення war (web archive). За замовчуванням gradle збирає його в каталозі \build\libs. Тепер ми готові написати наш докерфайл. Керуючись " Dockerfile reference " створимо докерфайл. Створимо файл під назвою "Dockerfile" в корені нашого Java проекту (там же, де build скрипт). Відкриємо його на редагування. Цей файл має свій формат, описаний у розділі " Dockerfile reference : FormatБудь-який докерфайл починається з інструкції FROM, вказуючи "базовий образ" (base image). Можна сказати, що це батьківський образ, на основі якого ми робимо наш image. Батьківський образ нам вибрати дуже просто. Веб-додатку потрібен веб-сервер. Наприклад, ми можемо використовувати веб-сервер Tomcat.Заходимо на офіційний репозиторій докера, який називається docker hub .
Варто також розуміти, що називається образ tomcat. Але крім назви він має тег. Тег – це як версія. Образи томкату різних версій відрізняються тим, яка версія Tomcat використовується, яка версія jre та який базовий образ. Наприклад, ми можемо отримати образ docker pull tomcat:9-jre8-alpine У ньому використовується 9 версія tomcat, jre версії 8 та образ alpine як основа. Це може мати важливу роль, щоб зменшити розмір нашого образу.
Як бачимо, різниця величезна. Якщо ми будуватимемо наш образ на основі tomcata alpine, то ми почнемо всього зі 100 мегабайт, а не з 600. Відповідно, раніше створений докерфайл додамо наступний вміст:
# Базовый образ,"наследуемся" от него
FROM tomcat:9-jre8-alpine
# Копируем из BuildContext'а собранный web archive в каталог томката
COPY build/libs/docker.war /usr/local/tomcat/webapps/docker.war
# Меняем рабочий каталог на томкатовский
WORKDIR /usr/local/tomcat
# Открываем порт 8080 для контейнера, т.к. его слушает томкат
EXPOSE 8080
І тепер виконаємо команду побудови образу: docker build -t jrdocker ..
-t- Це tag, тобто як назвати зібраний образ. Точкою в кінці ми позначаємо, що поточний каталог (каталог, де знаходиться докерфайл і звідки ми запускали команду), додаємо в Build context. Build context— це контекст тих файлів, які доступні для створення докерфайлу. Як видно, ми змогли скопіювати завдяки цьому зібраний war файл у наш образ, каталог веб-сервера. Тепер запустимо наш образ:docker run -d --rm -p 8888:8080 jrdocker
Щоб зрозуміти, чи запустився сервер, можна подивитися лог з контейнера. Лог можна отримати за допомогою команди docker logs із зазначенням контейнера за його ID або назвою. Наприклад:
Ну і не забуваємо, що ми на ім'я завжди можемо зайти на запущений контейнер командою: winpty docker exec -it Ім'яКонтейнера sh Тепер лишилося підключитися. Раніше ми вказали EXPOSE , тобто зсередини контейнера дозволабо доступ до порту 8080. Коли ж ми запускали сам контейнер, ми вказали тег -p ( incoming ports ), тим самим співвіднесли порт 8080 на контейнері (там очікує підключення веб-сервер томкат) з портом 8888 на машині з демоном докер. Як ми пам'ятаємо, демон декер ми запустабо не безпосередньо, а через docker-machine. Тому, ще раз запитаємо дані щодо наших докер машин за допомогою команди docker-machine ls і звернемося на сервер у контейнері:
Таким чином, ми з Вами щойно запустабо свій веб-додаток у докер контейнері! ) Ще хотілося б відзначити наступне. У разі виникнення проблем із доступом слід пам'ятати, що докер машина насамперед це віртуальна машина Virtual BOx. Можливо, проблеми в налаштуваннях мережі віртуальної машини. Робоча конфігурація VMBox може виглядати так:
Шари (layers)
Ми з вами вже розібралися, що образи створюються з докерфайлів і що докерфайли це набір команд. Ще ми розібралися, що докерфайл має батьківський. І що розмір образів різний. Цікаво, що можна переглянути історію того, як збирався образ за допомогою команди docker history . Наприклад:
Важливо про це сказати для розуміння того, що за своєю суттю кожен образ – це набір образів. Кожна зміна образу (кожна нова команда в докерфайлі) створює новий шар, який має власний ID. Докладніше про шари можна прочитати в документації " Docker: Images and Layers ". Так само дуже рекомендую до ознайомлення статтю на хабрі: " Образи та контейнери Docker у картинках ".
Висновок
Сподіваюся, цей невеликий огляд був достатнім, щоб зацікавити контейнерування. Нижче наведено посилання на додатковий матеріал, який може бути корисним:
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ