Linux 容器已经成为一个热门话题，保证容器镜像较小被认为是一个好习惯。本文提供了有关如何构建较小 Fedora 容器镜像的一些技巧。

microdnf

Fedora 的 DNF 是用 Python 编写的，因为它有各种各样的插件，因此它的设计是可扩展的。但是 有一个 Fedora 基本容器镜像替代品，它使用一个较小的名为 microdnf 的包管理器，使用 C 编写。要在 Dockerfile 中使用这个最小的镜像，FROM 行应该如下所示：

FROM registry.fedoraproject.org/fedora-minimal:30

如果你的镜像不需要像 Python 这样的典型 DNF 依赖项，例如，如果你在制作 NodeJS 镜像时，那么这是一个重要的节省项。

在一个层中安装和清理

为了节省空间，使用 dnf clean all 或其 microdnf 等效的 microdnf clean all 删除仓库元数据非常重要。但是你不应该分两步执行此操作，因为这实际上会将这些文件保存在容器镜像中，然后在另一层中将其标记为删除。要正确地执行此操作，你应该像这样一步完成安装和清理：

FROM registry.fedoraproject.org/fedora-minimal:30
RUN microdnf install nodejs && microdnf clean all

使用 microdnf 进行模块化

模块化是一种给你选择不同堆栈版本的方法。例如，你可能需要在项目中用非 LTS 的 NodeJS v11，旧的 LTS NodeJS v8 用于另一个，最新的 LTS NodeJS v10 用于另一个。你可以使用冒号指定流。

# dnf module list
# dnf module install nodejs:8

dnf module install 命令意味着两个命令，一个启用流，另一个是从它安装 nodejs。

# dnf module enable nodejs:8
# dnf install nodejs

尽管 microdnf 不提供与模块化相关的任何命令，但是可以启用带有配置文件的模块，并且 libdnf（被 microdnf 使用）似乎支持模块化流。该文件看起来像这样：

/etc/dnf/modules.d/nodejs.module
[nodejs]
name=nodejs
stream=8
profiles=
state=enabled

使用模块化的 microdnf 的完整 Dockerfile 如下所示：

FROM registry.fedoraproject.org/fedora-minimal:30
RUN \
   echo -e "[nodejs]\nname=nodejs\nstream=8\nprofiles=\nstate=enabled\n" > /etc/dnf/modules.d/nodejs.module && \
   microdnf install nodejs zopfli findutils busybox && \
   microdnf clean all

多阶段构建

在许多情况下，你可能需要大量的无需用于运行软件的构建时依赖项，例如构建一个静态链接依赖项的 Go 二进制文件。多阶段构建是分离应用构建和应用运行时的有效方法。

例如，下面的 Dockerfile 构建了一个 Go 应用 confd。

# building container
FROM registry.fedoraproject.org/fedora-minimal AS build
RUN mkdir /go && microdnf install golang && microdnf clean all
WORKDIR /go
RUN export GOPATH=/go; CGO_ENABLED=0 go get github.com/kelseyhightower/confd

FROM registry.fedoraproject.org/fedora-minimal
WORKDIR /
COPY --from=build /go/bin/confd /usr/local/bin
CMD ["confd"]

通过在 FROM 指令之后添加 AS 并从基本容器镜像中添加另一个 FROM 然后使用 COPY --from= 指令将内容从构建的容器复制到第二个容器来完成多阶段构建。

可以使用 podman 构建并运行此 Dockerfile：

$ podman build -t myconfd .
$ podman run -it myconfd

via: https://fedoramagazine.org/building-smaller-container-images/

作者：Muayyad Alsadi 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Ansible Container 解决了 Dockerfile 的不足，并对容器化项目提供了完整的管理。

Image by : opensource.com

我喜欢容器，并且每天都使用这个技术。即便如此，容器并不完美。不过，在过去几个月里，一系列项目已经解决了我遇到的一些问题。

我刚开始时，用 Docker 使用容器，这个项目使得这种技术非常流行。除了使用这个容器引擎之外，我学到了怎么去使用 docker-compose 以及怎么去用它管理我的项目。使用它使得我的生产力猛增！一个命令就可以运行我的项目，而不管它有多复杂。因此，我太高兴了。

使用一段时间之后，我发现了一些问题。最明显的问题是创建容器镜像的过程。Docker 工具使用一个定制的文件格式作为生成容器镜像的依据：Dockerfile。这个格式易于学习，并且很短的一段时间之后，你就可以自己制作容器镜像了。但是，一旦你希望进一步掌握它或者考虑到复杂场景，问题就会出现。

让我们打断一下，先去了解一个不同的东西：Ansible 的世界。你知道它吗？它棒极了，是吗？你不这么认为？好吧，是时候去学习一些新事物了。Ansible 是一个允许你通过写一些任务去管理你的基础设施，并在你选择的环境中运行它们的项目。不需要去安装和设置任何的服务；你可以从你的笔记本电脑中很容易地做任何事情。许多人已经接受 Ansible 了。

想像一下这样的场景：你在 Ansible 中，你写了很多的 Ansible 角色 role 和 剧本 playbook ，你可以用它们去管理你的基础设施，并且你想把它们运用到容器中。你应该怎么做？通过 shell 脚本和 Dockerfile 去写容器镜像定义？听起来好像不对。

来自 Ansible 开发团队的一些人问到这个问题，并且他们意识到，人们每天编写和使用的那些同样的 Ansible 角色和剧本也可以用来制作容器镜像。但是 Ansible 能做到的不止这些 —— 它可以被用于去管理容器化项目的完整生命周期。从这些想法中，Ansible Container 项目诞生了。它利用已有的 Ansible 角色转变成容器镜像，甚至还可以被用于生产环境中从构建到部署的完整生命周期。

现在让我们讨论一下，我之前提到过的在 Dockerfile 环境中的最佳实践问题。这里有一个警告：这将是非常具体且技术性的。出现最多的三个问题有：

1、 在 Dockerfile 中内嵌的 Shell 脚本

当写 Dockerfile 时，你可以指定会由 /bin/sh -c 解释执行的脚本。它类似如下：

RUN dnf install -y nginx

这里 RUN 是一个 Dockerfile 指令，其它的都是参数（它们传递给 shell）。但是，想像一个更复杂的场景：

RUN set -eux; \
    \
# this "case" statement is generated via "update.sh"
    %%ARCH-CASE%%; \
    \
    url="https://golang.org/dl/go${GOLANG_VERSION}.${goRelArch}.tar.gz"; \
    wget -O go.tgz "$url"; \
    echo "${goRelSha256} *go.tgz" | sha256sum -c -; \

这仅是从 golang 官方镜像 中拿来的一段。它看起来并不好看，是不是？

2、 解析 Dockerfile 并不容易

Dockerfile 是一个没有正式规范的新格式。如果你需要在你的基础设施（比如，让构建过程自动化一点）中去处理 Dockerfile 将会很复杂。仅有的规范是 这个代码，它是 dockerd 的一部分。问题是你不能使用它作为一个 库 library 来使用。最容易的解决方案是你自己写一个解析器，然后祈祷它运行的很好。使用一些众所周知的标记语言不是更好吗？比如，YAML 或者 JSON。

3、 管理困难

如果你熟悉容器镜像的内部结构，你可能知道每个镜像是由 层 layer 构成的。一旦容器被创建，这些层就使用联合文件系统技术堆叠在一起（像煎饼一样）。问题是，你并不能显式地管理这些层 — 你不能说，“这儿开始一个新层”，你被迫使用一种可读性不好的方法去改变你的 Dockerfile。最大的问题是，必须遵循一套最佳实践以去达到最优结果 — 新来的人在这个地方可能很困难。

Ansible 语言和 Dockerfile 比较

相比 Ansible，Dockerfile 的最大缺点，也是 Ansible 的优点，作为一个语言，Ansible 更强大。例如，Dockerfile 没有直接的变量概念，而 Ansible 有一个完整的模板系统（变量只是它其中的一个特性）。Ansible 包含了很多更易于使用的模块，比如，wait\_for，它可以被用于服务就绪检查，比如，在处理之前等待服务准备就绪。在 Dockerfile 中，做任何事情都通过一个 shell 脚本。因此，如果你想去找出已准备好的服务，它必须使用 shell（或者独立安装）去做。使用 shell 脚本的其它问题是，它会变得很复杂，维护成为一种负担。很多人已经发现了这个问题，并将这些 shell 脚本转到 Ansible。

关于作者

Tomas Tomecek - 工程师、Hacker、演讲者、Tinker、Red Hatter。喜欢容器、linux、开源软件、python 3、rust、zsh、tmux。More about me

via: https://opensource.com/article/17/10/dockerfiles-ansible-container

作者：Tomas Tomecek 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出