极牛技术实践分享活动
极牛技术实践分享系列活动是极牛联合顶级 VC、技术专家，为企业、技术人提供的一种系统的线上技术分享活动。
每期不同的技术主题，和行业专家深度探讨，专注解决技术实践难点，推动技术创新，每周三 20 点正式开课。欢迎各个机构、企业、行业专家、技术人报名参加。
嘉宾介绍
代闻，亚马逊 AWS 解决方案架构师, 负责基于 AWS 的云计算方案架构的咨询和设计，同时致力于 AWS 云服务在国内的应用和推广，在大规模后台架构、物联网应用、媒体行业转型、企业混合 IT 和自动化运维等方面有着广泛的设计和实践经验。在加入 AWS 之前，在思科中国担任系统工程师，负责方案咨询和架构设计，在企业私有云和基础网络方面有丰富经验。曾任 IBM 中国软件开发中心软件工程师，从事企业软件和移动平台的开发工作。
在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备 DevOps 能力的组织中，应用程序发布的风险却很低。目前开发人员对于 DevOps 的认识深浅不一，本期请到了亚马逊架构师代闻来为我们实例解析 DevOps。
01/DevOps 简介和适用场景
DevOps 是一个软件开发的方法，目的是为了提高内部运维能力，也就是说，DevOps 是运维的一个方式，只不过通过软件实现了更高的自动化。DevOps 一词，Dev 是形容词，Ops 是主体，DevOps 的兴起，并不是技术人员自娱自乐，而是业务需求推动的结果。
传统的瀑布式开发，周期长，风险大；现在的初创公司推崇的是敏捷开发、快速迭代
但是敏捷开发仅解决了软件开发的问题，如果集成、部署、平台搭建没有做相应的调整，Ops 将会是整个流程的短板。
当然，这里面涉及到另一个话题，就是微服务。当软件开发的各个团队负责各自服务，彼此通过约定接口调用实现松耦合，软件集成和部署就可以细化到各个服务，然后通过工具和平台实现持续的集成、部署、平台构建，平台的敏捷程度就会大大提升。其中，通过代码、脚本来加速集成、部署和平台构建的过程，可以成为 DevOps。
DevOps 需要关注的方面很多，主要有两个重点：
第一，文化和组织
关于 DevOps 文化和组织，听起来比较虚，但却是 DevOps 应用的核心。
传统公司里，开发和运维之间有既成组织架构的界限，向 DevOps 转型需要付出很多努力
初创公司负担少，更容易接受 DevOps。
DevOps 要求开发和运维之间互相协作，以业务为共同目标，实现快速迭代，平台的 feature 从设计、开发到交付的整个流程，都有担任 ops 角色的同事（也可能兼开发）参与，确保程序在设计初始就已经考虑到基础架构的优化，以及后续的内部 OP 事宜。
同时，担任 DevOps 角色的同事的技能要比以往更多一些，除了基本的服务器、网络、存储知识，还需要有代码或脚本能力。
综合下来，可以看到三种模式：
1）开发兼运维：这是在初创公司最常见的模式，5 人以下的团队很多是这样的；
2）每个产品团队有 OP 同事，但没有运维 Team。这是开始发展的公司，需要有专人做 OP，但是 op 还是在研发的 team；
3）独立的 OP Team，适用于已经有一定规模的公司。比如，在 AWS 的用户里，我常看到 80 人以上的技术团队，一半都会有考虑将基础架构管理独立出来。
但无论哪种模式，都要求 Ops 同事除了基本系统管理以外，能够有脚本或代码的能力，能够有基于云做平台架构的能力。
云计算将最底层的数据中心运维做完了，基于云做 DevOps 和架构设计也就成了自然而然的事情。比如，在猎豹移动，海外运维团队 10 人以下，管理着上万的 VM，以及各类平台服务，DevOps 是必须的。
另外，如果组织发展壮大后，在 DevOps 过程里有一些需要仲裁的事情（如上线时间和方式），或者有些标准需要制定（如版本、平台环境等），建议有一个技术委员会（如果组织小，也许就一两个人）来作仲裁。在 Netflix，这个委员会叫 CORE Team，大家可以 Google 以下 Re:invent 2015 大会上 Netflix 的分享。
第二，工具和平台

既然 DevOps 是以软件开发的方式来解决运维自动化，先看看软件开发的工具和平台。首先最底层的 Platform 就是服务器和操作系统，操作系统有 API 是一切的基础，然后操作系统的 API 包装成系统编程的 SDK，再然后才有高级语言和解释型语言运行的框架，最上面一层是代码，同时，代码也可以越过封装，通过 Native 调用的方式来调用更底层的接口。
02/AWS DevOps 介绍

