Подходит ли Docker для моего варианта использования?

У моей компании есть система, которую мы продаем и которая состоит из мини-компьютера Smartbox, работающего под управлением Ubuntu 12.04. В этом окне запускается приложение Django, а также ряд связанных с ним различных процессов запуска. Не намного больше. У нас есть тысячи таких коробок на поле. Мы управляем зависимостями пакетов, регистрируем процессы и т. Д. С помощью пакета deb с разной степенью успеха.

Нам нужен способ эффективно и надежно распространять обновления для наших пользователей на местах. Нам также нужно что-то, что, когда мы обновляем ОС (мы, как вы можете сказать, запоздали с обновлением Ubuntu), мы можем чувствовать себя относительно безопасными в том, что наши пакеты «только работают».

Я не знаю много о Docker, но когда я впервые услышал о нашей проблеме (я новый сотрудник), Docker был моей первой мыслью. Но чем больше я думал об этом, я чувствовал, что, возможно, это не так, поскольку эти блоки являются нашими, мы контролируем ОС на них, что является большой частью ценностного предложения Docker, или, насколько я понимаю. Так что, если мы ЗНАЕМ, что наши блоки всегда будут Ubuntu, и у нас будет просто приложение Django плюс несколько процессов для запуска, лучше ли Docker, чем пакет deb?

TL; DR: Docker против пакетов deb для распределенного устройства, которое всегда будет запускать Ubuntu, поэтому независимость от платформы не так важна.

Я не уверен на 100%, что понимаю из вопроса, но похоже, что решение Docker будет состоять в том, чтобы перейти от (физического?) Устройства с ОС и установленным на нем приложением к устройству с ОС и Docker на нем, запустив один контейнер с вашим приложением в нем. Это не избавляет от необходимости обновлять ОС на хосте и добавляет уровень сложности (и больше обновлений, с которыми приходится бороться, так как теперь вам придется поддерживать Docker и исправления ОС) без очевидного преимущества что касается конкретных областей, упомянутых в вопросе.

Однако, если вы говорите о переходе от виртуального устройства к контейнеру Docker, это может потенциально сгладить ситуацию для вас, но также добавляет Docker в качестве зависимости для вашего продукта; Вы не допускаете никого, кто не использует Docker и не хочет добавлять его в свой стек только для использования вашего продукта. Вы можете продолжить поддерживать тех, кто не / не использует Docker, продолжая поставлять (теперь уже «устаревшее») виртуальное устройство, как и раньше, но теперь вы только удвоили свою рабочую нагрузку, потому что у вас есть два дистрибутива для поддержки вместо один.

Я работал с Докером долгое время. Независимость от платформы хороша, но это не то, что я считаю наиболее полезным в Docker.

В первую очередь, вы получаете повторяемость. Вы можете создать Dockerfile, выполнить отладку в контейнере на компьютере разработчика, запустить тесты на сервере непрерывной интеграции, а затем в конечном продукте, и вы знаете, что он будет вести себя одинаково во всех этих средах. Не стоит забывать о зависимости, которую разработчик установил на свою машину. Кроме того, ваши разработчики не должны использовать Ubuntu на своем рабочем столе. Важно, чтобы мы были довольны пользователями Arch Linux :-)

Во-вторых, для вашего сценария обновления вы можете одновременно подключить несколько версий к одной машине. Если вы делаете какое- docker pull myapp:2.0то время 1.0, вы можете переключиться на 2.0очень быстро. Намного быстрее, чем полное обновление ОС. Если вы используете оркестратор с несколькими экземплярами микросервисов, вы можете даже выполнять непрерывные обновления, которые вообще не прерывают обслуживание.

Если вы используете модель микроуслуг, Docker также предоставляет «песочницы», которые могут ограничить количество урона, которое злоумышленники могут нанести в случае эксплойта. Вместо того, чтобы получить контроль над всей машиной, они получают контроль только над одним контейнером.

Основным недостатком является то, что вам нужна хост-ОС и какая-то оркестровка. Для этого есть много вариантов, но не стоит недооценивать объем работы, который требуется для его оценки, внедрения и поддержания.

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

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

