与AWS管理服务最接近的是CodeDeploy。有了它,您可以通过命令行或Web控制台在实例中协调部署。但是CodeDeploy只是从S3或GitHub拉到文物,到目前为止。截至目前,CodeCommit似乎从其他相关服务亚马逊完全隔离,就像CodePipeline和CodeDeploy,所以它似乎并没有成为一个不错的选择。但是,当然,亚马逊路线图是整合所有它们(不这样做是毫无意义的)。所以,现在,你会更好地使用GitHub比CodeCommit。
但是,考虑不使用GitHub上,那么你就需要你们之间的信息库中的CI(持续集成)解决方案和CodeDeploy,从源头上拉代码,可能生成或运行测试,它推到S3并告诉CodeDeploy关于它。例如,有CodeShip,这可以做到这一点,并与很多外部服务集成在一起。或者你甚至可以拥有自己的CI服务器,就像Jenkins一样,为你“粘贴”角色。 (詹金斯可能是最灵活的一个,因为它是开源的,并且可能有插件的所有内容。)
所以,打破一点点,你的工作流程是这样的事情:
- 推码到您的资料库;
- 每当发生事件(某个分支上的提交或新标签应该可配置)时,您将它拉出来,运行任何您想要或需要的东西(构建,测试,打包它)并推送它到S3(作为压缩文件,通常);
- 取决于你是如何设置的东西,你CI告诉代码部署在您EC2部署情况下马上,或者它只是告诉它有一个新的版本可用,让你触发部署,手动,通过Web控制台上的CLI,只要你想。
(实际上,CodeDeploy不压码EC2实例。相反,每个EC2实例必须运行代理哪些池定期CodeDeploy服务器,以了解是否有新的东西在本地应用。总之,CodeDeploy坐标,从代理获得反馈,所以它只是工作,好像它是100%为活性CodeDeploy侧和100%被动的情况下侧)。
最 “干净” 的AWS的解决办法是CodeCommit - >CodePipeline - >CodeDeploy,或者只是CodeCommit - >CodeDeploy,但这些服务并未完全集成目前为止。
在你的情况,最简单可行的解决办法,现在是Github上 - >CodeDeploy。任何不同的东西都会需要一些中间步骤,如我提供的示例(CodeShip,Jenkins等)。
我希望当我问这个问题时,我有这个答案。最后,我使用Fabric在我的EC2车队中运行git clone命令。 –
如果有人正在尝试此操作并遇到“配置文件默认未找到”的问题,请尝试使用''''指定空白配置文件。您的配置文件可能/应该存储在EC2实例的环境变量'$ AWS_DEFAULT_PROFILE'中。 –
@RobbieAverill您可以完全忽略'--profile default'位(并且正如您所说的,如果您没有默认配置文件,将其设置为默认值将不起作用) –