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

Docker складається з кількох компонентів:

1. Образ— сконфігурований розробниками набір ПЗ, що завантажується з офіційного сайту
2. Контейнер- імплементація образу - сутність на сервері, створена з нього, контейнер не повинен бути точною копією і може бути скоригований за допомогою Dockerfile
3. Volume— область на диску, яку використовує контейнер і зберігаються дані. Після видалення контейнера ПЗ не залишається, дані можуть використовуватися в майбутньому

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

Docker керування контейнерами: базові можливості

Встановимо Docker на Ubuntu або Debian сервер, якщо він ще не встановлений за інструкцією. Найкраще виконувати команди від імені непривілейованого користувача через sudo

Запуск найпростішого контейнера покаже, що все працює

Базові комагди для керування контейнерами

Вивести всі активні контейнери можна так

З ключем -a будуть виведені всі контейнери, у тому числі неактивні

Dicker призначає імена контейнерам випадковим чином, за необхідності можна вказати ім'я безпосередньо

docker run -name hello-world

Запускаємо контейнер з ім'ям my-linux-container на основі образу ubuntu і переходимо в консоль контейнера, вказуючи оболонку bash

docker run -it -name my-linux-container ubuntu bash

Щоб вийти з контейнера та знову опинитися на хост системі потрібно виконати

Всі образи, на основі яких створюються контейнери, завантажуються з hub.docker.com автоматично при першому створенні контейнера, ті, що вже існують локально, можна побачити, виконавши docker images

Створення контейнера з вже скачаного образу відбуватиметься значно швидше (майже миттєво)

При виході з контейнера з exit він зупиняється, щоб цього не відбувалося можна поєднанням клавіш CTRL+A+P

Можна прибрати всі контейнери, які не є активними

docker rm $(docker ps -a -f status=exited -q)

Або видаляти їх по одному

Замість ідентифікатора в останній команді можна вказати ім'я

У docker керування контейнерами проводиться за рахунок невеликої кількості інтуативно зрозумілих команд:

docker container start ID

docker container stop ID

docker container restart ID

docker container inspect ID

Остання особливо корисна, вона виводить всю інформацію про контейнер, конфігураційні файли і використовувані розділи диска. Весь список команд можна легко знайти у допомозі або на офіційному сайті Docker

Створення свого образу Docker та використання Dockerfile

Образи зазвичай створюються з уже існуючих за рахунок використання додаткових опцій, зазначених у Dockerfile

FROM ubuntu
CMD echo "hello world"

Зараз створюється новий образ на основі стандартного с ubuntu

Збираємо образ, давши йому ім'я (точка в кінці команди означає, що використовується поточний каталог, а значить і Dockerfile в ньому)

docker build -t my-ubuntu.

docker imagesтепер покаже і створений щойно образ my-ubuntu

Його можна запустити, у консоль при цьому буде виведено hello world і це єдина відмінність від дефолтного образу

Зазвичай потрібні складніші правила, наприклад, в образ нам потрібно включити python3 - перейдемо в новий каталог і створимо Dockerfile

FROM ubuntu
CMD apt-get update && apt-get install python3

Усі інструкції записуються в один рядок

docker build -t my-ubuntu-with-python3 .

Запускаємо контейнер, переходячи всередину

docker run -it my-ubuntu-with-python3 bash

Всередині від імені root потрібно виконати dpkg-l | grep python3, команда покаже, що пакет присутність в системі, що означає успіх

Усередині Docker тільки Linux, та, експериментально, FreeBSD. Запускається нативно під Linux і, експериментально, під FreeBSD. Під MacOSX, Windows – через віртуальну машину.

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

Це майже віртуальна машина. Майже, та не зовсім.

Є таке поняття "пекло залежностей". Будь-яке ПЗ встановлюється на комп'ютер, тягне за собою залежності(Конфігураційні файли, статичні файли звані зазвичай asset, допоміжні утиліти/сервіси, бібліотеки та ін.). Ряд із цих бібліотек/утиліт/сервісів несумісний один з одним.А з огляду на те, що кожна з цих бібліотек/утиліт/сервісів має і свої залежності - ситуація ще гірша.

