Тома и данные в Docker

Слой записи и тома

Поверх неизменяемых слоёв образа контейнер получает свой тонкий слой записи. Всё, что программа создаёт и правит, ложится туда. Посмотреть его можно командой docker diff: у меня она показала три строки, начинающиеся с буквы A (added, добавлено) - каталог /data и два файла в нём. Команда docker ps с ключом размера показала 52,4 мегабайта записанного при 61,5 мегабайта общего объёма вместе с образом.

Живёт этот слой ровно столько, сколько сам контейнер. Удалили контейнер - слой уничтожен вместе с ним. Поэтому состояние выносят наружу, а контейнер держат одноразовым. Я создал именованный том, записал в него из одного контейнера, тот завершился, и следующий контейнер прочитал ту же строку. Физически том лежит на самой машине по пути /var/lib/docker/volumes/имя/_data, а управляет им демон - постоянно работающая служба docker.

// Одноразовость контейнера - это не про аскезу, а про удобство обновлений. Данные лежат отдельно, поэтому новую версию образа катят поверх тех же данных: удалили старый контейнер, подняли новый, том подключили тот же. Если данные внутри контейнера, то каждое обновление превращается в переезд.

слой записи

изменяемый слой поверх образа; уничтожается вместе с контейнером

именованный том

хранилище под управлением демона, живущее отдельно от контейнеров

Перекрытие против наполнения, и ловушка одного файла

Два вида монтирования ведут себя по-разному, и это ловит почти каждого. Каталог машины просто накрывает точку монтирования: содержимое образа остаётся в слоях, но становится невидимым. Я собрал образ, где в /app/config лежат два файла, и пробросил туда пустой каталог машины - внутри стало видно 0 файлов. Именованный том наоборот: пустой том при первом использовании наполняется содержимым каталога из образа, и у меня внутри оказались оба файла.

Но дальше том живёт своей жизнью и на обновление образа не смотрит. Я собрал вторую версию образа: там три файла и другой текст в настройках. Новый контейнер без тома видит три файла и новый текст, а тот же контейнер со старым томом - два файла и старый текст. Именно так на проде оказываются настройки годичной давности при свежем образе.

// Отдельная ловушка - монтирование ОДНОГО файла. Оно привязано к записи о файле на диске, а не к имени. Проверил: примонтировал файл, дописал в него строку - контейнер новую строку увидел (номер записи 787053 не изменился). Потом отредактировал тот же файл через sed -i, который создаёт новый файл и переименовывает его поверх старого: номер записи стал 787054, на хосте новый текст, а контейнер продолжает читать старую версию. Тот же опыт с примонтированным КАТАЛОГОМ проходит нормально - контейнер видит правку сразу. Поэтому настройки монтируют каталогом.

монтирование каталога

проброс каталога хоста внутрь; накрывает то, что лежало в этой точке в образе

наполнение тома

разовое копирование содержимого образа в пустой том при первом использовании

запись о файле

внутренний номер файла на диске; монтирование одного файла держится за него, а не за имя

Куда девается место на диске

Драйвер логов по умолчанию складывает вывод контейнера в файл и не ограничивает его ничем. Замер: контейнер напечатал 60 000 строк обычного лога приложения, и это дало 6 408 890 байт, то есть примерно 107 байт на строку. Умножьте на болтливый сервис в проде: сотня строк в секунду даёт около 900 мегабайт в сутки с одного контейнера, и через неделю диск кончается.

Тот же контейнер с ограничением max-size=1m и max-file=2 оставил в журнале 968 457 байт - около мегабайта вместо шести. Цена честная: первые 50 949 строк потеряны, самая ранняя доступная строка теперь про заказ номер 50949. Ограничение задают в настройках демона, чтобы правило действовало на все контейнеры разом, а не на те, где о флаге не забыли.

// Логи - лишь один едок. Разбор начинают с команды docker system df, она показывает занятое по категориям. На этом сервере прямо сейчас: образы 11,68 гигабайта, из них 78% не используется ни одним контейнером; кэш сборки, то есть сохранённые промежуточные шаги прошлых сборок, 3,97 гигабайта; тома 2,78 гигабайта, из них 93% не подключено ни к чему. Чистка неиспользуемого экономит гигабайты, но на боевой машине её запускают осознанно: с ключом --volumes она унесёт и те тома, которые сейчас никем не заняты, а это чьи-то данные.

max-size и max-file

предел размера файла логов и число хранимых файлов

чистка неиспользуемого

удаление образов, слоёв и кэша без живых ссылок; с ключом томов удаляет и данные

Как отвечать: «Пересоздали контейнер с базой, данные исчезли. Что сделали не так?»

Данные лежали в слое записи контейнера, а он живёт ровно столько же, сколько сам контейнер: удалили контейнер - слой уничтожен. Состояние надо выносить на именованный том или в примонтированный каталог, а контейнер держать одноразовым, тогда его можно спокойно пересоздавать и катить новые версии образа поверх тех же данных. И сразу оговорю два подвоха монтирования, потому что на них ловятся следом. Пустой каталог хоста, примонтированный поверх каталога с содержимым образа, делает файлы образа невидимыми - я проверял, внутри видно ноль файлов. А пустой именованный том, наоборот, наполняется из образа при первом использовании и дальше на обновления образа не смотрит: свежий образ, а настройки старые.

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

На чём валятся

• −Держат данные в слое записи и теряют их при первом же пересоздании контейнера.
• −Монтируют пустой каталог поверх содержимого образа и решают, что файлы удалились.
• −Правят примонтированный одиночный файл редактором, который подменяет запись о файле, и не видят изменений внутри.
• −Ждут, что именованный том подхватит новые настройки из свежего образа. Он наполняется один раз.
• −Оставляют логи без ограничения размера: диск машины кончается за неделю.