使用Apple Silicon（M1）作为云工程师，历时两个月

因此，我几个月来一直在使用新的基于M1的MacBook Pro，以进行开发，电子邮件和开源维护者日常工作的其他工作。

使用此功能时，您通常会收到的典型第一反应是＆＃34;它运行我的Docker堆栈时听起来并不像飞机要起飞。

这是一个非常了不起的工程，从很多方面来说，我认为ARM体系结构是未来。许多快速发展的科技巨头（除苹果公司之外）正投入大量资金使ARM在大量用例中发挥作用：Nvidia（试图从软银购买ARM控股公司）和Amazon（对新型Graviton处理器的巨额投资） ）是最先想到的两个。

如您所知，在处理器中，低能耗（和低散热）通常等同于针对大型工作负载有效扩展处理能力。对于非云计算用例，这也意味着更长的电池续航时间（更少的浪费，更多的花销）。这就是为什么我认为ARM是未来的原因，即使主流云可能要花十年的时间才能迁移过来。

我需要使用的所有软件都可以正常工作。我发现，如果ARM本地版本不适用于某个应用程序，则模拟的版本就可以正常工作，并且我不会注意到任何性能上的缺陷。要模拟应用程序，您只需要安装Rosetta2。操作系统将自动检测到需要Rosetta，并提示您安装它。但是，您也可以通过以下方式手动安装

您用于开发的工具可能仍会赶上这种体系结构的更改，并且将持续一段时间。我们的工程师有时会使用非常低级的系统功能。在某些情况下，我必须安装软件的预览版，但是一切对我来说都很好。这是我测试过的一些程序：

✅VS代码。 amd64版本可以很好地运行，但是终端将是amd64进程，这可能会导致某些程序也以amd64的身份运行。在VS Code Insiders上可以使用arm64本机版本，并且效果非常好。

✅码头。 M1本机版本是必须的。仿真不会具有虚拟化功能，Docker应用程序需要虚拟化功能。您可以为M1下载Docker应用程序，该应用程序正在预览中。如文档页面上所述，目前有一些局限性与HTTP代理，VPN客户端和性能相关，但Docker团队正在快速取得进度。 （一个月或两颗月kubernetes wasn＆＃39; t工作，但现在是！）。

我还应该提一下，在前几周内，我在使用蓝牙时发出音频跳过的一些问题，但操作系统更新固定它（就像Apple批准）。

我还使用✅yubikey 5c nano和一堆随机外围设备，如✅USB麦克风和插入以太网的✅码头。

✅去。 1.16 RC为建立达尔文/ ARM64二进制文件增加了支持。我在Docker中建立了二进制文件，本身跑了它们。伟大的工作。

🟡java和scala。我有JVM的问题，遇到随机过程挂起。似乎没有AARCH64的官方OpenJDK版本，但有一些社区选项。查看以下信息。

🔴.NET并没有为我工作，也没有模仿。我没有调查原因。

✅Ruby和Ruby在Rails上工作在Docker中的本机架构上。尽量少的测试。

弄错您所运行的体系结构非常容易。 Rosetta 2很好。

区别的最简单方法是打开“活动监视器”，然后查看“架构”列：如果说的是Apple，它就是ARM。如果显示Intel，则为X86_64。这是我如何分辨Zoom是ARM进程，而Spotify是X86_64进程。

如果您不确定所使用的终端，则可以键入uname -m。它会说X86_64，arm64（mac）或aarch64（linux）。 arm64和aarch64都是ARM-与Mac相比，Mac上的uname报告有所不同。

我在M1笔记本电脑和MacStadium MacMini实例（我们用于Mac测试）上遇到的一个问题是Brew随机开始抱怨git丢失。不确定造成这种情况的原因是什么，但是可能是因为brew在过去几个月中一直在为许多软件包添加本机支持，并且这种迁移有可能导致某些不一致之处。这纯粹是猜测，但是，我还没有对此进行研究。

（无论如何，对于承载这么多程序包的项目，如此快速地切换体系结构都是一项非常令人印象深刻的工作！）

