基于微服务的Real DevOps实践
最值得一提的是Delivery Engineering开发的rea-shipper.
以我们一个实际的service charge-central为例,登陆到EC2 instance之后,可以看到正在运行的几个container. Global Infrastructure & Architecture 团队负责基础设施建设,管理维护并开发相应的工具,包括网络、数据中心、AWS账号的管理、Splunk的集成等.比如,去年悉尼大雨,Amazon的机房被水淹了,澳洲大批网站受到影响,也包括我们公司的一小部分,当时苦了GIA team的人了. 所以全工具链的配置和开发是Global Infrastructure & Architecture 和Delivery Engineering的职责,而作为程序猿的锤子,则是工具链的使用者.下面就说说程序猿所参与的DevOps日常. 程序猿DevOps日常1. Coding前面提到过代码库使用github企业版,采用github flow. 微服务需要的部署脚本和AWS Cloudformation的信息,提供给不同监控工具的接口,fried Docker image 定义等,也都是代码的一部分,需要开发人员完成. 2. 构建和部署构建和部署就以Buildkite为例子,这是一个微服务的buildkite脚本. 这个流程里代码检查和单元测试自动化起来很容易,那么怎么做整合测试?REA基于Ian Robinson提出的用消费者驱动的契约进行面向服务开发的模式开发了 开源的Pact 测试框架,用轻量级的契约测试来代替厚重的集成测试.Pact在消费端用单元测试的形式(更轻)来生成 pact 契约,服务端通过验证契约来保证两者稳定集成.一旦有一端契约未经协商发生改变,那么Pact测试就会失败. 构建成功之后,会把微服务打包成Docker Image然后上传到Docker Registry.我们会选择在Delivery Engineering提供的基准Docker Image之上来打包,这是一个微服务的Dockerfile的例子: 用这种方式,在buildkite上打包并上传到Docker Registry的时间小于三分钟. 部署时,脚本会调用rea-shipper.不同的环境下,Buildkite会选择不同的Agent进行部署:Test 环境的non-prod-corp:default和Prod环境的prod-corp:default.部署的时间通常10分钟以内,下面是一个微服务部署到test(6分1秒)和prod(5分43秒)的时间,图中能够看到Cloudformation更新的步骤. 尽管是全自动的部署,考虑到生产环境的重要性,我们还是选择谨慎地Block,需要某个开发人员手动触发.触发的时间没有特别的规定,只是在我们的kanban中,deploy是最后一步,这意味着只有真正部署到生产环境,这个卡片才算完成.如果部署过程中出现失败,rea-shipper不会切换运行中的ASG(Auto Scalling Group),业务并不会受到影响.如果部署的新版本发现bug需要紧急回滚,可以很容易地根据Docker Image的版本找到相应的Image进行部署. 3. 运维日常的运维如下图所示: 需要处理的问题一般有两种:
(编辑:济南站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |