当前位置:   article > 正文

初探 Google 云原生的CICD - CloudBuild

初探 Google 云原生的CICD - CloudBuild

大纲

![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/bbbc89fac0ca442589ebbdfafed26d5f.png

Google Cloud Build 简介

Google Cloud Build(谷歌云构建)是谷歌云平台(Google Cloud Platform,GCP)提供的一项服务,可帮助开发人员以一致和自动化的方式构建、测试和部署应用程序或构件。它为构建和部署应用程序提供了一个完全托管、可扩展和灵活的环境。

使用Cloud Build,开发人员可以使用配置文件(如YAML或JSON)定义构建流水线,指定构建过程中要执行的步骤和操作。可以根据事件(如代码库提交或更改)自动触发这些流水线,也可以由开发人员手动触发。

Cloud Build支持各种构建工具和编程语言,允许开发人员使用他们喜欢的工具和框架。它与其他GCP服务(如Cloud Storage、Container Registry和Cloud Run)无缝集成,实现了平滑的部署和发布工作流程。

Cloud Build的主要功能包括并行构建以加快执行速度、可定制的构建步骤、缓存以提高构建性能以及与版本控制系统的集成,便于源代码管理。

总之,Cloud Build简化了构建和部署过程,促进了自动化和协作,并帮助开发人员在谷歌云平台上优化软件开发生命周期。




与Jenkins 对比的优缺点

可以认为Cloud build 就是jenkins 的简单替代品, 比起jenkins, cloud build 有如下的优缺点

优点1:
Cloud build是完全云原生和serverless 的, 而jenkins 需要额外部署, 单这一点,足以让部分人选择它。

优点2:
Cloud build的配置简单, 学习成本低
对比起Jenkins 那复杂的一堆配置。。。
Cloudbuild 的部署步骤用yaml 编写, 跟Ansible 类似, 而Jenkins 的groovy script 学习曲线相对更陡峭

缺点1:
只适用于部署GCP的服务, 对于on-prem service 的部署比较吃力

缺点2:
配置简单, 但是没有jenkins 部署那么灵活, groovy script 功能更加强大

缺点3:
由于cloud build 的每个step 都在一个单独的容器内完成, 导致一些文件共享的问题
例如 如果有两个步骤, 第1个步骤 , mvn test 下载了1堆依赖
下1个步骤 mvn package 还是要下载同样的依赖。。。

总之
Cloudbuild 适合POC 场景下的部署, 快速简单.
Jenkins 更适合复杂场景的部署, 例如如果你的部署pipeline 需要包含 代码漏洞扫描, approval 流程系统集成 等其他步骤, 还是Jenkins 更方便




clould build yaml - 定义部署的步骤

用1个简单的例子:
我有1个简单的springboot service
https://github.com/nvd11/demo_cloud_user

想部署到google 的cloud run平台中。
步骤无非就是

  1. 编译 并 执行Junit cases - command: mvn test
  2. 打包成jar package - command: mvn package
  3. 打包成 docker image - command: docker build
  4. push docker image 到 Google Artifact Repository (google 镜像仓库)- command : docker pull 《image-path》
  5. 把镜像deploy 到 google cloud run 平台 - command: gcloud run deploy 《service name》–image=《image-path》。。

而上面提到, 其实每1个步骤就是1个命令
其中 步骤1和2执行的是mvn 的命令, 所以步骤1和2我们需要引入 mvn 的docker 镜像
步骤3和4是docker 命令, 需要引入包含docker/kaniko 的docker 镜像
步骤5 是gcloud 命令, 则需要 google sdk的docker 镜像

所以我们需要在springboot service 的项目主目录下新建1个cloudbuild.yaml (如果需要docker部署, dockerfile也还是需要的)
cloudbuild.yaml

steps:
  - id: check maven and jdk version
    name: maven:3.9-sapmachine-21 # https://hub.docker.com/_/maven
    entrypoint: mvn
    args: ['--version']

  - id: run maven test
    name: maven:3.9-sapmachine-21 # https://hub.docker.com/_/maven
    entrypoint: mvn
    args: ['test']

  - id: run maven package
    name: maven:3.9-sapmachine-21 # https://hub.docker.com/_/maven
    entrypoint: mvn
    args: ['package', '-Dmaven.test.skip=true']

  # https://cloud.google.com/build/docs/configuring-builds/substitute-variable-values
  - id: build docker image
    name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'europe-west2-docker.pkg.dev/$PROJECT_ID/my-docker-repo/demo-cloud-user', '.']

  - id: upload docker image to GAR
    name: 'gcr.io/cloud-builders/docker'
    args: [ 'push', 'europe-west2-docker.pkg.dev/$PROJECT_ID/my-docker-repo/demo-cloud-user']

  # deploy to Cloud run
  - id: deploy image to cloud run
    name: 'gcr.io/cloud-builders/gcloud'
    args: ['run', 'deploy', 'demo-cloud-user',
           '--image=europe-west2-docker.pkg.dev/$PROJECT_ID/my-docker-repo/demo-cloud-user',
           '--port=8080',
           '--platform=managed',
           '--region=europe-west2',
           '--no-allow-unauthenticated',
           '--service-account=vm-common@jason-hsbc.iam.gserviceaccount.com',
           '--key=projects/$PROJECT_ID/locations/europe-west2/keyRings/mykeyring/cryptoKeys/mycmek']
