travis-ci自动部署_如何使用Travis CI部署（几乎）零恐惧的Cloud Foundry应用

travis-ci自动部署

by Robin Bobbitt

罗宾·波比(Robin Bobbitt)

如何使用Travis CI部署(几乎)零恐惧的Cloud Foundry应用 (How to deploy your Cloud Foundry app with (almost) zero fear using Travis CI)

Application deployments to the cloud should be painless. We should be able to deploy new code continuously, as often as we want, without fear. The blue-green deployment model enables us to do this.

将应用程序部署到云应该很轻松。 我们应该能够连续不断地部署新代码，而不必担心。 蓝绿色的部署模型使我们能够做到这一点。

I recently joined a new team at work that was deploying node.js Cloud Foundry applications to the IBM Cloud using Travis with the Bluemix CloudFoundry deployment provider. This works great for quickly and easily setting up your deployment with just a few parameters.

我最近加入了一个新的团队，该团队正在使用Travis和Bluemix CloudFoundry部署提供程序将node.js Cloud Foundry应用程序部署到IBM Cloud。 这对于仅需几个参数即可快速轻松地设置部署非常有用。

Unfortunately, every deployment means an outage of your application as the existing version stops and the new version starts up. Also, there is no verification that the new code is good before the old code is blown away.

不幸的是，由于现有版本停止并且新版本启动，因此每次部署都意味着您的应用程序中断。 另外，在旧代码被吹走之前，没有验证新代码是否正确。

With the blue-green deployment technique, your current application (Blue) continues to run and take network traffic. While your new application code (Green) is deployed on a temporary route. The new Green application can be validated on the temporary route. If there are any problems, the deployment stops. The Blue application continues to serve traffic uninterrupted. Once the Green application is vetted, the router is updated to point at the Green application. The Blue can be stopped.

使用蓝绿色部署技术，您当前的应用程序(蓝色)将继续运行并获取网络流量。 新的应用程序代码(绿色)部署在临时路径上时。 可以在临时路径上验证新的绿色应用程序。 如果有任何问题，则部署将停止。 Blue应用程序继续为流量提供不间断的服务。 审核Green应用程序后，路由器将更新为指向Green应用程序。 蓝色可以停止。

In this manner, there is always a version of the application available to take traffic. Any problems in the deployment or runtime of the new code will not impact the availability of your application.

以这种方式，始终有一个应用程序版本可用于获取流量。 新代码的部署或运行​​时中的任何问题都不会影响应用程序的可用性。

I immediately started looking around for a way to blue-green deploy our applications. In the interest of writing as little custom code as possible, I decided to leverage the cf-blue-green-deploy plugin for the Cloud Foundry command-line interface (CLI). I will share how I did this here.

我立即开始寻找一种蓝绿色部署我们的应用程序的方法。 为了编写尽可能少的自定义代码，我决定将cf-blue-green-deploy插件用于Cloud Foundry命令行界面(CLI)。 我将在这里分享我的操作方式。

I’m going to assume if you landed here you are probably past the point of simply “getting started” with Travis. I won’t be covering those details here.

我要假设，如果您降落在这里，您可能已经超出了Travis的“入门”范围 。 我不会在这里介绍这些细节。

If you’re not interested in following along and just want to get straight to the goods, you can clone my working sample from GitHub.

如果您对后续操作不感兴趣，而只想直接了解它们，可以从GitHub克隆我的工作示例。

安装CF CLI和蓝绿色插件 (Installing the CF CLI and blue-green plugin)

Since we’re not using the Cloud Foundry deployment provider, we have to install the Cloud Foundry CLI ourselves, as well as the blue-green deploy plugin. We can do this in the before_deploy phase of the Travis build lifecycle.

由于我们没有使用Cloud Foundry 部署提供程序 ，因此我们必须自己安装Cloud Foundry CLI和蓝绿色的部署插件。 我们可以在Travis构建生命周期的before_deploy阶段中执行此操作。

Note that the before_deploy phase runs before each deployment provider. If you are doing additional things in your deploy phase, you may want to move these steps into the after_success phase (which runs just once after a successful build) to avoid unnecessary extra installs. You could also move these steps into the deploy script itself, which we will be writing next.

