Kubernetes 系列（二十九） CI/CD 之数据库管理

我还记得自己作为初级开发者的第一天。我非常紧张，不知道自己在做什么。我的焦虑一定是显而易见的，因为一个善良的灵魂决定收留我。那天我学习了如何在Java代码中编写SQL，以便对数据库做一些有趣的事情。

不过，在开始之前，我必须要求数据库管理员(DBA)创建几个表。我很快意识到，如果你想完成任何事情，DBA就是你的首选。需要一个新的专栏?叫DBA。必须编辑存储过程?这是DBA的工作。我很尊敬他。他是如此的超级巨星，以至于我自己在职业生涯中也做了一段时间的DBA类似的工作。

当然，现在我意识到事事依赖某人不可避免地会造成瓶颈。这是鲁莽的，压力很大，最糟糕的是，这是对DBA才能的浪费。

通过 CI/CD 管理数据库

使用CI/CD自动化数据库管理使我们能够在交付或部署过程中保持数据库模式的更新，从而保持敏捷。我们可以在不同的条件下初始化测试数据库，并根据需要迁移 schema，确保在正确的数据库版本上进行测试。我们可以在部署应用程序时同时升级和降级。自动化数据管理允许我们跟踪数据库中的每一个更改，这有助于调试生产问题。

