tu
/
docker-compose
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

上传文件至 /

This commit is contained in:
tu 2024-06-07 16:28:34 +08:00
commit b9fd2d73ef
5 changed files with 1434 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

328
Docker-compose-参数.md Normal file
View File

@ -0,0 +1,328 @@
```shell
Compose默认的模板文件名称为 docker-compose.yml，格式为yaml格式.
version: "3"
services:
webapp:
image: examples/web
ports:
- "80:80"
volumes:
- "/data"
注意每个服务都必须通过 image 指令指定镜像或 build 指令（需要 Dockerfile）等来自动构建生成镜像。如果使用 build 指令，在 Dockerfile 中设置的选项(例如：CMD, EXPOSE, VOLUME, ENV 等) 将会自动被获取，无需在 docker-compose.yml 中重复设置。
3.3.1.build
指定 Dockerfile 所在文件夹的路径（可以是绝对路径，或者相对 docker-compose.yml 文件的路径）。 Compose 将会利用它自动构建这个镜像，然后使用这个镜像。
version: '3'
services:
webapp:
build: ./dir
可以使用 context 指令指定 Dockerfile 所在文件夹的路径。使用 dockerfile 指令指定 Dockerfile 文件名,这里的文件名可以自定义，默认文件名为Dockerfile, 如果是默认文件名，可以不用指定dockerfile文件，使用 arg 指令指定构建镜像时的变量。
version: '3'
services:
webapp:
build:
context: ./dir
dockerfile: Dockerfile-alternate
args:
buildno: 1
使用 cache_from 指定构建镜像的缓存
build:
context: .
cache_from:
- alpine:latest
- corp/web_app:3.14
3.3.2.cap_add, cap_drop
指定容器的内核能力（capacity）分配。
例如，让容器拥有所有能力可以指定为：
cap_add:
- ALL
去掉 NET_ADMIN 能力可以指定为：
cap_drop:
- NET_ADMIN
3.3.3.command
覆盖容器启动后默认执行的命令
command: bundle exec thin -p 3000
该命令也可以是一个列表，类似于 dockerfile：
command: ["bundle", "exec", "thin", "-p", "3000"]
3.3.4.configs
config 定义仅在 3.3 版及更高版本的撰写文件格式中受支持
3.3.5.Container_name
指定容器名称。默认将会使用 项目名称_服务名称_序号 这样的格式。
container_name: docker-web-container
注意: 由于 Docker 容器名称必须是唯一的，因此如果指定了自定义名称，则不能将服务扩展到 1 个以上的容器。
使用 docker stack deploy 时的注意事项：在 swarm 模式下部署堆栈container_name时忽略该选项。
3.3.6.deploy
指定与服务部署和运行相关的配置,仅用于 Swarm mode.
3.3.7.devices
设备映射列表。使用与--devicedocker 客户端创建选项相同的格式.
devices:
- "/dev/ttyUSB0:/dev/ttyUSB0"
使用 docker stack deploy 时的注意事项
在 swarm 模式下部署堆栈devices时忽略该选项
3.3.8.depends_on
解决容器的依赖、启动先后的问题,表示服务之间的依赖关系。服务依赖会导致以下行为：
·docker-compose up按依赖顺序启动服务。在下面的例子中，db和redis在 之前启动web。
·docker-compose up SERVICE自动包含SERVICE的依赖项。在下面的示例中，docker-compose up web还创建并启动db和redis。
·docker-compose stop按依赖顺序停止服务。在以下示例中，web在db和之前停止redis。
version: "3.9"services:
web:
build: .
depends_on:
- db
- redis
redis:
image: redis
db:
image: postgres
注意：web 服务不会等待 redis db 「完全启动」之后才启动
3.3.9.dns
自定义 DNS 服务器。可以是一个值，也可以是一个列表.
dns: 8.8.8.8
dns:
- 8.8.8.8
- 114.114.114.114
3.3.10.dns_search
配置 DNS 搜索域。可以是一个值，也可以是一个列表。
dns_search: example.com
dns_search:
- domain1.example.com
- domain2.example.com
3.3.11.tmpfs
挂载一个 tmpfs 文件系统到容器。
tmpfs: /runtmpfs:
- /run
- /tmp
3.3.12.env_file
从文件中获取环境变量，可以为单独的文件路径或列表。如果通过 docker-compose -f FILE 方式来指定 Compose 模板文件，则 env_file 中变量的路径会基于模板文件路径。如果有变量名称与 environment 指令冲突，则按照惯例，以后者为准。
env_file: .env
env_file:
- ./common.env
- ./apps/web.env
- /opt/secrets.env
环境变量文件中每一行必须符合格式，支持 # 开头的注释行
# common.env: Set development environment
PROG_ENV=development
3.3.13.environment
设置环境变量。你可以使用数组或字典两种格式。只给定名称的变量会自动获取运行 Compose 主机上对应变量的值，可以用来防止泄露不必要的数据。
environment:
RACK_ENV: development
SESSION_SECRET:
environment:
- RACK_ENV=development
- SESSION_SECRET
如果变量名称或者值中用到 true|false，yes|no 等表达 布尔 (opens new window)含义的词汇，最好放到引号里，避免 YAML 自动解析某些内容为对应的布尔语义。这些特定词汇，包括y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF
3.3.14.expose
暴露端口，但不映射到宿主机，只被连接的服务访问。仅可以指定内部端口为参数
expose:
- "3000"
- "8000"
3.3.15.external_links
注意：不建议使用该指令。链接到 docker-compose.yml 外部的容器，甚至并非 Compose 管理的外部容器。
external_links:
- redis_1
- project_db_1:mysql
- project_db_1:postgresql
3.3.16.extra_hosts
类似 Docker 中的 --add-host 参数，指定额外的 host 名称映射信息。
extra_hosts:
- "googledns:8.8.8.8"
- "dockerhub:52.1.157.61"
会在启动后的服务容器中 /etc/hosts 文件中添加如下两条条目。
8.8.8.8 googledns
52.1.157.61 dockerhub
3.3.17.healthcheck
通过命令检查容器是否健康运行。
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost"]
interval: 1m30s
timeout: 10s
retries: 3
3.3.18.image
指定为镜像名称或镜像 ID。如果镜像在本地不存在，Compose 将会尝试拉取这个镜像。
image: ubuntu
image: orchardup/postgresql
image: a4bc65fd
3.3.19.labels
为容器添加 Docker 元数据（metadata）信息。例如可以为容器添加辅助说明信息。
labels:
com.startupteam.description: "webapp for a startup team"
com.startupteam.department: "devops department"
com.startupteam.release: "rc3 for v1.0"
3.3.20.links
警告: 该--link标志是 Docker 的遗留功能。它可能最终会被删除。除非您绝对需要继续使用它，否则我们建议您使用 用户定义的网络 来促进两个容器之间的通信，而不是使用--link.
用户定义的网络不支持但您可以使用的一项功能 --link是在容器之间共享环境变量。但是，您可以使用其他机制（例如卷）以更可控的方式在容器之间共享环境变量。
链接到另一个服务中的容器。指定服务名称和链接别名 ( "SERVICE:ALIAS")，或仅指定服务名称。
web:
links:
- "db"
- "db:database"
- "redis"
链接服务的容器可以通过与别名相同的主机名访问，如果未指定别名，则可以使用服务名称.
使用 docker stack deploy 时的注意事项: 在 swarm 模式下部署堆栈links时忽略该选项
3.3.21.logging
服务的日志记录配置
logging:
driver: syslog
options:
syslog-address: "tcp://192.168.0.42:123"
目前支持三种日志驱动类型。
driver: "json-file"
driver: "syslog"
driver: "none"
只有json-file和journald驱动程序可以直接从docker-compose up和获取日志docker-compose logs。使用任何其他驱动程序不会打印任何日志。
options 配置日志驱动的相关参数。设置最大存储大小和最大文件数使用键值对。
options:
max-size: "200k"
max-file: "10"
3.3.22.network_mode
设置网络模式。使用与 docker 客户端--network参数相同的值，加上特殊形式service:[service name]。
network_mode: "bridge"
network_mode: "host"
network_mode: "none"
network_mode: "service:[service name]"
network_mode: "container:[container name/id]"
3.3.23.networks
配置容器连接的网络。
version: "3"services:
some-service:
networks:
- some-network
- other-network
networks:
some-network:
other-network:
配置网络需要通过networks声名。
3.3.24.pid
跟主机系统共享进程命名空间。打开该选项的容器之间，以及容器和宿主机系统之间可以通过进程 ID 来相互访问和操作。
pid: "host"
3.3.25.ports
暴露端口信息。
使用宿主端口：容器端口 (HOST:CONTAINER) 格式，或者仅仅指定容器的端口（宿主将会随机选择端口）都可以.
有以下三种选择：
指定两个端口 ( HOST:CONTAINER)
仅指定容器端口（为主机端口选择了一个临时主机端口）。
指定要绑定到 AND 两个端口的主机 IP 地址（默认为 0.0.0.0，表示所有接口）：( IPADDR:HOSTPORT:CONTAINERPORT)。如果 HOSTPORT 为空（例如127.0.0.1::80），则会选择一个临时端口来绑定到主机上。
ports:
- "3000"
- "3000-3005"
- "8000:8000"
- "9090-9091:8080-8081"
- "49100:22"
- "127.0.0.1:8001:8001"
- "127.0.0.1:5000-5010:5000-5010"
- "127.0.0.1::5000"
- "6060:6060/udp"
- "12400-12500:1240"
注意：以HOST:CONTAINER格式映射端口时，使用小于 60 的容器端口时可能会遇到错误结果，因为 YAML 将格式xx:yy中的数字解析为 base-60 值。因此，我们建议始终将您的端口映射明确指定为字符串
3.3.26.secrets
存储敏感数据，例如 mysql 服务密码。
version: "3.1"services:
mysql:
image: mysql
environment:
MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password
secrets:
- db_root_password
- my_other_secret
secrets:
my_secret:
file: ./my_secret.txt
my_other_secret:
external: true
通过将密码定义到文件中，然后外包引入文件读取密码。
3.3.27.security_opt
指定容器模板标签（label）机制的默认属性（用户、角色、类型、级别等）。例如配置标签的用户名和角色名。
security_opt:
- label:user:USER
- label:role:ROLE
3.3.28.stop_signal
设置另一个信号来停止容器。在默认情况下使用的是 SIGTERM 停止容器。
stop_signal: SIGUSR1
3.3.29.sysctls
配置容器内核参数。
sysctls:
net.core.somaxconn: 1024
net.ipv4.tcp_syncookies: 0
sysctls:
- net.core.somaxconn=1024
- net.ipv4.tcp_syncookies=0
3.3.30.ulimits
指定容器的 ulimits 限制值。
例如，指定最大进程数为 65535，指定文件句柄数为 20000（软限制，应用可以随时修改，不能超过硬限制） 和 40000（系统硬限制，只能 root 用户提高）。
ulimits:
nproc: 65535
nofile:
soft: 20000
hard: 40000
3.3.31.volumes
数据卷所挂载路径设置。可以设置为宿主机路径(HOST:CONTAINER)或者数据卷名称(VOLUME:CONTAINER)，并且可以设置访问模式 （HOST:CONTAINER:ro）。
该指令中路径支持相对路径。
volumes:
- /var/lib/mysql
- cache/:/tmp/cache
- ~/configs:/etc/configs/:ro
如果路径为数据卷名称，必须在文件中配置数据卷。
version: "3"
services:
my_src:
image: mysql:8.0
volumes:
- mysql_data:/var/lib/mysql
volumes:
mysql_data:
3.3.32.其它指令
此外，还有包括 domainname, entrypoint, hostname, ipc, mac_address, privileged, read_only, shm_size, restart, stdin_open, tty, user, working_dir 等指令，基本跟 docker run 中对应参数的功能一致。
指定服务容器启动后执行的入口文件。
entrypoint: /code/entrypoint.sh
指定容器中运行应用的用户名。
user: nginx
指定容器中工作目录。
working_dir: /code
指定容器中搜索域名、主机名、mac 地址等。
domainname: your_website.comhostname: testmac_address: 08-00-27-00-0C-0A
允许容器中运行一些特权命令。
privileged: true
指定容器退出后的重启策略为始终重启。该命令对保持服务始终运行十分有效，在生产环境中推荐配置为 always 或者 unless-stopped。
restart: always
以只读模式挂载容器的 root 文件系统，意味着不能对容器内容进行修改。
read_only: true
打开标准输入，可以接受外部输入。
stdin_open: true
模拟一个伪终端。
tty: true
3.3.33.读取变量
Compose 模板文件支持动态读取主机的系统环境变量和当前目录下的 .env 文件中的变量。
例如，下面的 Compose 文件将从运行它的环境中读取变量 ${MONGO_VERSION} 的值，并写入执行的指令中。
version: "3"services:
db:
image: "mongo:${MONGO_VERSION}"
如果执行 MONGO_VERSION=3.2 docker-compose up 则会启动一个 mongo:3.2 镜像的容器；如果执行 MONGO_VERSION=2.8 docker-compose up 则会启动一个 mongo:2.8 镜像的容器。
若当前目录存在 .env 文件，执行 docker-compose 命令时将从该文件中读取变量。
在当前目录新建 .env 文件并写入以下内容。
# 支持 # 号注释MONGO_VERSION=3.6
执行 docker-compose up 则会启动一个 mongo:3.6 镜像的容器。
```

285
Docker-compose.md Normal file
View File

@ -0,0 +1,285 @@
<h1><center>Docker-compose</center></h1>
**作者：行癫（盗版必究）**
------
## 一：Docker-compose概述
​ Compose 是一个用于定义和运行多容器 Docker 应用程序的工具。使用 Compose，您可以使用 YAML 文件来配置应用程序的服务。然后，使用一个命令，您可以从您的配置中创建并启动所有服务
​ Compose 适用于所有环境：生产、登台、开发、测试以及 CI 工作流程
使用 Compose 基本上是一个三步过程：
​ 使用定义您的应用程序的环境，`Dockerfile`以便可以在任何地方复制它
​ 定义构成您的应用程序的服务，`docker-compose.yml` 以便它们可以在隔离环境中一起运行
​ 运行`docker compose up`，Docker compose 命令启动并运行您的整个应用程序
举例：
```shell
version: "3.9" # optional since v1.27.0
services:
web:
build: .
ports:
- "8000:5000"
volumes:
- .:/code
- logvolume01:/var/log
links:
- redis
redis:
image: redis
volumes:
logvolume01: {}
```
## 二：Docker-compose安装
#### 1.下载
```shell
[root@xingdian ~]# curl -SL https://github.com/docker/compose/releases/download/v2.6.0/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose
```
#### 2.创建软连接
```shell
[root@xingdian ~]# ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
```
#### 3.添加执行权限
```shell
[root@xingdian ~]# chmod a+x /usr/bin/docker-compose
```
#### 4.验证版本
```shell
[root@xingdian ~]# docker-compose --version
Docker Compose version v2.6.0
```
## 三：Docker-compose入门
#### 1.设置
定义应用程序依赖项：
​ 1.为项目创建一个目录：
```shell
[root@xingdian ~]# mkdir composetest
[root@xingdian ~]# cd composetest
```
​ 2.在项目目录中创建一个名为的文件`app.py`并将其粘贴到：
```shell
[root@xingdian composetest]# cat 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)
```
注意：
​ 在此示例中，`redis`是应用程序网络上的 redis 容器的主机名。我们使用 Redis 的默认端口，`6379`
​ 3.在您的项目目录中创建另一个名为的文件requirements.txt并将其粘贴到：
```shell
flask
redis
```
#### 2.创建 Dockerfile
​ 编写一个构建 Docker 映像的 Dockerfile。该映像包含 Python 应用程序所需的所有依赖项，包括 Python 本身
```shell
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"]
```
注意：
​ 从 Python 3.7 映像开始构建映像
​ 将工作目录设置为`/code`
​ 设置命令使用的环境变量`flask`
​ 安装 gcc 和其他依赖项
​ 复制`requirements.txt`并安装 Python 依赖项
​ 向镜像添加元数据以描述容器正在侦听端口 5000
​ 将项目中的当前目录复制`.`到镜像中的workdir `.`
​ 将容器的默认命令设置为`flask run`
#### 3.Compose 文件中定义服务
​ 在项目目录中创建一个名为的文件`docker-compose.yml`并粘贴以下内容：
```shell
version: "3.9"
services:
web:
build: .
ports:
- "8000:5000"
redis:
image: "redis:alpine"
```
​ 这个 Compose 文件定义了两个服务：`web`和`redis`
注意：
​ 该服务使用从当前目录中`web`构建的图像。`Dockerfile`然后它将容器和主机绑定到暴露的端口，`8000`. 此示例服务使用 Flask Web 服务器的默认端口，`5000`
​ 该`redis`服务使用 从 Docker Hub 注册表中提取的公共Redis映像
#### 4.使用 Compose 构建并运行您的应用程序
```shell
[root@xingdian composetest]# docker-compose up
[+] Building 95.0s (6/10)
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 291B 0.0s
[+] Building 481.8s (6/10)
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 291B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/python:3.7-alpine 4.3s
=> [1/6] FROM docker.io/library/python:3.7-alpine@sha256:a03bd8ebf621e25cc51ee80cb82d04ca 0.0s
=> [internal] load build context 0.0s
=> => transferring context: 1.06kB 0.0s
=> CACHED [2/6] WORKDIR /code 0.0s
=> [3/6] RUN apk add --no-cache gcc musl-dev linux-headers 477.5s
=> => # ERROR: libgomp-11.2.1_git20220219-r2: temporary error (try again later)
=> => # (5/12) Installing libatomic (11.2.1_git20220219-r2)
.............
composetest-web-1 | Use a production WSGI server instead.
composetest-web-1 | * Debug mode: off
composetest-web-1 | * Running on all addresses (0.0.0.0)
composetest-web-1 | WARNING: This is a development server. Do not use it in a production deployment.
composetest-web-1 | * Running on http://127.0.0.1:5000
composetest-web-1 | * Running on http://172.19.0.2:5000 (Press CTRL+C to quit)
```
#### 5.测试访问
​ 在浏览器中输入 http://localhost:8000/ 以查看正在运行的应用程序
![image-20220621164601764](https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220621164601764.png)
#### 6.查看docker镜像
```shell
[root@xingdian composetest]# docker images
```
![image-20220621171235416](https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220621171235416.png)
注意：
​ 停止应用程序，方法是`docker-compose down` 在第二个终端的项目目录中运行，或者在启动应用程序的原始终端中按 CTRL+C
#### 7.编辑 Compose 文件以添加绑定挂载
```shell
version: "3.9"
services:
web:
build: .
ports:
- "8000:5000"
volumes:
- .:/code
environment:
FLASK_ENV: development
redis:
image: "redis:alpine"
```
​ 新volumes密钥将主机上的项目目录（当前目录）挂载到/code容器内，允许您即时修改代码，而无需重建映像。environment键设置 FLASK_ENV环境变量，它告诉flask run在开发模式下运行并在更改时重新加载代码。这种模式应该只在开发中使用
#### 8.更新应用程序
​ 由于应用程序代码现在使用卷安装到容器中，因此您可以对其代码进行更改并立即查看更改，而无需重建映像
​ 更改问候语app.py并保存。例如，将Hello World! 消息更改为Hello from Docker!：
![image-20220621172737014](https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220621172737014.png)
#### 9.在浏览器中刷新应用程序
![image-20220621173011640](https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220621173011640.png)
#### 10.其他命令
```shell
[root@xingdian composetest]# docker-compose up -d //后台运行
[root@xingdian composetest]# docker-compose ps //列出容器
[root@xingdian composetest]# docker-compose pause //暂停服务
[root@xingdian composetest]# docker-compose unpause //取消暂停服务
[root@xingdian composetest]# docker-compose down //停止并移除容器、网络
[root@xingdian composetest]# docker-compose logs //查看容器的输出
[root@xingdian composetest]# docker-compose start //启动服务
[root@xingdian composetest]# docker-compose stop //停止服务
[root@xingdian composetest]# docker-compose stop [SERVICE...]
[root@xingdian composetest]# docker-compose cp //在服务容器和本地文件系统之间复制文件/文件夹
[root@xingdian composetest]# docker-compose cp [OPTIONS] SRC_PATH|- SERVICE:DEST_PATH
[root@xingdian composetest]# docker-compose run web env //为您的服务运行一次性命令,查看 web服务可以使用哪些环境变量
```

