Чи є недоліки використання пакету deb, як якщо б це контейнер для розгортання програми?

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

Я отримав цю ідею від читання цього блог тут , що робить деякі хороші аргументи для використання пакета DEB для існуючих раніше додатків пітона. Основним моментом цього привабливого для нас блогу є питання підтримки екосистеми Docker (обмін портами, дозволи, розміщення Docker Images тощо).

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

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

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

Можливою відповіддю буде те, що якщо ви готові написати пакет Debian для своєї програми, ви також можете використовувати Docker для розгортання програми. Цього можна досягти за допомогою сценарію конфігурації, apt_setup.shякий би виглядав так

apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF

cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF

і Dockerfileпо лінії

ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package

(У вашій конкретній ситуації це apt_setup.shбуде складніше, додавши сховища вузлів і деякі допоміжні пакети, такі як apt-transport-https .)

Тому дійсно можливо одночасно використовувати пакети Debian та Docker ...

Моя кишка […] говорить мені, що якби деб-пакети добре підходили, це було б частіше

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

"Офіційна" система упаковки з даного розповсюдження - це лише можливість багатьох інших встановити програмне забезпечення в якомусь обчислювальному середовищі. Є багато інших джерел, таких як менеджери пакунків, характерні для спільноти, такі як npm чи opam, дерева портів, такі як pkgsrc та звичайний розподіл вихідного коду. З цього погляду легко зрозуміти успіх Docker як спеціальної системи пакування:

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

• Докер має "вбудовану" (платну) послугу розміщення виробів, які він виробляє, Docker Hub .

Тепер яка сила пакетів Debian над зображеннями Docker як пакетної системи? Жорсткий контроль над залежностями при установці. (Можливість оновлення та поновлення також існує, але не має практичного значення, якщо ми реалізуємо шаблон непорушного сервера .) Це призводить до

Висновок

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

Так, є недоліки.

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

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

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

Пакет Debian (або RedHat) для встановлення програм був гарною практикою, коли це зроблено правильно. Пакети використовуються для розгортання програм, які нечасто змінюються. Пакети Debian включають деякі накладні витрати, такі як управління версіями, управління залежностями, сценарії попереднього та після встановлення тощо ...

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

Після того, як ви вирішите повністю замінити конфігурацію або залежності або додаток для кожного розгортання, оскільки це легше і менш схильне до помилок. Більшість організацій (раніше) переходили на цілком новий VM або хмарний примірник. Що означає, що встановлення пакета здійснювалося б на "чистому" сервері, а мутація файлів та конфігурації на сервері вже не є проблемою.

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

Заміна VM є неоптимальною, коли все, що вам потрібно, - це замінити додаток, саме тому легкі контейнери були введені як відповідь. За допомогою Docker (або іншого LWC) ви можете замінити базу користувачів, включаючи всі залежності, не замінюючи сам сервер. Ви також можете розміщувати кілька версій однієї програми, з різними залежностями, на одному сервері і лише перемикати вхідний мережевий трафік на оновлення. Крім того, щоб повернути мережевий трафік на відкат (синьо-зелений), що було надзвичайно важко у випадку управління розгортаннями через пакети.

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

Якщо говорити спеціально про упаковку зображення Docker, то не час виконання контейнера є кілька незначних біт. Найбільшим є те, що зображення Docker більше схоже на chroot, а це означає, що ви не можете випадково залежати від спільного стану системи, оскільки кожен використовуваний файл повинен бути явно включений у зображення, тоді як системний пакет може підбирати динамічні посилання, які ви не зробили очікуйте або іншим чином переплутайтеся з іншими пакетами. Це може створити складні залежності C, що завантажуються без вашого відома, наприклад, OpenSSL. Крім того, використовуючи пакети deb, не повторюйте спільні біти в системі зберігання даних Docker. Для деяких це може бути хорошою справою, кращою продуктивністю вводу / виводу та меншою кількістю рухомих фрагментів, але для інших це може бути проблемою.