标签白话容器下的文章

2019-01-21

2019年01月21日
3,389 阅读
0 评论
0 点赞

2019-01-18

2019年01月18日
3,518 阅读
0 评论
0 点赞

2019-01-17

linuxea:白话容器之CPU与内存资源限制概述(24) 我们知道容器能够运行，依赖内核的两个特性，一个是名称空间，一个是控制组。默认在docker中是没有任何资源限制的，在某些极端情况下能够几乎耗尽docker主机之上的所有资源。在此基础之上docker provides提供了一个控制容器能够使用多少内存，cpu，io，我们可以进行控制cpu和内存，而IO较弱控制。而其中的内存是非可压缩资源，CPU是可压缩资源。当容器内的进程耗尽CPU时，并且申请更多内存时候，可能会产生OOM。而CPU则不会出现这种问题。这些资源的限制依赖于capabilities资源限制从名称空间和cgroup来进行定义MemoryOOM如果在linux主机上，内核探测到当前宿主机已经没有足够内存可用于执行某些重要的系统功能，就会抛出OOME，并且开始启动kill 进程，以便于释放资源。一旦发生OOME，任何进程都有可能会被杀死，包括docker daemon在内如果内核发现内存被几乎耗尽无法执行本身的运作的时候，会进行检测使用内存异常的hogs进程。但是并不是使用内存最多的就是被杀掉的进程。这可能取决于，申请的内存总大小内耗尽比例来取决最佳被杀掉的进程，这个列表顺序可能是逆序的。为此，docker特地调整了docker daemon的OOM优先级，但是容器的优先级并未调整。为了便于控制，引入了一个oom-adj的功能，以防止系统中的重要进程被杀死，并定义要杀死的进程的顺序。oom_adj的可能值范围为-17到+15。分数越高，相关过程越有可能被OOM杀手杀死。如果 oom_adj设置为-17，则不会考虑将该进程用于OOM查杀。在每一个进程可以分配一个OOM-score的得分计算，根据其不良分数选择在内存不足情况下被杀死，，这个得分计算根据内存的申请的空间参考：https://lwn.net/Articles/317814/ https://lwn.net/Articles/391222/ https://lwn.net/Articles/548180/ https://lwn.net/Articles/391206/对于一些非常重要的容器，在启动的时候就需要调整oom_adj，另外也可以定义容器的策略，在出现OOM被kill后就restart默认是没有对资源限制的，限制容器的内存和CPU资源是有选项可以使用：内存资源raw,swap| `-m` 要么 `--memory=` | 限制容器使用内存，单位是k,b,m,g作为单位使用，可单独使用 | | `--memory-swap`* | 允许此容器交换到磁盘的内存量。查看[`--memory-swap`详情](https://docs.docker.com/config/containers/resource_constraints/#--memory-swap-details)。这个选项生效依赖于raw的选项是否配置 | | `--memory-swappiness` | 默认情况下，主机内核可以交换容器使用的匿名页面的百分比。您可以设置`--memory-swappiness`0到100之间的值，以调整此百分比。查看[`--memory-swappiness`详情](https://docs.docker.com/config/containers/resource_constraints/#--memory-swappiness-details)。 0并不是不使用| | `--memory-reservation` | 允许您指定小于软件限制的软限制`--memory`，当Docker检测到主机上的争用或内存不足时，该限制将被激活。如果使用`--memory-reservation`，则必须将其设置为低于`--memory`优先级。因为它是软限制，所以不保证容器不超过限制。 | | `--kernel-memory` | 容器可以使用的最大内核内存量。允许的最小值是`4m`。由于内核内存无法换出，因此内核内存不足的容器可能会阻塞主机资源，这可能会对主机和其他容器产生副作用。查看[`--kernel-memory`详情](https://docs.docker.com/config/containers/resource_constraints/#--kernel-memory-details)。 | | `--oom-kill-disable` | 默认情况下，如果发生内存不足（OOM）错误，内核会终止容器中的进程。要更改此行为，请使用该`--oom-kill-disable`选项。仅在已设置`-m/--memory`选项的容器上禁用OOM杀手。如果`-m`未设置该标志，则主机可能会耗尽内存，并且内核可能需要终止主机系统的进程才能释放内存。 |参考:https://docs.docker.com/config/containers/resource_constraints/#limit-a-containers-access-to-memory--memory-swap和memory联系与区别memswapmemory功能正数s正数M容器可用中总空间为s，其中ram为M，swap为(s-m)，若S=M，则无可用swap资源。这里的可用内存并不是s+m！0正数M下相当于未设置swap不设置正数M若主机(docker host)启用了swap，则容器的可用swap为2*M-1正数M若主机(docker host)启用了swap，则容器可使用最大至宿主机上的所有swap空间的swap资源容器内使用free命令看到的swap空间并不具有其所展现出的空间的指示意义CPU每一个容器都可以使用宿主机上所有的CPU资源。作为用户来讲，可以设置各种约束来限制给定容器访问主机的CPU额度。我们知道,CPU的核心数是少于进程数的，一个系统之上运行了很多个进程，运行的进程数量大于核心数量的时候，那个才是优先被运行？大多数用户使用和配置是由CFS调度程序来决定的。内核管理中最重要的一个组件CFS(Completely Fair Scheduler)，处理调度进程在本地的核心之上，用于普通Linux进程的Linux内核CPU调度程序。多个运行时标志允许您配置容器具有的CPU资源访问量。使用这些设置时，Docker会修改主机上容器的cgroup的设置。然而每个进程都是有优先级的，这种非实时优先级，有效范围是100-139，这个范围是可以使用nice(niceness scale)进行调整,-20到19,数字越小优先级越高。默认nice值为零。在1.13及更高版本中，支持实时调度程序。另外，还有实时优先级，0-99，默认范围为1到99，这些都是内核级的。然后100到139用于用户空间(非实时)，调度器CFS就是调度这些100-139之间的进程的延伸阅读：CFS: https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txtCFS: https://en.wikipedia.org/wiki/Completely_Fair_Scheduler进程调度：https://en.wikipedia.org/wiki/Completely_Fair_SchedulerCPU调度：https://www.studytonight.com/operating-system/cpu-scheduling进程优先级调整:https://bencane.com/2013/09/09/setting-process-cpu-priority-with-nice-and-renice/https://developer.ibm.com/tutorials/l-lpic1-103-6/https://www.ostechnix.com/change-priority-process-linux/https://www.nixtutor.com/linux/changing-priority-on-linux-processes/https://www.tecmint.com/set-linux-process-priority-using-nice-and-renice-commands/CPU资源也分为io密集型和CPU密集型，对于cpu密集型的可能需要调低优先级，当调度后就会耗时较长，而IO密集型是IO调度。对于占用很长时间的进程动态调低优先级，对于那些占用CPU很少又经常调度不上去的(CPU)将会调整高一些。CPU分配：选项描述--cpus=<value>指定容器可以使用的可用CPU资源量。例如，如果主机有两个CPU并且您已设置--cpus="1.5"，则容器最多保证一个半CPU。这相当于设置--cpu-period="100000"和--cpu-quota="150000"。可在Docker 1.13及更高版本中使用。--cpu-period=<value>指定CPU CFS调度程序周期，它与并用 --cpu-quota。默认为100微秒。大多数用户不会更改默认设置。如果您使用Docker 1.13或更高版本，请--cpus改用。--cpu-quota=<value>对容器施加CPU CFS配额。--cpu-period限制前容器限制为每秒的微秒数。作为有效上限。如果您使用Docker 1.13或更高版本，请--cpus改用。--cpuset-cpus限制容器可以使用的特定CPU或核心。如果您有多个CPU，则容器可以使用的以逗号分隔的列表或连字符分隔的CPU范围。第一个CPU编号为0.有效值可能是0-3（使用第一个，第二个，第三个和第四个CPU）或1,3（使用第二个和第四个CPU）。--cpu-shares将此标志设置为大于或小于默认值1024的值，以增加或减少容器的重量，并使其可以访问主机的CPU周期的较大或较小比例。仅在CPU周期受限时才会强制执行此操作。当有足够的CPU周期时，所有容器都会根据需要使用尽可能多的CPU。这样，这是一个软限制。--cpu-shares不会阻止容器以群集模式进行调度。它为可用的CPU周期优先考虑容器CPU资源。它不保证或保留任何特定的CPU访问权限。参考：https://docs.docker.com/config/containers/resource_constraints/#configure-the-default-cfs-scheduler而--cpu-shares是按照比例切分。1024:512比如当前系统上运行了两个人容器，第一个容器是1024，第二个容器是512，假如这俩个容器都需要可能多的使用CPU。假如CPU资源有100份(100%)，分为2分之一，各占512，而CPU资源以512为单位分为三份在两个容器上，如下：第一个容器占2份，而第二个容器占用1份，如果此时第二个容器启动后并没有占用CPU，那么第一个容器就可以占用第二个容器的512，这种方式就是共享式。在需要的时候就分配需要的额度，不需要的时候就给需要的使用。1024:512:2048假如现在有更大的比例，如下图这样一来就是分为了七份，2+1+4，分七份后后可用资源占用比例就不一样了,最后的2048是分成了4份542。同样，如果其中某一份容器或多个容器暂时不占用分配自己的CPU资源，仍然会被其他繁忙的容器所占用全部。也就是说，只要容器都在使用，就按照比例分配，如果只有一个使用，其他的不使用，这个使用的容器能够占用所有的CPU资源。如果有两个在使用，就按照剩下的比例分配给使用的，这个过程是随时动态调整的。任何一个容器不使用，就会被其他使用的容器说分配掉。CPU是可压缩资源，可随时加入更多的容器使用，只不过不同的分法，得到的结果不一样而已。CPU可压缩资源通过共享方式来分派，可压缩，也可随时调整比例。CPUshares有一特点，假如有4核心cpu，其中没一个容器的进程可任意调度到任何一个核心上面运行。一共使用1024比例，但是另外2个容器都不运行，那这个容器就不单单有一颗CPU的运算能力，而是有4颗CPU的运算能力，一颗CPU是100%，4个就相当于有400%的CPU。--cpus当然，也可以限制，假设如果一共有4核心，一个进程最多使用2个核心，且无论其他CPU空闲超过2个以上或者其他，被限制的cpu只能使用2核心，另外两个核心是空闲的(任意取其二，剩下不取) 。如下图左假设使用限制是2核心，也就是说，在4核心的cpu上使用的最多只能是200%，一个核心为100%，那也就是2颗核心。而现在可能是另外的一种方式，同样适用2核心，最多使用200%，但是却是每个核心各50%，重量不超过200%即可。如下图右但是，我们也可以限制核心数。--cpuset-cpus--cpus意味着这个进程只能运行在那个CPU核心。假如有4个核心，用的是0和3进行编号，那1和2就不能使用这些分配可以分为几种：1，按照压缩方式比例分配2，限定最多使用的核心数3，限定使用那些个CPU假如只有--cpuset-cpus限制了只能使用的0和1，那说明只能使用两个CPU，也就是200%，也可以限制使用的cpu时间周期和配额，这些选项在run或create时间使用。

2019年01月17日
4,027 阅读
0 评论
0 点赞

2019-01-16

linuxea:白话容器之dockerfile ARG和ONBUILD使用(6)(23) shell该SHELL指令允许覆盖用于shell形式的命令的默认shell 。Linux上的默认shell是["/bin/sh", "-c"]，而在Windows上["cmd", "/S", "/C"]。该SHELL指令必须以JSON格式写入Dockerfile。参考：https://docs.docker.com/engine/reference/builder/#shellSTOPSIGNAL该STOPSIGNAL指令设置将发送到容器的系统调用信号以退出。此信号可以是与内核的系统调用表中的位置匹配的有效无符号数，例如9，或SIGNAME格式的信号名，例如SIGKILL，例如15，停止容器。如果要发送其他的信号就要在这里定义STOPSIGNAL signalARGARG指令定义了一个变量，可以docker build使用该--build-arg <varname>=<value> 标志在构建时将该变量传递给构建器。这样定义的Dockerfile可以适用于较多的场景，尤其是程序版本迭代。如果指定了未在Dockerfile中定义的构建参数，则构建会输出警告。示例：定义ARG author默认是"linuxea.com.cn"ARG author="linuxea.com.cn" LABEL maintainer="${author}"[root@linuxEA-145 /data/linuxea3]$ cat Dockerfile FROM nginx:1.14.2-alpine ARG author="linuxea.com.cn" LABEL maintainer="${author}" ENV NGINX_ROOT="/data/wwwroot" ADD entrypoint.sh /bin/entrypoint.sh ADD index.html ${NGINX_ROOT}/ EXPOSE 8080/tcp 80/tcp HEALTHCHECK --interval=3s --timeout=3s --start-period=3s CMD wget -O - -q http://${IP:-0.0.0.0}:${NGPORT:-80}||exit 1 #HEALTHCHECK --start-period=3s CMD wget -O - -q http://${IP:-0.0.0.0}:${NGPORT} || exit 1 CMD ["/usr/sbin/nginx","-g","daemon off;"] ENTRYPOINT ["/bin/entrypoint.sh"]build[root@linuxEA-145 /data/linuxea3]$ docker build --build-arg author="mark www.linuxea.com" -t marksugar/nginx:v5 .查看，marksugar/nginx:v5的Labels是默认的linuxea.com.cn[root@linuxEA-145 /data/linuxea3]$ docker inspect -f {{.ContainerConfig.Labels}} marksugar/nginx:v5 map[maintainer:linuxea.com.cn]而后重新build，重新赋值--build-arg author="mark www.linuxea.com"[root@linuxEA-145 /data/linuxea3]$ docker build --build-arg author="mark www.linuxea.com" -t marksugar/nginx:v6 .而后在查看，赋值被生效[root@linuxEA-145 /data/linuxea3]$ docker inspect -f {{.ContainerConfig.Labels}} marksugar/nginx:v6 map[maintainer:mark www.linuxea.com]ONBUILDdocker onbuild用于指定当前的docker镜象用作另一个镜象的基本镜象时候运行的命令，在使用前，需要一个静态的基本镜象，而后其动态配置会在新的镜象（子镜象）发生作用，或者在新镜象依赖之前构建镜象的情况下使用！ONBUILD用于在Dockerfile中定义一个触发器，Dockerfile用于build镜像文件，此镜像文件可作为base image被另一个Dockerfile用作FROM指令的参数，并以之构建新的映像文件疑问当使用各种指令创建一个dockerfile，并在dockerfile指定了onbuild指令，当我们使用docker build使用当前的dockerfile构建镜象的时候，将会创建一个新的docker镜象，但onbuild指令不会应用于当前的docker镜象，仅仅作为将要创建新的景象用作为另外一个dockerfile中的基本镜象时候，才会应用此选项。在后面的这个Dockerfile中的FROM指令在build过程中被执行时，将会“触发”创建其base image的Dockerfile文件中的ONBUILD指令定义的触发器ONBULD <INSTRUCTION>尽管任何指令都可注册成为触发器指令，但ONBUILD不能自我嵌套，且不会触发FROM和MAINTAINER指令使用包含ONBUILD指令的Dockerfile构建的镜像应该使用特殊的标签，例如：mysql:5.6-onbuild在ONBUILD指令中使用ADD或COPY指令如果缺少指定的源文件时会失败(比如二次build copy，本地却无文件)。多数情况下，ONBUILD会执行ADD或者RUN进行下载安装等。也就说ONBUILD不会在自己构建的时候执行，而是在被其他人使用作为基础镜像的时候才会执行。添加一条ONBUILD，示例如下：ONBUILD ADD http://10.10.240.145/CentOS-Base.repo /etc/如下:[root@linuxEA-145 /data/linuxea3]$ cat Dockerfile FROM nginx:1.14.2-alpine ARG author="linuxea.com.cn" LABEL maintainer="${author}" ENV NGINX_ROOT="/data/wwwroot" ADD entrypoint.sh /bin/entrypoint.sh ADD index.html ${NGINX_ROOT}/ EXPOSE 8080/tcp 80/tcp HEALTHCHECK --interval=3s --timeout=3s --start-period=3s CMD wget -O - -q http://${IP:-0.0.0.0}:${NGPORT:-80}||exit 1 #HEALTHCHECK --start-period=3s CMD wget -O - -q http://${IP:-0.0.0.0}:${NGPORT} || exit 1 ONBUILD ADD http://10.10.240.145/CentOS-Base.repo /etc/ CMD ["/usr/sbin/nginx","-g","daemon off;"] ENTRYPOINT ["/bin/entrypoint.sh"]而后build为marksugar/httpd:v7[root@linuxEA-145 /data/linuxea3]$ docker build -t marksugar/httpd:v7 . Sending build context to Docker daemon 4.608kB Step 1/11 : FROM nginx:1.14.2-alpine ---> d956af1ad36a Step 2/11 : ARG author="linuxea.com.cn" ---> Using cache ---> c4c543206ad1 Step 3/11 : LABEL maintainer="${author}" ---> Using cache ---> 36edfcb86dfb Step 4/11 : ENV NGINX_ROOT="/data/wwwroot" ---> Using cache ---> 6547ed95f45a Step 5/11 : ADD entrypoint.sh /bin/entrypoint.sh ---> Using cache ---> d650f4dcb46c Step 6/11 : ADD index.html ${NGINX_ROOT}/ ---> Using cache ---> 865b4df58910 Step 7/11 : EXPOSE 8080/tcp 80/tcp ---> Using cache ---> 1454ea1fc5e3 Step 8/11 : HEALTHCHECK --interval=3s --timeout=3s --start-period=3s CMD wget -O - -q http://${IP:-0.0.0.0}:${NGPORT:-80}||exit 1 ---> Using cache ---> 157834157357 Step 9/11 : ONBUILD ADD http://10.10.240.145/CentOS-Base.repo /etc/ ---> Running in 37e29f61d449 Removing intermediate container 37e29f61d449 ---> f334451b2c4c Step 10/11 : CMD ["/usr/sbin/nginx","-g","daemon off;"] ---> Running in d3b24f896853 Removing intermediate container d3b24f896853 ---> b9307347b1ce Step 11/11 : ENTRYPOINT ["/bin/entrypoint.sh"] ---> Running in cd1f126e961f Removing intermediate container cd1f126e961f ---> a79987f1e18a Successfully built a79987f1e18a Successfully tagged marksugar/httpd:v7[root@linuxEA-145 /data/linuxea3]$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE marksugar/httpd v7 a79987f1e18a About a minute ago 17.7MB重新写一个Dockerfile，调用刚刚构建的marksugar/httpd:v7[root@linuxEA-145 /data/linuxea4]$ cat Dockerfile FROM marksugar/httpd:v7 RUN echo "helo" >> /tmp/linuxea.txt在build的时候，就会执行上一个Dockerfile中的ONBUILD命令，如下：[root@linuxEA-145 /data/linuxea4]$ docker build -t onbuild:1 . Sending build context to Docker daemon 2.048kB Step 1/2 : FROM marksugar/httpd:v7 # Executing 1 build trigger Downloading [==================================================>] 1.664kB/1.664kB ---> b64f3cd2ba7f Step 2/2 : RUN echo "helo" >> /tmp/linuxea.txt ---> Running in e9f45b68bb24 Removing intermediate container e9f45b68bb24 ---> 63bced5b493c Successfully built 63bced5b493c Successfully tagged onbuild:1而后run起来验证下[root@linuxEA-145 /data/linuxea4]$ docker run --name onbuild --rm onbuild:1 ls /etc/CentOS-Base.repo /etc/CentOS-Base.repo[root@linuxEA-145 /data/linuxea4]$ docker run --name onbuild --rm onbuild:1 cat /etc/CentOS-Base.repo # CentOS-Base.repo # # The mirror system uses the connecting IP address of the client and the # update status of each mirror to pick mirrors that are updated to and # geographically close to the client. You should use this for CentOS updates # unless you are manually picking other mirrors. # # If the mirrorlist= does not work for you, as a fall back you can try the # remarked out baseurl= line instead. # # [base] name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 ...

2019年01月16日
4,001 阅读
0 评论
0 点赞

2019-01-14

2019年01月14日
4,406 阅读
0 评论
0 点赞

2019-01-13

linuxea:白话容器之dockerfile COPY与ADD的最佳实践(4)(21) COPY与ADD的最佳实践COPY和ADD是可以将文件放入容器中，那么最好的用法是COPY而不是ADD，当然了，除非文件是tar包并且像自动解压此Dockerfile指令将一个或多个本地文件或文件夹复制到Docker镜像中的目标中。COPY <source>... <destination>COPY ["<source>",... "<destination>"] （包含空格的路径）使用COPY的示例Dockerfile这是COPY在Dockerfile中使用Ruby应用程序的方法。FROM ruby:2.5.1 WORKDIR /usr/src/app COPY Gemfile Gemfile.lock ./ RUN bundle install COPY . . CMD ["./your-daemon-or-script.rb"]它积聚在镜象中的层，先从父镜象ruby:2.5.1，使用所定义FROM。Docker指令WORKDIR为其后面的COPY或者ADD 指令定义工作目录使用COPY它时，会将文件从本地源（在本例 .中为当前目录中的文件）复制到定义的位置WORKDIR。在上面的示例中，第二个 .引用镜象中工作目录中的当前目录。使用COPY创建镜象图层的最佳做法Docker建议使用COPY以在不同镜象层中保存不同文件上下文的方式创建镜象层。这意味着重建镜象是有效的。最不可能更改的文件应位于较低层，而最可能更改的文件应最后添加。如果您有多个Dockerfile步骤使用上下文中的不同文件，则COPY它们是单独的，而不是一次性完成。这可确保每个步骤的构建缓存仅在特定所需文件更改时失效（强制重新执行该步骤）。编写Dockerfiles的最佳实践上面的Dockerfile示例演示了此原则。通过复制Gemfiles，然后RUN bundle install 使用已安装的Ruby Gems创建一个镜象层，可以对其进行缓存。最后两条Docker指令将应用程序的文件复制到镜象中，并使用默认命令设置CMD。这意味着如果您更改任何应用程序的文件，则可以使用缓存的父级和中间层重建Docker镜像。这比从头开始构建所有这些更有效。为什么不应该使用ADD该ADD指令具有类似的语法COPY。除了将本地文件和目录复制到Docker镜像中的目标之外，它还具有一些附加功能。ADD <source>... <destination>ADD ["<source>",... "<destination>"] （包含空格的路径）但是，Docker的Dockerfile最佳实践官方指南指出，这COPY是ADD大多数用途中的首选指令。一般而言，虽然*ADD* and *COPY*在功能上类似，但是*COPY*是优选的。那是因为它更透明*ADD*。*COPY*仅支持将本地文件基本复制到容器中，同时*ADD*具有一些功能（如仅限本地的tar提取和远程URL支持），这些功能并不是很明显。因此，最好的用途*ADD*是将本地tar文件自动提取到镜象中如：编写Dockerfiles的最佳实践*ADD rootfs.tar.xz /*其中一个ADD附加功能是它可以从URL复制文件，但Docker建议不要将其用于此目的。从URL复制文件的最佳做法如果ADDsource是URL，它将下载文件并将其复制到Docker镜像中的目标位置。docker表明，它往往是效率不高，从使用URL复制ADD，这是最好的做法，以使用其他策略，包括所需的远程文件。由于镜象大小很重要，ADD因此强烈建议不要使用从远程URL获取包。你应该使用curl或wget代替。这样，您可以删除提取后不再需要的文件，也不必在镜象中添加其他图层。 - Dockerfile最佳实践例如，你应该避免做以下事情：ADD http://example.com/big.tar.xz /usr/src/things/ RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things RUN make -C /usr/src/things all而是做一些像：RUN mkdir -p /usr/src/things \ && curl -SL http://example.com/big.tar.xz \ | tar -xJC /usr/src/things \ && make -C /usr/src/things all什么时候可以使用ADD如果<source>是具有可识别压缩格式的本地 tar存档，则它会自动解压缩为Docker镜像中的目录。例如：ADD rootfs.tar.xz /。这是Dockerfiles 中ADDover 的主要推荐用法COPY。对于不需要ADDtar自动提取功能的其他项目（文件，目录），应该始终使用COPY。

2019年01月13日
3,093 阅读
0 评论
0 点赞

2019-01-12

linuxea:白话容器之dockerfile CMD/entrypoint详解3(20) 此前的RUN和CMD，我们知道，RUN是构建的时候运行的命令，在镜像完成后RUN就运行结束。随后推送到仓库中，这些RUN命令是不会在进行运行的。-　init在Docker上下文中，一个Docker只会运行一个应用程序，那么应该运行那个程序，又是什么应用？一般情况下，能拥有生产能力的应用通常在宿主机上一般表现是运行在后台守护进程程序，如：mysql,nginx等。这些服务在运行时候，都是以某个进程运行。某个进程都应该是某个进程的子进程，除init之外，而init是由内核启动的，一般我们在启动一个进程的时候，是以shell的子进程运行的，在命令行下创建的任何进程都是shell的子进程，而有一些经常也会直接占据shell的终端设备，就算使用&放置后台，启动的父进程也仍然是shell。进程终止的时候会将所有的子进程销毁，这种情况下我们会使用nohub command &，这样一来就类似于将启动的进程init那么在Docker中运行的init进程(init的id是1)是由内核启动，还是托管shell启动。如果基于内核启动 ls /etc/* ,|等shell特性是无法使用的，那么如果基于shell启动，那init的id就不再是1了exec假如想基于shell的方式来启动一个主进程，那么shell的id号就是1，而后基于此在启动主进程，但是这样一来shell就不能退出，那可能需要一种能够剥离终端的方式启动，但是剥离了终端的方式启动，主进程号又不是1了。不过，我们可以使用exec来解决，shell启动是没有问题，进程号id是1也没有关系，exec顶替shell的id为1，取代shell进程，shell退出后exec就成了id为1的进程。在很多时候，在容器内启动一个应用程序的时候可以不基于shell，直接启动也可以，也可以基于shell，如果基于shell启动，并且不违背shell主进程id为1的调节关系，那么就可以使用第二种方式，exec。CMDRUN是构建的镜象build时候执行的，而cmd是定义一个镜象文件启动为容器时候默认要运行的程序，而Docker容器默认运行一个程序，在运行CMD的时候，是可以写多条CMD的，而最后一条CMD是生效的。而RUN是可以从上倒下接多RUN命令逐一运行。CMD类属于RUN命令，CMD指令也可以用于运行任何命令或应用程序，不过，二者的运行时间点不同RUN指令运行与映像文件构建过程中，而CMD指令运行于基于Dockerfile构建出的新映像文件启动一个容器时CMD指令的首要目的在于为启动的容器指定默认要运行的程序，且运行结束后，容器也将终止；不过，CMD指令的命令其可以被Docker run命令选项所覆盖在Dockerfile中可以存在多个CMD指令，但仅最后一个会生效命令CMD <command> CMD ["<executable>","<paraml>","<param2>"] CMD ["<param1>","<param2>"]前两种语法格式的意义同RUN第一种的CMD的命令执行是直接写命令的，并且PID不为1，也无法接收信号(接收信号的必然是pid为1的超级管理进程)，docker stop也无法停止。第二种直接启动为ID为1的进程，可接受处理shell信号的。第三种则用于ENTRYPOINT指令提供默认参数编写Dockerfile如，创建目录后追加文件，最后用CMD直接调用httpd启动FROM busybox LABEL maintainer="linuxea.com" app="CMD" ENV WEB_ROOT="/data/wwwroot" RUN mkdir -p ${WEB_ROOT} \ && echo '<h1> helo linuxea .</h1>' >> ${WEB_ROOT}/index.html CMD /bin/httpd -f -h ${WEB_ROOT}开始build[root@linuxEA /data/linuxea2]$ docker build -t marksugar/httpd:9 Sending build context to Docker daemon 2.048kB Step 1/5 : FROM busybox ---> 59788edf1f3e Step 2/5 : LABEL maintainer="linuxea.com" app="CMD" ---> Running in b6e91f2461dd Removing intermediate container b6e91f2461dd ---> 53559ed7015a Step 3/5 : ENV WEB_ROOT="/data/wwwroot" ---> Running in 3e615febfd44 Removing intermediate container 3e615febfd44 ---> a7917cb7ecbb Step 4/5 : RUN mkdir -p ${WEB_ROOT} && echo '<h1> helo linuxea .</h1>' >> ${WEB_ROOT}/index.html ---> Running in 15153c929109 Removing intermediate container 15153c929109 ---> 8e5548f3c00a Step 5/5 : CMD /bin/httpd -f -h ${WEB_ROOT} ---> Running in feeb34a9c423 Removing intermediate container feeb34a9c423 ---> a091b6d8a31d Successfully built a091b6d8a31d Successfully tagged marksugar/httpd:9从这里可以看到，这条启动命令是/bin/sh启动的子进程，在此后启动的时候会替换成id1，也就是默认执行exec将/bin/sh替换掉[root@linuxEA /data/linuxea2]$ docker inspect marksugar/httpd:9 ... "Cmd": [ "/bin/sh", "-c", "/bin/httpd -f -h ${WEB_ROOT}" ... 而后run起来，但是这里是没有交互式接口的，尽管使用了-it[root@linuxEA /data/linuxea2]$ docker run --name linuxea --rm -it marksugar/httpd:9 不过，可以使用exec进入容器，/bin/httpd -f -h /data/wwwroot的id为1我们在Dockerfile中直接使用命令的方式避免他不是1，那么这里就直接启动为1，默认执行力exec替换。这也就说明了，尽管使用-it仍然进入不了容器的原因，init1的进程不是shell。进入就要在使用exec绕过进入[root@linuxEA ~]$ docker exec -it linuxea sh / # ps aux PID USER TIME COMMAND 1 root 0:00 /bin/httpd -f -h /data/wwwroot 7 root 0:00 sh 13 root 0:00 ps aux / # 第二种格式CMD ["/bin/httpd","-f","-h ${WEB_ROOT}"]以这种方式进行buildFROM busybox LABEL maintainer="linuxea.com" app="CMD" ENV WEB_ROOT="/data/wwwroot" RUN mkdir -p ${WEB_ROOT} \ && echo '<h1> helo linuxea .</h1>' >> ${WEB_ROOT}/index.html #CMD /bin/httpd -f -h ${WEB_ROOT} CMD ["/bin/httpd","-f","-h ${WEB_ROOT}"]启动就会报错No such file[root@linuxEA /data/linuxea2]$ docker run --name linuxea --rm -it marksugar/httpd:10 httpd: can't change directory to ' ${WEB_ROOT}': No such file or directory报错No such file是因为CMD ["/bin/httpd","-f","-h ${WEB_ROOT}"]并不会运行成shell的子进程，而此变量是shell的变量，内核却不知道这个路径，所以会报错。不过，我们可以指定为shell，如： CMD ["/bin/sh","-c","/bin/httpd","-f","-h ${WEB_ROOT}"]引言此前我们使用一条命令运行容器的时候，CMD的指令是可以被覆盖的，如下[root@linuxEA ~]$ docker run --name linuxea --rm -it marksugar/httpd:9 ls /etc group hosts mtab passwd shadow hostname localtime network resolv.conf上面这条命令是说，运行这个容器，ls /etc覆盖了此前镜像中的CMD中的启动httpd的命令。但是有时候我们不希望被覆盖，就使用ENTRYPOINTENTRYPOINT类似于CMD指令的功能，用于为容器指定默认的运行程序，从而使得容器像是一个单独的可执行文件与CMD不同的是由ENTRYPOINT启动的程序不会被docker run命令行指定的参数所覆盖，而且，这些命令行参数会被当作参数传递给ENTRYPOINT指令的指定程序不过，docker run命令--entrypoint选项参数可覆盖ENTRYPOINT指令指定的程序ENTRYPOINT <command> ENTRYPOINT ["<executable>","<param1>","<param2>"]docker run命令传入的命令参数会覆盖CMD指令的内容并且附加到ENTRYPOINT命令最后作为其参数使用Dockerfile文件中也可以存在多个ENTRYPOINT指令，但仅有最后一个生效我们先编写一个Dockerfile，使用NETRYPOINT启动FROM busybox LABEL maintainer="linuxea.com" app="CMD" ENV WEB_ROOT="/data/wwwroot" RUN mkdir -p ${WEB_ROOT} \ && echo '<h1> helo linuxea .</h1>' >> ${WEB_ROOT}/index.html ENTRYPOINT /bin/httpd -f -h ${WEB_ROOT}而后build[root@linuxEA /data/linuxea2]$ docker build -t marksugar/httpd:11 . Sending build context to Docker daemon 2.048kB Step 1/5 : FROM busybox ---> 59788edf1f3e Step 2/5 : LABEL maintainer="linuxea.com" app="CMD" ---> Using cache ---> 53559ed7015a Step 3/5 : ENV WEB_ROOT="/data/wwwroot" ---> Using cache ---> a7917cb7ecbb Step 4/5 : RUN mkdir -p ${WEB_ROOT} && echo '<h1> helo linuxea .</h1>' >> ${WEB_ROOT}/index.html ---> Using cache ---> 8e5548f3c00a Step 5/5 : ENTRYPOINT /bin/httpd -f -h ${WEB_ROOT} ---> Running in 34c028efac0d Removing intermediate container 34c028efac0d ---> b7be6f74fc65 Successfully built b7be6f74fc65 Successfully tagged marksugar/httpd:11启动是没有问题的[root@linuxEA /data/linuxea2]$ docker run --name linuxea --rm -it marksugar/httpd:11我们获取到这个ip。访问试试[root@linuxEA ~]$ docker inspect -f {{.NetworkSettings.IPAddress}} linuxea 192.168.100.2[root@linuxEA ~]$ curl 192.168.100.2 <h1> helo linuxea .</h1>ENTRYPOINT而后使用CMD的方式同样来覆盖[root@linuxEA /data/linuxea2]$ docker run --name linuxea --rm -it marksugar/httpd:11 ls /etc容器依然运行起来，但我们并没有看到ls /etc的内容。这是因为在run的时候使用了ls /etc并不会替换Dockerfile中ENTRYPOINT的运行命令，只是在ENTRYPOINT命令之后加了ls /etc，而httpd识别不出ls /etc而已如果一定要进行覆盖，就需要使用--entrypoint，如下：docker run --name linuxea --rm -it --entrypoint "/bin/ls" marksugar/httpd:11 -al /etc[root@linuxEA ~]$ docker run --name linuxea --rm -it --entrypoint "/bin/ls" marksugar/httpd:11 -al /etc total 28 drwxr-xr-x 1 root root 66 Dec 8 09:07 . drwxr-xr-x 1 root root 6 Dec 8 09:07 .. -rw-rw-r-- 1 root root 307 Sep 6 20:11 group -rw-r--r-- 1 root root 13 Dec 8 09:07 hostname -rw-r--r-- 1 root root 177 Dec 8 09:07 hosts -rw-r--r-- 1 root root 127 May 4 2018 localtime lrwxrwxrwx 1 root root 12 Dec 8 09:07 mtab -> /proc/mounts drwxr-xr-x 6 root root 79 Oct 1 22:37 network -rw-r--r-- 1 root root 340 Sep 6 20:11 passwd -rw-r--r-- 1 root root 114 Dec 8 09:07 resolv.conf -rw------- 1 root root 243 Sep 6 20:11 shadow示例ENTRYPOINT此时我们知道ENTRYPOINT是作为入口点的指令，通过exec 指定，指定的命令和参数作为一个JSON数组，那就意味着需要使用双引号而不是单引号ENTRYPOINT ["executable", "param1", "param2"]使用此语法，Docker将不使用命令shell，这意味着不会发生正常的shell处理。如果需要shell处理功能，则可以使用shell命令启动JSON数组。ENTRYPOINT [ "sh", "-c", "echo $HOME" ]另一种选择是使用脚本来运行容器的入口点命令。按照惯例，它通常在名称中包含入口点。在此脚本中，您可以设置应用程序以及加载任何配置和环境变量。下面是一个如何使用ENTRYPOINT exec语法在Dockerfile中运行它的示例。COPY ./docker-entrypoint.sh / ENTRYPOINT ["/docker-entrypoint.sh"] CMD ["postgres"]例如，Postgres官方图像使用以下脚本作为其ENTRYPOINT：#!/bin/bash set -e if [ "$1" = 'postgres' ]; then chown -R postgres "$PGDATA" if [ -z "$(ls -A "$PGDATA")" ]; then gosu postgres initdb fi exec gosu postgres "$@" fi exec "$@"docker-compose 的写法：Docker Compose文件中使用的命令是相同的，除了使用小写字母。entrypoint: /code/entrypoint.sh可以在docker-compose.yml中使用列表定义入口点。entrypoint: - php - -d - zend_extension=/usr/local/lib/php/xdebug.so - -d - memory_limit=-1 - vendor/bin/phpunit不过仍然可可以使用docker run --entrypoint或docker-compose run --entrypoint标记覆盖入口的指令CMD/commandCMD（Dockerfiles）/ command（Docker Compose文件）的主要目的是在执行容器时提供默认值。这些将在入口点之后被附加到入口的参数。例如，如果运行docker run <image>，则将执行Dockerfiles中CMD/所指定的命令和参数command。在Dockerfiles中，可以定义CMD包含可执行文件的默认值。例如：CMD ["executable","param1","param2"]如果省略了可执行文件，则还必须指定一条ENTRYPOINT指令。CMD ["param1","param2"] （作为ENTRYPOINT的默认参数）注意：其中只能有一条CMD指令Dockerfile。如果列出多个CMD，则只有最后一个CMD生效。Docker Compose命令使用Docker Compose时，可以在docker-compose.yml中定义相同的指令，但它以小写形式写成完整的单词command。command: ["bundle", "exec", "thin", "-p", "3000"]覆盖CMD可以覆盖CMD运行容器时指定的命令。docker run rails_app rails console如果指定了参数docker run，那么它们将覆盖指定的默认值CMD。语法最佳实践还有EXEC语法，shell语法两个另一个有效的选项ENTRYPOINT和CMD。这将以字符串形式执行此命令并执行变量替换。ENTRYPOINT command param1 param2 CMD command param1 param2CMD应该几乎总是以形式使用CMD [“executable”, “param1”, “param2”…]。因此，如果镜象是用于服务的，例如Apache和Rails，那么你可以运行类似的东西CMD ["apache2","-DFOREGROUND"]`。实际上，建议将这种形式的指令用于任何基于服务的镜象。所述*ENTRYPOINT*shell形式防止任何*CMD*或*run*被使用命令行参数覆盖，但是有缺点，*ENTRYPOINT*将被开始作为一个子命令*/bin/sh -c*，其不通过信号。这意味着可执行文件将不是容器*PID 1*- 并且不会收到Unix信号 - 因此您的可执行文件将不会收到*SIGTERM*来自*docker stop <container>*如果*CMD*用于为*ENTRYPOINT*指令提供默认参数，则应使用JSON数组格式指定*CMD*和*ENTRYPOINT*指令。BothCMD和ENTRYPOINTinstructions指定运行容器时执行的命令。很少有规则描述它们如何相互作用。Dockerfiles应至少指定一个CMD或ENTRYPOINT命令。ENTRYPOINT 应该在将容器用作可执行文件时定义。CMD应该用作定义ENTRYPOINT命令的默认参数或在容器中执行ad-hoc命令的方法。CMD 在使用替代参数运行容器时将被覆盖。延伸阅读：https://docs.docker.com/engine/reference/builder/ https://docs.docker.com/develop/develop-images/dockerfile_best-practices/ https://docs.docker.com/engine/reference/builder/#usage https://docs.docker.com/compose/compose-file/ https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

2019年01月12日
3,869 阅读
0 评论
0 点赞