Знакомство с Docker или зачем это всё нужно
Всем привет. Меня зовут Алексей, вместе с командой я занимаюсь разработкой прикладных решений в системе Saby компании Тензор. В своей статье хочу поговорить про Docker.
При знакомстве с любой технологией важно понимать, зачем инвестировать своё время в её изучение. Для этого нужно иметь хотя бы общее представление о предметной теме.
Сейчас, когда Docker используется повсеместно, многие разработчики (особенно молодые) относятся к нему, как к данности, при этом не до конца понимая, зачем, собственно, он используется и какие проблемы решает. На Хабре есть ознакомительные статьи про Docker, однако они не в полной мере (вернее, не в той мере, в которой хотелось бы мне:)) освещают данный вопрос. Так возникла идея написания этой статьи. При ее подготовке были использованы: информация из книги Docker In Action, данные с профильных сайтов, собственные разработки для выступления на внутрикорпоративном митапе Тензора, материалы с IT-форумов и, конечно, личный опыт. Если вы опытный разработчик/администратор/devops, и уже давно используете Docker, вы вряд ли узнаете что-то новое из статьи и можете смело проходить мимо. Если же ваш профессиональный путь только начинается, надеюсь, что этот материал поможет вам в освоении данной технологии.
Разработка программного обеспечения — это не только написание кода. Скажу больше: во многих прикладных задачах написать сам код не так уж сложно (если говорить об отрасли в среднем). Получить данные из БД (или любого другого хранилища), отобразить эти данные, обработать, сохранить обратно в БД, вызвать внешние сервисы и т.п. — все это довольно распространенные задачи, с которыми, уверен, сталкивались многие. Но это еще не все. Кроме этого необходимо обеспечить выполнение нефункциональных требований к системе:
корректная обработка ошибок/исключений;
производительность;
безопасность;
масштабируемость;
наблюдаемость;
обновляемость;
стоимость обслуживания и поддержки после ввода в промышленную эксплуатацию;
отказоустойчивость;
и т.д.
Если мы все это соберем воедино, история станет не такой простой. Давайте посмотрим на примере. Предположим, что у нас есть некая система, состоящая из нескольких компонентов, работающих на одном сервере. Эти компоненты могут использовать различные библиотеки, вызывать компоненты и функции ОС:
Узкое место очевидно: если что-то случится с сервером, вся система перестанет работать. Как обеспечить масштабируемость и отказоустойчивость? Одно из решений — увеличить число узлов нашей системы (т.е. использовать горизонтальное масштабирование. В свою очередь под вертикальным масштабированием подразумевают увеличение мощности железа — CPU, памяти и т.п.). Этого можно добиться, например, переместив компоненты системы с физического сервера на виртуальные машины и запустив их на нескольких серверах:
Теперь, если какой-либо компонент системы, ВМ или сервер, упадет, — остальные продолжат работать, и вся система продолжит функционировать хотя, возможно, с чуть меньшей производительностью. Это, конечно, сильно упрощенная схема, но она позволяет понять суть. В рамках данной статьи не будем углубляться в детали, как организовать оркестрацию кластера, теорию репликации БД, настройку распределенного кеша и другие связанные вопросы. Все это достаточно сложные и обширные темы, по которым написана не одна статья и книга.
Итак, использование кластера позволило улучшить отказоустойчивость системы. Однако, если заглянем внутрь виртуальных машин, то обнаружим, что ситуация с компонентами и зависимостями не изменилась. Внутри ОС компоненты по-прежнему используют различные библиотеки. При этом возможно, что одному компоненту нужна одна версия определенной библиотеки, а другому — иная версия этой же библиотеки.
Как обновлять такой кластер? Можно загружать обновления на каждую виртуальную машину и обновлять все компоненты один за одним. В небольшой системе это, возможно, сработает, но что произойдет, когда количество компонентов вырастет, и количество сред, в которых эти компоненты нужно запускать, тоже увеличится? Зависимости будут накапливаться, как снежный ком, делая поддержку системы все сложнее и дороже. В итоге получаем нечто похожее на следующую таблицу, которую также называют «матрицей ада»:
Число элементов этой матрицы будет тем больше, чем больше компонентов и сред будет в нашей системе. Также проблемы с зависимостями придется решать при настройке CI/CD — чем их больше, тем сложнее будет настройка.
Можно ли как-нибудь улучшить ситуацию? Например, если бы можно было упаковать компонент/сервис нашей распределенной системы вместе со всеми необходимыми зависимостями, конфигурацией, переменными среды и т. д. в «нечто», что позволило бы нам запускать этот компонент/сервис в любой среде на любой ОС (на ноутбуке разработчика, автономном сервере, в кластере и т.п.). Тогда мы могли бы просто переносить это «нечто» между средами:
Здесь на сцену выходят контейнеры и Docker. Говоря о контейнерах, в воображении возникает баржа, перевозящая грузовые контейнеры. Как мы увидим ниже, образ Docker — это своего рода грузовой контейнер, внутри которого содержатся компоненты и их зависимости. Эта аналогия отражена в логотипе Docker:
Термин «контейнер» пришел из операционных систем на базе Unix. Первоначально использовался термин «jail» (тюрьма), но с 2005 года с выпуском Sun Solaris 10 и Sun Containers более распространенным стал термин «контейнер». Контейнер — это изолированная среда выполнения приложений. По умолчанию, приложению, запущенному внутри контейнера, запрещен доступ к ресурсам за пределами своего контейнера. Основной проблемой ручного создания и конфигурирования контейнеров была сложность и, как следствие, вероятность непреднамеренных ошибок.
Docker упрощает создание контейнеров. В контексте Docker контейнеры — это дочерние процессы фоновой службы Docker. Контейнеры запускаются из образов (images). Как уже упоминалось выше, образ Docker является хорошим аналогом грузового контейнера. У каждого образа есть т.н. базовый образ (указывается в команде FROM … в Dockerfile — скрипте для создания образов), поверх которого слоями добавляются ваши изменения (напр. установка расширения mysql для образа на основе php fpm добавляет новый слой, с указанным расширением). Базовый образ может быть основан как на Linux, так и на Windows Server Core. Проверить, на основе какой ОС построен ваш образ, можно с помощью команды docker inspect.
Образы хранятся в репозиториях (repositories), которые, в свою очередь, организованы в реестры (registries). Самый известный общедоступный реестр образов — DockerHub (тот самый, который не так давно нам неожиданно заблокировали, а потом также неожиданно разблокировали). Также возможно запустить собственный локальный реестр образов внутри компании.
Docker состоит из нескольких частей:
утилита командной строки;
фоновая служба;
набор удаленных сервисов (DockerHub, JFrog и др.)
Вместе они упрощают работу с контейнерами и позволяют построить собственную инфраструктуру управления контейнерами:
Docker имеет открытый исходный код и работает в Linux, Windows (поверх Hyper-V или WSL2) и MacOS. Обратите внимание, что хотя запустить Linux контейнер (контейнер, у которого базовый образ основан на Linux) в Docker, работающем в Windows, не составляет труда (под капотом WSL2 представляет собой легковесную виртуальную машину с Linux ядром), в то же время запустить Windows контейнер (контейнер, у которого базовый образ основан на Windows Server Core) в Docker, работающем в Linux, не так просто:
Для этого есть решения, но не совсем очевидные. Из того, что я нашел: можно запустить ОС Windows Server Core внутри VirtualBox, который, в свою очередь, работает в контейнере Docker в Linux, либо использовать оболочку Wine. Также при этом необходимо решить проблемы с лицензией для Windows.
Обратите внимание, что контейнер — это не то же самое, что виртуальная машина:
Виртуальные машины:
запускают собственную ОС, в которой запускается установленное ПО;
требуют больше ресурсов (зависит от сценариев, но в среднем на стандартном ПК можно запустить лишь несколько ВМ);
стартуют медленнее;
проблемы снэпшотов: большой размер, сложности с отслеживанием изменений (diffs) и версионностью;
из одного набора VMX/VMDK файлов можно запустить одну ВМ.
С другой стороны, контейнеры:
работают в одной родительской ОС;
требуют меньше ресурсов (также зависит от сценариев, но опять же на обычном ПК можно запустить множество контейнеров одновременно);
обычно стартуют в течение нескольких секунд (сейчас не берем во внимание сервисы в docker compose с зависимостями друг от друга, т.е. когда один контейнер ждет, пока другой будет полностью запущен и готов к работе);
изменения добавляются как дополнительный слой: можно отследить изменения и просматривать историю;
из одного образа (image) можно запустить множество контейнеров.
Теперь, обладая этими знаниями, можно решить упомянутую выше «матрицу ада», используя контейнеры:
Но, как это часто бывает, решая одну проблему, мы получаем другую: как управлять этой матрицей? За ответом на этот вопрос необходимо обратиться к технологиям оркестрации контейнеров, таким как Kubernetes и Docker Swarm. Однако, эта тема уже выходит за рамки текущей статьи.
В заключение хотел бы отметить, что Docker интересен именно как часть большего пазла, позволяющего построить инфраструктуру развертывания. Представьте, что программисты публикуют релиз в git. Система сборки по вебхукам (webhooks) получает уведомление, с помощью Dockerfile собирает образы компонентов, используя последнюю версию исходного кода, и добавляет их в локальный реестр образов. После этого уже система оркестрации получает уведомление, запускает контейнеры из новых образов, а контейнеры из старых образов останавливаются (если говорить про Kubernetes, то этому соответствует запуск и остановка pod-ов). В итоге наша система не только сама мониторит свое состояние и умеет адаптироваться под увеличенные нагрузки (с помощью связки Kubernetes + Docker), но и обновляет сама себя. По-моему, звучит достаточно интересно, чтобы потратить время на изучение этих технологий.
