Преимущества управления контейнерами MariaDB с помощью программного обеспечения оркестрации

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

В ходе обсуждения мы должны помнить, что Docker Engine, CRI-I, containerd, Mirantis Container Runtime, Podman и другие OCI контейнерные среды выполнения могут использоваться для настройки производственных и/или тестовых сред. Эти варианты использования сильно отличаются с точки зрения базы данных: производственная база данных может быть большой и, как правило, содержит данные, которые мы не хотим потерять. Тестовые среды обычно содержат небольшие образцы данных, которые можно сравнительно быстро восстановить. Эта страница сосредоточена на последнем случае.

Эфемерная природа контейнеров

Изображения — это формат, определенный спецификацией OCI, который можно скомпилировать из Dockerfiles как один из способов. Контейнеры — это указанный OCI runtime способ создания рабочей версии изображения. Обычно контейнер не изменяется с момента его создания. Другими словами, контейнеры обычно предназначены для того, чтобы быть эфемерными, что означает, что их можно уничтожить и заменить новыми контейнерами в любое время. При условии надлежащей избыточности (например, несколько веб-серверов работают с одними и теми же службами) уничтожение одного контейнера и запуск нового контейнера того же типа не причинит никакого вреда.

Мы немного позже обсудим, как это относится к MariaDB и, в более общем плане, к серверам баз данных.

Когда что-то должно измениться, например, какая-то версия программного обеспечения или конфигурация, обычно обновляются Dockerfiles, и контейнеры пересоздаются из последних версий изображений. По этой причине контейнеры не должны содержать ничего, что не должно быть потеряно, и их пересоздание должно быть чрезвычайно быстрым процессом. Для объявления, какие контейнеры образуют определенную среду, и как они взаимодействуют друг с другом, используются Docker Compose или режим Swarm.

Напротив, Ansible и Puppet в основном предназначены для управления конфигурацией существующих серверов. Они не пересоздают серверы, а изменяют их конфигурацию. Таким образом, у Docker и Ansible совершенно разные подходы. По этой причине Ansible и Puppet нечасто используются для развертывания контейнеров в производстве. Однако совместное использование их может принести определенные преимущества, особенно для тестовых сред.

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

Технологии с состоянием

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

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

Однако в OCI Containers есть функции, называемые томами. Том — это каталог в системе хоста, сопоставленный с каталогом в одном или нескольких контейнерах. Тома не уничтожаются при уничтожении контейнеров. Они могут использоваться для совместного использования данных между любым количеством контейнеров и системой хоста. Таким образом, они также являются хорошим способом сохранения данных.

Предположим, что контейнер MariaDB, называемый mariadb-main-01, использует том, который сопоставлен с /var/docker/volumes/mariadb-main. В какой-то момент мы хотим использовать более новую версию MariaDB. Как объяснялось ранее, для этого в контейнерах используется способ — уничтожить контейнер и создать новый, использующий более новую версию изображения MariaDB.

Таким образом, мы уничтожим mariadb-main-01. Том по-прежнему остаётся. Затем мы создаём новый контейнер с тем же именем, но на основе более новой версии изображения. Мы также убеждаемся, что связываем том с новым контейнером, чтобы он мог снова использовать /var/docker/volumes/mariadb-main. В этот момент мы можем захотеть запустить mariadb-upgrade, но помимо этого, всё должно просто работать.

Реализации контейнерной среды выполнения также предоставляют возможность создавать том с явным именем, и он также будет постоянным. Фактическое расположение в файловой системе управляется средой выполнения.

Описанные выше шаги просты, но их ручное выполнение занимает много времени и подвержено ошибкам. Автоматизация их с помощью какого-либо программного обеспечения автоматизации, такого как Ansible или Puppet, часто является желательной.

Способы развертывания контейнеров

Контейнеры могут быть развернуты следующими способами:

• Вручную. См. Установка и использование MariaDB через Docker. Это не рекомендуется для производства или сложных сред. Однако это легко сделать в простейших случаях. Если мы хотим внести изменения в наши собственные изображения, нам нужно будет изменить Dockerfiles, уничтожить контейнеры и пересоздать их.
• С Docker Compose. См. Настройка стека LAMP с помощью Docker Compose для простого примера. При изменении Dockerfile нам нужно будет уничтожить контейнеры и пересоздать их, что обычно так же просто, как запуск docker-compose down и docker-compose-up. После изменения docker-cmpose.yml (возможно, для добавления контейнера или сети) нам просто нужно будет снова запустить docker-compose-up, потому что оно идемпотентно.
• Используя Ansible, Puppet или другое программное обеспечение автоматизации, как упоминалось ранее. Мы можем использовать Ansible или Puppet для создания контейнеров и повторного запуска их каждый раз, когда хотим внести изменения в контейнеры. Это означает, что контейнеры потенциально создаются один раз и изменяются любое количество раз.

