Где лежат пределы уместности Docker
Такой интересный вопрос задали нам читатели и однозначного ответа на него нет. Потому что Docker имеет существенные отличия от классического подхода и их следует учитывать.
Но перед тем, как продолжить дальше, мы вспомним принцип бритвы Оккама, общая суть которого сводится к смыслу: не стоит множить сущности без необходимости. Это универсальное правило, для любых сфер деятельности.
Поэтому перед тем, как взять в руки любую технологию надо подумать: а что она мне даст? Какие задачи позволит решить лучше, быстрее, проще. И что вы потеряете в ее отсутствие.
Перед тем как переходить к Docker мы рассмотрим классический способ управления ПО в Linux – это пакеты. Пакеты – это надежно. Пакеты родных репозиториев непосредственно интегрированы в систему и риски что-то сломать минимальные.
Но здесь у нас появляется и другая сторона, пакеты привязаны к системе, если мейнтейнер не собрал для вашей версии ОС новую версию пакета, то у вас ее не будет. Вы можете подключить сторонний репозиторий или собрать ее сами, но это очень плохие практики в продуктовых системах, чреватые потерей стабильности и сбоями.
Классическая виртуализация ничего не меняет в этой схеме, просто позволяет разделить одну систему на несколько, каждая из которых будет выглядеть как полноценная ОС на полноценном наборе железа, со своим ядром, кастомными настройками и т.д. и т.п.
Контейнеризация на базе LXC это уже несколько иной уровень, хотя внешне такие контейнеры очень похожи на виртуальную машину, но на самом деле никакой виртуализацией тут и не пахнет.
Процессы и библиотеки LXC запускаются непосредственно на хосте и используют ядро и ресурсы хоста, просто ограничены своими пространствами имен (namespaces) и лимитами ресурсов (cgroups).
При этом LXC предоставляет контейнеризацию на уровне системы, в контейнере воспроизводится окружение любого необходимого дистрибутива Linux, доступен пакетный менеджер и большинство системных настроек.
Но ничего нового в работе с ПО у нас пока не появилось, просто теперь мы можем выбирать в разных контейнерах разные окружения, исходя их требований нашего ПО. Принципы управления и администрирования остаются классическими.
Docker же предлагает совершенно иной подход: один контейнер – один процесс. Окружение – только необходимые для работы процесса зависимости и библиотеки. А сам контейнер – сущность одноразовая, которая создается при запуске и уничтожается при остановке.
Все настройки и пользовательские данные хранятся в подключаемых томах на хосте, которые динамически монтируются в запущенный контейнер, также как и динамически создается сетевая инфраструктура.
В основе контейнера лежит атомарный образ, который собирается один раз и потом многократно используется, внесения изменений в образ «на ходу» не допускаются.
Все это достаточно непривычно и после классического подхода вызывает массу вопросов, особенно если нам нужно понимать многоконтейнерные связки. Но тут нам на помощь приходят оркестраторы, самый простой из которых Docker Compose.
Они позволяют описать конфигурацию приложения в виде кода, который расскажет какие контейнеры надо запустить, что к ним подключить, как связать между собой. Фактически переводя работу с системой на уровень «инфраструктура как код».
Теперь нам не нужно ставить пакеты, зависимости, проверять их версии, решать проблемы совместимости. Нам нужен только Docker, он сам скачает нужные образы, создаст указанные нами контейнеры, применит указанные нами настройки и все это будет работать.
Надо перенести на другую систему, легко – переносим файлы с описанием инфраструктуры и пользовательские данные. Все снова работает. Без оглядки на версию хостовой ОС. Это удобно, особенно когда приложение требует целый стек, причем определенных версий.
И требования приложения могут меняться. В этом случае просто меняем версию образа в докер и перезапускаем систему. Классическая проблема версии PHP, которой нет в дистрибутиве решается быстро и безопасно, легким движением руки.
Продолжение следует.
