“上穷碧落下黄泉”，关于DevOps的“三生三世，十里桃花”

easthomeRT

“上穷碧落下黄泉”，DevOps的三生三世前是ITIL，前世是Agile,后世可能要和AI发生“不得不说的故事了”！

       与ITIL三生三世的孽缘可以问杨幂，那为何DevOps的前世是Agile呢？因为DevOps的DNA与Agile一致的，它们都以敏捷价值观为依归。DevOps的价值观相对于敏捷宣言略有所改进，比如把“可工作的软件”改成“关注发布给客户的业务或者软件的整体”，都高于“详尽的文档”的理念是一致的。都把尽早给客户交付有价值的软件作为此生的执念，其观念的一致性可见其同宗同源的本质。

       除此之外，Agile所关注的快速迭代和DevOps所提倡的持续交付都强调自动化（Automation）。大家都知道自动化是要靠工具的。比如我们耳熟能详的持续集成工具Jenkins、分布式(DVCS)版本控制的工具Git和运行状态监控工具Nagios等。企业可以通过这些工具链来开发属于自己的微服务，并把微服务部署到Docker容器上。

       以下是来自澳洲某公司的DevOps工具链示例：

      （原文详见“近处的墨村”的微信公众号）

• 代码仓库：Github企业版；
• 构建和部署工具：Buildkite和Jenkins，还有Bamboo；
• 容器平台：微服务用Docker进行打包；
• 环境：公司核心Service部署在AWS（Amazon Web Services）中，有独立的测试、开发、预生产和成产的云环境，彼此安全隔离；
• 日志管理：Splunk。所有微服务的日志都能够通过Splunk Agent发送到集中的Splunk服务器，以方便程序猿Trouble Shooting。完全避免了登陆到不同的机器收集log的窘境；
• 监控：使用AWS Cloudwatch监控AWS的服务，比如某个SQS对应的dead-letter queue里是不是收到了消息，或者AWS Lamda执行是不是有错误等；NewRelic用来监控网络和设备的性能；Nagios提供服务可用性监控，提供心跳API供Nagios的主动模式使用；通过设置接收相应的消息格式，Nagios也可以使用被动模式监控微服务。一旦无法Ping通某个微服务或者在一定时间内没有收到微服务的消息，那么会马上产生一个PagerDuty告警来通知相关人员；
• 告警：PagerDuty。前面提到的监控工具都可以配置相应的条件来产生告警，产生的告警都会通过PagerDuty用邮件，Slack，电话和短信的方式通知给当时的值日人员。PageDuty虽然是全天24小时运行，也只有极少部分高优先级的告警才会在非工作时间发出；
• 协同工作：Leankit。
  
  

       除此之外，微服务则是当今运维届的“肖申克的救赎”。定义好API接口的微服务可以独立存在，独立部署且具备可扩展性。微服务作为一种全新物种，我们在开发它时也需要遵循既定的原则，参考如下：

• 基准代码： 一份基准代码，多份部署；
• 依赖： 显式声明依赖关系；
• 配置： 在环境中存储配置；
• 后端服务： 把后端服务当作附加资源；
• 构建，发布，运行： 严格分离构建和运行；
• 进程： 以一个或多个无状态进程运行应用；
• 端口绑定： 通过端口绑定提供服务；
• 并发： 通过进程模型进行扩展；
• 易处理： 快速启动和优雅终止可最大化健壮性；
• 开发环境与线上环境等价： 尽可能的保持开发，预发布，线上环境相同；
• 日志： 把日志当作事件流；
• 管理进程： 后台管理任务当作一次性进程运行。
  
  

       微服务的特定原则与要求可能会在运营管理上增加额外的复杂度，解决之道就是自动构建和部署。DevOps的工具链恰恰提供了发布流水线和自动化部署功能，Docker容器恰恰是微服务的理想载体。

       未来可以想见，DevOps会因“微服务和容器”而更加精彩，传统运维的卫道者也会因“人面不知何处去，桃花依旧笑春风”而日趋无奈。

本文出自东方瑞通刘通老师，转载请注明！

更多行业干货、技术文章，请关注公众号：东方瑞通终身学习~