88
Docker-compose应用项目.md Normal file
View File

@ -0,0 +1,88 @@
<h1><center>Docker-compose项目应用</center></h1>
作者：行癫（盗版必究）
------
## 一：环境准备
1.docker环境
2.docker-compose环境
3.jar包
注意：
​ 该案例主要是网络的配置（network）创建网络；使用网络
​ 该案例主要是links使用（相当于本地服务器域名解析）
​ 项目在连接数据库时，可以在docker-compose使用links连接hostname（项目中数据库地址改为hostname的值）
​ 该项目配置了数据库在docker-compose文件中直接导入（官方Dockerfile中有专门的目录和执行脚本）
## 二：Docker-compose
#### 1.准备
![image-20230327004541931](https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20230327004541931.png)
#### 2.Dockerfile文件
```shell
[root@nfs-harbor a]# cat Dockerfile
FROM centos:7
MAINTAINER "xingdian" <xingdian@gmail.com>
ENV TZ=Asia/Shanghai
ENV LANG=en_US.UTF-8
ENV LANGUAGE=en_US:en
ENV LC_ALL=en_US.UTF-8
ADD jdk-8u211-linux-x64.tar.gz /usr/local/
RUN mv /usr/local/jdk1.8.0_211 /usr/local/java
ENV JAVA_HOME /usr/local/java/
ENV PATH $PATH:$JAVA_HOME/bin
COPY mayday.jar /usr/local
EXPOSE 10086
CMD java -jar /usr/local/mayday.jar
```
#### 3.Docker-compose文件
```shell
[root@nfs-harbor a]# cat docker-compose.yml
version: "3.1"
networks:
xingdian:
ipam:
driver: default
config:
- subnet: 172.28.0.0/16
services:
db.com:
container_name: db
image: mysql:5.7.38
environment:
MYSQL_ROOT_PASSWORD: 123456
MYSQL_DATABASE: maydaytest
hostname: db.com
networks:
- xingdian
volumes:
- /etc/localtime:/etc/localtime
- ./mysql:/var/lib/mysql
- ./mayday.sql:/docker-entrypoint-initdb.d/mayday.sql
web.com:
container_name: web
build: .
hostname: web.com
networks:
- xingdian
ports:
- 30090:8091
links:
- db.com
```

