从应用架构角度理解Docker

从应用架构角度理解Docker

来源:转自fundebug 时间:2020年12月22日16:32:10


难度:简单

从应用架构角度理解Docker

刚开始,你只需要写一个Node.js程序,挂载一个静态网站;
然后,你做了一个用户账号系统,这时需要数据库了,比如说MySQL; 
后来,为了提升性能,你引入了Memcached缓存;终于有一天,你决定把前后端分离,这样可以提高开发效率;
当用户越来越多,你又不得不使用Nginx做反向代理; 对了,随着功能越来越多,你的应用依赖也会越来越多…总之,你的应用架构只会越来越复杂。不同的组件的安装,配置与运行步骤各不相同,于是你不得不写一个很长的文档给新同事,只为了让他搭建一个开发环境。
使用Docker的话,你可以为不同的组件逐一编写Dockerfile,分别构建镜像,然后运行在各个容器中。这样做,将复杂的架构统一了
所有组件的安装和运行步骤统一为几个简单的命令:
构建Docker镜像: docker build
上传Docker镜像: docker push
下载Docker镜像: docker pull
运行Docker容器: docker run

从应用部署角度理解Docker

通常,你会有开发,测试和生产服务器,对于某些应用,还会需要进行构建。不同步骤的依赖会有一些不同,并且在不同的服务器上执行。
如果手动地在不同的服务器上安装依赖,是件很麻烦的事情。比如说,当你需要为Node.js应用添加一个新的npm模块,或者升级一下Node.js,是不是得重复操作很多次?
友情提示一下,手动敲命令是极易出错的,有些失误会导致致命的后果(参考最近Gitlab误删数据库与AWS的S3故障)。
如果使用Docker的话,开发、构建、测试、生产将全部在Docker容器中执行,你需要为不同步骤编写不同的Dockerfile。
当依赖变化时,仅需要稍微修改Dockerfile即可。结合构建工具Jenkins,就可以将整个部署流程自动化。另一方面,Dockerfile将Docker镜像描述得非常精准,能够保证很强的一致性。
比如,操作系统的版本,Node.js的版本,NPM模块的版本等。
这就意味着,在本地开发环境运行成功的镜像,在构建、测试、生产环境中也没有问题。
还有,不同的Docker容器是依赖于不同的Docker镜像,这样他们互不干扰。比如,两个Node.js应用可以分别使用不同版本的Node.js。

从集群管理角度理解Docker

架构规模越来越大的时候,你有必要引入集群了。
这就意味着,服务器由1台变成了多台,同一个应用需要运行多个备份来分担负载。当然,你可以手动对集群的功能进行划分: Nginx服务器,Node.js服务器,MySQL服务器,测试服务器,生产服务器…这样做的好处是简单粗暴;也可以说财大气粗,因为资源闲置会非常严重。还有一点,每次新增节点的时候,你就不得不花大量时间进行安装与配置,这其实是一种低效的重复劳动。
下载Docker镜像之后,Docker容器可以运行在集群的任何一个节点。一方面,各个组件可以共享主机,且互不干扰;另一方面,也不需要在集群的节点上安装和配置任何组件。
至于整个Docker集群的管理,业界有很多成熟的解决方案,例如Mesos,Kubernetes与Docker Swarm。这些集群系统提供了调度,服务发现,负载均衡等功能,让整个集群变成一个整体。
你不喜欢docker只是你还没理解他的好,等你理解以后他就会成为你开发的一个利器
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值