Docker-compose-1
本章要点:dockek-compose基础用法,compose基础说明,无案例
Docker-Compose项目是Docker官方的开源项目,负责实现对Docker容器集群的快速编排。本文编写来源参考: docker菜鸟入门,Docker Compose 容器编排技术使用详解,compose安装使用、入门进阶案例,隐藏敏感配置项(secrets方式)
Docker-compose理论
Docker-compose特点
-
简化多容器应用程序的管理
-
- Docker Compose 允许您将多个容器组合成一个应用程序,并通过一个配置文件来定义和管理它们。这使得启动、停止、重建和管理整个应用程序变得简单。
-
声明式配置
-
- 使用 YAML 文件来定义应用程序的配置,使得配置文件易于阅读、理解和维护。您可以定义服务的各种属性,如镜像、环境变量、端口映射、卷挂载等。
-
快速启动和停止
-
- 通过简单的命令,如
docker-compose up
和docker-compose down
,您可以快速启动和停止整个应用程序。这使得本地开发和测试变得方便和高效。
- 通过简单的命令,如
-
自动化容器之间的网络连接
-
- Docker Compose 自动为应用程序中的服务创建一个默认网络,并将每个容器连接到该网络。这使得容器之间的通信变得简单,可以通过服务名称来进行访问,而无需处理 IP 地址和端口号。
-
数据卷管理
-
- Docker Compose 允许您定义卷挂载,将容器内的数据持久化到宿主机上。这简化了数据的管理和迁移,并可以确保数据的持久性。
-
可扩展性和复用性
-
- Docker Compose 允许您轻松地扩展和重用配置文件。您可以定义多个环境(如开发、测试、生产等)的配置,并根据需要进行组合和使用。
Docker-compose使用场景
如果日常开发中遇到下面的场景,可以考虑使用Docker Compose
-
搭建本地开发环境
-
- Docker Compose 可以帮助开发人员在本地快速搭建和管理多容器的开发环境。通过定义每个服务的镜像、环境变量、端口映射等属性,开发人员可以轻松地启动和停止整个应用程序,并在不同的服务之间进行通信。
-
部署测试环境
-
- Docker Compose 可以用于在测试环境中运行和管理多容器的应用程序。通过创建一个与生产环境相似的容器组合,测试人员可以在一个独立的环境中进行端到端的测试,并且可以轻松地重建和销毁整个测试环境。
-
持续集成和持续部署
-
- Docker Compose 可以与持续集成和持续部署工具集成,如 Jenkins、GitLab CI、Travis 等。通过在配置文件中定义构建步骤和部署策略,可以将整个应用程序以容器化的方式自动构建、测试和部署到生产环境中。
-
多环境部署
-
- Docker Compose 允许你定义多个环境(如开发、测试、生产)的配置文件,并根据需要进行组合和使用,这使得在不同环境中轻松部署应用程序变得简单和可靠。
-
微服务架构
-
- Docker Compose 适用于构建和管理微服务架构。通过将每个微服务定义为一个独立的服务,并使用容器进行隔离,可以实现微服务之间的松耦合和独立部署。
Docker-compose安装
-
-
方式一
bash下载链接: https://github.com/docker/compose/releases ~]# wget https://github.com/docker/compose/releases/download/v2.40.0/docker-compose-linux-x86_64 ~]# mv docker-compose-Linux-x86_64 /usr/local/bin/ ~]# chmod +x /usr/local/bin/docker-compose-Linux-x86_64 ~]# mv /usr/local/bin/docker-compose-Linux-x86_64 /usr/local/bin/docker-compose ~]# docker-compose --version Docker Compose version v2.40.0 ~]# docker --version Docker version 26.1.4, build 5650f9b
-
方式二
bash~]# yum install python3 ~]# yum -y install python3-pip ~]# pip3 install --upgrade pip ~]# pip3 install docker-compose ~]# docker-compose --version
-
Docker Compose 配置文件属性
Docker Compose 使用 YAML 文件来定义服务。官方推荐的默认文件名为 compose.yml ,但同时也支持 docker-compose.yml,compose 文件中包含 6 个顶级属性 :version、services、networks、volumes、configs 与secrets,主要就是围绕这几个属性一直加参数,在下面的内容中将会结合实际的案例一一说明。首先在服务器目录下创建一个docker-compose.yml文件,后面的内容都编写在该文件中。
version
version 是一个顶级属性,但已经过时, 不再需要在 compose 文件中出现了。
serivces
services 是一个顶级属性,也是整个Docker Compose配置文件中作为服务定义最重要的属性,它用于定义一个应用中所包含的服务。Docker Compose 会将每个服务部署在各自的容器中。其下包含的第一级的属性即为服务名称,这个名称可以根据服务内容随意命名。而在服务名称下还可包含很多的属性,常用属性如下:
build
-
用于指定当前 Dockerfile 的路径,以 [./]就是当前
bash# 当前目录 Docker-compose.yml, Dockerfile version: '3' services: web: # <-- 该 web 服务使用从 Dockerfile 当前目录中构建的镜像 build: .
-
如果 Dockerfile 文件名不是默认名称,则需要通过 build 下的 context 属性指定路径,dockerfile 属性指定文件名
bash当前目录 Docker-compose.yml, abcDockerfile services: webapp: # <-- 该 webapp 服务使用从 Dockerfile 当前目录中构建的镜像 build: context: ./ dockerfile: abcDockerfile
image
指定当前服务所需要使用的镜像,如本地没有这个镜像,则会从dockerhub中自动pull
-
使用格式
bashimage: redis image: ubuntu:14.04 image: tutum/influxdb image: example-registry.com:4000/postgresql image: a4bc65fd # 镜像id
-
示例
bashversion: "3.7" services: redis: image: redis <-- 镜像名称,如果不指定: 就是 latest
container_name
指定自定义容器名称,如果不指定则自动生成
-
示例
bash# 如这段配置,容器名就是 tomcat8.5.100 services: tomcat: # 服务名称 image: tomcat:8.5.100-jre8 # redis镜像版本 container_name: tomcat8.5.100 # 容器名称
ports
主机映射端口:容器端口
-
语法
bashports: - 10240:8080 # 绑定容器的 8080 端口到主机的 10240 端口 - 8080:8080 # 绑定容器的 8000 端口到主机的 8080 端口 - 443 # 绑定容器的 443 端口到主机的任意端口,容器启动时随机分配绑定的主机端口号
-
示例
bashservices: tomcat: # 服务名称 image: tomcat:8.5.100-jre8 # redis镜像版本 container_name: tomcat8.5.100 # 容器名称 ports: - 8081:8080 # 绑定容器的 8080 端口到主机的 8081 端口
command
用于覆盖 Dockerfile 中的 CMD 指令命令,如果Dockerfile中已经有CMD指定,那就不需要在配置了。
-
示例
bash# 假设Dockfile中存在:CMD ["/data/nginx/sbin/nginx","-g","daemon off;"] services: nginx: # 服务名称 image: nginx:1.28.0 # nginx镜像版本 container_name: n1 # 容器名称 ports: - 8080:8080 # 绑定容器的 8080 端口到主机的 8081 端口 command: ["/data/nginx/sbin/nginx","-g","daemon off;"] # 如果指定了command则覆盖dockerfile的CMD,不指定则用Dockerfile的CMD
restart
-
no:是默认的重启策略,在任何情况下都不会重启容器。
-
always:容器总是重新启动。
-
on-failure:在容器非正常退出时(退出状态非0),才会重启容器。
-
unless-stopped:在容器退出时总是重启容器,但是不考虑在Docker守护进程启动时就已经停止了的容器
restart: "no"
restart: always
restart: on-failure
restart: unless-stopped
注:swarm 集群模式,请改用 restart_policy。
depends_on
depends_on 是一个用于定义服务之间依赖关系的关键字。它允许您指定一个或多个服务依赖于其他服务,以确保在启动或重新创建容器时,所依赖的服务先于依赖它们的服务启动。如下,web容器启动时,需要依赖db和redis两个容器的启动之后才会启动
-
示例
bashservices: tomcat: # 服务名称 image: tomcat:8.5.100-jre8 # redis镜像版本 container_name: tomcat8.5.100 # 容器名称 ports: - 8081:8080 # 绑定容器的 8080 端口到主机的 8081 端口 depends_on: # <-- 依赖于db跟redis - db - redis
-
补充说明
- 启动顺序
- 通过在服务的配置中使用 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"] 选项。
- 无法保证健康状态
deploy-集群选项
指定与服务的部署和运行有关的配置。 docker-compose deploy
命令的作用是将一个由docker-compose.yml
定义的服务栈部署到Swarm集群。这个命令会创建所需的服务和网络,并在集群中启动它们。它还会管理服务的更新和扩展
deploy属性下有一个常用属性 replicas,用于指定该服务启动的容器的数量。即实现一个服务多个容器。一旦指定了 deploy:replicas,就不能再指定container_name 属性了。因为各个启动的容器名称不能相同,而只能由系统自动生成。
-
如下示例:
bash# 这里有点像k8s? version: "3.7" services: redis: image: redis:alpine deploy: mode:replicated replicas: 6 endpoint_mode: dnsrr labels: description: "This redis service label" resources: limits: cpus: '0.50' memory: 50M reservations: cpus: '0.25' memory: 20M restart_policy: condition: on-failure delay: 5s max_attempts: 3 window: 120s
-
可以选参数:
-
endpoint_mode:访问集群服务的方式。
- vip: Docker 集群服务一个对外的虚拟 ip。所有的请求都会通过这个虚拟 ip 到达集群服务内部的机器
- **dnsrr:**DNS 轮询(DNSRR)。所有的请求会自动轮询获取到集群 ip 列表中的一个 ip 地址。
-
labels:在服务上设置标签。可以用容器上的 labels(跟 deploy 同级的配置) 覆盖 deploy 下的 labels。
-
mode:指定服务提供的模式。
-
- replicated:复制服务,复制指定服务到集群的机器上。
- global:全局服务,服务将部署至集群的每个节点。
-
restart_policy:配置如何在退出容器时重新启动容器。
- condition:可选 none,on-failure 或者 any(默认值:any)。
- delay:设置多久之后重启(默认值:0)。
- max_attempts:尝试重新启动容器的次数,超出次数,则不再尝试(默认值:一直重试)。
- window:设置容器重启超时时间(默认值:0)。
-
rollback_config:配置在更新失败的情况下应如何回滚服务。
- parallelism:一次要回滚的容器数。如果设置为0,则所有容器将同时回滚。
- delay:每个容器组回滚之间等待的时间(默认为0s)。
- failure_action:如果回滚失败,该怎么办。其中一个 continue 或者 pause(默认pause)。
- monitor:每个容器更新后,持续观察是否失败了的时间 (ns|us|ms|s|m|h)(默认为0s)。
- max_failure_ratio:在回滚期间可以容忍的故障率(默认为0)。
- order:回滚期间的操作顺序。其中一个 stop-first(串行回滚),或者 start-first(并行回滚)(默认 stop-first )。
-
update_config:配置应如何更新服务,对于配置滚动更新很有用。
- parallelism:一次更新的容器数。
- delay:在更新一组容器之间等待的时间。
- failure_action:如果更新失败,该怎么办。其中一个 continue,rollback 或者pause (默认:pause)。
- monitor:每个容器更新后,持续观察是否失败了的时间 (ns|us|ms|s|m|h)(默认为0s)。
- max_failure_ratio:在更新过程中可以容忍的故障率。
- order:回滚期间的操作顺序。其中一个 stop-first(串行回滚),或者 start-first(并行回滚)(默认stop-first)。
-
networks (service|顶层属性)
用于指定当前服务容器要连接到的网络。该网络必须是已经存在的 ,通常会提前创建好,或通过顶级属性networks 创建的网络。
-
networks主要有下面的几种
-
default
默认情况下docker-compose会建立一个默认的网络,名称为docker-compose.yml所在目录名称小写形式加上"_default",我们的TFLinux环境就是"tflinux_default"。
bash# 这个默认网络会对所有services下面的服务生效,所以services下面的各个服务之间才能够通过service名称互相访问。如果要自定义默认网络可以针对"default"网络进行设置,这样就会影响到默认网络了。 networks: default: driver: bridge
-
自定义
bash# 除了默认网络之外,我们也可以建立自定义的网络,这个网络名称就比较随意了 networks: persist: driver: bridge
-
已存在的网络
bash# 通过 docker network create 创建的网络,这里需要用到 external 关键字, 这里就可以配置跨主机桥用。 networks: persist: external: name: bridge2
-
-
菜鸟网示例
bashservices: some-service: networks: some-network: aliases: - alias1 other-network: aliases: - alias2 networks: some-network: # Use a custom driver driver: custom-driver-1 other-network: # Use a custom driver which takes special options driver: custom-driver-2
-
aliases :同一网络上的其他容器可以使用服务名称或此别名来连接到对应容器的服务。
volumes(service|顶层属性)
将主机的数据卷或者文件挂载到容器里,用于多个容器之间共享数据。这些卷可以用于持久性数据存储,例如数据库文件、配置文件等。通过使用 docker-compose volume
,您可以轻松地管理这些数据卷,并确保它们在容器之间共享和持久化。volume 通常可以使用路径与卷标两种方式。
-
示例-路径
bashdb: image: mariadb:latest ports: - "3306:3306" volumes: - /etc/mysql:/var/lib/mysql
-
示例-卷标
通过创建卷标
docker volume create name
挂载点:/var/lib/docker/volume/CreateName/_data
bashservices: backend: image: awesome/database volumes: - db-data:/etc/data backup: image: backup-service volumes: - db-data:/var/lib/backup/data volumes: db-data:
secrets
官网参数secrets, 没实际测试当前仅在刷理论,后续在测试
Secrets是Docker提供的一种安全机制,用于存储和管理敏感数据,如密码、API密钥等,通过使用Secrets,我们可以将这些数据与应用程序代码分离,从而提高安全性和可维护性。根据官网介绍Secret是1.25之后引入的,它运行在swarm上的命令。使用Secrets需要执行Swarm初始化操作
docker swarm init
。
-
基于环境变量
-
创建secret:
bashecho "pgpwd" | docker secret create PGSQL_PWD -
-
查看secret
bashdocker secret ls
-
编辑docker-compose.yml
bashversion: '3.1' services: postgres-dev: image: pgrouting/pgrouting:12-3.1-3.1.3 container_name: postgres-dev restart: always environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: ${PGSQL_PWD} ports: - 5432:5432 volumes: - /etc/localtime:/etc/localtime:ro #将外边时间直接挂载到容器内部,权限只读 - ./data:/var/lib/postgresql/data secrets: - PGSQL_PWD
-
-
基于文件
-
示例1
-
创建密码文件
bash# 在 docker-compose.yml 同级目录下, echo "thispassword" > password.txt # 定义密码 chmod 600 password.txt # 仅当前用户可读写
-
编辑docker-compose.yml
bashversion: '3.8' services: app: image: nginx secrets: - source: db_password # 引用上述密钥名称 target: /run/secrets/db_pass # 容器内挂载路径,默认权限 0400 secrets: db_password: # 密钥名称,需唯一 file: ./password.txt # 本地文件路径,相对 Compose 文件位置
-
-
示例2
bashecho "thispassword" >> my_secret.txt vim docker-compose.yml version: "3.1" services: mysql: image: mysql environment: MYSQL_ROOT_PASSWORD_FILE: /run/secrets/my_secret secrets: - my_secret secrets: my_secret: file: ./my_secret.txt # 权限需设置为600
-