回到现在解决问题。使用brew doctor，我发现Xcode需要重新安装。简单：xcode-select --install。但是，问题仍然存在。在MacStadium实例上，我能够卸载brew并重新安装它，一切都很好。在通过木桶安装了很多东西之后，我在笔记本电脑上这样做不太舒服。取而代之的是，我能够通过brew brew卸载git来删除brew git，并且仅依赖于Xcode的git，这似乎还可以。 （如果任何人阅读此书都知道我的啤酒git有什么问题，并可以告诉我如何解决它，请在Twitter上对我执行ping操作：@vladaionescu）

从第一天开始，Docker预览对我来说几乎是完美无缺的。一开始使用多平台图像似乎令人生畏，但实际上它非常简单。

用于Mac App的Docker与Qemu一起打开盒子 - 所以Docker能够运行ARM64和AMD64图像。现在，大多数官方图像也支持ARM64。如果您＆＃39;重新构建图像，默认情况下，它＆＃39; ll使用您的本地体系结构执行构建（arm64），大多数事情通常只需工作。但是，如果您正在卷曲某些二进制文件，可能需要在其URL中从x86_64切换到AARCH64的一些二进制文件，或者您＆＃39;重新执行较低级别的东西。我也注意到一些阿尔卑斯山包裹也不适用于ARM（例如Shellcheck）。

Docker团队建议Qemu是一种最佳方法，最好尽可能地运行图像。当我试图通过qemu效仿它们时，我遇到了一些二进制文件。这里的Sebastiaan Van Stijn的报价＆＃39; Moby技术转向Comitee（TSC）的成员。

几乎所有官方图像都适用于任何一个平台。第三方是一个混合包，大部分社区都只提供了AMD64版本。作为样本，Kafka社区形象仅为AMD64。 Redis Image是多平台的。你怎么知道？转到Docker Hub页面以获取标记（例如最新）并查找此下拉列表。如果存在下拉目，则意味着它＆＃39; s多平台图像。

要为不同的体系结构构建图像，可以使用Docker BuildX Build --platform = Linux / AMD64。而不是通常的Docker Build ..有关建设多平台图像的更多详细信息，请参阅Akihiro Suda＆＃39; s博客。

如果码头从注册表中提取图像，则将默认为您的本机架构（如果可用），除非您指定--platform = linux / amd64。

如果您停放运行图像，它将默认为您在本地可用的图像的任何版本，或者它将尝试从注册表中提取ARM64版本。您还可以通过--platform = linux / amd64来覆盖平台，如果您＆＃39; d专门运行AMD64版本。

Docker Compose会愉快地运行各种架构的混合。相同的规则适用于拉动和运行。您还可以指定平台：Linux / AMD64，用于Docker-Compose.yml中的服务定义，如果您喜欢具体。

需要注意的一件事是，QEMU不支持Docker-in-Docker（此处不再使用PR）。因此，您不能在amd64 Docker中运行arm64 Docker，反之亦然。但是，如果您运行本机支持的Docker-in-Docker，则内部Docker仍然可以很好地运行多平台映像。

我在M1上的Docker预览中注意到的另一个问题是，当前使用多处理器存在性能问题-如此之多，以至于使用单核的性能有时会比使用8核的性能稍好。或者至少是@jasmas声称的。我还看到了一些基准测试了MySQL之类的数据库的导入，并且看来苹果虚拟化API存在一些明显的性能问题（约25倍）。我没有看到这种常用用法有如此大的差异，但希望这些问题能尽快解决。

通用的VS Code版本尚未提供对Apple Silicon的本地支持，但运行amd64仿真版本的效果很好。您还可以通过VS Code Insiders提供的VS Code Universal版本（在单个软件包中包含两种体系结构）使用本机版本。

我在使用amd64版本时遇到的一个问题是，我没有意识到终端机也是amd64进程（同样，Rosetta 2也是如此）。在某些情况下，这会导致运行Docker时出现一些奇怪的问题，其中QEMU正在处理分段错误。经过一番努力之后，通过切换到基于ARM的VS Code Insiders版本解决了该问题。