公有云对 DevOps 的支持，其实是一个原理。以 AWS 为例，Platform 就是底层的基础设施，AWS 通过技术平台实现了基础设施虚拟化，并提供 API，这是最核心的部分，没有 API，一切无从谈起。这个 API 就是 Restful API，这也是 Amazon Web Services 的由来，因为 Restful API 就是 web services，AWS 做了很多的工作，把 restful API 包装成 java、python、php、ruby 等 sdk，到这里已经可以通过编程的方式控制基础设施了，但是为了更加易用，AWS 提供了各类的 service 来作为自动化框架，如基于 Chef 的 opsworks，快速部署的 Elasticbeanstalk，将基础设施代码化的 cloudformation 等。
通过这一层的搭建，用户只需要在配置文件或模板或脚本里指定资源，就可以完成部署和控制，因为 Framework 具备执行和验证的逻辑。

这是使用 python sdk （名字叫 boto）启用二次
启用 EC2 的代码
逻辑和行文需要自己控制，已经很好用了，比如你要启用 20 台，每台的参数可能会有不同，就可以通过写 python 脚本的方式，快速搭建，但是行文是自己控制的。

这是一个 cloudformation 模板，里面也是启用一个 instance，但是，这里面只有资源描述，具体的操作逻辑是 cloudformation 这个服务来进行的。
通过框架服务，在自动化的基础上，可以进一步实现标准化。

这个图是 AWS 的 DevOps 服务在开发运维整个生命周期的支持情况。
三个黄色的框，分别是 CodeCommit、CodePipeline 和 CodeDeploy。
CodeCommit 是一个托管的 Git 仓库，用于托管代码，好处是 AWS 托管服务，高可用，完全支持 git。
CodePipeline 是一个集成编译和测试的工作流服务，可以联合源代码仓库、编译服务器（如 genkins）、部署服务（如 codedeploy）工作，将部署流程可视化，并能管理复杂的条件分支。
CodeDeploy 是一个代码部署服务，通过在 EC2 虚拟机上部署 Agent，可以实现分批和滚动部署，并可以通过配置文件实现部署前后的检测和验证脚本执行。
以上三个工具都可以和第三方工具集成，在部署（deploy）、平台构建（Provision）和监控（Monitor）方面，AWS 服务很多。
Cloudformation 其实是通过 json 描述的模板来实现基础架构的搭建，你可以把 cloudformation 模板也存入 Git 仓库，每一次基础设施修改都是通过修改 cloudformation 模板，然后应用来改动（cloudformation 可以自己判断差别和资源依赖，实现最小化变更范围）。然后再存入 git 的时候，在注释中写明更改原由。cloudformation 可以做到基础架构代码化，非常重要。
监控方面，Cloudwatch 可以监控 AWS 各类服务的数据，比如 EC2 的 CPU、网络、存储 IO，ELB 的连接数、排队数、溢出数，数据库服务的 IO、延迟等等。
AWS Opswork 和 ElasticBeanstalk 都是完整覆盖三个阶段的服务，不同之处是，Opswork 偏运维，控制粒度细，基于 Chef 来实现平台和应用部署，基于 AWS API 来实现底层搭建。
熟悉 Chef 的同学会很容易喜欢上 Opsworks。
ElasticBeanstalk 更加适合研发背景多一些，或者不喜欢做很多运维工作的同学，ElasticBeanstalk 可以自动化搭建底层基础设施和平台环境（如 tomcat、python、ruby 等），同时，ElasticBeanstalk 的命令行可以和 git 命令协同工作，git commit 之后，一条 eb deploy 命令可以完成部署。但是 ElasticBeanstalk 的平台环境版本不可以随意修改，对底层资源的修改也需要修改通过 elasticbeanstalk 来作。
ECS 全程 EC2 Container Services，是 AWS 的 docker 集群管理服务，这里就不详细展开了。
值得一提的时，ElasticBeanstalk 和 ECS 也可以联动，如果 ElasticBeanstalk 提供的环境不能满足要求，你可以把你的自定义环境打包到 docker Image，ElasticBeanstalk 支持 docker 部署。
03/ 猎豹 DevOps 案例分享
最后，分享一下猎豹 DevOps 的一些情况。
各项服务的频繁开启与维护: 自动化运维开发
代码快速迭代: 基于 ansible 的发布配置管理
各业务成本控制: 基于 tags 的成本核算
服务性能监控: zabbix 监控
上面四项是猎豹移动在海外运维中遇到的问题的解决办法。
猎豹移动增长非常迅猛，现在使用了几乎所有的 AWS 商用 Region 以服务全球用户。

