dockercli（dockerclientbuildimages）

本篇文章给大家谈谈dockercli，以及dockerclientbuildimages对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、详解Docker——你需要知道的Docker进阶知识三
• 2、dockerfile使用phpcli模式
• 3、【docker】docker的容器创建与管理过程
• 4、dockerphp-cli如何使用
• 5、Docker Checkpoint/Restore
• 6、Docker和LXC有什么不同

详解Docker——你需要知道的Docker进阶知识三

我们可以将数据保存在容器中，但是这样存在一些缺点：

针对上述的缺点，有些数据，例如数据库文件，我们不应该将其保存在镜像或者容器的可写层中。Docker 提供三种不同的方式将数据从 Docker 主机挂载到容器中，分别为卷（ volumes ），绑定挂载（ bind mounts ），临时文件系统（ tmpfs ）。很多时候， volumes 总是正确的选择。

无论使用上述的哪一种方式，数据在容器内看上去都是一样的。它被认为是容器文件系统的目录或文件。

对于三种不同的存储数据的方式来说，卷是唯一完全由 Docker 管理的。它更容易备份或迁移，并且我们可以使用 DockerCLI 命令来管理卷。

列出本地可用的卷列表：

这种由系统随机生成名称的卷称为 匿名卷 ，匿名卷名称不具备可读性，使用起来不太方便，所以创建卷时一般会指定其 name 。例如我们创建一个名为 volume1 的卷。

创建好卷之后，我们可以用卷来启动一个容器，这里首先需要学习 docker container run 命令的两个参数：

对于前面创建的卷 volume1 ，可使用如下命令来在容器中使用：

使用 --mount 的命令如下：

上述操作，我们运行了两个容器，并分别挂渗行载了一个卷。对于这两个容器来说，由于挂载的是同一个卷，所以它们将共享该数据卷。多个容器共享数据卷时，需要注意并发读写问题。可以分别连接到两个容器中，操作数据来验证数据是同步的。

绑定挂载（ bind-mounts ）通过将主机上的目录挂载到容器中，使得容器可以操作和修改主机上的文件。

例如，我们将 /home/hellodocker 目录挂载到容器中的 /home/hellodocker 目录下，使用的命令如下：

而如果使用 --mount ，相应的语句如下：

上述两个操作针对的是目录，而对于挂载文件来说，可能会出现一些特殊情况，涉及到绑定挂载和使用卷的区别。下面我们重现这一操作：

首先在当前目录，即 /home/hellodocker 目录下，创建一个 test.txt 文件。并向其中写入文本内容 "test1"：

接着创建一个容器 hellodocker6 ，将 test.txt 文件挂载到容器中的 /test.txt 路径，并查看容器中 /test.txt 文件的内容：

这时新打开一个终端，通过 echo 命令向 /home/hellodocker/test.txt 文件追加内容 "test2"，并在容器中查看 /test.txt 文件的内容:

这时无论是在容器中还是主机上都能查看到该文件的最新内容。接下来在主机上查看 test.txt 的 inode 号，并使用 vim 编辑该文件丛渣哗，添加 "test3"，并查看该文件的内容：

在主机上使用 vim 编辑后，通过 vim 做出的修改并不能在容器中查看到

这是因为 vim 编辑文件的时候，会将文件内容暂存到一个临时文件中，退出保存后会删除原来的文件，并将临时文件重命名为原文件。但是我们标识文件是通过 inode ，因此 Docker 绑定的依然是旧的主机文件，所以容器中看到的依然是旧的内容。

对于数据卷来说，由 docker 完全管理，而绑定挂载需要我们自己去维护。我们需要自己手动去处理这些问题，这些问题并不仅仅是上面演示的这些，还有用户权限， SELINUX 等。

tmpfs 只存梁姿储在主机的内存中。当容器停止时，相应的数据就会被移除。

dockerfile使用phpcli模式

dockerfile使用phpcli模式需要调用。Dockerfile是一个用来构建镜像的文本埋或文件，文本内容包含猛液枣了一条条构建镜像所枝拆需的指令和说明。php-cli是phpCommandLineInterface的简称。

[img]

【docker】docker的容器创建与管理过程

