Docker镜像的创立

创立镜像有三种方法，分别为依据已有镜像创立、依据本地模板创立以及依据Dockerfile创立。

依据现有镜像创立

docker export 将容器导出

创立一个容器，进入容器并创立文件写入数据，再运用docker export导出容器成紧缩包，能够搬迁，或许直接导入运用

然后经过docker import导入成镜像。即依据本地模板创立（容器的导入导出和搬迁），后面再介绍。

docker commit将容器提交为新的镜像

仍然运用前面的容器，将修正后的容器提交为新的镜像，需求运用该容器的ID号创立新镜像

格局：docker commit -m 阐明 -a 作者 -p 容器ID 生成新的镜像称号

选项解说

选项	作用
-m	指定阐明信息
-a	作者信息
-p	生成进程中止原容器运转

操作进程

将容器导出成镜像
运用导出的镜像创立容器
进入容器检查数据
检查镜像详细信息

依据本地模板创立

经过导入操作体系模板文件能够生成镜像，模板能够从OPENVZ 开源项目下载，下载地址为：Open source container-based virtualization for Linux. (openvz.org)

本次试验用debian的模板进行。

#模板里面能够就运用docker export 指令导出的容器文件
#下载模板
wget http://download.openvz.org/template/precreated/debian-7.0-x86-minimal.tar.gz
#导入为镜像，两种方法
cat debian-7.0-x86-minimal.tar.gz | docker import - debian:test #方法一
 
docker import debian-7.0-x86-minimal.tar.gz -- debian:test #方法二
#检查镜像
docker images
#运用导入的镜像创立容器
docker run -itd debian:test bash
docker ps -a

操作进程

这里已经有模板，移动到虚拟机中，无需再下载
将模板导入为镜像
运用导入的镜像创立容器
进入容器后，即可运用

依据Dockerfile 创立

联合文件体系(UnionFS)

UnionFS(联合文件体系)： Union文件体系(UnionFS)是一种分层、轻量级并且高性能的文件体系，它支撑对文件体系的修正作为一次提交来一层层的叠加，一起能够将不同目录挂载到同一个虚拟文件体系下。AUFS、overlayFS 及Devicemapper 都是一种UnionFS 。

Union文件体系是Docker镜像的根底。镜像能够经过分层来进行继承，依据根底镜像(没有父镜像)，能够制作各种详细的运用镜像。

特性：一次一起加载多个文件体系，但从外面看起来，只能看到一一个文件体系，联合加载会把各层文件体系叠加起来，这样最终的文件体系会包括一切底层的文件和目录。

咱们下载的时分看到的一层层的便是联合文件体系。

镜像加载原理

Docker的镜像实践上由一层一层的文件体系组成，这种层级的文件体系便是UnionFS。

bootfs主要包括bootloader和kernel，bootloader主要是引导加载kernel，Linux刚发动时会加载bootfs文件体系。

在Docker镜像的最底层是bootfs，这一层与咱们典型的Linux/Unix体系是一样的，包括boot加载器和内核。当boot加载完结之后整个内核就都在内存中了，此刻内存的运用权已由bootfs转交给内核，此刻体系也会卸载bootfs。

rootfs，在bootfs之上。包括的便是典型Linux体系中的/dev、/proc、/bin、/etc等规范目录和文件。rootfs便是各种不同的操作体系发行版，比方Ubuntu, Centos等。

bootfs便是内核引导器（引导加载内核）和内核。
rootfs是n多个根底镜像（供给根底操作环境）和运用镜像叠加在一起的只读层。
运转的容器实例会在rootfs之上增加一个可读可写层。

Docker 镜像结构的分层

容器层的文件操作

镜像层数量可能会很多，一切镜像层会联合在一起组成一个统一的文件体系。假如不同层中有一个相同途径的文件，比方/a，上层的/a会掩盖基层的/a，也便是说用户只能访问到上层中的文件/a。在容器层中，用户看到的是一个叠加之后的文件体系。

文件操作阐明

文件操作	阐明
增加文件	在容器中创立文件时，新文件被增加到容器层中。
读取文件	在容器中读取某个文件时，Docker 会从上往下顺次在各镜像层中查找此文件。—旦找到，当即将其仿制到容器层，然后翻开并读入内存。
修正文件	在容器中修正已存在的文件时，Docker 会从上往下顺次在各镜像层中查找此文件。一旦找到，当即将其仿制到容器层，然后修正之。
删去文件	在容器中删去文件时，Docker 也是从上往下顺次在镜像层中查找此文件。找到后，会在容器层中记录下此删去操作。(仅仅记录删去操作)

只要当需求修正时才仿制—份数据，这种特性被称作Copy-on-Write。可见，容器层保存的是镜像改动的部分，不会对镜像本身进行任何修正。

这样就解说了咱们前面提出的问题:容器层记录对镜像的修正，一切镜像层都是只读的，不会被容器修正，所以镜像能够被多个容器同享。

在容器中进行删去操作

演示进程

明明在容器v1已经删去了var目录，但用与v1相同的镜像创立v2后，var目录仍然存在。

原因

看着是已经删去，可是实践上删去的只不过是容器层的副本，真实的目录是在镜像上面，删去不掉的，容器层才是可读可写层，镜像只能读。

为什么Docker里的centos的巨细才200M？

由于关于精简的OS，rootfs能够很小，只需求包括最根本的指令、东西和程序库就能够了，由于底层直接用宿主机的kernel，自己只需求供给rootfs就能够了。由此可见关于不同的linux发行版，bootfs根本是一致的， rootfs会有差别，因而不同的发行版能够共用bootfs。

大部分镜像是通用的，但假如专门依据某个版本创立的镜像，在其他版本的操作体系中运转可能会有问题。

Dockerfile

Docker镜像是一个特殊的文件体系，除了供给容器运转时所需的程序、库、资源、装备等文件外，还包括了一些为运转时预备的一些装备参数(如匿名卷、环境变量、用户等)。镜像不包括任何动态数据，其内容在构建之后也不会被改动。

镜像的定制实践上便是定制每一层所增加的装备、文件。假如咱们能够把每一层修正装置、构建、操作的指令都写入一个脚本，用这个脚本来构建、定制镜像，那么镜像构建透明性的问题、体积的问题就都会解决。这个脚本便是Dockerfile。

Dockerfile是一个文本文件，其内包括了一条条的指令（Instruction）,每一条指令构建一层，因而每一条指令的内容，便是描绘该层应当怎么构建。有了Dockerfile，咱们需求定制首己额定的需求时，只需在Docketlle上增加或许修正指令，从头生成image 即可，省去了敲指令的费事。便是描绘该层应当怎么构建。有了Dockerfile，当咱们需求定制自己额定的需求时，只需在Dockerfile上增加或许修正指令，从头生成image即可，省去了敲指令的费事。

除了手动生成Docker镜像之外，能够运用bockerfile主动生成镜像。Dockerfile 是由多条的指令组成的文件，其中每条指令对应Linux中的一条指令，Docker程序将读取Dockerfile中的指令生成指定镜像。

Dockerfile结构大致分为四个部分：根底镜像信息、保护者信息、镜像操作指令和容器发动时履行指令。Dockerfile每行支撑一条指令，每条指令可携带多个参数，支撑运用以“#“号开头的注释。

Docker镜像结构的分层

镜像不是一个单一的文件，而是有多层构成。容器其实是在镜像的最上面加了一层读写层，在运转容器里做的任何文件改动，都会写到这个读写层。假如删去了容器，也就删去了其最上面的读写层，文件改动也就丢掉了。Docker运用存储驱动管理镜像每层内容及可读写层的容器层。

Dockerfile中的每个指令都会创立一个新的镜像层；
镜像层将被缓存和复用；
当Dockerfile的指令修正了，仿制的文件改动了，或许构建镜像时指定的变量不同了，对应的镜像层缓存就会失效；
某一层的镜像缓存失效，它之后的镜像层缓存都会失效；
镜像层是不可变的，假如在某一层中增加一个文件，然后在下一层中删去它，则镜像中仍然会包括该文件，仅仅这个文件在Docker 容器中不可见了。

bootfs： bootfs加载器+内核，容器都是同享内核的，所以都有相同的bootfs。
rootfs只读层： rootfs能够有多层，对外体现看起来便是一个整体。
运用镜像运转一个容器实例时，就会在rootfs只读层上挂载一层可读可写层。

Dockerfile 操作指令的指令

Dockerﬁle简介

Dockerﬁle其实便是咱们用来构建Docker镜像的源码，当然这不是所谓的编程源码，而是一些指令的组合，只要理解它的逻辑和语法格局，就能够编写Dockerﬁle了。

简单点说，Dockerﬁle的作用：它能够让用户个性化定制Docker镜像。由于作业环境中的需求各式各样，网络上的镜像很难满足实践的需求。

Dockerﬁle常见指令

指令	作用
FROM image_name:tag	声明根底镜像
MAINTAINER user_name	声明镜像的作者
ENV key value	设置环境变量 (能够写多条)
RUN command	编译镜像时运转的脚本(能够写多条)
CMD	设置容器的发动指令
ENTRYPOINT	设置容器的进口程序
ADD source_dir/ﬁle dest_dir/ﬁle	将宿主机的文件仿制到镜像内，假如是一个紧缩文件，将会在仿制后主动解压。支撑URL途径下载源文件，但下载方式不能主动解压。
COPY source_dir/ﬁle dest_dir/ﬁle	和ADD类似，将宿主机的文件仿制到镜像内，可是假如有紧缩文件并不能解压。不支撑URL途径下载。
WORKDIR path_dir	设置作业目录
ARG	设置编译镜像时加入的参数
VOLUMN	设置容器的挂载卷

Dockerfile操作常用的指令

FROM 镜像

指定新镜像所依据的根底镜像，第一条指令有必要为FROM指令，每创立一-个镜像就需求一条FROM指令。

MAINTAINER 姓名

阐明新镜像的保护人信息

RUN 指令

在所依据的镜像上履行指令，并提交到新的镜像中.

尽量削减run指令的条数。

当指令较长时，能够运用 \ 来换行；
多条指令能够运用 ; 或 && 合并成一条指令，削减镜像的层数。

ENTRYPOINT

ENTRYPOINT ["要运转的程序"，"参数1"，"参数2"]

设定容器发动时第一个运转的指令及其参数。

能够经过运用指令docker run --entrypoint来掩盖镜像中的ENTRYPOINT指令的内容。

两种格局：

exec格局（数值格局）：ENTRYPOINT [“指令”，“选项”，“参数”]
shell格局：ENTRYPOINT 指令 选项 参数

前面四个指令就能够创立一个大略的镜像。

CMD

CMD ["要运转的程序"，"参数1"，"参数2"]

发动容器时默许履行的指令或许脚本，Dockerfile只能有一条CMD指令。假如指定多条指令，只履行最终一条指令。

假如在docker run时指定了指令或许镜像中有ENTRYPOINT，那么CMD就会被掩盖。

CMD 能够为ENTRYPOINT 指令供给默许参数。

两种格局：

exec方式：CMD [“要运转的程序”，“参数1”, “参数2”]
shell方式: CMD 指令 参数1 参数2

ENTRYPOINT和CMD共存的景象： ENTRYPOIN指定指令，CMD传参

容器运转时的优先级

docker run –entrypoint > Dockerfile ENTRYPOINT > docker run指令> Dockerfile CMD

ENTRYPOINT和CMD的差异

ENTRYPOINT设定容器发动时第一个运转的指令；CMD是发动容器时默许履行的指令，假如指定多条CMD指令，只履行最终一条指令。
假如在docker run时指定了指令或许镜像中有ENTRYPOINT，那么CMD就会被掩盖，并且会将CMD中的指令作为参数传给ENTRYPOINT。
CMD能够为ENTRYPOINT进行传参。

EXPOSE 端口号

指定新镜像加载到Docker 时要开启的端口。

用于露出端口，否则即使做了端口映射，外部也找不到。

ENV

ENV 环境变量变量值

设置一个环境变量的值，会被后面的RUN运用。

ADD

将源文件仿制到镜像的指定途径中，源文件要与 Dockerfile 位于相同目录中，或许是一个URL。（URL途径，在线途径）

注意事项

假如源途径是个文件，且方针途径是以 / 结束，则docker会把方针途径当作一个目录，会把源文件仿制到该目录下。假如方针途径不存在，则会主动创立方针途径。
假如源途径是个文件，且方针途径是不以/结束，则docker会把方针途径当作一个文件。假如方针途径不存在，会以方针途径为名创立一个文件，内容同源文件。假如方针文件是个存在的文件，会用源文件掩盖它，当然仅仅内容掩盖，文件名还是方针文件名。假如方针文件实践是个存在的目录，则会源文件仿制到该目录下。注意，这种情况下，最好显示的以/结束，以避免混杂。
假如源途径是个目录，且方针途径不存在，则docker会主动以方针途径创立一个目录，把源途径目录下的文件仿制进来。假如方针途径是个已经存在的目录，则docker 会把源途径目录下的文件仿制到该目录下。
假如源文件是个归档文件，则docker会主动帮解压。（解压后仿制源目录到镜像中的目录） URL下载和解压特性不能一起运用。任何紧缩文件经过URL仿制，都不会主动解压。（不支撑下载和解压一起运用，下载就不会解压。即只解压本地紧缩包，不会解压下载的紧缩包）

ADD的优缺陷

ADD的优点：在履行<源文件>为tar紧缩文件的话，紧缩格局为 gzip、bzip2以及xz的情况下，会主动仿制并解压成<方针途径>
ADD的缺陷：在不解压的前提下，无法仿制tar紧缩文件。会令镜像构建缓存失败，然后可能会令镜像构建变得比较缓慢。详细是否运用，能够依据是否需求主动解压来决议。

COPY

只仿制本地主机上的文件/目录仿制到方针地点，源文件/目录要与Dockerfile在相同的目录中。

ADD和COPY比较：（同样需求下，官方推荐运用 COPY）

共同点：
- ADD和COPY都能够仿制本地文件到镜像中。
差异：
- ADD：假如是一个紧缩文件，ADD会在仿制后主动解压。且支撑URL途径下载源文件，但URL下载和解压特性不能一起运用，任何紧缩文件经过URL仿制，都不会主动解压。
- COPY：假如是紧缩文件，COPY并不能解压。且COPY只能仿制本地文件，不支撑URL途径仿制。

VOLUME [“目录”]

在容器中构建一个挂载点（即创立数据卷）

USER 用户/UID

指定运转容器时的用户。（用于切换用户）

WORKDIR 途径

为后续的RUM、CMD、ENTRYPOIDT指定作业方针。（用于切换容器中的目录）

CMD能够为ENTRYPOINT指令供给默许参数

workdir /opt  #切换镜像层
run cd /opt  #会增加镜像层

ONBULD 指令

指定所生成的镜像作为一个根底镜像时所要运转的指令。

当在一个Dockerfile文件中加上ONBUILD指令，该指令对运用该Dockerfile构建镜像（比方为A镜像）不会发生实质性影响。

可是当编写一个新的Dockerfile文件来依据A镜像构建一个镜像（比方为B镜像）时，这时结构A镜像的Dockerfile文件中的ONBUILD指令就收效了，在构建B镜像的进程中，首先会履行ONBUILD指令指定的指令，然后才会履行其它指令。

（即加私货，这个指令不是给我用的，是给其他镜像用的）

AGR

设置编译镜像时加入的参数。

ARG指令，能够引证在docker build构建镜像时指定的参数，即达到引证参数的作用。

运用ENV指令界说的环境变量始终会掩盖同名的ARG指令。

ARG CONT_IMG_VER   #Dockfile中指定变量名 
ENV CONT_IMG_VER=v1.0.0 
RUN echo $CONT_IMG_VER #AEG和ENV界说的变量名，不要重复，否则最终echo的是ENV界说的值
docker build --build-arg CONT_IMG_VER=v2.0 .   #构建镜像时传入变量值
#由于AEG和ENV界说的变量名重复了，ENV指令界说的环境变量始终会掩盖同名的ARG指令，所以最终输出的是ENV界说的值。

创立镜像

编写完结Dockerfile之后，能够经过 docker build 指令来创立镜像。

根本的格局为 docker build [选项] 途径，该指令将读取指定途径下（包括子目录）的Dockerfile，并将该途径下一切内容发送给Docker服务端，由服务端来创立镜像。因而一般主张放置Dockerfile的目录为空目录。

另外，能够经过.dockerignore文件（每一行增加一条匹配形式）来让Docker疏忽途径下的目录和文件。

要指定镜像的标签信息，能够经过-t选项。

在编写Dockerfile 时，有严格的格局需求遵从

第一行有必要运用FROM指令指明所依据的镜像称号；
之后运用MAINTAINER 指令阐明保护该镜像的用户信息；
然后是镜像操作相关指令，如RUN指令/EXPOSE/ADD/ENV/ARG等等。每运转一条指令，都会给根底镜像增加新的一层。（多条指令能够运用 ; 或 && 合并成一条指令，削减镜像的层数）
最终运用CMD或许ENTRYPOINT指令指定发动容器时要运转的指令操作。

Dockerfile事例实战

Dockerfile编写进程

FROM 指定根底镜像
MAINTAINER 指定镜像作者信息
RUN EXPOSE ENV ADD 等指令指定镜像构建的进程
CMD ENTRYPOINT 指定容器发动时运转的指令

事例1：yum源装置Apache

创立作业目录，预备Dockerfile文件

#指定根底镜像
FROM centos:7
#指定镜像及作者信息
MAINTAINER this is apache image <jj>
#镜像操作指令装置Apache软件
RUN yum -y install httpd
#露出程序端口80
EXPOSE 80
#把本地编写好的网页文件仿制到容器镜像中的指定方位
ADD index.html /var/www/html/
#指定发动容器时第一个运转的指令，前台运转Apache
ENTRYPOINT ["/usr/sbin/apachectl"]
CMD ["-D", "FOREGROUND"]

预备页面信息
构建apache镜像
- build构建镜像
- -t指定生成镜像的称号
- . 代表当时dockerfile目录
依据构建的镜像运转容器
进行访问测验

事例2：编译装置Apache

预备装置包，装置包置于作业目录中

apr-1.6.2.tar.gz
apr-util-1.6.0.tar.gz
httpd-2.4.29.tar.bz2

#指定根底镜像
FROM centos:7
#指定作者信息
MAINTAINER this is apache <jj>
#装置Nginx
RUN yum -y install gcc gcc-c++ make pcre pcre-devel expat-devel perl
ADD apr-1.6.2.tar.gz /opt/
ADD apr-util-1.6.0.tar.gz /opt/
ADD httpd-2.4.29.tar.bz2 /opt/
RUN mv /opt/apr-1.6.2 /opt/httpd-2.4.29/srclib/apr &&\
    mv /opt/apr-util-1.6.0 /opt/httpd-2.4.29/srclib/apr-util &&\
    cd /opt/httpd-2.4.29 &&\
    ./configure --prefix=/usr/local/httpd --enable-so --enable-rewrite --enable-charset-lite --enable-cgi &&\
    make -j3 &&\
    make install
#露出端口
EXPOSE 80
#指定容器运转时履行的指令
CMD ["/user/local/httpd/bin/apachect","-D","FOREGROUND"]

事例3：编译装置Nginx

预备Nginx的装置包，装置包置于作业目录中
预备Dockerfile文件

#指定根底镜像
FROM centos:7
#指定镜像及作者信息
MAINTAINER this is nginx image <jj>
#履行yum装置依靠包
RUN yum -y install pcre-devel zlib-devel gcc gcc-c++ make
#履行创立用户的指令
RUN useradd -M -s /sbin/nologin nginx
#解压文件到opt目录
ADD nginx-1.22.0.tar.gz /opt/
#切换作业目录
WORKDIR  /opt/nginx-1.22.0/
#履行装备和编译装置
RUN ./configure \
--prefix=/usr/local/nginx \
--user=nginx \
--group=nginx \
--with-http_stub_status_module
RUN make
RUN make install
#让体系辨认Nginx的指令
ENV PATH /usr/local/nginx/sbin:$PATH
#露出端口
EXPOSE 80
EXPOSE 443
#指定要运转的指令
ENTRYPOINT ["/usr/local/nginx/sbin/nginx"]
CMD ["-g","daemon off;"]

构建apache镜像
依据构建的镜像运转容器
进行访问测验

多阶段构建容器

#指定根底镜像
FROM centos:7
#指定作者信息
MAINTAINER this is apache <jj>
#装置Nginx
RUN yum -y install gcc gcC-Ct make pcre pcre-devel expat-devel perl
ADD apr-1.6.2.tar.gz /opt/
ADD apr-util-1.6.0.tar.gz /opt/
ADD httpd-2.4.29.tar.bz2 /opt/
RUN mv /opt/apr-1.6.2 /opt/httpd-2.4.29/srclib/apr && \
mv /opt/apr-util-1.6.0 /opt/httpd-2.4.29/srclib/apr-util &&\
cd /opt/httpd-2.4.29 &&\
./configure --pref ix=/usr/local/httpd --enable-5o --enable-rewrite --enable-charset-lite -enable-cgi &&\
make -j2 &&\
make install
##阶段二
FROM centos:7
#把上一个阶段的结果,仿制到这个阶段进行运用
COPY -- from=0 /usr/local/httpd/ /usr/local/httpd/
RUN yum instalil -y pcre pcre-devel expat-devel perl
#露出端口
EXPOSE 80
#指定容器运转时履行的指令
CMD ["/user/local/httpd/bin/ apachect","-D","FOREGROUND"]

构建dockerfile的时刻传参

FROM centos:7
ARG INPUY_VAR
RUN echo $INPUY_VAR

ARG与ENV

ENV所输出的值，始终会掩盖ARG传入的值

VOLUME能够避免用户忘记运用-v发动容器导致容器数据的丢掉

假如用户在运转容器的时分运用了-v指定了挂载目录，此刻VOLUME指令就不会收效，只要在不-v的时分起作用

总结

怎么把我的镜像体积给缩小?

根底镜像尽量运用轻量级最小化的镜像。
Dockerfile中尽量把RUN指令合并在一起，削减镜像的层数（由于每一个RUN指令便是一个镜
多级构建（拿Dockerfile构建好的镜像再构建一次)。

创立镜像

依据本机镜像创立

依据镜像docker run运转容器，在容器中增修改的操作
运用指令docker commit提交成新的镜像

依据容器模板文件创立

docker export将容器导出为模板文件
运用指令docker import将模板文件导入成镜像

依据Dockerfile构建镜像

Dockerfile结构大致分为四个部分:根底镜像信息（用from指定)、保护者信息 (maintainer.镜像操作指令和容器发动时履行指令。

第一行有必要运用FROM指令指明所依据的镜像称号;
之后运用MAINTAINER指令阐明保护该镜像的用户信息;
然后是镜像操作相关指令，如RUN指令/EXPOSE/ADD/ENV/ARG等等。每运转一条指令，都会给根底镜像增加新的一层。(多条指令能够运用;或&&合并成一条指令，削减镜像的层数)
最终运用CMD或许ENTRYPOINT指令指定发动容器时要运转的指令操作。

发动时运转的优先级

docker run –entrypoint 指令 > ENTRYPOINT 发动指令 >docker run 镜像指令 > CMD 默许发动指令

ADD 与 COPY 的差异

共同点：都能仿制本地文件/目录到镜像中
差异：COPY只能仿制本地文件/目录，而ADD还能经过URL下载文件仿制到镜像中，ADD还有能把本地tar包解压成目录仿制到镜像的功能，但ADD不能一起把经过URL下载的tar包进行解压仿制到镜像中

镜像的文件类型

UNTONFS 联合文件体系

存储驱动 overlay2

镜像的组成

镜像由bootfs（加载内核） rootfs（镜像层、只读）两个部分组成

Dockerfile创建镜像

Docker镜像的创立

依据现有镜像创立

docker export 将容器导出

docker commit将容器提交为新的镜像

操作进程

依据本地模板创立

操作进程

依据Dockerfile 创立

联合文件体系(UnionFS)

镜像加载原理

Docker 镜像结构的分层

容器层的文件操作

文件操作阐明

在容器中进行删去操作

演示进程

原因

为什么Docker里的centos的巨细才200M？

Dockerfile

Docker镜像结构的分层

Dockerfile 操作指令的指令

Dockerﬁle简介

Dockerﬁle常见指令

Dockerfile操作常用的指令

FROM 镜像

MAINTAINER 姓名

RUN 指令

ENTRYPOINT

CMD

容器运转时的优先级

ENTRYPOINT和CMD的差异

EXPOSE 端口号

ENV

ADD

注意事项

ADD的优缺陷

COPY

ADD和COPY比较：（同样需求下，官方推荐运用 COPY）

VOLUME [“目录”]

USER 用户/UID

WORKDIR 途径

ONBULD 指令

AGR

创立镜像

在编写Dockerfile 时，有严格的格局需求遵从

Dockerfile事例实战

Dockerfile编写进程

事例1：yum源装置Apache

事例2：编译装置Apache

事例3：编译装置Nginx

多阶段构建容器

构建dockerfile的时刻传参

ARG与ENV

VOLUME能够避免用户忘记运用-v发动容器导致容器数据的丢掉

总结

怎么把我的镜像体积给缩小?

创立镜像

依据本机镜像创立

依据容器模板文件创立

依据Dockerfile构建镜像

发动时运转的优先级

ADD 与 COPY 的差异

镜像的文件类型

镜像的组成

相关文章

从数字化概念到落地，都说是一道坎，JNPF能为企业带来什么呢？​

前端之虎陈随易-我的产品变现秘诀

程序员赚钱案例库#2 ToB的Google Photos(tagbox.io)

Java 字符串 String、StringBulider和StringBuffer

作者信息

从数字化概念到落地，都说是一道坎，JNPF能为企业带来什么呢？