宣布 Spack 公共二进制包
Spack 最初被设计为源码包管理器，但如今用户无需再苦苦等待编译。多年来，Spack 一直具备创建二进制构建缓存的能力，但构建二进制文件的重担一直落在用户（如应用团队、HPC 设施的部署团队等）身上。
今天，得益于 Spack v0.18 中的一些改进，以及 AWS、Kitware 和 E4S 项目团队的帮助，我们开始走上为 Spack 中所有内容构建二进制文件的道路。目前，我们已经为以下操作系统/架构提供了二进制文件：
| 操作系统 | 目标架构 |
|---|---|
amzn2 (Amazon Linux 2) |
graviton2 |
amzn2 |
aarch64 |
amzn2 |
x86_64_v4 |
ubuntu18.04 |
x86_64 |
您也可以在 cache.spack.io 浏览这些缓存的内容。
如果您已经是老手，这里是尝试 0.18 二进制版本所需的步骤：
spack mirror add binary_mirror https://binaries.spack.io/releases/v0.18
spack buildcache keys --install --trust
如果您不熟悉 Spack 二进制文件，我们在下方提供了在 graviton2 节点上使用这些二进制文件的说明。请注意，您不需要检出 Spack v0.18 版本；您也可以使用来自最新 develop 分支的缓存。
Spack 二进制文件有何不同？
二进制打包并不新鲜，基于 .rpm 和 .deb 的发行版已经存在多年，而 conda 在 Python 世界也非常流行。在这些发行版中，二进制包规范与二进制文件之间通常存在 1:1 的关系，并且长期维护着单一、可移植的软件栈。
传统上，HPC 用户避免使用这类系统，因为它们并非针对我们想要运行的具体机器而构建，且很难为我们想要支持的所有不同类型的机器生成二进制文件。GPU 和特定的微架构（例如 skylake、cascadelake 等）使情况变得更加复杂。
Spack 二进制文件更类似于 Nix 或 Guix 所使用的那些——它们是构建过程的缓存，而不是特殊准备的二进制文件，通过二进制安装包在本质上与从源码构建产生的是相同的安装结果。为了确定性，软件包在部署时会携带它们构建时所用的依赖项。Spack 的一个不同之处在于，我们在构建中存储了更多的元数据——编译器、微架构目标（使用 archspec）、标志、构建选项和其他元数据。我们可以使用单个软件包来构建所有这些目标，并且可以从单个软件包描述中生成许多经过优化的二进制文件。其效果如下：
借助 Spack，我们不仅尝试利用可移植的软件包 DSL 来实现可移植的构建，还将其用于优化的二进制文件。我们可以从相同的软件包文件和目标中生成许多经过优化的二进制文件，并且可以使用相同的软件包描述来维护许多可移植的软件栈。这减轻了维护人员的负担，因为我们不需要支持成千上万个配方——只需要支持软件包数量对应的配方即可。而且，使用 Spack 环境可以轻松地即时组装新的软件栈。Spack 二进制文件也是可重定位的，因此您可以轻松地将其安装在您心仪的 HPC 机器的主目录中，而无需请求管理员协助。
滚动发布的持续集成 (CI)
为了支持组合式二进制文件，我们尽量将工作向上游推进。我们不想花一周时间来准备一个新版本，因此我们围绕这些构建构建了云自动化。对于 Spack 的每一个 PR，我们都会重建我们支持的栈，并允许贡献者在 PR 中迭代他们的二进制构建。我们在不同的架构和不同的站点上测试这些构建，如果 PR 更改或引入的所有构建都通过了测试，我们就将该 PR 标记为可以合并。这使我们能够依靠最广泛的软件包维护者群体来确保我们的构建始终正常运行。
这种方法的一个问题是，我们不能信任在 pull request 中完成的构建。我们需要知道 PR 构建是否有效，但我们可能不认识所有的贡献者，也不能信任核心维护者批准 PR 之前构建的内容。我们通过分叉构建过程解决了这个问题。
每个 PR 都有其自己的二进制缓存，贡献者可以在维护者审阅其工作之前迭代构建（尽管对于首次贡献者，我们显然必须批准 CI）。贡献者可以在他们自己的栈上并行工作，且每个 PR 的构建缓存使他们能够快速工作，仅重建已更改的软件包。
一旦维护者审阅并批准了 PR，我们就会在更受信任的环境中重建引入的任何新二进制文件。此环境不会重用来自 PR 环境的任何二进制数据，这确保了早期 PR 提交中的不良内容不会通过二进制文件混入。我们为 develop 和 release 分支进行重建，并在与构建环境分离的环境中进行签名，以确保签名密钥永远不会暴露给构建系统代码。完成并签名的重建版本会被放置在滚动的 develop 二进制缓存或特定版本的二进制缓存中。您可以在 spack.github.io/keys 找到该版本的公钥。
扩展缓存
这仅仅是冰山一角。我们目前每周在 Amazon AWS 上运行 40,000 次构建以维护我们的二进制文件，并在 E4S 项目的帮助下保持其运行。Kitware 正在确保我们的云构建基础设施能够扩展。您可以在 stats.e4s.io 查看构建农场的统计数据。
我们将在不久的将来扩展到数千个。我们的目标是最终覆盖所有 Spack 软件包，使大多数用户不再需要从源码构建，并消除从决定运行模拟到能够开始科学模拟之间的漫长等待时间。敬请期待更多的编译器、更多优化的构建和更多的软件包。
Spack 旨在降低维护二进制发行版的负担，并使混合源码构建与二进制安装变得简单。二进制镜像中可用的软件包将通过二进制文件进行安装，而对于任何不可用的软件包，Spack 将无缝切换到源码构建。用户将看到二进制包安装速度提升约 20 倍，且二进制打包的性能改进工作正在进行中。
在云端运行 Spack 二进制文件
在全新的 amazon-linux 镜像上，您只需 7 条命令即可安装经过优化的 HPC 应用程序。（如果您已经在运行 Spack，则只需额外 3 条命令）。如果您想并行运行这些代码，可以在 ParallelCluster 实例上执行此操作。
假设您想要安装 gromacs。
首先我们需要安装 Spack。Spack 需要一些底层依赖项才能运行，包括 C/C++ 编译器。默认情况下，您的镜像中没有这些内容，因此您需要使用 yum 安装它们：sudo yum install -y git gcc gcc-c++ gcc-gfortran
现在您可以从 github 克隆 Spack 并检出最新版本。Spack 将引导其余所需的组件来安装二进制软件包。您还需要设置 Spack shell 集成，以便将 Spack 加入您的路径并使其所有功能可用：git clone https://github.com/spack/spack.git cd spack git checkout v0.18.0 . share/spack/setup-env.sh
现在您可以配置 Spack 以使用预构建的二进制缓存。您可以将其指向 develop 或 releases/v0.18.0。
spack mirror add binary_mirror https://binaries.spack.io/develop
spack buildcache keys --install --trust
您可以将 Spack 下载的公钥与 https://spack.github.io/keys/ 上提供的公钥进行比较，以作为验证二进制文件来源的另一种真实性来源。
现在您可以下载优化的 HPC 应用程序二进制文件了。
spack install gromacs
Spack 将为任何可用的包规范安装二进制文件，并积极重用依赖项的二进制文件。您可以使用 Spack 查看有哪些可用内容。
spack buildcache list --allarch
任何不可用的内容仍将重用现有的依赖项二进制包，并无缝故障转移到从源码构建那些尚无二进制文件的组件。
10 分钟后，您的应用程序就已经可用了，现在您可以去进行您原本打算进行的科学研究了。