我们已经在Earthly中增加了对Apple M1的支持，到目前为止，它的运行非常出色。这是Beta版，因此如果您尝试一下-我们非常感谢您可以通过GitHub问题或在Slack中给我们提供任何反馈。

我经常使用的一个实用的实用技巧是，如果尚未将构建的一部分移植到amd64，则只需将其标记为--platform = linux / amd64-因此只有该部分可以在amd64。其余的将在本地运行。但是，这是相对罕见的-大多数Docker构建都可以在任何一个平台上工作。我们的示例构建非常具有代表性。还提供了有关Earthly的多平台构建的详尽指南。

您不必构建darwin / arm64二进制文件即可在M1上运行它们。 Rosetta 2仿真在Intel上非常有效。但是，如果您愿意，Go 1.16 RC刚刚添加了对此的支持。

使用JVM时遇到问题。在线调查之后，似乎OpenJDK尚未可用于M1。对我而言，这表现出来的方式是JVM进程将随机挂起。通过在Docker或Earthly版本中使用--platform = linux / amd64，我能够使OpenJDK大部分时间都能正常工作，但是我仍然看到随机挂起。

根据此StackOverflow线程，存在Azul为M1提供的Zulu JDK构建，并且Microsoft也为OpenJDK建立了aarch64构建。我没有测试这些，所以我不能说它们是否运作良好。

关于新笔记本电脑，我注意到的一件事是，一切打开都非常快，而从睡眠时间中唤醒的时间也很短。不过，这些差异是不到一秒的差异，因此您可能不会注意到-也许这是安慰剂对我起作用，并且没有真正的差异:-)

如上所述，由于多核问题，Docker目前较慢。据我所知，与Intel MacBook Pro相比，差异约为1.75倍。我认为这将在将来的Docker for Mac应用程序预览中修复。

M1的电池续航时间真的非常好-变焦会议和电子邮件的半天时间仅消耗了我20％的电池电量。我很多时候在家工作，所以我不经常使用。但是很高兴知道，如果我在旅​​途中需要它的话，它确实可以持续很长时间。

我不能不谈起M1的安装成本。它的规格与我去年购买的Intel MBP非常相似，但是便宜了整整1000美元。太疯狂了。我不知道为什么-在大多数情况下，它感觉确实很出色，没有噪音，并且电池寿命很长。

我认为这里的策略是，这将是该产品线中的低端MacBook Pro，而未来基于Apple Silicon的产品将具有更强大的规格。

如您所见，我的工作流程非常繁琐。 Docker对我来说似乎运作良好，它消除了与单个语言生态系统工具有关的任何可能的痛苦。

对于大多数二进制文件，如果它们不能在本地平台上运行，则Rosetta 2可以在它们上面产生奇迹，或者只需要Docker中的--platform = linux / amd64即可。 JVM问题是我无法完全解决的唯一问题-而且，我也没有花时间去尝试Microsoft提供的OpenJDK构建或Zulu JVM。

总体而言，我对我的M1感到满意。我喜欢最前沿的技术，并且不得不使用某些软件的预览版，但是在我的典型工作流程中没有主要问题。我很惊讶大多数事情的效果如何。

如果您是开发人员，而您的编码效率取决于您的笔记本电脑，那么在购买之前，我会三遍检查我的设置是否可以在ARM架构上正常工作。在大多数情况下，您在Java / Scala世界之外应该还不错-但您永远不会知道！ QEMU有时会被击中或错过。

如果您不是开发人员，或者仅使用笔记本电脑浏览和发送电子邮件，那么我真的看不到为什么您会在此笔记本电脑上选择Intel MacBook的任何原因。我还要假设MacBook Air版本也很棒（与Intel版本的MacBook Air不同，后者通常在现代Web浏览中速度较慢）。 M1芯片在Pro和Air之间非常相似，因此不需要风扇。