各种各样的开发人员,
在azure管道的容器作业中,即使同一容器用于多个作业,对于每个作业容器也会从注册表中拉出。
当然,如果映像真的很小,这没问题,但是如果有人打算使用覆盖vscode本地开发的相同映像进行构建-这会比实际构建花费更多的时间。 / p>
那么有人解决了缓存容器的问题吗?
这里是一个例子:
# in this example, all jobs use the same container.
# in stage 1, the jobs are started serial, so job 2 only starts if
# job 1 is done -> and the image is downloaded for both jobs independently
# in stage 2, the jobs are started in parallel,
# and the image is downloaded for both jobs in the stage independently
trigger:
batch: true
branches:
include:
- "*"
resources:
containers:
- container: ubuntu
image: ubuntu:18.04
stages:
- stage: STAGE1
jobs:
- job: PrintInfoStage1Job1
container: ubuntu
steps:
- script: |
echo "THIS IS STAGE 1, JOB 1"
displayName: "JOB 1"
- job: PrintInfoStage1Job2
dependsOn: PrintInfoStage1Job1
container: ubuntu
steps:
- script: |
echo "THIS IS STAGE 1, JOB 2"
displayName: "JOB 2"
- stage: STAGE2
dependsOn: STAGE1
jobs:
- job: PrintInfoStage2Job1
dependsOn: []
container: ubuntu
steps:
- script: |
echo "THIS IS THE STAGE 2, JOB 1"
displayName: "JOB 1"
- job: PrintInfoStage2Job2
container: ubuntu
dependsOn: []
steps:
- script: |
echo "THIS IS THE STAGE 2, JOB 2"
displayName: "JOB 2"
答案 0 :(得分:2)
Azure DevOps容器作业:用于多个作业的缓存容器吗?
最初,我们的设计和开发思路主要是出于安全性和一致性原因考虑的,因此每次都应该是崭新的形象。现在,我们收到了来自许多开发人员的关于希望支持缓存图像的mannny功能请求。现在,考虑到这种设计思想的缺点,这将使开发人员浪费太多时间等待图像被下拉。如果可以缓存图像,则可以大大提高构建效率。
现在,有关此功能的大部分实际缓存工作已经由我们的Azure Artifacts团队完成。由于我是从该团队获得的最新流程,是我们无法在天蓝色devops中发布此功能之前,需要做一些工作,这些工作围绕安全性来确保不会将缓存用作攻击媒介。完成此操作后,我们将启动客户预览。它将在最近部署。
请参阅我们的路线图:Speed up pipeline with caching跟踪其开发和发布过程。您还可以跟踪由天蓝色工件PM发布的blog。另外,您可以关注并监视此PR。
直到现在,没有什么更好的方法可以改善此问题。甚至将 Cache 任务与 Docker 结合使用来执行其任务,保存/加载各自的操作与从公共注册表下载基本映像/层的操作非常匹配。
我仍将监视此功能的开发过程。一旦PR完成并将功能代码部署到所有区域(甚至将其作为预览功能发布),我将更新此答案以让您和其他SO用户知道。