请注意， before_deploy阶段在每个部署提供程序之前运行。 如果要在部署阶段执行其他操作，则可能需要将这些步骤移至after_success阶段(成功构建后仅运行一次)，以避免不必要的额外安装。 您也可以将这些步骤移到部署脚本本身中，我们将在接下来编写。

Regardless of where you put it, here is the script:

无论放在何处，以下都是脚本：

- echo "Installing cf cli"- test x$TRAVIS_OS_NAME = "xlinux" && rel="linux64-binary" || rel="macosx64"; wget "https://cli.run.pivotal.io/stable?release=${rel}&source=github" -qO cf.tgz && tar -zxvf cf.tgz && rm cf.tgz- export PATH="$PATH:."- cf --version

- echo "Installing cf blue-green deploy plugin"- cf add-plugin-repo CF-Community https://plugins.cloudfoundry.org- cf install-plugin blue-green-deploy -r CF-Community -f

The command to install the CLI comes directly from the CloudFoundry DPL source. The commands to install the blue-green deploy plugin come from the plugin’s README.

安装CLI的命令直接来自CloudFoundry DPL 源 。 安装蓝绿色deploy插件的命令来自该插件的README 。

调用蓝绿色部署 (Invoking the blue-green deploy)

To invoke the blue-green deploy, we will use the script deployment provider, which executes a provided command and checks for zero status as indication of success.

为了调用蓝绿色的部署，我们将使用脚本部署提供程序 ，该脚本执行提供程序执行提供的命令并检查零状态是否成功。

deploy:# on update to master branch we deploy to Cloud Foundry- provider: script  skip_cleanup: true  script:  ./scripts/cf-blue-green-deploy.sh blue-green-cf-travis manifest.yml prod  on:    branch: master

Note that skip_cleanup is set to true. Without this, the cf CLI and blue-green deploy plugin you just installed would be removed prior to the deploy running.

请注意， skip_cleanup设置为true 。 否则，您刚安装的cf CLI和蓝绿色部署插件将在运行部署之前被删除。

The cf-blue-green-deploy.sh script logs in to the Cloud Foundry API and invokes the blue-green deploy plugin. In addition to specifying an application name and manifest file, you can also pass a smoke test script to the blue-green deploy plugin. The plugin will call the smoke test script after the new application code has been deployed, but before the application route is switched to the new application. This allows you to run any number of tests against the new code before any real traffic accesses it.

cf-blue-green-deploy.sh脚本登录到Cloud Foundry API并调用blue-green deploy插件。 除了指定应用程序名称和清单文件之外，您还可以将冒烟测试脚本传递给蓝绿色的deploy插件。 在部署了新的应用程序代码之后，但在将应用程序路由切换到新应用程序之前，该插件将调用冒烟测试脚本。 这使您可以在任何实际流量访问新代码之前对新代码运行任何数量的测试。

The smoke test script is passed a single argument. The argument is the temporary URL of the newly deployed application. If the smoke test script exits with success, the blue-green deploy will complete by switching the route to the new application. If the smoke test script exits with a failure, traffic continues to flow to the old version of the application. The new version remains available for troubleshooting.

烟雾测试脚本传递了一个参数。 参数是新部署的应用程序的临时URL。 如果烟雾测试脚本成功退出，则通过将路由切换到新应用程序来完成蓝绿色部署。 如果冒烟测试脚本因失败而退出，流量将继续流向该应用程序的旧版本。 新版本仍可用于故障排除。

In my example project, the smoke test script invokes a /version API and verifies that it returns with a 200 status code.

在我的示例项目中，冒烟测试脚本调用/ version API并验证它是否返回200状态代码。

In our real projects at work, we run a Postman collection against the newly deployed app. You want your smoke test suite to be sufficiently big enough that you feel confident in your new code, but not so big that it takes a long time to complete a deployment or flaky tests block you from completing a successful deploy.

在工作中的实际项目中，我们针对新部署的应用程序运行Postman集合。 您希望烟雾测试套件足够大，以使您对新代码充满信心，但又不要太大，以至于需要很长时间才能完成部署，或者测试不稳定会阻止您成功完成部署。

You could optionally run a more comprehensive suite of regression tests as an after_deploy step, after your new code is live.