Наприклад, ми використовуємо Yandex.Cocaine, яка нормально компілюється лише на Ubuntu 14.04 (і, начебто, на Debian 7). Але не під CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 та ін. скомпілювати його неможливо. Запускаємо у цих операційних системах у Докері.

З іншого боку, і водночас, вам необхідно встановити інше, більш сучасне ПЗ. І водночас старіше. Причому навіть не йдеться про версії Linux, що серйозно відрізняються. Наприклад, одне ПЗ вимагає не менше Ubuntu 14.10, а інше не більше Linux 14.04.

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

Таким чином, ми маємо бінарний файл, що запускається як би у своїй операційній системі.

Ви можете сказати - ба, та це ж давно відома віртуальна машина. Але ж ні, це не так.Це так звані контейнери. Жодною віртуальною машиною там і не пахне. За винятком Windows та MacOSX,де робота без віртуальної машини поки що експериментально можлива тільки, а нормою в цих ОС є використання Докера всередині повноцінної віртуальної машини.

Але віртуальні машини з Докер використовуються тільки для розробки. Для запуску в production віртуальні машини з Докер не використовуються.

Докер використовує контейнери для операційної системи. LXC у Linux, Jails у FreeBSD. Контейнер – це область операційної системи, ізольована від основної частини операційної системи. У контейнері своє дерево каталогів (включаючи системні /dev, /bin, /sbin та ін.), свої мережеві порти та ін.

Але при цьому не використовується повна віртуалізація. Що суттєво економить ресурси. Запустити 100 повноцінних віртуальних машиннавряд чи вийде навіть потужному сервері. А от запустити 100 контейнерів Docker навіть на слабкому домашньому комп'ютері – можливо.

Щоправда, використання не повної віртуалізації обмежує використання операційних систем усередині контейнерів. Як правило, це спеціально підготовлені версії Linux чи FreeBSD. Саме спеціально підготовлені. Windows – у принципі в контейнері запустити неможливо.

Контейнери існували до Docker. Докер, строго кажучи, це всього лише дуже зручний набір інструментів, зібраних воєдино, для керування контейнерною віртуалізацією Але дуже зручний.

Для чого це використовується?

Хлопці з усіляких Dropbox, Facebook та ін гігантах, що запускають по 1 млн. різних програм у своїх сервісах, зіткнулися, що неможливо скрізь гарантувати ідентичні налаштування операційної системи.А це критично.

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

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

Більш того - спочатку розробник програмного забезпечення тестує програму в контейнері Докер, з певними налаштуваннями. І в цьому ж (або з такими ж налаштуваннями) контейнері Докера програма їде на сервер.

Це дозволяє гарантувати набагато більшу ідентичність середовища розробки та середовища виконання.

До цього люди мучилися, вигадували хитрі інсталятори.

Потім плюнули на спроби впорядкувати оточення в ОС- і зараз концепція така - встановлювати програми на сервері разом зі своїми індивідуально налаштованими під них операційними системами- тобто усередині контейнерів. 1 контейнер = 1 налаштування ОС = 1 програма всередині.

Іншими словами:

• Докер-контейнер слід використовувати для налагодження.
• Той самий Докер-контейнер потрібно використовувати і на сервері.

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

Докер застосовується до створення/налаштування тільки серверного програмного забезпечення під Linux(Експериментально під FreeBSD). Чи не для смартфонів. А якщо десктопів – то лише програмне забезпечення без GUI.

Оскільки Докер дозволив одним махом спростити роботу розробникам та адмінам та підвищити якість результату- зараз бум на Докер. Придумано величезна гора інструментів для управління розгортанням додатків, створених з Докером. Якщо раніше щоб запустити 10 000 програм на 1000 серверах потрібно було як мінімум 3 висококваліфікованих девопса, які писали купу описів якце зробити на Puppet, Salt, Chef, Ansible, та й то не було гарантій, це все тестувалося місяцями. То зараз з Докером навіть один кваліфікований девопс може керувати мільйонами програм на десятках тисяч серверів. З куди більшою гарантією, що все це заведеться нормально.

