Не удалось пересобрать приложение: неподдерживаемый драйвер хранения Docker (btrfs)

Мы собираемся выполнить миграцию нашего сервера и установки Discourse.
Мы используем новый сервер с файловой системой btrfs.

Я провожу тесты на тестовой машине: скопировал все файлы и установил все необходимые компоненты (nginx, docker, сам Discourse).

С файловой системой ext4 всё работало нормально.
Однако теперь, когда я делаю то же самое с файловой системой btrfs, при попытке выполнить ‘launcher rebuild app’ получаю следующую ошибку:

Ваша установка Docker использует неподдерживаемый драйвер хранилища. Если мы продолжим, ваша установка может оказаться неработоспособной.
Рекомендуемый драйвер хранилища — overlay2, хотя также могут работать zfs и aufs.
Известно, что другие драйверы хранилища вызывают проблемы.
Вы можете определить используемую файловую систему, выполнив команду "docker info" и посмотрев строку 'Storage Driver'.

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

Очевидно, что команда docker info показывает, что используется btrfs.
Я прочитал в этом форуме, что у Discourse возникают проблемы с некоторыми драйверами хранилища Docker, и именно поэтому он отказывается выполнять пересборку.

Есть ли способ изменить его на ‘overlay’ или другой драйвер, совместимый с Discourse и позволяющий получить доступ к файлам с файловой системы btrfs?

Как следует настроить Docker?
Возможно ли сделать это только для контейнера Discourse, оставив остальную конфигурацию Docker по умолчанию?

Спасибо.

Примечание

И overlay, и overlay2 в настоящее время не поддерживаются на btrfs или любой файловой системе с копированием при записи (Copy on Write) и должны использоваться только на разделах ext4.

Так как Docker не поддерживает использование драйвера overlay2 поверх btrfs, похоже, что рекомендация инструмента запуска — это единственный доступный вариант. То есть продолжать запускать Discourse на системе, где Docker использует файловую систему ext4, или модифицировать launcher, чтобы игнорировать драйвер хранилища, и надеяться на лучшее.