# yum -y install  docker  docker-ce-cli   containerd.io

# rpm -qa | grep container

# rpm -qa | grep docker

# rpm -ql docker-ce-cli | grep bin

# rpm -ql docker-ce | grep bin

# rpm -ql containerd.io | grep bin 

# systemctl status docker

# systemctl status containerd

/var/run/docker.sock

/run/containerd/containerd.sock

/usr/bin/docker 和 /usr/bin/dockerd 就是命令行客户端和daemon

dcocker的架构是 C/S 模式

docker-containerd

docker-containerd-ctr

docker-containerd-shim

 docker-init

 docker-proxy

 docker-runc 

其实最简单的方式，就是加个命令行参数 --help 看看他们的简介。

可以看出来，docker-init, docker-containerd-shim 和 docker-proxy 没有在帮助里告诉我们是干什么的，其他的都有：粗颤

docker-containerd: 高性能容器运行时

docker-containerd-ctr: docker-containerd 的命令行客户端

docker-runc: 运行容器的命令行工具

如果去搜索一番，就会发现：docker-containerd 就是  containerd ，而 docker-runc 就是  runc 。

containerd是真正管控容器的daemon，执行容器的时候用的是runc。

为什么 要分的七零八散呢？

我估计其中主要的原因是防止docker垄断，因此把容器标准独立出来，就有了  runtime-spec ，然后有了 runc ，然后有了 containerd (此处发展历史没有考究，并不关心)。

可以看出来，docker本身其实已经被剥离干净了，只剩下docker自身的一些特色功能了，真正容器的管控都在containerd里实现。 

所以接下来介绍的顺序是 runc, containerd, shim, docker-init, docker-proxy。

runc是标准化的产物，为了防止一家商业公司主导容器化标准，因此又了open containers组织，因此，创建容器，其实最终通过runc就可以了。

dockerd 有个子进程，是 containerd，然后 containerd 有子进程。

从  官方仓库  的描述可以看出来，其实 containerd 就包含了我们常用的 docker 的命令：

增删查改容器

增删查改镜像

也就是说，如果我们要对容器进行操控，直接使用 containerd 其实就够了。

说明： 如果没有单独起一个containerd，而是使用了 docker-containerd，通过 ps aux | grep docker 发现它使用了 /var/run/docker/containerd/containerd.toml 这个配置文件岩颂败，而监听路径就写在里面。

shim的翻译是垫片，就是修自行车的时候，用来夹在螺丝和螺母之间的小铁片。

关于樱宏shim本身，网上介绍的文章很少，但是作者在 Google Groups 里有解释到shim的作用：

1. 允许runc在创建运行容器之后退出

2. 用shim作为容器的父进程，而不是直接用containerd作为容器的父进程，是为了防止这种情况：当containerd挂掉的时候，shim还在，因此可以保证容器打开的文件描述符不会被关掉

3. 依靠shim来收集报告容器的退出状态，这样就不需要containerd来wait子进程

因此，使用shim的主要作用，就是 将containerd和真实的容器（里的进程）解耦 ，这是第二点和第三点所描述的。

而第一点，为什么要允许runc退出呢？ 

因为，Go编译出来的二进制文件，默认是静态链接，因此，如果一个机器上起N个容器，那么就会占用M*N的内存，其中M是一个runc所消耗的内存。 但是出于上面描述的原因又不想直接让containerd来做容器的父进程，因此，就需要一个比runc占内存更小的东西来作父进程，也就是shim。但实际上， shim仍然比较占内存（ 参考这里 ）。

我们都知道UNIX系统中，1号进程是init进程，也是所有孤儿进程的父进程。

而使用docker时，如果不加 --init 参数，容器中的1号进程 就是所给的ENTRYPOINT。

而加上 --init 之后，1号进程就会是  tini 。

在entrypoint.sh中使用Tini的优势是什么？

用来做容器和宿主机之间的端口映射，其底层是使用iptables来完成的。

The docker-proxy

docker本身而言包括了，docker client和dockerd（docker daemon），dockerd本身实属是对容器相关操作的api的最上层封装，

直接面向操作用户。

dockerd

