我目前有一个 GitHub 存储库，其中包含我的应用程序代码和 Kubernetes 部署配置文件（称为deployment.yml）。即，我的存储库具有以下结构：
repository
+- ...application code...
+- Dockerfile
\- deployment.yml
当更改推送到此 GitHub 存储库时，将执行一系列 GitHub 操作，将我的应用程序容器化为 Docker 映像并将该映像发布到 Docker Hub。
在开发机器上，我有一个 Kubernetes 集群正在运行。我deployment.yml从存储库中提取文件，然后kubectl apply -f deployment.yml使用kubectl rollout restart deployment/<name>.
我deployment.yml的配置如下：
apiVersion: apps/v1
kind: Deployment
metadata:
...
spec:
replicas: 1
...
template:
...
spec:
containers:
- name: <name>
image: foo/bar:v1.0.0
imagePullPolicy: IfNotPresent
ports:
- containerPort: <port>
imagePullSecrets:
- name: <creds-id>
图像的版本（即v1.0.0in foo/bar:v1.0.0）源自我在 Git 中使用的标签。即，如果我将提交标记为v1.0.0，则会为该标记运行新构建，并将新的 Docker 映像发布到带有标记的 Docker Hub v1.0.0。
我的问题是我将 Kubernetes 配置 ( deployment.yml) 存储在被标记的同一个存储库中。这意味着，我标记提交（即v2.0.0），其中包含的图像foo/bar:v1.0.0中deployment.yml。即，我对我的代码进行更改，然后决定一旦这些更改足够了，将标记特定的提交。由于我希望我的开发机器上的集群使用最新的、批准的（即标记的）代码，然后我更新deployment.yml并提交，但新提交是在标记提交之后。
为了解决这个问题，我必须更改deployment.yml我知道将被标记的提交的文件。即，知道我所做的下一次提交将被标记为v2.0.0，我将不得不更改deployment.yml以使用图像foo/bar:v2.0.0并将该更改添加到提交（即要标记的那个）。在这种情况下，标记为 as 的提交v2.0.0将foo/bar:v2.0.0在其deployment.yml.
是否有可以解决此问题的技术或最佳实践（例如模板或其他实践）？
谢谢你。
Helm模板也是一个不错的选择，但是如果您的项目是基本的并且不会有太多要求，则使用这种基本方法以 repo 简单的方式保持deployment.yaml。
理想情况下，您可以使部署文件尽可能保持动态，而不是固定加载项的值。
apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: test-image
labels:
app: test-image
spec:
selector:
matchLabels:
app: test-image
tier: frontend
strategy:
type: RollingUpdate
template:
metadata:
labels:
app: test-image
tier: frontend
spec:
containers:
- image: TEST_IMAGE_NAME
name: test-image
ports:
- containerPort: 8080
name: http
- containerPort: 443
name: https
在YAML CI配置中，我们根据需要更改deployment.yaml 文件中的IMAGE URL。
Google could buildCI 文件示例，但是您可以在YAML CI 中编写或更新逻辑
steps:
- id: 'set test core image in yamls'
name: 'ubuntu'
args: ['bash','-c','sed -i "s,TEST_IMAGE_NAME,gcr.io/$PROJECT_ID/$REPO_NAME/$BRANCH_NAME:$SHORT_SHA," deployment.yaml']
在您的流程中，YAML文件和运行时将字符串替换为您要添加的URL。
Git会给你必要的变量，比如COMMIT HASH或TAGGED VERSION。
Example CI file YAML file,
steps:
- id: 'build test core image'
name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/$PROJECT_ID/$REPO_NAME/$BRANCH_NAME:$SHORT_SHA', '.']
- id: 'push test image'
name: 'gcr.io/cloud-builders/docker'
args: ['push', 'gcr.io/$PROJECT_ID/$REPO_NAME/$BRANCH_NAME:$SHORT_SHA']
- id: 'set test core image in yamls'
name: 'ubuntu'
args: ['bash','-c','sed -i "s,TEST_IMAGE_NAME,gcr.io/$PROJECT_ID/$REPO_NAME/$BRANCH_NAME:$SHORT_SHA," deployment.yaml']
- name: 'gcr.io/cloud-builders/kubectl'
args: ['apply', '-f', 'deployment.yaml']
在您的内部deployment.yaml将有一个字符串TEST_IMAGE_NAME，它将在CI操作过程中被替换
使用简单的 ubuntu 命令sed：sed -i "s,TEST_IMAGE_NAME,gcr.io/$PROJECT_ID/$REPO_NAME/$BRANCH_NAME:$SHORT_SHA," deployment.yaml
变量，如$SHORT_SHA将得到自动注射或添加Github上那么现在您的CI服务器你有一个deployment.yaml与Image-URL那些已经推到码头工人枢纽。
我们在 CI 期间动态替换了我们的TEST_IMAGE_NAME字符串deployment.yaml。
现在你可以deployment.yaml从 CI 服务器应用它，它会更新或推送部署到K8s集群运行的任何地方。
注意：
如果您还想将配置存储在 repo 中，您可以从 CI 服务器 repo 提交回文件，您必须存储3部署文件 dev- deploymentl.yaml，stag-deployment.yaml如果任何分支中有任何更改，您可以再次将该文件从 CI 服务器提交到 repo 和您的YAML 配置也将保存在repo 中。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句