MinIO、Podman 和 Apple 硅芯片

于 DevOps 2022 年 7 月 25 日

我使用 Mac 很长时间了。就像，“上个千年”那么久。因此，我一直愿意寻找方法让软件在我的 Mac 上运行，无论这是否是个好主意。但当涉及到服务器时，我一直都在使用 Linux，这也意味着需要找到一些疯狂的解决方案才能正常工作。十多年前切换到 OS X（现在是 macOS）是我世界里一件非常受欢迎的事情，因为它意味着我可以在我的 Mac 上直接使用所有这些 Linux 脚本，无需虚拟机、双引导或坦白地说，任何妥协。

然后出现了容器、云以及所有相关的东西，包括这种思维方式的转变：你可以在需要时启动一个服务器，并在完成工作后干净地将其关闭。 MinIO 在这种环境下运行得非常出色！而且当我加入 MinIO 时，我非常热衷于在 Mac 上运行一些 MinIO 容器。

Homebrew 使其变得简单

对于那些不熟悉 Homebrew 的人来说，它被称为 Mac 的“缺失的包管理器”。我无法对阅读本文的开发人员大声说出这一点：获取 Homebrew。去做吧。首先，我从现在开始的所有笔记都以拥有 Homebrew 为前提，其次，它绝对是获取大量软件包的最简单方法，并且可以与操作系统集成，而无需将大量文件散布在整个系统中。甚至，我带着极大的兴奋说，如果你想以裸机方式运行，可以通过一个简单的 brew install minio/stable/minio 命令从 Homebrew 安装 MinIO 本身。所有内容都位于 /opt/homebrew（Apple Silicon）或 /usr/local（Intel）中。如果你准备好了，安装 Homebrew 的命令

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

但我在这里并不是要赞美直接在我的 Mac 硬件上运行 MinIO。主要是因为这太简单了，我认为不值得写一篇博文。这篇文章主要是因为我的目标是拥有一个可重复的过程，任何人都可以快速地在任何平台上使用它来启动自己的环境。这就是容器发挥作用的地方。

Podman 或 Docker

Docker 是一个很棒的平台。事实上，当我第一次启动我的 MinIO 容器时，它使用的是 Docker。那么为什么不只发布一篇关于在 Docker 上运行容器的文章呢？好吧，同样，这很简单。事实上，我在下面为 Podman 运行的大多数命令都可以很容易地用 Docker 完成，只需将命令从一个切换到另一个即可。 Docker 也很好地与 Mac 集成，并且在 Mac 上运行时确实比 Podman 有一些优势（本机容器化是主要优势），但我从来都不是一个简单做事的人。在 90 年代，问题不是“为什么不直接使用 Docker？”而是“为什么不直接使用 Windows？” 在那之前是“为什么不直接使用 emacs？” 还有在那之前“你为什么反对使用穿孔卡片？” 这是一个永无止境的循环，答案总是“因为”。你不妨问我为什么还保留一台可用的 Mac Plus。因为我喜欢它！

我也非常喜欢 Podman。它与 Linux 内核很好地集成，而且让我觉得有趣的是，要在 Mac 上运行它，我实际上是在启动一个小的 Linux 实例，然后由它为我运行 Podman。这些命令被有意地编写成基本上与 Docker 命令相同（实际上，Podman 网站建议简单地将“docker”设为“podman”的别名，然后看看谁会注意到），从而使从我之前熟悉的命令迁移变得非常简单。并且，并非无足轻重，我是一个命令行用户。要在我的 Mac 上运行 Docker，需要 Docker Desktop，我实际上并没有每天都使用它，所以为什么不跳过我不需要的东西呢？

在 Mac 上，可以通过 Homebrew 安装 Podman

brew install podman

这将安装许多支持软件，特别是 qemu 命令。安装 Podman 后，你需要运行一个 Linux 实例。你的 Podman 容器将通过 qemu 在一个小的 Fedora 虚拟机中运行。现在，事情变得有点奇怪了。由于存在这一额外层，你需要将本地驱动器挂载到 Fedora 实例中。幸运的是，当你在初始化机器时，有一个标志允许 Podman 使用 Mac 上的本地驱动器

