Google Cloudbuild yaml file 中 entrypoint 和 args 的写法

最新推荐文章于 2024-06-21 11:46:24 发布

nvd11

最新推荐文章于 2024-06-21 11:46:24 发布

阅读量984

点赞数 21

分类专栏： google cloud gcp yaml 文章标签： googlecloud yaml cloudbuild

本文链接：https://blog.csdn.net/nvd11/article/details/139364268

版权

gcp 同时被 3 个专栏收录

30 篇文章 0 订阅

订阅专栏

google cloud

28 篇文章 0 订阅

订阅专栏

yaml

3 篇文章 0 订阅

订阅专栏

编写cloudbuild.yaml 时有几个关键参数

entrypoint 和 args 的基本介绍

id: 显示在 cloud build logs 里的item 名字
name: docker 镜像名字 - 下面的命令会在这个镜像的1个容器instance 内执行
entrypoint: 执行的命令入口，只能有1个对象
args：命名的参数，它是1个list

问题来了，如何理解深而慢是entrypoint 和 args

entrypoint 就是执行的命令 bin file 名字， args 是参数，不能混淆

例如:

cat /tmp/1.txt /tmp/2.txt

中
cat 就entrypoint
/tmp/1.txt /tmp/2.txt 就是两个参数，因为args 是1个list

又如：

echo abc def

中， echo 是 entrypoint, args 是 [abc, def]

所以在clouldbuild.yaml 中下面command 1是正确的， command 2 是错误的

steps:

  # correct
  - id: test command 1
    name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: echo
    args: [abc, def]

  # wrong
  - id: test command 2
    name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: echo abc
    args: [ def ]


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-config#logging

因为第2中写法，它把 echo abc 作为endpoint, 虽然合并字符串也是 echo abc def, 跟 command 1 的写法一样，但是yaml 中命令的写法绝对不是字符串

而镜像中的 /usr/bin 中绝对不可能有1个 echo abc 包括空格的file, 所以会出错
日志

starting build "34e39f7f-e039-4572-a392-21a154ed8228"

FETCHSOURCE
Fetching storage object: gs://jason-hsbc_cloudbuild/source/1717185531.688094-1bcec1bbcfb64618b377c2a5e097c551.tgz#1717185513807965
Copying gs://jason-hsbc_cloudbuild/source/1717185531.688094-1bcec1bbcfb64618b377c2a5e097c551.tgz#1717185513807965...
/ [0 files][    0.0 B/ 73.9 KiB]                                                
-
- [1 files][ 73.9 KiB/ 73.9 KiB]                                                
Operation completed over 1 objects/73.9 KiB.                                     
tar: cloudbuild-test.yaml: time stamp 2024-05-31 19:58:47.9453259 is 4.465130295 s in the future
BUILD
Starting Step #0 - "test command 1"
Step #0 - "test command 1": Already have image (with digest): gcr.io/cloud-builders/gcloud
Step #0 - "test command 1": abc def
Finished Step #0 - "test command 1"
Starting Step #1 - "test command 2"
Step #1 - "test command 2": Already have image (with digest): gcr.io/cloud-builders/gcloud
Finished Step #1 - "test command 2"
ERROR
ERROR: build step 1 "gcr.io/cloud-builders/gcloud" failed: starting step container failed: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "echo abc": executable file not found in $PATH: unknown

使用 bash - c 命令

如果我们想执行 cat 命令则需要把entrypoint set 成 cat, 不是echo
而其实我们可以用bash entrypoint 统一起来

我们先看下 -c 作用

    -c        If  the -c option is present, then commands are read from the first non-option argument command_string.  
              If there are arguments after the command_string, the first argument is assigned to $0 and any remaining arguments are assigned to the positional parameters.  
              The assignment to $0 sets the name of the shell, which is used in warning and error messages.

不是那么好懂, 举个例子：

[gateman@manjaro-x13 mkinitcpio.d]$ bash -c 'echo $1 $0' abc def
def abc