这是内部运维平台的架构图，基于 Boto（aws api 的 python sdk）来构建，猎豹自己开发了一个资源申请流程系统，内部用户可以在网页上申请资源，后台通过 boto 来控制 aws 资源
此外，更复杂的一些运维和部署，通过 ansible 来做。
对于初创公司，可以通过 sdk 控制，也可以通过 aws 命令行来实现自动化。Ansible 也是一个非常不错的工具，不需要 agent，支持 aws api.

这是 ansible 快速部署 ebs 存储卷的一个例子。
总结下要点：
首先，DevOps 是个方式，要建立正确的文化，开发与运维互相协作，运维技能需要从单点系统扩展到架构设计和脚本自动化。
第二，选用正确的平台和工具，诸如 SDK、运维框架等平台和工具，尽量选用已有和比较成熟的，然后直接使用或进行二次开发。但即使二次开发，也是结合业务流，而不是重新做已有平台的事情。
第三，完整考虑各个环境，包括开发、编译、测试、集成、部署、平台构建、监控等，从软件设计之初就考虑到最终的基础架构支持和优化部署，通过微服务演化加速继承和部署，DevOps 在其中至关重要。
第四，从哪里上手？第一步，AWS 命令行和 SDK（比如基于 python 的 boto 或 boto3）；第二步，使用 AWS 基础设施服务，如 cloudformation；第三步，结合使用场景使用高级服务，如 ElasticBeanstak、Opsworks 等提高运维规范和敏捷度，CodeCommit、CodePipeline、CodeDeploy 优化 CI/CD 流程。
04/Q&A
Q1：在 DevOps 环节中是否需要专门的安全人员？如何解决安全问题？
安全是贯彻始终的，在初创公司，最好是大家形成安全意识，使用工具、平台和服务，也都积极了解安全方面的功能和保障。在 AWS 上做 DevOps，要留意数据存储和传输时候加密，数据的访问权限设置，部署避免使用静态秘钥绑定等等。
Q2：Devops 只适用于敏捷开发团队，还是也使用其它开发周期？
如果不做敏捷开发，那么 DevOps 更多的是自动化部署、降低人为错误、提高运维标准化方面。比如，虽然研发依然是瀑布式开发，但是运维 Team 内部可以做自动化，基础架构代码化，但是有业务驱动的话，动力一般更强，对不对。
Q3：国内团队如何选择选择云厂商？
AWS 的 API 和 SDK 是最全面的，在一个比较全面的平台上可以专注自己的平台构建。首先，AWS 的基础服务功能很全面，比如 VPC，现在还没有看到一个级别的；第二，AWS 的 PaaS 服务可以简化运维，如数据分析类（EMR、Redshift、Kinesis）、数据库类（RDS、DynamoDB）；第三，在同一平台上向先驱学习，比如 Netflix、SuperCell、小米、猎豹、MobiVista、Camera360 等等。
大家 Google 一下 Netflix 的 OSS，有很多开源的好工具，便于大家在 AWS 上自动化运维、做大数据分析、提高架构可靠性。
Q4: 如何利用 Docker 实现 DevOps 自动化、做好应用持续集成、持续交付有什么好的案例。
Docker 革命性地改变了开发和部署，改变了持续集成和交付的流程，研发和运维之间的交付从代码编程了 DockerImage（或者 Code+DockerFile），运维只需要关注底层资源自动化。但是，DockerImage 封装的平台环境要有内部的标准，虽然隔离后可以多环境，但多环境还是要有标准，方便管理。
另外，底层平台的自动化依然需要编程或脚本来实现自动化提供，这点没有变。
现在业界有一个误区，就是把 Docker 的集装箱特性和高动态特性没有分场景去谈，如果是你自己用，更多是关注 Docker 的集装箱特性，如果你是用 Docker 做一个 PaaS，那才需要关注和实现在集群里提供高动态。
＊此分享由亚马逊的代闻在极牛线上技术分享群里所分享
【下期重磅预告】
下周三（9.20）我们邀请了腾讯云的三位技术大牛共同进行线上分享！
< 讲师群 >
张浩 - 腾讯云产品经理
闫二辉 - 腾讯云资深存储架构师
周维跃 - 腾讯云资深研发工程师
< 主题 >
腾讯云分布式高可靠消息队列 CMQ 架构最佳实践
有意加入的技术朋友，请在极牛公众号 (ji-niu)里回复“技术分享”。