使用Apple Silicon(M1)作为云工程师,历时两个月

2021-03-04 02:54:57

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

使用此功能时,您通常会收到的典型第一反应是"它运行我的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' 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。如果您'重新构建图像,默认情况下,它' ll使用您的本地体系结构执行构建(arm64),大多数事情通常只需工作。但是,如果您正在卷曲某些二进制文件,可能需要在其URL中从x86_64切换到AARCH64的一些二进制文件,或者您'重新执行较低级别的东西。我也注意到一些阿尔卑斯山包裹也不适用于ARM(例如Shellcheck)。

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

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

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

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

如果您停放运行图像,它将默认为您在本地可用的图像的任何版本,或者它将尝试从注册表中提取ARM64版本。您还可以通过--platform = linux / amd64来覆盖平台,如果您' 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之间非常相似,因此不需要风扇。