Есть ли недостатки использования пакета deb, как если бы это был контейнер для развертывания приложения?

Моя команда в настоящее время пытается решить, следует ли нам развертывать наше приложение Nodejs как пакет deb, вместо того, чтобы пытаться запустить его в контейнере, таком как Docker.

Я получил эту идею от чтения этого блог здесь , что делает некоторые хорошие аргументы для использования пакета DEB для существующих ранее приложений питона. Основным моментом этого блога, который нам интересен, является вопрос поддержки экосистемы Docker (совместное использование портов, разрешения, размещение образов Docker и т. Д.)

Похоже, что «деппакеты как исходные контейнеры» имеют большой смысл для небольших сервисов, где нет проблем с конфликтами портов и где все зависимости поддерживаются в виртуальной среде.

Однако я хочу сказать, что если бы пакеты deb подходили друг другу, это было бы более распространенным явлением, и докер был бы объявлен как более специфичное для языка решение. Есть ли какие-либо недостатки использования чего-то вроде пакетов deb для развертывания наших сервисов вместо использования полной системы, такой как docker?

Во-первых, хотя 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 одновременно, однако…

Моя интуиция […] говорит мне, что если бы пакеты deb были подходящими, это было бы более распространенным

Это правильная загвоздка, которая заставляет нас задаться вопросом: почему Docker пользуется популярностью как специальная система упаковки, а не таковой? (См. Выше.)

«Официальная» система упаковки из данного дистрибутива просто возможность среди многих других установить программное обеспечение в некоторой вычислительной среде. Существует множество других доступных источников, таких как менеджеры пакетов, относящиеся к сообществу, такие как npm или opam, деревья портов, такие как pkgsrc, и распространение простого исходного кода. С этой точки зрения легко понять успех Docker как специальной системы упаковки:

• Спецификации Docker очень близки к сценарию оболочки, и из какого бы источника он ни исходил, мы устанавливаем программное обеспечение с помощью оболочки.

• Docker имеет «встроенный» (платный) сервис для размещения артефактов, которые он производит, Docker Hub .

Каковы же преимущества пакетов Debian над образами Docker как системы пакетов? Жесткий контроль над зависимостями при установке. (Возможность обновления и понижения также существует, но не имеет практического значения, если мы реализуем шаблон неизменяемого сервера .) Это приводит к

Вывод

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

Да, есть недостатки.

С пакетом .deb вы не сможете иметь две версии одного и того же приложения на одном хосте. Вам придется полагаться на доступные пакеты распространения, например, если ваше приложение использует nodejs, либо вы застряли с версией распространения, либо вам придется установить свою собственную.

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

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

Пакет Debian (или RedHat) для установки приложений является хорошей практикой, если все сделано правильно. Пакеты используются для развертывания приложений, которые редко меняются. Пакеты Debian включают в себя некоторые накладные расходы, такие как управление версиями, управление зависимостями, сценарии до и после установки и т. Д.

Во многих случаях обновление с более старой версии до новой версии требует тщательного написания сценариев, внимания к деталям в версии и т. Д. Поскольку изменение существующего состояния затруднительно. Было бы намного проще полностью заменить текущее состояние новым, не меняя ничего.

Как только вы решите полностью заменить свою конфигурацию или зависимости или приложение в каждом развертывании, потому что это проще и менее подвержено ошибкам. Большинство организаций (раньше) переходили на совершенно новую виртуальную машину или облачный экземпляр. Это означает, что установка пакета будет выполняться на «чистом» сервере, и изменение файлов и конфигурации на сервере больше не является проблемой.

Те разработчики, которые создавали пакеты и не понимали ошибочность и сложность мутаций, в результате испытали немало трудностей.

Замена ВМ является неоптимальной, когда все, что вам нужно, это заменить приложение, поэтому в качестве ответа были представлены легкие контейнеры. Используя Docker (или другой LWC), вы можете заменить пользовательскую базу, включая все зависимости, без замены самого сервера. Вы также можете разместить несколько версий одного и того же приложения с разными зависимостями на одном сервере и переключать входящий сетевой трафик только при обновлении. А также переключить сетевой трафик на откат (сине-зеленый), что было особенно сложно в случае управления развертываниями через пакеты.

Контейнеры представляют способ объединения всего кода приложения, а также зависимостей и конфигурации в образ. Этот образ имеет несколько свойств, которые делают его намного лучше, чем традиционные пакеты операционной системы. Например, у него есть теги, которые позволяют управлять версиями, но также есть слои, которые позволяют экономить место. Он позволяет легко отправлять эти образы на серверы и в среды разработки с помощью реестра. И эти образы могут быть выполнены как контейнеры в любой среде и на любом сервере, практически одинаково. Это включает в себя ноутбук разработчика, а также производственную среду. Опять же, кое-что, что было намного сложнее сделать с виртуальными машинами и / или с версиями программного обеспечения на основе пакетов. Тестирование одного и того же изображения на ноутбуке разработчика и сохранение тех же самых битов и байтов в производстве устраняет многое »

Говоря конкретно об элементе упаковки изображений Docker, а не о времени выполнения контейнера, есть несколько незначительных моментов. Самое главное, что образ Docker больше похож на chroot, что означает, что вы не можете случайно зависеть от общего состояния системы, поскольку каждый используемый файл должен быть явно включен в образ, в то время как системный пакет может получать динамические ссылки, которые вы не делали. ожидать или иначе стать более переплетенными с другими пакетами. Это может привести к сложным зависимостям C, загружаемым без вашего ведома, например, OpenSSL. Кроме того, использование пакетов deb не приводит к дублированию общих битов в системе хранения Docker. Для некоторых это может быть хорошо, лучшая производительность ввода-вывода и меньше движущихся частей, но для других это может быть проблемой.