kubernetes - InitContainer 或 Helm Hook 数据库迁移回滚

Question

我阅读了很多有关为 Kubernetes 应用程序应用数据库迁移的最佳实践。其实常见的解决方案有以下三种:

1. 数据库迁移的单独 CI/CD 阶段(通常我们在部署新的应用程序版本之前运行它，但在某些情况下我们可以先部署，这对于当前问题并不重要)。只需解耦应用和迁移，然后在不同阶段一一运行它们即可。
2. InitContainer:我们可以在主应用容器启动之前运行数据库迁移。这是一个很好的解决方案，但我们必须小心调整它以对所有 Pod 和副本运行一次迁移，不要在 Pod 重新启动时运行并检查探针(kubelet 可以在迁移仍在运行时在超时时杀死容器)
3. 单独的 Kubernetes Job 或 Helm Hook。 与 initContainer 接近，无法与应用程序容器共享数据(但对于数据库迁移来说并不是真正必要的，所以没关系)。也必须小心超时 - Helm 可以在迁移完成之前终止 Job。

但是问题 - 如何为这些解决方案应用回滚？？？

让我们尝试形成我的想法:

1. CI/CD 中的单独阶段:我们可以保存之前的迁移名称，然后在另一个阶段回滚到它。管道:迁移 -> 部署 -> 测试 -> 回滚数据库并重新部署
2. 但是对于InitContainer和HelmHook我必须想办法如何实现Rollback!我们需要额外的容器吗？ helm 回滚是否也会影响数据库(不这么认为)。 最佳实践是什么？

我将非常高兴收到任何建议!

Answer 1

我也开始调查这个问题，看起来所有手册、教程和实践都是仅供转发的。如果您需要回滚数据库迁移，您将面临 Helm 回滚的限制。 Helm 中有一个 Unresolved 问题 ( https://github.com/helm/helm/issues/5825 ) 可以解决这个问题，但到目前为止似乎还没有解决方案。

因此，Helm 回滚可能不是适合数据库的机制，因为您最终会使用容器镜像创建批处理/v1.Job，而该容器镜像对您需要回滚的更改一无所知。我使用 Liquibase，它要求您需要回滚的变更集存在于变更日志中。

我认为目前这个问题可以通过仅前向方法来解决:

1. 构建容器镜像，将新的变更集引入您的数据库。
2. 在 Helm 的发布值中指定应运行以执行迁移的容器镜像和命令(例如 liquibase update )。
3. 如果迁移失败并且您发现需要回滚，则不要调用 helm rollback 。您部署一个新版本，并在其值中指定应执行数据库迁移回滚的容器镜像以及命令(例如 liquibase rollback <tag> )。我自己现在正在走这条路，这看起来是我能想到的最好的解决方案。

希望有帮助。