Docker 入门笔记
这是一篇笔者入门 Docker 时的读书笔记。
最后更新于
这有帮助吗？
这是一篇笔者入门 Docker 时的读书笔记。
最后更新于
这有帮助吗？
把这篇博客献给我的朋友。
没有他无数次向我安利 Docker ，就不会有这篇博客，感谢他。
传统虚拟机技术是虚拟出一套硬件后，在其上运行一个完整操作系统，在该系统上再运行所需应用进程；而容器内的应用进程直接运行于宿主的内核，容器内没有自己的内核，而且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便。
在 Docker 中每当我们每次运行 docker run 或者 docker start 时，都会 createSpec 创建一个用于设置进程间隔离的 Spec 。
在 createSpec 的 setNamespaces 方法中不仅会设置进程相关的命名空间，还会设置与用户、网络、IPC 以及 UTS 相关的命名空间。
在创建新进程时传入 CLONE_NEWPID ，也就是使用 Linux 的命名空间来实现进程的隔离，Docker 容器内部的任意进程都对宿主机器的进程一无所知。
PID namespaces用来隔离进程的ID空间，使得不同pid namespace里的进程ID可以重复且相互之间不影响。
PID namespace可以嵌套，也就是说有父子关系，在当前namespace里面创建的所有新的namespace都是当前namespace的子namespace。父namespace里面可以看到所有子孙后代namespace里的进程信息，而子namespace里看不到祖先或者兄弟namespace里的进程信息。
当 Docker 服务器在主机上启动之后会创建新的虚拟网桥 docker0，随后在该主机上启动的全部服务在默认情况下都与该网桥相连。
docker0 会为每一个容器分配一个新的 IP 地址并将 docker0 的 IP 地址设置为默认的网关。网桥 docker0 通过 iptables 中的配置与宿主机器上的网卡相连，所有符合条件的请求都会通过 iptables 转发到 docker0 并由网桥分发给对应的机器。
为了保证当前的容器进程没有办法访问宿主机器上其他目录，我们在这里还需要通过 libcontainer 提供的 pivot_root 或者 chroot 函数改变进程能够访问个文件目录的根节点。
Control Groups（简称 CGroups）就是能够隔离宿主机器上的物理资源，例如 CPU、内存、磁盘 I/O 和网络带宽。
在 CGroup 中，所有的任务就是一个系统的一个进程，而 CGroup 就是一组按照某种标准划分的进程，在 CGroup 这种机制中，所有的资源控制都是以 CGroup 作为单位实现的，每一个进程都可以随时加入一个 CGroup 也可以随时退出一个 CGroup。
启动容器时，Docker 会为这个容器创建一个与容器标识符相同的 CGroup。
每一个 CGroup 下面都有一个
tasks文件，其中存储着属于当前控制组的所有进程的 pid，作为负责 cpu 的子系统。
在 Docker 中使用 systemctl 指令时，会出现错误Failed to get D-Bus connection: Operation not permitted ，
这就说明你试图在一个 Docker 容器中开启多个后台进程，这是违反 Docker 使用规范的。
Docker的设计理念是在容器里面不运行后台服务，容器本身就是宿主机上的一个独立的主进程，也可以间接的理解为就是容器里运行服务的应用进程。一个容器的生命周期是围绕这个主进程存在的，所以正确的使用容器方法是将里面的服务运行在前台。
There is no docker0 bridge on macOSBecause of the way networking is implemented in Docker Desktop for Mac, you cannot see a
docker0interface on the host. This interface is actually within the virtual machine.
也就是说，在 Mac OS 下 Docker 的实现方式，是首先创建一个 Linux 的虚拟机，再将 Docker 放入虚拟机中实现，而对于 Linux 虚拟机，与 Mac OS 之间的通信，目前版本采用/var/run/docker.sock这种 socket 文件来通信，在 Mac OS 宿主机中自然 ping 不通 Docker 容器。
Docker采用Union FS技术设计了分层储存的架构，一个镜像即为多层文件系统联合组成。
镜像构建时，会一层层构建，前一层是后一层的基础。每一层构建完就不会再发生改变，后一层上的任何改变只发生在自己这一层。比如，删除前一层文件的操作，实际不是真的删除前一层的文件，而是仅在当前层标记为该文件已删除。在最终容器运行的时候，虽然不会看到这个文件，但是实际上该文件会一直跟随镜像。
分层储存使得镜像的复用变得更加容易。
每一个容器运行时，是以镜像为基础层，在其上创建一个当前容器的存储层，我们可以称这个为容器运行时读写而准备的存储层为 容器存储层。
按照 Docker 最佳实践的要求，容器不应该向其存储层内写入任何数据，容器存储层要保持无状态化。所有的文件写入操作，都应该使用 数据卷（Volume）、或者绑定宿主目录，在这些位置的读写会跳过容器存储层，直接对宿主（或网络存储）发生读写，其性能和稳定性更高。
仓库名及标签名均为 <none> 的镜像即为虚悬镜像，虚悬镜像是因为新版本替代了旧版本而使用相同的仓库名及标签名造成的，可以使用 docker image prune 命令清除。
不要使用 docker commit 定制镜像，定制镜像应该使用 Dockerfile 来完成。
在分层存储的架构下，除当前层外，之前的每一层都是不会发生改变的。换句话说，任何修改的结果仅仅是在当前层进行标记、添加、修改，而不会改动上一层。如果使用 docker commit 制作镜像，以及后期修改的话，每一次修改都会让镜像更加臃肿一次，所删除的上一层的东西并不会丢失，会一直如影随形的跟着这个镜像，即使根本无法访问到。这会让镜像更加臃肿。
Dockerfile 是一个文本文件，其内包含了一条条的 指令(Instruction)，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。
FROM 用于指定镜像基础
如果你以 scratch 为基础镜像的话，意味着你不以任何镜像为基础，接下来所写的指令将作为镜像第一层开始存在。
RUN 用于执行命令
两种格式：
Shell：RUN <命令>
Exec：RUN ["可执行文件", "参数1", "参数2"]
注意，Dockerfile 中每一个指令都会建立一层镜像，建议在一条 Run 语句中尽可能多地运行指令，以减少不必要的层数增加。
在Run命令准备结束时，我们需要删除为了编译构建而下载的软件，清理所有下载、展开的文件，清理 apt 缓存文件。
这是很重要的一步，我们之前说过，镜像是多层存储，每一层的东西并不会在下一层被删除，会一直跟随着镜像。因此镜像构建时，一定要确保每一层只添加真正需要添加的东西，任何无关的东西都应该清理掉。
ADD 和 COPY 用于复制文件
另外需要注意的是，
ADD指令会令镜像构建缓存失效，从而可能会令镜像构建变得比较缓慢。
CMD 用于指定主进程启动命令
Docker 不是虚拟机，容器中的应用都应该以前台执行，而不是像虚拟机、物理机里面那样，用
systemd去启动后台服务，容器内没有后台服务的概念。例如，使用
service nginx start命令，则是希望 upstart 来以后台守护进程形式启动nginx服务。而刚才说了CMD service nginx start会被理解为CMD [ "sh", "-c", "service nginx start"]，因此主进程实际上是sh。那么当service nginx start命令结束后，sh也就结束了，sh作为主进程退出了，自然就会令容器退出。
ENTRYPOINT 入口点
在运行 docker run 命令后，跟在镜像名后面的是 command，运行时会替换 CMD 的默认值，所以为了在 CMD 命令后添加命令参数，就需要使用 ENTRYPOINT 。
当存在 ENTRYPOINT 后，CMD 的内容将会作为参数传给 ENTRYPOINT，而跟在镜像名后面命令就是新的 CMD。
ENV 环境变量设置
这个指令很简单，就是设置环境变量而已，无论是后面的其它指令，如
RUN，还是运行时的应用，都可以直接使用这里定义的环境变量。
ARG 构建参数
构建参数和
ENV的效果一样，都是设置环境变量。所不同的是，ARG所设置的构建环境的环境变量，在将来容器运行时是不会存在这些环境变量的。但是不要因此就使用ARG保存密码之类的信息，因为docker history还是可以看到所有值的。
VOLUME 定义匿名卷
使用 VOLUME /data 后，这里的 /data 目录就会在运行时自动挂载为匿名卷，任何向 /data 中写入的信息都不会记录进容器存储层，从而保证了容器存储层的无状态化。
EXPOSE 声明端口
EXPOSE指令是声明运行时容器提供服务端口，这只是一个声明，在运行时并不会因为这个声明应用就会开启这个端口的服务。要将
EXPOSE和在运行时使用-p <宿主端口>:<容器端口>区分开来。-p，是映射宿主端口和容器端口，换句话说，就是将容器的对应端口服务公开给外界访问，而EXPOSE仅仅是声明容器打算使用什么端口而已，并不会自动在宿主进行端口映射。
WORKDIR 指定工作目录
使用
WORKDIR指令可以来指定工作目录（或者称为当前目录），以后各层的当前目录就被改为指定的目录，如该目录不存在，WORKDIR会帮你建立目录。
因为两条 RUN 命令之间间隔了一层镜像，即 RUN cd /home 命令后下一条语句并不会进入到 /home ，此时需要使用 WORKDIR 。
Docker 采用了 C/S 结构，也就是说我们在使用 docker build 命令的时候，并非在本地构建镜像，而是在服务端，也就是 Docker 引擎中构建的。
当我们进行镜像构建的时候，并非所有定制都会通过 RUN 指令完成，经常会需要将一些本地文件复制进镜像，比如通过 COPY 指令、ADD 指令等。那么在这种客户端/服务端的架构中，如何才能让服务端获得本地文件呢？
这就引入了上下文的概念。当构建的时候，用户会指定构建镜像上下文的路径，
docker build命令得知这个路径后，会将路径下的所有内容打包，然后上传给 Docker 引擎。这样 Docker 引擎收到这个上下文包后，展开就会获得构建镜像所需的一切文件。
例如，我们要使用 Docker 运行以下程序：
使用以下写法会导致 Docker 镜像过大以及暴露源码：
推荐使用写法：
也就是说，我们只需要编译后的程序的话，应该开启另一个镜像，并加载上一阶段的产物。
Docker Compose 是由 Python 编写，实现上调用了 Docker 服务提供的 API 来对容器进行管理。
中给出的回答是
服务类的镜像，如、、、、、、 等。
语言类的镜像，如 、、、、 等。
操作系统镜像，如 、、、、 等。
在 Docker 官方的 中要求，尽可能的使用 COPY，因为 COPY 的语义很明确，就是复制文件而已，而 ADD 则包含了更复杂的功能，其行为也不一定很清晰。最适合使用 ADD 的场合，就是所提及的需要自动解压缩的场合。
本作品采用进行许可，转载时请注明原文链接，图片在使用时请保留全部内容，可适当缩放并在引用处附上图片所在的文章链接。