podman machine init -v /local/path/to/Minio/data:/Minio/data

这很重要！你不希望你的数据卡在执行 Podman 工作的机器内部，因为该机器可以（也可能应该）定期回收。通过让 Podman 从本地目录加载数据，无论容器是否正在运行，你都可以访问该数据，甚至根据需要在其他容器中重用它。

初始化基本机器后，运行

podman machine start

这需要一段时间，甚至可能看起来卡在了 等待虚拟机… 上。耐心是一种美德，很快你就会看到 机器“podman-machine-default”启动成功。在此过程中，你可能会遇到一些关于运行 rootless 的消息（你可以忽略它，因为 MinIO 在 rootless 环境中运行良好，只需要公开端口 9000 和 9090）或运行 Docker API 连接器（通常很有用，因此请按照步骤操作，特别是如果你正在从 Docker 迁移过来——不是说这篇文章以任何方式鼓励这样做）。

一旦你实际运行 Podman 的 Fedora 实例启动并运行，请使用以下命令启动 MinIO 容器：

podman run \
	-p 9000:9000 \
	-p 9090:9090 \
	--name minio \
	-v /Minio/data:/data \
	-e "MINIO_ROOT_USER=admin" \
	-e "MINIO_ROOT_PASSWORD=ifyouusethispasswordsupportwilllaughatyou" \
	quay.io/minio/minio server /data --console-address ":9090"

虽然这似乎接管了你的终端窗口，但实际上你可以按下 Ctrl-C，并取回你的提示符，你的容器仍然会运行。这与 Docker 略有不同，并且有点违背了我对 Linux 的总体经验，但是，我们应该都泰然处之。

由于它是在 Mac 上的 Fedora 虚拟机中运行的 MinIO 容器实例，因此我们在这里实际做的是将本地文件系统 (/local/path/to/Minio/data) 挂载到基于 Fedora 的 Podman 机器 (/Minio/data) 中，然后告诉 MinIO 将其挂载为 /data。然后，服务器使用该目录来存储我们上传到 MinIO 的所有对象。

现在我们遇到了一个大问题：这会导致数据访问速度变慢，因为你正在挂载基本 Linux 实例中的远程磁盘，然后要求 Podman 容器访问它。两层虚拟化磁盘访问可能太慢，以至于 MinIO 无法正常工作，除非你使用的是快速硬件。什么样的速度才算足够快？这样说吧：我的 2012 年英特尔 iMac 无法通过连接到 USB 的外置硬盘存储数据来实现，但在我的 2022 年 MacBook Pro 上，使用板载 SSD 和 M1 Pro 芯片，MinIO 通过 Podman 的功能足以完成我目前要求它做的所有事情。当然，这两台 Mac 之间存在很大差异：10 年；完全不同的处理器架构；存储速度差异巨大。因此，你的体验绝对会有所不同。但是，如果你在一个大量对象中存储了大量数据，你可能会看到一些超时。这应该告诉你，在 Mac 上进行的整个 Podman 操作实际上仅用于开发目的，绝不应该让它离开你的 MacBook 到野外，或者更糟糕的是，生产环境。 [注意：作者并非只是说 Podman 不适合生产——在日常使用的 Mac 上运行 Podman 不适合生产。] 优势在于，如果你在 Mac 上的 Podman 无法满足需求，你仍然可以将你的数据（以及所有服务器设置）带到下一个容器，因为数据就在你的本地文件系统上。

不将其用于生产环境还有另一个充分的理由：服务器时间漂移。如果我的 MacBook 在 Podman 运行时进入睡眠状态，那么我的 Mac 系统时间将开始偏离 Fedora 虚拟机系统时间。这是一个问题，因为 MinIO 会查看客户端发出请求的时间，并将其与 MinIO 在服务器上处理请求的时间进行比较。如果存在差距，MinIO 会拒绝执行请求。显然，这是一个安全措施，并且是 MinIO 实现 S3 兼容存储的一部分，但你可能会在基于 Podman 的开发环境中遇到此问题。也许这是 Podman 未来可能会解决的问题，在休眠一段时间后同步 Fedora 虚拟机时间，或者也许你可以花一些时间在虚拟机上设置一个合适的 NTP 客户端，或者也许它就是这样，因为在真实的生产环境中，主机不太可能像我的 MacBook 一样进入休眠状态。无论如何，解决方法是尝试将其关闭并重新打开，因为它是一个容器，这就是容器的用途。但要全部关闭。以下是步骤

