php容器打包技巧_Docker容器构建最佳实践

文章目录 [+]

一个容器一个运用程序

当开始利用容器时，常见的一个误区是把容器当成虚拟机来使。
这样做每每会让他们不能轻易知足某些需求而非常痛楚，同时也背离了容器的最大上风点。
很多初学者在群里问了很多为么：为什么Docker不能aaa？怎么实现Docker bbb?然后他须要的答案实在上只是须要一个虚拟。
虽然当代容器已经可以知足这些需求，但是这会极大减弱容器模型的大多数优点。
以经典的Apache/MySQL/PHP堆栈为例，你可能很想在一个容器中运行所有组件。
但是，最佳实践是利用两个或三个不同的容器：Apache容器，MySQL容器，和运行PHP-FPM的php容器。

由于容器设计思想是容器和托管的运用程序具有相同的生命周期，因此每个容器应该只包含一个运用程序。
当容器启动时，运用程序随之启动，当容器停滞时，运用也会停滞。

php容器打包技巧_Docker容器构建最佳实践

容器如果支配了多个运用，则它们有可能具有不同的生命周期或处于不同的状态。
例如，一个正在运行的容器，但其核心组件之一溘然崩溃或无相应。
由于没有额外的运行状况检讨，全体容器管理系统（Docker或Kubernetes）将无法判断容器是否康健。
在Kubernetes集群中，容器默认是不会重启的。

（图片来自网络侵删）

有些公共镜像中可能会利用如下有一些的操作，但不遵照原则：

利用进程管理系统（比如supervisor）来管理容器中的一个或多个运用。
利用bash脚本作为容器中的入口点，并使其产生多个运用程序作为后台作业。

旗子暗记处理，PID 1和僵尸进程

Linux旗子暗记是掌握容器内进程生命周期的紧张方法。
为了与前一条最佳实践保持同等，为了将运用程序的生命周期和容器相干，请确保运用程序能够精确处理Linux旗子暗记。
个中最主要的一个Linux旗子暗记是SIGTERM，由于它用来终止进程。
运用可能还会收到SIGKILL旗子暗记，用于非正常地终止进程，或者SIGINT旗子暗记，用于接管，键入的Ctrl + C指令。

进程标识符（PID）是Linux内核为每个进程供应的唯一标识符。
PID具有名称空间，容用具有自己的一组PID，这些PID会被映射到宿主机系统的PID。
Linux内核启动时会创建第一个进程具有PID1。
用来init系统用来管理其他进程，比如systemd或SysV。
同样，容器中启动的第一个进程也是PID1。
Docker和Kubernetes利用旗子暗记与容器内的进程进行通信。
Docker和Kubernetes都只能向容器内具有PID 1的进程发送旗子暗记。

在容器环境中，须要考虑两个PIDs和Linux旗子暗记的问题。

Linux内核如何处理旗子暗记？

Linux内核处理PID 1的进程办法与对其他进程不同。
PID1，不会自动注册旗子暗记量SIGTERM，以是SIGTERM或SIGINT默认对PID 1无效。
默认必须利用SIGKILL旗子暗记来杀掉进程，无法优雅的关闭进程，可能会导致缺点，监视数据写入中断（对付数据存储）以及一些不必要的告警。

范例的初始化系统如何处理伶仃进程？

范例的初始化系统（例如systemd）也用被用来删除（捕获）伶仃的僵尸进程。
僵尸进程（其父进程已去世亡的进程）将会被附加到具有PID 1的进程下，被其捕获关闭。
但是在容器中，须要映射到容器PID 1的进程来处理。
如果该进程无法精确处理，则可能会涌现内存不敷或其他资源不敷的风险。

面对这些问题有几种常见的办理方案：

以PID 1运行并注册旗子暗记处理程序

该方案用来办理第一个问题。
如果运用以受控办法天生子进程（常日是这种情形）是有效的，可以避免第二个问题。
最大略方法是在Dockerfile中利用CMD和/或ENTRYPOINT指令启动你的进程。
例如，下面的Dockerfile中，nginx是第一个也是唯一要启动的进程。

FROM debian:9

RUN apt-get update && \

apt-get install -y nginx

EXPOSE 80

CMD [ "nginx", "-g", "daemon off;" ]

把稳：Nginx进程注册其自己的旗子暗记处理程序。
利用此办理方案，在许多情形下，你必须在运用程序代码中实行相同的操作。

有时可能须要准备容器中的环境以使进程正常运行。
在这种情形下，最佳实践是让容器在启动时运行shell初始化脚本。
该Shell脚本的用来配置所需的环境并启动紧张进程。
但是，如果采取这种方法，则shell脚本拥有PID 1，这便是为什么必须利用内置exec命令从shell脚本启动进程的缘故原由。
exec命令将脚本更换为所需的程序，进程将继续PID 1。

在Kubernetes中启用进程名称空间共享

为Pod启用进程名称空间共享时，Kubernetes对该Pod中的所有容器利用单个进程名称空间。
Kubernetes Pod根本容器成为PID 1，并自动捕获伶仃的进程。

利用专门的初始化系统

就像在更经典的Linux环境中一样，也可以利用init系统来办理这些问题。
但是，如果用于这个目的，普通的初始化系统（例如systemd或SysV）太繁芜且太重，建议利用专门的容器创建的初始化系统（例如tini）。

如果利用容器专用的初始化系统，则初始化进程具有PID 1，并实行以下操作：

注册精确的旗子暗记处理程序。

确保旗子暗记对你的运用程序有效。

捕获所有僵尸进程。

可以通过利用docker run命令的--init选项在Docker中利用此办理方案。
要在Kubernetes中利用，则必须在容器镜像中先安装init系统，并将其用作容器的入口。

优化Docker构建缓存

Docker的构建缓存可以极大的加速容器镜像的构建。
在容器系统中镜像是逐层构建的，在Dockerfile中，每条指令都会在镜像中创建一个层。
在构建期间，如果可能，Docker会考试测验重用先前构建中一层，尽可能跳过其底层来减少构建花费本钱的步骤。
Docker只有在所有先前的构建步骤都利用它的情形下，才能利用其构建缓存。
只管这种做法常日使构建更快，但须要考虑一些情形。

例如，要充分利用Docker构建缓存，必须将须要常常变动的构建步骤放在Dockerfile的后面。
如果将它们放在前面，则Docker无法将其构建缓存用于其他变动频率较低的构建步骤。
常日为源代码的每个新版本构建一个新的Docker镜像，以是应尽可能在Dockerfile的后面将源代码添加到镜像。
如下图，你可以看到，如果要变动了STEP 1，则Docker只能重用FROM FROM debian:9步骤中的层。
但是，如果变动STEP 3，则Docker可以将这些层重新用于STEP 1和STEP 2。

图中蓝色表示可以重用的层，赤色表示必须重修的层。
层的重用原则导致另一个后果，如果构建步骤依赖于存储在本地文件系统上的任何类型的缓存，则该缓存必须在同一构建步骤中天生。
如果未天生此缓存，则可能会利用来自先前构建的过期的缓存来实行的构建步骤。
通过apt或yum等程序包管理器中最常有这个问题，必须在一个RUN命令中同时安装所有必须要的库。
如果变动下面Dockerfile中的第二个RUN步骤，则不会重新运行apt-get update命令，从而导致过期的apt缓存。

FROM debian:9

RUN apt-get update

RUN apt-get install -y nginx

而是，在单个RUN步骤中合并两个命令：

FROM debian:9

RUN apt-get update && \

apt-get install -y nginx

删除不必要的工具

为了保护你的运用免受攻击者的侵害，请考试测验通过删除所有不必要的工具来减少运用的攻击面。
例如，删除诸如netcat之类的实用程序，由于可以用necat随便就能构建一个反向shell。
如果容器中不安装netcat，则攻击者无法这样大略利用。

纵然没有容器化，此最佳实践也适用于任何事情负载。
差异在于，与经典虚拟机或裸机做事器比较，利用容器实现起来要随意马虎得多。

个中一些工具可能对付调试有用。
例如，如果你将此最佳实践推得足够远，那么详尽的日志，跟踪，概要剖析和运用程序性能管理系统将成为必不可少的。
实际上，你不再可以依赖本地调试工具，由于它们常日具有很高的特权。

文件系统内容

镜像中应尽可能少的保留内容。
如果可以将运用程序编译为单个静态链接的二进制文件，则将该二进制文件添加到暂存镜像中将使得到终极镜像，该镜像仅包含一个运用程序，无其他内容。
通过减少镜像中打包的工具数量，可以减少潜在的可在容器中实行的操作。

文件系统安全

镜像中没有工具是不足的。
必须防止潜在的攻击者安装工具。
可以在此处组合利用两种方法：

首先，避免以root用户身份在容器内运行。
该方法供应了第一层安全性，并且可以防止攻击者利用嵌入在镜像中的包管理器（如apt-get或apk）修正root拥有的文件。
为了利用该方法，必须禁用或卸载sudo命令。

以只读模式启动容器，可以通过利用docker run命令中的--read-only标志或利用Kubernetes中的readOnlyRootFilesystem选项来实行此操作。
可以利用PodSecurityPolicy在Kubernetes中逼迫实行此操作。

把稳：如果运用须要将临时数据写入磁盘，也可以利用readOnlyRootFilesystem选项，只需为临时文件添加emptyDir卷。
Kubernetes中不支持emptyDir卷上的挂载，以是不能在启用noexec标志的情形下挂载该卷。

最小化镜像

天生较小的镜像具有诸如更快的上载和下载韶光等优点，这对付Kubernetes中pod的冷启动韶光尤为主要：镜像越小，节点下载就越快。
但是，构建小型镜像很难，由于可能会在无意中给终极镜像引入了构建依赖项或未优化的镜像层。

利用最小的根本镜像

根本镜像是Dockerfile中FROM指令中所引用的镜像。
Dockerfile中的所有指令均基于该镜像构建。
根本镜像越小，天生的镜像就越小，下载和加载就越快。
例如，alpine:3.7镜像比centos:7镜像就小好几十M。

我们乃至还可利用 scratch根本镜像，这是一个空镜像，可以在其上构建自己的运行时环境。
如果须要运行的运用程序是静态链接的二进制文件，利用暂存根本镜像非常随意马虎：

FROM scratch

COPY mybinary /mybinary

CMD [ "/mybinary" ]

GoogleContainerTools的Distroless项目供应了多种措辞（Java，Python(3)，Golang，Node.js，dotnet）的根本镜像。
镜像仅包含措辞的运行时，剔除了Linux发行版的很多工具，例如Shell，运用包管理器等，下面项目的一个Golang的列子：

减少镜像无效删减

要减小镜像的大小，须要严格遵守只安装必须的运用的原则。
可能有时候须要临时安装一些工具的软件包，利用后在后面的步骤中再删除。
但是，这种方法也是有问题的。
由于Dockerfile的每条指令都会创建一个镜像层，创建后，再在稍后的步骤中删除的方法，实际不能减少镜像的大小。
（数据还在，只是被隐蔽在底层而已）。
比如：

缺点Dockerfile

FROM debian:9

RUN apt-get update && \

apt-get install -y \

[buildpackage]

RUN [build my app]

RUN apt-get autoremove --purge \

-y [buildpackage] && \

apt-get -y clean && \

rm -rf /var/lib/apt/lists/

精确Dockerfile

FROM debian:9

RUN apt-get update && \

apt-get install -y \

[buildpackage] && \

[build my app] && \

apt-get autoremove --purge \

-y [buildpackage] && \

apt-get -y clean && \

rm -rf /var/lib/apt/lists/

在缺点版本Dockerfile中，[buildpackage]和/var/lib/ap /lists/中的文件仍旧存在于与第一个RUN相对应的镜像层中。
该层是镜像的一部分，只管里面的数据在终极镜像中不可访问，但也会和其他镜像层一起上传和下载。

在精确版本Dockerfile中，所有操作都在构建的运用程序的同一层中完成。
/var/lib/apt/lists/中的[buildpackage]和文件在终极镜像中不会存在，真正起到了删除的效果。

减少镜像无效删除的另一种方法是利用多阶段构建（Docker 17.05中引入）。
多阶段构建许可在第一个"构建"容器中构建运用程序，并在利用相同Dockerfile的同时在另一个容器中利用结果。

不才面的Dockerfile中，hello二进制文件内置在第一个容器中，并注入了第二个容器。
由于第二个容器是从头开始的，以是天生的镜像仅包含hello二进制文件，而不包含构建期间所需的源文件和目标文件。
但是，二进制文件是必须静态链接才能正常事情。

FROM golang:1.10 as builder

WORKDIR /tmp/go

COPY hello.go ./

RUN CGO_ENABLED=0 go build -a -ldflags '-s' -o hello

FROM scratch

CMD [ "/hello" ]

COPY --from=builder /tmp/go/hello /hello

考试测验创建具有公共镜像层的镜像

如果必须下载Docker镜像，则Docker首先检讨镜像中是否已经包含某些层。
如果你具有这些镜像层，就不会下载。
如果以前下载的其他镜像与当前下载的镜像具有相同的根本镜像，则当前镜像的下载数据量会少很多。

在企业内部，可以为开拓职员供应一组通用的标准根本镜像来减少必要的下载。
系统只会下载每个根本镜像一次，初始下载后，只须要使每个镜像中不同的镜像层，镜像的共同层越多，下载速率就越快。
如下图中赤色框的根本镜像就只需下载一次。

容器注册表进行漏洞扫描

对做事器和虚拟机，软件漏洞扫描是常用的一个安全手段，通过集中式软件扫描系统，列出了每台主机上安装的软件包和存在的漏洞源，并及时关照管理员修补漏洞，比如虫虫之前的文章中先容过的Flan Scan系统。

由于容器原则上是不可变的，以是不建议对存在漏洞的情形下对其进行漏洞修补。
最佳实践是对其重修镜像，打包补丁程序，然后重新支配。
与做事器比较，容器的生命周期要短得多，身份标识的定义要好得多。
因此，利用类似的集中检测容器中漏洞的一种不好的方法。

为理解决这个问题，可以在托管镜像的容器注册表（Container Registry）中进行漏洞扫描。
这样就可以在创造容器镜像中的漏洞。
将镜像上传到注册表时或漏洞库更新时，就会进行扫描，或者启动操持任务定期扫描。

检测到漏洞后，可以利用脚本来触发自动漏洞修补过程。
最好是结合版本管理（比如Gitlab）CI/CD管道来持续进行镜像构建来进行漏洞修补。
一样平常步骤如下：

1.将镜像存储在容器注册表中并启用漏洞扫描。

2.配置一个作业，该作业定期从容器注册表中获取新漏洞，并在须要时触发镜像重修。

3.构建新镜像后，通过持续支配系统CD来将镜像支配到验证环境中。

4.手动检讨验证是否正常。

5.如果未创造问题，请手动推送灰度支配莅临盆环境。

精确标记镜像

Docker镜像常日由两个部分标识：它们的名称和标签。
例如，对付centos:8.0.1镜像，centos是名称，而8.0.1是标签。
如果在Docker命令中未供应最新标签，则默认利用最新标签。
名称和标签对在任何给定时间都是该当唯一的。
但是，可以根据须要将标签重新分配给其他镜像。
构建镜像时，须要精确标记，遵照统一同等标记策略。

容器镜像是一种打包和发布软件的方法。
标记镜像可让用户识别软件的特定版本进行下载。
因此，将容器镜像上的标记系统关系到软件的发布策略。

利用语义版本标记

发行软件的常用方法是利用语义化版本号规范（The Semantic Versioning Specification）版本号来"标记"（如git tag命令中的）特定版本的源代码。
语义化版本号规范是为了改进各种软件版本号格式混乱，语义不明的现状由semver.org提出的一种处理版本号的规整方法。
在该规范中软件版本号由三部分构成：X.Y.Z，个中：

X是紧张版本，有向下不兼容的修正或者颠覆性的更新时增加。

Y是次要版本，有向下兼容的修正或者添加兼容性的新功能时增加1。

Z是补丁程序版本，仅仅是打一些兼容性补丁，做一些兼容性修复时增加。

次要版本号或补丁程序版本号中的每个增量都必须是向后兼容的变动。

如果该系统或类似系统，请按照以下策略标记镜像：

最新标签始终指的是最新（可能稳定）的镜像。
创建新镜像后，该标签即被移动。

X.Y.Z标签是指软件的特定版本。
请不要将其移动到其他镜像。

X.Y标记是指软件X.Y次要分支的最新修补程序版本。
当发布新的补丁程序版本时，它将被移动。

X标记是指X紧张分支的最新次要版本的最新补丁程序版本。
当发布新的修补程序版本或新的次要版本时，它将移动。

利用此策略可以利用户灵巧地选择他们要利用的软件版本。
他们可以选择特定的X.Y.Z版本，并确保镜像永不变动，或者可以通过选择不太详细的标签来自动获取更新。

用Git提交哈希标记

如果你用持续交付系统并且常常发布软件，则可能不能利用语义版本掌握规范中描述的版本号。
在这种情形下，处理版本号的常用方法是利用Git commit SHA-1哈希（或它的简短版本）作为版本号。
根据设计事理，Git的提交哈希是不可变的，并引用到软件的特定版本。