Первый вопрос, который вы должны задать (вы сказали, что вы новичок): как теперь обрабатываются обновления ОС и приложения? Работает ли текущая методология для вас (вашей компании)? Что работает хорошо? Что можно улучшить? Можете ли вы провести аудит физической конфигурации на ваших целевых машинах в полевых условиях, чтобы убедиться, что на них установлены правильные исправления ОС, приложения и были ли внесены несанкционированные изменения.

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

Хотя есть несколько крошечных областей перекрытия, Docker и системы упаковки Debian по сути решают две очень разные проблемы :

• Система пакетов Debian создана для установки программного обеспечения на хост и его обновления как можно проще. Он способен обрабатывать сложные шаблоны зависимостей и ограничений между компонентами программного обеспечения, например «программное обеспечение X версии A требует программного обеспечения Y с установленной версией B или более новой» или «программное обеспечение X никогда не должно устанавливаться с программным обеспечением Z версии C».

• Система Docker предназначена для простого описания и развертывания сервисов, особенно микросервисов, возможно, на нескольких хостах - например, рое Docker или кластер Kubernetes.

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

Имея это в виду, мне кажется, что вы действительно ищете, чтобы реализовать шаблон неизменяемого сервера, Недавнее развитие облачных технологий сделало возможным обновление программного обеспечения не с помощью классической системы обновления программного обеспечения из системы пакетов программного обеспечения (такой как система пакетов Debian), а скорее путем простой замены полного сервера сразу. (Некоторые люди делали это до этой разработки, имея на сервере три ОС, две из которых использовались попеременно для запуска устройства, и мини-ОС, предназначенную для замены устройства. Несмотря на то, что это не слишком сложно, это, похоже, всегда оставалось Эта методика может быть интересна для вас, потому что, если вы используете для обновления программного обеспечения на вашем сервере с помощью диспетчера пакетов, конечное состояние сервера зависит от «истории обновления» сервера - особенно, если ошибки происходят в Процесс обновления. Эта неоднородность плохая,

У нас есть тысячи таких коробок на поле. Мы управляем зависимостями пакетов, регистрируем процессы и т. Д. С помощью пакета deb с разной степенью успеха.

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

Теперь существуют различные варианты реализации шаблона неизменяемого сервера, два популярных варианта - использовать образы Docker, изображения или «образы основного экземпляра» от вашего облачного провайдера (это называется AMI в AWS и просто пользовательские изображения в Google Compute Engine) , Ваш вариант использования запрещает использование облачных технологий, поэтому я буду считать изображения Docker единственным приемлемым выбором. (Для завершения, безусловно, можно использовать другие подходы, например, использование Virtual Box или аналогичного решения для виртуализации, в качестве альтернативы Docker.)

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

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

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

Я думаю, что это может быть хорошим вариантом (необходимы дальнейшие испытания)

Вы можете указать URL-адрес со всеми тегами / версией созданного вами контейнера, и клиенты прочитают этот URL-адрес, чтобы узнать, есть ли новая версия контейнера.

Вы можете хранить личные файлы / настройки локально, и вы никогда не потеряете эту информацию в обновлениях, и вы убедитесь, что то, что вы сделали и протестировали, будет работать для всех одинаково.

Даже вы могли бы дать пользователям возможность выбрать, какую версию из доступных они хотят использовать (если вы хотите предоставить такую ​​возможность).

Это будет похоже на "" только обновить один пакет "", говоря только о получении новой версии контейнера, гораздо лучше, чем при работе с пакетами debian;)

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

Соображения, которые вам необходимо учитывать, включают в себя хранение данных, поскольку контейнеры не сохраняют изменения при перезапуске, поэтому вам нужен объем данных. Вероятно, у вас будет гораздо больше соображений, если вы начнете копаться в этом. Система, с которой я сейчас работаю (все на основе докера), находится в разработке уже более года, и мы все еще находим области, в которых нам нужно внести изменения в контейнер, конфигурации и т. Д.