最近我问了一个问题,为什么当我试图部署到我的cloudbuild.yaml中的Firebase主机时,我会得到错误的cloudbuild.yaml。然而,由于我发现这个问题被信息搞得太臃肿,所以我试图把它分解。
我创建了一个简单的映像来可视化当我调用gcloud builds submit --config=cloudbuild.yaml时所发生的事情。那么,为什么我不能从dist/browser访问目录dist/browser,即使它是在创建目录dist/browser的Dockerfile之后处理的呢?

发布于 2021-03-19 19:56:01
云构建最好概念化为以本地文件系统的形式应用于数据的一系列函数(步骤)(通常只是/workspace,因为这是添加到每个步骤的默认卷挂载,但您可以添加其他卷挂载)和因特网。
除非您显式地将数据发布回这两个源之一(步骤的一个卷挂载或Internet),否则每个函数(step)的输出都是独立的。
在本例中,docker build使用本地文件(在示例中未显示)并在图像中生成dist/browser,但该文件夹仅可在该图像中访问;没有向例如在后续步骤中可以使用的/workspace添加任何内容。
为了随后使用该目录:
将该步骤生成的(文件系统)映像挂载并从其中提取目录的一种方法(不建议;可能的话,permitted).
docker cp文件从它返回到云构建的(VM)文件系统(可能在/workspace).
建议书
与其对包含目录的映像进行docker build‘处理,不如将Dockerfile解构为一系列云构建步骤。这样,您想要的工件(如果写在步骤的某个卷挂载下),将在随后的步骤中可用:
steps:
- name: gcr.io/cloud-builders/npm
args:
- install
- name: gcr.io/cloud-builders/npm
args:
- run
- build:ssr # Presumably this is where dist/browser is generated?
- name: firebase
args:
- deploy # dist/browser注意每个云构建步骤都有一个implicit:
证明
下面是一个最小的云构建配置,它使用一个名为testdir的卷,该卷映射到Cloud的/testdir目录。
注意到示例使用
testdir来证明这一点。每个could步骤都会自动挂载/workspace,这可以被使用。
配置:
/testdir
freddie.txt
-- /testdir
/testdir中的一个文件freddie.txt,现在包含freddie.txtoptions:
# volumes:
# - name: testdir
# path: /testdir
steps:
- name: busybox
volumes:
- name: testdir
path: /testdir
args:
- ash
- -c
- "ls -1a /testdir"
- name: busybox
volumes:
- name: testdir
path: /testdir
args:
- ash
- -c
- 'echo "Hello Freddie" > /testdir/freddie.txt'
- name: busybox
volumes:
- name: testdir
path: /testdir
args:
- ash
- -c
- "ls -1a /testdir"注意到,取消
options下的注释volumes将消除在每一步中复制volumes的需要。
编辑后的输出如下:
gcloud builds submit \
--config=./cloudbuild.yaml \
--project=${PROJECT}
# Lists (empty) /testdir
Starting Step #0
Step #0: Pulling image: busybox
Step #0: .
Step #0: ..
# Creates /test/freddie.txt
Starting Step #1
Step #1: Already have image: busybox
Finished Step #1
# List /testdir containing freddie.txt
Starting Step #2
Step #2: .
Step #2: ..
Step #2: freddie.txt
Finished Step #2https://stackoverflow.com/questions/66714188
复制相似问题