金策略如何实现自动化数据库迁移

这期我们来看看金策略如何实现金融数据库自动化数据库迁移

我们有三个专用环境：开发、分段构建和生产。每个环境都有自己的专用 VPC，因此 VPC 中的资源不能直接从外部访问，通常来说这是很好的。

问题是我们有时需要修改某些组件的模式结构，例如：添加一个新的表或列。在 Java-ish 中，我们使用 Liquibase 来管理 DDL / DML 的更改。同样的，通常来说这是很好的。但是我们要如何才能使这些更改通过持续交付的方式应用到各个不同的环境中呢？

我们针对上述问题，提出了几种解决方法：

1、在启动时执行

您可以让您的组件执行此操作。例如，您可以将应用程序配置为在启动时应用它。对于 Spring Boot 应用程序来说，这非常简单。您只需将 liquibase jar 添加到环境变量并配置一些配置属性即可实现此目的。

这种方法对于在本地的开发或开发环境来说可能是很好的，但是对于分段构建或生产呢？问题在于，您的数据库迁移脚本可能很慢，执行它们可能需要几分钟、几个小时甚至几天的时间。

对于上述情况，使用 ECS 的效果就不太理想了，因为在那里部署服务时，您定义了 ECS 将用于验证组件的运行状态，在执行数据库迁移脚本的情况下启动它，会导致整个迁移过程被认为是不健康的。而且 ECS 可能会在迁移过程中杀死您的容器。您可以为 ECS 服务配置一个宽限期，但这可能很难预测到它的值，因为每个迁移都可能不同。

2、手动应用

另一种选择是 SSH 连接到与服务在同一个 VPC 中运行的EC2实例，并从那里手动运行迁移脚本（你可能知道这种做法有多糟糕）。

3、使用 docker 容器

另一个选择是创建一个专用的 docker 镜像来运行迁移脚本。我们选择了这个选项：

定义 docker 镜像：

我们使用了一个开源的基础镜像，它为我们提供了一种执行 Liquibase 更改日志的方法。我们所要做的就是定义一些环境变量并将 Liquibase 更改日志复制过去。空变量是故意放进去的，以便大家在运行容器时记得替换掉它们。

我们将镜像定义文件与我们的代码库一起存储，因此在发布时会对其进行版本控制和标记。有了这一点，我们更新了 Jenkins 的工作，作为工作流程的一部分来构建和推动新的 docker 镜像。

下一步是更新 Jenkins 的工作来触发使用我们的新镜像迁移数据库的 ECS 任务。为此，我们使用了自己的框架，但您可以使用 Terraform 或K8s，或者您甚至可以使用以下命令手动运行它（请不要在生产中执行！）

由于我们不在容器启动时运行迁移，所以我们不再有与长时间运行的迁移相关的问题，从而导致 ECS 运行状况检查失败。但好处是，我们的迁移现在已经与我们的部署分离了（这是一篇很好的文章，解释了从应用程序部署中分离数据库迁移的好处）。

使用这种新方法，我们必须确保我们的迁移始终与当前在生产中运行的代码兼容。它需要一些额外的工作，但现在意味着我们可以毫不费力地回滚我们的版本。

解决这个问题可能还有许多其他（也许更好）的方法，但是这种方法对我们更有效。如果你对这个话题有任何想法或想法可以在文尾处留言与我们探讨。