对于使用容器的用户来说，容器如何存储在磁盘上通常是一个谜。在这篇文章中，我们将了解容器镜像的存储方式以及可用于直接处理这些镜像的一些工具 - Podman
容器镜像存储的演变
当我第一次开始使用容器时，我不喜欢 Docker 架构的一件事是守护进程隐藏了有关镜像存储的信息。人们使用镜像的唯一现实方式是通过守护进程。我们正在开发该atomic工具，并希望有一种方法来挂载容器镜像，以便我们可以扫描它们。毕竟，容器镜像只是 devicemapper 或覆盖层下的挂载点。
Red Hat 的容器运行时团队创建了atomic mount在 Docker 下挂载镜像的命令，并在atomic scan.这里的问题是守护进程不知道这一点，因此如果有人试图在我们安装镜像时删除镜像，守护进程会感到困惑。锁定和操作必须在守护进程内完成。
当我们开始创建新的容器引擎时，我们需要的第一件事就是构建一个新的容器/存储库，它不需要守护进程来控制它。我们希望允许多个工具同时使用存储，而无需相互了解。
我们将使用文件系统锁定来控制对存储数据的访问。第一步是分离出 Docker 项目下的容器/存储，称为 graphdriver。这些存储驱动程序实现了不同的写时复制（COW）存储驱动程序，包括overlay、devicemapper、btrfs、xfs、vfs、aufs......如果你想在go项目中使用该库，那么你只需实现一个存储即可。
请注意，容器/存储库与容器存储接口（CSI）无关。容器/存储是将容器镜像存储在COW文件系统上，而CSI则用于容器写入的卷。例如，您可以使用 CSI 来存储 MariaDB 容器镜像使用的数据库，该数据库存储在容器/存储中。我希望这能消除任何困惑。 # 存储配置 *** ** * ** *** 容器存储配置在 storage.conf 文件中定义。对于以 root 身份运行的容器引擎，storage.conf 文件存储在`/etc/containers/storage.conf`.如果您使用 Podman 等工具无根运行，则 storage.conf 文件存储在`$HOME/.config/containers/storage.conf`. 现在我们来看一下`storage.conf`。 ## driver ```ini $ cat /etc/containers/storage.conf # This file is is the configuration file for all tools # that use the containers/storage library. # See man 5 containers-storage.conf for more information # The "container storage" table contains all of the server options. [storage] # Default Storage Driver driver = "overlay" ``` 驱动领域至关重要。在容器/存储中，我们默认使用overlay驱动程序。在 Docker 世界中，有两个 Overlay 驱动程序，overlay 和 Overlay2，现在大多数用户使用 Overlay2 驱动程序，所以我们只使用其中一个，并将其称为 Overlay。如果您不小心在配置容器中使用了overlay2，存储足够智能，可以将其别名为overlay。 ## graphroot ```ini # Temporary storage location runroot = "/var/run/containers/storage" # Primary Read/Write location of container storage graphroot = "/var/lib/containers/storage" ``` graphroot定义了实际镜像的存储位置。我们建议您在此位置设置大量空间，因为人们往往会随着时间的推移存储大量镜像。设置存储不需要特殊工具，您应该使用标准 Linux 命令以最适合您需求的任何方式设置存储，但我们建议您在 /var/lib/containers 上挂载大型设备。 ## storage.options ```ini [storage.options] # Storage options to be passed to underlying storage drivers ``` 每个图形驱动程序有很多存储选项。其中一些允许您使用容器存储做一些有趣的事情，我将在下面讨论其中的一些。 ## additionalimagestores ```ini # AdditionalImageStores is used to pass paths to additional Read/Only image stores # Must be comma separated list. additionalimagestores = [ ] ``` additionalimagestores是一项很酷的功能，它允许您设置附加的只读镜像存储。例如，您可以设置包含许多覆盖容器镜像像的 NFS 共享，并通过 NFS 与所有容器引擎共享它们。然后，他们可以使用 NFS 存储上的镜像并启动容器，而不是要求每个运行容器引擎的节点拉取巨大的镜像。 ## size ```ini # Size is used to set a maximum size of the container image. Only supported by # certain container storage drivers. size = "" ``` 大小控制容器镜像的大小，如果您运行的系统中有大量用户将拉取镜像，您可能需要设置配额以确保没有用户能够拉取巨大的镜像。例如，[OpenShift.com使用此功能来控制其用户，尤其是在使用](https://link.juejin.cn?target=https%3A%2F%2Fwww.openshift.com%2F "https://www.openshift.com/")[OpenShift Online](https://link.juejin.cn?target=https%3A%2F%2Fwww.openshift.com%2Fproducts%2Fonline%2F "https://www.openshift.com/products/online/")时。 ## mounting ```ini # Path to an helper program to use for mounting the file system instead of mounting it # directly. # mount_program = "/usr/bin/fuse-overlayfs" # mountopt specifies comma separated list of extra mount options mountopt = "nodev" ``` 该标志允许您将特殊的安装选项传递到驱动程序中。例如，设置该`nodev` 字段可防止用户使用容器镜像中显示的设备节点。容器引擎在安装于 的 tmpfs 上提供设备`/dev`，因此没有理由将设备嵌入到镜像中，特别是当它们可用于规避安全性时。 ## Remap-UIDs/GIDs ```bash # Remap-UIDs/GIDs is the mapping from UIDs/GIDs as they should appear inside of # a container, to UIDs/GIDs as they should appear outside of the container, and # the length of the range of UIDs/GIDs. Additional mapped sets can be listed # and will be heeded by libraries, but there are limits to the number of # mappings which the kernel will allow when you later attempt to run a # container. # # remap-uids = 0:1668442479:65536 # remap-gids = 0:1668442479:65536 ``` 重新映射 uids 和 gids 标志告诉容器/存储以重新映射的格式存储镜像，供指定用户命名空间内的用户使用。如果您设置`remap-uids`to ，`0:100000:65536`这会告诉容器存储在存储镜像时重新映射`UID=0`to `100,000, UID=1`、to等（直到 uid ）拥有的文件。现在，如果容器引擎在映射内运行容器，它将使用与用户而不是 root 关联的 uid 更安全地运行。```100,001``UID=2``100,0002``65536``` ```ini # Remap-User/Group is a name which can be used to look up one or more UID/GID # ranges in the /etc/subuid or /etc/subgid file. Mappings are set up starting # with an in-container ID of 0 and the a host-level ID taken from the lowest # range that matches the specified name, and using the length of that range. # Additional ranges are then assigned, using the ranges which specify the # lowest host-level IDs first, to the lowest not-yet-mapped container-level ID, # until all of the entries have been used for maps. # # remap-user = "storage" # remap-group = "storage" [storage.options.thinpool] # Storage Options for thinpool ``` ## Others 其余选项用于使用 devicemapper 等驱动程序以及其他一些选项创建 Thinpool。您可以参考`/etc/containers/storage.conf`磁盘上的文件以获取说明，也可以参考 storage.conf(5) 手册页以获取更多信息。 ## 使用容器存储 容器引擎和 Podman、Buildah、[CRI-O](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fkubernetes-sigs%2Fcri-o "https://github.com/kubernetes-sigs/cri-o")、Skopeo 等工具同时共享容器存储。他们都可以看到彼此的镜像，并且可以基于文件锁定彼此结合使用或完全单独使用。这意味着 podman 可以安装和检查容器。虽然它们共享实际存储，但它们不一定共享容器信息。有些工具具有不同的容器用例，并且不会显示其他工具的容器。例如，buildah 只是为了构建容器镜像的过程而创建构建容器，因为这些不需要 podman 容器的所有内容，所以它有一个单独的数据库。机器人工具可以删除彼此的容器镜像，但它们会单独处理它们。 ```arduino # podman create -ti --name fedora-ctr fedora sh ed4b68304e9fbbbc527593c28c917535e1d67d7d5c3f25edc568b71275ab69fc sh-4.4# podman mount fedora-ctr /var/lib/containers/storage/overlay/b16991596db22b90b78ef10276e2ae73a1c2ca9605014cad95aac00bff6608bc/merged # ls /var/lib/containers/storage/overlay/b16991596db22b90b78ef10276e2ae73a1c2ca9605014cad95aac00bff6608bc/merged bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var ``` 虽然 buildah 和 CRI-O 可以使用相同的 Fedora 镜像 您甚至可以使用 Skopeo 在启动时预加载容器/存储，以使容器/镜像可供任何容器工具技术使用。请记住，没有容器守护程序控制此访问，只有标准文件系统工具。