初试Docker swarm命令
测试环境:
- OS:OS X
- Docker:1.12.0-rc2
- Docker Machine:0.8.0-rc1
系统构成:
升级Docker
使用Docker for Mac升级Docker很简单,这里不多说了;升级之后确认一下是最新版的Docker就可以了。
创建3台Docker主机
首先,使用Docker Machine创建3台主机,一台名为 manager1
,其余两台为 worker1
和 worker2
:
创建master节点:
创建2个worker节点:
之后可以确认一下3台机器是否创建成功,以及ta们的IP地址:
创建Swarm集群
首先,切换到 manager1
主机,使用 docker swarm init
命令创建一个集群:
使用 docker info
确认一下当前节点信息,可以看到Swarm属性部分:
在2台worker节点上,通过 docker swarm join
命令加入到刚才创建的集群中:
回到 manager1
节点,确认一下集群中节点的个数和状态。在 MANAGER STATUS
属性中,可以看到谁是Leader:
创建nginx服务
首先,创建一个覆盖网络:
然后使用这个覆盖网络,创建nginx服务:
这样,就创建了一个具有一个副本( --replicas 1
)的 nginx
服务,使用镜像 nginx
。
注意上面的 STATE
字段中刚开始的服务状态为 Preparing
,需要等一会才能变为 Running
状态,其中最费时间的应该是下载镜像的过程。
过一会再查看服务状态,就可以看到状态已经变为 Running
了,这是可以通过 http://192.168.99.100/
查看 Nginx服务。
对服务进行扩展(scale)
当然,如果只是通过service启动容器,swarm也算不上什么新鲜东西了。Service还提供了复制(类似k8s里的副本)功能。可以通过 docker service scale
命令来设置服务中容器的副本数:
和创建服务一样,增加scale数之后,将会创建新的容器,这些新启动的容器也会经历从准备到运行的过程,过一分钟左右,服务应该就会启动完成,这时候可以再来看一下 nginx
服务中的容器(task):
可以看到,之前 nginx
容器只在 manager1
上有一个实例,而现在又增加了4个实例。
我们可以在 manager1
上查看一下这台主机上运行的容器:
容器异常停止时的处理
如果一个服务中的一个任务突然终止了,Docker会怎么处理?这里我们就来模拟某一容器异常终止的情况。
在操作之前,我们在另一个窗口,准备好使用 tail -f /var/log/docker.log
命令来查看Docker守护进程的日志。
我们通过 docker rm -f
来删除一个容器(4b
表示的是我们第一个启动的 4bbc02bc426e
容器):
回到Docker守护进程的日志查看窗口,我们会看到类似这样的日志(有删减),从日志中,我们可以看到旧容器(id为 4bbc02bc426e
,task id为 d8okdip767972p083tix4dk7d
)的删除和新容器(task id为 cumjdktbadaxca66rt4hi63na
)的调度过程(删除了日志中的时间戳和日志级别等非重要信息,但保留了日志的时间顺序):
从上面的日志我们不难看出,一个任务的生命周期的前半生,大概就是 ASSIGNED
-> ACCEPTED
-> PREPARING
-> STARTING
-> RUNNING
。
在 manager1
主机上,我们看到这个容器已经删除了, ps
只能看到一个容器:
再来查看一下 nginx
服务的任务列表,可以看到新创建的任务 cumjdktbadaxca66rt4hi63na
被调度到了 worker2
上运行:
删除一个节点?
不难想象,如果一个节点都宕机了,则Docker应该会将在该节点运行的容器,调度到其他节点,以满足指定数量的副本保持运行状态。
下面我们就来模拟一下这种场景。
首先,我们删除一个节点 worker2
:
删除之后,Docker就会开始重新调度,最终调度结束(< 1分钟)后,再查看该服务的任务状态,应该如下面这样,有5个 nginx
容器在剩下的两台机器上运行:
除了上面用到的一些命令, docker service
还有以下一些子命令:
比如我们可以用 docker service inspect
来获得 nginx
服务的详情信息:
也可以通过 docker service rm nginx
命令,删除 nginx
服务(现在的版本删除服务前没有警告提示,请小心操作)。
总结
上手很简单,Docker swarm可以非常方便的创建类似k8s那样带有副本的服务,确保一定数量的容器运行,保证服务的高可用。
然而,光从官方文档来说,功能似乎又有些简单,从生产环境来说,下面这些方面都还有所欠缺(其实从Swarm v1就有这个问题):
- 没有配置文件,不好进行版本化管理,不方便部署
- 持久存储的缺失。Docker已经支持Volume Driver,k8s等也有存储卷插件在机制,真正的生产环境没有Volume支持估计是很难想象的。
- 是否能确保本身的高可用
- 调度策略还处于初级阶段
不过,正如Docker让容器技术变得平民化一样,Docker Machine和Swarm,也将在各种基础设施上运行Docker和Docker集群变得更加简单,从这一点上来说,其意义也是很大的。
不过在开源社区和商业竞争的角度来看,Docker Swarm将会走向何方呢?
评论前必须登录!
注册