65
Docker-compose部署wordpress.md Normal file
View File

@ -0,0 +1,65 @@
<h1><center>Docker-compose部署wordpress</center></h1>
------
**作者：行癫（盗版必究）**
## 一：环境准备
#### 1.docker-ce正常使用
#### 2.docker-compose正常使用
#### 3.镜像地址
```shell
https://share.weiyun.com/Ybc5T48m
```
## 二：容器互联
#### 编写Dockerfile文件
```shell
[root@master wordpress]# cat docker-compose.yaml
version: '3.3'
services:
mysql:
image: 10.0.0.230/xingdian/mysql@sha256:897086d07d1efa876224b147397ea8d3147e61dd84dce963aace1d5e9dc2802d
environment:
MYSQL_ROOT_PASSWORD: 123456
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
depends_on:
- mysql
image: 10.0.0.230/xingdian/wordpress@sha256:561bff4ab02c2eee2f5e80c5c0e1832359be84f7129433d640de039ba7acd57b
ports:
- 82:80
environment:
WORDPRESS_DB_HOST: mysql
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
```
#### 启动wordpress
```shell
[root@master wordpress]# docker-compose up -d
```
#### 查看
```shell
[root@master wordpress]# docker-compose ps
Name Command State Ports
-----------------------------------------------------------------------------------------
wordpress_mysql_1 docker-entrypoint.sh mysqld Up 3306/tcp
wordpress_wordpress_1 docker-entrypoint.sh apach Up 0.0.0.0:82->80/tcp,:::82->80/tcp
```
#### 浏览器访问
<img src="https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/image-20220820210705142.png" alt="image-20220820210705142" style="zoom:50%;" />

668
Docker进阶.md Normal file
View File

