很多公司技术支持岗位的工作,如配置域名,部署环境,修改复位配置,服务重启,扩容缩容,梳理和完善监控,根据开发的需要查找日志等工作,需要和开发进行大量的沟通,如什么是外网域名,什么是内网域名、A name、C name,防火墙规则该如何设定,操作系统等基础环境需要什么依赖。因为很多研发不了解运维的术语和知识点,导致沟通困难,效率很低。而且这样的需求还很多,把运维压的喘不过气,占用了几乎所有的时间,但是开发的需求可能还是迟迟不能满足。
这样的公司可能遇到了以下问题:
如何才能解决?答案是流程化、标准化、自动化、平台化。
即主动梳理运维工作任务,形成标准化的操作流程,尤其是针对需要多人协作完成的任务,比如应用的发布部署,把流程固化到流程平台系统中,保证每个人执行都能按照流程严格执行,不会有哪些环节遗漏,而且当前的流程状态对所有人都可见,能清晰的看到谁正在处理,处理人也会更主动尽快的完成该任务。
从架构角度按照应用类别制定应用的部署标准,比如Web类型的应用,服务化的应用(我们内部用的JSF),或者是比较新的微服务的应用(Spring Boot等),部署脚本和工具平台按照约定好的规范进行设计开发,减少了因为应用种类繁多导致工具和平台的复杂。
早期写了非常多的脚本,任务执行机到要执行任务的服务器之间通过SSH免密钥认证,再根据需要批量执行命令。随着服务器规模和应用数量的扩张,很快脚本执行的方式无法满足业务发展,难以理解,同一个类型的任务多个脚本并存,存在误操作,缺乏清晰的操作历史记录和回滚机制,即使后续替换了如Puppet,Saltstack,Ansible这样的配置管理工具,但根本问题并没有解决。
平台化是这次分享的重点,一定要在前面三条的基础上进行建设,如果没有清晰的流程,明确的标准,平台建设起来也只是自动化工具的集成,解决不了公司核心问题。
以下说的平台化内容主要是PaaS平台化,即主要从应用和中间件的角度,这里不讨论IaaS的内容。
PasS平台化将问题的关注点从基础资源上升到了应用层面,目标是提供一个帮助开发人员运行、管理应用的平台,让使用者更关注运行的代码(业务逻辑)。
PaaS能解决的问题:
应用聚合:如开发需要一个Redis,直接启动一个Redis容器即可
服务发现、快速伸缩、状态管理等
服务监控、恢复、容灾
费用统计:提供计算资源信息汇总,针对不同项目收费
安全管控:不管什么平台,安全都非常重要,例如A应用可以访问B,B不允许访问A以及安全审计等。
快速部署
随着Docker容器技术的出现,让我们有了更合适的工具建设PaaS平台,具备了基于应用构建服务的能力。
在Docker容器调度框架上,我们又选择了Kubernetes平台。
先列一下目前三大主流的容器调度框架的功能和特点:
资源调度、服务发现、服务编排、资源逻辑隔离、服务自愈、安全配置管理、Job任务支持、自动回滚、内部域名服务、健康检查、有状态支持、运行监控/日志、扩容缩容、负载均衡、灰度升级、容灾恢复、应用HA。
Mesos是一个分布式内核,目前的发展方向是数据中心操作系统(DCOS),它同时支持 Marathon、 Kubernetes 和 Swarm 等多种框架,Mesosphere 也是 Kubernetes 生态的一员。
注意Marathon的技术栈是Scala语言,而Docker和Kubernetes的技术栈都是Go语言。
从Docker1.12版本开始,Swarm随Docker一起默认安装发布,也由于随Docker引擎一起发布,无需额外安装,配置简单。
支持服务注册、服务发现,内置Overlay Network以及Load Balancer。
与Docker CLI非常类似的操作命令,对熟悉Docker的人非常容易上手学习。
每一种工具都有自己的核心理念。
Mesos理念是数据中心操作系统(DCOS),为了解决IaaS层的网络、计算和存储问题,所以Mesos的核心是解决物理资源层的问题。
Kubernetes的核心是如何解决自动部署,扩展和管理容器化(containerized)应用程序。
所以,个人认为Mesos和Kubernetes是两种维度,对于我们的场景来说,关心应用的状态多于物理资源层管理,因此更关心的是容器化应用程序管理,这是我们选择Kubernetes的主要原因。
另外选择Kubernetes还考虑了其它优势,如:
再来看一下我眼中的基于当前最流行的微服务架构的设计是什么样的,即我们PaaS平台上要运行的典型应用是什么样的。
微服务架构因为有注册中心自动解决了服务注册发现的问题,所以对内部服务来讲就不用依赖传统的负载均衡器等工具,很容易将各个服务Docker化,迁移到PaaS平台里统一管理。
在建设PaaS平台之前,参考《高效人士的七个习惯》设定了PaaS平台建设的原则:
Kubernetes对外提供服务,用的是Lvs+Ingress,每次添加一个新的服务之后会调用一次DNS的API,按照规则生成一个内部域名供访问使用。
具体实施时,主要有几个基础组件需要开发:
一个中小企业做成这样后,日常运维的工作量即可大量减少,两三个人就能完成日常的应用运维工作,有兴趣地话可以去挑战一下。当然做完这些后,还只是一个小型的PaaS平台。
如果是再复杂一点的PaaS平台,应该还有哪些要继续做的呢?
环境管理:即一套平台管理多套不同的Kubernetes集群。安全管理、流程管理、计费管理等功能模块。
还有因为规模增加和更高的可靠性要求,对应的网络,IO等各种优化。
其实还有很多功能就不一一列举了,可以根据自己的实际情况添加功能模块,设计有自己公司特色的PaaS平台。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞16
添加新评论1 条评论
2018-05-31 09:43