Docker-Compose安装

安装方法一：
下载Docker-Compose：

sudo curl -L https://github.com/docker/compose/releases/download/1.23.0-rc3/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

安装Docker-Compose：
sudo chmod +x /usr/local/bin/docker-compose
查看版本 :
docker-compose version
安装方法二：
安装pip

yum -y install epel-release yum -y install python-pip

确认版本
pip --version
更新pip
pip install --upgrade pip
安装docker-compose
pip install docker-compose
查看版本
docker-compose version
安装补全工具：
为了方便输入命令，也可以安装Docker的补全提示工具帮忙快速输入命令：
安装
yum install bash-completion
下载docker-compose脚本

curl -L https://raw.githubusercontent.com/docker/compose/$(docker-compose version --short)/contrib/completion/bash/docker-compose > /etc/bash_completion.d/docker-compose

3、Docker-Compose卸载

如果是二进制包方式安装的，删除二进制文件即可：
sudo rm /usr/local/bin/docker-compose
如果通过Python pip工具安装的，则执行如下命令删除：
sudo pip uninstall docker-compose

Compose 文件格式有3个版本,分别为1, 2.x 和 3.x
目前主流的为 3.x 其支持 docker 1.13.0 及其以上的版本

常用参数：
version # 指定 compose 文件的版本
services # 定义所有的 service 信息, services 下面的第一级别的 key 既是一个 service 的名称

 build # 指定包含构建上下文的路径, 或作为一个对象，该对象具有 context 和指定的 dockerfile 文件以及 args 参数值 context # context: 指定 Dockerfile 文件所在的路径 dockerfile # dockerfile: 指定 context 指定的目录下面的 Dockerfile 的名称(默认为 Dockerfile) args # args: Dockerfile 在 build 过程中需要的参数 (等同于 docker container build --build-arg 的作用) cache_from # v3.2中新增的参数, 指定缓存的镜像列表 (等同于 docker container build --cache_from 的作用) labels # v3.3中新增的参数, 设置镜像的元数据 (等同于 docker container build --labels 的作用) shm_size # v3.5中新增的参数, 设置容器 /dev/shm 分区的大小 (等同于 docker container build --shm-size 的作用) command # 覆盖容器启动后默认执行的命令, 支持 shell 格式和 [] 格式 configs # 不知道怎么用 cgroup_parent # 不知道怎么用 container_name # 指定容器的名称 (等同于 docker run --name 的作用) credential_spec # 不知道怎么用 deploy # v3 版本以上, 指定与部署和运行服务相关的配置, deploy 部分是 docker stack 使用的, docker stack 依赖 docker swarm endpoint_mode # v3.3 版本中新增的功能, 指定服务暴露的方式 vip # Docker 为该服务分配了一个虚拟 IP(VIP), 作为客户端的访问服务的地址 dnsrr # DNS轮询, Docker 为该服务设置 DNS 条目, 使得服务名称的 DNS 查询返回一个 IP 地址列表, 客户端直接访问其中的一个地址 labels # 指定服务的标签，这些标签仅在服务上设置 mode # 指定 deploy 的模式 global # 每个集群节点都只有一个容器 replicated # 用户可以指定集群中容器的数量(默认) placement # 不知道怎么用 replicas # deploy 的 mode 为 replicated 时, 指定容器副本的数量 resources # 资源限制 limits # 设置容器的资源限制 cpus: "0.5" # 设置该容器最多只能使用 50% 的 CPU memory: 50M # 设置该容器最多只能使用 50M 的内存空间 reservations # 设置为容器预留的系统资源(随时可用) cpus: "0.2" # 为该容器保留 20% 的 CPU memory: 20M # 为该容器保留 20M 的内存空间 restart_policy # 定义容器重启策略, 用于代替 restart 参数 condition # 定义容器重启策略(接受三个参数) none # 不尝试重启 on-failure # 只有当容器内部应用程序出现问题才会重启 any # 无论如何都会尝试重启(默认) delay # 尝试重启的间隔时间(默认为 0s) max_attempts # 尝试重启次数(默认一直尝试重启) window # 检查重启是否成功之前的等待时间(即如果容器启动了, 隔多少秒之后去检测容器是否正常, 默认 0s) update_config # 用于配置滚动更新配置 parallelism # 一次性更新的容器数量 delay # 更新一组容器之间的间隔时间 failure_action # 定义更新失败的策略 continue # 继续更新 rollback # 回滚更新 pause # 暂停更新(默认) monitor # 每次更新后的持续时间以监视更新是否失败(单位: ns|us|ms|s|m|h) (默认为0) max_failure_ratio # 回滚期间容忍的失败率(默认值为0) order # v3.4 版本中新增的参数, 回滚期间的操作顺序 stop-first #旧任务在启动新任务之前停止(默认) start-first #首先启动新任务, 并且正在运行的任务暂时重叠 rollback_config # v3.7 版本中新增的参数, 用于定义在 update_config 更新失败的回滚策略 parallelism # 一次回滚的容器数, 如果设置为0, 则所有容器同时回滚 delay # 每个组回滚之间的时间间隔(默认为0) failure_action # 定义回滚失败的策略 continue # 继续回滚 pause # 暂停回滚 monitor # 每次回滚任务后的持续时间以监视失败(单位: ns|us|ms|s|m|h) (默认为0) max_failure_ratio # 回滚期间容忍的失败率(默认值0) order # 回滚期间的操作顺序 stop-first # 旧任务在启动新任务之前停止(默认) start-first # 首先启动新任务, 并且正在运行的任务暂时重叠 注意： 支持 docker-compose up 和 docker-compose run 但不支持 docker stack deploy 的子选项 security_opt container_name devices tmpfs stop_signal links cgroup_parent network_mode external_links restart build userns_mode sysctls devices # 指定设备映射列表 (等同于 docker run --device 的作用) depends_on # 定义容器启动顺序 (此选项解决了容器之间的依赖关系， 此选项在 v3 版本中 使用 swarm 部署时将忽略该选项) 示例： docker-compose up 以依赖顺序启动服务，下面例子中 redis 和 db 服务在 web 启动前启动 默认情况下使用 docker-compose up web 这样的方式启动 web 服务时，也会启动 redis 和 db 两个服务，因为在配置文件中定义了依赖关系 version: '3' services: web: build: . depends_on: - db - redis redis: image: redis db: image: postgres dns # 设置 DNS 地址(等同于 docker run --dns 的作用) dns_search # 设置 DNS 搜索域(等同于 docker run --dns-search 的作用) tmpfs # v2 版本以上, 挂载目录到容器中, 作为容器的临时文件系统(等同于 docker run --tmpfs 的作用, 在使用 swarm 部署时将忽略该选项) entrypoint # 覆盖容器的默认 entrypoint 指令 (等同于 docker run --entrypoint 的作用) env_file # 从指定文件中读取变量设置为容器中的环境变量, 可以是单个值或者一个文件列表, 如果多个文件中的变量重名则后面的变量覆盖前面的变量, environment 的值覆盖 env_file 的值 文件格式： RACK_ENV=development environment # 设置环境变量， environment 的值可以覆盖 env_file 的值 (等同于 docker run --env 的作用) expose # 暴露端口, 但是不能和宿主机建立映射关系, 类似于 Dockerfile 的 EXPOSE 指令 external_links # 连接不在 docker-compose.yml 中定义的容器或者不在 compose 管理的容器(docker run 启动的容器, 在 v3 版本中使用 swarm 部署时将忽略该选项) extra_hosts # 添加 host 记录到容器中的 /etc/hosts 中 (等同于 docker run --add-host 的作用) healthcheck # v2.1 以上版本, 定义容器健康状态检查, 类似于 Dockerfile 的 HEALTHCHECK 指令 test # 检查容器检查状态的命令, 该选项必须是一个字符串或者列表, 第一项必须是 NONE, CMD 或 CMD-SHELL, 如果其是一个字符串则相当于 CMD-SHELL 加该字符串 NONE # 禁用容器的健康状态检测 CMD # test: ["CMD", "curl", "-f", "http://localhost"] CMD-SHELL # test: ["CMD-SHELL", "curl -f http://localhost || exit 1"] 或者 test: curl -f https://localhost || exit 1 interval: 1m30s # 每次检查之间的间隔时间 timeout: 10s # 运行命令的超时时间 retries: 3 # 重试次数 start_period: 40s # v3.4 以上新增的选项, 定义容器启动时间间隔 disable: true # true 或 false, 表示是否禁用健康状态检测和 test: NONE 相同 image # 指定 docker 镜像, 可以是远程仓库镜像、本地镜像 init # v3.7 中新增的参数, true 或 false 表示是否在容器中运行一个 init, 它接收信号并传递给进程 isolation # 隔离容器技术, 在 Linux 中仅支持 default 值 labels # 使用 Docker 标签将元数据添加到容器, 与 Dockerfile 中的 LABELS 类似 links # 链接到其它服务中的容器, 该选项是 docker 历史遗留的选项, 目前已被用户自定义网络名称空间取代, 最终有可能被废弃 (在使用 swarm 部署时将忽略该选项) logging # 设置容器日志服务 driver # 指定日志记录驱动程序, 默认 json-file (等同于 docker run --log-driver 的作用) options # 指定日志的相关参数 (等同于 docker run --log-opt 的作用) max-size # 设置单个日志文件的大小, 当到达这个值后会进行日志滚动操作 max-file # 日志文件保留的数量 network_mode # 指定网络模式 (等同于 docker run --net 的作用, 在使用 swarm 部署时将忽略该选项) networks # 将容器加入指定网络 (等同于 docker network connect 的作用), networks 可以位于 compose 文件顶级键和 services 键的二级键 aliases # 同一网络上的容器可以使用服务名称或别名连接到其中一个服务的容器 ipv4_address # IP V4 格式 ipv6_address # IP V6 格式 示例: version: '3.7' services: test: image: nginx:1.14-alpine container_name: mynginx command: ifconfig networks: app_net: # 调用下面 networks 定义的 app_net 网络 ipv4_address: 172.16.238.10 networks: app_net: driver: bridge ipam: driver: default config: - subnet: 172.16.238.0/24 pid: 'host' # 共享宿主机的 进程空间(PID) ports # 建立宿主机和容器之间的端口映射关系, ports 支持两种语法格式 SHORT 语法格式示例: - "3000" # 暴露容器的 3000 端口, 宿主机的端口由 docker 随机映射一个没有被占用的端口 - "3000-3005" # 暴露容器的 3000 到 3005 端口, 宿主机的端口由 docker 随机映射没有被占用的端口 - "8000:8000" # 容器的 8000 端口和宿主机的 8000 端口建立映射关系 - "9090-9091:8080-8081" - "127.0.0.1:8001:8001" # 指定映射宿主机的指定地址的 - "127.0.0.1:5000-5010:5000-5010" - "6060:6060/udp" # 指定协议 LONG 语法格式示例:(v3.2 新增的语法格式) ports: - target: 80 # 容器端口 published: 8080 # 宿主机端口 protocol: tcp # 协议类型 mode: host # host 在每个节点上发布主机端口, ingress 对于群模式端口进行负载均衡 secrets # 不知道怎么用 security_opt # 为每个容器覆盖默认的标签 (在使用 swarm 部署时将忽略该选项) stop_grace_period # 指定在发送了 SIGTERM 信号之后, 容器等待多少秒之后退出(默认 10s) stop_signal # 指定停止容器发送的信号 (默认为 SIGTERM 相当于 kill PID; SIGKILL 相当于 kill -9 PID; 在使用 swarm 部署时将忽略该选项) sysctls # 设置容器中的内核参数 (在使用 swarm 部署时将忽略该选项) ulimits # 设置容器的 limit userns_mode # 如果Docker守护程序配置了用户名称空间, 则禁用此服务的用户名称空间 (在使用 swarm 部署时将忽略该选项) volumes # 定义容器和宿主机的卷映射关系, 其和 networks 一样可以位于 services 键的二级键和 compose 顶级键, 如果需要跨服务间使用则在顶级键定义, 在 services 中引用 SHORT 语法格式示例: volumes: - /var/lib/mysql # 映射容器内的 /var/lib/mysql 到宿主机的一个随机目录中 - /opt/data:/var/lib/mysql # 映射容器内的 /var/lib/mysql 到宿主机的 /opt/data - ./cache:/tmp/cache # 映射容器内的 /var/lib/mysql 到宿主机 compose 文件所在的位置 - ~/configs:/etc/configs/:ro # 映射容器宿主机的目录到容器中去, 权限只读 - datavolume:/var/lib/mysql # datavolume 为 volumes 顶级键定义的目录, 在此处直接调用 LONG 语法格式示例:(v3.2 新增的语法格式) version: "3.2" services: web: image: nginx:alpine ports: - "80:80" volumes: - type: volume # mount 的类型, 必须是 bind、volume 或 tmpfs source: mydata # 宿主机目录 target: /data # 容器目录 volume: # 配置额外的选项, 其 key 必须和 type 的值相同 nocopy: true # volume 额外的选项, 在创建卷时禁用从容器复制数据 - type: bind # volume 模式只指定容器路径即可, 宿主机路径随机生成; bind 需要指定容器和数据机的映射路径 source: ./static target: /opt/app/static read_only: true # 设置文件系统为只读文件系统 volumes: mydata: # 定义在 volume, 可在所有服务中调用 restart # 定义容器重启策略(在使用 swarm 部署时将忽略该选项, 在 swarm 使用 restart_policy 代替 restart) no # 禁止自动重启容器(默认) always # 无论如何容器都会重启 on-failure # 当出现 on-failure 报错时, 容器重新启动 其他选项： domainname, hostname, ipc, mac_address, privileged, read_only, shm_size, stdin_open, tty, user, working_dir 上面这些选项都只接受单个值和 docker run 的对应参数类似 对于值为时间的可接受的值： 2.5s 10s 1m30s 2h32m 5h34m56s 时间单位: us, ms, s, m， h 对于值为大小的可接受的值： 2b 1024kb 2048k 300m 1gb 单位: b, k, m, g 或者 kb, mb, gb networks # 定义 networks 信息 driver # 指定网络模式, 大多数情况下, 它 bridge 于单个主机和 overlay Swarm 上 bridge # Docker 默认使用 bridge 连接单个主机上的网络 overlay # overlay 驱动程序创建一个跨多个节点命名的网络 host # 共享主机网络名称空间(等同于 docker run --net=host) none # 等同于 docker run --net=none driver_opts # v3.2以上版本, 传递给驱动程序的参数, 这些参数取决于驱动程序 attachable # driver 为 overlay 时使用, 如果设置为 true 则除了服务之外，独立容器也可以附加到该网络; 如果独立容器连接到该网络，则它可以与其他 Docker 守护进程连接到的该网络的服务和独立容器进行通信 ipam # 自定义 IPAM 配置. 这是一个具有多个属性的对象, 每个属性都是可选的 driver # IPAM 驱动程序, bridge 或者 default config # 配置项 subnet # CIDR格式的子网，表示该网络的网段 external # 外部网络, 如果设置为 true 则 docker-compose up 不会尝试创建它, 如果它不存在则引发错误 name # v3.5 以上版本, 为此网络设置名称

