标签 Windows 下的文章

Docker 1.12 swarm模式下遇到的各种问题

前段时间,由于工作上的原因,与Docker的联系发生了几个月的中断^_^,从10月份开始,工作中又与Docker建立了广泛密切的联系。不过这次,Docker却给我泼了一盆冷水:(。事情的经过请允许多慢慢道来。

经过几年的开发,Docker已经成为轻量级容器领域不二的事实标准,应用范围以及社区都在快速发展和壮大。今年的年中,Docker发布了其里程碑的版本Docker 1.12,该版本最大的变动就在于其引擎自带了swarmkit ,一款Docker开发的容器集群管理工具,可以让用户无需安装第三方公司提供的工具或Docker公司提供的引擎之外的工具,就能搭建并管理好一个容器集群,并兼有负载均衡、服务发现和服务编排管理等功能。这对于容器生态圈内的企业,尤其是那些做容器集群管理和服务编排平台的公司来说,不亚于当年微软在Windows操作系统中集成Internet Explorer。对此,网上和社区对Docker口诛笔伐之声不绝于耳,认为Docker在亲手打击社区,葬送大好前程。关于商业上的是是非非,我们这里暂且不提。不可否认的是,对于容器的普通用户而言,Docker引擎内置集群管理功能带来的更多是便利。

9月末启动的一款新产品的开发中,决定使用容器技术,需要用到容器的集群管理以及服务伸缩、服务发现、负载均衡等特性。鉴于团队的能力和开发时间约束,初期我们确定直接利用Docker 1.12版本提供的这些内置特性,而不是利用第三方,诸如k8sRancher这样的第三方容器集群管理工具或是手工利用各种开源组件“拼凑”出一套满足需求的集群管理系统,如利用consul做服务注册和发现等。于是Docker 1.12的集群模式之旅就开始了。

一、环境准备

这次我们直接使用的是阿里的公有云虚拟主机服务,这里使用两台aliyun ECS:

manager: 10.46.181.146/21(内网)
worker: 10.47.136.60/22 (内网)

系统版本为:

Ubuntu 14.04.4:
Linux iZ25cn4xxnvZ 3.13.0-86-generic #130-Ubuntu SMP Mon Apr 18 18:27:15 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Docker版本:

# docker version
Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 05:22:43 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:        Thu Aug 18 05:22:43 2016
 OS/Arch:      linux/amd64

Ubuntu上Docker的安装日益方便了,我个人习惯于采用daocloud推荐的方式,在这里可以看到。当然你也可以参考Docker官方的doc

如果你的Ubuntu上已经安装了old版的Docker,也可以在docker的github上下载相应平台的二进制包,覆盖本地版本即可(注意1.10.0版本前后的Docker组件有所不同)。

二、Swarm集群搭建

Docker 1.12内置swarm mode,即docker原生支持的docker容器集群管理模式,只要是执行了docker swarm init或docker swarm join到一个swarm cluster中,执行了这些命令的host上的docker engine daemon就进入了swarm mode。

swarm mode中,Docker进行了诸多抽象概念(这些概念与k8s、rancher中的概念大同小异,也不知是谁参考了谁^_^):

- node: 部署了docker engine的host实例,既可以是物理主机,也可以是虚拟主机。
- service: 由一系列运行于集群容器上的tasks组成的。
- task: 在具体某个docker container中执行的具体命令。
- manager: 负责维护docker cluster的docker engine,通常有多个manager在集群中,manager之间通过raft协议进行状态同步,当然manager角色engine所在host也参与负载调度。
- worker: 参与容器集群负载调度,仅用于承载tasks。

swarm mode下,一个Docker原生集群至少要有一个manager,因此第一步我们就要初始化一个swarm cluster:

# docker swarm init --advertise-addr 10.46.181.146
Swarm initialized: current node (c7vo4qtb2m41796b4ji46n9uw) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join \
    --token SWMTKN-1-1iwaui223jy6ggcsulpfh1bufn0l4oq97zifbg8l5na914vyz5-2mg011xh7vso9hu7x542uizpt \
    10.46.181.146:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

通过一行swarm init命令,我们就创建了一个swarm集群。同时,Docker daemon给出了清晰提示,如果要向swarm集群添加worker node,执行上述提示中的语句。如果其他node要以manager身份加入集群,则需要执行:docker swarm join-token manager以获得下一个“通关密语”^_^。

# docker swarm join-token manager
To add a manager to this swarm, run the following command:

    docker swarm join \
    --token SWMTKN-1-1iwaui223jy6ggcsulpfh1bufn0l4oq97zifbg8l5na914vyz5-8wh5gp043i1cqz4at76wvx29m \
    10.46.181.146:2377

对比两个“通关密语”,我们发现仅是token串的后半部分有所不同(2mg011xh7vso9hu7x542uizpt vs. 8wh5gp043i1cqz4at76wvx29m)。

在未添加新node之前,我们可以通过docker node ls查看当前集群内的node状态:

# docker node ls
ID                           HOSTNAME      STATUS  AVAILABILITY  MANAGER STATUS
c7vo4qtb2m41796b4ji46n9uw *  iZ25mjza4msZ  Ready   Active        Leader

可以看出当前swarm仅有一个node,且该node是manager,状态是manager中的leader。

我们现在将另外一个node以worker身份加入到该swarm:

# docker swarm join \
     --token SWMTKN-1-1iwaui223jy6ggcsulpfh1bufn0l4oq97zifbg8l5na914vyz5-2mg011xh7vso9hu7x542uizpt \
     10.46.181.146:2377
This node joined a swarm as a worker.

在manager上查看node情况:

# docker node ls
ID                           HOSTNAME      STATUS  AVAILABILITY  MANAGER STATUS
8asff8ta70j91myh734os6ihg    iZ25cn4xxnvZ  Ready   Active
c7vo4qtb2m41796b4ji46n9uw *  iZ25mjza4msZ  Ready   Active        Leader

Swarm集群中已经有了两个active node:一个manager和一个worker。这样我们的集群环境初建ok。

三、Service启动

Docker 1.12版本宣称提供服务的Scaling、health check、滚动升级等功能,并提供了内置的dns、vip机制,实现service的服务发现和负载均衡能力。接下来,我们来测试一下docker的“服务能力”:

我们先来创建一个用户承载服务的自定义内部overlay网络:

root@iZ25mjza4msZ:~# docker network create -d overlay mynet1
avjvpxkfg6u8xt0qd5xynoc28
root@iZ25mjza4msZ:~# docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
dba1faa24c0d        bridge              bridge              local
a2807d0ec7ed        docker_gwbridge     bridge              local
2b6eb8b95c00        host                host                local
55v43pasf7p9        ingress             overlay             swarm
avjvpxkfg6u8        mynet1              overlay             swarm
6f2d47678226        none                null                local

我们看到在network list中,我们的overlay网络mynet1出现在列表中。这时,在worker node上你还看不到mynet1的存在,因为按照目前docker的机制,只有将归属于mynet1的task调度到worker node上时,mynet1的信息才会同步到worker node上。

接下来就是在mynet1上启动service的时候了,我们先来测试一下:

在manager节点上,用docker service命令启动服务mytest:

# docker service create --replicas 2 --name mytest --network mynet1 alpine:3.3 ping baidu.com
0401ri7rm1bdwfbvhgyuwroqn

似乎启动成功了,我们来查看一下服务状态:

root@iZ25mjza4msZ:~# docker service ps mytest
ID                         NAME          IMAGE       NODE          DESIRED STATE  CURRENT STATE                     ERROR
73hyxfhafguivtrbi8dyosufh  mytest.1      alpine:3.3  iZ25mjza4msZ  Ready          Preparing 1 seconds ago
c5konzyaeq4myzswthm8ax77w   \_ mytest.1  alpine:3.3  iZ25mjza4msZ  Shutdown       Failed 1 seconds ago              "starting container failed: co…"
6umn2qlj34okagb4mldpl6yga   \_ mytest.1  alpine:3.3  iZ25mjza4msZ  Shutdown       Failed 6 seconds ago              "starting container failed: co…"
5y7c1uoi73272uxjp2uscynwi   \_ mytest.1  alpine:3.3  iZ25mjza4msZ  Shutdown       Failed 11 seconds ago             "starting container failed: co…"
4belae8b8mhd054ibhpzbx63q   \_ mytest.1  alpine:3.3  iZ25mjza4msZ  Shutdown       Failed 16 seconds ago             "starting container failed: co…"

似乎服务并没有起来,service ps的结果告诉我:出错了!

但从ps的输出来看,ERROR那行的日志太过简略:“starting container failed: co…” ,无法从这里面分析出失败原因,通过docker logs查看失败容器的日志(实际上日志是空的)以及通过syslog查看docker engine的日志都没有特殊的发现。调查了许久,无意中尝试手动重启一下失败的Service task:

# docker start 4709dbb40a7b
Error response from daemon: could not add veth pair inside the network sandbox: could not find an appropriate master "ov-000101-46gc3" for "vethf72fc59"
Error: failed to start containers: 4709dbb40a7b

从这个Daemon返回的Response Error来看似乎与overlay vxlan的网络驱动有关。又经过搜索引擎的确认,大致确定可能是因为host的kernel version太low导致的,当前kernel是3.13.0-86-generic,记得之前在docker 1.9.1时玩vxlan overlay我是将kernel version升级到3.19以上了。于是决定升级kernel version

升级到15.04 ubuntu版本的内核:

命令:

    apt-get install linux-generic-lts-vivid

升级后:

# uname -a
Linux iZ25cn4xxnvZ 3.19.0-70-generic #78~14.04.1-Ubuntu SMP Fri Sep 23 17:39:18 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

reboot虚拟机后,重新启动mytest service,这回服务正常启动了。看来升级内核版本这味药是对了症了。

这里issue第一个吐槽:Docker强依赖linux kernel提供的诸多feature,但docker似乎在kernel版本依赖这块并未给出十分明确的对应关系,导致使用者莫名其妙的不断遇坑填坑,浪费了好多时间。

顺便这里把service的基本管理方式也一并提一下:

scale mytest服务的task数量从2到4:

docker service scale mytest=4

删除mytest服务:

docker service rm mytest

服务删除执行后,需要一些时间让docker engine stop and remove container instance。

四、vip机制测试

Docker 1.12通过集群内置的DNS服务实现服务发现,通过vip实现自动负载均衡。单独使用DNS RR机制也可以实现负载均衡,但这种由client端配合实现的机制,无法避免因dns update latency导致的服务短暂不可用的情况。vip机制才是相对理想的方式。

所谓Vip机制,就是docker swarm为每一个启动的service分配一个vip,并在DNS中将service name解析为该vip,发往该vip的请求将被自动分发到service下面的诸多active task上(down掉的task将被自动从vip均衡列表中删除)。

我们用nginx作为backend service来测试这个vip机制,首先在集群内启动mynginx service,内置2个task,一般来说,docker swarm会在manager和worker node上各启动一个container来承载一个task:

# docker service create --replicas 2 --name mynginx --network mynet1 --mount type=bind,source=/root/dockertest/staticcontents,dst=/usr/share/nginx/html,ro=true  nginx:1.10.1
3n7dlr8km9v2xd66bf0mumh1h

一切如预期,swarm在manager和worker上各自启动了一个nginx container:

# docker service ps mynginx
ID                         NAME       IMAGE         NODE          DESIRED STATE  CURRENT STATE               ERROR
bcyffgo1q3i5x0qia26fs703o  mynginx.1  nginx:1.10.1  iZ25mjza4msZ  Running        Running about a minute ago
arkol2l7gpvq42f0qytqf0u85  mynginx.2  nginx:1.10.1  iZ25cn4xxnvZ  Running        Running about a minute ago

接下来,我们尝试在mynet1中启动一个client container,并在client container中使用ping、curl对mynginx service进行vip机制的验证测试。client container的image是基于ubuntu:14.04 commit的本地image,只是在官方image中添加了curl, dig, traceroute等网络探索工具,读者朋友可自行完成。

我们在manager node上尝试启动client container:

# docker run -it --network mynet1 ubuntu:14.04 /bin/bash
docker: Error response from daemon: swarm-scoped network (mynet1) is not compatible with `docker create` or `docker run`. This network can only be used by a docker service.
See 'docker run --help'.

可以看到:直接通过docker run的方式在mynet1网络里启动container的方法失败了,docker提示:docker run与swarm范围的网络不兼容。看来我们还得用docker service create的方式来做。

# docker service create --replicas 1 --name myclient --network mynet1 test/client tail -f /var/log/bootstrap.log
0eippvade7j5e0zdyr5nkkzyo

# docker ps
CONTAINER ID        IMAGE                                                 COMMAND                  CREATED             STATUS              PORTS                    NAMES
4da6700cdf4d        test/client:latest   "tail -f /var/log/boo"   33 seconds ago      Up 32 seconds                                myclient.1.3cew8x46i5b28e2q3kd1zz3mq

我们使用exec命令attach到client container中:

root@iZ25mjza4msZ:~# docker exec -it 4da6700cdf4d /bin/bash
root@4da6700cdf4d:/#

在client container中,我们可以通过dig命令查看mynginx service的vip:

root@4da6700cdf4d:/# dig mynginx

; <<>> DiG 9.9.5-3ubuntu0.9-Ubuntu <<>> mynginx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34806
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mynginx.            IN    A

;; ANSWER SECTION:
mynginx.        600    IN    A    10.0.0.2

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11)
;; WHEN: Tue Oct 11 08:58:58 UTC 2016
;; MSG SIZE  rcvd: 48

可以看到为mynginx service分配的vip是10.0.0.2。

接下来就是见证奇迹的时候了,我们尝试通过curl访问mynginx这个service,预期结果是:请求被轮询转发到不同的nginx container中,返回结果输出不同内容。实际情况如何呢?

root@4da6700cdf4d:/# curl mynginx
^C
root@4da6700cdf4d:/# curl mynginx
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title> 主标题 | 副标题< /title>
</head>
<body>
<p>hello world, i am manager</p>
</body>
</html>
root@4da6700cdf4d:/# curl mynginx
curl: (7) Failed to connect to mynginx port 80: Connection timed out

第一次执行curl mynginx,curl就hang住了。ctrl+c后,再次执行curl mynginx,顺利返回manager节点上的nginx container的response结果:”hello world, i am manager“。

第三次执行curl mynginx,又hang住了,一段时间后显示timed out,这也从侧面说明了,swarm下的docker engine的确按照rr规则将request均衡转发到不同nginx container,但实际看来,从manager node上的client container到worker node上的nginx container的网络似乎不通。我们来验证一下这两个container间的网络是否ok。

我们在两个node上分别用docker inspect获得client container和nginx container的ip地址:

    manager node:
        client container: 10.0.0.6
        nginx container: 10.0.0.4
    worker node:
        nginx container: 10.0.0.3

理论上,位于同一overlay网络中的三个container之间应该是互通的。但实际上通过docker exec -it container_id /bin/bash进入每个docker container内部进行互ping来看,manager node上的两个container可以互相ping通,但无法ping通 worker node上的nginx container,同样,位于worker node上的nginx container也无法ping通位于manager node上的任何container。

通过docker swarm leave将worker节点从swarm cluster中摘出,docker swarm会在manager上再启动一个nginx container,这时如果再再client container测试vip机制,那么测试是ok的。

也就是说我遇到的问题是跨node的swarm network不好用,导致vip机制无法按预期执行。

后续我又试过双swarm manager等方式,vip机制在跨node时均不可用。在docker github的issue中,很多人遇到了同样的问题,涉及的环境也是多种多样(不同内核版本、不同linux发行版,不同公有云提供商或本地虚拟机管理软件),似乎这个问题是随机出现的。 按照docker developer的提示检查了swarm必要端口的开放情况、防火墙、swarm init的传递参数,都是无误的。也尝试过重建swarm,在init和join时全部显式带上–listen-addr和–advertise-addr选项,问题依旧没能解决。

最后,又将docker版本从1.12.1升级到最新发布的docker 1.12.2rc3版本,重建集群,问题依旧没有解决。

自此确定,docker 1.12的vip机制尚不稳定,并且没有临时解决方案能绕过这一问题。

五、Routing mesh机制测试

内部网络的vip机制的测试失败,让我在测试Docker 1.12的另外一个机制:Routing mesh之前心里蒙上了一丝阴影,一个念头油然而生:Routing mesh可能也不好用。

对于外部网络和内部网络的边界,docker 1.12提供了ingress(入口) overlay网络应对,通过routing mesh机制,保证外部的请求可以被任意集群node转发到启动了相应服务container的node中,并保证高
可用。如果有多个container,还可以实现负载均衡的转发。

与vip不同,Routing mesh在启动服务前强调暴露一个node port的概念。既然叫node port,说明这个暴露的port是docker engine listen的,并由docker engine将发到port上的流量转到相应启动了service container的节点上去(如果本node也启动了service task,那么也会负载分担留给自己node上的service task container去处理)。

我们先清除上面的service,还是利用nginx来作为网络入口服务:

# docker service create --replicas 2 --name mynginx --network mynet1 --mount type=bind,source=/root/dockertest/staticcontents,dst=/usr/share/nginx/html,ro=true --publish 8091:80/tcp nginx:1.10.1
cns4gcsrs50n2hbi2o4gpa1tp

看看node上的8091端口状态:

root@iZ25mjza4msZ:~# lsof -i tcp:8091
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
dockerd 13909 root   37u  IPv6 121343      0t0  TCP *:8091 (LISTEN)

dockerd负责监听该端口。

接下来,我们在manager node上通过curl来访问10.46.181.146:8091。

# curl 10.46.181.146:8091
^C
root@iZ25mjza4msZ:~# curl 10.46.181.146:8091
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title> 主标题 | 副标题< /title>
</head>
<body>
<p>hello world, i am master</p>
</body>
</html>
root@iZ25mjza4msZ:~# curl 10.46.181.146:8091

在vip测试中的一幕又出现了,docker swarm似乎再将请求负载分担到两个node上,当分担到worker node上时,curl又hang住了。routing mesh机制失效。

理论上再向swarm cluster添加一个worker node,该node上并未启动nginx service,当访问这个新node的8091端口时,流量也会被转到manager node或之前的那个worker node,但实际情况是,跨node流量互转失效,和vip机制测试似乎是一个问题。

六、小结

Docker 1.12的routing mesh和vip均因swarm network的问题而不可用,这一点出乎我的预料。

翻看Docker在github上的issues,发现类似问题从Docker 1.12发布起就出现很多,近期也有不少:

https://github.com/docker/docker/issues/27237

https://github.com/docker/docker/issues/27218

https://github.com/docker/docker/issues/25266

https://github.com/docker/docker/issues/26946

*https://github.com/docker/docker/issues/27016

这里除了27016的issue发起者在issue最后似乎顿悟到了什么(也没了下文):Good news. I believe I discovered the root cause of our issue. Remember above I noted our Swarm spanned across L3 networks? I appears there is some network policy that is blocking VxLAN traffic (4789/udp) across the two L3 networks. I redeployed our same configuration to a single L3 network and can reliably access the published port on all worker nodes (based on a few minutes of testing)。其余的几个issue均未有solution。

不知道我在阿里云的两个node之间是否有阻隔vxlan traffic的什么policy,不过使用nc探测4789 udp端口均是可用的:

nc -vuz 10.47.136.60 4789

无论是配置原因还是代码bug导致的随机问题,Docker日益庞大的身躯和背后日益复杂的网络机制,让开发者(包括docker自己的开发人员)查找问题的难度都变得越来越高。Docker代码的整体质量似乎也呈现出一定下滑的不良趋势。

针对上述问题,尚未找到很好的解决方案。如果哪位读者能发现其中玄机,请不吝赐教。

现代企业应用架构-使用Docker CaaS交付敏捷的、可移植的、受控的应用

年初,火得发烫的独角兽IT公司Docker发布了一款新的企业级产品 Docker Datacenter (简称:DDC)。作 为拥有原生Docker容器技术的公司,其每个市场动作都会让轻量级容器生态圈内的公司不敢小觑。而要揣度Docker对商业改变的理解、对容器 技术栈应用的理解以及对新产品和服务在生态圈中的定位,就有必要对Docker的这款产品做一些比较深刻的了解。而其技术白皮书 恰是我们了解 Docker该产品的入口。这里我就基于自己对容器相关技术栈的粗浅理解,翻译一下这篇篇幅不长的技术白皮书,希望能给大家带来些许帮助。

标题:现代企业应用架构-使用Docker CaaS交付敏捷的、可移植的、受控的应用

译文全文如下:

摘要

开发人员不接受被锁住的平台。就像《金发小女孩和三只熊》 故事那样,开发人员们一直在为其开发环境寻找一种可以在自由和约束之间拥 有最佳平衡的权力。在这个过程中,他们发现“平台即服务”(PaaS)模型层次太高、过于抽象以及约束过多,并且为了实现一个完全锁定的、黑盒的 环境而牺牲了灵活性;同时,他们也发现“基础设施即服务”(IaaS)模型提供的各自的容器服务也是不够的,因为那种服务仅驻留在各自的基础设施 中,缺乏远见。在寻求适当方案的过程中,一些组织开始提供基于Docker的“容器即服务”(CaaS)的环境,这种模型为开发团队提供了敏捷 性;为运维团队提供了控制力;为应用程序提供了跨基础设施的可移植性 — 从本地数据中心到公有云,横跨诸多网络和存储设备供应商。

Docker平台为基础设施无关的CaaS模型提供了一套集成套件。使用这个方案,IT运维团队既可以对基础设施,也可以对基础应用内容进行安全 保护、配置和管理;同时开发人员也能够以自助的方式来构建和部署他们的应用。

在本白皮书中,我们将讨论新软件模型的驱动力,Docker平台的能力,细化CaaS的需求,以及详细说明在构建、交付(运输)和运行应用程序过 程中解决核心问题的重要性。

重要结论包括:

• 云、数据和微服务是如何改变商业的
• 理解Docker的发展历程
• Docker CaaS模型的能力与优势

一、通过软件改变商业

运行成品软件的私有数据中心以及一年更新一次的巨大单一代码库的时代已经离我们远去了。一切都在变化。不管是迁移到云上,在云间移植,用现代化的 方法改造遗留程序,还是构建新的应用和数据结构,我们想要的结果都是相同的 – 速度。你动作的越快,你的公司将会越成功。

软件是定义你的公司的关键IP(知识产权),即便你的公司实际出售的商品可能只是一件T恤、一辆车或复利(compounding interest)。软件就是你如何接洽客户,如何吸引新用户,如何理解他们的数据,如何推广你的产品或服务以及如何处理他们的订单。

要做好这些,当今的软件正趋向定制化。为一个非常具体的工作而设计的软件片段被称为微服务(microservice)。微服务的设计目标是让 每一个由必要组件构建出来的服务在适当类型的底层基础设施资源上运行一个特定的工作(job)。接下来,这些服务松耦合在一起,可以随时被修改, 无需担心服 务运行的先后次序。

这种方法,虽然对持续改进十分有利,但在达成最终结果的过程中也提出了许多挑战。首先,它创建了一个新的、不断膨胀的服务、依赖和基础设施矩阵, 让它自身很难于管理。此外,它没有考虑到眼前大量已经存在的遗留程序,完全异构的应用程序栈以及实际中必须保证运行起来的进程。

二、Docker的发展历程以及AND的力量

2013年,Docker以具备构建、交付、到处运行的应用容器而出现在大众视野当中。与今天集装箱的运输类似,软件容器就是一个软件的标准单 元,不管容器内存放的代码和依赖是什么,容器外部看起来都相同。这使得开发人员和系统管理员可以跨基础设施和各种各样环境传输容器,而无需做任何 修改和考虑不同环境下的不同配置。Docker的历程就从此时开始了。

敏捷性: Docker的速度和简洁让Docker一经推出便大受开发者欢迎,同时也使得其开源项目的热度以流星般速度蹿升。现在开发者能很容易地将软件以及其依赖 打包到一个容器中。开发者可以使用任何语言、版本和工具,因为这些都被打包到一个容器中,容器将所有异质性标准化了,并且无需付出任何代价。

可移植性: Docker技术的本质让那批开发者意识到他们的应用容器现在可移植了,而且是以在以前不可能的方式。他们可以将应用从开发环境直接交付到测试和产品环境 且代码总是按设计那样正常工作。环境中的任何差异都不会影响到容器里面的应用。应用也无需修改就可以正常工作在生产环境中。这同样也是IT运维团 队的一个福音,因为现在他们可以跨数据中心迁移应用来避免厂商的平台锁定了。

控制: 当应用程序沿着通往生产环境的生命周期前进时,关于安全性、可管理性以及伸缩性等新问题需要进一步得到解答。Docker标准化了你的环境,同时维护着你 的业务所需的异质性。Docker提供了设置适当控制级别的能力以及维护服务级别、性能以及监管的灵活性。IT运维组能够通过供应、安全加固、监 控和伸缩基础设施和应用来保持峰值服务水平。没有两个程序或业务是一样的,Docker允许你决定如何去控制你的应用环境。

Docker成长历程的核心是AND的力量。Docker是唯一一个可以跨应用生命周期所有阶段,为开发者和IT运维团队在提供敏捷性、可移植性 和控制的方案。从这些核心原则来看,CaaS的脱颖而出正是由于由其构建的新应用又好又快。

三、Docker Containers as a Service(CaaS)

容器即服务(CaaS)是什么?它是基于基础设施和内容的一个IT受控的、安全的应用环境,利用它开发人员可以以自助的方式构建和部署应用。

img{512x368}

在上面的CaaS图示中,开发和IT运维团队通过registry相互协作。registry服务用于维护一个安全的、经过签名的映像仓库。左边 的开发者通过registry服务可以将软件拉(pull)到本地,按自己的步伐构建软件。当软件通过集成测试,开发者将其内容推回(push back)registry以保存最新版本。部署步骤因内部过程的不同而异,既可以通过工具自动进行,也可以是人工部署。

上图中右侧的IT运维组为生产环境基础设施管理着不同供应商的合同,诸如:计算、网络和存储。这些团队负责提供应用所需的计算资源,使用 Docker Universal Control Plane随时随地监控集群和应用。他们能在云间迁移应用,或伸缩服务来维持峰值服务水平。

四、关键特性和考量

Docker CaaS为组织提供了一套框架用于统一他们环境中的各种系统、语言和工具,并为业务提供所需的控制、安全或特权级别。由于是一种支持全部Docker API的Docker原生方案,Docker CaaS能够无缝地将应用从本地开发环境部署到生产环境,而无需改变代码或简化部署周期。

以下特性组成了组织应用环境的最低需求。在这个范式中,开发和运维团队被授权使用各自最佳的工具,而无需担心对系统、其他人的工作流或锁定状态造 成破坏。

1、开发者和运维的需求。 许多工具仅能解决针对一个团队的功能需求,但CaaS打破了持续改进的周期。为了获得从开发到生产环境运行的真正加速,你需要在一个连续周期内同时满足两类用户的需求。Docker为每个团队都提供了独特的能力,同时还提供了横跨整个平台的一致的API,保证了从一个团队到另外一个团队的无缝过渡。

2、应用程序生命周期的所有阶段。 从持续集成到持续交付以及开发运维(devops),这些实践都是为了消除瀑布开发方法以及其带来的滞后的周期。通过给开发和运维团队提供工具,Docker可以无缝的支持应用从构建、测试到部署到生产环境运行的所有阶段。

3、任何语言。开发者敏捷性意味着开发者在构建他们的应用的时候可以自由选择使用任何应用特性需要的编程语言、版本和工具。同时,在同一时间运行一个语言的多个版本的能力也为开发者提供了极大的灵活性。Docker让你的团队更加关注于构建应用程序本身,而不是思考如何构建一个可以在Docker中运行的应用。

4、任何操作系统。 绝大多数的组织拥有不止一款操作系统。一些工具在Linux上工作的更好,而另外一些可能在Windows上运行的更优异。应用平台需要考虑和支持这种多样性。否则,只能算是解决了部分问题而已。Docker起初是为Linux社区量身打造的,但Docker和微软公司正着手在Windows Server上实现Docker,以支持数百万现存企业应用以及未来企业应用。

5、任何基础设施。 谈到基础设施,组织想要的是选择、备份和杠杆作用。这是否意味着你需要拥有多个私有数据中心,一个混合云或者多个云提供商呢,其实关键点在于具备将应用负荷在不同环境间迁移而又不出问题的能力。Docker技术架构将基础设施与应用分离,使得应用容器可以在横跨基础设施在任意基础设施上运行。

6、Open API,插件式架构和生态系统。 一个平台不能算作是一个真正的平台,如果它只是一个封闭的孤岛。如果你想首先改良更新你现有的环境,通过实现新技术一般是不可行的。Docker的一个基本指导原则就是一个开放的平台。开放意味着API和插件可以让你利用上你已有的投资并让Docker适应你的环境和过程。开放性可以让生态系统更加活跃,且当你的CaaS增加特定功能时,它可以给你提供更多的灵活性和更多的选择。

虽然CaaS具有许多特性,但上述这些特性却是关键的,因为这种新的定制化应用范式只是为你的技术架构引入了更多异质性。Docker CaaS平台根本上就是为了支持这种多样性而设计的,并且针对任意规模提供相应的控制能力。

五、Docker CaaS

平台组件: Docker CaaS平台由一系列集成软件方案以及一个灵活的部署模型组成,以满足你的业务需求。

img{512x368}

本地数据中心/虚拟私有云(VPC): 对于那些要使用自己网络的组织,Docker Trusted Registry和Docker Universal Control Plan可以被部署在本地数据中心或虚拟私有云中,并且可以连接你已有的基础设施以及系统,比如存储、Active Directory/LDAP以及监控与日志解决方案。映像文件存储在你自己的存储架构中,Trusted Registry提供存储和管理服务能力,并且同时提供基于角色的对映像的基本访问控制。Universal Control Plane提供对Docker环境的可视化管理,包括Swarm集群、Trusted Registry仓库,容器以及多容器应用。

在云中: 对于那些接受使用SaaS方案的组织来说,Docker Hub和Docker Cloud提供了基于Docker上运行和管理的registry和control plane服务。Hub是一个云Registry服务,用于存储和管理映像文件以及用户权限。Docker Cloud供应和管理部署集群,同时也监控和管理已部署应用。使用Docker Cloud连接到你选择的云基础设施或使用你自己的物理节点来部署你的应用吧。

你的Docker CaaS可以设计成集中控制和管理,也可以设计成分布式管理以授权给各自应用团队。这种灵活性使得你可以建立一个最适合你的业务的模型,就像你选择基础设施和内容实现过程那样。CaaS是构建、交付和运行应用理念的一个延伸。

事实上由于CaaS统一了跨环境的本质,加速了许多IT倡议被接纳的过程。每个组织都有其自己采纳的倡议:从容器化,包括对已有应用的改造和迁移,到微服务,再到持续集成、持续交付和devops以及对各类云的接纳、迁移、混合及支持多种云。在每个场景中,Docker CaaS都能带来敏捷性、可移植性和控制,使得组织能接受那些用例。

六、AND的力量

总之,云、应用和数据的变化已经将技术和商业之间的对话,从“你如何帮我削减成本”换成了“你如何加速我的商业”。当你踏上你的旅途时,Docker提供了额外的灵活性帮你选择在哪里存储你的应用内容以及在哪里部署你的控制台。让你的CaaS适配你的业务需求,不管是部署在本地数据中心或虚拟私有云上,还是作为云服务被平滑地消费。无论你的业务是什么,Docker CaaS平台都会提供敏捷性、可移植性和控制力,尽可能又快又好的构建最好的应用,以最优的代价提供峰值性能的服务,并且不会被平台锁定。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats