聊一聊互联网公司Docker容器化是如何实践的?

标签: 互联网 公司 docker | 发表时间:2019-05-29 14:05 | 作者:兰博基尼
出处:https://www.iteye.com

简介

docker容器技术在17年可谓是炽手可热,docker不仅仅改变了传统软件服务的交付流程,更是为云计算和微服务大规模集群管理部署,提供了强有力的技术支撑。当今各大公司企业也是把容器化技术作为不可或缺的技术战略,于17年初我们也开始步入docker技术的生态圈,尝试进行对当前服务做容器化的改造,而持续交付作为项目开发流程中较为核心的一步,也是落地实践最早一步。

 

我们的问题

17年初,基于微服务的架构,仅我们团队内的服务单元已经过百,特别是经历网站的促销活动,机器扩容,资源分配等问题真的是苦不堪言,除此之外更是有一些困绕已久的问题等待解决:

1. 发布系统不统一

因为涉及到不同语言的系统开发,各个系统的构建流程都有不同,涉及到node,C#,Java还有python,发布到不同服务器上,需要通过对应的发布系统,各个系统之间记录关联很难核对,不便于追踪。

2. 多环境的管理

服务器资源新增,修改部署的配置比较多,包括打通与发布系统的环境相关联,基础服务的安装配,包括node,jdk和tomcat服务器等。

3. 环境的一致性

由于各种历史问题,导致项目发布的测试环境、集成环境和产线环境配置不一致,给系统问题的排查定位带来一定的难度,项目部署目录,服务启动用户,甚至包括jdk版本的问题,这些问题同时加重了运维工作的复杂度。

4. 资源的分配

主要是软资源的计算分配,因为服务单元非常多,每个服务单元的内存,端口分配问题会随着服务数量的增加,越来越难以计算和管理,CMDB统计不够实时,造成最终的结果就是资源利用率比较低。

 

微服务架构

选择docker一个重要的原因,就不得不提到微服务了,微服务相比传统的服务采用单体的架构方式,部署方式和开发模式上有很大优势。单体架构的方式,服务系统过于庞大臃肿,项目发布部署风险较高,迭代开发周期较长,而微服务按照业务维度进行功能模块拆分,使其各自成为一个可独立提供服务,可独立部署运行的单元模块,通过指定的网络协议模块之间进行通信,并且在开发模式上,也是相互独立,大幅提高了项目开发上线的周期,做到快速迭代。但是随着则业务复杂性的提升,微服务的集群数量也会急速上升,带来的问题就是面对如此多服务如何高效的管理,部署,监控等一些问题,而docker处理这些却有着得天独厚的优势。

我们微服务架构核心采用的框架是基于Spring Boot和Dubbo,并且是支持双协议的通信,http/https和Dubbo RPC的调用方式,Dubbo的主要是内部模块调用依赖,而http的接口主要是提供给异构系统的接入。整体的项目架构图如下:

聊一聊互联网公司Docker容器化是如何实践的?

容器化之路

如今再次说到docker的时候,我们往往已经不仅仅谈论的只是docker本身,因为docker engine 只是改变了应用运行时的状态管理,更多的我们还关注到服务的调度,编排,网络管理,存储,监控,配置管理等等一系列的服务,docker 俨然已经是一个庞大的技术生态圈,这个生态圈里面,大家比较关心的其中一个核心服务的就是容器编排了,因为容器编排彻底的改变了传统软件服务交付流程,而容器编排则又以k8s 和mesos 为主的居多,更确切的说,k8s已经不仅仅是作为一个编排工具了,此处暂时不做讨论,两者的选型介绍可后续关注,此次也不做过多讨论。

我们选择的容器编排是以mesos为主的,简单介绍一个以mesos为核心的各个组件以及服务依赖。

zk 注册中心,这个注册并不是服务的注册,而是用来管理mesos集群状态数据的中心服务,通过zk来构建一套高可用的mesos集群。

mesos-slave 部署在每个node(主机)节点的服务,用来采集服务器数据信息,执行指令。

mesos-master 管理服务器资源信息,分派mesos-slave资源调度指令。

marathon 资源计算服务,根据应用部署需要的资源信息,提供资源分配,并且提供了一套UI,通过UI可方便的进行管理操作。

各个组件服务结构如下图:

 

聊一聊互联网公司Docker容器化是如何实践的?

 

镜像

 

我们的服务,主要的包括Java和node两种类型的服务,所以基础镜像也根据不同的版本号,提供了多种类型。镜像基础使用的是alpine的版本,镜像文件非常小,jdk使用的openjdk,加上启动服务的脚本以及其他配置,配置内容,镜像最终大小100M左右,加上项目打包好以后的镜像,在150M上下,当然为了一些项目的特殊需求,也提供了oracle jdk的镜像版本,但是至今未使用过。

 

构建

 

我们的技术框架最初是基于Spring Boot,通过Spring Boot提供的打包插件,可以方便的把项目构建成一个运行时需要的jar包,启动jar包和指定的运行时的一些参数信息,是通过gitlab统一管理的一些shell文件,通过jenkins构建过程,动态的把项目的jar包和启动脚本,封装在一起,然后发布到应用服务器,解压启动。但是如果采用docker部署,这种方式就不可行了,因为docker部署面向的是镜像。