文件格式示例：
version: "3"
services:

 redis: image: redis:alpine ports: - "6379" networks: - frontend deploy: replicas: 2 update_config: parallelism: 2 delay: 10s restart_policy: condition: on-failure db: image: postgres:9.4 volumes: - db-data:/var/lib/postgresql/data networks: - backend deploy: placement: constraints: [node.role == manager]

任何相对完整的应用服务都不可能是由单一的程序来完成支持，计划使用 Docker 来部署的服务更是如此。大型服务需要进行拆分，形成微服务集群方能增强其稳定性和可维护性。本篇随笔将对 Docker Compose 和 Docker Swarm 的原理和配置做整理归纳，并分享其使用经验。
docker——compose插图

总结一下，这张图很形象：Docker 可以看做集装箱把杂乱的货物一个个整理归类， Compose 则是用于编排这些集装箱，最后 Swarm 就是多提供几条船，挂掉一两条还能继续走，提高稳定性。

1. YAML 简介

Docker Compose 的配置文件采用 YAML 格式，因此有必要在正文之前简要说明下。YAML 是一门专门用来写配置文件的语言，设计目标就是方便读写，其实质上是一种通用的数据串行化格式，基本语法规则如下：

大小写敏感。
# 表示注释。
使用缩进表示层级关系。
缩进时不允许使用 Tab 键，只允许使用空格。
缩进的空格数目不重要，只要相同层级的元素左侧对齐即可。

