如果您想了解Docker系列教程19-DockerCompose简介的相关知识,那么本文是一篇不可错过的文章,我们将对docker—compose进行全面详尽的解释,并且为您提供关于Docker17.
如果您想了解Docker系列教程19-Docker Compose简介的相关知识,那么本文是一篇不可错过的文章,我们将对docker—compose进行全面详尽的解释,并且为您提供关于Docker 17.03系列教程(一)Docker EE/Docker CE简介与版本规划、Docker Compose 和 Docker Swarm 和 Docker Service、Docker Compose比Docker Swarm和Docker Stack有什么好处?、Docker 从入门到进阶七:DockerFile 与 Docker Compose的有价值的信息。
本文目录一览:- Docker系列教程19-Docker Compose简介(docker—compose)
- Docker 17.03系列教程(一)Docker EE/Docker CE简介与版本规划
- Docker Compose 和 Docker Swarm 和 Docker Service
- Docker Compose比Docker Swarm和Docker Stack有什么好处?
- Docker 从入门到进阶七:DockerFile 与 Docker Compose
Docker系列教程19-Docker Compose简介(docker—compose)
原文:http://www.itmuch.com/docker/19-docker-compose-summary/ ,转载请说明出处。
经过前文讲解,我们可使用Dockerfile(或Maven)构建镜像,然后使用docker命令操作容器,例如docker run、docker kill等。
然而,使用分布式应用一般包含若干个服务,每个服务一般都会部署多个实例。如果每个服务都要手动启停,那么效率之低、维护量之大可想而知。
本章我们来讨论如何使用Docker Compose来轻松、高效地管理容器。为了简单起见,本章将Docker Compose简称为Compose。
Compose是一个用于定义和运行多容器Docker应用程序的工具,前身是Fig。它非常适合用在开发、测试、构建CI工作流等场景。本书所使用的Compose版本是1.10.0。
TIPS
Compose的GitHub:https://github.com/docker/compose
Docker 17.03系列教程(一)Docker EE/Docker CE简介与版本规划
近日,Docker发布了Docker 17.03。进入Docker 17时代后,Docker分成了两个版本:Docker EE和Docker CE,即:企业版(EE)和社区版(CE)。那么这两个版本有什么区别呢?不仅如此,Docker进入17.03后,版本命名方式跟之前完全不同,以后Docker又会有怎样的版本迭代计划呢?本文将为您一一解答。
版本区别
Docker EE
Docker EE由公司支持,可在经过认证的操作系统和云提供商中使用,并可运行来自Docker Store的、经过认证的容器和插件。
Docker EE提供三个服务层次:
服务层级 | 功能 |
---|---|
Basic | 包含用于认证基础设施的Docker平台 Docker公司的支持 经过认证的、来自Docker Store的容器与插件 |
Standard | 添加高级镜像与容器管理 LDAP/AD用户集成 基于角色的访问控制(Docker Datacenter) |
Advanced | 添加Docker安全扫描 连续漏洞监控 |
大家可在该页查看各个服务层次的价目:https://www.docker.com/pricing 。
Docker CE
Docker CE是免费的Docker产品的新名称,Docker CE包含了完整的Docker平台,非常适合开发人员和运维团队构建容器APP。事实上,Docker CE 17.03,可理解为Docker 1.13.1的Bug修复版本。因此,从Docker 1.13升级到Docker CE 17.03风险相对是较小的。
大家可前往Docker的RELEASE log查看详情https://github.com/docker/docker/releases 。
Docker公司认为,Docker CE和EE版本的推出为Docker的生命周期、可维护性以及可升级性带来了巨大的改进。
版本迭代计划
Docker从17.03开始,转向基于时间的YY.MM
形式的版本控制方案,类似于Canonical为Ubuntu所使用的版本控制方案。
Docker CE有两种版本:
edge版本每月发布一次,主要面向那些喜欢尝试新功能的用户。
stable版本每季度发布一次,适用于希望更加容易维护的用户(稳定版)。
edge版本只能在当前月份获得安全和错误修复。而stable版本在初始发布后四个月内接收关键错误修复和安全问题的修补程序。这样,Docker CE用户就有一个月的窗口期来切换版本到更新的版本。举个例子,Docker CE 17.03会维护到17年07月;而Docker CE 17.03的下个稳定版本是CE 17.06,这样,6-7月这个时间窗口,用户就可以用来切换版本了。
Docker EE和stable版本的版本号保持一致,每个Docker EE版本都享受为期一年的支持与维护期,在此期间接受安全与关键修正。
总结
- Docker从17.03开始分为企业版与社区版,社区版并非阉割版,而是改了个名称;企业版则提供了一些收费的高级特性。
- EE版本维护期1年;CE的stable版本三个月发布一次,维护期四个月;另外CE还有edge版,一个月发布一次。
参考文档
- https://blog.docker.com/2017/03/docker-enterprise-edition/
版权说明
本文采用 CC BY 3.0 CN协议 进行许可。 可自由转载、引用,但需署名作者且注明文章出处。如转载至微信公众号,请在文末添加作者公众号二维码。
关注我
关注我
博客:http://www.itmuch.com
微信公众号:
Docker Compose 和 Docker Swarm 和 Docker Service
Docker Compose
介绍
通过yml文件配置,高效管理多个docker,启停
中文文档
https://www.jb51.cc/manual/view/36129.html
安装
# 慢
$ sudo curl -L "https://github.com/docker/compose/releases/download/1.27.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
# 国内镜像
$ sudo curl -L https://get.daocloud.io/docker/compose/releases/download/1.24.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
授权文件
$ sudo chmod +x /usr/local/bin/docker-compose
测试
$ docker-compose --version
docker-compose version 1.27.4, build 1110ad01
卸载
sudo rm /usr/local/bin/docker-compose
测试使用(官方给的)
1创建文件夹
$ mkdir composetest
$ cd composetest
2写测试程序Python。app.py
import time
import redis
from flask import Flask
app = Flask(__name__)
cache = redis.Redis(host='redis', port=6379)
def get_hit_count():
retries = 5
while True:
try:
return cache.incr('hits')
except redis.exceptions.ConnectionError as exc:
if retries == 0:
raise exc
retries -= 1
time.sleep(0.5)
@app.route('/')
def hello():
count = get_hit_count()
return 'Hello World! I have been seen {} times.\n'.format(count)
3创建py文件依赖文件requirements.txt
flask
redis
4创建Dockerfile文件
FROM python:3.7-alpine
workdir /code
ENV FLASK_APP=app.py
ENV FLASK_RUN_HOST=0.0.0.0
RUN apk add --no-cache gcc musl-dev linux-headers
copY requirements.txt requirements.txt
RUN pip install -r requirements.txt
EXPOSE 5000
copY . .
CMD ["flask", "run"]
5创建docker-compose.yml
# version: "3.9" 需要版本对应
version: "3"
services:
web:
build: .
ports:
- "5000:5000"
redis:
image: "redis:alpine"
6使用Compose构建并运行应用程序
docker-compose up
# 后台运行
# docker-compose up -d
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-87feppxX-1608950922543)(C:\Users\admin\AppData\Local\Temp\1608866566146.png)]
- docker images 自动下载依赖镜像
- 默认服务名: 文件名 _ 服务名 _ num(集群副本数量)
- 创建docker compose自己默认网络,并将所有启动的容器添加到网络中
- 在同一网络下可以直接使用域名访问
停止
# 前端运行使用 ctrl + c 停止
# 后台运行使用
docker-compose stop
yml文件规则
version: "3" # docker-compose核心版本
services: # 服务
fw: # 服务名称
image: redis # 服务配置
ports: # 服务配置2
- "5000:5000"
depends_on: # 依赖(启动顺序)
- fw2
- redis
..... # 容器启动的所有配置
fw2:
image: # 服务配置
官方文档 https://docs.docker.com/compose/compose-file/compose-file-v2/
测试开源程序(官方给的)
创建工作文件夹 my_wordpress/
创建docker-compose.yml
version: '3.3'
services:
db:
image: MysqL:5.7
volumes:
- db_data:/var/lib/MysqL
restart: always
environment:
MysqL_ROOT_PASSWORD: somewordpress
MysqL_DATABASE: wordpress
MysqL_USER: wordpress
MysqL_PASSWORD: wordpress
wordpress:
depends_on:
- db
image: wordpress:latest
ports:
- "8000:80"
restart: always
environment:
wordpress_DB_HOST: db:3306
wordpress_DB_USER: wordpress
wordpress_DB_PASSWORD: wordpress
wordpress_DB_NAME: wordpress
volumes:
db_data: {}
后台运行
docker-compose up -d
Docker Swarm
- 集群
- 必须有两个或两个以上主节点才能运行
[root@centos3 ~]# docker swarm --help
Usage: docker swarm COMMAND
Manage Swarm
Commands:
ca 管理根CA
init 初始化集群
join 加入集群
join-token 创建加入令牌
leave 离开集群
unlock 解锁群
unlock-key 管理解锁密钥
update 更新集群
Run 'docker swarm COMMAND --help' for more information on a command.
1初始化一个集群
docker swarm init [OPTIONS]
名字,简写 | 默认 | 描述 |
---|---|---|
–advertise-addr | 通告地址(格式:<ip | interface>:端口) | |
–autolock | 假 | 启用管理器自动锁定(需要解锁密钥才能启动停止的管理器) |
–availability | active | 节点的可用性(“活动”|“暂停”|“漏”) |
–cert-expiry | 2160h0m0s | 节点证书的有效期(ns | us | ms | s | m | h) |
–data-path-addr | 用于数据路径流量的地址或接口(格式:<ip | interface>) | |
–dispatcher-heartbeat | 5S | 调度员心跳周期(ns | us | ms | s | m | h) |
–external-ca | 一个或多个证书签名端点的规格 | |
–force-new-cluster | 假 | 强制从当前状态创建一个新的群集 |
–listen-addr | 0.0.0.0:2377 | 监听地址(格式:<ip | interface>:端口) |
–max-snapshots | 0 | 要保留的附加木筏快照的数量 |
–snapshot-interval | 10000 | Raft快照之间的日志条目数 |
–task-history-limit | 5 | 任务历史保留限制 |
# 初始化集群
docker swarm init --advertise-addr 192.168.0.191
2加入一个节点
docker swarm join [OPTIONS] HOST:PORT
名字,简写 | 默认 | 描述 |
---|---|---|
–advertise-addr | 通告地址(格式:<ip | interface>:端口) | |
–availability | active | 节点的可用性(“活动”|“暂停”|“漏”) |
–data-path-addr | 用于数据路径流量的地址或接口(格式:<ip | interface>) | |
–listen-addr | 0.0.0.0:2377 | 监听地址(格式:<ip | interface>:端口) |
–token | 进入群的令牌 |
# 例如加入一个节点
# 令牌SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2
docker swarm join --token SWMTKN-1-3pu6hszjas19xyp7ghgosyx9k8atbfcr8p2is99znpy26u2lkl-7p73s1dx5in4tatdymyhg9hu2 192.168.0.191:2377
3获取令牌
docker swarm join-token [OPTIONS] (worker|manager)
# 工作令牌
docker swarm join-token worker
# 管理令牌
docker swarm join-token manager
查看节点
# 查看节点
docker node
Docker Service
docker service COMMAND
命令 | 描述 |
---|---|
docker service create | 创建一项新服务 |
docker service inspect | 显示一项或多项服务的详细信息 |
docker service logs | 获取服务或任务的日志 |
docker service ls | 列出服务 |
docker service ps | 列出一项或多项服务的任务 |
docker service rm | 删除一项或多项服务 |
docker service scale | 扩展一个或多个复制服务 |
docker service update | 更新服务 |
1创建服务
docker service create [OPTIONS] IMAGE [COMMAND] [ARG...]
名字,简写 | 默认 | 描述 |
---|---|---|
–config | 指定配置以暴露给服务 | |
–constraint | 展示位置限制 | |
–container-label | 容器标签 | |
–credential-spec | 托管服务帐户的凭证规范(仅限Windows) | |
–detach,-d | 真正 | 立即退出,而不是等待服务收敛 |
–dns | 设置自定义DNS服务器 | |
–dns-option | 设置DNS选项 | |
–dns-search | 设置自定义DNS搜索域 | |
–endpoint-mode | 要人 | 端点模式(vip或dnsrr) |
–entrypoint | 覆盖图像的默认入口点 | |
–env,-e | 设置环境变量 | |
–env-file | 读入环境变量文件 | |
–group | 为容器设置一个或多个补充用户组 | |
–health-cmd | 运行以检查运行状况的命令 | |
–health-interval | 运行检查之间的时间(ms | s | m | h) | |
–health-retries | 0 | 需要报告不健康的连续失败 |
–health-start-period | 在重新计数到不稳定(ms | s | m | h)之前,容器初始化的开始时间段 | |
–health-timeout | 允许一次检查运行的最长时间(ms | s | m | h) | |
–host | 设置一个或多个自定义主机到IP映射(主机:IP) | |
–hostname | 容器主机名 | |
–label, -l | 服务标签 | |
–limit-cpu | 限制cpu | |
–limit-memory | 0 | 限制记忆 |
–log-driver | 记录驱动程序的服务 | |
–log-OPT | 记录驱动程序选项 | |
–mode | 复制 | 服务模式(复制或全局) |
–mount | 将文件系统挂载附加到服务 | |
–name | 服务名称 | |
–network | 网络附件 | |
–no-healthcheck | 假 | 禁用任何容器指定的HEALTHCHECK |
–no-resolve-image | 假 | 不要查询注册表来解析图像摘要和支持的平台 |
–placement-PREF | 添加展示位置首选项 | |
–publish,-p | 将端口发布为节点端口 | |
–quiet,-q | 假 | 抑制进度输出 |
–read-only | 假 | 将容器的根文件系统挂载为只读 |
–replicas | 任务数量 | |
–reserve-cpu | 预留cpu | |
–reserve-memory | 0 | 保留内存 |
–restart-condition | 满足条件时重新启动(“none”|“on-failure”|“any”)(默认为“any”) | |
–restart-delay | 重启尝试之间的延迟(ns | us | ms | s | m | h)(默认5秒) | |
–restart-max-attempts | 放弃前的最大重启次数 | |
–restart-window | 用于评估重新启动策略的窗口(ns | us | ms | s | m | h) | |
–rollback-delay | 0 | 任务回滚之间的延迟(ns | us | ms | s | m | h)(默认值为0) |
–rollback-failure-action | 回滚失败的操作(“暂停”|“继续”)(默认“暂停”) | |
–rollback-max-failure-ratio | 0 | 在回滚期间容忍的失败率(默认0) |
–rollback-monitor | 0 | (ns | us | ms | s | m | h)(默认5秒)每个任务回滚之后的持续时间 |
–rollback-order | 回滚顺序(“start-first”|“stop-first”)(默认“stop-first”) | |
–rollback-parallelism | 1 | 同时回滚的任务的最大数量(0一次全部回滚) |
–secret | 指定泄露给服务的秘密 | |
–stop-grace-period | 强制杀死一个容器之前等待的时间(ns | us | ms | s | m | h)(默认10秒) | |
–stop-signal | 停止容器的信号 | |
–tty, -t | 假 | 分配一个伪TTY |
–update-delay | 0 | 更新之间的延迟(ns | us | ms | s | m | h)(默认为0) |
–update-failure-action | 更新失败的操作(“暂停”|“继续”|“回滚”)(默认“暂停”) | |
–update-max-failure-ratio | 0 | 更新期间容许的失败率(默认0) |
–update-monitor | 0 | (ns | us | ms | s | m | h)(默认5秒)每个任务更新后的持续时间 |
–update-order | 更新顺序(“start-first”|“stop-first”)(默认为“stop-first”) | |
–update-parallelism | 1 | 同时更新的最大任务数(0个一次全部更新) |
–user,-u | 用户名或UID(格式:<名称| uid>:<组| gid>) | |
–with-registry-auth | 假 | 向注册代理发送注册表认证详细信息 |
–workdir,-w | 容器内的工作目录 |
# 例如,启动一个Nginx服务,暴露8080端口
docker service create -p 8080:80 --name Nginx01 Nginx
# docker run 容器启动,单机版本
# docker service 服务启动,支持扩缩容器
# 查看服务
docker service ps Nginx01
# 查看副本
docker service ls
# 查看详情
docker service inspect Nginx01
2更新服务
docker service update [OPTIONS] SERVICE
名字,简写 | 默认 | 描述 |
---|---|---|
–args | 服务命令参数 | |
–config-add | 添加或更新服务上的配置文件 | |
–config-RM | 删除配置文件 | |
–constraint-add | 添加或更新展示位置约束 | |
–constraint-RM | 删除约束 | |
–container-label-add | 添加或更新容器标签 | |
–container-label-rm | 用钥匙取出容器标签 | |
–credential-spec | 托管服务帐户的凭证规范(仅限Windows) | |
–detach,-d | 真 | 立即退出,而不是等待服务收敛 |
–dns-add | 添加或更新自定义DNS服务器 | |
–dns-option-add | 添加或更新DNS选项 | |
–dns-option-rm | 删除一个DNS选项 | |
–dns-rm | 删除自定义的DNS服务器 | |
–dns-search-add | 添加或更新自定义DNS搜索域 | |
–dns-search-rm | 删除一个DNS搜索域 | |
–endpoint-mode | 端点模式(vip或dnsrr) | |
–entrypoint | 覆盖图像的默认入口点 | |
–env-add | 添加或更新环境变量 | |
–env-RM | 删除一个环境变量 | |
–force | 假 | 即使没有更改需要,也强制更新 |
–group-add | 向容器添加一个附加的补充用户组 | |
–group-RM | 从容器中删除先前添加的补充用户组 | |
–health-cmd | 运行以检查运行状况的命令 | |
–health-interval | 运行检查之间的时间(ms | s | m | h) | |
–health-retries | 0 | 需要报告不健康的连续失败 |
–health-retries | 在重新计数到不稳定(ms | s | m | h)之前,容器初始化的开始时间段 | |
–health-timeout | 允许一次检查运行的最长时间(ms | s | m | h) | |
–host加 | 添加或更新自定义主机到IP映射(主机:IP) | |
–host-RM | 删除自定义的主机到IP映射(主机:IP) | |
–hostname | 容器主机名 | |
–image | 服务图片标签 | |
–label-add | 添加或更新服务标签 | |
–label-RM | 用钥匙去除标签 | |
–limit-cpu | 限制cpu | |
–limit-memory | 0 | 限制记忆 |
–log-driver | 记录驱动程序的服务 | |
–log-OPT | 记录驱动程序选项 | |
–mount-add | 添加或更新服务上的装载 | |
–mount-RM | 通过目标路径移除一个安装 | |
–network加 | 添加一个网络 | |
–network-RM | 删除网络 | |
–no-healthcheck | 假 | 禁用任何容器指定的HEALTHCHECK |
–no-resolve-image | 假 | 不要查询注册表来解析图像摘要和支持的平台 |
–placement-PREF-ADD | 添加展示位置首选项 | |
–placement-PREF-RM | 删除展示位置偏好设置 | |
–publish相加 | 添加或更新已发布的端口 | |
–publish-RM | 通过目标端口删除发布的端口 | |
–quiet,-q | 假 | 抑制进度输出 |
–read-only | 假 | 将容器的根文件系统挂载为只读 |
–replicas | 任务数量 | |
–reserve-cpu | 预留cpu | |
–reserve-memory | 0 | 保留内存 |
–restart-condition | 条件满足时重新启动(“none”|“on-failure”|“any”) | |
–restart-delay | 重启尝试之间的延迟(ns | us | ms | s | m | h) | |
–restart-max-attempts | 放弃前的最大重启次数 | |
–restart-window | 用于评估重新启动策略的窗口(ns | us | ms | s | m | h) | |
–rollback | 假 | 回退到先前的规范 |
–rollback-delay | 0 | 任务回滚之间的延迟(ns | us | ms | s | m | h) |
–rollback-failure-action | 回滚失败的操作(“暂停”|“继续”) | |
–rollback-max-failure-ratio | 0 | 在回滚期间容忍的失败率 |
–rollback-monitor | 0 | 每个任务回滚后监视失败的持续时间(ns | us | ms | s | m | h) |
–rollback-order | 回滚顺序(“start-first”|“stop-first”) | |
–rollback-parallelism | 0 | 同时回滚的任务的最大数量(0一次全部回滚) |
–secret-add | 添加或更新服务的秘密 | |
–secret-RM | 去掉一个秘密 | |
–stop-grace-period | 强制杀死一个容器之前的等待时间(ns | us | ms | s | m | h) | |
–stop-signal | 停止容器的信号 | |
–tty, -t | 假 | 分配一个伪TTY |
–update-delay | 0 | 更新之间的延迟(ns | us | ms | s | m | h) |
–update-failure-action | 更新失败的操作(“暂停”|“继续”|“回滚”) | |
–update-max-failure-ratio | 0 | 更新期间容错的失败率 |
–update-monitor | 0 | (ns | us | ms | s | m | h)每个任务更新后的持续时间 |
–update-order | 更新顺序(“start-first”|“stop-first”) | |
–update-parallelism | 0 | 同时更新的最大任务数(0个一次全部更新) |
–user,-u | 用户名或UID(格式:<名称| uid>:<组| gid>) | |
–with-registry-auth | 假 | 向注册代理发送注册表认证详细信息 |
–workdir,-w | 容器内的工作目录 |
# 为 Nginx01 创建 10 个副本
docker service update --replicas 10 Nginx01
# 或 使用 scale 命令
docker service scale Nginx01=10
移除服务
docker service rm Nginx01
Docker Compose比Docker Swarm和Docker Stack有什么好处?
从我读到的内容来看,似乎Docker-Compose是一个在单个主机上创建多个容器的工具,而Docker Swarm是一个可以完全相同但具有更多控制权的工具,并且在Docker Stack的帮助下可以在多个主机上完成.我浏览了教程,也遇到了这个帖子:
docker-compose.yml vs docker-stack.yml what difference?
而且我得出的结论是,当你可以将Docker Swarm与Docker Stack一起使用时,没有理由使用Docker-Compose.他们甚至可以使用相同的docker-compose.yml.
似乎Docker-compose出现在swarm和堆栈之前,并且可能是swarm堆栈的新解决方案使得compose过时,但它仍然是遗留原因.这个想法是否正确?如果没有,在构建开发或生产环境方面,Docker-Compose对Docker Swarm和Docker Stack有什么好处?
It seems that Docker-compose came before the swarm and stack and maybe the new solution of swarm + stack makes compose obsolete,but it still remains for legacy reasons. Is this thinking correct?
简而言之,是的. Compose在所有Swarm之前出现(它起源于名为fig的第三方实用程序).更糟糕的是,甚至还有两个不同的Swarms,旧的Swarm(一个是单独的工具)和Swarm模式(这些日子内置于docker二进制文件中).
它似乎正在演变为内置于Docker中的服务和部署概念.但我猜想Docker Compose和Swarm Mode部署的东西会并存一段时间.
知道Docker Compose基础是一个名为libcompose(https://github.com/docker/libcompose)的库是有益的,其他第三方实用程序使用它来支持用于部署的docker-compose.yml文件格式(参见Rancher和rancher-compose作为示例) .我想他们会努力继续支持libcompose.
我不清楚Docker Swarm部署的东西是否实际上使用了libcompose.在我粗略的搜索中,Swarm模式似乎没有实现libcompose并且做了自己的事情.我不确定这与Docker Compose和libcompose的未来有何关系.你认为合适的解释……
Docker 从入门到进阶七:DockerFile 与 Docker Compose
文章目录
-
- Dockerfile
-
- Dockerfile 是什么
- Dockerfile 规则
- Dockerfile 构建镜像示例
- Dockerfile 保留字
- 虚悬镜像
- Docker Compose 容器编排
-
- Docker Compose 是什么?
- 下载安装 compose
- compose 使用步骤
- compose 常用命令
Dockerfile
Dockerfile 是什么
Dockerfile 是用来 构建 Docker 镜像 的文本文件,是由一条条构建镜像所需的指令和参数构成的脚本。
就拿我之前几次虚拟机崩溃的例子来说吧,别的咱也不说。由于我的虚拟机上部署着我毕设的一大堆环境,每次崩溃我都要一个一个去给它们下载回来,那时候我就在想,我能不能搞个一键安装的 shell 脚本,放那儿自己运行,我一觉醒来啥都配好了。
现在上容器了,一两个镜像咱自己安装就好了,但是原生 Linux 系统那是真的要啥没啥啊,还手动一个个安装吗?能确保一个不落吗?还是直接给我来个清单一键安装吧。
Dockerfile 规则
FROM:定制的镜像都是基于 FROM 的镜像。
RUN:用于执行后面跟着的命令行命令。
RUN <命令行命令>
# <命令行命令> 等同于,在终端操作的 shell 命令。
・1:每条保留字指令都必须为大写字母且后面要跟随至少一个参数
・2:指令按照从上到下,顺序执行
・3:# 表示注释
・4:每条指令都会创建一个新的镜像层并对镜像进行提交,所以过多无意义的层,会造成镜像膨胀过大。
以下两种写法高下立判:
FROM centos
RUN yum -y install wget
RUN wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz"
RUN tar -xvf redis.tar.gz
以上执行会创建 3 层镜像。可简化为以下格式:
FROM centos
RUN yum -y install wget \
&& wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz" \
&& tar -xvf redis.tar.gz
如上,以 && 符号连接命令,这样执行后,只会创建 1 层镜像。
Dockerfile 构建镜像示例
在 Dockerfile 文件的存放目录下,执行构建动作:
mkdir myfile
cd myfile
vim Dockerfile
FROM ubuntu
MAINTAINER wlf<lion@qq.com>
ENV MYPATH /usr/local
WORKDIR $MYPATH
#安装vim编辑器
#安装ifconfig命令查看网络IP
#安装java8及lib库
RUN apt install net-tools && install vim && glibc.i686 && mkdir /usr/local/java
#ADD 是相对路径jar,把jdk-8u171-linux-x64.tar.gz添加到容器中,安装包必须要和Dockerfile文件在同一位置
ADD jdk-8u171-linux-x64.tar.gz /usr/local/java/
#配置java环境变量
ENV JAVA_HOME /usr/local/java/jdk1.8.0_171
ENV JRE_HOME $JAVA_HOME/jre
ENV CLASSPATH $JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$JRE_HOME/lib:$CLASSPATH
ENV PATH $JAVA_HOME/bin:$PATH
EXPOSE 80
CMD echo $MYPATH
CMD echo "success--------------ok"
CMD /bin/bash
构建:docker build -t 新镜像名字:TAG .
Dockerfile 保留字
FROM- 镜像从那里来
MAINTAINER- 镜像维护者信息
RUN- 构建镜像执行的命令,每一次RUN都会构建一层
CMD- 容器启动的命令,如果有多个则以最后一个为准,也可以为ENTRYPOINT提供参数
VOLUME- 定义数据卷,如果没有定义则使用默认
USER- 指定后续执行的用户组和用户
WORKDIR- 切换当前执行的工作目录
HEALTHCHECH- 健康检测指令
ARG- 变量属性值,但不在容器内部起作用
EXPOSE- 暴露端口
ENV- 变量属性值,容器内部也会起作用
ADD- 添加文件,如果是压缩文件也解压
COPY- 添加文件,以复制的形式
ENTRYPOINT- 容器进入时执行的命令
虚悬镜像
・仓库名、标签都是的镜像,俗称 dangling image。
from ubuntu
CMD echo ''action is success''
喏,这个就可以构建出来一个,瞅一眼。
查看所有当前虚悬镜像:
docker image ls -f dangling=true
删除所有虚悬镜像:
docker image prune
留着也没用。
Docker Compose 容器编排
Docker Compose 是什么?
Compose 是 Docker 公司推出的一个工具软件,可以管理多个 Docker 容器组成一个应用。你需要定义一个 YAML 格式的配置文件
docker-compose.yml,写好多个容器之间的调用关系。然后,只要一个命令,就能同时启动 / 关闭这些容器
Docker-Compose 是 Docker 官方的开源项目, 负责实现对 Docker 容器集群的快速编排。
下载安装 compose
官网:https://docs.docker.com/compose/
下载命令:
sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
compose 使用步骤
·编写Dockerfile定义各个微服务应用并构建出对应的镜像文件
·使用 docker-compose.yml 定义一个完整业务单元,安排好整体应用中的各个容器服务。
·最后,执行docker-compose up命令 来启动并运行整个应用程序,完成一键部署上线
关于 yml 文件教程:待补全。
compose 常用命令
Compose常用命令
docker-compose -h # 查看帮助
docker-compose up # 启动所有docker-compose服务
docker-compose up -d # 启动所有docker-compose服务并后台运行
docker-compose down # 停止并删除容器、网络、卷、镜像。
docker-compose exec yml里面的服务id # 进入容器实例内部 docker-compose exec docker-compose.yml文件中写的服务id /bin/bash
docker-compose ps # 展示当前docker-compose编排过的运行的所有容器
docker-compose top # 展示当前docker-compose编排过的容器进程
docker-compose logs yml里面的服务id # 查看容器输出日志
docker-compose config # 检查配置
docker-compose config -q # 检查配置,有问题才有输出
docker-compose restart # 重启服务
docker-compose start # 启动服务
docker-compose stop # 停止服务
本文同步分享在 博客 “看,未来”(CSDN)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与 “OSC 源创计划”,欢迎正在阅读的你也加入,一起分享。
关于Docker系列教程19-Docker Compose简介和docker—compose的问题就给大家分享到这里,感谢你花时间阅读本站内容,更多关于Docker 17.03系列教程(一)Docker EE/Docker CE简介与版本规划、Docker Compose 和 Docker Swarm 和 Docker Service、Docker Compose比Docker Swarm和Docker Stack有什么好处?、Docker 从入门到进阶七:DockerFile 与 Docker Compose等相关知识的信息别忘了在本站进行查找喔。
本文标签: