Хранилище Docker: постоянные параметры для контейнеров

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

Хотя контейнеры обычно недолговечны и не связаны с какими-либо постоянными ресурсами, возможность гарантировать, что данные существуют после прекращения работы контейнера, имеет решающее значение для многих приложений. Есть несколько обходных путей для постоянного хранения данных из контейнеров, хотя не все они так просты, как хотелось бы. Контейнеры — это просто маленькие мини-среды в коробке, и без данных или кода, работающего в них, они даже не существуют. Они появляются, когда есть работа, а затем исчезают, как и было задумано. Данные сегодня чрезвычайно ценны, и людям нравится где-то хранить записи о том, что происходит. Тома данных Docker — это первое решение, которое мы собираемся рассмотреть, и его также довольно легко настроить.

Объемы данных Docker

Вместо того, чтобы вводить контейнеры с кодом каждый раз, когда они запускаются, том данных Docker представляет собой не что иное, как каталог, такой как каталог DOS, например, C:/DOS/GAMES/DIRECTORY. Затем каталог используется в качестве точки монтирования и может быть определен пользователем перед запуском контейнеров. Что он делает, так это сидит в файловой системе хоста и постоянно хранит данные для контейнера. Томам обычно присваиваются случайные 64-символьные имена, такие как временные файлы в Windows, но рекомендуется изменить их на что-то более управляемое.

Причина того, что том данных находится на хосте, а не в контейнерах, заключается в том, что теперь он управляется за пределами возможностей хранилища Docker. Это делает все намного быстрее, так как большая часть нагрузки снимается с драйвера хранилища, который в противном случае должен был бы отслеживать все изменения и различия. Контейнеры Linux созданы на основе образа базового контейнера, поэтому любые данные, хранящиеся в базовом контейнере, в основном реплицируются в каждом отдельном контейнере, что значительно увеличивает объем ресурсов. Это называется оверлейной файловой системой, и контейнеры используют ее для реализации процесса копирования при записи, который сравнивает новую информацию с базовым образом и сохраняет только изменения. Эти изменения затем отбрасываются, когда контейнер завершает работу, и, следовательно, возникает дилемма.

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

Контейнеры данных Docker

Альтернативный и более интересный метод заключается в том, что вместо того, чтобы иметь доступ к данным из тома извне или загружать их в образ базового контейнера, назначьте контейнер только для хранения и предоставьте всем другим контейнерам доступ к нему, как к внешнему устройству хранения. Просто для ясности: этот контейнер не обрабатывает никакого кода, а действует как смонтированный том данных, из которого другие контейнеры могут получить доступ к данным. Еще одним преимуществом является тот факт, что теперь вы эффективно повторно используете один и тот же том, к которому обращаются все контейнеры, а не создаете новые случайные 64-символьные тома. Однако важно помнить, что если основной образ базового контейнера остановлен — это конец ваших данных — поэтому перед этим необходимо выполнить сценарий резервного копирования.

Корневые каталоги

В обоих приведенных выше сценариях объем хранилища находится в файловой структуре Docker /var/lib/docker/volume. В третьем методе мы собираемся смонтировать внешний каталог с хоста в контейнер так же, как мы делали это ранее, за исключением того, что теперь контейнеры имеют доступ ко всему каталогу и могут использоваться для хранения данных одним или несколькими контейнерами по адресу в то же время. Это также полезно, когда вы хотите протестировать код. Все, что вам нужно сделать, это загрузить код в каталог перед его монтированием, и после его запуска вы можете вносить изменения в код и наблюдать за эффектами в контролируемой среде. Следует помнить, что контейнеры по умолчанию имеют доступ для чтения/записи, поэтому, если вы предоставите им один из ваших критических каталогов для игры, убедитесь, что вы изменили этот доступ на доступ только для чтения или будьте готовы к последствиям.

Плагины

Наконец, мы подошли к интересным решениям для хранения данных, и, хотя хранение считается ахиллесовой пятой Docker, это прекрасная возможность для молодых корпоративных стартапов воспользоваться этой возможностью. Docker превосходен, но еще лучше то, что он оставляет огромные пробелы в стеке для новых инструментов и решений, которые могут стать полезными. Хотя сейчас у Docker есть Swarm, изначальное отсутствие программного обеспечения для оркестровки сделало Kubernetes тем, чем он является сегодня (к большой зависти Докера, но это совсем другая статья). Отсутствие постоянного хранилища — не что иное, как подарок предприятию: присоединяйтесь к вечеринке, если можете.

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

На недавнем Dockercon 2017 было сделано два крупных объявления о хранилищах: одно из них от лондонской StorageOS, которая выпустила бета-версию своего постоянного хранилища для контейнеров, которое будет доступно в виде бесплатного 40-мегабайтного плагина после завершения бета-тестирования.

Другое предложение было от Nimble Storage, и это реальное физическое предложение, а не программный плагин. Предложение Nimble называется MultiCloud Flash Fabric и представляет собой реальное устройство хранения данных, основанное на платформе флэш-памяти Nimble с прогнозированием. Благодаря производительности флэш-памяти и прогнозному анализу, а также возможности заменять или добавлять жесткие диски без нарушения работы системы, это надежное предложение для хранения данных. Флэш-хранилище Nimble стоит от 40 000 долларов, но оно является окончательным решением проблемы с хранилищем Docker, поскольку позволяет разработчикам работать с производственными данными, поставлять их и запускать. Это действительно портативный стек данных, соответствующий Docker.

Принцип работы подключаемых модулей хранилища заключается в том, что они сопоставляют хранилище с одного хоста с внешней службой хранения, такой как традиционное устройство хранения или один из флэш-массивов Nimble. Однако, если контейнер переключает хосты, информация теряется, и здесь вступает в действие наше третье решение для хранения: Flocker. Flocker — это не решение для хранения, а платформа, разработанная ClusterHQ, которая управляет и автоматизирует перемещение контейнеров с хоста на хост. Многие крупные компании пишут код для Flocker API, в том числе Dell, EMC, NetAPP и Pure Storage, подтверждая его пригодность для корпоративного использования Docker.

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