# https://stackoverflow.com/questions/68779751/error-publishing-source-code-from-cloud-build-to-a-bucket-using-triggers
logsBucket: gs://jason-hsbc_cloudbuild/logs/
options: # https://cloud.google.com/cloud-build/docs/build-config#options
  logging: GCS_ONLY # or CLOUD_LOGGING_ONLY https://cloud.google.com/cloud-build/docs/build-co
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40

十分简单易懂:
其中Google 已经允许在Cloudbuild 使用built-in的默认参数, 例如$PROJECT_ID 代替真实的gcp project id

参考:
https://cloud.google.com/build/docs/configuring-builds/substitute-variable-values

值得注意的是options- logging 如果配置了CLOUD_LOGGING_ONLY则cloud build 日志会发送到google 日子平台

日志格式:
在这里插入图片描述

如果是选择GCS_ONLY 则需要配置logsBucket
日志格式:在这里插入图片描述
个人更喜欢更简介的第2种。



用Cloud build trigger 触发部署

当写好cloudbuild.yaml写好后, 有两种方法出发部署
第一种是使用cloud build trigger

所谓cloud build trigger 就是让你的代码仓库的更新事件(commit/pull request) 去触发一个部署

而目前代码仓库只支持github 和 bitbucket, 置于国内的gitee, coding之类或者gitlab 私有化部署的代码仓库不支持

新建1个trigger 的详细步骤

1.打开trigger 的google console 页面, 点击新建trigger button

在这里插入图片描述



填写trigger 参数

有几个关键参数
region: 建议和您的其他resource 的region保持一致,减少网络传输距离
Name: cloudbuild的名字, 必填
Repository: 就是你的代码仓库, 第一次使用,需要配置google cloud 到github Oauth2 授权
在这里插入图片描述
branch: 就是制定某个branch的时间, 可以用.*代替全部branch, 建议只写某几个release branch
Event:有3个选项, 这里不解释了
1.push to a new branch
2.push new tag
3.pull request

Cloud Build configuration file location:
默认是 /cloudbuild.yaml 当然可以改成其他的, 让1个项目可以多种部署参数。
Service account: 部署所以用的service account, 如果不填, 则用cloud build 本身的agent service account 去部署, 权限问题是个坑。

注意上面的步骤也可以用terraform管理



触发Trigger

有两种方式, 1就是真的去修改代码, 利用commit/pull request/tag 事件出发
2是在ui上按run
在这里插入图片描述



查看build 状态和历史

部署历史的dashboard 能在UI上查看
在这里插入图片描述
点进去某个item 就能看详细的日志
在这里插入图片描述

当然用命令行也是可以的, 但是不太方便, 主要是查看具体日志的部分, 暂时我只能基于bucket 里的日志来查看:

Service URL: https://demo-cloud-user-7hq3m4pdya-nw.a.run.app
[gateman@manjaro-x13 demo_cloud_user]$ gcloud builds list --region=europe-west2
ID                                    CREATE_TIME                DURATION  SOURCE  IMAGES  STATUS
499f567c-10c9-4ae3-9456-d29bbc02168a  2024-05-01T18:21:10+00:00  3M21S     -       -       SUCCESS
6eec19d7-d7dc-4b51-8c5a-57a00879f044  2024-05-01T18:00:28+00:00  3M16S     -       -       SUCCESS
678554d2-b56b-4c5b-a81a-61addde1bc46  2024-05-01T15:03:33+00:00  3M19S     -       -       SUCCESS
d9ef5b26-52c6-4278-b1b1-e42ec5d456ad  2024-04-23T15:31:07+00:00  2M46S     -       -       SUCCESS
85946729-b839-4d42-9fda-e610f4333ba2  2024-04-23T15:02:02+00:00  2M37S     -       -       FAILURE
d636308d-2c19-4c59-9943-6371b185a022  2024-04-22T19:16:26+00:00  2M35S     -       -       SUCCESS
114660c2-6c23-410e-8bf9-76877dcd3bb0  2024-04-22T19:02:52+00:00  17S       -       -       SUCCESS
8d21277c-51c5-4f59-8a00-6db5d1dbd837  2024-04-22T18:34:56+00:00  35S       -       -       FAILURE
b3221243-5ada-4ccb-958e-c06ce127e788  2024-04-22T18:28:51+00:00  -         -       -       FAILURE
e1fde2bf-b7a1-47aa-9629-b3561c2dcca0  2023-11-04T20:54:29+00:00  1M38S     -       -       SUCCESS
[gateman@manjaro-x13 demo_cloud_user]$ gsutil cat gs://jason-hsbc_cloudbuild/logs/log-499f567c-10c9-4ae3-9456-d29bbc02168a-step-5.txt
Already have image (with digest): gcr.io/cloud-builders/gcloud
Deploying container to Cloud Run service [demo-cloud-user] in project [jason-hsbc] region [europe-west2]
Deploying...
Setting IAM Policy.............done
Creating Revision..........................................................................................................................................................................................................done
Routing traffic.....done
Done.
Service [demo-cloud-user] revision [demo-cloud-user-00006-v9c] has been deployed and is serving 100 percent of traffic.
Service URL: https://demo-cloud-user-7hq3m4pdya-nw.a.run.app
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23