podman stop minio
podman machine stop
podman machine start
podman start minio

这之所以有效，是因为之前的 podman run 命令将容器命名为 minio。如果你将其命名为其他名称，请使用其他名称。

在此阶段，你拥有一个可以向其发送数据和从中提取数据的 MinIO 实例。如果你正在构建一个概念验证，这可能足以展示你的想法，完成第一次迭代，开始开发。而这始终是我的目标：我如何才能从无到有地快速获得值得炫耀的东西。但是，一旦你的应用程序成熟，你需要转向更强大的东西。

Podman 的保养和喂养

在某个阶段，你可能会想要清理所有这些内容并继续处理其他事情。坦白地说，这就是 Podman 在我看来最闪光的地方。通常的 Docker 风格命令都存在，可以向你展示如何删除你的容器和镜像。

podman ps -a
podman rm
podman images
podman rmi

但是 Fedora 虚拟机呢？这个命令可以方便地显示正在运行的内容

podman system connection list

如果你想删除所有内容，在关闭 MinIO 实例和 Fedora 虚拟机后，运行以下命令

podman machine rm

正是这个功能让我选择了 Podman，因为它留下的杂乱少得多。如果你真的想清理，请检查你的主目录，在 .config 和 .local 下。可能只留下一些空目录和 Fedora qcow2 文件。由于 Fedora 定期更新，Podman 会自动更新此文件。但由于 Podman 是无根且无守护进程的，因此没有系统服务需要清理，没有受保护目录中的文件需要查找和删除，并且在你没有积极运行容器时，也没有系统资源被使用。这就是我喜欢它的原因。这就是我使用它的原因。它满足我的需要，仅此而已。

我喜欢的另一件事是 Podman 也定期更新。但是，由于我们在使用 Homebrew，因此更新它就像运行以下命令一样简单

brew upgrade

MinIO 呢？好吧，那个容器镜像会随着我们所有的发布及时移动，所以偶尔拉取一个新的镜像也是值得的！什么时候？这就是你想要花一些时间查看 MinIO 镜像历史记录的地方

podman image historm minio

检查 CMD ["minio"] 条目。如果它的 CREATED 条目超过一周，那么你可能没有运行最新的 MinIO 版本！使用以下命令拉取一个新的版本

podman pull quay.io/minio/minio

然后，只需停止并启动你的 MinIO 容器即可获得所有新功能。数据呢？它仍然都在那里。除非你删除本地目录，否则你的数据将保留。

让我重复一遍

除非你删除本地目录，否则你的数据将保留。

这意味着你可以在需要时轻松地迁移到 Docker 或裸机。

这有道理吗？

没有。

我是认真的。这没有道理。它很笨拙。在某些地方很脆弱。而且它绝对比仅仅安装 Docker Desktop 还要麻烦。或者仅仅在 Mac 上以裸机方式运行 MinIO，这可以通过简单的命令来完成

brew install minio/stable/minio

但它也是一项挑战，有点像“因为它就在那里”的那种风格，我与自己打赌，看看我是否能让它工作。对于一个简单的、快速的、功能性的开发环境来说，它非常棒，而且可以快速清理。它与我们的命令行客户端一起工作，你可以使用以下命令安装它

brew install minio/stable/mc

归根结底，它有一些极客魅力。那么我为什么要这么做呢？因为我喜欢 Mac。我喜欢 Podman。我当然也非常喜欢 MinIO。而且我偶尔也喜欢用难的方式做事，即使它没有道理。明天，我将回去编写 MinIO 的培训，我将更加关注最佳方法、简单方法、可重复的方法，以及有道理的方法。

但仅限于今天，这很有趣。