bash -c 后面第1个参数就是要执行的命令，但是这个参数要用单引号(不是双引号）来包住，第2个参数开始，都是第1个参数(被执行命令）

注意，单引号不要写成双引号，否则，参数可能获取失败， $0 会被赋予 shell name

[gateman@manjaro-x13 mkinitcpio.d]$ bash -c "echo $1 $0" abc def
/bin/bash

总之， bash -c 只会执行1条命令，第2个参数开始都是第1个参数的子参数

如果想一次执行两条命令，下面是错误示范

[gateman@manjaro-x13 mkinitcpio.d]$ bash -c 'echo abc' 'echo def'
abc

因为它把 ‘echo def’ 作为 ‘echo abc’ 的参数，并没有被执行

正确写法：

[gateman@manjaro-x13 demo_cloud_user]$ bash -c 'echo abc; echo def'
abc
def

对于cloudbuild 来讲，我们也可以用bash -c 的写法来编写 entrypoint 和 args

steps:

  # correct
  - id: test command 1
    name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: echo
    args: [abc, def]

  # correct
  - id: test command 2
    name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: bash
    args: [ -c, echo abc def ]

  # incorrect nothing output
  - id: test command 3
    name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: bash
    args: [ -c, echo , abc def ]

  # correct
  - id: test command 4
    name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: bash
    args: [ -c, echo $0 , abc def ]

  # correct
  - id: test command 5
    name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: bash
    args: [ -c, echo $0 $1 , abc, def ]

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-config#logging

注意第3种写法是错误的， abc def 作为 ‘echo’ 的参数毫无效果
输出：

starting build "e234fd52-bfe2-4c5a-91c0-6980ef6db448"

FETCHSOURCE
Fetching storage object: gs://jason-hsbc_cloudbuild/source/1717245688.299578-00e798950592461f9661290baa21addd.tgz#1717245670180704
Copying gs://jason-hsbc_cloudbuild/source/1717245688.299578-00e798950592461f9661290baa21addd.tgz#1717245670180704...
/ [0 files][    0.0 B/ 73.9 KiB]                                                
-
- [1 files][ 73.9 KiB/ 73.9 KiB]                                                
Operation completed over 1 objects/73.9 KiB.                                     
tar: cloudbuild-test.yaml: time stamp 2024-06-01 12:41:24.1218889 is 4.953891927 s in the future
BUILD
Starting Step #0 - "test command 1"
Step #0 - "test command 1": Already have image (with digest): gcr.io/cloud-builders/gcloud
Step #0 - "test command 1": abc def
Finished Step #0 - "test command 1"
Starting Step #1 - "test command 2"
Step #1 - "test command 2": Already have image (with digest): gcr.io/cloud-builders/gcloud
Step #1 - "test command 2": abc def
Finished Step #1 - "test command 2"
Starting Step #2 - "test command 3"
Step #2 - "test command 3": Already have image (with digest): gcr.io/cloud-builders/gcloud
Step #2 - "test command 3": 
Finished Step #2 - "test command 3"
Starting Step #3 - "test command 4"
Step #3 - "test command 4": Already have image (with digest): gcr.io/cloud-builders/gcloud
Step #3 - "test command 4": abc def
Finished Step #3 - "test command 4"
Starting Step #4 - "test command 5"
Step #4 - "test command 5": Already have image (with digest): gcr.io/cloud-builders/gcloud
Step #4 - "test command 5": abc def
Finished Step #4 - "test command 5"
PUSH
DONE

对于args 使用另1种的数组写法

众所周知，在yaml 中，数组有两种表示方式

1是中括号模式
例如：

args: [abc, def]

args:
  - abc
  - def

上面那种写法是正确的
对于本文里例子， couldbuild.yaml 命令也可以写成

  # correct
  - id: test command 1
    name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: echo
    args: [abc, def]

  # correct
  - id: test command 2
    name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: bash
    args: [ -c, echo abc def ]

  # correct
  - id: test command 3
    name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: bash
    args:
      - -c
      - echo abc def

上面3种写法都是等价的

对于多条命令的另1种写法

例如我想连续执行两条命令
echo abc 和 head /etc/proc/cpuinfo

这时entrypoint 就不能是 echo 和 head, 只能是bash

写法1：

  - id: test command 1
    name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: bash
    args:
      - -c
      - echo abc; head /proc/cpuinfo

主要用分号隔开，如果真的想写成两行

则写法2, 用| 表示，则两行之间不需要写 ; 但是他们其实加起来还是args 的1个参数，并不是两个

  # correct
  - id: test command 2
    name: 'gcr.io/cloud-builders/gcloud'
    entrypoint: bash
    args:
      - -c
      - |
        echo abc
        head /proc/cpuinfo

输出是一样的

starting build "5733316f-83e9-4566-98fd-f33fca535eda"

FETCHSOURCE
Fetching storage object: gs://jason-hsbc_cloudbuild/source/1717249155.147565-a60f825e1e024b9eb1fc4529b01cf417.tgz#1717249137259618
Copying gs://jason-hsbc_cloudbuild/source/1717249155.147565-a60f825e1e024b9eb1fc4529b01cf417.tgz#1717249137259618...
/ [0 files][    0.0 B/ 73.9 KiB]                                                
-
- [1 files][ 73.9 KiB/ 73.9 KiB]                                                
Operation completed over 1 objects/73.9 KiB.                                     
tar: cloudbuild-test.yaml: time stamp 2024-06-01 13:39:13.706183 is 8.186919054 s in the future
BUILD
Starting Step #0 - "test command 1"
Step #0 - "test command 1": Already have image (with digest): gcr.io/cloud-builders/gcloud
Step #0 - "test command 1": abc
Step #0 - "test command 1": processor	: 0
Step #0 - "test command 1": vendor_id	: GenuineIntel
Step #0 - "test command 1": cpu family	: 6
Step #0 - "test command 1": model		: 79
Step #0 - "test command 1": model name	: Intel(R) Xeon(R) CPU @ 2.20GHz
Step #0 - "test command 1": stepping	: 0
Step #0 - "test command 1": microcode	: 0xffffffff
Step #0 - "test command 1": cpu MHz		: 2199.998
Step #0 - "test command 1": cache size	: 56320 KB
Step #0 - "test command 1": physical id	: 0
Finished Step #0 - "test command 1"
Starting Step #1 - "test command 2"
Step #1 - "test command 2": Already have image (with digest): gcr.io/cloud-builders/gcloud
Step #1 - "test command 2": abc
Step #1 - "test command 2": processor	: 0
Step #1 - "test command 2": vendor_id	: GenuineIntel
Step #1 - "test command 2": cpu family	: 6
Step #1 - "test command 2": model		: 79
Step #1 - "test command 2": model name	: Intel(R) Xeon(R) CPU @ 2.20GHz
Step #1 - "test command 2": stepping	: 0
Step #1 - "test command 2": microcode	: 0xffffffff
Step #1 - "test command 2": cpu MHz		: 2199.998
Step #1 - "test command 2": cache size	: 56320 KB
Step #1 - "test command 2": physical id	: 0
Finished Step #1 - "test command 2"
PUSH
DONE