dockerd本身实属是对容器相关操作的api的最上层封装，直接面向操作用户。

containerd

dockerd实际真实调用的还是 containerd的api接口（rpc方式实现 ），containerd是dockerd和runc之间的一个中间交流组件。

containerd-shim

containerd-shim是一个运行的容器的真实垫片载体，每启动一个容器都会起一个新的docker-shim进程。

他直接通过指定的三个参数：容器id，boundle目录（containerd的对应某个容器生成的目录，一般位于：/var/run/docker/libcontainerd/containerID），运行二进制（默认为runc）来调用runc的api创建一个容器（比如创建容器：最后拼装的命令如下：runc create  ）

runc

runc是一个命令行工具端，根据oci（开放容器组织）的标准来创建和运行容器。

1. docker 与 dockerd 通过/var/run/docker.sock 通讯

2. dockerd通过 grpc 与containerd模块通信，dockerd由libcontainerd负责和containerd进行交换，dockerd与containerd通信socket文件为 /run/containerd/containerd.sock

3. containerd在dockerd启动时 被启动 ，然后containerd启动grpc请求监听，containerd处理grpc请求，根据请求做相应动作

4. 若是start或是exec容器，containerd拉起一个 container-shim ，并进行相应的操作

5. container-shim拉起后，start/exec/create拉起runC进程，通过exit、control文件和 containerd 通信，通过父子进程关系和SIGCHLD监控容器中进程状态

6. 在整个容器生命周期中，containerd通过epoll监控容器文件，监控容器事件

Docker组件介绍（一）：runc和containerd

Docker组件介绍（二）：shim, docker-init和docker-proxy

关于docker启动一个容器后进程

dockerphp-cli如何使用

使用dockerphp-cli进行命令行操作可以通过以下步骤便消咐捷地完成。首先，您需要安装并配置一个Docker环境。然后，在命令行中使用拿旅纯“docker run -it --rm -v $(pwd):/app -w /app php:7.4-cli php [filename.php]”命令，其中"[filename.php]"是您需要运行的PHP文件。此命令会在Docker容器中启动PHP CLI，并将当前文件夹挂镇明载到容器中。您可以在此容器中执行命令行操作。最后，使用“exit”命令退出容器。这是尝试使用dockerphp-cli的步骤，希望对您有帮助。

Docker Checkpoint/Restore

唔，暂时小记一下checkpoint / restore，希望之后能回顾并深入认识下目前的问题。

CRIU全称“Checkpoint / Restore in Userspace”，是一个为Linux提供检查点/恢复功能的工具，主要是对运行中的应用进行冻结(freeze)再基于其在磁盘上的所有文件建立检查点，并根据checkpoint恢复冻结时状态并继续运行。CRIU可以运用到场景包括：应用热迁移（live migration）、快照、远程调试（debugging）等等。CRIU为OpenVZ、LXZ/LXD、Docker等都提供了很好的支持。

/proc是一个基于内存的文件系统，包括CPU、内存、分区划分、[I/O地址]、直接内存访问通道和正在运行的进程等等，Linux通过/proc访问内核内部数据结构及更改内核设置等。Checkpoint很大程度上是基于/proc文件系统孙岁激进行的，主要依赖/proc获取文件描述符信息、管道参数、内存映则袜射等。

Checkpoint通过进程转存器(process dumper)进行以下步骤：

Restore恢复过程主要进行以下步骤：

Docker container实际上也是一个进程，故CRIU实质上是对容器进程进行checkpoint/restore。

源码装CRIU有一丢丢麻烦，记得把官网说的那些库都下完整哦。

docker虽然提供了checkpoint，但切换至experimental下才能用，新建/etc/docker/daemon.json文件，（docker的配置文件，默认没有）。

若该文件参数更改很多，就会起冲突......解决办法：尽量只将自己需要更改的配置参数写入就好，若还冲突，就启动docker时手动指定参数或脚本启动吧。

另外，我使用docker 18及之后的版本时，checkpoint无法正常使用，主要出现以下问题：

