减少持续交付的运输时间，尤其是在修补程序

Question

我正在使用一些技术和服务实现持续交付，例如docker，shippable，AWS Elastic beanstalk等。但是，将应用程序自动部署到生产服务器需要几（5~7）分钟，从推送到git存储库。

它非常整洁，但有时候我可能想立即对修补程序进行微小的更改，然后这个5到7分钟的时间太长了，等待，因为它主要是关于构建docker镜像并上传/下载它，或者运行npm test和npm install命令。有时我想跳过这些步骤并立即应用更改。

我正在考虑几个想法但他们有一些问题：

• 通过服务器中的HTTP打开一些秘密的URI接口，用于修补和重启自己
  • 这有两个问题;我们必须为容器提供不同的github密钥，并且由于负载均衡器后面有多个实例，所以要确保修补每个实例都太复杂了
• 体力劳动。直接连接到实例并对其进行修补
  • 但我们推出了持续交付系统以避免这种情况

这种问题有最佳做法吗？

Answer 1

对于分期，我们使用基于SCP的部署，你也可以使用capistrano，phing /任何套件来形式化它。

因此，如果您需要按照上面提到的方式进行修补，请在您的应用代码容器上安装SSHd服务器并以此方式进行部署。

因此，您混合了基于映像的部署以及基于修补程序的部署。您应该始终确保还在后台构建图像。否则，容器重制将改变您的状态/回滚修补程序。