Чтобы реализовать второй вариант, если вы решите пойти по этому пути, закомментируйте (добавив символ # в начало) строку exit 1 в следующих строках скрипта launcher с помощью предпочитаемого вами текстового редактора:

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

Спасибо за быстрый ответ.

Если я правильно понял, Docker не может использовать альтернативные драйверы хранения для доступа к файлам нижней системы, если используется файловая система с копированием при записи (COW), например btrfs.

Похоже, что хорошего решения нет, так как Discourse может столкнуться с проблемами при использовании драйвера хранения btrfs в Docker.

Возврат к ext4 не является вариантом, поскольку вся миграция была направлена на то, чтобы убедиться, что файлы данных остаются в файловой системе btrfs с поддержкой COW, что позволяет делать снимки и поддерживать данные в чистоте.

Нет смысла использовать btrfs в других частях системы, так как её основная цель — обеспечить доступ к форуму Discourse.

Жаль, ведь было бы здорово запустить систему с защитой файловой системы COW.

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

Использование --skip-prereqs пропускает множество других проверок, что, как вы отметили, создаёт различные риски при выполнении пересборки. Закомментирование этой единственной строки не более и не менее рискованно, чем работа на btrfs, и изменения должны автоматически сливаться при обновлении лаунчера. Это означает, что, скорее всего, вы сможете внести это изменение один раз и в основном забыть о нём.

Хорошо, спасибо, я об этом не знал.

Честно говоря, это сообщение относилось к старому devicemapper, который был известной проблемой с точки зрения надёжности.

На протяжении многих лет мы использовали aufs, а в последнее время — драйвер overlay2, и никаких проблем не возникало. Если вы хотите попробовать btrfs, пожалуйста, через несколько месяцев оставьте здесь отчёт.

Спасибо.
На продакшн-сервере я боюсь этого делать.
Если возникнут проблемы с драйвером Docker и он запишет повреждённые данные, наличие снимков, резервных копий или чего-либо ещё не поможет в случае сбоя.
Если существует безопасный способ хранения данных в резервной копии, я мог бы попробовать…
Какие проблемы возникали в прошлом?

Однако в наши дни такие файловые системы с записью при копировании (COW) очень полезны. Можно делать снимки, данные защищены от повреждений при записи или других сбоях, легко добавлять место или перемещать устройства…

Было бы здорово, если бы в будущем это появилось в Discourse.
Возможно, я смогу помочь с тестированием. У меня это уже работает на тестовой машине.

Проблема в том, что если я редактирую файл лаунчера, чтобы добавить btrfs в список поддерживаемых драйверов хранения Docker, то при запуске скрипт жалуется, что он был изменён локально и будет перезаписан удалённой версией (из GitHub). Как это исправить?

Какое именно сообщение вы видите и на каком этапе пересборки оно появляется?

Я только что запустил виртуальную машину, которую использую для тестирования, изменил строку и пересобрал проект. В момент, когда лаунчер обновляет сам себя, он выполнил git pull и сделал fast-forward слияние, как я и ожидал, сохранив внесённое изменение.

Версия, с которой я обновлялся, не включала изменений в самом лаунчере, но я ожидаю, что это будет работать аналогично, если нет конфликта, то есть если строка exit 1 или строки в непосредственной близости от неё не изменены в репозитории.

Спасибо за ваш ответ и интерес.
Позвольте мне попытаться прояснить ситуацию.

Я изменил скрипт запуска, чтобы включить btrfs в число поддерживаемых форматов.
В функции check_prereqs я изменил:

if ! $docker_path info 2> /dev/null | egrep -q 'Storage Driver: (btrfs|aufs|zfs|overlay2)$'; then

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

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

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

Не знаю, были ли недавно внесены какие-либо изменения в лаунчер, и возможно, изначально у меня была старая версия лаунчера, которая не выполняла реконструкцию, а теперь (после обновления вчера) делает это.

Я тестирую это с btrfs, и всё работает нормально: можно запускать и останавливать приложение, создавать резервные копии — пока всё функционирует корректно.

Docker, похоже, создаёт подтомы btrfs для хранения данных контейнеров, когда обнаруживает, что работает на файловой системе btrfs и использует драйвер хранения btrfs.
Таким образом, кажется, что он применяет некоторые оптимизации при клонировании контейнеров или создании снимков через команды docker.

Но я не знаю, может ли драйвер работать некорректно (он, похоже, не является экспериментальным в Docker, нет предупреждений об использовании его с btrfs, или я их не нашёл), и было бы лучше (если это возможно) изменить настройки docker info, чтобы использовать драйвер overlay2, как если бы он работал на стандартной файловой системе.
Теоретически Docker мог бы записывать файлы и выполнять операции на файловой системе btrfs, не учитывая её возможности (поскольку btrfs на уровне пользователя не отличается от других файловых систем для операций ввода-вывода файлов).

Буду рад любым мнениям или опыту использования драйвера хранения Docker btrfs или настройки драйвера overlay2 для использования при работе Docker на файловой системе btrfs.

У меня нет прямого опыта, которым можно было бы поделиться, но я настоятельно не рекомендую пытаться заставить Docker использовать драйвер overlay2 поверх btrfs. Это явно не поддерживается, и драйвер overlay2 может делать предположения о файловой системе, которые для btrfs могут оказаться верными, а могут и нет, что с высокой вероятностью приведёт к различным непредсказуемым результатам. Вы действительно не хотите сталкиваться с непредсказуемым поведением на уровне файловой системы.

Низкоуровневые операции с файловой системой будут выполняться Docker и драйвером хранения btrfs. Если это зрелая и хорошо поддерживаемая комбинация, которая, в отличие от devicemapper, не известна своими багами, есть хороший шанс, что всё будет работать корректно.

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

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


Если в будущем вы окажетесь в подобной ситуации, вы всегда можете отменить изменения, обновить систему, а затем снова применить изменения перед запуском launcher:

cd /var/discourse
git reset --hard
git pull
sed -i 's/Storage Driver: (/Storage Driver: (btrfs|/' launcher
./launcher rebuild app

Спасибо большое.

Итак, я не буду пытаться использовать драйвер хранилища Docker overlay2 поверх файловой системы btrfs. Я позволю Docker использовать драйвер btrfs, ожидая, что он будет работать корректно и без проблем.
На странице Docker Storage Drivers | Learn the Different Storage drivers of Docker указано, что это рекомендуемый подход, официально поддерживаемый для SUSE Linux Enterprise (SLE), а также рекомендуемый для Ubuntu.
Debian 10 и 11 поддерживают btrfs в ядре без изменений и позволяют загружаться с раздела btrfs (только раздел UEFI должен быть другого типа).

Поэтому я предполагаю, что это хорошо протестировано.

Ответ Рафаэля, похоже, указывает на то, что нет особых причин не использовать его. Проблемы были связаны с devicemapper, и тогда был сделан запрос на использование хорошо известных файловых систем, вероятно, в то время, когда btrfs и другим системам с копированием при записи (COW) уделялось не так много внимания.

Я попробую.
Я сообщу о своём опыте (хорошем или плохом) использования.
На данный момент всё работает гладко, позволяя легко изменять размер файловой системы, добавлять и удалять устройства и т. д., и это внушает уверенность в том, что нижележащие данные корректны и будут сохранены без ошибок.
Единственная мера предосторожности касается драйвера хранилища Docker, если он недостаточно протестирован, но, похоже, он широко используется в SLE (где btrfs используется как файловая система по умолчанию уже давно).

Должен сказать, что наш продакшн-сервер работает уже 9 дней на файловой системе BTRFS без каких-либо проблем.

Ранее я проводил тесты на тестовом сервере.
Я перемещал форум с одного места на подтом, добавлял и удалял диски и пространство в файловой системе — всё работало без сбоев.

Отчитаюсь позже, после более длительного использования.

Я довольно новичок в BTRFS и не знаю его глубоко, но он не так сложен и работает так, как ожидается.

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

Все работает плавно.
Драйверы btrfs для Docker, похоже, функционируют безупречно.
Было бы здорово, если бы другие люди протестировали запуск Discourse на btrfs, и поддержка btrfs могла бы быть интегрирована в дистрибутив Discourse.

Мы останавливаем форум на мгновение, делаем снимок с помощью btrfs (за несколько секунд) и снова запускаем его.
Затем создаём внешнюю резервную копию сделанного снимка.

Кажется, всё работает отлично.

Я восстановил резервную копию на другой машине для тестирования, и она работает.

Отлично это слышать! Можете отправить PR, который добавит это в

Я попробую. Я не очень хорошо разбираюсь в GitHub, надеюсь, всё получится.

Готово, я отправил PR, надеюсь, всё в порядке.