@ -0,0 +1,668 @@
<h1><center>Docker进阶</center></h1>
**作者：行癫（盗版必究）**
------
## 一：深入理解容器
#### 1.Docker的镜像和容器的区别
###### Docker镜像：
​ 假设Linux内核是第0层，那么无论怎么运行Docker，它都是运行于内核层之上的。这个Docker镜像，是一个只读的镜像，位于第1层，它不能被修改或不能保存状态
​ 一个Docker镜像可以构建于另一个Docker镜像之上，这种层叠关系可以是多层的。第1层的镜像层我们称之为基础镜像（Base Image），其他层的镜像（除了最顶层）我们称之为父层镜像（Parent Image）。这些镜像继承了他们的父层镜像的所有属性和设置，并在Dockerfile中添加了自己的配置
​ 要列出本地所有有效的镜像，可以使用命令
```shell
[root@xingdian ~]# docker images
```
###### Docker容器：
​ Docker容器可以使用命令创建：
```shell
[root@xingdian ~]# docker run imagename
```
​ 它会在所有的镜像层之上增加一个可写层。这个可写层有运行在CPU上的进程，而且有两个不同的状态：
​ 运行态（Running）和退出态 （Exited）
​ 这就是Docker容器。当我们使用docker run启动容器，Docker容器就进入运行态，当我们停止Docker容器时，它就进入退出态。当我们有一个正在运行的Docker容器时，从运行态到停止态，我们对它所做的一切变更都会永久地写到容器的文件系统中。要切记，对容器的变更是写入到容器的文件系统的，而不是写入到Docker镜像中的。我们可以用同一个镜像启动多个Docker容器，这些容器启动后都是活动的，彼此还是相互隔离的。我们对其中一个容器所做的变更只会局限于那个容器本身。如果对容器的底层镜像进行修改，那么当前正在运行的容器是不受影响的，不会发生自动更新现象
​ 64字符的十六进制的字符串来定义容器ID，它是容器的唯一标识符。容器之间的交互是依靠容器ID识别的，由于容器ID的字符太长，我们通常只需键入容器ID的前4个字符即可。当然，我们还可以使用容器名
#### 2.容器名称
​ --name= Assign a name to the container
​ --为容器分配一个名字，如果没有指定，会自动分配一个随机名称
​ --docker run子命令的参数
###### 容器命名方式
​ 使用UUID长命名（"f78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778"）
​ 使用UUID短命令（"f78375b1c487"）
​ 使用Name("xingdian")
注意：
​ 这个UUID标识是由Docker deamon生成的
​ 如果你在执行docker run时没有指定--name，那么deamon会自动生成一个随机字符串UUID
​ 但是对于一个容器来说有个name会非常方便，当你需要连接其它容器时或者类似需要区分其它容器时，使用容器名称可以简化操作。无论容器运行在前台或者后台，这个名字都是有效的
​ 如果在使用Docker时有自动化的需求，你可以将containerID输出到指定的文件中（PIDfile）类似于某些应用程序将自身ID输出到文件中，方便后续脚本操作
```shell
--cidfile="": Write the container ID to the file
```
#### 3.镜像名称
​ 镜像是Docker最核心的技术之一，也是应用发布的标准格式。无论你是用docker pull image，或者是在Dockerfile里面写FROM image，下载镜像应该是Docker操作里面最频繁的动作之一
​ 下面是在本地机器运行docker images的输出结果：
​ ![img](https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/Cs3aazbF6VPifePJoVHd0g.png)
​ 常说的"ubuntu"镜像其实不是一个镜像名称，而是代表了一个名为ubuntu的Repository，同时在这个Repository下面有一系列打了tag的Image，Image的标记是一个GUID，为了方便也可以通过Repository:tag来引用
​ 那么Registry又是什么呢？Registry存储镜像数据，并且提供拉取和上传镜像的功能
​ Registry中镜像是通过Repository来组织的，而每个Repository又包含了若干个Image
​ Registry包含一个或多个Repository
​ Repository包含一个或多个Image
​ Image用GUID表示，有一个或多个Tag与之关联
注意：
​ 当一个镜像的名称不足以分辨这个镜像所代表的含义时，你可以通过tag将版本信息添加到run命令中，以执行特定版本的镜像
```shell
[root@xingdian ~]# docker run ubuntu:14.04
```
#### 4.名字空间
​ namespace 空间隔离
​ cgroup 资源限制
​ rootfs 文件系统
​ 名字空间是 Linux 内核一个强大的特性。每个容器都有自己单独的名字空间，运行在其中的应用都像是在独立的操作系统中运行一样。名字空间保证了容器之间彼此互不影响
###### pid 名字空间
​ 不同用户的进程就是通过 pid 名字空间隔离开的，且不同名字空间中可以有相同 pid
###### net 名字空间
​ 有了pid名字空间, 每个名字空间中的 pid 能够相互隔离，但是网络端口还是共享 host 的端口。网络隔离是通过 net 名字空间实现的，每个 net 名字空间有独立的 网络设备, IP 地址, 路由表, /proc/net 目录。这样每个容器的网络就能隔离开来
###### mnt名字空间
​ 类似 chroot，将一个进程放到一个特定的目录执行。mnt 名字空间允许不同名字空间的进程看到的文件结构不同，这样每个名字空间 中的进程所看到的文件目录就被隔离开了
###### uts 名字空间
​ UTS("UNIX Time-sharing System") 名字空间允许每个容器拥有独立的 hostname 和 domain name, 使其在网络上可以被视作一个独立的节点而非主机上的一个进程
###### user 名字空间
​ 每个容器可以有不同的用户和组 id, 也就是说可以在容器内用容器内部的用户执行程序而非主机上的用户
## 二：Docker资源限制
​ 虽然容器内的第 1 号进程在“障眼法”的干扰下只能看到容器里的情况，但是宿主机上，它作为第 100 号进程与其他所有进程之间依然是平等的竞争关系。这就意味着，虽然第 100 号进程表面上被隔离了起来，但是它所能够使用到的资源（比如 CPU、内存），却是可以随时被宿主机上的其他进程（或者其他容器）占用的。当然，这个 100 号进程自己也可能把所有资源吃光
​ Linux Cgroups 就是 Linux 内核中用来为进程设置资源限制的一个重要功能
​ Linux Cgroups 的全称是 Linux Control Group。
​ 它最主要的作用，就是限制一个进程组能够使用的资源上限，包括 CPU、内存、磁盘、网络带宽等等
​ Cgroups 还能够对进程进行优先级设置、审计，以及将进程挂起和恢复等操作
#### 1.系统压力测试工具
​ stress是一个linux下的压力测试工具，专门为那些想要测试自己的系统，完全高负荷和监督这些设备运行的用户
安装：
```shell
[root@xingdian ~]# yum install stress -y
```
测试场景举例：
```shell
测试CPU负荷
[root@xingdian ~]# stress –c 4
增加4个cpu进程，处理sqrt()函数函数，以提高系统CPU负荷
内存测试
[root@xingdian ~]# stress –i 4 --vm 10 --vm-bytes 1G --vm-hang 100 --timeout 100s
新增4个io进程，10个内存分配进程，每次分配大小1G，分配后不释放，测试100S
磁盘I/O测试
# stress –d 1 --hdd-bytes 3G
新增1个写进程，每次写3G文件块
硬盘测试（不删除）
# stress -i 1 -d 10 --hdd-bytes 3G –hdd-noclean
新增1个IO进程，10个写进程，每次写入3G文件块，且不清除，会逐步将硬盘耗尽。
```
stress各主用参数说明：
```shell
--help 显示帮助信息
--version 显示软件版本信息
-t secs:
--timeout secs指定运行多少秒
-c forks:
--cpu forks 产生多个处理sqrt()函数的CPU进程
-m forks
--vm forks:产生多个处理malloc()内存分配函数的进程，后接进程数量
-i forks
--io forks:产生多个处理sync()函数的磁盘I/O进程
--vm-bytes bytes：指定内存的byte数，默认值是1
--vm-hang:表示malloc分配的内存多少时间后在free()释放掉
-d :
--hdd:写进程，写入固定大小，通过mkstemp()函数写入当前目录
--hdd-bytes bytes:指定写的byte数，默认1G
--hdd-noclean:不要将写入随机ascii数据的文件unlink，则写入的文件不删除，会保留在硬盘空间。
```
#### 2.限制CPU share
​ CPU 资源：
​ 主机上的进程会通过时间分片机制使用 CPU，CPU 的量化单位是频率，也就是每秒钟能执行的运算次数。为容器限制 CPU 资源并不能改变 CPU 的运行频率，而是改变每个容器能使用的 CPU 时间片。理想状态下，CPU 应该一直处于运算状态（并且进程需要的计算量不会超过 CPU 的处理能力）
​ Docker 限制 CPU Share：
​ docker 允许用户为每个容器设置一个数字，代表容器的 CPU share，默认情况下每个容器的 share 是 1024。这个 share 是相对的，本身并不能代表任何确定的意义。当主机上有多个容器运行时，每个容器占用的 CPU 时间比例为它的 share 在总额中的比例。docker 会根据主机上运行的容器和进程动态调整每个容器使用 CPU 的时间比例
​ 例子：
​ 如果主机上有两个一直使用 CPU 的容器（为了简化理解，不考虑主机上其他进程），其 CPU share 都是 1024，那么两个容器 CPU 使用率都是 50%；如果把其中一个容器的 share 设置为 512，那么两者 CPU 的使用率分别为 67% 和 33%；如果删除 share 为 1024 的容器，剩下来容器的 CPU 使用率将会是 100%
​ 好处：
​ 能保证 CPU 尽可能处于运行状态，充分利用 CPU 资源，而且保证所有容器的相对公平
​ 缺点：
​ 无法指定容器使用 CPU 的确定值
​ 设置 CPU share 的参数：
​ -c --cpu-shares，它的值是一个整数
​ 我的机器是 4 核 CPU，因此运行一个stress容器,使用 stress 启动 4 个进程来产生计算压力：
```shell
# docker pull progrium/stress
# yum install htop -y
# docker run --rm -it progrium/stress --cpu 4
stress: info: [1] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd
stress: dbug: [1] using backoff sleep of 12000us
stress: dbug: [1] --> hogcpu worker 4 [7] forked
stress: dbug: [1] using backoff sleep of 9000us
stress: dbug: [1] --> hogcpu worker 3 [8] forked
stress: dbug: [1] using backoff sleep of 6000us
stress: dbug: [1] --> hogcpu worker 2 [9] forked
stress: dbug: [1] using backoff sleep of 3000us
stress: dbug: [1] --> hogcpu worker 1 [10] forked
```
​ 在另外一个 terminal 使用 htop 查看资源的使用情况：
![img](https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/7n18fo_pTFNkVJh7YB_Y0g.png)
​ 上图中看到，CPU 四个核资源都达到了 100%。四个 stress 进程 CPU 使用率没有达到 100% 是因为系统中还有其他机器在运行
​ 为了比较，另外启动一个 share 为 512 的容器
```shell
# docker run --rm -it -c 512 progrium/stress --cpu 4
stress: info: [1] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd
stress: dbug: [1] using backoff sleep of 12000us
stress: dbug: [1] --> hogcpu worker 4 [6] forked
stress: dbug: [1] using backoff sleep of 9000us
stress: dbug: [1] --> hogcpu worker 3 [7] forked
stress: dbug: [1] using backoff sleep of 6000us
stress: dbug: [1] --> hogcpu worker 2 [8] forked
stress: dbug: [1] using backoff sleep of 3000us
stress: dbug: [1] --> hogcpu worker 1 [9] forked
```
​ 因为默认情况下，容器的 CPU share 为 1024，所以这两个容器的 CPU 使用率应该大致为 2：1，下面是启动第二个容器之后的监控截图：
![img](https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/Ja6pTPxoymBhtTRmjhbrRQ.png)
​ 两个容器分别启动了四个 stress 进程，第一个容器 stress 进程 CPU 使用率都在 54% 左右，第二个容器 stress 进程 CPU 使用率在 25% 左右，比例关系大致为 2：1，符合之前的预期
#### 3.限制容器能使用的 CPU 核数
​ -c --cpu-shares 参数只能限制容器使用 CPU 的比例，或者说优先级，无法确定地限制容器使用 CPU 的具体核数；从 1.13 版本之后，docker 提供了 --cpus 参数可以限定容器能使用的 CPU 核数。这个功能可以让我们更精确地设置容器 CPU 使用量，是一种更容易理解也因此更常用的手段
--cpus 后面跟着一个浮点数，代表容器最多使用的核数，可以精确到小数点二位，也就是说容器最小可以使用 0.01 核 CPU
​ 限制容器只能使用 1.5 核数 CPU
```shell
# docker run --rm -it --cpus 1.5 progrium/stress --cpu 3
stress: info: [1] dispatching hogs: 3 cpu, 0 io, 0 vm, 0 hdd
stress: dbug: [1] using backoff sleep of 9000us
stress: dbug: [1] --> hogcpu worker 3 [7] forked
stress: dbug: [1] using backoff sleep of 6000us
stress: dbug: [1] --> hogcpu worker 2 [8] forked
stress: dbug: [1] using backoff sleep of 3000us
stress: dbug: [1] --> hogcpu worker 1 [9] forked
```
​ 在容器里启动三个 stress 来跑 CPU 压力，如果不加限制，这个容器会导致 CPU 的使用率为 300% 左右（也就是说会占用三个核的计算能力）。实际的监控如下图：
![img](https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/9UmN9NvD1JFTwHY4DGL1mA.png)
​ 可以看到，每个 stress 进程 CPU 使用率大约在 50%，总共的使用率为 150%，符合 1.5 核的设置
​ 如果设置的 --cpus 值大于主机的 CPU 核数，docker 会直接报错：
```shell
# docker run --rm -it --cpus 8 progrium/stress --cpu 3
docker: Error response from daemon: Range of CPUs is from 0.01 to 4.00, as there are only 4 CPUs available.
See 'docker run --help'.
```
​ 如果多个容器都设置了 --cpus ，并且它们之和超过主机的 CPU 核数，并不会导致容器失败或者退出，这些容器之间会竞争使用 CPU，具体分配的 CPU 数量取决于主机运行情况和容器的 CPU share 值。也就是说 --cpus 只能保证在 CPU 资源充足的情况下容器最多能使用的 CPU 数，docker 并不能保证在任何情况下容器都能使用这么多的 CPU（因为这根本是不可能的）
#### 4.内存资源
​ 默认情况下，docker 并没有对容器内存进行限制，也就是说容器可以使用主机提供的所有内存。这当然是非常危险的事情，如果某个容器运行了恶意的内存消耗软件，或者代码有内存泄露，很可能会导致主机内存耗尽，因此导致服务不可用。对于这种情况，docker 会设置 docker daemon 的 OOM（out of memory） 值，使其在内存不足的时候被杀死的优先级降低。另外，就是你可以为每个容器设置内存使用的上限，一旦超过这个上限，容器会被杀死，而不是耗尽主机的内存
​ 限制内存上限虽然能保护主机，但是也可能会伤害到容器里的服务。如果为服务设置的内存上限太小，会导致服务还在正常工作的时候就被 OOM 杀死；如果设置的过大，会因为调度器算法浪费内存。因此，合理的做法包括
​ 为应用做内存压力测试，理解正常业务需求下使用的内存情况，然后才能进入生产环境使用，一定要限制容器的内存使用上限，尽量保证主机的资源充足，一旦通过监控发现资源不足，就进行扩容或者对容器进行迁移，如果可以（内存资源充足的情况），尽量不要使用 swap，swap 的使用会导致内存计算复杂，对调度器非常不友好
###### Docker 限制容器内存使用量：
​ 在 docker 启动参数中，和内存限制有关的包括（参数的值一般是内存大小，也就是一个正数，后面跟着内存单位 b、k、m、g，分别对应 bytes、KB、MB、和 GB）：
```shell
-m --memory：容器能使用的最大内存大小，最小值为 4m
--memory-swap：容器能够使用的 swap 大小
--memory-swappiness：默认情况下，主机可以把容器使用的匿名页（anonymous page）swap 出来，你可以设置一个 0-100 之间的值，代表允许 swap 出来的比例
--memory-reservation：设置一个内存使用的 soft limit(软限制)，如果 docker 发现主机内存不足，会执行 OOM 操作。这个值必须小于 --memory 设置的值
--kernel-memory：容器能够使用的 kernel memory (内核内存)大小，最小值为 4m。
--oom-kill-disable：是否运行 OOM 的时候杀死容器。只有设置了 -m，才可以把这个选项设置为 false(假)，否则容器会耗尽主机内存，而且导致主机应用被杀死
```
​ 关于 --memory-swap 的设置： --memory-swap 必须在 --memory 也配置的情况下才能有用
​ 如果 --memory-swap 的值大于 --memory，那么容器能使用的总内存（内存 + swap）为 --memory-swap 的值，能使用的 swap 值为 --memory-swap 减去 --memory 的值
​ 如果 --memory-swap 为 0，或者和 --memory 的值相同，那么容器能使用两倍于内存的 swap 大小，如果 --memory 对应的值是 200M，那么容器可以使用 400M swap
​ 如果 --memory-swap 的值为 -1，那么不限制 swap 的使用，也就是说主机有多少 swap，容器都可以使用
​ 如果限制容器的内存使用为 64M，在申请 64M 资源的情况下，容器运行正常（如果主机上内存非常紧张，并不一定能保证这一点）
```shell
# docker run --rm -it -m 64m progrium/stress --vm 1 --vm-bytes 64M --vm-hang 0
WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap.
stress: info: [1] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
stress: dbug: [1] using backoff sleep of 3000us
stress: dbug: [1] --> hogvm worker 1 [7] forked
stress: dbug: [7] allocating 67108864 bytes ...
stress: dbug: [7] touching bytes in strides of 4096 bytes ...
stress: dbug: [7] sleeping forever with allocated memory
.....
```
​ 而如果申请 100M 内存，会发现容器里的进程被 kill 掉了（worker 7 got signal 9，signal 9 就是 kill 信号）
```shell
# docker run --rm -it -m 64m progrium/stress --vm 1 --vm-bytes 100M --vm-hang 0
WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap.
stress: info: [1] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
stress: dbug: [1] using backoff sleep of 3000us
stress: dbug: [1] --> hogvm worker 1 [7] forked
stress: dbug: [7] allocating 104857600 bytes ...
stress: dbug: [7] touching bytes in strides of 4096 bytes ...
stress: FAIL: [1] (415) &lt;-- worker 7 got signal 9
stress: WARN: [1] (417) now reaping child worker processes
stress: FAIL: [1] (421) kill error: No such process
stress: FAIL: [1] (451) failed run completed in 0s
```
#### 5.IO资源
​ 对于磁盘来说，考量的参数是容量和读写速度，因此对容器的磁盘限制也应该从这两个维度出发。目前 docker 支持对磁盘的读写速度进行限制，但是并没有方法能限制容器能使用的磁盘容量（一旦磁盘 mount 到容器里，容器就能够使用磁盘的所有容量）
​ 限制磁盘的读写速率，docker 允许你直接限制磁盘的读写速率，对应的参数有：
​ --device-read-bps：磁盘每秒最多可以读多少比特（bytes）
​ --device-write-bps：磁盘每秒最多可以写多少比特（bytes）
​ 上面两个参数的值都是磁盘以及对应的速率，限制 limit 为正整数，单位可以是 kb、mb 和 gb
比如可以把设备的读速率限制在 1mb：
```shell
# docker run -it --device /dev/sda:/dev/sda --device-read-bps /dev/sda:1mb ubuntu:16.04 bash
root@6c048edef769:/# cat /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device
8:0 1048576
root@6c048edef769:/# dd iflag=direct,nonblock if=/dev/sda of=/dev/null bs=5M count=10
10+0 records in
10+0 records out
52428800 bytes (52 MB) copied, 50.0154 s, 1.0 MB/s
```
​ 从磁盘中读取 50m 花费了 50s 左右，说明磁盘速率限制起了作用
​ 另外两个参数可以限制磁盘读写频率（每秒能执行多少次读写操作）：
​ --device-read-iops：磁盘每秒最多可以执行多少 IO 读操作
​ --device-write-iops：磁盘每秒最多可以执行多少 IO 写操作
​ 上面两个参数的值都是磁盘以及对应的 IO 上限
比如，可以让磁盘每秒最多读 100 次：
```shell
# docker run -it --device /dev/sda:/dev/sda --device-read-iops /dev/sda:100 ubuntu:16.04 bash
root@2e3026e9ccd2:/# dd iflag=direct,nonblock if=/dev/sda of=/dev/null bs=1k count=1000
1000+0 records in
1000+0 records out
1024000 bytes (1.0 MB) copied, 9.9159 s, 103 kB/s
```
​ 从测试中可以看出，容器设置了读操作的 iops 为 100，在容器内部从 block 中读取 1m 数据（每次 1k，一共要读 1000 次），共计耗时约 10s，换算起来就是 100
总结：
​ Linux Cgroups 的设计还是比较易用的，简单粗暴地理解呢，它就是一个子系统目录加上一组资源限制文件的组合
## 三：理解容器文件系统
​ Namespace 的作用是"隔离"，它让应用进程只能看到该 Namespace 内的"世界"；而 Cgroups 的作用是"限制"，它给这个"世界"围上了一圈看不见的墙。这么一折腾，进程就真的被"装"在了一个与世隔绝的房间里，而这些房间就是 PaaS 项目赖以生存的应用"沙盒"
​ 可是，还有一个问题：这个房间四周虽然有了墙，但是如果容器进程低头一看地面，又是怎样一副景象呢？
​ 换句话说，容器里的进程看到的文件系统又是什么样子的呢？
​ 可能你立刻就能想到，这一定是一个关于 Mount Namespace 的问题：容器里的应用进程，理应看到一份完全独立的文件系统。这样，它就可以在自己的容器目录（比如 /tmp）下进行操作，而完全不会受宿主机以及其他容器的影响
​ 那么，真实情况是这样吗？
​ 一段小程序：作用是，在创建子进程时开启指定的 Namespace。使用它来验证一下刚刚提到的问题
```shell
#define _GNU_SOURCE
#include <sys/mount.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <stdio.h>
#include <sched.h>
#include <signal.h>
#include <unistd.h>
#define STACK_SIZE (1024 * 1024)
static char container_stack[STACK_SIZE];
char* const container_args[] = {
"/bin/bash",
NULL
};
int container_main(void* arg)
{
printf("Container - inside the container!\n");
execv(container_args[0], container_args);
printf("Something's wrong!\n");
return 1;
}
int main()
{
printf("Parent - start a container!\n");
int container_pid = clone(container_main, container_stack+STACK_SIZE, CLONE_NEWNS | SIGCHLD , NULL);
waitpid(container_pid, NULL, 0);
printf("Parent - container stopped!\n");
return 0;
}
```
​ 代码功能非常简单：在 main 函数里，通过 clone() 系统调用创建了一个新的子进程 container_main，并且声明要为它启用 Mount Namespace（即：CLONE_NEWNS 标志）
​ 而这个子进程执行的，是一个"/bin/bash"程序，也就是一个 shell。所以这个 shell 就运行在了 Mount Namespace 的隔离环境中
​ 编译一下这个程序：
```shell
[root@xingdian ~]# gcc -o ns ns.c
[root@xingdian ~]# ./ns
Parent - start a container!
Container - inside the container!
```
​ 这样，就进入了这个"容器"当中（表面上看不大出来-xingdian注）。可是，如果在"容器"里执行一下 ls 指令的话，就会发现一个有趣的现象： /tmp 目录下的内容跟宿主机的内容是一样的
```shell
[root@xingdian ~]# ls /tmp
# 你会看到好多宿主机的文件
```
​ 也就是说：即使开启了 Mount Namespace，容器进程看到的文件系统也跟宿主机完全一样
​ 这是怎么回事呢？
​ 仔细思考一下，你会发现这其实并不难理解：Mount Namespace 修改的，是容器进程对文件系统"挂载点"的认知。但是，这也就意味着，只有在"挂载"这个操作发生之后，进程的视图才会被改变。而在此之前，新创建的容器会直接继承宿主机的各个挂载点
​ 这时，你可能已经想到了一个解决办法：创建新进程时，除了声明要启用 Mount Namespace 之外，还可以告诉容器进程，有哪些目录需要重新挂载，就比如这个 /tmp 目录。于是，在容器进程执行前可以添加一步重新挂载 /tmp 目录的操作：
```shell
int container_main(void* arg)
{
printf("Container - inside the container!\n");
// 如果你的机器的根目录的挂载类型是 shared，那必须先重新挂载根目录
// mount("", "/", NULL, MS_PRIVATE, "");
mount("none", "/tmp", "tmpfs", 0, "");
execv(container_args[0], container_args);
printf("Something's wrong!\n");
return 1;
}
```
​ 在修改后的代码里，在容器进程启动之前，加上了一句 mount("none", "/tmp", "tmpfs", 0, "") 语句。就这样，告诉了容器以 tmpfs（内存盘）格式，重int container_main(void* arg)
```shell
{
printf("Container - inside the container!\n");
execv(container_args[0], container_args);
printf("Something's wrong!\n");
return 1;
}新挂载了 /tmp 目录。
```
​ 编译执行修改后的代码结果又如何呢？试验一下：
```shell
[root@xingdian ~]# gcc -o ns ns.c
[root@xingdian ~]# ./ns
Parent - start a container!
Container - inside the container!
[root@xingdian ~]# ls /tmp
这次 /tmp 变成了一个空目录，这意味着重新挂载生效了。
用 mount -l 检查：
[root@xingdian ~]# mount -l | grep tmpfs
none on /tmp type tmpfs (rw,relatime)
```
​ 容器里的 /tmp 目录是以 tmpfs 方式单独挂载的。可以卸载一下/tmp目录看看效果
​ 更重要的是，因为创建的新进程启用了 Mount Namespace，所以这次重新挂载的操作，只在容器进程的 Mount Namespace 中有效。如果在宿主机上用 mount -l 来检查一下这个挂载，你会发现它是不存在的：
​ 在宿主机上
```shell
[root@xingdian ~]# mount -l | grep tmpfs
```
![img](https://xingdian-image.oss-cn-beijing.aliyuncs.com/xingdian-image/GDC-shjNkp1Xrs3PUgEjRw.png)
​ 这就是 Mount Namespace 跟其他 Namespace 的使用略有不同的地方：它对容器进程视图的改变，一定是伴随着挂载操作（mount）才能生效
​ 我们希望的是：每当创建一个新容器时，我希望容器进程看到的文件系统就是一个独立的隔离环境，而不是继承自宿主机的文件系统。怎么才能做到这一点呢？
​ 可以在容器进程启动之前重新挂载它的整个根目录"/"。而由于 Mount Namespace 的存在，这个挂载对宿主机不可见，所以容器进程就可以在里面随便折腾了
​ 在 Linux 操作系统里，有一个名为 chroot 的命令可以帮助你在 shell 中方便地完成这个工作。顾名思义，它的作用就是帮你"change root file system"，即改变进程的根目录到你指定的位置
​ 假设，现在有一个 /home/xingdian/test 目录，想要把它作为一个 /bin/bash 进程的根目录
​ 首先，创建一个 test 目录和几个 lib 文件夹：
```shell
[root@xingdian ~]# mkdir -p /home/xingdian/test
[root@xingdian ~]# mkdir -p /home/xingdian/test/{bin,lib64,lib}
然后，把 bash 命令拷贝到 test 目录对应的 bin 路径下：
# cp -v /bin/{bash,ls} /home/xingdian/test/bin
```
​ 接下来，把 ls和bash命令需要的所有 so 文件，也拷贝到 test 目录对应的 lib 路径下。找到 so 文件可以用 ldd 命令：（ldd　列出动态依赖库）
```shell
[root@xingdian ~]# list="$(ldd /bin/ls | egrep -o '/lib.*\.[0-9]')"
[root@xingdian ~]# for i in $list; do cp -v "$i" "/home/xingdian/test/${i}"; done
[root@xingdian ~]# list="$(ldd /bin/bash | egrep -o '/lib.*\.[0-9]')"
[root@xingdian ~]# for i in $list; do cp -v "$i" "/home/xingdian/test/${i}"; done
```
​ 最后，执行 chroot 命令，告诉操作系统，将使用 /home/xingdian/test 目录作为 /bin/bash 进程的根目录：
```shell
[root@xingdian ~]# chroot /home/xingdian/test /bin/bash
```
​ 这时，执行 "ls /"，就会看到，它返回的都是 /home/xingdian/test 目录下面的内容，而不是宿主机的内容
​ 更重要的是，对于被 chroot 的进程来说，它并不会感受到自己的根目录已经被"修改"成 /home/xingdian/test 了
​ 这种视图被修改的原理，是不是跟我之前介绍的 Linux Namespace 很类似呢
​ 实际上，Mount Namespace 正是基于对 chroot 的不断改良才被发明出来的，它也是 Linux 操作系统里的第一个 Namespace
​ 为了能够让容器的这个根目录看起来更"真实"，一般会在这个容器的根目录下挂载一个完整操作系统的文件系统，比如 Ubuntu16.04 的 ISO。这样，在容器启动之后，在容器里通过执行 "ls /" 查看根目录下的内容，就是 Ubuntu 16.04 的所有目录和文件
​ 而这个挂载在容器根目录上、用来为容器进程提供隔离后执行环境的文件系统，就是所谓的"容器镜像"。它还有一个更为专业的名字，叫作：rootfs（根文件系统）
​ 所以，一个最常见的 rootfs，或者说容器镜像，会包括如下所示的一些目录和文件，比如 /bin，/etc，/proc 等等
```shell
[root@xingdian ~]# ls /
bin dev etc home lib lib64 mnt opt proc root run sbin sys tmp usr var
```
​ 而进入容器之后执行的 /bin/bash，就是 /bin 目录下的可执行文件，与宿主机的 /bin/bash 完全不同
​ 所以，对 Docker 项目来说，它最核心的原理实际上就是为待创建的用户进程：
​ 启用 Linux Namespace 配置
​ 设置指定的 Cgroups 参数
​ 切换进程的根目录（Change Root）
​ 这样，一个完整的容器就诞生了。不过，Docker 项目在最后一步的切换上会优先使用 pivot_root 系统调用，如果系统不支持，才会使用 chroot。这两个系统调用功能类似
​ rootfs 只是一个操作系统所包含的文件、配置和目录，并不包括操作系统内核，同一台机器上的所有容器，都共享宿主机操作系统的内核。如果你的应用程序需要配置内核参数、加载额外的内核模块，以及跟内核进行直接的交互，你就需要注意了：这些操作和依赖的对象，都是宿主机操作系统的内核，它对于该机器上的所有容器来说是一个"全局变量"，牵一发而动全身
​ 在 Linux 操作系统中，这两部分是分开存放的，操作系统只有在开机启动时才会加载指定版本的内核镜像
​ 这是容器相比于虚拟机的缺陷之一：虚拟机不仅有模拟出来的硬件机器充当沙盒，而且每个沙盒里还运行着一个完整的 Guest OS 给应用随便用
容器的一致性 ：
​ 由于云端与本地服务器环境不同，应用的打包过程，一直是使用 PaaS 时最"痛苦"的一个步骤
​ 但有了容器镜像（即 rootfs）之后，这个问题被解决了
​ 由于 rootfs 里打包的不只是应用，而是整个操作系统的文件和目录，也就意味着，应用以及它运行所需要的所有依赖，都被封装在了一起
​ 对于大多数开发者而言，他们对应用依赖的理解，一直局限在编程语言层面。比如 Golang 的 Godeps.json。但实际上，一个一直以来很容易被忽视的事实是，对一个应用来说，操作系统本身才是它运行所需要的最完整的"依赖库"
​ 有了容器镜像"打包操作系统"的能力，这个最基础的依赖环境也终于变成了应用沙盒的一部分。这就赋予了容器所谓的一致性：无论在本地、云端，还是在一台任何地方的机器上，用户只需要解压打包好的容器镜像，那么这个应用运行所需要的完整的执行环境就被重现出来了
​ 这种深入到操作系统级别的运行环境一致性，打通了应用在本地开发和远端执行环境之间难以逾越的鸿沟
联合文件系统：Union File System 也叫 UnionFS：
​ Docker 公司在实现 Docker 镜像时并没有沿用以前制作 rootfs 的标准流程，做了一个创新：
​ Docker 在镜像的设计中，引入了层（layer）的概念。也就是说，用户制作镜像的每一步操作，都会生成一个层，也就是一个增量 rootfs。用到了一种叫作联合文件系统（Union File System）的能力
​ 主要的功能是将多个不同位置的目录联合挂载（union mount）到同一个目录下
​ 比如，现在有两个目录 A 和 B，它们分别有两个文件：
```shell
[root@xingdian ~]# tree
├── A
│ ├── a
│ └── x
└── B
├── b
└── x
```
​ 然后，使用联合挂载的方式，将这两个目录挂载到一个公共的目录 C 上：
```shell
[root@xingdian ~]# mkdir C
[root@xingdian ~]# yum install funionfs -y //我这里用的是centos7自带的联合文件系统，效果一样
[root@xingdian ~]# funionfs -o dirs=./A:./B none ./C
```
​ 再查看目录 C 的内容，就能看到目录 A 和 B 下的文件被合并到了一起：
```shell
[root@xingdian ~]# tree ./C
./C
├── a
├── b
└── x
```
​ 可以看到，在这个合并后的目录 C 里，有 a、b、x 三个文件，并且 x 文件只有一份。这，就是"合并"的含义
​ 此外，如果在目录 C 里对 a、b、x 文件做修改，这些修改也会在对应的目录 A、B 中生效
```shell
[root@xingdian ~]# echo hello >> C/a
[root@xingdian ~]# cat C/a
hello
[root@xingdian ~]# cat A/a
hello
[root@xingdian ~]# echo hello1 >> A/a
[root@xingdian ~]# cat A/a
hello
hello1
[root@xingdian ~]# cat C/a
hello
hello1
```