YAML 支持的数据结构有三种:

对象：animal:cat。
数组：一组中划线开头的行，例如:

# ex1 - cat - dog - bird # ex2 - - cat - dog - bird # ex3 animal: [cat, dog, bird]

值类型和字符串。

2. Docker Compose

2.1 安装与简介

Docker 可以极为方便地部署单个服务，但这时候我们需要一个工具来整合 Docker 的功能，使之能够更便捷地去管理整个微服务集群的部署和迁移，Docker Compose 正是应此而生。他是由 Python 编写的程序，能够根据指令结合配置文件转换成对应的 Docker API 的操作，并直接体现到 Docker Daemon 中，这就代替我们完成了重复输入复杂指令的过程，主要功能可分为以下两点:

Service：代表的是运行同种应用程序的一个或多个相同容器的抽象定义，也是我们在Docker Compose 中配置的主要对象。在每个 Docker Compose 的配置文件中，我们可以定义多个服务，并定义服务的配置，以及服务于服务之间的以来关系。
Project：代表的是由多个服务所组成的一个相对完整的业务单元。

安装命令:

curl -L https://github.com/docker/compose/releases/download/1.19.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose && chmod +x /usr/local/bin/docker-compose

2.2 配置参数

Docker Compose 的核心就是其配置文件，采用 YAML 格式，默认为 docker-compose.yml ，参数详解可查阅“官方文档”，以下只做一个常规摘要。

