[TOC] # 选择Docker ## Docker性能损耗的这几个方面 : ### 1,CPU与内存隔离 Docker使用<span style='color:red;background:#ff0;'>`cgroup`</span>来限制容器的CPU和内存资源。这意味着Docker会在用户空间和内核空间之间插入一层额外的开销,来监控和隔离容器的资源使用。 ### 2,镜像层加密 Docker image由多个layer组成,这些<span style='color:red;background:#ff0;'>`layer互相独立,无法直接访问下层layer的数据。这必然会带来额外的I/O开销。`</span> 对于overlay文件系统(`Docker默认的存储驱动`),会将所有layer都载入内存,通过union mount的方式暴露给容器。这也增加了内存消耗。 ### 3,网络 Docker使用iptables和自己的`veth`设备来实现容器网络隔离。与直接使用宿主机`NIC`相比,这增加了软件交换层,开销较大。 尤其在处理大量小数据集锥的场景下,性能下降最多。 ### 4,I/O 容器访问宿主机设备,不可避免多了一层映射,会带来额外的`latencies`。 特别是对I/O密集型应用来说,这会造成明显的性能损耗。 > 因此性能敏感的应用,仍需要直接部署到宿主机上,而不是通过Docker容器运行。 > <span style='color:red;background:#ff0;'>Docker的这些虚拟化技术,带来了隔离性与可移植性的好处,但同时也有性能损耗。</span> # Docker 常用命令 ### Dockerfile #### 逻辑判断 判断容器用户名是否存在; 不存在就创建用户，并为用户以及用户组设定 apache2目录权限 ``` ARG groupname\="staff" ARG username\="jerryxu" RUN getent passwd $username && \\ echo "it is exists!" || \\ useradd \-r \-g $groupname $username ; chown jerryxu:staff /etc/apache2 \-R ; ``` ### 管理镜像 * `docker images`:列出所有本地镜像 * `docker pull [image]`:从镜像仓库下拉一个镜像 * `docker rmi [image]`:删除一个本地镜像 * `docker build -t [image]:[tag] .`:从 Dockerfile 创建镜像 * `docker tag [image] [username/image]`:给镜像打标签 ### 管理容器 * `docker ps`:列出所有运行中的容器 * `docker ps -a`:列出所有容器,包括未运行的 * `docker run [image]`:创建一个新的容器并运行 * `docker start/stop [container]`: 启动/停止一个容器 * `docker exec -it [container] bash`:进入一个运行中的容器的bash shell * `docker rm [container]`:删除一个容器 ### 其他命令 * `docker version`:显示docker的版本信息 * `docker system prune`:删除所有停止的容器、网络、图像和磁盘卷 * `docker logs [container]`:获取容器的日志 * `docker network ls`:列出所有网络 * `docker inspect [container]`:获取容器的配置细节 * `docker stats`:显示实时运行容器的资源使用情况 <a style="color:#f00"> ##### </a> * `docker system df`:展示容器使用的磁盘空间 * `docker system info`:获取docker系统信息 * `docker history [container]`:获取镜像创建历史 # Dockerfile 指令优先级 1. ONBUILD - 最低优先级,只在父镜像使用`ONBUILD`时才触发 2. COPY 、 ADD - 将文件复制到镜像内 3. RUN - 执行命令创建新的镜像层 4. WORKDIR - 设置工作目录 5. ENV - 设置环境变量 6. ARG - 定义构建参数 7. VOLUME - 将目录挂载为数据卷 8. EXPOSE - 开放端口信息 9. USER - 指定运行容器时的用户名或 UID 10. ENTRYPOINT - 指定容器默认执行命令,高于CMD 11. CMD - 与ENTRYPOINT类似,但可以被后续 Docker run 参数覆盖 12. FROM - 指定基础镜像 ## CMD 和 `ENTRYPOINT` | 是否指定ENTRYPOINT | CMD指定 | 执行结果 | | --- | --- | --- | | 存在 | 为空字符串 | 执行ENTRYPOINT指定的命令 | | 存在 | 为具体命令 | 执行ENTRYPOINT指定的命令 | | 存在 | | 执行ENTRYPOINT指定的命令 | | 不存在 | 为空字符串 | 容器退出 | | 不存在 | 为具体命令 | 执行CMD指定的命令 | 根据表格可以总结: * 如果存在ENTRYPOINT,则执行ENTRYPOINT指定的命令 * 无论CMD是否指定,ENTRYPOINT都会生效 * ENTRYPOINT的优先级高于CMD * 如果只有CMD但没有ENTRYPOINT,则执行CMD指定的命令 * 如果CMD为空字符串,而ENTRYPOINT又不存在,容器直接退出 # Docker compose 服务配置的指令 优先级 1. `command`:指定容器启动时运行的命令。在命名冲突时,优先级最高。 2. `entrypoint`: 指定容器默认的入口点(entry point),可以覆盖容器原来的`ENTRYPOINT`指令。 3. `build.context`: 使用构建上下文构建镜像,生效`Dockerfile`中的指令。 4. `image`:指定用已有镜像来启动容器。 ## ENTRYPOINT 使用场景 | 场景 | 示例 | 作用 | | --- | --- | --- | | 作为系统服务运行 | ENTRYPOINT ["/usr/sbin/sshd", "-D"]`| 保证容器每次以同样方式起服务 | | 作为命令行工具 | ENTRYPOINT ["my-cli"] | 形成一个可执行文件,运行时指定参数 | | 作为部署工具 | ENTRYPOINT ["deploy"] | 封装整个部署过程在容器内 | | 作为once-off任务 | ENTRYPOINT ["make","build"] | 形成一个完整的可执行文件,自动完成任务 |