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


15

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

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

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

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


1
Вони не є взаємовиключними, ви можете розгорнути дебютний пакет у контейнері Docker. Можливо, вам слід запитати про Microservices vs Virtual Machines?
Кріс

Хм, ні, це стосується конкретного використання деб-пакету замість докерного контейнера. Я додам більше інформації з блогу до питання.
аві

3
"Ми вважали, що модернізувати ядро ​​просто для швидшого надсилання коду - це рішення надмірної кількості". це просто звучить для мене неправильно. що може бути важливіше, ніж швидкість доставки?
Ассаф Лав'є

Відповіді:


16

По-перше, хоча 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 або деякою системою управління конфігурацією, якщо ви змішування програмного забезпечення різного походження.


6

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

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

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

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


Ні, ніхто не пропонував використовувати рубін, вузол, пітон тощо. Ви також робите пакети з них і вкладаєте їх у / opt. Ваші пакети будуть залежати від них. Ви можете абсолютно встановити декілька версій свого додатка з деб-пакетами, у самому Debian є багато прикладів. Насправді це найкращий спосіб управління кількома версіями. Ця відповідь абсолютно неправильна.
figtrap

1
@figtrap ОК, спробуйте використовувати офіційну програму elastika.co repo та встановити паралельно еластичний пошук v. 2.3 та v. 5.6. Те, що ви описуєте, - це встановлення двох різних пакетів і велике налаштування, якщо ви робите належні пакети .deb. Це кошмар в термінах залежностей від побудови, а також у обслуговуванні, коли вам потрібні дві різні версії libc десь у глибині стека.
Тенсібай

5

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

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

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

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

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

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


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

1

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.