Може скластися помилкове враження, що розробник готує контейнери до Докер, а потім передає їх адміну.
Правильна методологія все ж таки інша:

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

Тобто за правильної обмеження справи розробник неспроможна/не повинен впливати те, який буде образ.
А ось у тестовому середовищі (запускається на сервер, недоступному розробнику у великих командах) і в production використовується один і той самий образ.

Основна ідея - що тестували, як і запускаємо на бойовому сервері. Один-в-один, включаючи ті ж файли (Не такі ж, а саме ті ж самі).

Ми не раз торкалися тематики і розглядали безліч систем для їх побудови. Сьогодні ми познайомимо з однією чудовою системою контейнерами Docker.

Почнемо з того, що опишемо базовий функціонал, який стане в нагоді в подальших статтях циклу, і коротко нагадаємо про архітектуру Docker. Docker використовує клієнт-серверну архітектуру та складається з клієнта – утиліти docker, яка звертається до сервера за допомогою RESTful API, і демона в операційній системі Linux (див. рис. 1). Хоча Docker працює і на відміну від Linux ОС, у цій статті вони не розглядаються.

Основні компоненти Docker:

• Контейнери– ізольовані за допомогою технологій операційної системи користувацькі оточення, в яких виконуються програми. Найпростіше дати визначення контейнеру Docker як запущеному з образу додатку. До речі, саме цим ідеологічно і відрізняється Docker, наприклад, від LXC ( Linux Containers), хоча вони використовують ті самі технології ядра Linux. Розробники проекту Docker сповідує принцип: один контейнер – це одна програма.
• Образи– доступні лише для читання шаблони програм. Поверх існуючих образів можуть додаватися нові рівні, які спільно становлять файлову систему, змінюючи або доповнюючи попередній рівень. Зазвичай новий образ створюється або за допомогою збереження вже запущеного контейнера новий образ поверх існуючого, або за допомогою спеціальних інструкцій для утиліти . Для розділення різних рівнів контейнера на рівні файлової системи можна використовувати AUFS, btrfs, vfs та Device Mapper. Якщо передбачається використання Docker спільно з SELinux, то потрібно Device Mapper.
• Реєстри (Registry), що містять репозиторії ( repository) образів, - мережеві сховища образів. Можуть бути як приватними, і загальнодоступними. Найвідомішим реєстром є.

Для ізоляції контейнерів в операційних системах GNU/Linux використовуються стандартні технології ядра Linux, такі як:

• Простір імен ( Linux Namespaces).
• Контрольні групи ( Cgroups).
• Засоби управління привілеями ( Linux Capabilities).
• Додаткові, мандатні системи безпеки, такі як AppArmor або SELinux.

Розглянемо перелічені технології трохи докладніше.

Механізм контрольних груп (Cgroups)надає інструмент для тонкого контролю за розподілом, пріоритизацією та управлінням системними ресурсами. Контрольні групи реалізовані у ядрі Linux. У сучасних дистрибутивах управління контрольними групами реалізовано через systemd, однак зберігається можливість керування за допомогою бібліотеки libcgroupта утиліти cgconfig. Основні ієрархії контрольних груп (їх також називають контролерами) перераховані нижче:

• blkio- задає ліміти на операції введення-виводу та доступ до блокових пристроїв;
• cpu- Використовуючи планувальник процесів, розподіляє процесорний час між завданнями;
• cpuacct– створює автоматичні звіти щодо використання ресурсів центрального процесора. Працює спільно з контролером cpu, описаним вище;
• cpuset– закріплює за завданнями певні процесори та вузли пам'яті;
• devices– регулює доступ завдань до певних пристроїв;
• freezer- Зупиняє або відновлює завдання;
• memory– встановлює ліміти та генерує звіти про використання пам'яті завданнями контрольної групи;
• net_cls– здійснює тегування мережевих пакетів ідентифікатором класу ( classid). Це дозволяє контролеру трафіку ( команда tc) та брандмауеру ( iptables) враховувати ці теги під час обробки трафіку;
• perf_event– дозволяє проводити моніторинг контрольних груп за допомогою утиліти perf;
• hugetlb– дозволяє використовувати віртуальні сторінки пам'яті великого розміру та застосовувати до них ліміти.

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