据说是???moby的原因，但看Stackflow上的问题也还是open的，关闭了一个但感觉他关的莫名其妙；有一个问题下，开发人员说解决了，但还未推到新版本。我的解决办法：试验之后， 建议使用较新版本17.06进行checkpoint/restore ，可以正常使用，可能18版本（小生年方18，尚未婚娶）太新了脚跟还没站稳。

现在可以开始愉快地使用docker checkpoint了！！Docker CLI提供了checkpoint命令。

create

ls

rm 无话可说

start

启动时没有单独的命令，但在container start可以指定checkpoint选项参数，如将容器从/home/vickee/chkps/目录下的chkp0恢复：

注意：在创建checkpoint时，若我们指定的路径为/home/PATH，则恢复时还需要具体指定到该路径下的/home/PATH/[CONTAINER_FULL_ID]/checkpoints。因为恢复时，我们可能新建容器，或者将另一个容器从别的容器的checkpoint恢复，故需自己根据checkpoint信息进行路径完善。

CRIU对最新内核的支持有限，且好像在较新版本中，移除了--checkpoint-dir即指定目录这一特性。

若容器运行时有用external terminal（ docker run -t ），checkpoint会失败的。[ 参数-t 让docker分配一个伪终端并绑定到容器的标准输入上, -i 则让容器的雀橘标准输入保持打开，常一起使用。]

links：

Docker和LXC有什么不同

二者的区别如下：

1、使用范围

LXC：Linux 环境

Docker：Docker 可以在 Linux 上运行，也可以在Windows 上运行。并且支macos，因此 Docker 并不完全依赖于 Linux，而是本机使用它运行的操作系统

2、人气

LXC：LXC 已经很老了，但由于一些限制，在开发人员和管理员中并没有得到多少普及

Docker：Docker 使容器超越了操作系统级别，以自身合并应用程序的粒度。可以说 docker 是 LXC 的扩展，因此受到欢迎

3、工具

LXC：LXC 工具与运行裸机服务器的传统系统管理员非常接近，即直接 SSH 访问，这允许使用团队可能在裸机或运行在其上的虚拟机上使用的自动化脚本Virtual Box 和任何其他虚拟化生产环境。这种可移植性功能使任何应用程序从传统 Linux 服务器迁移到在 LXC 容器上运行的过程非常无缝，但前提是尚未使用任何其他容器化解决方案，例如 基或谈稿dockers。

Docker：在 Docker 的情况下，工具以 Docker CLI（命令行界面）为中心，其中包含用于列出镜像、收集和处理 Docker 镜像的命令。Docker Hub 是一个公共镜像注册中心，可以为常用应用程序提供对可变数量镜像的访问。如果需要，您还可以下载所需的操作系统镜像，以便在 docker 容器上运行。例如，假设一个 Docker 容器中的 Linux 操作系统。这个特殊的功能通常与一些 LXC 容器相关联，这使我们能够在不需要 VM 的情况下运行操作系统。但是，Docker 容器在处理应用程序时重量更轻，以支持快速节奏，实现更高的可扩展性，并使用微服务架构部署所需的应用程序。

4、生态

LXC：不需要任何其他搏侍伍供应商来提供 LXC 的工具，因为我们已经在 Linux 上使用的生态系统也足以支持 LXC

Docker：Docker 需要对庞大的生态系统提供更专业的支持。Docker 得到 AWS、IBM、Google 和 Microsoft Azure 等主要云提供商的支持。Docker 生态系统包括 Docker Swarm 来管理 Docker 容器集群；Docker Trusted Registry 用于管理 Docker 镜像的注册表；Docker Compose 在需要交换数据的多个容器上启动多个应用程序，最后，Docker Machine 创建启用 docker 的虚拟机

5、使用便利

LXC：从 VM 迁移到 LXC 非常容易，因为 LXC 为系统映像运行标准的 init，这使您可以在 docker 容器上运行。例如，更不用说 Docker 容器中的 Linux 操作系统。这个特殊的功能通常与一些 LXC 容器相关联，这使我们能够在不需要 VM 的情况下运行操作系统。

Docker：Docker 容器在处理应用程序时重量更轻，以支持快速节奏，实现更高的可扩展性，并使用微服务架构部署所需的应用程序。

关于dockercli和dockerclientbuildimages的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。