使用AWS时,通过AWS CodeDeploy将应用程序部署到新创建的实例似乎是一种很好的方式。其工作原理如下:
现在,当应用程序包(例如jar或debian软件包)部署到部署组时,它将自动部署到自动扩展组中启动的新实例。
我的问题是:这种部署策略如何适合像Travis CI这样的CI工具?
具体做法是:
答案 0 :(得分:4)
tl; dr版本:
好的,这是长版:
我建议您尝试Deployment Walkthrough或查看文档中的Concepts。它可以帮助您更快地熟悉CodeDeploy。
如果您不想,您不必使用CodeDeploy的AutoScaling组。具有AutoScaling集成的CodeDeploy允许您管理需要动态更改大小的队列与部署到它们的代码分开,但这不是使用CodeDeploy的要求。您也可以手动启动一些EC2实例,安装主机代理,然后将它们标记到部署组中 - 但是它们不会像AutoScaling实例那样在启动时自动部署。在任何一种情况下,您始终可以创建车队范围的部署。
您必须做一些工作才能将其与CI工具集成。 CodeDeploy不直接管理您的构建工件,因此您的构建过程将需要这样做。要进行自动部署,您需要:
appspec.yml
创建存档包,处理安装/升级所需的任何脚本以及构建工件。您可能希望将CodePipeline视为与CodeDeploy集成的持续投放系统的示例。
CodeDeploy使用部署配置来控制它部署到机群中实例的积极程度。 (对于自动部署,此配置会被忽略,因为每个实例都是单独处理的。)CodeDeploy将使部署失败并停止部署到新实例(如果它不会在不违反部署配置中的约束的情况下使另一个实例失败)。
有三个built in部署配置,您可以通过CLI或API创建自己的部署配置,如果您需要另一个配置。要一次只部署一个实例,您可以使用CodeDeployDefault.OneAtATime
部署配置,在任何给定时间最多允许一个不健康的主机。
答案 1 :(得分:0)
对于其他人(例如我),寻找有关如何将Travis-CI与CodeDeploy实际集成的示例:
appspec.yml
文件和用于部署的任何脚本都应打包在您的应用程序捆绑包中(以下示例中为latest.zip
)。以下.travis.yml
配置对我有用:
script: npm run build
before_deploy:
- zip -r latest dist/*
- mkdir -p dpl_cd_upload
- mv latest.zip dpl_cd_upload/latest.zip
deploy:
- provider: s3
access_key_id: "XXXX"
secret_access_key: "YYYYY"
bucket: "deployments-bucket-name"
local_dir: dpl_cd_upload
skip_cleanup: true
- provider: codedeploy
access_key_id: "ZZZZZ"
secret_access_key: "WWWW"
bucket: "deployments-bucket-name"
key: latest.zip
bundle_type: zip
application: CodeDeployAppName
deployment_group: CodeDeployDeploymentGroupName
以下示例非常有用: https://github.com/travis-ci/cat-party/blob/master/.travis.yml