【Hacker News搬运】缓存为王：GitHub Actions中Docker层缓存指南

hackernews

Title: Cache is King: A guide for Docker layer caching in GitHub Actions

缓存为王：GitHub Actions中Docker层缓存指南

Text:

Url: https://blacksmith.sh/blog/cache-is-king-a-guide-for-docker-layer-caching-in-github-actions

在分析抓取的内容后，以下是对所提供文章的总结：

文章讨论了在GitHub Actions中使用Docker进行构建时实现缓存的不同策略。Docker的缓存机制基于层的概念，其中每个层都是Dockerfile中指令的结果，并且只包含前一层的变化。这种分层结构允许在后续的Docker构建中重用层，从而实现更快的、按需构建，而不是每次都从零开始构建。

文章首先描述了没有缓存的情况，即每次运行作业时Docker都需要从头开始构建图像。然后，它介绍了三种不同的缓存策略：

1. 使用GitHub Actions本地缓存：这是最简单的策略，但它的缓存空间有限（每个仓库只有10GB），并且缓存仅限于运行Docker构建的开发分支。这意味着缓存不能在组织内或与其他构建系统共享。

2. 使用Docker注册表作为缓存后端：这种方法包括内联缓存和注册表缓存。内联缓存将构建缓存直接嵌入Docker图像中，而注册表缓存将缓存作为注册表中的单独图像存储。这种策略的好处是不受GitHub Actions缓存大小限制和淘汰策略的影响，并且可以在组织内或与其他构建系统中共享缓存。

3. 注册表缓存后端：这是内联缓存的增强版，它将缓存 artifacts作为单独的图像推送到注册表中。与内联缓存不同，注册表缓存支持在多阶段Docker构建中缓存中间层，从而增加后续构建的缓存命中几率。它还支持多种选项，如压缩类型、级别和缓存图像的命名等。

文章最后提到，Blacksmith公司一直在寻找提高CI作业性能的方法，并预告了即将推出的自动Docker层缓存功能、同源Docker镜像和强大的远程构建器等功能。如果需要帮助优化工作流程，或者希望在新功能发布时获得通知，可以联系他们的邮箱hello@blacksmith.sh。

Post by: adityamaru

Comments:

cpfohl: This is wild. I've spent the last three weeks working on this stuff for two separate clients.Important note if you're taking advice: cache-from and cache-to both accept multiple values. Cache to just ouputs the cache data to all the ones specified. cache-from looks for cache hits in the sources in-order. You can do some clever stuff to maximize cache hits with the least amount of downloading using the right combination.

cpfohl: 这太疯狂了。I-；在过去的三个星期里，我为两个不同的客户做这件事 重要提示如果您；重新考虑建议：cache-from和cache-to都接受多个值。Cache，只将缓存数据输出到所有指定的数据。cache from按顺序查找源中的缓存命中数。使用正确的组合，您可以做一些巧妙的事情，以最少的下载量最大限度地提高缓存命中率。

user-: I feel like ive seen so many new companies just providing cheaper github actions.

user-: 我觉得我看到很多新公司只是提供更便宜的github操作。

boronine: I've spent days trying all of these solution at my company. All of these solutions suck, they are slow and only successful builds get their layers cached. This is a dead end. The only workable solution is to have a self-hosted runner with a big disk.

boronine: I-；我在公司花了好几天时间尝试所有这些解决方案。所有这些解决方案都很糟糕，速度很慢，只有成功的构建才能缓存层。这是一条死胡同。唯一可行的解决方案是拥有一个带有大磁盘的自托管运行程序。

aayushshah15: (blacksmith co-founder here)it's unfortunate the amount of expertise / tinkering required to get "incrementalism" in docker builds in github actions. we're hoping to solve this with some of the stuff we have in the pipeline in the near future.

aayushshah15: （此处为铁匠联合创始人）；不幸的是，专业知识的数量；需要修补才能获得“；渐进主义；在docker中构建github操作。我们；我们希望在不久的将来用我们正在准备的一些东西来解决这个问题。

notnmeyer: this is pretty neat—it’s been a while since i’ve tried caching layers with gha. it used to be quite frustrating.my previous experience was that in nearly all situations the time spent sending and retrieving cache layers over the network wound up making a shorter build step moot. ultimately we said “fuck it” and focused on making builds faster without (docker layer) caching.

notnmeyer: 这非常巧妙——我已经有一段时间没有尝试使用gha缓存层了。这曾经很令人沮丧 我以前的经验是，在几乎所有情况下，通过网络发送和检索缓存层所花费的时间都会使更短的构建步骤变得毫无意义。最终，我们说了“去他妈的”，并专注于在没有（docker层）缓存的情况下使构建更快。