【问题标题】:DB Migration on a Load-Balanced Cloud Foundry Deployment负载平衡 Cloud Foundry 部署上的数据库迁移
【发布时间】:2019-02-14 01:00:21
【问题描述】:

我正在 Cloud Foundry 上部署一个应用程序。我还在部署之前运行了一个数据库迁移。为此,我的启动命令如下所示:

./run_migration && ./run_app

这在 1 个实例上运行良好,但现在我有 2 个实例,因此启动命令更改为:

[ $CF_INSTANCE_INDEX != 0 ] || ./run_migration && ./run_app

这样迁移只在实例号 0 上运行。这也有效。但是,一旦迁移失败。

2019-02-12T13:56:45.27+0100 [APP/PROC/WEB/0]OUT Exit status 1
2019-02-12T13:56:45.28+0100 [CELL/SSHD/0]OUT Exit status 0
OK

requested state: started
instances: 2/2

     state      since                    cpu     memory        disk
#0   starting   2019-02-12 01:56:36 PM   0.0%    0 of 1G       0 of 1G
#1   running    2019-02-12 01:56:39 PM   15.8%   93.3M of 1G   249.4M of 1G

据我所知,尽管只有一个实例成功启动,但 puch 被认为是健康的。

当并非所有实例都设法启动时,有没有办法让推送失败

【问题讨论】:

  • 您使用的是什么版本的 cf cli?
  • Nm,在最新的cf cli上看到的和你一样。

标签: database-migration cloud-foundry


【解决方案1】:

当并非所有实例都设法启动时,有没有办法使推送失败

我不知道有什么方法可以做到这一点,但您可以随时跟进并在 cf push 完成后检查。

运行cf app <app> | grep 'instances:',您应该会看到正在运行的请求数和总请求数。如果它们不匹配,那就出问题了。

如果您只是想让您的部署脚本失败,那么进行这样的检查(虽然多做一些工作)就足够了。如果还有其他原因,您需要为您的问题添加一些背景信息,以便我们更好地理解用例。

希望对您有所帮助!

【讨论】:

  • 嗯,这都是关于概念的。以前当我推送时会有迁移,然后启动应用程序。如果一切顺利,那么我有一个新版本的应用程序。如果出现故障,那么我仍然是该应用程序的旧版本。现在,当我有两个实例时,似乎无法使用 CF 进行“整体”部署。我必须部署,然后检查一些东西,然后可能会回滚……
  • If something failed then I the still the old version of the app. - 我认为这不是真的。当您推送时,平台将停止您的应用程序,暂存新应用程序,然后尝试启动它。您的应用程序将关闭,如果无法启动,它将处于崩溃状态,直到您修复它。您也许可以使用旧的 droplet 重新启动,但这不是标准推送周期的一部分。
  • 为您的应用程序获得干净的无停机升级需要做的是蓝/绿部署。我不确定这将如何与您在第一个实例上运行的数据库迁移一起工作。
  • 您可能要考虑的另一件事是,当您的应用程序有多个实例时,它们会并行启动。他们不会等待第一个实例开始。因此,如果您的数据库迁移需要一分钟才能完成,那么其他应用程序实例将启动并至少在数据库迁移运行时尝试运行一分钟。
  • 现在最后一件事。如果你还没有看到任务,你可能想看看那些。这是在 CF -> docs.cloudfoundry.org/devguide/using-tasks.html#use-cases 上运行迁移的另一种选择。
猜你喜欢
  • 1970-01-01
  • 2015-12-24
  • 2010-12-14
  • 2022-01-10
  • 2012-12-18
  • 2021-01-06
  • 2021-07-29
  • 1970-01-01
  • 2023-03-16
相关资源
最近更新 更多