用google SDK 命令行去触发

这种方法无需配置trigger, 只需要在local 本地或者安装有google sdk 的环境下
进入代码项目的folder
执行

gcloud builds submit --config=path/to/custom-build-config.yaml
  • 1

config 参数可以不写, 默认的config 位置就是./cloudbuild.yaml

这种trigger 方式还有这些好处

  1. 无需关心git remote 的地址, 支持任何项目, 甚至没有交给git管理的项目
  2. 无需commit 代码就可以触发build, 随改随部署

例子:

[gateman@manjaro-x13 demo_cloud_user]$ gcloud builds submit
Creating temporary tarball archive of 24 file(s) totalling 108.2 KiB before compression.
Some files were not included in the source upload.

Check the gcloud log [/home/gateman/.config/gcloud/logs/2024.05.02/03.17.04.250214.log] to see which files and the contents of the
default gcloudignore file used (see `$ gcloud topic gcloudignore` to learn
more).

Uploading tarball of [.] to [gs://jason-hsbc_cloudbuild/source/1714591025.18917-5d48d906138b4c9d906c9ceb47c62898.tgz]
Created [https://cloudbuild.googleapis.com/v1/projects/jason-hsbc/locations/global/builds/8bf33682-33a3-452c-9653-5966a35e1611].
Logs are available at [ https://console.cloud.google.com/cloud-build/builds/8bf33682-33a3-452c-9653-5966a35e1611?project=912156613264 ].
ID                                    CREATE_TIME                DURATION  SOURCE                                                                                   IMAGES  STATUS
8bf33682-33a3-452c-9653-5966a35e1611  2024-05-01T19:16:48+00:00  2M57S     gs://jason-hsbc_cloudbuild/source/1714591025.18917-5d48d906138b4c9d906c9ceb47c62898.tgz  -       SUCCESS

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

至于具体日志,还是建议去console 上查看




cloud build 的一些坑

1. gcloud SDK 执行的cloud build 的region 是global (non-region)

这个是google 暂时的limitation
导致两个问题:
1. 在gcp console 上我们必须用global region 去filter google sdk出发的cloudbuild 历史和看日志, 这代表 用trigger 出发和google sdk出发的cloudbuild 历史不在同1页上
2. gcloud builds submit command 默认下会尝试在 us region(人类希望的大本营) 创建bucket, 如果你的gcp project 所在的organization policy限制了us region的权限, 则你会遇到这个错误:

ERROR: (gcloud.builds.submit) HTTPError 412: 'us' violates constraint 'constraints/gcp.resourceLocations'	
  • 1

原因: cloud build 无法在us region 创建staging folder
https://cloud.google.com/sdk/gcloud/reference/builds/submit#–gcs-source-staging-dir
解决方法1:

    ERROR: (gcloud.builds.submit) HTTPError 412: 'us' violates constraint 'constraints/gcp.resourceLocations'
  • 1

解决方法2:
创建bucket gs://_cloudbuild/ bucket

我采用了第二种




glcoud builds build 所以的service account 是cloud build 默认的agent account

即使你用admin account 执行 gcloud build 命令, 默认下它用的是 cloud build 的agent account
最好预先分配好权限, 否则部署cloud run/ GKE 时很可能会失败
当然用下面页面分配也是可以的
在这里插入图片描述

还有一种方法,
可以用 glcoud builds build --account=emailaddr 来强制使用某个service account来部署, 前提是这个service account 已经在当前环境用gcloud auth 登陆

声明:本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:【wpsshop博客】
推荐阅读
相关标签
  

闽ICP备14008679号