- Питання дещо складніше, ніж «куди поміститься більше додатків»
- Проблема контейнерів № 1: безпека
- Інші проблеми контейнерів
- непростий вибір
Питання дещо складніше, ніж «куди поміститься більше додатків»
Назвіть будь-яку технологічну компанію, і можна буде з упевненістю сказати, що вона теж інвестує в контейнери. Google - звичайно. IBM - так. Microsoft - безумовно. Але той факт, що контейнери зараз неймовірно популярні, ще не робить віртуальні машини застарілими. Адже це зовсім не так.
Так, контейнери дозволяють вмістити набагато більше додатків на одному фізичному сервері, ніж будь-яка віртуальна машина. Технології контейнеризації на кшталт Docker в цьому плані легко кладуть на лопатки VM.
Віртуальні машини займають багато системних ресурсів. Кожна з них містить не тільки операційну систему, але і необхідне для роботи віртуальне обладнання. А це відразу забирає досить багато оперативної пам'яті і процесорних циклів. З контейнером ситуація зовсім інша - в ньому можна розмістити тільки додаток і необхідний мінімум системних бібліотек для виконання; на це піде мінімум ресурсів.
На практиці це означає, що при використанні контейнерів ви зможете розмістити в два-три рази більше додатків на одному сервері. Крім того, контейнеризація дозволяє створювати портативний і цілісне оточення для розробки, тестування та подальшого розгортання.
Якби наше порівняння на цьому закінчувалося, впору було б писати некролог для класичної віртуалізації. Але питання все ж дещо складніше і ширше, ніж «куди поміститься більше додатків».
Проблема контейнерів № 1: безпека
Це найсерйозніша проблема, яка, однак, часто не береться до уваги. Деніел Уолш, інженер з безпеки з Red Hat, опублікував статтю « порожні контейнери ». Там розглядається Docker, який використовує libcontainers в якості основи. Libcontainers взаємодіє з п'ятьма просторами - Process, Network, Mount, Hostname, Shared Memory - при роботі з Linux. При цьому є безліч важливих підсистем ядра Linux поза контейнера.
До них відносяться всі пристрої, SELinux, Cgroups і вся файлова система всередині / sys. Це означає, що при наявності у користувача або додатки прав суперкористувача в контейнері операційна система може бути зламана. І це погано.
Є багато способів убезпечити Docker і інші технології контейнеризації. Наприклад, можна змонтувати / sys тільки для читання, змусити процеси контейнерів працювати з певними розділами файлової системи і налаштувати мережу так, щоб можна було підключатися лише до певних внутрішнім сегментам. Але нічого з цього за замовчуванням не зроблено, і вам доведеться додатково потурбуватися цими питаннями.
В якості базового правила можна порекомендувати ставитися до контейнерів так само, як ви ставитеся до будь-якого серверного додатку. Ось що радить Уолш:
- Видаліть привілеї якомога швидше.
- Запускайте служби без прав root всюди, де це можливо.
- Ставтеся до прав root в контейнері так, як якщо б вони діяли і поза ним.
Інша проблема полягає в тому, що контейнеризовано додатки випускає хто завгодно. І серед розробників завжди знайдуться «погані хлопці». Якщо, наприклад, ви або ваші співробітники досить ліниві, щоб запустити на сервері перший-ліпший контейнер, то цілком можете отримати трояна. Важливо донести до співробітників думка, що не можна просто завантажити будь-які додатки з Інтернету так само, як вони це роблять на своїх смартфонах.
Взагалі, на смартфони теж не варто ставити що попало, але це вже зовсім інша історія.
Інші проблеми контейнерів
Виходить, якщо вирішити питання безпеки, то контейнери будуть відмінним вибором? Не зовсім. Варто задуматися і про інші аспекти.
Роб Хиршфельд, генеральний директор RackN, зазначив наступне: «Ідея« ізольованою коробки »допомагає вирішити частину проблем з нижчими системами (ви знаєте, що у вас там є), але ніяк не з вищестоящими (ви не знаєте, від чого залежите)».
Поділ системи на безліч більш дрібних окремих частин - хороша ідея. Але це означає і те, що управляти доведеться ЩЕ ВЕЛИКИМ числом елементів. Завжди існує якась переломна точка між декомпозицией і неконтрольованим розростанням.
Роб Хиршфельд, генеральний дир Ектор RackN
Тут я хотів би додати, що це не тільки проблема безпеки, але і проблема забезпечення якості. Можна сказати, що X контейнерів в змозі підтримувати веб-сервер NGINX, але чи достатньо вам цього? Включений в таке рішення заодно і оновлений балансувальник TCP? Розгорнути додаток в контейнері досить легко, але якщо помилитися з вибором компонентів, то ви просто витратите час даремно.
Хиршфельд також вказує на серйозність проблеми розростання числа контейнерів. Варто пам'ятати про те, що «Поділ системи на безліч більш дрібних окремих частин - хороша ідея. Але це означає і те, що управляти доведеться ЩЕ ВЕЛИКИМ числом елементів. Завжди існує якась переломна точка між декомпозицией і неконтрольованим розростанням ».
Пам'ятайте: вся суть контейнера полягає в запуску одного ізольованого додатки. Чим більше завдань ви призначаєте на контейнер, тим вище ймовірність того, що їх варто було вирішувати за допомогою віртуальних машин.
Вірно, деякі технології контейнеризації начебто Linux Containers (LXC) можуть використовуватися замість VM. Наприклад, LXC можна використовувати для запуску певних програм Red Hat Enterprise Linux (RHEL) 6 на екземплярі RHEL 7. Але якщо говорити в загальному, то для запуску однієї програми підходять контейнери, а для кількох краще використовувати віртуальні машини.
непростий вибір
Так що ж вибрати - VM або контейнери? Якщо потрібно запустити кілька копій однієї програми, скажімо MySQL, то використовуйте контейнер. Якщо потрібна б про більша гнучкість при роботі декількох програм - задійте віртуальну машину.
Крім того, контейнери зазвичай прив'язують до певної версії операційної системи. Це буває корисно: немає необхідності турбуватися про залежності, якщо додаток коректно працює в контейнері. Але натомість ви отримуєте додаткові обмеження. З віртуальними машинами не важливо, який гипервизор використовується (KVM, Hyper-V, vSphere, Xen), - швидше за все, ви зможете запустити там будь-яку ОС. Немає проблеми запустити в VM специфічне додаток, що працює тільки на QNX. Але реалізувати це з нинішнім поколінням контейнерів стає не просто.
Отже, підсумуємо:
- Необхідно запускати максимум додатків на мінімальній кількості серверів? В такому випадку ви напевно скористаєтеся контейнерами. Але пам'ятайте про необхідність додатково подбати про безпеку.
- Якщо ж потрібно виконувати безліч додатків і / або підтримувати різні ОС - краще підійдуть віртуальні машини. І якщо питання безпеки для вашої організації стоїть на першому місці, то теж краще залишитися при VM.
- Вважаю, більшість з нас будуть використовувати контейнери спільно з віртуальними машинами як в хмарах, так і у власних ЦОД. Адже відкриваються контейнерами можливості економії на масштабі дуже значні, щоб їх ігнорувати. А у віртуальних машин як і раніше є чимало переваг.
У міру «дорослішання» технології контейнеризації нас чекає таке майбутнє, де контейнери і віртуальні машини спільно становитимуть гнучку і портативну хмарну середу. До цього ще далеко, але світло в кінці тунелю вже видніється.
Даний матеріал є приватною записом члена спільноти Club.CNews.
Редакція CNews не несе відповідальності за його зміст.
Включений в таке рішення заодно і оновлений балансувальник TCP?
