在项目实践中，容器化改造和DevOps建设如何进行？
本帖最后由 adminlily 于 2018-11-15 16:44 编辑容器技术的兴起，不仅带来了应用开发部署的变革，也带来了应用设计架构和运维部署变化。企业进行容器化改造，最主要的是根据当前的企业应用和实际业务需求情况，选择适合容器化管理平台，进行应用容器化改造和Devops的建设。本次分享在项目实践中，如何进行容器化改造和DevOps的建设，以及采取了哪些策略。为什么要建设容器云？
纵观虚拟化技术的发展在历史，虚拟化技术跨越IT架构，实现包括资源、应用、网络、桌面在内的全系统虚拟化的发展阶段。许多金融、保险等行业早已完成从物理机到虚拟化的转换。使用虚拟化技术一定程度上降低了运维复杂性，提升了资源的使用率，但这种虚拟化技术可视作云计算中IaaS的发展。当前移动多媒体APP和互联金融、大数据等行业的业务面临如下问题期待解决：
1.应用系统基础组件多：由于使用的基础软件多为复杂商业软件，功能繁多，真正经常使用的功能一般都有少数。这些基础软件系统架构复杂、安装部署复杂度呈曲线上升
2.应用部署与升级复杂：应用系统规模越来越复杂，庞大的部署架构模式使得应用的安装、部署和更新也相对比较复杂，部署训运维成本都成倍增加
3.敏捷与高效管理困难：在移动APP和互联网金融等多种行业的激烈市场竞争时，应用业务的需求变化越发频繁，同时也希望研发部门的软件交付周期越来越短，要高效、敏捷开发、Devops 、增强应用感知
4.面临硬件使用率低、资源分配调度缓慢的问题，无法满足应用快速上线、弹性伸缩、智能决策的需求
为了解决上述问题从而更好的提升研发和运维团队的生产力，而更加灵活、高效、快速的满足业务系统需求，更好提升业务价值。这就需要引入容器技术，使用容器云它可以从本质上更好的解决面临的问题。
过去一年美国超过 40% 的公司尝试过Docker，并且四分之一的公司使用了编排系统。一些大型企业的数据库、大数据等应用都在逐步采用容器技术。
容器的价值
容器的优势
1.标准化应用的部署和交付：由于容器镜像的方式实现运行环境的标准化，屏蔽应用部署过程中针对不同环境需要的环境配置、安装步骤等复杂过程。类似“沙箱”技术，每台主机上可运行几百到上千容器，提供服务
2.加速Devops的落地实施：容器的理念及其技术特点，能够更好的与CI/CD技术进行融合，促进CI/CD理念的落地，可从技术手段上保证项目管理方式和管理理念的真正有效落地
3.有效整合现有资源：容器可运行在多种云平台环境中，物理、虚拟机、阿里云、AWS、OpenStack、Azure等，可实现对企业不同的基础资源的统一化管理，降低系统运维难度
4.提升资源利用率：容器是基于操作系统的轻量级虚拟化技术，共享操作系统的内核进程和内核资源，从而有效节省操作系统级资源开销， 容器启动速度快，占用资源少，通过容器密度的提升更好的利用资源
5.管理更加简单： 使用容器技术，只需要小小的修改，就可以替代以往大量的更新工作。所有的修改都以增量的方式被分发和更新，从而实现自动化并且高效的管理
6.生态系统完善：使用容器组件，组建企业级镜像仓库，实现企业级应用商店功能，应用系统日志监控等，几乎是应有尽有
一、项目目标
[*]实现容器的管理与调度
[*]进行应用的容器化
[*]容器管理平台
[*]实现镜像的集中管理
[*]实现CI/CD流程自动化
1、项目描述
规模：50台业务节点机
项目目标：容器管理平台
提供高可用布署，异构环境管理，应用集群化布署/升级/回滚、服务发现、健康检查、调度、弹性伸缩、负载均衡、日志/监控等功能
2、镜像管理仓库
提供高可用镜像仓库布署、镜像安全、镜像管理、访问控制等
3、应用容器化
营销平台应用系统的容器化改造及上线
4、持续集成/部署
实现营销系统持续集成/部署的全自动化流程
二、方案设计
1、容器平台设计要求
由于实施部署环境是在某企业内部阿里云（私有云）中进行搭建容器管理平台。具体环境描述与要求如下：
使用阿里云私有云平台统一管理，有多处机房，要求开发、测试环境与生产环境隔离
需要共用一个高可用的镜像仓库，用于存储企业内部的应用镜像
使用VPC专用网络，网络环境复杂；没有硬件负载均衡器，只有阿里云的SLB
目的是通过容器管理平台可以提高虚拟主机的利用率
平台需要高可用部署，提供稳定可靠的运行环境
要有针对部署的业务系统的统一日志收集和查看以及筛选功能
有两套业务系统需要容器化，而且业务系统操作要隔离
每套业务系统容器化模块需要实现CICD
建立企业级的应用商店，为企业提供一键式部署应用的功能
2、基础框架概览
3、容器管理平台搭建目标
容器管理平台的基础环境：
三、应用微服务化
1、应用微服务化的好处
应用微服务化的目的是有效的拆分应用，实现敏捷开发和部署。
四个方面的优点，分别如下：
通过分解巨大单体式应用为多个服务的方法解决了复杂性问题。每个微服务组件都是简单灵活的，能够独立部署
可以使得每个服务都有专门的开发团队负责，更专注、更高效 、更可靠
微服架构模式每个微服务之间是低耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展
微服务架构与语言工具无关，自由选择合适的语言和工具，高效的完成业务目标
2、应用微服务化的原则
四个原则如下：
1.AKF拆分原则
2.前后端分离
3.无状态服务
4.Restful通信风格
3、营销平台服务架构
应用微服务化，需要根据微服务应用的设计原则和企业内部应用实际情况进行部署情况进行合理选择。
[*]Nginx：做为反向代理和负载均衡的配置，进行容器化配置
[*]前端：静态stN和应用层中间件Tomcat
[*]基础组件层：ActiveMQ、Kafka、Redis集群和单机以及MongoDB集群容器化
[*]服务层：由zookeeper、CSF提供主站app与公共服务、连接数据库、后台业务处理建立通信
4、营销平台服务关系图
5、微服务化思路
互联网和移动多媒体应用的发展，在敏捷快速迭代、高可用、高性能、高并发等方面要求越所以，我们采用微服务化是把应用拆解为多个应用服务，组合，每个服务自治，以达到更加灵活，维护方便的效果。下面是根据客户业务系统进行拆分的方式。
1.基础服务组件：像ActiveMQ集群、Kafka集群、Redis主从集群、MongoDB集群以及Redis单点，这些相对容易进行容器化改造，只要按照业务应用的部署方式需求，进行容器化
2.ZooKeeper和ZKWeb：服务间通信和注册端（ZooKeeper集群）和管理端（ZKWeb），分开进行应用容器化设计
3.Csf_server和csf_web：主要是提供服务，所有的公共服务，连接数据库、后台业务处理等服务和管理
4.业务端：stN是静态资源主要是从项目工程中将静态文件（html、js、css、img、images等），单独拆分出来，进行独立部署，从而达到动静分离的目的。
5.Rmdp：是后台管理端，产品发布，订单管理、优惠策略、审核等一系列的管理操作
6.Nginx负载：入口nginx主要配置主机分发，通过URL后缀来访问那此业务主机
7.CSF和airmdp数据库：阿里云RDS数据库服务服务，不需要容器化
6、容器化展示
通过容器化管理平台把营销平台运行容器化组件，上架到容器平台的应用栈中。对接数据库，进行业务连续性的功能测试，确保业务的流程正常。
7、营销平台联调
8、应用商店
构建企业应用商店和一键部署应用能力。
9、添加云主机
添加主机驱动，对Machine的管理更加精进了一步，管理Catalog应用市场一样管理Machine Driver，部署和管理方式更加直观。添加完成Driver后，就可以在Plugin中使用了。
在集群中，可以通过对容器访问和主机资源进行监控，当资源使用率达到告警值的时候，触发自动添加主机的操作，在系统中自动把ECS主机纳管理到容器管理平台中，进行资源的扩容操作。
10、扩容、缩容
通过创建Webhook，获取扩容或缩容的HTTP API网址，然后通过curl工具发送HTTP POST请求，实现扩容或缩容。
1.根据CPU、内存等自定义触发条件阈值和扩展条件设置
2.智能监测应用环境，并自动横向扩展容器
3.支持除主机CPU、内存的资源监控外，可对会话等自定义的系统或应用资源监控，根据指定负载范围进行基于容器的弹性伸缩
四、CI/CD建设
1、什么是CI/CD？
[*]持续集成——Continuous Integration简称CI，是指频繁地（一天多次）将代码集成到主干。目标是让产品快速迭代，同时保持高质量。核心措施：代码集成到主干前必须通过自动化测试，测试零失败的代码才能合并。
[*]持续交付——Continuous Delivery 简称CD，指的是频繁地更新版本软件，交付给QA团队或者用户，让他们评审。如果评审通过了，代码就进入生产阶段。比如，我们完成测试后，可以把代码部署到连接数据库的Staging 环境中进行更多的自动化测试。如果代码没有问题，可以继续手动部署到生产环境中。
[*]持续部署——Continuous Deployment 也简称CD，它是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。持续部署是持续交付的最高阶段。
据调查显示，2016年，38%的企业已经在使用DevOps, 2017年超过70%的IT市场会将目光聚焦在DevOps技术及功能上。
2、CI/CD流程概览
基于Jenkins，实现从开发者提交代码、编译构建、环境部署，关键环节邮件通知相关人员。
3、CI/CD流程
[*]提交申请：开发人员提交开发代码到SVN、Git服务器
[*]人工定时确发：如果发现代码有更新可进行人工或定时触发代码的编辑操作
[*]自动构建：Jenkins会根据构建脚本把编译打包文件和Dockerfile进行自动生成镜像，并上传至镜像仓库；根据需求可发出邮件通知
[*]自动部署：Jenkins根据部署的Compose文件和容器管理平台对接
[*]获取部署环境信息： 获取需要部署环境ENV:id，访问和存取key以及操作（部署、更新）
[*]部署成功： 如果镜像编译正常，Compose文件和管理平台对接正常，获取部署环境信息正常，那么，就会根据需求进行平台应用栈部署。如果部署失败，也可以正常发布邮件通知
[*]自动测试：如果部署成功以后，可根据自动化测试脚本，进行项目的单元测试和检查检查测试。测试最终的结果，可通过邮件通知开发或运维人员
4、CI/CD展示
5、解决方案价值
[*]快速发布，能够应对业务需求，并更快地实现软件价值
[*]编码->测试->上线->交付的频繁迭代周期缩短，同时获得迅速反馈
[*]高质量的软件发布标准，整个交付过程标准化、可重复、可靠
[*]整个交付过程进度可视化，方便团队人员了解项目成熟度
[*]更先进的团队协作方式。从需求分析、产品的用户体验到交互设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费
五、CI/CD建设
1、日志管理
在容器环境里，集中式日志存储更加重要。相比传统的运维模式，Docker通常使用编排系统管理容器，容器和宿主机之间的映射并不固定，容器也可能不断的在宿主机之间迁移，登录到机器上查看日志的方式完全没法用了，集中式日志成了唯一的选择。结合Logstash，ElasticSearch和Kibana三个组件，可以搭建一套高效的日志收集和分析系统。
2、ELK日志系统数据流图
ELK stack支持组件间的灵活组合，提供强大的开箱即用的日志收集和检索功能。
从上图中看到ELK系统进行日志收集的过程，可以分为三个环节：
[*]日志收集和导入ElasticSearch
[*]ElasticSearch进行索引等处理
[*]可视化操作，查询等
Logstash可以结合Redis或者Kafka等收集应用服务器产生的日志，经过简单的过滤等操作后发送到ElasticSearch，ElasticSearch进行相关的索引处理，最后在Kibana进行相关的可视化操作。
3、容器管理平台中具备：
[*]日志收集
[*]容器系统日志
[*]应用日志
[*]平台日志审计
[*]集成了ELK
4、App Stack & Link
5、Kibana展示
六、总结
在企业内部进行应用微服务化改造，说起来简单，但真正做起来需要考虑很多方面的因素。根据实际的服务架构进行考虑与解决：
[*]应用架构微服务化，从功能的角度去拆分，如不同的功能拆成不同的微服务，微服务的目标在于充分分解应用程序以方便应用敏捷开发和部署。
[*]微服务是一个分布式系统，使得整体变得复杂。开发者需要选择和实现基于消息或者RPC的进程间通信机制，服务调用者应有一些应对策略。
[*]使用服务注册中心做服务可用性检测，如果发现某个服务节点不可用，就会将其从注册中心中删除。为了保证生产者、zk、消费者之间的服务同步 。只依托ZK做状态检测还不够，需要服务提供者和消费者的链路层做双向心跳检测。
[*]在企业做推广和营销宣传时，stN静态容器需要，需要获取到FTP服务器中获取网站做推广时的静态资源图片。这就需要同步机制，来监控FTP服务器图片库目录是否有改变，如果改变，就需要把静态资源同步到容器的指定目录中，实现静态资源的同步更新。
通过应用微服务化，已经完成两个业务系统的微服务化改造，并且已经成功上架到容器管理平台中，对外提供服务。
DevOps 1.0主要是围绕着协调开发、QA和运维三者，其主要目标是制度化持续交付，同时创造更加灵活稳定的应用架构。DevOps的三原则：
[*]一键式部署（Automatic Deploy）：部署过程中，标准化部署过程，实现一键式部署
[*]一次构建打包（Automatic Delivery）：在测试环境、UAT环境和生产环境的流转过程中，只打包一次，软件包按顺序自动交付到各个环境，最终发布到生产环境
[*]一次配置分发（Automatic Distribution）：在生产环境发布过程，建立统一的配置分发管理，将繁琐的分布式环境配置一次分发到各个数据中心，简化发布过程
在DevOps 2.0时代，我们注意到作为成功的软件交付的关键因素，自适应特性交付正在兴起。
无论如何变化，DevOps成功与否，公司组织是否利于协作是关键。开发人员和运维人员可以良好沟通互相学习，从而拥有高生产力。并且协作也存在于业务人员与开发人员之间。不断完善提高企业的标准化流程是最终的目的。
Q&A
Q：您确定你们是FTP做文件管理？A：FTP只有用于存放活动宣传的图片，在容器环境中，需要把这些图片同步到stN容器中。
Q：用Jenkins测试完了以后如何发布到生产环境的？
A：由于这个项目的客户是开发和测试环境中一个容器管理平台，生产环境一个容器管理平台，开发测试写成，生成生产环境的镜像tag；由于生产环境的应用stack更新，需要通过手动触发，进行更新。
Q：请问，日志的话，是不是每个服务都有规定格式？
A：做应用容器化改造，需要进行应用日志的收集，这样需要规定应用日志输出的格式和目录。这样方便进行统一的日志收集与管理。
Q：这个环境支持应用一键部署到公有云嘛？
A：如果使用PaaS云混合云部署，是可以支持一键部署到公有云环境中。
Q：请问数据库是怎样部署的，有进行容器化吗？A：此客户项目实施中，使用MySQL和MongoDB两种数据库。其中MongoDB集群部署，做了容器化改造；另外，MySQL数据库使用阿里云的RDS数据库，没有容器化。阿里云平台提供服务库服务和备份，快照。
Q：AKF原则可以详细介绍嘛？
A：AKF扩展立方体（参考《The Art of Scalability》）技术专家抽象总结的应用扩展的三个维度：
[*]X 轴 ：指的是水平复制，即在负载均衡服务器后增加多个Web服务器
[*]Z 轴 ：是对数据库的扩展，即分库分表（分库是将关系紧密的表放在一台数据库服务器上，分表是因为一张表的数据太多，需要将一张表的数据通过hash放在不同的数据库服务器上
[*]Y 轴 ：是功能分解，将不同职能的模块分成不同的服务。从y轴这个方向扩展，才能将巨型应用分解为一组不同的服务，例如订单管理中心、客户信息管理中心、商品管理中心、支付系统等等。 详细请参考《The Art of Scalability》
Q：如何切换开发、测试、生产环境的参数配置？
A： 如果您有三个Environment环境，开发、测试、生产环境需求；我们可以创建三个环境分别如下：DEV（开发环境）、TEST（测试环境）、PRO（生产环境），每个环境下面的应用栈与其它环境想到隔离，互不影响；如果需要切换管理，只需要在管理平台中进行ENV环境的切换，即可对相应的环境与应用栈进行管理。
Q：请问目前监控使用的是什么方案？
A：容器管理平台本身是基于cAdvisor可以监控实时容器指标CPU、Menory、I/O、网络资源资源。同时，它也可以部署使用其它监控应用栈。例如：Prometheus、Grafana、Datadog等。
Q：代码怎么部署到容器中，是通过外部硬盘挂载吗，是不是每次都重新生成新的镜像？
A：容器本身是生命周期比较短暂，而且会根据策略自动迁移。一般不会把代码代码通过外部挂载到容器。通常做法如果代码变动或更新，重新build镜像。可以根据自己定义是时间段进行build镜像。
Q：对于数据库集群，现阶段是怎么运维的，有案例？同时对于数据安全是怎么保证的？数据的备份采用什么方式？
A：针对数据库集群的运维，这个是一个针对性很强的专业问题；数据库的备份/还原、监控、故障处理、性能优化、升级/迁移、健康检查，用户反馈数据库问题等等，这些都需要专门的DBA处理。数据库运维总原则：第一：能不给数据库做的事情不要给数据库，数据库只做数据容器；第二：对于数据库的变更必须有记录，可以回滚。 数据库的安全至关重要，有相应的权限管理，以最低粒度的控制权限。所有开发人员权限粒度到表一级，数据库管理员和系统管理员权限粒度到库一级等等。不同的数据库以及部署方式不一样，要求的备份也有差别。以MySQL为例，如果搭建主从架构，就要通过binlog文件同步复制主库的数据。另外，通过系统计划任务执行mysqldump做周期性全备份；还有，物理备份，直接拷贝数据文件、参数文件、日志文件。最后，专门的备份工具如：mysqlhotcopy、ibbackup等。
原创：惠志朋
页:
[1]