我目前有一个 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.0
中的 foo/bar:v1.0.0
)源自我在 Git 中使用的标签。即,如果我将提交标记为 v1.0.0
,则会为该标记运行一个新构建,并将一个新的 Docker 映像发布到带有标记 v1.0.0
的 Docker Hub。
我的问题是我将 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
并将该更改添加到提交(即一个被标记)。在这种情况下,标记为 v2.0.0
的提交将在其 foo/bar:v2.0.0
中包含 deployment.yml
的图像。
是否有可以解决此问题的技术或最佳实践(例如模板或其他实践)?
谢谢。
答案 0 :(得分:4)
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 build
CI 文件示例,但是您可以在 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。
示例 CI 文件 YAML 文件,
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
和 {{1 }} 你已经推送到 docker hub。
我们在 CI 期间动态替换了 Image-URL
中的 TEST_IMAGE_NAME
字符串。
现在您可以从 CI 服务器应用此 deployment.yaml
,它会更新或推送部署到 K8s 集群,无论它在哪里运行。
注意:
如果你想将配置存储在 repo 中,你可以从 CI 服务器 repo 提交回文件,你必须存储 deployment.yaml
部署文件,dev-3
,deploymentl.yaml
if任何分支中的任何更改都可以从 CI 服务器将该文件再次提交到 repo,并且您的 YAML 配置也将保存在 repo 中。