文章目录
- 一、Docker概述
- 二、Docker三剑客
- 1. Compose
- 2. Machine
- 3. Swarm
- 三、简要需求
- 1. 样例工程
- 2. 代码模块
- 3. 调用方向
- 4. 期望启动顺序
- 四、思路分析
- 1.各走各路
- 1.)`docker-compose -f`指定不同配置文件
- 2.)`docker-compose up -d service-name`指定服务名
- 3.)两种方式比较
- 2. 等等我
- 1.)脚本
- 2.)如何使用
- 3.)执行结果
- 五、关于depends_on
一、Docker概述
Docker 是一个开源的应用容器引擎,基于 Go 语言 并遵从 Apache2.0 协议开源。
Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化。
容器是完全使用沙箱机制,相互之间不会有任何接口(类似 iPhone 的 app),更重要的是容器性能开销极低。
Docker的应用场景
- Web 应用的自动化打包和发布。
- 自动化测试和持续集成、发布。
- 在服务型环境中部署和调整数据库或其他的后台应用。
- 从头编译或者扩展现有的 OpenShift 或 Cloud Foundry 平台来搭建自己的 PaaS 环境。
二、Docker三剑客
compose、machine 和 swarm
是docker 原生提供的三大编排工具。
1. Compose
在实际生产环境中,一个应用往往由许多服务构成,而 docker 的最佳实践是一个容器只运行一个进程,因此运行多个微服务就要运行多个容器。多个容器协同工作需要一个有效的工具来管理他们,定义这些容器如何相互关联。compose 应运而生。
compose 是用来定义和运行一个或多个容器(通常都是多个)运行和应用的工具。使用 compose 可以简化容器镜像的构建以及容器的运行。
compose 使用 YAML 文件来定义多容器之间的关系。一个 docker-compose up 就可以把完整的应用跑起来。
2. Machine
Docker Machine 是一个简化Docker 安装的命令行工具。通过一个简单的命令行即可在相应的平台上安装 Docker,为用户提供了灵活的功能,使得用户可以在任一主机上运行 Docker 容器。简单说,一个 Docker Machine 就是一个 Docker host 主机和经过配置的 Docker client 的结合体。
3. Swarm
Swarm 是 Docker 社区提供的原生支持 Docker 集群的工具。 它可以把多个 Docker 主机组成的系统转换成为单一的虚拟 Docker 主机。Swarm 对外提供两种 API。一种是标准的 Docker API,例如 Dokku、Compose、Krane、Flynn、Deis、Jenkins等;另一种是 Swarm 的集群管理 API,用于集群的管理。
Swarm工具本身不是很成熟,不建议用在生产环境。
而 Google 开源的Kubernetes
是目前容器生态圈中最受欢迎的编排部署工具。
三、简要需求
1. 样例工程
https://gitee.com/00fly/microservice-all-in-one/tree/master/micro-service
git clone https://gitee.com/00fly/microservice-all-in-one.git
2. 代码模块
模块 | 功能 | 说明 |
---|---|---|
microservice-eureka | 注册中心 | - |
microservice-front | 前端工程 | 后台访问网关接口 |
microservice-gateway | 网关 | 路由、聚合接口文档 |
microservice-movie | 微服务1 | - |
microservice-user | 微服务2 | - |
3. 调用方向
4. 期望启动顺序
① eureka --> ②user --> ③ movie --> ④ gateway --> ⑤front
四、思路分析
1.各走各路
简单来说就是: 分组启动,必须保证服务在同一网络内
1.)docker-compose -f
指定不同配置文件
springboot有一核心原则:约定大于配置
,在compose也类似,我们知道docker-compose中默认的配置文件为docker-compose.yml
,这并不意味着我们只能使用此配置文件,实际上我们可以通过类似 docker-compose -f xxx.yml
来指定。
具体文件见:https://gitee.com/00fly/microservice-all-in-one/tree/master/micro-service/docker/compose-network-step-by-step
将此目录上传到安装了docker的lunix服务器目录,依次执行0-4 sh,镜像已经上传到阿里,发现容器启动成功。
2.)docker-compose up -d service-name
指定服务名
具体文件见:https://gitee.com/00fly/microservice-all-in-one/tree/master/micro-service/docker/compose-step-by-step
全部的服务均在docker-compose.yml
中指定,服务均位于同一网络内
。
3.)两种方式比较
指定不同配置文件
优点:步骤清晰,服务划分一目了然
缺点:需要提前指定网络,后期调整服务启动顺序,需要修改yml文件,稍显麻烦,维护不便。
指定服务名
优点:统一使用默认compose配置文件,后期调整服务启动顺序方便。
2. 等等我
借助wait-for.sh实现
需要注意的是:此脚本需要提前打包到镜像内。
1.)脚本
wait-for.sh
#!/bin/sh
TIMEOUT=15
QUIET=0
echoerr() {
if [ "$QUIET" -ne 1 ]; then printf "%s\n" "$*" 1>&2; fi
}
usage() {
exitcode="$1"
cat << USAGE >&2
Usage:
$cmdname host:port [-t timeout] [-- command args]
-q | --quiet Do not output any status messages
-t TIMEOUT | --timeout=timeout Timeout in seconds, zero for no timeout
-- COMMAND ARGS Execute command with args after the test finishes
USAGE
exit "$exitcode"
}
wait_for() {
for i in `seq $TIMEOUT` ; do
nc -z "$HOST" "$PORT" > /dev/null 2>&1
result=$?
if [ $result -eq 0 ] ; then
if [ $# -gt 0 ] ; then
exec "$@"
fi
exit 0
fi
sleep 1
done
echo "Operation timed out" >&2
exit 1
}
while [ $# -gt 0 ]
do
case "$1" in
*:* )
HOST=$(printf "%s\n" "$1"| cut -d : -f 1)
PORT=$(printf "%s\n" "$1"| cut -d : -f 2)
shift 1
;;
-q | --quiet)
QUIET=1
shift 1
;;
-t)
TIMEOUT="$2"
if [ "$TIMEOUT" = "" ]; then break; fi
shift 2
;;
--timeout=*)
TIMEOUT="${1#*=}"
shift 1
;;
--)
shift
break
;;
--help)
usage 0
;;
*)
echoerr "Unknown argument: $1"
usage 1
;;
esac
done
if [ "$HOST" = "" -o "$PORT" = "" ]; then
echoerr "Error: you need to provide a host and port to test."
usage 2
fi
wait_for "$@"
2.)如何使用
用法sh wait-for.sh {检测地址}:{检测端口} -- {检测成功后执行脚本}·
举例如下
sh wait-for.sh www.baidu.com:80 -- echo "baidu is up"
具体文件见:https://gitee.com/00fly/microservice-all-in-one/blob/master/micro-service/docker/compose-wait/docker-compose.yml
执行restart.sh
#!/bin/bash
docker-compose down && docker-compose --compatibility up -d && docker stats
3.)执行结果
启动eureka
启动user
启动movie
启动gateway
启动front
我们也可以查看日志
Operation timed out就是wait-for.sh打印的等待日志信息。
五、关于depends_on
有同学已经注意到,在docker-compose.yml中, 可以使用depends_on
以下是一些关于 depends_on 的详解:
-
启动顺序:
通过在服务的配置中使用 depends_on,您可以告诉 Docker Compose 在启动容器时按照指定的顺序启动服务。例如,如果服务 A 依赖于服务 B 和服务 C,则在启动时,Docker Compose 会先启动服务 B 和服务 C,然后才会启动服务 A。 -
仅表示依赖关系:
depends_on 只表示依赖关系,而不会等待依赖的服务完全可用。它只确保在依赖的服务启动后再启动当前服务。因此,依赖的服务可能仍在进行初始化或准备阶段,而不一定已经完全可用。如果需要等待服务完全可用,可以结合使用其他工具或技术,例如健康检查或等待脚本。 -
无法保证健康状态:
depends_on 并不能保证依赖的服务在启动后处于健康状态。它只负责在启动时按照指定顺序启动服务,但并不检查服务的健康状态或等待服务变为可用状态。对于检查服务健康状态,可以使用其他机制,例如使用健康检查命令或工具。 -
并行启动:
默认情况下,Docker Compose 会尽可能并行启动服务,而不是完全按照 depends_on 指定的依赖关系顺序启动。这是因为 Docker Compose 会尝试最大化容器的并发启动,以提高启动效率。如果需要强制按照依赖关系顺序启动,请使用 depends_on 结合 restart 关键字的 condition: [“service_started”] 选项。
综上所述,depends_on 关键字允许您定义 Docker Compose 服务之间的依赖关系,但它并不能保证服务的可用性或健康状态
。
有任何问题和建议,都可以向我提问讨论,大家一起进步,谢谢!
-over-