在分布式应用中,一个完整的应用可能由多个不同的部件组成,每一个组件就是一个“服务”。在Docker中,服务是比容器更高一层的抽象。每个服务都管理一种类型的容器,但是它可以定义运行几个实例、资源配额、负载均衡、对外保暴露的端口、重启策略等。
想要使用Docker中的服务功能,除了基本的Docker组件,另外还要安装Docker compose。参考https://docs.docker.com/compose/overview/
Docker通过yaml文件定义一个服务,示例代码如下:
version: "3"
services:
web:
# replace username/repo:tag with your name and image details
image: username/repo:tag
deploy:
replicas: 5
resources:
limits:
cpus: "0.1"
memory: 50M
restart_policy:
condition: on-failure
ports:
- "4000:80"
networks:
- webnet
networks:
webnet:
代码解释。
version: "3"
表示compose的版本。
services:
services节点下边包含服务,可以是一个服务也可以是多个服务,但是每个服务都只管理一种类型的容器。
web:
服务名称
image: username/repo:tag
服务下边容器运行时使用的image,要保证它可用。
deploy:
replicas: 5
resources:
limits:
cpus: "0.1"
memory: 50M
restart_policy:
condition: on-failure
这一部分代码指出,需要运行5个容器实例,每个容器实例占用的cpu、内存,最后是重启策略,当容器实例运行失败时重启。
ports:
- "4000:80"
networks:
- webnet
这一部分指出将容器网络上的80端口映射到宿主机上的4000端口,webnet表示容器运行时本身使用的网络。其实这里有几个问题,关于4000端口。Docker在集群内可能把实例部署在任何节点上,而节点上的4000端口是否已经被占用是无法保证的。本质上的问题是docker实例本身与宿主机发生了强耦合,在正式应用中这个是不可以的。
在节点环境中,客户端通过访问宿主机4000端口访问服务,宿主机在几个可用的实例中选择一个为用户服务,相当于是宿主机提供了负载均衡的功能。如果是多节点环境,容器实例分布在多个节点上,则会需要DNS服务的配合,需要比宿主机更高层次的负载均衡,这样客户端才能找到容器实例。
本示例只是简单展示,这些问题会在另一篇介绍compose的文章中分析解决方案。
networks:
webnet:
使用到的网络,可以被所有本文件中定义的服务使用。
运行服务
Docker compose定义的服务只能通过Docker swarm集群部署。假设现在只在一台主机上运行Docker,执行如下命令创建集群:
docker swarm init
本命令创建了一个swarm集群,当然目前集群中只有一个节点,此节点既是master管理节点,也是工作节点。关于多节点swarm集群的创建,参考:https://blog.csdn.net/dkfajsldfsdfsd/article/details/79923218。
运行如下命令运行服务:
docker stack deploy -c docker-compose.yml getstartedlab
命令成功后,列出系统中所有服务:
docker service ls
单独查看某个服务的详情:
docker service ps getstartedlab_web
查看系统中所有容器:
docker container ls -q
缩扩容
修改yaml文件中副本的个数,然后重新部署:
docker stack deploy -c docker-compose.yml getstartedlab
结束服务运行
docker stack rm getstartedlab
# 结束集群
docker swarm leave --force
本文是一个简单的示例,部署的实例存在很多问题,如实例对宿主机网络的依赖、对宿主机存储的依赖、将实例从一个节点迁移到另一个节点可能吗?如果实现?负载均衡怎么解决?DNS怎么解决等。下一篇专门分析一下compose如何解决此类问题。