docker镜像的构建方式有多种,最合理的一种莫过于Dockerfile了,但此时我们产线运行的项目已经非常多了,一个个往里面添加Dockerfile已经不现实,所以就提供了一个Dockerfile模板,里面标注了基础镜像信息,在项目构建的流程中,通过获取一些项目参数,动态生成一个Dockerfile文件,最后通过docker build生成镜像文件,然后提交到镜像库,这个过程对于开发人员完全无感知,就这样悄无声息的完成了项目格式的转化,并且对于不同类型的项目,提供了不同类型的Dockerfile模板,甚至可以通过项目做定制化。

上面说Dockerfile是动态生成并且对开发人员无感知的,而这个构建过程,也是通过执行容器实现的,通过容器挂载的方式,把构建的结果显示在宿主机上,这整个的过程都做成了docker镜像,并且使用Dockerfile管理这些镜像,通过不同的Dockerfile轻而易举的自定义各个类型项目的构建过程,比如node项目的构建和Java的构建不同,就定义两个Dockerfile就可以了,统一在gitlab上管理,维护成本变得非常低。

 

发布

 

项目构建完成,容器的的编排部署,主要是通过marathon操作。marathon本身提供了一些对外开放的api接口,这个开放接口也是我们做自动化基石。项目构建完毕,流程并没有结束。marathon管理的服务编排,主要是配置文件,定义应用,内存,端口,以及健康监测都是在配置文件里面管理的,所以基于此,我按照格式定义了一个项目,专门来管理这些项目的配置,并且把这些配置提交到gitlab上进行管理,项目结构如下:

 

聊一聊互联网公司Docker容器化是如何实践的?

 

每一个环境对应的目录下,都是一个marathon的配置文件模板,之所以是模板,因为每次构建生成不同的镜像tag是系统自动生成的,会动态替换参数,并且调用marathon的api接口进行服务更新,服务的更新策略也都配置在marathon配置文件中的,整个的构建和发布流程,分为各自独立的两模块,通过一套shell完成,也可以独立使用,但还是为了考虑操作的简单性,接入了jenkins,并且通过jenkins增强了权限控制,并且对操作记录可追踪。构建流程结构如下图:

 

聊一聊互联网公司Docker容器化是如何实践的?

 

 

运行

 

一开始我们采用docker,只是拿了部分服务测试,并非一蹴而就,全部直接推广使用。项目测试运行刚上线,开始遇到第一个问题。写到这里,简单普及一下docker的网络模式,docker的网络模式默认的四种方式host,bridge,none和自定义的网络模式,host的方式就是容器和主机共享网络空间,容器和主机共用网络端口,这种方式的弊端不言而喻,就是部署应用的时候要关注服务器的端口分配。bridge的方式是采用的独立的网络空间,通过虚拟网桥的方式利用主机的网卡进行通信,容器的网络空间是独立的,容器内部服务端口和主机映射端口是随机的。none的形式就是关闭网络模式,这种适合于计算的服务类型。而自定义的网络模式,主要是来解决跨主机网络通信的问题,每个容器网络空间也是各自独立的,而我们的服务主要采用的就是种方式,问题也恰恰出在这里。

由于采用的是部分服务做docker化,老的服务可能需要访问新的服务,但是这个时候,老服务在利用Dubbo调用新服务的通信的时候,发现对方注册是IP地址无法访问,原因就是docker容器内的Dubbo提供的服务,注册上去的其实是个虚拟IP地址,和原有老的服务根本就不同一个网络内。所以网络单向是不通的,网络调用结构如下图:

 

聊一聊互联网公司Docker容器化是如何实践的?

 

既然是网络的问题,那么针对该问题的解决方案也列了几个:

方案一:所有服务进行docker容器化部署,这样的话所有服务就处于同一个虚拟网络段内,但是这个迁移的成本和风险非常大。

方案二:基于物理层面网络做修改配置,但是这种维护的成本较大,可扩展性不好。

方案三:更改容器内服务运行的网络,采用host的方式配置,这种方式其实并没有充分利用容器化带来的便利之处,但是确实最简单解决这个问题的方法,所以最终考虑,选择这个方案解决,而后期的优化方案,去Dubbo化。

其实针对容器网络的模块,这里也只是冰山一角,未来面临更复杂的产线环境,将会遇到更多网络的配置问题。

 

总结

容器化之路是,这里仅仅只是起点,本次只是简单的介绍了最开始容器化项目构建交付的流程,实际上在实践中遇到的问题不止如此,希望对大家有所帮助,思路上也希望能有共鸣,后续对相关细节问题还会再次介绍。



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [互联网 公司 docker] 推荐:

聊一聊互联网公司Docker容器化是如何实践的?