Приклади просторів імен, що використовуються Docker:

• PID, Process ID- Ізоляція ієрархії процесів.
• NET, Networking- Ізоляція мережевих інтерфейсів.
• PC, InterProcess Communication- Управління взаємодією між процесами.
• MNT, Mount- Управління точками монтування.
• UTS, Unix Timesharing System– ізоляція ядра та ідентифікаторів версії.

Механізм під назвою Capabilitiesдозволяє розбити привілеї користувача root на невеликі групи привілеїв та призначати їх окремо. Цей функціонал у GNU/Linux з'явився починаючи з версії ядра 2.2.Спочатку контейнери запускаються вже з обмеженим набором привілеїв.

За допомогою опцій команди docker можете дозволяти та забороняти:

• операції монтування;
• доступ до сокетів;
• виконання частини операцій із файловою системою, наприклад, зміна атрибутів файлів або власника.

Докладніше ознайомитися з привілеями можна за допомогою man-сторінки CAPABILITIES(7).

Установка Docker

Розглянемо інсталяцію Docker на прикладі CentOS. При роботі з CentOS у вас є вибір: використовувати останню версію з u pstreamабо версію, зібрану проектом CentOS із додатками Red Hat. Опис змін на сторінці.

В основному це зворотне портування виправлень з нових версій upstream та зміни, запропоновані розробниками Red Hat, але поки що не прийняті в основний код. Найбільш помітною відмінністю на момент написання статті було те, що у нових версіях сервіс docker був поділений на три частини: демон docker, containerd та runc. Red Hat поки не вважає, що ця зміна стабільна, і поставляє монолітний файл версії 1.10.

Налаштування репозиторію для встановлення upstream-версії, як і інструкції для інсталяції в інших дистрибутивах та ОС, наведені в посібнику з інсталяції на офіційному сайті . Зокрема, налаштування для репозиторію CentOS 7:

# cat /etc/yum.repos.d/docker.repo name=Docker Repository baseurl=https://yum.dockerproject.org/repo/main/centos/7 enabled=1 gpgcheck=1 gpgkey=https://yum .dockerproject.org/gpg

Встановлюємо необхідні пакети на та запускаємо та включаємо сервіс:

# yum install -y docker-engine # systemctl start docker.service # systemctl enable docker.service

Перевіряємо статус сервісу:

# systemctl status docker.service

Також можна переглянути системну інформацію про Docker та оточення:

При запуску аналогічної команди у разі встановлення Docker з репозиторіїв CentOS побачите незначні відмінності, зумовлені використанням старішої версії програмного забезпечення. З висновку docker infoможемо дізнатися, що як драйвер для зберігання даних використовується Device Mapper, а як сховище – файл у /var/lib/docker/:

# ls -lh /var/lib/docker/devicemapper/devicemapper/data -rw-------. 1 root root 100G Dec 27 12:00 /var/lib/docker/ devicemapper/devicemapper/data

Опції запуску демона, як це зазвичай буває в CentOS, зберігаються в /etc/sysconfig/. В даному випадку ім'я файлу docker. Відповідний рядок /etc/sysconfig/docker, що описує опції:

OPTIONS="--selinux-enabled --log-driver=journald"

Якби ви запустили команду docker не користувачем root і не користувачем, що входить до групи docker, ви побачили б подібну помилку:

$ docker search mysql

Warning: failed to get default registry endpoint from daemon (Cannot connect to the Docker daemon. Is the docker daemon running on this host?). Using system default: https://index. docker.io/v1/

Cannot connect to the Docker daemon. Is the docker daemon running on this host?

Зверніть увагу, що фактично включення користувача до групи docker рівносильне включенню цього користувача до групи root.

У розробників RHEL/CentOS дещо інший підхід до безпеки демона Docker, ніж у розробників самого Docker з upstream. Докладніше про підхід Red Hat написано у статті розробника дистрибутива RHEL Дена Волша.

Якщо ж ви хочете «стандартну» поведінку Docker, встановленого з репозиторіїв CentOS (тобто описане в офіційній документації), необхідно створити групу docker і додати в опції запуску демона:

OPTIONS="--selinux-enabled --log-driver=journald ↵ --group=docker"

Після цього рестартуємо сервіс і перевіряємо, що файл сокету docker належить групі docker, а не root:

Пошук образів та теги Docker

Спробуймо знайти контейнер на Docker Hub.

$ docker search haproxy

У цьому висновку ми одержали список ряду образів HA Proxy. Найвищий елемент списку – це HA Proxy із офіційного репозиторію. Такі образи відрізняються тим, що в імені немає символу «/» , що відокремлює ім'я репозиторію користувача від імені самого контейнера. У прикладі за офіційним показано два образи haproxy з відкритих репозиторіїв користувачів eeacms та million12.

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

• Це рекомендовані до використання образи, створені з урахуванням найкращих рекомендацій та практик.
• Вони є базовими образами, які можуть стати відправною точкою для більш тонкого налаштування. Наприклад, базові образи Ubuntu, CentOS або бібліотек та середовищ розробки.
• Містять останні версії програмного забезпечення з усуненими вразливістю.
• Це офіційний канал розповсюдження продуктів. Щоб шукати лише офіційні образи, можете використати опцію -filter "is-official=true"команди docker search.

Число зірок у виведенні команди docker searchвідповідає популярності образу. Це аналог кнопки Likeу соціальних мережах або закладок для інших користувачів. Automatedозначає, що образ збирається автоматично із спеціального сценарію засобами Docker Hub. Зазвичай слід віддавати перевагу образам, що автоматично збираються внаслідок того, що його вміст може бути перевірено знайомством з відповідним файлом .

Завантажуємо офіційний образ HA Proxy:

$ docker pull haproxy Using default tag: latest

Повне ім'я образу може виглядати так:

[ім'я користувача]ім'я образу[:тег]

Переглянути список завантажених образів можна командою docker images:

Запуск контейнерів

Для запуску контейнера не обов'язково заздалегідь завантажувати образ. Якщо він доступний, то буде завантажено автоматично. Давайте спробуємо запустити контейнер з Ubuntu. Ми не будемо вказувати репозиторій, і буде завантажено останній офіційний образ, підтримуваний Canonical.

$ docker run -it ubuntu [email protected]:/#

Крім команди run, ми вказали дві опції: -i– контейнер повинен запуститися в інтерактивному режимі та -t- Повинний бути виділений псевдотермінал. Як видно з висновку, у контейнері маємо привілеї користувача root, а як ім'я вузла відображається ідентифікатор контейнера. Останнє може бути справедливим не для всіх контейнерів і залежить від розробника контейнера. Перевіримо, що це дійсно оточення Ubuntu:

[email protected]:/# cat /etc/*release | grep DISTRIB_DESCRIPTION DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"

Команду uname -aдля таких цілей використовувати не вийде, оскільки контейнер працює з ядром хоста.

Як одна з опцій можна було б задати унікальне ім'я контейнера, на яке можна для зручності посилатися, крім ID-контейнер.Вона задається як -name<имя>. Якщо опція опущена, ім'я генерується автоматично.

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

Подивитися список запущених контейнерів можна командою. Для цього відкриємо другий термінал:

Однак якщо віддати команду контейнера, створеного з образу mysql, ми не виявимо. Скористаємося опцією -a, яка показує всі контейнери, а не лише запущені:

Очевидно, що при запуску контейнера не було вказано обов'язкових параметрів. Ознайомитися з описом змінних середовища, необхідних для запуску контейнера, можна знайти офіційний образ MySQL на Docker Hub. Повторимо спробу, використовуючи опцію -eяка задає змінні оточення в контейнері:

$ docker run --name mysql-test ↵ -e MYSQL_ROOT_PASSWORD=docker -d mysql

Останнім параметром виступає команда, яку хочемо виконати всередині контейнера. У цьому випадку це командний інтерпретатор Bash. Опції -itаналогічні за призначенням використаним раніше у команді docker run.

Фактично після запуску цієї команди у контейнер mysql-testдодається ще один процес – bash. Це можна побачити за допомогою команди pstree. Скорочений висновок до команди docker exec: