龙空技术网

从安全到镜像流水线,Docker 最佳实践与反模式一览

CSDN 243

前言:

今天姐妹们对“docker镜像仓库命令”大概比较看重,小伙伴们都想要学习一些“docker镜像仓库命令”的相关内容。那么小编在网络上搜集了一些有关“docker镜像仓库命令””的相关资讯,希望同学们能喜欢,各位老铁们快快来学习一下吧!

作者 | Timothy Mugayi

译者 | 弯月,责编 | 夕颜

封图 | CSDN付费下载自视觉中国

出品 | CSDN(ID:CSDNnews)

在使用Docker的大部分时间里,我们并不关心其内部的工作原理。仅凭启动一个Docker容器并且让应用程序运行良好,并不能说明你已经实现了一个良好的解决方案。有时,由于时间限制,我们只能复制粘贴Docker镜像,却没能真正理解实现细节以及如何构建Docker镜像的细微差别。

在本文中,我们将探讨Docker的最佳实践和反模式。反模式是人们对于反复出现的问题的一般解决方案,这些方案没有效率,甚至会完全抵消Docker技术栈带来的好处。

下面我们来看看我们的哪些做法不可取。

我们需要的标签

标签是必不可少的,我们需要通过标签传达有关Docker镜像的信息。你可以将标签视为Docker镜像ID的别称。Git标签负责标记特定的提交,而Docker标签与之类似,可以给不同时间点上的Docker镜像添加版本。忘记打标签是小事,但会带来一些弊端,具体来讲,如果未指定标记,则默认镜像将被标记为latest。

FROM your_image_name:latest

如果你频繁执行该操作,那么很有可能镜像不是最新的,可能指向的是旧版本。因此,请使用适当的标签并遵守某个版本控制标准,例如语义版本控制。这样,Docker镜像使用者才能确保Docker镜像的兼容性并时刻保持最新,还可以有计划地使用正确的版本。

还有一个情况应该避免。你可以利用最新的默认标签(如FROM python3:latest),从Docker镜像仓库中提取最新的镜像。乍一看,这种做法似乎是个好主意,但却有一些意想不到的副作用:每个最新的请求可能都会派生出与以前的构建完全不同的Docker镜像。弄明白Docker镜像损坏的原因将会变得很困难,因为镜像本应该是不可变的。因此,我强力建议使用特定的标签来标记镜像(例如:python3:1.0.1)。这种方法可以确保你的Dockerfile保持不变。

在同一个容器中运行多个服务

虽然你可以在同一个容器中运行多个服务,但我并不建议你这么做,原因有两个。在使用Docker服务时,我们应该努力维持责任单一性。最佳做法是,组成应用程序的每个服务都应在各自的容器中运行,请务必将每项独立的功能都打包到单独的独立容器镜像中。

将多个服务添加到一个Docker镜像的做法似乎很诱人,但是你不应该将容器镜像视为虚拟机。一个容器包含多个服务,可能会导致你的应用程序很难水平扩展。Docker容器核心概念是,它们都是瞬态的,专为分发而设计,这对于现代Web应用程序来说很理想,因为它的瞬态特性、扩展和并发会非常容易。添加多个服务会增加管理分发的难度。

另外,单个容器上的多个服务还会加大管理安全性的难度。庞大的镜像可能会降低CI/CD的速度,你需要小心。

使用LABEL对镜像进行分类

这并不能说是反模式,但我认为值得一提。我在处理各种Docker镜像时注意到了一件事:有时这些镜像的创建者没有使用LABEL maintainer标签。这个标签可在事件中设置镜像的Author字段,当出现问题或需要澄清时,这个标签可以方便大家了解该与何人内部联系;如果镜像是公开共享的,也可以知道该与哪个外部的人联系。

这绝不是唯一可以使用的标签。你可以根据需要定义各种标签,来对镜像进行分类,定义许可信息,也可以定义标签来帮助自动化。

除了maintainer,还可以使用多行标签:

# Set one or more individual labelsLABEL com.example.version="0.0.1-beta"LABEL vendor1="RBTSB Incorporated"LABEL vendor2=TIPTAPCODE\ IncorporatedLABEL com.example.release-date="202-04-02"LABEL com.example.version.production="0.0.1"

Docker 1.10之前的单行标签会创建新的docker层,如果你使用的是最新版的Docker,则不必担心创建额外的层。

LABEL vendor=ACME\ Incorporated \com.example.is-beta= \com.example.is-production="" \com.example.version="0.0.1-beta" \com.example.release-date="2015-02-12"

我们应该将尽可能多的元数据添加到不可变的Docker镜像,以方便追踪,提高可见性和可维护性。

避免构建依赖特定环境的镜像

在构建Docker镜像时,我们应始终牢记不变性。最好不要使用带有dev、test、staging和production的镜像,因为这会破坏单一来源的原则。另一个问题是,如果在不同环境上验证或调试,则这种做法无法保证镜像的相似。

为什么要使用非Root容器?

在默认情况下,Docker容器以root身份运行。以root用户身份运行的Docker容器可以完全控制主机系统。然而,出于安全考虑,我并不推荐这种做法。使用非root运行的Docker容器镜像可以多一层保护,在生产环境中通常建议使用非root容器。但是,由于这些容器由非root用户运行,因此无法执行需要特殊权限的任务。如果需要利用USER指令指定非root用户(如以下示例所示),则需要进行一些上下文切换。

FROM python:3.6-slim-busterLABEL maintainer="Timothy Mugayi <timothy.mugayi@gmail.com>"RUN apt-get update && apt-get install -y --no-install-recommends \wget && rm -rf /var/lib/apt/lists/*# Dumb initRUN wget -O /usr/local/bin/dumb-init  chmod +x /usr/local/bin/dumb-initRUN pip install --upgrade pipWORKDIR /usr/src/appCOPY requirements.txt .RUN pip install -r requirements.txtCOPY helloworld.py .USER 1001ENTRYPOINT ["/usr/local/bin/dumb-init", "python3", "-u", "./helloworld.py"] 

如果你使用的基础镜像不是由root生成的,但需要切换回root,则可以执行以下操作:

 FROM <namespace>/<image>:<tag_version>USER root

不要在单个容器内运行太多进程

容器的优点以及容器相对于虚拟机的优势在于,通过多个相互交互的容器组成一个完整的应用程序。我们无需在单个容器中运行完整的应用程序。相反,我们应尽可能将应用程序分解为多个服务,并将服务分布到多个容器上。这样可以最大程度地提高灵活性和可靠性。

不要在容器内安装操作系统

使用一段时间Docker后,你就有可能遇到这种情况。虽然你可以在容器内安装和运行完整的Linux操作系统。但是你应该这样做吗?

这可能不是一个好主意。Docker镜像是使用层的概念构建的,因此添加的东西越多,镜像就会膨胀得越大。一个完整的操作系统并不是Docker的理想使用情况。在理想情况下,你的容器内部只应该加载必要的组件。

不要在容器内运行不必要的服务

为了充分利用容器的优势,你应该尽可能保持容器精简。这样可以最大程度地提高性能,并最大程度地降低安全风险。因此,请避免运行并非绝对必要的服务。例如,若非必要请不要在容器内运行SSH服务,你可以选用其他方式(例如Docker exec)登录到容器。

不要在容器内加载不必要的程序

你必须知道这种反模式。在使用Docker时,很多人倾向于在镜像中加载sonar之类的工具,来确保代码覆盖率等。

使用从Docker CE 17.05+开始支持的多阶段构建(Multistage builds)模式,你可以在Dockerfile中使用多个FROM stage。临时构建的阶段容器将被丢弃,因此最终的运行时容器镜像都很精简。举个例子,当你需要从源文件编译一些二进制文件,然后在第二个阶段中将二进制文件复制到最终镜像中。

优点:

构建速度更快,精简的镜像可以让CI/CD过程更快,镜像通过网络进行传输时花费的时间也更少。需要的存储空间更少。冷启动(拉取镜像)更快。潜在的受攻击面更少。

缺点:

容器内的工具较少,但这是保证容器的精简所需付出的一点小小的代价。

在容器内加入供观察的工具

即便没有监视解决方案,你也可以照常运行容器,但需要牢记,从本质上来说,你很难知道容器内部发生了什么,特别是随着容器数量的增加。

Docker本身自带了许多指标,能够公开每个运行容器的CPU、内存、网络和I/O使用情况,可通过Docker远程API的/stats端点访问。App dynamics 和 Newrelic 是两个现成的程序,可以与Docker镜像一起打包,帮助你从应用程序级别了解应用程序和容器的运行状况。

基础镜像的爱恨交织

“你知道是谁构建了这个景象,里面都添加了什么吗?”

这里说的都是可追溯性。牢记安全性是所有软件开发人员都应努力的方向。你需要了解如何跟踪Docker镜像的源,并了解里面有什么。

你需要时刻牢记以下几点:

镜像是怎样创建的。验证镜像在创建后未经更改。验证镜像的内容。扫描镜像是否有安全漏洞。

我们可以通过一些工具对容器进行静态分析。这些工具涉及方方面面,已超出了本文的范围,但是我建议你花一些时间来学习。

Clair是一个有趣的工具,可为你的Docker应用程序提供自动容器漏洞和安全扫描。扫描基于常见的漏洞和公开(CVE)的数据库。如果你本地运行Docker,则可以下载Postgres,然后将Clair连接到Postgres上。以下是启动和运行Clair所需的最低配置:

$ mkdir $PWD/clair_config$ curl -L  -o $PWD/clair_config/config.yaml$ docker run -d -e POSTGRES_PASSWORD="" -p 5432:5432 postgres:9.6$ docker run --net=host -d -p 6060-6061:6060-6061 -v PWD/clair_config:/config quay.io/coreos/clair:latest -config=/config/config.yaml

如果你想更改Postgres的端口,请确保同时修改config.yaml文件。如果你的系统上已经运行了另一个Postgres,请注意不要将docker端口更改为5432以外的端口。

clair:database:# Database drivertype: pgsqloptions:# PostgreSQL Connection string# : host=localhost port=5432 user=postgres password=123456 sslmode=disable statement_timeout=60000

在镜像启动并执行后,你可以运行Docker ps来确认容器已启动且正常运行:

你需要注意Clair没有Web UI或CLI。你只能通过REST API或第三方CLI工具来使用。

Bayan Collector是一款轻巧的静态分析应用程序,可以从镜像仓库启动容器以进行静态分析,可以运行任意脚本并收集有用的信息(例如已安装的软件包),强制执行策略,以及对镜像进行校验。

Docker Bench for Security是由Docker团队创建的工具,它会在Docker的宿主上运行一个安全最佳做法清单,并标记发现的任何问题。

不要在容器镜像中存储敏感数据

请一定避免这个错误。如果你的镜像对外公开,或者开发人员无意中将镜像推送到公共的Docker镜像仓库中,那么就会导致隐私和敏感信息的泄露。切记永远不要在Dockerfile中对敏感信息使用COPY或`。

为了避免这种情况,请将敏感数据存储在安全文件系统上,并让容器进行连接。一般情况下,这个文件系统应该在容器所在的宿主上,或者可通过AWS Elastic Block Storage(EBS)等块存储或S3等对象存储服务来使用。

此外,你应避免在Docker镜像中存储安全凭证。作为开发人员,有时我们会采用偷懒的做法,在代码中硬编码密码和私钥。你需要习惯使用-e参数在运行时为Docker容器指定环境变量。

你也可以通过env-file,从文件中读取环境变量。通过CMD或`从第三方来源获取凭据的自定义脚本也可用于获取Docker容器所需的相关凭据。

不要在容器内存储数据或日志

容器化改变了日志的性质。容器是瞬态、无状态应用程序的理想选择。本质上,存储在运行容器中的所有数据都应该是短暂的,你可能已经注意到,当容器关闭时,数据将丢失。因此,将数据存储在Docker容器之外的做法更值得推崇。有一些工具可以帮助你提取Docker日志,并将其放在更永久的数据存储中。

在处理Docker日志时需要牢记一点:Docker至少拥有三个级别的日志记录,即Docker容器、Docker服务和宿主操作系统,你选择的日志记录方法应该能够提取所有级别的日志。

不要写入容器的文件系统

每次将内容写入容器的文件系统都会激活“写时复制”策略。这会使用存储驱动程序(deviermapper、overlayfs或其他驱动)创建新的存储层。在实际应用中,这会给存储驱动带来巨大的压力,特别是使用Devicemapper或BTRFS的情况下。

确保容器只向卷中写入数据。对于小型的临时文件可以写入tmpfs,因为tmpfs是仅存在于内存或交换分区中的临时文件系统。

不要运行PID 1

这是许多人都不知道的常见问题。

Docker中的进程运行时没有init进程负责清理子进程,所以容器可能会出现僵尸进程,导致意料之外的错误。

使用tini或dumb-init

PID 1在Unix中很特殊,因此在init系统中忽略它通常会导致进程和信号处理错误。这会导致类似于容器无法优雅地停止,或本应摧毁的容器出现泄露等问题。

僵尸进程指的是运行已经停止,但依然在进程表中占据位置的进程,因为它们的父进程没有调用wait系统调用进行回收。理论上,每个结束的进程都会非常短暂地呈现僵尸状态,但有些进程的僵尸状态会持续很久。

如果某个进程会生成新进程,但信号处理的实现不好,无法捕获子进程的信号并将其终止,那么可以使用Tini或dumb-init。例如,bash脚本就无法正确处理或释放信号。

下面是运行dumb init的示例,其中prepare.sh可以是shell脚本,也可以是用于执行应用程序的命令:

RUN wget -O /usr/local/bin/dumb-init  chmod +x /usr/local/bin/dumb-initENTRYPOINT ["/usr/local/bin/dumb-init", "/usr/bin/prepare.sh"]

或者如果你选择tini,可以参考下面使用Python anaconda conda的示例:

RUN conda install --yes -c conda-forge tiniENTRYPOINT ["tini", "-g", "--", "/usr/bin/prepare.sh"]

最后,这里是一个更一般的示例,不依赖于任何编程语言:

FROM node:13.12.0-slimMAINTAINER Timothy Mugayi <timothy.mugayi@gmail.com>ENV TINI_VERSION='v0.13.0'# Add tini init, see  {TINI_VERSION}/tini /tiniRUN chmod +x /tini# Set tini as entrypointENTRYPOINT ["/tini", "--"]

在CI/CD中使用Dockerfile格式检查

跟编程语言一样,Docker也有格式检查工具。

采用格式检查工具有许多好处,因为它会强制你使用最佳实践。在CI/CD过程中加入格式检查,可以帮助团队避免常见的错误,并在构建产品Docker镜像时建立最佳实践。可以从hadolint开始,这是一个用Haskell编写的Dockerfile格式检查工具,能够解析Dockerfile成AST,并在AST上执行规则检查。

我们来运行一个示例。要对Docker进行格式检查,可以执行以下命令:

$ docker run --rm -i hadolint/hadolint < Dockerfile

格式检查完成后会显示以下结果:

上图中的错误码DL3008“Pin”来自hadolint的错误码描述状态。固定版本号可以强制构建时安装特定版本的包,不论缓存中是什么。这个技巧可以减少依赖包意料之外的改变导致的构建错误。

最后的一点想法

在本文中,我们谈了很多内容,覆盖了从安全到Docker镜像流水线的方方面面。

有许多技巧可以让Docker镜像更好、更安全。希望这篇文章可以给你带来一些启发,帮助你理解应该做什么、不应该做什么,并为你提供一些在构建内部或外部Docker容器镜像时可以应用的方案。

原文链接:

本文为CSDN翻译文章,转载请注明出处。

今日福利

遇见陆奇

同样作为“百万人学 AI”的重要组成部分,2020 AIProCon 开发者万人大会将于 7 月 3 日至 4 日通过线上直播形式,让开发者们一站式学习了解当下 AI 的前沿技术研究、核心技术与应用以及企业案例的实践经验,同时还可以在线参加精彩多样的开发者沙龙与编程项目。参与前瞻系列活动、在线直播互动,不仅可以与上万名开发者们一起交流,还有机会赢取直播专属好礼,与技术大咖连麦。

标签: #docker镜像仓库命令