使用CI/CD管理数据是正确执行[持续部署]的唯一方法(https://semaphoreci.com/cicd)。

DBA 角色

当数据管理自动化时，DBA的角色是什么?他们是无关紧要吗?相反，从卑微的家务中解脱出来后，他们现在可以自由地专注于更有吸引力的增值工作，比如:

• o 监控和优化数据库引擎性能。
• o 建议方案设计。
• o 数据库正常化规划。
• o 对等审查数据库更改和迁移脚本，同时考虑它们对数据库操作的影响。
• o 决定应用迁移的最佳时机。
• o 确保恢复策略能够根据SLA的需求工作。
• o 编写或改进迁移脚本。

CI/CD 数据库管理技术

使数据库管理变得复杂的是，我们必须在修改 schema 的同时保存数据。我们不能像对应用程序那样在每个版本中替换数据库。

当我们考虑到数据库在迁移期间必须保持在线，并且在回滚事件中不会丢失任何东西时，这个问题就更加具有挑战性了。

因此，让我们探索一些技术来帮助我们实现安全迁移。

将数据库脚本提交版本控制系统

通常有两种数据库脚本:数据定义语言(DDL)和数据操作语言(DML)。DDL创建和修改数据库结构，如表、索引、触发器、存储过程、权限或视图。DML用于操作表中的实际数据。

与所有代码一样，这两种脚本都应该保存在版本控制中。在版本控制中保留更改可以让我们重建数据库模式的整个历史。这使得变更对团队可见，因此它们可以被同行评审。数据库脚本包括:

• o 用于在不同版本之间向前和向后滚动数据库版本的脚本。
• o 生成自定义数据集的脚本，用于验收和容量测试。
• o 用于初始化新数据库的数据库模式定义。
• o 更改或更新数据的任何其他脚本。

使用数据库管理工具

有许多工具可用于编写和维护迁移脚本。一些框架，如Rails、Laravel和Django，内置了它们。但是，如果您的堆栈不是这样，那么可以使用通用工具，如Flyway、DBDeploy和SQLCompare来完成这项工作。

所有这些工具的目的都是维护一组不间断的增量脚本，这些脚本可以根据需要升级和降级数据库模式。这些工具可以通过检查现有模式并以正确的顺序运行更新脚本来确定需要哪些更新。它们是比手工编写脚本更安全的选择。

例如，要从版本66到版本70，迁移工具将执行编号为66、67、68、69和70的脚本。反过来也可以执行同样的操作，以向后滚动数据库。

自动迁移可以满足99%的数据管理需求。是否存在管理必须在CI/CD之外进行的情况?是的，但它们通常是一次性的或特定于情况的更改，其中大量的数据必须作为广泛工程工作的一部分进行移动。一个很好的例子是Stripe的bajillion记录迁移。

保持小的变化

在软件开发中，当我们能够安全、小步地行走时，我们会走得更快。这个策略也适用于数据库管理。一次性进行广泛而彻底的更改可能会导致意想不到的结果，比如丢失数据或锁住表。最好是将更改分成几个部分，并随着时间的推移应用它们。

将部署与数据迁移解耦

应用程序部署和数据迁移具有非常不同的特征。虽然部署通常只需要几秒钟时间，而且一天可以执行多次，但是数据库迁移更不频繁，并且在高峰时间以外执行。

我们必须将数据迁移与应用程序部署分开，因为它们需要不同的方法。解耦使这两项任务更容易、更安全。

解耦只有在应用程序在数据库兼容性方面有一定余地的情况下才能起作用，也就是说，应用程序的设计应该努力使其尽可能向后兼容。

建立持续部署和迁移管道

与部署分离的迁移允许我们将连续的交付管道分为两个:一个用于迁移数据库，另一个用于部署应用程序。这为我们提供了连续部署应用程序的好处，同时控制迁移何时运行。我们可以使用基于更改的工作流来自动触发相关的管道。

做附加的迁移

附加数据库更改创建新的表、列或存储过程，而不是重命名、覆盖或删除它们。这些类型的更改更安全，因为它们可以在保证数据不丢失的情况下进行回滚。

例如，假设在生产数据库中有以下表。

CREATE TABLE pokedex (id BIGINT GENERATED BY DEFAULT AS IDENTITY (START WITH 1) PRIMARY KEY,name VARCHAR(255)category VARCHAR(255));

添加一个新列将是一个附加更改:

ALTER TABLE pokedex ADD COLUMN height float;

回滚更改只是删除新列的问题:

ALTER TABLE pokedex DROP COLUMN height;

然而，我们不能总是进行附加更改。当我们需要更改或删除数据时，我们可以通过临时保存原始数据来保持数据的完整性。例如，更改列类型可能会截断原始数据。通过将旧数据保存在临时列中，可以使更改更安全。

ALTER TABLE pokedex RENAME COLUMN description to description_legacy;
ALTER TABLE pokedex ADD COLUMN description JSON;
UPDATE pokedex SET description = CAST(description_legacy AS JSON);

采取了预防措施后，我们可以无风险地回滚:

ALTER TABLE pokedex DROP COLUMN description;
ALTER TABLE pokedex RENAME COLUMN description_legacy to description;

通过 CI/CD 回滚

无论是降级应用程序还是迁移失败，在某些情况下，我们必须撤消数据库更改，有效地将其回滚到过去的模式版本。只要我们有回滚脚本并保持更改是非破坏性的，这就不是一个大问题。

与任何迁移一样，回滚也应该是脚本化和自动化的(我见过很多手动回滚使情况更糟的情况)。

除非速度很快，否则不要做全量备份

尽管有所有的预防措施，事情还是会出错，升级失败会破坏数据库。必须始终有某种备份机制将数据库恢复到工作状态。

问题是:我们是否应该在每次迁移之前进行备份?答案取决于数据库的大小。如果数据库备份需要几秒钟，我们可以完成。然而，大多数数据库都太大，备份时间太长，无法实现。然后，我们必须依赖于可用的任何恢复策略，比如每日或每周完全转储，再加上事务时间点恢复。

作为补充，我们应该定期测试我们的恢复策略。我们很容易相信我们有有效的备份，但在我们尝试它们之前我们不能确定。不要等到灾难发生时才尝试恢复数据库——准备好一些灾难恢复计划，并不时执行它。

考虑蓝绿部署

蓝绿色部署是一种更复杂的技术，需要非常熟悉数据库引擎的工作方式。因此，我建议在您对通过CI/CD流程管理数据库有信心之后，谨慎使用它。

蓝绿色部署是一种允许我们在版本之间立即切换的策略。蓝绿色部署的要点是有两个独立的环境，称为蓝色和绿色。一个是活动的(有用户)，而另一个是升级的。用户可以根据需要来回切换。

如果我们有单独的数据库，我们可以很好地利用蓝绿的即时回滚功能。在部署之前，未激活的系统(下图中的绿色)从蓝色接收当前数据库恢复，并与镜像机制保持同步。然后，它被迁移到下一个版本。

一旦升级和测试了非活动的系统，就可以切换用户。

万一出现问题，用户可以立即切换回旧版本。这种设置的唯一问题是，在回滚后，由绿色一侧的用户执行的事务必须在蓝色一侧重放。

测试技术

因为迁移可能会破坏数据或导致中断，所以我们希望在投入生产之前格外小心并彻底测试它。幸运的是，有相当多的测试技术可以帮助我们。

单元和集成测试

单元测试作为一般规则，在可能的情况下不应依赖或访问数据库。单元测试的目的是检查函数或方法的行为。我们通常可以摆脱这种存根或嘲笑。当这是不可能的或太不方便时，我们可以使用内存数据库来完成这项工作。

另一方面，实际的数据库通常在集成测试中看到。它们可以在测试中按需旋转，装入空表或特殊制作的数据集，并在测试后关闭。

验收和端到端测试

我们需要一个与生产环境非常相似的环境来进行验收测试。虽然在测试数据库中使用匿名的生产备份很有诱惑力，但它们往往太大、太笨拙，不太有用。相反，我们可以使用精心制作的数据集，或者更好的是，创建空模式并使用应用程序的内部API将测试数据填充到它。

兼容性和迁移测试

如果我们的目标是让应用程序前后兼容多个数据库版本，那么我们必须执行回归测试。这可以通过在迁移前后对数据库模式运行验收测试来实现。

在像前面描述的这样的未耦合设置上，应用程序的持续部署管道将对当前模式版本执行验收测试。因此，当发生迁移时，我们只需要对下一个数据库版本进行验收测试:

1. 1. 用当前的生产模式加载测试数据库。
2. 2. 运行迁移。
3. 3. 验收测试运行。

该方法还有一个额外的好处，可以在迁移脚本本身中检测问题，因为很多事情都可能出错，比如由于现有数据、名称冲突或表被锁定太长时间而导致新约束失败。

总结

数据库脚本应该与其余代码同等对待——应用相同的原则。确保dba能够访问代码存储库，以便他们能够帮助设置、修改和同行评审数据管理脚本。这些脚本应该进行版本控制，并接受与代码相同级别的审查。

在使用CI/CD设置自动化数据库管理方面投入的精力将在速度、稳定性和生产力方面得到很多倍的回报。开发人员可以不受阻碍地工作，而dba则可以做他们最擅长的事情:保持数据库的干净和良好运行。

感谢你的阅读!