我认为脚本将运行当一个新盒子上线时，这将使我最新的代码下降。该脚本还应该执行我的数据库迁移吗？我不确定如何才能在一个盒子上运行它？
#1 楼
您如何进行部署？ Nuke +重建ASG（一次是一个节点，还是一次替换整个组），或者您是否有一个脚本可以重新部署所有活动节点？此外，如何您是在触发部署吗？
理想情况下，您希望从某种形式的CI服务器（例如Bamboo或Jenkins）运行/触发部署。如果执行此操作，则可以从构建服务器（或其组件构建代理实例）运行数据库迁移。
例如，这将使您可以更好地控制环境。 ，如果部署失败，则从快照还原数据库。
评论
目前，我们仅通过SSH进入生产环境并提取代码。实际上，我认为大多数时候我们只有一个节点。我当时以为我们会使用代码部署。我们还没有太多的AWS / Devops经验，只是试图找到一种简单的方法来开始使用负载平衡和ASG。
–米克
17年9月27日在7:49
AWS CodeDeploy很棒，一旦规模扩大并开始使用更多服务器，便可以长期扩展。目前，如果您正在手动进行SSH部署，则始终可以使用单独的脚本来运行数据库迁移。即您将通过CodeDeploy运行普通的部署脚本，然后手动从一个节点上迁移数据库。如果您不打算构建可以在任何时候运行Liquibase的CI服务器，那么您还可以研究其他软件，例如Datical：aws.amazon.com/blogs/devops/…
– Maplebird
17年9月27日在18:35
#2 楼
许多orm的商店迁移状态都在数据库本身中，但是如果您“手动”执行，则也很难构建自己。只是有一个“ migrationstate”表，其中存储了所有已执行的迁移。这样，当节点联机时，它可以简单地对照其本地“ migrations”文件夹检查该表，并执行丢失的内容-这只会导致版本升级后仅第一个节点执行迁移。附带说明：CloudFoundry通过允许秤集中的每个实例（节点）访问其标识符来解决此问题。第一个为0，下一个为1，依此类推。这样一来，节点即可知道节点是否为第一个，并可以执行迁移。我认为ASG没有相同之处。
评论
我假设通过从单片式迁移到自动缩放，您正在专门指代数据库。您正在使用AWS RDS吗？如果没有，您是否调查过？ aws.amazon.com/blogs/database / ...是的，我们正在使用RDS。否，我正在扩展和平衡应用程序运行所在的EC2实例。
一种解决方案是使用诸如flyway或liquibase之类的东西可以在数据库上运行幂等更新，这样，每个开始的节点都可以尝试更新数据库，并且如果迁移已经发生，则什么也不做。
合理的警告，Flyway仅在迁移运行后才将其标记为已完成。如果您从多个节点同时启动Flyway，则很有可能他们会尝试一次执行相同的迁移，这可能会引起问题。