到目前为止，所有的代码都已经被构建和标记，并且已经创建了一个Docker镜像。我们现在已准备好将服务部署到10.1.3节中创建的Amazon ECS容器。完成这项部署所做的工作可在travis_scripts/deploy_to_amazon_ecs.sh中找到。代码清单10-7展示了这个脚本的代码。
代码清单10-7 将Docker镜像部署到EC2
echo "Launching $BUILD_NAME IN AMAZON ECS"
ecs-cli configure --region us-west-1 --access-key $AWS_ACCESS_KEY
--secret-key $AWS_SECRET_KEY --cluster spmia-tmx-dev
ecs-cli compose --file docker/common/docker-compose.yml up
rm –rf ~/.ecs
注意
在AWS控制台中，仅显示该地区所在的州/城市/国家的名称，而不是实际的地区名称（如us-west-1、us-east-1等）。例如，如果读者查看AWS控制台，并希望看到北加利福尼亚地区，则没有迹象表明，该地区的名称是us-west-1。
由于Travis在每次构建时都会启动新的构建虚拟机，所以需要使用AWS访问密钥和私密密钥来配置构建环境的ecs-cli客户端。完成之后，可以使用ecs-cli compose命令和docker-compose.yml文件启动到ECS集群的部署。docker-compose.yml通过参数化的方式使用构建名称（包含在环境变量$BUILD_NAME中）。
10.6.8 启动平台测试
构建过程还有最后一步——启动平台测试。在每次部署到新环境之后，都要启动一系列平台测试，以确保所有服务都正常工作。平台测试的目标是在已部署的构建中调用微服务，并确保服务正常工作。
我将平台测试作业与主构建分离，以便平台测试可以独立于主构建被调用。为此，我使用Travis CI REST API以编程方式调用平台测试。travis_scripts/trigger_platform_tests.sh脚本负责完成这项工作。代码清单10-8展示了这个脚本的代码。
代码清单10-8 使用Travis CI REST API启动平台测试
echo "Beginning platform tests for build $BUILD_NAME"
travis login --org --no-interactive
--github-token $GITHUB_TOKEN ⇽--- 使用GitHub令牌通过Travis CI登录，将返回的令牌存储在RESULTS变量中
export RESULTS=`travis token --org`
export TARGET_URL="https://api.travis-ci.org/repo/
carnellj%2F$PLATFORM_TEST_NAME/requests"
echo "Kicking off job using target url: $TARGET_URL"
body="{
"request": {
"message": "Initiating platform tests for build $BUILD_NAME",
"branch":"master",
"config": {
"env": {
"global": ["BUILD_NAME=$BUILD_NAME", ⇽--- 构建调用的JSON体，将两个值传递给下游作业
"CONTAINER_IP=$CONTAINER_IP"]
}
}
}}"
curl -s -X POST ⇽--- 使用curl调用Travis CI REST API
-H "Content-Type: application/json"
-H "Accept: application/json"
-H "Travis-API-Version: 3"
-H "Authorization: token $RESULTS"
-d "$body"
$TARGET_URL
代码清单10-8中做的第一件事是使用Travis CI命令行工具登录到Travis CI并获得一个可用于调用其他Travis REST API的OAuth2令牌。我们将此OAuth2令牌存储在$RESULTS环境变量中。
接下来，为REST API调用构建JSON体。下游Travis CI作业启动了一系列测试API的Python脚本。这个下游作业期望设置两个环境变量。在代码清单10-8中构建的JSON体中，传递了两个环境变量，即$BUILD_NAME和$CONTAINER_IP，这些变量将被传递给测试作业：
"env": {
"global": [BUILD_NAME=$BUILD_NAME",
"CONTAINER_IP=$CONTAINER_IP"]
}
脚本中的最后一个操作是调用运行平台测试脚本的Travis CI构建作业。这是通过使用curl命令为测试作业调用Travis CI REST端点来完成的：
curl -s -X POST
-H "Content-Type: application/json"
-H "Accept: application/json"
-H "Travis-API-Version: 3"
-H "Authorization: token $RESULTS"
-d "$body"
$TARGET_URL
这段平台测试脚本（Travis CI构建脚本）被单独存储在一个名为chapter10-platform-tests的GitHub存储库中。这个存储库有3个Python脚本，它们用于测试Spring Cloud Config服务器、Eureka服务器和Zuul服务器。Zuul服务器平台测试还测试许可证服务和组织服务。就测试服务的各个方面来说，这些测试并不全面，但是它们确实对服务执行了足够多的测试，以确保服务能够正常工作。
注意
本章不打算介绍这些平台测试。原因是这些测试很简单，介绍这些测试并不会为本章增添太大的价值。
10.7 关于构建和部署管道的总结
当本章（和本书）结束时，我希望读者对构建一个构建和部署管道的工作量有所了解。一个功能良好的构建和部署管道对于部署服务至关重要。微服务架构的成功不仅取决于服务中涉及的代码，还包括了解以下几点。
这个构建/部署管道中的代码是为了本书的目的而简化的。一个好的构建/部署管道将更为通用化。它将得到DevOps团队的支持，并分解成一系列独立的步骤（编译→打包→部署→测试），开发团队可以使用这些步骤来“挂钩”他们的微服务构建脚
本。
本章中使用的虚拟机成像过程过分简单化，每个微服务都使用Docker文件来定义将要安装在Docker容器上的软件。许多商家使用诸如Ansible、Puppet或Chef等服务提供工具，将操作系统安装和配置到虚拟机或正在构建的容器上。
本书的应用程序的云部署拓扑被整合到一个服务器上。但是，在实际的构建/部署管道中，每个微服务都有自己的构建脚本，并且可以独立地部署到集群的ECS容器中。
10.8 小结
构建和部署管道是交付微服务的关键部分。一个功能良好的构建和部署管道应该允许在几分钟内部署新功能和修复bug。
构建和部署管道应该是自动的，没有直接的人工交互来交付服务。这个过程的任何手动部分都代表了潜在的可变性和故障。
构建和部署管道的自动化需要大量的脚本和配置才能正确进行。构建所需的工作量不容小觑。
构建和部署管道应该交付一个不可变的虚拟机或容器镜像。服务器镜像一旦创建了，就不应该被修改。
环境特定的服务器配置应该在服务器建立时作为参数传入。