新代码上线后，您可以选择作为after_deploy步骤来运行一套更全面的回归测试。

在IBM Cloud中进行蓝绿色部署的副作用 (Side effects of a blue-green deploy in IBM Cloud)

There are a few nuances of this approach to be aware of if you are deploying to IBM Cloud. Because you are creating a new CF application instance each time you blue-green deploy, your application guid will change. If you use the Availability Monitoring service, your configured tests will be lost when your guid changes.

如果要部署到IBM Cloud，需要注意一些这种方法的细微差别。 因为每次蓝绿色部署时都在创建一个新的CF应用程序实例，所以您的应用程序guid将会更改。 如果使用“可用性监视”服务，则当Guid更改时，配置的测试将丢失。

To work around this, stand up a permanent dummy application. Write your tests for your blue-green deployed app in this dummy application’s configuration. You can specify any URL when you write your Availability Monitoring tests.

要解决此问题，请建立一个永久的虚拟应用程序。 在此虚拟应用程序的配置中为蓝绿色部署的应用程序编写测试。 编写可用性监视测试时，可以指定任何URL。

Similarly, if you use the Log Analysis service, you’ll see that when you click the “View in Kibana” link on your application dashboard’s Logs tab, you will be launched into a Kibana search on the application guid string. Any application logs from before your most recent deployment will not show up. To work around this, you can simply filter on the application name rather than the application guid.

同样，如果使用Log Analysis服务，则将在单击应用程序仪表板的“日志”选项卡上的“在Kibana中查看”链接时看到，将在应用程序guid字符串上启动Kibana搜索。 最新部署之前的任何应用程序日志都不会显示。 要解决此问题，您可以仅过滤应用程序名称而不是应用程序guid。

Another service that has the same issue is Auto-Scaling. Each time a new application is stood up as part of the blue-green deploy, it needs its Auto-Scaling policy reconfigured. There is a command line interface available that you presumably could use to script this, but I have not yet had a need to try this.

具有相同问题的另一项服务是自动缩放。 每次将新应用程序作为蓝绿色部署的一部分进行安装时，都需要重新配置其自动扩展策略。 有一个命令行界面可用，您大概可以用它来编写脚本，但是我还没有必要尝试这个。

If any of these issues are non-starters for you, you always have the option of writing a custom blue-green deploy script that leverages two permanent CF applications, a blue, and a green. These two apps would take turns being live and being idle. You could configure both applications with an auto-scaling policy, for example.

如果您对这些问题都不满意，那么您始终可以选择编写自定义蓝绿色部署脚本，该脚本利用两个永久CF应用程序(一个蓝色和一个绿色)。 这两个应用程序将轮流运行并处于空闲状态。 例如，您可以使用自动缩放策略配置这两个应用程序。

Of course, this approach means you can’t take advantage of the blue-green deploy plugin described in this post, and you need to maintain your own custom script.

当然，这种方法意味着您不能利用本文中介绍的蓝绿色部署插件，而需要维护自己的自定义脚本。

结语 (Wrapping up)

In this post, we’ve examined how we can accomplish a low risk, zero-downtime deployment using Travis and the cf blue-green deploy plugin.

在本文中，我们研究了如何使用Travis和cf blue-green deploy插件完成低风险，零停机时间的部署。

In a real project, we would have even greater assurances, as we would have a suite of unit tests in place, and errors there would fail the Travis build before the deployment had a chance to run. We would also potentially have dev and staging branches configured to deploy to their own respective spaces in our Cloud Foundry organization, allowing us to validate and stabilize the application as necessary before promoting changes to production.

在真实的项目中，我们将拥有更大的保证，因为我们将拥有一套单元测试，并且在部署有机会运行之前，Travis构建中的错误将失败。 我们还可能会将dev和staging分支配置为部署到Cloud Foundry组织中各自的空间，从而使我们能够在促进生产变更之前根据需要验证和稳定应用程序。

Thanks for reading! This is my first Medium story, and I hope you found it useful.

谢谢阅读！ 这是我的第一个中型故事，希望您发现它有用。

翻译自: https://www.freecodecamp.org/news/how-to-deploy-your-cloud-foundry-app-with-almost-zero-fear-using-travis-ci-926697fff8f6/

travis-ci自动部署