Где должны храниться критические и непроизводственные данные?

Question

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

Меня спросили, должны ли мы сохранять важные для производства данные внутри экземпляра докера или внеЭто?Каков будет мой выбор и причины для этого.

Будет ли ваш ответ отличаться в случае, если у нас есть непродолжительные некритические данные?

В ответ на ваши вопросы укажите причины.

Answer 1

Два самых основных соображения, которые вы должны иметь здесь:

1. При удалении контейнера все в файловой системе контейнера теряется.
2. Чаще всего удалять контейнеры; требуется изменить многие параметры запуска или обновить контейнер на более новый образ.

Таким образом, вы не хотите хранить что-либо «в контейнере» в качестве основного хранилища данных: оно недоступно извне контейнера и будет потеряно в следующий раз, когда появится критическое обновление безопасности, и вы должны удалить контейнер.

На простом Докере я бы посоветовал оставить

... на изображении : ваше фактическое приложение (скомпилированный двоичный файл или его интерпретированный источник в зависимости от ситуации; объем не входит в объем)

... в контейнере: /tmp

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

... в именованном томе или в подключенном хост-каталоге: постоянные данные, которые контейнер записывает в файловой системе

В этом последнем пункте подумайте о том, чтобы попытаться вообще избежать этого слоя; хранение данных в базе данных, работающей «где-то еще» (может быть другой контейнер, облачный сервис, такой как RDS, ...), упрощает такие вещи, как резервное копирование, и упрощает запуск нескольких реплик одного и того же сервиса. Резервное копирование хост-каталога проще, но в некоторых средах (MacOS) это недопустимо медленно.

Мои ответы здесь не меняются на «производственный» или «непроизводственный» или «критический» против «некритический», за некоторыми исключениями, которые можно оправдать, сказав «все в порядке, если я потеряю эти данные» («потому что это не главная копия»).

Answer 2

Большая часть данных должна управляться извне в контейнеры и изображения контейнеров. Я склонен рассматривать данные, ограниченные контейнером, как временные (промежуточные | отбрасываемые) данные. В противном случае, если это происходит, но это не важно для моего бизнеса, зачем его создавать?

Название «контейнер» вводит в заблуждение. Контейнеры не похожи на виртуальные машины, где существует сильный барьер (изоляция) между виртуальными машинами. Когда вы запускаете несколько контейнеров на одном хосте, вы можете перечислить все их процессы, используя ps aux на хосте.

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

В отличие от процессов, файлы в слоях контейнера более изолированы. Несмотря на то, что в хост-системе слои представлены в виде файлов, вы не можете просто ls файлы слоя контейнера из хост-ОС. Это делает доступ к данным в контейнере более сложным. Существует также снижение производительности для эффективной работы файловой системы поверх другой файловой системы.

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

Менее важно, но не менее важно, сравнительно легко выполнить эквивалент rm -rf * с Docker, удалив контейнеры (docker container rm ...) и тем самым удалив приложение и ваши данные.