Подходит Ли 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. Независимость от платформы — это хорошо, но я не считаю это самым полезным в Docker.

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

Во-вторых, для вашего сценария обновления вы можете одновременно загрузить на компьютер несколько версий. Если вы сделаете 2.0 while 1.0 работает, вы можете переключиться на docker pull myapp:2.0 extremely quickly. Much faster than doing a full OS upgrade would normally take. If you use an orchestrator with multiple instances of microservices, you can even do rolling upgrades that don't interrupt service at all.

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

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

В целом докер предоставляет множество преимуществ как разработчикам, так и эксплуатационному персоналу. Я использую 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 кажется мне разумным, поскольку вы можете внести и протестировать изменения в контейнере самостоятельно, а затем, в зависимости от вашего процесса выпуска, перезапустить контейнеры, всегда извлекая :latest или что-то подобное, что обеспечит проверенное обновление.

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