我已将初始 azure-pipelines.yml 拆分为使用模板、迭代等...无论出于何种原因，尽管使用了 latest 标记和/或 {{1 }}。
此外，我基本上有两个管道 imagePullPolicy: Always 和 PR：
Release 在提交 PR 请求以合并到 PR 时触发。它会自动触发此管道来运行单元测试、构建 Docker 映像、执行集成测试等，然后在一切通过后将映像推送到 ACR。production 管道通过且 PR 获得批准时，它会合并到 PR 中，然后触发 production 管道。以下是我的 Release 部署清单之一的示例（应用这些清单时，管道会显示 k8s）：
unchanged以下是我一直在拆分的与 apiVersion: apps/v1
kind: Deployment
metadata:
name: admin-v2-deployment-prod
namespace: prod
spec:
replicas: 3
selector:
matchLabels:
component: admin-v2
template:
metadata:
labels:
component: admin-v2
spec:
containers:
- name: admin-v2
imagePullPolicy: Always
image: appacr.azurecr.io/app-admin-v2:latest
ports:
- containerPort: 4001
---
apiVersion: v1
kind: Service
metadata:
name: admin-v2-cluster-ip-service-prod
namespace: prod
spec:
type: ClusterIP
selector:
component: admin-v2
ports:
- port: 4001
targetPort: 4001
相关的各种管道：
.yamls# templates/variables.yaml
variables:
dockerRegistryServiceConnection: '<GUID>'
imageRepository: 'app'
containerRegistry: 'appacr.azurecr.io'
dockerfilePath: '$(Build.SourcesDirectory)'
tag: '$(Build.BuildId)'
imagePullSecret: 'appacr1c5a-auth'
vmImageName: 'ubuntu-latest'
# pr.yaml
trigger: none
resources:
- repo: self
pool:
vmIMage: $(vmImageName)
variables:
- template: templates/variables.yaml
stages:
- template: templates/changed.yaml
- template: templates/unitTests.yaml
- template: templates/build.yaml
parameters:
services:
- api
- admin
- admin-v2
- client
- template: templates/integrationTests.yaml
# templates/build.yaml
parameters:
- name: services
type: object
default: []
stages:
- stage: Build
displayName: Build stage
jobs:
- job: Build
displayName: Build
steps:
- ${{ each service in parameters.services }}:
- task: Docker@2
displayName: Build and push an ${{ service }} image to container registry
inputs:
command: buildAndPush
repository: $(imageRepository)-${{ service }}
dockerfile: $(dockerfilePath)/${{ service }}/Dockerfile
containerRegistry: $(dockerRegistryServiceConnection)
tags: |
$(tag)
# release.yaml
trigger:
branches:
include:
- production
resources:
- repo: self
variables:
- template: templates/variables.yaml
stages:
- template: templates/publish.yaml
- template: templates/deploy.yaml
parameters:
services:
- api
- admin
- admin-v2
- client
# templates/deploy.yaml
parameters:
- name: services
type: object
default: []
stages:
- stage: Deploy
displayName: Deploy stage
dependsOn: Publish
jobs:
- deployment: Deploy
displayName: Deploy
pool:
vmImage: $(vmImageName)
environment: 'App Production AKS'
strategy:
runOnce:
deploy:
steps:
- task: KubernetesManifest@0
displayName: Create imagePullSecret
inputs:
action: createSecret
secretName: $(imagePullSecret)
kubernetesServiceConnection: 'App Production AKS'
dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
- ${{ each service in parameters.services }}:
- task: KubernetesManifest@0
displayName: Deploy to ${{ service }} Kubernetes cluster
inputs:
action: deploy
kubernetesServiceConnection: 'App Production AKS'
manifests: |
$(Pipeline.Workspace)/k8s/aks/${{ service }}.yaml
imagePullSecrets: |
$(imagePullSecret)
containers: |
$(containerRegistry)/$(imageRepository)-${{ service }}:$(tag)
和 PR 都通过...对我在这里做错的任何建议？
答案 0 :(得分：3)
无论出于何种原因，尽管使用了最新标签，但并未部署新图像
Kubernetes 如何知道有新镜像？ Kubernetes 配置是声明性。 Kubernetes 已经在运行曾经是“最新”的镜像。
<块引用>这是我的一个 k8s 部署清单的示例（应用这些清单时管道表示未更改）
是的，它未改变，因为声明性disered状态没有改变。部署清单声明了应该部署什么，它不是命令。
无论何时构建映像，请始终为其指定一个唯一名称。并且无论何时您想要部署某些东西，始终为应该运行的什么设置一个唯一的名称——然后 Kubernetes 将使用滚动部署以优雅的零停机方式管理它——除非您将其配置为不同的行为。
答案 1 :(得分：1)
在你的部署中你拉
image: appacr.azurecr.io/app-admin-v2:latest
由于没有散列，而只是引用了部署的标记 latest 说：
“你想要最新的？我有最新的跑步！”。
重要的部分是“运行”。如果首先不需要拉取，拉取策略 always 无济于事。
可能的解决方案：