services

所有服务的根节点。

image

指定服务的镜像名，若本地不存在，则 Compose 会去仓库拉取这个镜像:

services: web: image: nginx

ports

端口映射，例：

ports: - "80:80" - "81:81"

volumes

挂载主机目录，其中 ro 表示只读，例：

volumes: - "/etc/nginx/www:/www" - "/var/run/docker.sock:/tmp/docker.sock:ro"

大多数情况下集群中部署的应该都是无状态服务，服务可复制且不固定在某一台宿主机，所以挂载的数据卷最好应当与宿主机脱离关系，例：

 web: services: image: nginx volumes: - type: volume source: logs target: /mnt volume: nocopy: true volumes: logs: driver_opts: type: nfs o: addr=***.cn-hangzhou.nas.aliyuncs.com,rw device: ":/"

当然，这种情况下最好是优先创建数据卷，后在配置文件中引用，例：

docker volume create --driver local \ --opt type=nfs \ --opt o=addr=***.cn-hangzhou.nas.aliyuncs.com,rw \ --opt device=:/ \ logs volumes: logs: external: true

若必须挂载集群中一台宿主机的目录作为数据卷，则要安装一个 docker 插件:

docker plugin install vieux/sshfs # 若配置了密钥对则可省略 password 参数 docker volume create \ -d vieux/sshfs \ --name sshvolume \ -o "sshcmd=user@1.2.3.4:/remote" \ -o "password=$(cat file_containing_password_for_remote_host)\ sshvolume

networks

配置服务间的网路互通与隔离，例：

services: web: image: nginx networks: - proxy - youclk networks: youclk: external: true proxy: external: true

secrets

配置服务密码访问，例：

services: redis: image: redis:latest deploy: replicas: 1 secrets: - my_secret - my_other_secret secrets: my_secret: file: "./my_secret.txt" my_other_secret: external: true docker secret create [OPTIONS] SECRET [file|-] echo "admin:password" | docker secret create my_secret - docker secret create my_secret ./secret.json

healthcheck

健康检查，这个非常有必要，等服务准备好以后再上线，避免更新过程中出现短暂的无法访问。

healthcheck: test: ["CMD", "curl", "-f", "http://localhost/alive"] interval: 5s timeout: 3s

其实大多数情况下健康检查的规则都会写在 Dockerfile 中:

