如何部署使用google cloud build和Source Repository新推送的多个云功能？

Question

我有一个项目文件夹，其中包含不同的云功能文件夹，例如

Project_Folder
    -Cloud-Function-Folder1
         -main.py
         -requirements.txt
         -cloudbuild.yaml
    -Cloud-Function-Folder2
         -main.py
         -requirements.txt
         -cloudbuild.yaml
    -Cloud-Function-Folder3
         -main.py
         -requirements.txt
         -cloudbuild.yaml
            --------- and so on!

现在我现在拥有的是。我将代码从 Cloud Fucntions 文件夹一一推送到 Source Repository 到 Source Repository（每个函数文件夹单独的 Repos）。然后它启用了触发云构建然后部署功能的触发器。 我拥有的 cloudbuild.yaml 文件如下所示..

 steps:

 - name: 'python:3.7'
 entrypoint: 'bash'
 args: 
   - '-c'
   - |
       pip3 install -r requirements.txt
       pytest

 - name: 'gcr.io/cloud-builders/gcloud'
  args:
  - functions 
  - deploy
  - Function
  - --runtime=python37
  - --source=.
  - --entry-point=function_main
  - --trigger-topic=Function
  - --region=europe-west3  

现在，我想做的是创建一个单一的源代码库，每当我更改一个云函数中的代码并推送它时，只有它得到部署，其余部分仍然像以前一样。

---

更新

现在我也在下面尝试了类似的方法，但即使我正在处理单个功能，它也会同时部署所有功能。

Project_Folder
    -Cloud-Function-Folder1
         -main.py
         -requirements.txt
    -Cloud-Function-Folder2
         -main.py
         -requirements.txt
    -Cloud-Function-Folder3
         -main.py
         -requirements.txt
    -cloudbuild.yaml
    -requirements.txt

cloudbuild.yaml 文件如下所示

 steps:

 - name: 'python:3.7'
 entrypoint: 'bash'
 args: 
   - '-c'
   - |
       pip3 install -r requirements.txt
       pytest

 - name: 'gcr.io/cloud-builders/gcloud'
  args:
  - functions 
  - deploy
  - Function1
  - --runtime=python37
  - --source=./Cloud-Function-Folder1
  - --entry-point=function1_main
  - --trigger-topic=Function1
  - --region=europe-west3  

 - name: 'gcr.io/cloud-builders/gcloud'
  args:
  - functions 
  - deploy
  - Function2
  - --runtime=python37
  - --source=./Cloud-Function-Folder2
  - --entry-point=function2_main
  - --trigger-topic=Function2
  - --region=europe-west3 

Answer 1

这更复杂，您必须使用 Cloud Build 的限制和约束。

我这样做：

• 获取自上次提交后更新的目录
• 在这个目录上循环，做我想做的事

---

假设1：所有子文件夹都使用相同的命令部署

因此，为此我将cloudbuild.yaml 放在我的目录的根目录中，而不是在子文件夹中

steps:
- name: 'gcr.io/cloud-builders/git'
  entrypoint: /bin/bash
  args:
    - -c
    - |
        # Cloud Build doesn't recover the .git file. Thus checkout the repo for this
        git clone --branch $BRANCH_NAME https://github.com/guillaumeblaquiere/cloudbuildtest.git /tmp/repo ;
        # Copy only the .git file
        mv /tmp/repo/.git .
        # Make a diff between this version and the previous one and store the result into a file
        git diff --name-only --diff-filter=AMDR @~..@ | grep "/" | cut -d"/" -f1 | uniq > /workspace/diff

# Do what you want, by performing a loop in to the directory
- name: 'python:3.7'
  entrypoint: /bin/bash
  args:
    - -c
    - |
       for i in $$(cat /workspace/diff); do
       cd $$i
           # No strong isolation between each function, take care of conflicts!!
           pip3 install -r requirements.txt
           pytest
       cd ..
       done

- name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: /bin/bash
  args:
    - -c
    - |
       for i in $$(cat /workspace/diff); do
       cd $$i
           gcloud functions deploy .........           
       cd ..
       done

---

假设 2：部署特定于子文件夹

因此，为此，我将cloudbuild.yaml 放在我的目录的根目录中，并将另一个放在子文件夹中

steps:
- name: 'gcr.io/cloud-builders/git'
  entrypoint: /bin/bash
  args:
    - -c
    - |
        # Cloud Build doesn't recover the .git file. Thus checkout the repo for this
        git clone --branch $BRANCH_NAME https://github.com/guillaumeblaquiere/cloudbuildtest.git /tmp/repo ;
        # Copy only the .git file
        mv /tmp/repo/.git .
        # Make a diff between this version and the previous one and store the result into a file
        git diff --name-only --diff-filter=AMDR @~..@ | grep "/" | cut -d"/" -f1 | uniq > /workspace/diff

# Do what you want, by performing a loop in to the directory. Here launch a cloud build
- name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: /bin/bash
  args:
    - -c
    - |
       for i in $$(cat /workspace/diff); do
       cd $$i
           gcloud builds submit
       cd ..
       done

请注意此处的timeout，因为您可以触发大量 Cloud Build，并且需要花费一些时间。

---

想要手动运行您的构建，不要忘记添加 $BRANCH_NAME 作为替换变量

gcloud builds submit --substitutions=BRANCH_NAME=master

Answer 2

这很简单，但是您需要控制构建触发器方面的行为，而不是cloudbuild.yaml。从概念上讲，您希望限制云构建触发行为并将其限制为 repo 中的某些更改。

因此，在构建触发器页面中使用 regEx glob 包含过滤器：

您将为每个云函数构建一个触发器（或云运行）并按如下方式设置“包含的文件过滤器（glob）”：

• Cloud-Function1-Trigger

  Project_Folder/Cloud-Function-Folder1/**

• Cloud-Function2-Trigger

  Project_Folder/Cloud-Function-Folder2/**

...

假设：

1. 对于每个触发器，都设置了 repo 和分支，以便 repo 的根目录具有 Project_Folder/
2. Repo 和分支已适当设置为，以便触发器可以定位和访问路径 Project_Folder/Cloud-Function-Folder1/* 中的文件

当我拥有超过 2-3 个云功能时，我倾向于使用 Terraform 以自动化方式创建所有必需的触发器。

Answer 3

如果您创建单个源代码库并将代码更改为一个云函数，则必须创建一个 'cloudbuild.yaml' configuration file。您需要将此单一存储库连接到 Cloud Build。然后创建一个 build trigger 选择这个 repo 作为 Source。此外，您需要configure deployment，并且无论何时您将新代码推送到您的存储库，您都会自动触发在 Cloud Functions 上的构建和部署。