MinIO、Podman 和 Apple Silicon

很长一段时间以来，我一直是 Mac 用户。就像“上个千年”一样。因此，我一直乐于寻找让软件在我的 Mac 上运行的方法，无论这是个好主意还是坏主意。但是当谈到服务器时，我全神贯注于 Linux，这也意味着在寻找可行的解决方案方面存在一定的疯狂。十多年前转向 OS X（现在的 macOS）在我的世界里是一件非常受欢迎的事情，因为这意味着我可以直接在我的 Mac 上使用所有 Linux 脚本的优点，而无需虚拟机，或双启动，或者坦率地说，妥协.  

然后出现了容器和云以及随之而来的一切，包括这种心态的转变，即您可以在需要时启动服务器，并在完成工作后让它干净地消失。MinIO 在这种环境下工作得非常好！当我加入 MinIO 时，我热衷于让一些 MinIO 容器在我的 Mac 上运行。

自制软件让一切变得简单

对于那些不熟悉 Homebrew 的人来说，它被称为 Mac 的“缺失包管理器”。对于阅读本文的开发人员，我不能大声说：get Homebrew。做吧。首先，我从这一点开始的所有笔记都基于 Homebrew，其次，它绝对是以一种与操作系统集成的简单方式获取大量软件包的最佳方式，而不会在你的系统中乱扔一堆文件。甚至，我非常兴奋地说，MinIO 本身可以从 Homebrew 安装，如果你想运行裸机，只需一个简单的brew install minio/stable/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 VM 中运行。现在，这就是它变得有点奇怪的地方。由于这个额外的层，您需要将本地驱动器挂载到 Fedora 实例中。幸运的是，有一个标志允许 Podman 在您初始化机器时使用 Mac 上的本地驱动器：

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

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

一旦基础机器被初始化，然后运行：

podman machine start

这需要一点时间，甚至可能看起来挂在Waiting for VM …  耐心是一种美德上，很快您就会看到Machine "podman-machine-default" started successfully。在这个过程中，你可能还会遇到一些关于running rootless的消息（你可以忽略这个，因为MinIO在rootless环境下运行良好，只需要暴露端口9000和9090）或者运行Docker API connector（一般有用，所以跟随这些步骤，特别是如果你一般从 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 VM 中运行的 MinIO 容器实例，我们在这里真正做的是将本地文件系统 ( ) 挂载/local/path/to/Minio/data到基于 Fedora 的 Podman 机器 ( /Minio/data) 中，然后告诉 MinIO 将其挂载为/data. 服务器然后使用该目录来存储我们上传到 MinIO 的所有对象。  

现在我们遇到了一个大问题：这会导致数据访问速度变慢，因为您在基本 Linux 实例中安装了一个远程磁盘，然后要求 Podman 容器访问它。除非您使用快速硬件，否则两层虚拟化磁盘访问对于 MinIO 来说可能太慢而无法真正发挥作用。多快才够快？让我们这样说吧：我的 2012 Intel iMac 无法将数据存储在 USB 连接的外部驱动器上，但在我的 2022 MacBook Pro 上，带有板载 SSD 和 M1 Pro 芯片，MinIO-via-Podman 是到目前为止，它的功能足以完成我要求它做的几乎所有事情。当然还有很多这两台 Mac 之间的日光间隔：10 年；完全不同的处理器架构；存储速度差别很大。所以，你的里程绝对会有所不同。但是，如果您在大量对象中存储大量数据，您可能会遇到一些超时。这应该告诉您的是，Mac 上的整个 Podman 练习实际上仅用于开发目的，绝不应允许离开您的 MacBook 进入野外或更糟糕的生产环境。[注意：作者不仅仅说Podman 不适合生产——日常使用的 Mac 上的 Podman 不适合生产。]  好处是，如果您在 Mac 上不再使用 Podman，您仍然可以将您的数据（以及所有服务器设置）带到下一个容器中，因为数据就在您的本地文件系统中。

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

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

这是有效的，因为podman run之前的命令称为 container minio。如果您将其命名为其他名称，请使用其他名称。

在这个阶段，你有一个工作的 MinIO 实例，你可以向它发送数据和从中提取数据。如果您正在构建 POC，这可能足以展示您的想法，完成第一次迭代，开始开发。这一直是我的目标：我能以多快的速度从一无所有变成值得炫耀的东西。但是，一旦您的应用程序成熟，您将需要转向更强大的东西。

Podman 护理和喂养

在某个阶段，你会想要清理所有这些并继续做其他事情。坦率地说，这是 Podman 在我看来最闪耀的地方。通常的 Docker 样式命令都在那里向您展示如何删除容器和图像：

podman ps -a
podman rm
podman images
podman rmi

但是 Fedora VM 呢？此命令方便地向您显示正在运行的内容：

podman system connection list

如果您想删除所有内容，请在关闭 MinIO 实例和 Fedora VM 后运行：

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。我喜欢波德曼。当然，我也喜欢一些 MinIO。有时我喜欢用艰难的方式做事，即使这没有意义。明天，我将回去为 MinIO 编写培训，我将更加专注于最好的方式、简单的方式、可重复的方式，以及 Makes Sense 的方式。

但就在今天，这很有趣。