无法重建应用：不支持的docker存储驱动程序（btrfs）

安装
1

我们将迁移我们的服务器和 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 配置保持默认？

谢谢。

2

注意

overlay 和 overlay2 目前在 btrfs 或任何写时复制文件系统上均不受支持，应仅在 ext4 分区上使用。

由于 Docker 不支持在 btrfs 之上使用 overlay2 驱动程序，因此启动器工具的建议似乎是您的选择范围。也就是说，继续在 Docker 由 ext4 支持的系统上运行 Discourse，或者修改 launcher 以忽略存储驱动程序并祈祷一切顺利。

如果您想选择后者，可以通过您喜欢的文本编辑器在 launcher 脚本的以下行中注释掉（在行首添加 #）exit 1 行来实现：

考虑到“其他存储驱动程序已知存在问题”，我不建议这样做。

1 个赞
3

感谢您的快速回复。

所以，如果我理解正确的话，当您使用 btrfs 这样的 COW 文件系统时，docker 无法使用其他替代存储驱动程序来访问底层系统文件。

所以没有好的解决方案，因为 discourse 在使用 docker 的 btrfs 存储驱动程序时可能会遇到问题。

恢复到 ext4 不是一个选项，因为所有的迁移都是为了确保数据文件保留在 COW btrfs 文件系统下，以及它进行快照和保持数据干净的能力。

在系统的其他部分使用 btrfs 没有意义，因为它的主要目标是提供 discourse 论坛访问。

这很可惜，因为能够让它在 COW 文件系统的保护下运行将是很好的。

使用 --skip-prereqs 标志更容易。但在生产系统中使用它可能会有风险。
我在测试机上试过了，目前运行得还可以，但问题似乎在于长期使用。

4

使用 --skip-prereqs 会跳过许多其他测试，正如你所提到的，这在执行重建时会带来各种风险。注释掉那一行与在 btrfs 上运行的风险没有多大区别，并且当启动器自行更新时，它应该会自动合并，这意味着你可能只需更改一次，然后就可以基本忘记它了。

1 个赞
5

好的；谢谢，我之前没意识到这一点。

6

坦率地说，那条消息是针对旧的 devicemapper 的，它存在已知的可靠性问题。

多年来，我们使用了 aufs，最近我们使用了 overlay2 驱动程序，都没有出现问题。如果你想尝试使用 brtfs，请在几个月后在这里提交一份报告。

2 个赞
7

谢谢。
在生产服务器上，我担心这样做。
如果 Docker 驱动程序出现问题并写入损坏的数据，那么如果发生崩溃，快照、备份或任何其他东西都将无济于事。
如果有一种安全的方式来维护备份中的数据，我或许可以尝试……
过去发生过什么类型的问题？

但如今，这种 COW 文件系统非常有用。您可以进行快照，数据可以防止写入期间或其他故障造成的损坏，还可以轻松地添加空间或移动设备……

如果将来能在 discourse 上看到它，那就太好了。
也许我可以帮助测试。我已在一台测试机上运行了它。

8

问题是，如果我编辑启动器文件以将 btrfs 添加到支持的 docker 存储驱动程序列表中，当我运行脚本时，它会抱怨脚本已被本地修改，并且将被远程版本（来自 github）覆盖。
我该如何解决这个问题？

9

你看到的具体消息是什么？它发生在重建的哪个阶段？

我刚启动了一个用于测试的虚拟机，修改了那一行，然后重新构建。在启动器更新自身的阶段，它执行了 git pull 并进行了我预期的快进合并，保留了修改。

我正在更新的版本不包括对启动器本身的更改，但我认为只要没有冲突，它应该以同样的方式工作，也就是说，只要那一行 exit 1 或非常接近的行没有在存储库中更改。

1 个赞
10

感谢您的回复和关注。
让我尝试澄清一下。

我已经修改了启动器脚本，将 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 信息，以便使用 overlay2 驱动程序运行它，就好像它在标准文件系统上运行一样。
理论上，Docker 可以在不考虑其功能的情况下（因为从用户级别来看，btrfs 与其他文件系统在文件 I/O 方面没有区别）在其 btrfs 文件系统上写入其文件并执行操作。

欢迎就使用 btrfs docker 存储驱动程序或在 btrfs 文件系统上使用 docker 时配置 overlay2 驱动程序的任何意见或经验。

11

我没有直接的经验可以提供，但我强烈建议不要强迫 Docker 在 btrfs 之上使用 overlay2 驱动程序。这是明确不支持的，overlay2 驱动程序可能会对文件系统做出一些假设，而这些假设对于 btrfs 来说可能成立也可能不成立，从而可能导致各种意外的结果。你真的不希望在文件系统级别出现意外结果。

Docker 和 btrfs 存储驱动程序将负责低级文件系统操作。如果这是一个成熟且维护良好的组合，不像 devicemapper 那样存在已知的 bug，那么它很有可能就能正常工作。

据我所知，Discourse 不支持 btrfs 的原因并不是因为它预期会失败，而仅仅是因为他们没有足够的信息来告诉人们它会起作用。

他们没有（或没有足够）的动力在 btrfs 上运行自己的服务器，所以他们获取这些信息的唯一方法就是让社区中的人们在生产环境中尝试使用它，并在长时间后进行反馈。这种情况还没有发生，所以它仍然不受支持。

如果你将来遇到这种情况，你可以随时重置更改，更新，然后在运行启动器之前再次应用更改：

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

非常感谢。

所以，我不会尝试在 btrfs 文件系统上使用 docker 的 overlay2 存储驱动程序，我会让 docker 使用 btrfs 驱动程序，并期望它能正常工作而不会出现任何问题。
在这里 Docker Storage Drivers | Learn the Different Storage drivers of Docker 他们说这是 SLE Linux 推荐的方法并且官方支持，但在 Ubuntu 中也推荐。
Debian 10 和 11 在内核中支持 btrfs 而无需修改，并且支持从 btrfs 分区启动（只有 UEFI 分区应该是其他类型）。

所以我假设它经过了充分的测试。

来自 Rafael 的回答似乎表明没有特别的理由不使用它。问题出在 devicemapper 上，他们要求使用众所周知的文件系统，可能是在当时对 btrfs 或其他 COW 系统不太关注的时候。

我会尝试一下。
我会报告我的使用经验（好或坏）。
目前它运行得很顺利，并且让我能够轻松地更改文件系统大小、添加设备、删除它们等，并让我相信底层数据是正确的，并且将保持没有错误。
唯一的预防措施是 docker 存储驱动程序，如果它没有经过充分测试，但它似乎在 SLE（长期以来一直将 btrfs 作为默认存储文件系统实现）中得到了广泛使用。

1 个赞
13

我必须说，我们的生产服务器已在 BTRFS 文件系统上运行了 9 天，一切正常。

我之前在测试服务器上进行过测试。
我已将论坛从一个位置移动到一个子卷，并向文件系统添加和删除了磁盘和空间，一切正常。

我将在使用更长时间后报告。

我对 BTRFS 还比较陌生，并不深入了解它，但它并不像预期的那样困难，而且它确实按预期工作。

2 个赞
14

我必须说，我们在 btrfs 文件系统上运行 discourse 已经将近一个月了，没有任何问题。

它运行得很流畅。
Docker 的 btrfs 驱动程序似乎工作得很完美。
如果其他人测试在 btrfs 上运行 discourse，并将 btrfs 支持集成到 discourse 分发版中，那将是很好的。

我们暂时停止论坛，使用 btrfs 进行快照（几秒钟），然后重新启动它。
然后我们对拍摄的快照进行外部备份。

它似乎工作得很完美。

我已将备份恢复到另一台机器上进行测试，并且运行正常。

那

2 个赞
15

很高兴听到这个消息！你能发送一个 PR 将其添加到
discourse_docker/launcher at main · discourse/discourse_docker · GitHub 吗？

16

我会试试。我对 GitHub 不是非常精通，希望我能做得好。

完成了，我已经提交了 PR，希望我做得没问题。

1 个赞
17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.