如何通过DOCKER OVERLAY2目录名查找容器名和容器ID

du -s ./* | sort -rn | more

 docker ps -q | xargs docker inspect --format '{{.State.Pid}}, {{.Id}}, {{.Name}}, {{.GraphDriver.Data.WorkDir}}' | grep bff25099a59b0fc8addd06f9223872f2904256f0432b3c3c47b58faef167115f

// 查看docker版本信息
docker version

// 搜索可用的镜像
docker search mysql

//拉取镜像-默认是拉取的最新版本
docker pull mysql

//拉取镜像-特定版本拉取(版本号一定要是官方放出的版本号，否则是查找不到的)
docker pull mysql:8.0.22

// 列举本机所有镜像
docker images -a

// 列出镜像结果，并且只包含镜像ID和仓库名
docker images --format "{{.ID}}: {{.Repository}}"

// 删除镜像('xxx'可以为镜像id或镜像REPOSITORY)
docker rmi xxx

// 保存对容器的修改（如安装了ping）
参见https://www.docker.org.cn/book/docker/docer-save-changes-10.html
查看被修改的容器 ：docker ps -l
提交指定容器保存为新的镜像： docker commit <container id> <new image name>

// 查看容器详细信息
docker inspect xxx

// 查看所有容器
docker ps -a  
[or]
docker container ls -a

// 查看运行中的容器
docker ps

// 删除指定容器（Docker 会发送 SIGKILL 信号给容器。 加-f是删除处于运行中的容器）
docker rm -f xxx

// 查看docker容器日志
docker logs xxx

// 新建并启动容器
docker run

// docker run命令实用参数举例
-d 让docker处于后台运行
-P 容器内部端口随机映射到主机的端口
-p 容器内部端口绑定到主机指定的端口（使用：docker run -d -p <主机端口>:<容器端口> ...）
--name 给容器起别名（使用：docker run -d -P --name <容器别名> <镜像>）
-it 进入交互式终端（这是两个参数，一个是 -i 交互式操作，一个是 -t 终端。通常还会在镜像名后跟一个命令，如我们希望有个交互式 Shell，因此在镜像后会跟一个 bash）
--rm 这个参数是说容器退出后随之将其删除。
-v 添加数据卷（-v /my/own/datadir:/var/lib/mysql /my/own/datadir是主机的数据库路径 /var/lib/mysql是容器中的数据库路径）


// 查看指定容器的启动命令
docker ps -a --no-trunc | grep xxx
[or]
在docker inspect的Path参数也可见

// 查看容器端口绑定情况
docker port xxx

// 查看docker网络
docker network ls

// 创建网络
docker network create -d bridge test-net
(说明：-d用于指定docker网络类型，分为bridge、overlay)

// 连接容器(运行一个容器并连接到新建的 test-net 网络)
docker run -itd --name test1 --network test-net ubuntu /bin/bash
docker run -itd --name test2 --network test-net ubuntu /bin/bash
(而后，test1、test2容器间便可以互相ping通了)


// 进入容器后，若发现有的命令不支持，如：ping www.baidu.com，提示：`bash: ping: command not found`
// 这时就需要手动安装对应命令了。但执行apt-get install ping时，又提示：`E: Unable to locate package ping`
// 解决方式：先执行apt-get update，再执行apt-get install ping即可


// 构建镜像
docker build -t xxx .

** Q：docker优势 **

1、更高效的利用系统资源
由于容器不需要进行硬件虚拟以及运行完整操作系统等额外开销，Docker 对系统资源的利用率更高。
无论是应用执行速度、内存损耗或者文件存储速度，都要比传统虚拟机技术更高效。
因此，相比虚拟机技术，一个相同配置的主机，往往可以运行更多数量的应用。

2、更快速的启动时间
Docker容器应用，由于直接运行于宿主内核，无需启动完整的操作系统，
因此可以做到秒级、甚至毫秒级的启动时间。大大的节约了开发、测试、部署的时间。

3、一致的运行环境
开发过程中一个常见的问题是环境一致性问题。
由于开发环境、测试环境、生产环境不一致，导致有些 bug 并未在开发过程中被发现。
而 Docker 的镜像提供了除内核外完整的运行时环境，确保了应用运行环境一致性，
从而不会再出现 “这段代码在我机器上没问题啊” 这类问题。

4、持续交付和部署
对开发和运维（DevOps）人员来说，最希望的就是一次创建或配置，可以在任意地方正常运行。
使用 Docker 可以通过定制应用镜像来实现持续集成、持续交付、部署。
开发人员可以通过 Dockerfile 来进行镜像构建，并结合 持续集成(Continuous Integration) 系统进行集成测试，
而运维人员则可以直接在生产环境中快速部署该镜像，甚至结合 持续部署(Continuous Delivery/Deployment) 系统进行自动部署。

5、更轻松的迁移
由于 Docker 确保了执行环境的一致性，使得应用的迁移更加容易。
因此用户可以很轻易的将在一个平台上运行的应用，迁移到另一个平台上，而不用担心运行环境的变化导致应用无法正常运行的情况。

6、更轻松的扩展和维护
Docker 使用的分层存储以及镜像的技术，使得应用重复部分的复用更为容易，
也使得应用的维护更新更加简单，基于基础镜像进一步扩展镜像也变得非常简单。

// docker commit 的语法格式为：
docker commit [选项] <容器ID或容器名> [<仓库名>[:<标签>]]
// 举例
$ docker commit \
    --author "Tao Wang <twang2218@gmail.com>" \
    --message "修改了默认网页" \
    webserver \
    nginx:v2
// 查看镜像的历史版本提交信息
docker history nginx:v2

docker build https://github.com/twang2218/gitlab-ce-zh.git#:8.14

docker build http://server/context.tar.gz

// Dockerfile指令详解
- FROM 指定基础镜像
所谓定制镜像，那一定是以一个镜像为基础，在其上进行定制。而 FROM 就是指定基础镜像。
因此一个 Dockerfile 中 FROM 是必备的指令，并且必须是第一条指令。
(Docker 还存在一个特殊的镜像，名为 scratch。这个镜像是虚拟的概念，并不实际存在，它表示一个空白的镜像。因此直接 FROM scratch 会让镜像体积更加小巧。
如果以 scratch 为基础镜像的话，意味着你不以任何镜像为基础，接下来所写的指令将作为镜像第一层开始存在。)

- RUN 执行命令
其格式有两种：
    1. shell 格式：RUN <命令>
    2. exec 格式：RUN ["可执行文件", "参数1", "参数2"]
每一个 RUN 都是启动一个容器、执行命令、然后提交存储层文件变更。
对于有多个命令的情况，建议将命令间用‘&&'连接，避免多层构建镜像。正确示例：
    RUN buildDeps='gcc libc6-dev make' \
        && apt-get update \
        && apt-get install -y $buildDeps

- COPY 复制文件
格式：
    COPY <源路径>... <目标路径>
    COPY ["<源路径1>",... "<目标路径>"]
COPY 指令将从构建上下文目录中 <源路径> 的文件/目录复制到新的一层的镜像内的 <目标路径> 位置。
比如：
    COPY package.json /usr/src/app/
    COPY hom* /mydir/
<源路径> 可以是多个，甚至可以是通配符
<目标路径> 可以是容器内的绝对路径，也可以是相对于工作目录的相对路径（工作目录可以用 WORKDIR 指令来指定）。
    目标路径不需要事先创建，如果目录不存在会在复制文件前先行创建缺失目录。

- ADD 更高级的复制文件
ADD 指令和 COPY 的格式和性质基本一致，但也有所不同。
比如 <源路径> 可以是一个 URL，这种情况下，Docker 引擎会试图去下载这个链接的文件放到 <目标路径> 去。
    下载后的文件权限自动设置为 600，如果这并不是想要的权限，那么还需要增加额外的一层 RUN 进行权限调整；
    另外，如果下载的是个压缩包，需要解压缩，也一样还需要额外的一层 RUN 指令进行解压缩。
    所以不如直接使用 RUN 指令，然后使用 wget 或者 curl 工具下载，处理权限、解压缩、然后清理无用文件更合理。
    因此，这个功能其实并不实用，而且不推荐使用。
如果 <源路径> 为一个 tar 压缩文件的话，压缩格式为 gzip, bzip2 以及 xz 的情况下，ADD 指令将会自动解压缩这个压缩文件到 <目标路径> 去。
在 Docker 官方的最佳实践文档中要求，尽可能的使用 COPY，因为 COPY 的语义很明确，就是复制文件而已，而 ADD 则包含了更复杂的功能，其行为也不一定很清晰。
另外需要注意的是，ADD 指令会令镜像构建缓存失效，从而可能会令镜像构建变得比较缓慢。

- CMD 容器启动命令
CMD 指令的格式和 RUN 相似，也是两种格式：
    shell 格式：CMD <命令>
    exec 格式：CMD ["可执行文件", "参数1", "参数2"...]
Docker不是虚拟机，容器就是进程。既然是进程，那么在启动容器的时候，需要指定所运行的程序及参数。
CMD 指令就是用于指定默认的容器主进程的启动命令的。
在指令格式上，一般推荐使用 exec 格式，这类格式在解析时会被解析为 JSON 数组，因此一定要使用双引号 "，而不要使用单引号。
如果使用 shell 格式的话，实际的命令会被包装为 sh -c 的参数的形式进行执行。比如：
    CMD echo $HOME
    在实际执行中，会将其变更为：
    CMD [ "sh", "-c", "echo $HOME" ]
提到 CMD 就不得不提容器中应用在前台执行和后台执行的问题。
容器中的应用都应该以前台执行，而不是像虚拟机、物理机里面那样，用 upstart/systemd 去启动后台服务，容器内没有后台服务的概念。
对于容器而言，其启动程序就是容器应用进程，容器就是为了主进程而存在的，主进程退出，容器就失去了存在的意义，从而退出，其它辅助进程不是它需要关心的东西。
举例：
    CMD service nginx start
    使用 service nginx start 命令，是希望以后台守护进程形式启动 nginx 服务。
    而刚才说了 CMD service nginx start 会被理解为 CMD [ "sh", "-c", "service nginx start"]，因此主进程实际上是 sh。
    那么当 service nginx start 命令结束后，sh 也就结束了，sh 作为主进程退出了，自然就会令容器退出。
    正确的做法是直接执行 nginx 可执行文件，并且要求以前台形式运行。比如：
        CMD ["nginx", "-g", "daemon off;"]

- ENTRYPOINT 入口点
ENTRYPOINT 的目的和 CMD 一样，都是在指定容器启动程序及参数。ENTRYPOINT 在运行时也可以替代，不过比 CMD 要略显繁琐，需要通过 docker run 的参数 --entrypoint 来指定。
当指定了 ENTRYPOINT 后，CMD 的含义就发生了改变，不再是直接的运行其命令，而是将 CMD 的内容作为参数传给 ENTRYPOINT 指令，换句话说实际执行时，将变为：
<ENTRYPOINT> "<CMD>"
其使用场景及好处参见：https://docs.kilvn.com/docker_practice/image/dockerfile/entrypoint.html

- ENV 设置环境变量
格式有两种：
    ENV <key> <value>
    ENV <key1>=<value1> <key2>=<value2>...
这个指令很简单，就是设置环境变量而已。
环境变量可以使用的地方很多，很强大。通过环境变量，我们可以让一份 Dockerfile 制作更多的镜像，只需使用不同的环境变量即可。

- VOLUME 定义匿名卷
格式为：
    VOLUME ["<路径1>", "<路径2>"...]
    VOLUME <路径>
之前我们说过，容器运行时应该尽量保持容器存储层不发生写操作，对于数据库类需要保存动态数据的应用，其数据库文件应该保存于卷(volume)中。
为了防止运行时用户忘记将动态文件所保存目录挂载为卷，在 Dockerfile 中，我们可以事先指定某些目录挂载为匿名卷，
这样在运行时如果用户不指定挂载，其应用也可以正常运行，不会向容器存储层写入大量数据。
VOLUME /data 这里的 /data 目录就会在运行时自动挂载为匿名卷，任何向 /data 中写入的信息都不会记录进容器存储层，
从而保证了容器存储层的无状态化。当然，运行时可以覆盖这个挂载设置。比如：
    docker run -d -v mydata:/data xxxx
    在这行命令中，就使用了 mydata 这个命名卷挂载到了 /data 这个位置，替代了 Dockerfile 中定义的匿名卷的挂载配置。

- EXPOSE 声明端口
格式为 EXPOSE <端口1> [<端口2>...]
指令是声明运行时容器提供服务端口，这只是一个声明，在运行时并不会因为这个声明应用就会开启这个端口的服务。
在 Dockerfile 中写入这样的声明有两个好处:
    一个是帮助镜像使用者理解这个镜像服务的守护端口，以方便配置映射；
    另一个用处则是在运行时使用随机端口映射时，也就是 docker run -P 时，会自动随机映射 EXPOSE 的端口。

- WORKDIR 指定工作目录
格式为 WORKDIR <工作目录路径>
使用 WORKDIR 指令可以来指定工作目录（或者称为当前目录），以后各层的当前目录就被改为指定的目录，如该目录不存在，WORKDIR 会帮你建立目录。

- USER 指定当前用户
格式：USER <用户名>
USER 指令和 WORKDIR 相似，都是改变环境状态并影响以后的层。
    WORKDIR 是改变工作目录，
    USER 则是改变之后层的执行 RUN, CMD 以及 ENTRYPOINT 这类命令的身份。

- HEALTHCHECK 健康检查
格式：
    HEALTHCHECK [选项] CMD <命令>：设置检查容器健康状况的命令
    HEALTHCHECK NONE：如果基础镜像有健康检查指令，使用这行可以屏蔽掉其健康检查指令
HEALTHCHECK 指令是告诉 Docker 应该如何进行判断容器的状态是否正常，这是 Docker 1.12 引入的新指令。
自 1.12 之后，Docker 提供了 HEALTHCHECK 指令，通过该指令指定一行命令，用这行命令来判断容器主进程的服务状态是否还正常，从而比较真实的反应容器实际状态。
    背景：
        在没有 HEALTHCHECK 指令前，Docker 引擎只可以通过容器内主进程是否退出来判断容器是否状态异常。
        很多情况下这没问题，但是如果程序进入死锁状态，或者死循环状态，应用进程并不退出，但是该容器已经无法提供服务了。
        在 1.12 以前，Docker 不会检测到容器的这种状态，从而不会重新调度，导致可能会有部分容器已经无法提供服务了却还在接受用户请求。
当在一个镜像指定了 HEALTHCHECK 指令后，用其启动容器，初始状态会为 starting，在 HEALTHCHECK 指令检查成功后变为 healthy，如果连续一定次数失败，则会变为 unhealthy。
HEALTHCHECK 支持下列选项：
    --interval=<间隔>：两次健康检查的间隔，默认为 30 秒；
    --timeout=<时长>：健康检查命令运行超时时间，如果超过这个时间，本次健康检查就被视为失败，默认 30 秒；
    --retries=<次数>：当连续失败指定次数后，则将容器状态视为 unhealthy，默认 3 次。
和 CMD, ENTRYPOINT 一样，HEALTHCHECK 只可以出现一次，如果写了多个，只有最后一个生效。
在 HEALTHCHECK [选项] CMD 后面的命令，格式和 ENTRYPOINT 一样，分为 shell 格式，和 exec 格式。
  命令的返回值决定了该次健康检查的成功与否：0：成功；1：失败
举例：
    假设我们有个镜像是个最简单的 Web 服务，我们希望增加健康检查来判断其 Web 服务是否在正常工作，我们可以用 curl 来帮助判断，其 Dockerfile 的 HEALTHCHECK 可以这么写：
    FROM nginx
    RUN apt-get update \
        && apt-get install -y curl \
        && rm -rf /var/lib/apt/lists/*
    HEALTHCHECK --interval=5s --timeout=3s \
        CMD curl -fs http://localhost/ || exit 1
    这里我们设置了每 5 秒检查一次（这里为了试验所以间隔非常短，实际应该相对较长）,
    如果健康检查命令超过 3 秒没响应就视为失败，并且使用 curl -fs http://localhost/ || exit 1 作为健康检查命令。

- ONBUILD 为他人做嫁衣裳
参见：https://docs.kilvn.com/docker_practice/image/dockerfile/onbuild.html

docker save mynginx | gzip > mynginx-latest.tar.gz

docker load -i mynginx-latest.tar.gz

docker save <镜像名> | bzip2 | pv | ssh <用户名>@<主机名> 'cat | docker load'

docker export myubuntu > myubuntu.tar

cat myubuntu.tar | docker import - myubuntu:v1.0