我已经在 GitHub 上使用源代码设置了一个 Google Cloud Platform kubernetes 集群(和容器注册表)。源代码被分成多个文件夹,每个微服务都有单独的 Dockerfile。
我想使用 GitHub 操作设置 CI/CD。
据我所知,default GKE workflow 将使用机密连接到 gcloud,构建映像并将它们推送到 Container Registry。然后执行更新。
- name: Build
run: |-
docker build -t "gcr.io/$PROJECT_ID/$IMAGE_1:$GITHUB_SHA" service1/.
docker build -t "gcr.io/$PROJECT_ID/$IMAGE_2:$GITHUB_SHA" service2/.
docker build -t "gcr.io/$PROJECT_ID/$IMAGE_3:$GITHUB_SHA" service3/.
- name: Publish
run: |-
docker push "gcr.io/$PROJECT_ID/$IMAGE_1:$GITHUB_SHA"
docker push "gcr.io/$PROJECT_ID/$IMAGE_2:$GITHUB_SHA"
docker push "gcr.io/$PROJECT_ID/$IMAGE_3:$GITHUB_SHA"
这是来自 GKE 工作流的部署片段:
# Deploy the Docker image to the GKE cluster
- name: Deploy
run: |-
./kustomize edit set image gcr.io/PROJECT_ID/IMAGE:TAG=gcr.io/$PROJECT_ID/$IMAGE:$GITHUB_SHA
./kustomize build . | kubectl apply -f -
kubectl rollout status deployment/$DEPLOYMENT_NAME
kubectl get services -o wide
答案 0 :(得分:1)
部署是如何进行的?
要了解如何部署或运行此工作流,请参阅此 documentation
<块引用>kustomize 有什么用?
kustomize 是一个用于应用配置的 configuration mangement
<块引用>我是否必须在 gcloud 上配置 GKE 密钥/令牌以外的任何内容
除非您为验证工作流程添加额外的安全层,否则您不必这样做。
<块引用>假设我想更新多个 docker 镜像。构建多个镜像并推送它们就足够了吗?像下面一样(为了清楚起见简化了一点),或者我是否还必须修改 Deploy 作业
我认为不需要修改部署作业。构建多个镜像并推送到GCR中就足够了
答案 1 :(得分:0)
我只是想在发布此问题并实施 GitHub 操作后分享我使用 GKE 的经验。
<块引用>部署是如何进行的?
基本上,工作流通过 gcloud CLI(这也会设置 kubectl 上下文)建立与 GKE 的连接。
建立连接并定位到正确的集群后,您就可以随心所欲了。
我是否必须在 gcloud 上配置 GKE 密钥/令牌以外的任何内容
没有其他要求。请记住正确散列它并将其存储在 GitHub 上的秘密中。
<块引用>假设我想更新多个 docker 镜像...
按照问题的方式进行操作绝对有效且功能齐全。
<块引用>...或者我是否还必须修改部署作业
我决定稍微改变一下部署。
# Deploy update to services
- name: Deploy
run: |-
kubectl set image deployment dep1 dep1="gcr.io/$PROJECT_ID/$IMAGE_1:$GITHUB_SHA"
kubectl set image deployment dep2 dep2="gcr.io/$PROJECT_ID/$IMAGE_2:$GITHUB_SHA"
这样我就不必使用我不熟悉的Kustomize。
如果您将 update strategy 设置为 RollingUpdate - - 我认为这是默认设置 - - 图像标记的更改将触发滚动更新(其他策略也可能有效)。但是要使用这种方法,您必须在构建 Docker 镜像并使用上面的代码部署它们时使用相同的镜像标签。使用 $GITHUB_SHA 将为提交提供独特的哈希值,可用于区分 docker 镜像。
这可能不是最优雅的解决方案,但我相信您可以想出更好的解决方案(例如获取发布标签),因为这只是一个变量。