容器镜像制作 流程与规范

容器镜像制作 流程与规范

介绍容器的使用规范，包括构建镜像、启动容器、挂载数据卷、容器导入导出、连接harbor镜像仓库等。

一、容器镜像制作流程与规范

原则上，容器镜像内应用程序与开源软件的管理同应用的管理。

如发现开源软件安全漏洞需要升级，遵循谁制作谁升级；镜像仓库由系统设备部统一管理和维护。

镜像是在基础文件集（root filesystem）之上依次变更的集合，及在容器运行的默认执行参数。

制作镜像的主要步骤：

选择基础镜像编写Dockerfile编译应用构建镜像docker bulid -f Dockerfile -t XX/XX:version .推送至镜像仓库

一）基本原则

尽可能地设计成无状态服务容器镜像必须在测试环境制作。容器内开源软件清单及版本等同于应用软件管理流程。如发现开源软件安全漏洞需要升级，遵循谁制作谁升级；容器只运行一个进程。需要持久化的数据写入到共享存储配置与镜像内容分离容器中使用k8s内部dns代替ip地址配置形式为减少镜像的体积和编译时间，应避免安装额外的、不需要的包，只安装必要的包。

镜像中的软件包。安装软件包时，避免安装推荐的非依赖软件包。

安装完毕之后，需清理临时安装包：对于yum使用“yum clean all”来进行清理减少镜像层。根据Dockerfile语法，只有 RUN，COPY，ADD 这 3 条指令会增加镜像层，其它的指令仅会创建临时的中间镜像，并不会增加最终镜像的大小。所以，尽可能的把多条 RUN，COPY，ADD 指令合并为一条，这样可以让镜像包含尽可能少的层数，以减少镜像的体积。多阶段构建。如果构建的镜像包含了很多层，可以根据层的修改频率来对镜像层进行排序，把经常有变动的层放在Dockerfile最下面，很少变动的层，特别是涉及到网络下载的操作放在Dockerfile 的上面。自己开发的模块要避免使用App 的主进程作为最终阻塞 Container 退出的命令，建议方式是把App 的主进程作为后台进程，用 tail -f /dev/null 之类的进程作为主前台进程

二）镜像分类

镜像可分为以下三类：

基础镜像：仅包含除操作系统核心外的操作系统运行环境的镜像。系统部设备部对此负责。中间件镜像：在基础镜像之上，加入运行应用所需的中间件软件后构建的镜像。应用支持部与系统设备部对此负责。应用镜像：基于统一提供的基础镜像或中间件镜像加入可执行的应用包后构建的镜像。项目组对此负责。

三）基础镜像

基础镜像应遵循如下规范：

基础镜像应使用CentOS操作系统。若有特殊需求使用其它Linux操作系统，必须说明原由。版本建议使用 Centos 7。基础镜像必须使用镜像仓库中统一提供的镜像。

四）中间件镜像

中间件镜像应遵循如下规范：

中间件镜像原则上应仅包含消息中间件或交易中间件（诸如TOMCAT、rabbitmq）一种中间件软件。若同一中间件镜像需要包括大于一种中间件软件，必须采用多次打包方式（每次打包一种中间件软件）。中间件镜像应从对应中间件技术栈官网下载，随后根据我行中间件规范进行调整更新。中间件镜像版本同中间件基线。中间件镜像必须使用镜像仓库中统一提供的镜像。

五）应用镜像

1、应用的容器化改造，分为两个部分：

应用容器化。应用与配置分离。

应用容器化是指把编译以后的应用程序包，加入到基础镜像或者中间件镜像，实现应用容器化。并且通过能够通过配置的端口直接进行访问。应用与配置分离是指将同一环境下的，原有应用的配置文件全部分离出来，通过配置中心进行统一管理，在容器启动的时候通过挂载的方式统一访问本环境配置中心下的配置。这样就完成了应用的配置改造。

2、应用镜像应遵循如下规范：

必须使用镜像仓库统一提供的基础镜像或中间件镜像进行应用镜像构建。应用镜像仅可对以下内容进行修改，不得包括其它与应用无关的文件。

A. 中间件镜像的配置文件B. 可执行的应用包C. 依赖包介质（包括jar包、war包、ear包以及其他相关可执行程序文件）D. 应用参数配置文件启动命令

应用镜像中加入的依赖包必须符合相应安全要求，经过安全漏洞扫描。不允许在应用镜像中加入操作系统的第三方调试工具，如nmoun等。如确有特殊需求，应在可行性方案中详细说明设计原由申请特例。应用镜像大小应控制在1G以下，不建议使用过1G的应用镜像，如确有特殊需求，应在上线评审时备案具体技术方案并提出特例申请。多环境问题处理

多环境一般包括开发、SIT、UAT、PP、PI环境与生产环境，每一个环境对应配置中心的一套配置，应用镜像在不同环境中程序本身不需要变动。在容器启动的时候，挂载所属环境对应的相关配置即可。以实现环境对应用程序的透明。

六）Dockerfile编写规范

Dockerfile用于Docker镜像构建的由一系列命令和参数构成的脚本，Dockerfile结构分为四部分：基础镜像信息、维护者信息、镜像操作指令、容器启动时执行指令。其编写应遵从规范如下：

1、基础镜像信息

FROM指令

必须为dockerfile第一句有效指令。尽量使用相关技术栈网站的官方镜像作为基础镜像。避免从头开始制作。

2、维护者信息

MAINTAINER指令

需设置维护者信息：MAINTAINER Name

3、镜像操作指令

RUN指令

1）避免更新基础镜像中的基础软件包，避免执行yum update或apt upgrade的命令。2）尽量使用RUN apt update && apt install -y \的方式保证每次制作镜像时，都是安装的最新的软件包。3）在安装命令以及构建后，应清理缓存以及临时文件，以减少镜像的大小，执行...&& yum clean all。4）安装依赖包的命令应放在一行RUN关键字命令中。5）Dockerfile中需把把多个参数排在不同的行中，提高可读性。确保易读性，很长的命令不要一写到底。遇到长命令可以用“\”符号进行连接。遇到几个命令在一起的，可以用“\ &&”方式连接。echo ‘nice to meet you’ \&& echo ‘hello’6）减少镜像的层数。根据Dockerfile语法，只有 RUN、COPY、ADD这3条指令会增加镜像层，其它的指令仅会创建临时的中间镜像，并不会增加最终镜像的大小。所以，尽可能的把多条RUN、COPY、ADD 指令合并为一条，这样可以让镜像包含尽可能少的层数，以减少镜像的体积。#推荐的写法RUN wget && tar -xzf app.tar.gz && rm app.tar.gz#不推荐的写法RUN wget tar -xzf app.tar.gzRUN rm app.tar.gz

EXPOSE指令

ADD与COPY指令

1）使用COPY命令，只从本地服务器拷贝文件。2）如果压缩包拷贝进镜像后，不希望这个压缩包被自动解压缩，使用COPY命令。反之，如果希望拷贝进镜像之后就自动解压，使用ADD命令。3）如果涉及到远程文件, 建议使用RUN curl或RUN wget命令替代 ADD。

ADD 的优点：在执行 <源文件> 为 tar 压缩文件的话，压缩格式为 gzip, bzip2 以及 xz 的情况下，会自动复制并解压到 <目标路径>。

ADD 的缺点：在不解压的前提下，无法复制 tar 压缩文件。会令镜像构建缓存失效，从而可能会令镜像构建变得比较缓慢。具体是否使用，可以根据是否需要自动解压来决定。

WORKDIR指令

1）尽量使用绝对路径。2）切换目录的时候尽量使用WORKDIR, 而不是使用RUN cd /dir。

VOLUME  定义匿名数据卷。在启动容器时忘记挂载数据卷，会自动挂载到匿名卷

作用：

避免重要的数据，因容器重启而丢失，这是非常致命的。避免容器不断变大。

格式：VOLUME ["<路径1>", "<路径2>"...]VOLUME <路径>在启动容器 docker run 的时候，我们可以通过 -v 参数修改挂载点。

USER 用于指定执行后续命令的用户和用户组，这边只是切换后续命令执行的用户（用户和用户组必须提前已经存在）。

格式：

USER <用户名>[:<用户组>]

HEALTHCHECK 用于指定某个程序或者指令来监控 docker 容器服务的运行状态。

格式：HEALTHCHECK [选项] CMD <命令>：设置检查容器健康状况的命令HEALTHCHECK NONE：如果基础镜像有健康检查指令，使用这行可以屏蔽掉其健康检查指令HEALTHCHECK [选项] CMD <命令> : 这边 CMD 后面跟随的命令使用，可以参考 CMD 的用法。

ONBUILD 用于延迟构建命令的执行。

简单的说，就是 Dockerfile 里用 ONBUILD 指定的命令，在本次构建镜像的过程中不会执行（假设镜像为 test-build）。当有新的 Dockerfile 使用了之前构建的镜像 FROM test-build ，这时执行新镜像的 Dockerfile 构建时候，会执行 test-build 的 Dockerfile 里的 ONBUILD 指定的命令。

格式：ONBUILD <其它指令>

LABEL 指令用来给镜像添加一些元数据（metadata），以键值对的形式

语法格式如下：

LABEL = = = ...

比如我们可以添加镜像的作者：

LABEL org.opencontainers.image.authors="wzs"

4、容器启动时执行指令

CMD指令

1）原则上Dockerfile只能使用CMD关键字启动一个应用，不建议使用shell脚本启动多个应用进程。2）CMD指令设置镜像中的默认启动命令和参数。容器启动之后，如果没有加入任何启动命令，则默认执行镜像中的CMD设置的默认的启动命令。3）设置启动命令时，应该尽量使用json格式，如CMD ["command", "arg1", "arg2"]。

类似于 RUN 指令，用于运行程序，但二者运行的时间点不同:

CMD 在docker run 时运行。RUN 是在 docker build。

作用：为启动的容器指定默认要运行的程序，程序运行结束，容器也就结束。CMD 指令指定的程序可被 docker run 命令行参数中指定要运行的程序所覆盖。

注意：如果 Dockerfile 中如果存在多个 CMD 指令，仅最后一个生效。

ENTRYPOINT指令

1）必须确保中间件镜像和应用镜像的Dockerfile未使用ENTRYPOINT shell方式启动容器。如需使用ENTRYPOINT，应使用ENTRYPOINT exec方式，并必须配合使用CMD作为Dockerfile 尾句为ENTRYPOINT提供参数。2）通过ENTRYPOINT指令可设置镜像的入口程序。当启动主程序之前还需要执行大量的前置操作时，可将ENTRYPOINT的入口指令设置为一个脚本entrypoint.sh。

类似于 CMD 指令，但其不会被 docker run 的命令行参数指定的指令所覆盖，而且这些命令行参数会被当作参数送给 ENTRYPOINT 指令指定的程序。

但是, 如果运行 docker run 时使用了 --entrypoint 选项，将覆盖 CMD 指令指定的程序。

优点：在执行 docker run 的时候可以指定 ENTRYPOINT 运行所需的参数。

注意：如果 Dockerfile 中如果存在多个 ENTRYPOINT 指令，仅最后一个生效。

可以搭配 CMD 命令使用：一般是变参才会使用 CMD ，这里的 CMD 等于是在给 ENTRYPOINT 传参，以下示例会提到。

示例：假设已通过 Dockerfile 构建了 nginx:test 镜像：FROM nginxENTRYPOINT ["nginx", "-c"] # 定参CMD ["/etc/nginx/nginx.conf"] # 变参 1、不传参运行$ docker run nginx:test容器内会默认运行以下命令，启动主进程。nginx -c /etc/nginx/nginx.conf2、传参运行$ docker run nginx:test -c /etc/nginx/new.conf容器内会默认运行以下命令，启动主进程(/etc/nginx/new.conf:假设容器内已有此文件)nginx -c /etc/nginx/new.conf

ENV指令

若需要使用启动参数，应在Dockerfile内通过ENV关键字体现。

设置环境变量，定义了环境变量，那么在后续的指令中，就可以使用这个环境变量。

格式：

ENV ENV = =...

以下示例设置 NODE_VERSION = 7.2.0 ， 在后续的指令中可以通过 $NODE_VERSION 引用：

ENV NODE_VERSION 7.2.0RUN curl -SLO "\ && curl -SLO "ENV 作用一致。不过作用域不一样。ARG 设置的环境变量仅对 Dockerfile 内有效，也就是说只有 docker build 的过程中有效，构建好的镜像内不存在此环境变量。构建命令 docker build 中可以用 --build-arg <参数名>=<值> 来覆盖。格式：ARG <参数名>[=<默认值>]

5、其他规范：

1）由于dockerfile是自动化执行文件，故需确保所有命令执行正确，以避免执行中断。2）所有指令全部大写。3）应使用多阶段方式构建镜像即多个Dockerfile分步骤构建镜像，以便于严格控制最终应用镜像的大小。4）使用 LABEL 标签提供完整的镜像信息，至少应包括：所属项目组名称、维护人姓名、维护人联系方式。5）原则上应该尽可能降低单个Dockerfile复杂性，减少多个Dockerfile间的依赖关系，必须确保未安装不必要的程序包和依赖包。6）在构建镜像时，尽量新创建一个目录，把Dockerfile，需要拷贝到镜像中的文件都放入到新建的目录中，把新目录作为构建上下文来执行docker build构建操作。切忽不要使用存在较大不相关文件的目录作为构建上下文，这样会导致镜像的体积和镜像构建时间都成倍增加。举例： 创建构建目录mkdir dockerbuild && cd $docker build –t 10.100.10.100/daocloud/testimage:v1.0 .7）只将编译后的程序放入运行容器中 避免运行容器中安装编译相关包。 避免编译过程中参数大量临时文件造成容器臃肿。 避免容器镜像发布时同时泄露源码。

二、镜像仓库使用规范

使用行方私有仓库存储镜像。像需通过tag标签，实现版本控制。镜像仓库管理员设置不同项目管理员（租户），租户可对其项目镜像进行管理，包括镜像权限管理等。镜像仓库由系统设备部统一管理和维护。

三、容器存储规范

Docker 容器运行时产生的数据具有易失性，如有持久性数据的存储需求，必须存放至宿主机本地盘或NAS共享存储。

2、将volume绑定到宿主机指定目录

创建数据卷，挂载到容器内volumedir目录下，将volumedir挂载到宿主机匿名卷下

docker run -it --name $CONTAINER_NAME -v $VOLUMEDIR $IMAGE_NAME

挂载一个主机目录作为数据卷

docker run -it --name $CONTAINER_NAME -v $docker_name_volumedir:$VOLUMEDIR $IMAGE_NAME$docker_name_volumedir默认为/var/lib/docker下新建目录

四、容器网络规范

host模式，使用--net=host指定。container模式，使用--net=container:NAME_or_ID指定。none模式，使用--net=none指定。bridge模式，使用--net=bridge指定，默认设置。

六、容器安全规范

容器里涉及的非应用本身的开源软件或者系统软件，因为安全漏洞等原因需要进行相应的版本升级的，需要明确重新出容器镜像的流程。提出解决建议。容器镜像流程建议：总体上容器镜像内应用程序和开源软件的管理同应用的管理。容器镜像主进程不得用root用户运行，需新建用户执行：

RUN groupadd -g 1001 appgroup && \useradd -r -u 1001 -g appgroup appuserUSER appuser

七、Docker compose使用规范

对于多节点集群系统，涉及前后启动顺序的，需使用docker compose技术实现对多个容器的逻辑编排。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。