- - 开源软件 - ITeye博客
docker容器技术在17年可谓是炽手可热,docker不仅仅改变了传统软件服务的交付流程,更是为云计算和微服务大规模集群管理部署,提供了强有力的技术支撑. 当今各大公司企业也是把容器化技术作为不可或缺的技术战略,于17年初我们也开始步入docker技术的生态圈,尝试进行对当前服务做容器化的改造,而持续交付作为项目开发流程中较为核心的一步,也是落地实践最早一步.

Docker 公司已死 !

- -
作者简介:Chris Short在IT行业有20多年的从业经历,他毕生坚定地提倡使用开源解决方案. 他是身体部分残障的美国空军退伍老兵,现与妻子和儿子一起住在密歇根州大底特律都市区. 要说Docker在2017年的日子非常难过,那已经算是轻描淡写了. 除了优步(Uber)外,我实在想不出还有哪一家更加被利用、被炒作、资金充裕的硅谷初创公司(仍在运营之中)像Docker在2017年那样步履维艰、糟糕透顶.

Docker & Flatpak

- - IT瘾-dev
目前最流行的技术莫过于Docker,Docker和Docker衍生的东西用到了很多很酷的技术,目前deepin应用软件发布转变成flatpak,这些看似风牛马不相及的技术方案,实际都使用了一个共同的底层技术——Namespace,假如没有namespace支持,这些技术实现都将成为空中楼阁. 一句话总结,无论是Docker、sysmted-nspawn还是flatpak,都是在namespace基础上,针对不同的场景,生出的不同的解决方案.

北美互联网公司求职记

- - 雷锋网
@zellux,雷锋网已取得作者授权, 原文链接. 最近签掉了 offer,找工作的事情算是告一段落. 在这里写一点面试体验和心得,希望对有兴趣去北美工作的朋友有所帮助. 先简单介绍下自己,国内硕士在读,明年毕业,没有牛 paper,也没参加过 ACM-ICPC 竞赛. 在实验室做过内核、虚拟机和 Android 底层相关的研究工作,接过一些网页和移动开发的外包,2011 年开始在字节社兼职负责后台开发.

.中国互联网公司人效榜

- - 创业家杂志社
你为你的公司贡献了多少收入、多少利润. 前几天,腾讯科技一篇 报道,揭示苹果人均净利润高达45.18万美元,谷歌的人均净利润也有24.2万美元,分列第一、二名. 如果要就此排一个榜单的话,绝没可能出现在这份榜单前列的惟一一个美国科技巨头可能是亚马逊,亚马逊现在都在季度亏损中,而去年的人均销售额也才85.6万美元(它去年一举就招了三万名员工),离苹果谷歌遥遥万里.

互联网公司福利哪家强?

- - IT耳朵
年底了,作为互联网圈儿的“耳朵”,IT耳朵有责任也有义务为大家整理一下互联网公司的福利情况,不过原来我们的好伙伴拉勾网已经整理过了,朵仔就在这里重新编辑、配图然后分享给大家,看看有没有你家公司呢. 他们赚多少:每年提薪14%左右. 他们的住行:办公室有专门的睡眠室. 他们还有啥:大概就是五险一金、带薪年假、员工培训这些常规项目.

互联网公司的指数们

- - 扯氮集--上海魏武挥的Blog
4月头上,随着蚂蚁金服正式推出淘金100指数,BAT三家互联网巨头再一次在同一个领域里碰头:他们都开始做自己的股票指数. 如果算上新浪的i指数,迄今为止,已经有四家互联网公司编制股票指数. 对股票指数的投资,被视为一种被动型投资,它比较适合风险厌恶度高而且相对没有太多时间看盘的人. 我一向认为,在整个大势走好的情况下,投资指数,是一种不错的解决方案.

docker初体验之docker-tomcat

- - BlogJava-首页技术区
docker已经是现在最热的容器技术,最近也去体验了一下,在daocloud注册了一个账号,并开始本机实战docker. daocloud免费有两个容器可用,体验送T恤,邀请送书,这里我分享一个daocloud的邀请码 https://account.daocloud.io/signup?invite_code=mxeq2jkmcur37vz6ven8,daocloud是非常棒的容器云平台,使用体验好,问题响应也及时,绑定微信还送一个额外容器.

小米到底是一家硬件公司还是互联网公司?

- - 科幻星系
随着小米IPO日益临近,业内越来越多的相关消息不断传出. 还记得在小米1时代,这款手机以1999元的价格搭配顶配的硬件等,迅速对彼时的智能手机市场产生了极大冲击. 当时业界就有人质疑雷军:赚的钱够喝粥吗. 当然了,雷军是笑而不语还是暗自窃喜我们不得而知. 但就现在来说,雷军以低价硬件起家的策略显然已经成功了.

国内移动互联网初创公司汇总

- lichzy - 同步控
如果您是关注移动互联网行业的项目分析师、资本合伙人,如果您刚刚打算涉足移动互联网领域创业,又如果您正在从事移动互联网相关的产品策划、竞品分析,那么请将这份来自 17Startup 的、不断更新的国内移动互联网初创公司汇总列表加入您的浏览器收藏夹——你可能会经常用到它. 网页地址:http://17startup.com/#!/category/7.