Во всех этих случаях вполне возможно добавить Vagrant в картину. Vagrant — это способ развертывания или настройки нескольких хостов, включая виртуальные машины (самый распространённый случай), и контейнеров. Он независим от используемой технологии, поэтому может развернуть виртуальную машину, контейнер или даже удалённый сервер одинаковым образом. Контейнеры могут взаимодействовать с Vagrant двумя способами:

• В качестве средства настройки. В этом случае Vagrant, как правило, развернёт виртуальную машину и воспользуется Docker для настройки приложений, которые должны выполняться в ней, как контейнеры. Это обеспечивает более высокий уровень изоляции по сравнению с запуском контейнеров на локальном хосте. Особенно если у вас есть разные среды для локального развертывания, потому что вы можете иметь их на разных виртуальных машинах.
• В качестве провайдера. Vagrant локально развернёт один или несколько контейнеров. После запуска каждого контейнера Vagrant по желанию может использовать средство настройки для обеспечения запуска контейнером надлежащего программного обеспечения с соответствующей конфигурацией. В этом случае Ansible, Puppet или другое программное обеспечение автоматизации можно использовать как средство настройки. Но опять же, это необязательно: можно вносить изменения в Dockerfiles и пересоздавать контейнеры каждый раз.

Преимущества управления контейнерами с помощью программного обеспечения автоматизации

Контейнеры можно полностью управлять с помощью Docker Compose или режима Swarm. Это часто хорошая идея.

Однако выбор программного обеспечения автоматизации, такого как Ansible или Puppet, также имеет свои преимущества. К ним относятся:

• Контейнеры позволяют работать, не изменяя систему хоста, и их создание очень быстро. Гораздо быстрее, чем виртуальные машины. Это делает контейнеры желательными для тестовых сред.
• Как уже объяснялось, можно сделать все контейнеры эфемерными и использовать тома для хранения важных данных. Но это означает добавление некоторой сложности для адаптации эфемерной философии к технологиям, которые по своей природе не эфемерны (базы данных). Кроме того, многие специалисты по базам данных не любят этот подход. Использование программного обеспечения автоматизации позволяет легко запускать обновления и изменения конфигурации в контейнерах, рассматривая их как неэфемерные системы.
• Иногда контейнеры используются только в тестовых средах. Если производственные базы данных управляются с помощью Ansible, Puppet или другого программного обеспечения автоматизации, это может привести к дублированию кода. Обработка изменений конфигурации с использованием одних и тех же процедур сократит затраты на техническое обслуживание.
• Хотя пересоздание контейнеров быстро, возможность применения небольших изменений с помощью Ansible или Puppet может быть удобнее в некоторых случаях: особенно если мы записываем файлы в сам контейнер или если пересоздание загрузки контейнера включает в себя какую-то длительную процедуру.
• Попытка сделать что-то нестандартное с Dockerfiles может быть сложной. Например, запуск двух процессов в контейнере возможен, но может быть проблематичным, поскольку контейнеры предназначены для запуска одного основного процесса на контейнер. Однако в некоторых ситуациях это желательно. Например, контейнеры PMM запускают несколько разных процессов. Запуск дополнительных процессов с помощью Ansible или Puppet может быть проще, чем сделать это с помощью Dockerfile.

Учитывая всё это, давайте посмотрим на некоторые примеры случаев, когда управление контейнерами с помощью Ansible, Puppet или другого программного обеспечения автоматизации предпочтительнее, чем уничтожение контейнеров каждый раз, когда мы хотим внести изменения:

• Мы используем Ansible или Puppet в производстве, и мы пытаемся сделать тестовые среды максимально похожими на производственные. Используя Ansible/Puppet в разработке тоже, мы можем повторно использовать часть кода.
• Мы часто вносим изменения в контейнеры, и пересоздание контейнеров не так быстро, как должно быть (например, потому что необходимо восстановить дамп MariaDB dump).
• Создание контейнера предполагает некоторую сложную логику, которая нелегко укладывается в Dockerfile или Docker Compose (включая, но не ограничиваясь, запуск нескольких процессов на один контейнер).

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

Как развернуть в контейнер из программного обеспечения оркестрации

Предположим, вы хотите управлять конфигурацией контейнеров с помощью Ansible.

На первый взгляд, самый простой способ — запустить Ansible в системе хоста. Ему потребуется подключиться к контейнерам через SSH, поэтому контейнеры должны открыть порт 22. Но у нас несколько контейнеров, поэтому нам потребуется сопоставить порт 22 каждого контейнера с разными портами в хосте. Это трудно поддерживать и потенциально небезопасно: в производстве следует избегать экспонирования портов любого контейнера хосту.

Лучшим решением является запуск самого Ansible в контейнере. Плейбуки будут находиться в объеме контейнера, поэтому мы сможем получить к ним доступ с хост-системы для более удобного управления. Контейнер Ansible будет взаимодействовать с другими контейнерами с использованием контейнерной сети, используя стандартный порт 22 (или другой порт по вашему выбору) для всех контейнеров.

См. также

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

• Развертывание контейнеров с помощью Ansible.
• Развертывание контейнеров с помощью Puppet.

Контент первоначально предоставлен Vettabase Ltd.