FROM nginx RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/* HEALTHCHECK --interval=5s --timeout=3s CMD curl -f http://localhost/alive || exit 1

depends_on

依赖的服务，优先启动，例：

depends_on: - redis

environment & env_file

设置环境变量和指定环境变量的文件，例：

environment: - VIRTUAL_HOST=test.youclk.com env_file: - ./common.env

deploy

部署相关的配置都在这个节点下，例：

deploy: mode: replicated replicas: 2 restart_policy: condition: on-failure max_attempts: 3 update_config: delay: 5s order: start-first # 默认为 stop-first，推荐设置先启动新服务再终止旧的 resources: limits: cpus: "0.50" memory: 1g deploy: mode: global # 不推荐全局模式（仅个人意见）。 placement: constraints: [node.role == manager]

若非特殊服务，以上各节点的配置能够满足大部分部署场景了。

3. Swarm

Docker 默认包含了 Swarm，因此可以直接使用，初始化命令：

docker swarm init

此时将会默认当前节点为 Leader，以下命令为查看 token：docker swarm join-token （worker|manager），其他节点可以用 manager 或者 worker 的身份加入到当前集群，例：

docker swarm join --token SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-1awxwuwd3z9j1z3puu7rcgdbx 172.17.0.2:2377

执行 docker swarm leave 脱离集群。

以下各节点常规操作命令，比较简单，就不解释了:

docker node demote [NODE] docker node inspect [NODE] docker node ls docker node promote [NODE] docker node ps [NODE] docker node rm [NODE] docker node update [OPTIONS] NODE

4. 应用案例

集群最擅长的就是解决多服务问题，只要在同一 network 之下，服务之间默认可以直接通过 service_name 互通有无。但为了避免混乱，各服务与外部的通信最好统一交给一个反向代理服务转发。因对 nginx 比较熟悉，所以我最初选择的代理是“jwilder/nginx-proxy”：

复制代码

server { listen 80; server_name localhost; location /alive { return 200; } } server { listen 81; return 301 https://$host$request_uri; } FROM jwilder/nginx-proxy ADD ./src /etc/nginx/conf.d ADD https://gitee.com/youclk/entry/raw/master/debian/sources-vpc.list /etc/apt/sources.list RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/* HEALTHCHECK --interval=5s --timeout=3s CMD curl -f http://localhost/alive || exit 1 version: "3.5" services: proxy: image: $REGISTRY/proxy ports: - "80:80" - "81:81" volumes: - "/var/run/docker.sock:/tmp/docker.sock:ro" deploy: placement: constraints: [node.role == manager] restart_policy: condition: on-failure max_attempts: 3 update_config: delay: 5s order: start-first resources: limits: cpus: "0.50" memory: 1g

负载均衡使用的是阿里云的 SLB，监听 80 -> 81， 443 -> 80，这样一个服务就实现了节点检查、代理和 https 重定向为一身。拖 nginx 的福，反正用起来就是爽，点击“Nginx 原理解析和配置摘要”进一步了解。

正所谓乐极生悲，某一次我在扩展 Swarm 集群的时候提升了部分 work 节点为 manager，并且扩展了代理的数量，这让很多服务频繁出现 503，找来找去我发现问题出在 nginx-proxy 代理上。当服务在各节点分布不均的时候，非 leader 节点上的那个代理无法找到服务，废了老大的劲儿也没找到合理的解决方案。

最后我决定选择“Docker Flow Proxy”作为新的代理（好家伙，这一看文档吓我一跳，我还是第一次看到私人的开源项目能把参考文档写得这么详细，作者的细腻程度“令人发指”，小弟顶礼膜拜之），以下是我的案例：

version: "3.5" services: proxy: image: vfarcic/docker-flow-proxy ports: - "80:80" networks: - proxy environment: - LISTENER_ADDRESS=swarm-listener - MODE=swarm secrets: - dfp_users_admin deploy: replicas: 2 labels: - com.df.notify=true - com.df.port=8080 - com.df.serviceDomain=localhost - com.df.reqPathSearchReplace=/alive,/v1/docker-flow-proxy/ping swarm-listener: image: vfarcic/docker-flow-swarm-listener networks: - proxy volumes: - /var/run/docker.sock:/var/run/docker.sock environment: - DF_NOTIFY_CREATE_SERVICE_URL=http://proxy:8080/v1/docker-flow-proxy/reconfigure - DF_NOTIFY_REMOVE_SERVICE_URL=http://proxy:8080/v1/docker-flow-proxy/remove deploy: placement: constraints: [node.role == manager] networks: proxy: external: true secrets: dfp_users_admin: external: true

更换代理的过程也并非一帆风顺，我在 https 重定向这个问题浪费了好多时间，最后也没在代理中解决。作者当然是考虑到了这个问题，经典的解决方案应如下：

services: proxy: image: vfarcic/docker-flow-proxy ports: - "80:80" - "443:443" networks: - proxy environment: - LISTENER_ADDRESS=swarm-listener - MODE=swarm deploy: replicas: 2 labels: - com.df.notify=true - com.df.httpsOnly=true - com.df.httpsRedirectCode=301

但奈何哥哥“非经典”呀，我的 https 证书和负载均衡都委托给阿里云的 SLB 了，SLB 代理的后端请求只能限定 http。我的想法还是监听所有请求 443 端口的域名并返回 301，但以下方案并没有成功:

labels: - com.df.notify=true - com.df.httpsRedirectCode=301 - com.df.serviceDomainAlgo=hdr_dom（host） - com.df.srcPort.1=80 - com.df.port.1=8080 - com.df.serviceDomain.1=localhost - com.df.reqPathSearchReplace.1=/alive,/v1/docker-flow-proxy/ping - com.df.srcPort.2=443 - com.df.port.2=8080 - com.df.serviceDomain.2=youclk.com,localhost - com.df.httpsOnly.2=true

当然重定向可以在各服务内部实现，但我不认为这是个好的解决方案。最后的最后，我想反正迟早都要上 CND，于是就在 CND 中加了 https 重定向（哎，就是带宽的费用要 double 咯…）:
docker——compose插图2

除了代理，最好再加一个监控服务，我选择了官方案例中的 visualizer ，配合 proxy 示例：

services: visualizer: image: dockersamples/visualizer networks: - proxy volumes: - "/var/run/docker.sock:/var/run/docker.sock" deploy: placement: constraints: [node.role == manager] labels: - com.df.notify=true - com.df.serviceDomain=visualizer.youclk.com - com.df.port=8080 - com.df.usersSecret=admin

visualizer 算是敏感服务了，一般需要用密码保护，这里通过 com.df.usersSecret 指定了密码文件，密码已写入 secrets dfp_users_admin 中。注意，com.df.usersSecret 的值与 dfp_users_* 必须相同，示例已在上文。部署后显示如下：
docker——compose插图3

docker-flow-proxy 还有一个默认的监控服务，显示如下：
docker——compose插图4
不过数据没有统一收集，因此意义不大，看看就好。除此之外就是真正需要部署的应用了，只要服务器性能足够，随便想来几个来几个。

在之前使用Docker的过程中，一直是用 Docker run 命令单独启动container后再加入Overlay网络的方式实现部署工作的. 这种方式看似直接，但是随着服务所包含的container的个数越来越多（docker 命令）也就越来越多，由此带来许多重复工作。。。

在官网上看到了通过 docker-compose 可以执行container的编排，尤其是compose files — V3版本，加入的许多功能可以方便我们将服务中的contain部署在单独的docker host 或者多个 hosts (swarm 节点) 上，于是考虑到目前对于 docker 的使用情况，确实也到了进行高级特性的尝试阶段，于是乎，走起！

分享一个示例：https://hackernoon.com/deploy-docker-compose-v3-to-swarm-mode-cluster-4159e9cca712#.lyx2e8fd9

上面的说的是如何使用compose V3 + swarm 构建一个猫狗投票系统，官方的例子，描述的很详细，有兴趣的童鞋可以研究一下。。。我在这里部署的方式也是使用了类似的方法，区别之处在与：实例中运用了“docker stack deploy”命令在多个host上面部署，而我使用的是“docker-compose up” 分别在两个host上面启动与部署服务。

准备工作

首先是通过 Swarm 创建 nodes,并且创建Overlay网络模式. 我在这里就不在赘述，大家可以参看我之前的随笔或者利用万能的互联网找到答案。

我这里使用的Docker engine 和 Docker-compose 版本如下：

docker——compose插图5

Docker-compose

众所周知，compose 就是 docker提供给我们用来进行编排的利器，那么我们应该如何使用她呢？

在解析docker-compose.yml之前，我想先说明一下我的业务，在熟悉业务之后，我们再来看看具体的"code".

业务需求：我们要在两个host (swarm node)上面分别建立一组服务，为了简单起见，我将nodes命名为nodeDB和nodeService；顾名思义，我们就是要在nodeDB上面建立database的服务（我这里是部署oracle server），在nodeService上面部署我们的程序(containers). 而 containers 之间的通信就是通过Swarm的Overlay网络来完成的。

NodeDB的docker-compose.yml

version: '3' services: frs_orasvr: build: context: ./frsDB dockerfile: Dockerfile image: frs_orasvr_img:v1 container_name: frs_orasvr hostname: frs_orasvr ports: - "1521:1521" volumes: - /DATA/compose_frs/frsDB/cafisFRSDB/:/frs networks: - qrtSwamComposeNet networks: qrtSwamComposeNet: driver: overlay

这里请注意几个内容：

1. networks: 在 compose file V3中, 允许我们通过networks关键字定义一个基于 Docker0 网络的 subnet。然后将我们的服务添加到这个subnet中。这样做的好处实现了服务之间的隔离，一旦我们不需要这组服务了，我们可以通过命令“docker-compose down” 卸载服务和对应的subnet,他不会对其他的服务造成影响。

2. build: 我们可以通过build命令来指定加载那个Dockerfile。 Dockerfile 提供给我们一种方式将通用的dockr image 定制化成为自己的image，这些定制化的步骤就可以以Dockerfile的方式记录下来。例如，我之前从docker 仓库里pull 下来一个image, 我们叫他baseImage，之后在此基础上进行了我的定制化生成myImage，如果需要在其他机器上面使用myImage,之前的做法吧myImage提交到私有仓库，在需要的时候pull下来，但是如果不同的地方需要不同的myImage (v1,v2,v3…),就有可能造成Image泛滥。现在我们通过Dockerfile的方式记录自己的定制过程，就会方便许多。

OK，啰嗦了一大堆。。。现在我们再来看看我们的Dockerfile长得如何：

FROM 172.100.1.15:5000/oracle11g_server_v3 RUN mkdir /frs/ COPY /cafisFRSDB/ /frs/ COPY /cafisFRSDB/listener.ora /app/oracle/11.2.0/network/admin/ CMD ["/bin/bash", "/frs/startup.sh"]

Dockerfile的内容很简单，就是copy文件；

CMD — 就是我们需要在启动container的时候执行的shell脚本，通过她启动oracle服务和实例（业务逻辑需求）。

现在我们cd到docker-compose.yml文件所在的目录，输入命令 “docker-compose up”，命令执行完成后我们可以看到

1. 建立网络 composefrs_qrtSwarmComposeNet

docker——compose插图6

2. 通过 Dockerfile 生成 imge

docker——compose插图7

3. compose运行image，生成container并且调用shell脚本

docker——compose插图8

到此，我们在nodeDB上面的工作就完成了。。。

NodeService的docker-compose.yml

我们要在这个host (swarm node) 部署服务，服务中的container需要与之前node上面oracle服务通信。。。

直接上code (简单起见，只列出了services 中的一个 container)

version: '3' services: frs_ftsoft: build: context: ./ftsoft dockerfile: Dockerfile image: frs_ftsoft_img:v1 networks: - composefrs_qrtSwamComposeNet container_name: frs_ftsoft hostname: frs_ftsoft mac_address: xx:xx:xx:xx:xx:xx volumes: - /data/CabisSvr/DockerFrs/ftsoft:/frs networks: composefrs_qrtSwamComposeNet: external: true

Compose文件中使用的 Dockerfile 的内容和之前差不多，就不在这里多说了。

注意：

1. 由于之前我们在nodeDB的compose file 里面已经创建过了网络，这里需要指定为external：true （不需要在创建了），在container里面加入即可。

2. 我们直接运行"docker-compose up"会报错，内容大致为找不到指定的网络。。。这是由于我们之前在nodeDB上面创建的network不会自动再新的node上面显示（官方说法），所以我们需要先在 nodeService 上面运行一个container让其加入网络 “composefrs_qrtSwamComposeNet“

例如 “docker run -itd –name=mybusybox –network=composefrs_qrtSwamComposeNet busybox /bin/sh”

之后我们便可以在nodeService上面能够查看到 composefrs_qrtSwamComposeNet 网络，此时再运行“docker-compose up”就OK了。这点还是有点坑的

结论

OK，通过在nodeDB和nodeService上运行两次 " docker-compose up ",命令，我们实现了在不同的hosts节点上运行containers，最终将他们以service的方式展现给外部用户。

PS，我还尝试过用docker stack deploy的方式进行部署，使用它最大的好处就是可以再一台机器上完成部署（传说中的一键部署），但是由于其中的种种限制(例如必须保证需要部署的service中使用的image必须提前存在于指定机器或者私有仓库，且不能使用Dockerfile临时编译; 不能指定conainer的IP，Mac 等等。。。),最终未能如愿，希望在 docker 之后的版本里能够改善吧。

本文只是一种实际部署方案的例子，涉及到的技术有（除Docker/Docker Swarm外）：

Docker overlay network

Fluentd

Prometheus stack

vegasbrianc的Prometheus监控方案

步骤大纲：

部署Docker machine

基本配置

配置网络

启动Fluentd日志服务

部署Docker swarm集群

配置网络

添加Node

部署Prometheus stack

给Node打Label

创建监控网络

启动service

部署应用

识别stateless与stateful

创建应用网络

给Node打Label

启动service

1 部署Docker machine 1.1 基本配置

准备若干Linux服务器（本例使用Ubuntu 16.04），参照Docker CE 镜像源站提到的步骤安装Docker CE。

参照Docker Daemon生产环境配置。

1.2 配置bridge网络

参照Docker Daemon生产环境配置中的mtu和子网章节。

1.3 启动Fluentd日志服务

参考使用Fluentd收集Docker容器日志。

2 部署Docker swarm集群

到一台机器上执行docker swarm init，这个机器将作为manager node。

执行docker node ls会看到类似下面的结果：

$ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS dxn1zf6l61qsb1josjja83ngz * manager1 Ready Active Leader

如果你计划不会把工作负载跑在manager node上，那么使用docker drain：

docker node update --availability drain <node-id>

可参考Docker Swarm基本命令清单。

2.1 配置网络MTU和子网

参考Docker Overlay网络的MTU。

特别注意

观察docker_gwbridge和ingress的子网是否与已有网络冲突：

$ docker network inspect -f '{{json .IPAM}}' docker_gwbridge {"Driver":"default","Options":null,"Config":[{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]} $ docker network inspect -f '{{json .IPAM}}' ingress {"Driver":"default","Options":null,"Config":[{"Subnet":"10.255.0.0/16","Gateway":"10.255.0.1"}]}

如果有冲突则参考Docker Overlay网络的MTU中的方法修改子网。

2.2 添加Node

参考Docker Swarm基本命令清单。

3 部署Prometheus stack

使用的是vegasbrianc的Prometheus监控方案。

整个监控方案包含一下几个组件：

Prometheus

Node-exporter，运行在每个node上

Alertmanager

cAdvisor，运行在每个node上

Grafana

3.1 给Node打Label

挑选一台Node作为运行监控服务的机器。给这个node打上label：

$ docker node update --label-add for-monitor-stack=1 <node-id>

3.2 创建监控网络

$ docker network create -d overlay --attachable monitor-net

参考参考Docker Overlay网络的MTU检查子网与MTU是否配置正确。

3.3 启动service

clone vegasbrianc的Prometheus监控方案项目代码。

使用我修改过的docker-stack.yml

启动service：

$ docker stack deploy \ --with-registry-auth \ --prune \ -c docker-stack.yml \ p8s-monitor-stack

访问地址：

Prometheus：http://<任意swarm node ip>:9000

Node-exporter：http://<任意swarm node ip>:9010

Alertmanager：http://<任意swarm node ip>:9020

cAdvisor：http://<任意swarm node ip>:9030

Grafana：http://<任意swarm node ip>:9040，用户名admin，密码foobar

4 部署应用 4.1 识别stateless与stateful

如果你的应用由多个组件（service）组成，那么在部署它们之前你得识别出哪些是stateless service哪些是stateful service。

针对每个service你自问以下三个问题：

这个service崩溃之后，是不是只需要重启它就可以了，而不需要关心数据恢复？

这个service是否可以在node之间任意迁移，且不需要分布式存储？

这个service是否无需固定IP？

如果上述回答都是Yes，那么这个service就是stateless的，只要有一个是No，则这个service是stateful的。

对于stateless service，你可以：

用docker stack deploy部署

用docker service create部署

对于stateful service，你可以：

用docker run部署

用docker-compose up部署

如果没有固定IP的要求，那么你也可以用docker stack deploy/docker service create部署，前提是你得保证这个service只会固定在一台机器上运行。

有时候你的应用既有stateless service又有stateful service，这时需要把他们挂载到同一个overlay网络里，这样它们之间就能够互相通信了。

4.2 创建应用网络

创建app-net（你也可以改成自己的名字）

$ docker network create -d overlay --attachable app-net

参考Docker Overlay网络的MTU检查子网与MTU是否配置正确。

4.3 给Node打Label

如果你对于Service部署在哪个Node上有要求，那么你得给Node打上Label：

$ docker node update --label-add <your-label>=1 <node-id>

然后在docker-compose.yaml里添加约束条件：

version: "3.7" services: busybox: image: busybox deploy: placement: constraints: - node.labels.<your-label> == 1

4.4 启动service

对于stateless service，编写docker-compose.yaml，里面写了同时挂载app-net和monitor-net，比如：

version: "3.7" services: busybox: image: busybox networks: app-net: monitor-net: aliases: - busybox ... networks: app-net: external: true monitor-net: external: true

注意上面设置了busybox service在monitor-net中的别名，这是因为如果你用docker stack deploy部署，那么busybox的名字默认是<stack-name>_busybox，这样对于prometheus而言此名字不稳定，不便于配置详见Prometehus监控Docker Swarm Overlay网络中的容器。

然后用docker stack deploy部署：

$ docker stack deploy --with-registry-auth --prune -c docker-compose.yaml <stack-name>

如果用docker service create则：

$ docker service create \ --network app-net \ --network monitor-net \ --name <name> \ ... 其他参数 <image>

下面举例docker run启动stateful service的方法：

$ docker run -d \ --name <name> \ --network app-net \ ... 其他参数 \ <image> # 然后再挂载到monitor-net上 $ docker network connect monitor-net <name>

原文链接：https://blog.csdn.net/weixin_38278993/article/details/101350681?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522168605913416800225522928%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=168605913416800225522928&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-14-101350681-null-null.268%5Ev1%5Ekoosearch&utm_term=%E7%BE%A4%E6%99%96nas%E5%AD%98%E5%82%A8%E3%80%81%E7%BE%A4%E6%99%96923%E3%80%81%E7%BE%A4%E6%99%96ipv6%E5%A4%96%E7%BD%91%E8%AE%BF%E9%97%AE%E3%80%81%E7%BE%A4%E6%99%96docker%E5%BF%85%E8%A3%85%E8%BD%AF%E4%BB%B6%E3%80%81%E7%BE%A4%E6%99%96%E7%9B%B4%E6%92%AD%E3%80%81%E7%BE%A4%E6%99%96+cpu%E3%80%81%E7%BE%A4%E6%99%96%E6%96%87%E4%BB%B6%E7%AE%A1%E7%90%86app%E3%80%81%E7%BE%A4%E6%99%96%E4%BD%BF%E7%94%A8%E8%AF%A6%E7%BB%86%E6%95%99%E7%A8%8B%E3%80%81%E7%BE%A4%E6%99%96quickconnect%E3%80%81%E7%BE%A4%E6%99%96%E7%B3%BB%E7%BB%9F%E4%B8%8B%E8%BD%BD%E3%80%81%E7%BE%A4%E6%99%96%E6%9C%8D%E5%8A%A1%E5%99%A8%E3%80%81%E7%BE%A4%E6%99%96nas%E4%BD%BF%E7%94%A8%E6%95%99%E7%A8%8B

声明📢本站内容均来自互联网，归原创作者所有，如有侵权必删除。本站文章皆由CC-4.0协议发布，如无来源则为原创，转载请注明出处。

THE END

教程转载