Cloud Run에 Cloud Storage FUSE 사용 튜토리얼

이 튜토리얼에서는 Cloud Storage를 네트워크 파일 시스템으로 Cloud Run 서비스에 마운트하는 방법을 설명합니다. Cloud Run 작업에도 동일한 접근 방법을 사용할 수 있습니다.

이 튜토리얼에서는 오픈소스 FUSE 어댑터를 사용하여 여러 컨테이너와 서비스 간에 데이터를 공유합니다.

파일 시스템을 마운트하려면 서비스가 Cloud Run 2세대 실행 환경을 사용해야 합니다. Cloud Run 작업은 2세대 환경을 자동으로 사용합니다.

2세대 실행 환경을 통해 네트워크 파일 시스템을 컨테이너의 디렉터리에 마운트할 수 있습니다. 파일 시스템을 마운트하면 호스트 시스템과 인스턴스 간에 리소스를 공유하고 인스턴스가 가비지로 수집된 후에도 리소스를 유지할 수 있습니다.

Cloud Run에서 네트워크 파일 시스템을 사용하려면 컨테이너가 파일 시스템 마운트 및 애플리케이션 프로세스를 비롯한 여러 프로세스를 실행해야 하므로 고급 Docker 지식이 필요합니다. 이 튜토리얼에서는 작업 예시와 함께 필요한 개념을 설명합니다. 하지만 이 튜토리얼을 애플리케이션에 맞게 조정할 때는 변경사항이 미칠 수 있는 영향을 이해해야 합니다.

디자인 개요

파일 시스템 아키텍처

이 다이어그램은 gcsfuse FUSE 어댑터를 통해 Cloud Storage 버킷에 연결하는 Cloud Run 서비스를 보여줍니다. Cloud Run 서비스와 Cloud Storage 버킷은 네트워킹 비용을 없애고 성능을 최적화하기 위해 같은 리전에 있습니다.

제한사항

이 튜토리얼에서는 파일 시스템을 선택하는 방법을 설명하지 않으며 프로덕션 준비를 다루지 않습니다. POSIX 파일 시스템과의 주요 차이점과 Cloud Storage FUSE의 기타 시맨틱스를 검토하세요.
이 튜토리얼에서는 파일 시스템으로 작업하거나 파일 액세스 패턴을 논의하는 방법을 보여주지 않습니다.

목표

파일 공유 역할을 할 Cloud Storage 버킷을 만듭니다.
시스템 패키지 및 init-process를 사용하여 마운트 및 애플리케이션 프로세스를 관리하는 Dockerfile을 빌드합니다.
Cloud Run에 배포하고 서비스의 파일 시스템에 대한 액세스 권한을 확인합니다.

비용

이 튜토리얼에서는 다음과 같은 비용이 청구될 수 있는 Google Cloud 구성요소를 사용합니다.

시작하기 전에

Google Cloud 계정에 로그인합니다. Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

프로젝트 선택기로 이동

Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

프로젝트 선택기로 이동

Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

API Cloud Run, Cloud Storage, Artifact Registry, and Cloud Build 사용 설정
API 사용 설정

gcloud CLI를 설치하고 초기화합니다.

필요한 역할

최소 역할 집합으로 튜토리얼을 완료하는 데 필요한 권한을 얻으려면 관리자에게 프로젝트에 대한 다음 IAM 역할을 부여해 달라고 요청합니다.

Artifact Registry 관리자(roles/artifactregistry.admin)
Cloud Build 편집자(roles/cloudbuild.builds.editor)
Cloud Run 관리자(roles/run.admin)
서비스 계정 사용자(roles/iam.serviceAccountUser)
서비스 사용량 소비자(roles/serviceusage.serviceUsageConsumer)
스토리지 관리자(roles/storage.admin)

역할 부여에 대한 자세한 내용은 액세스 관리를 참조하세요.

커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.

gcloud 기본값 설정

Cloud Run 서비스의 기본값으로 gcloud를 구성하려면 다음 안내를 따르세요.

기본 프로젝트를 설정합니다.
```
gcloud config set project PROJECT_ID
```
PROJECT_ID를 이 튜토리얼용으로 만든 프로젝트 이름으로 바꿉니다.
선택한 리전에 맞게 gcloud를 구성합니다.
```
gcloud config set run/region REGION
```
REGION을 지원되는 Cloud Run 리전 중 원하는 리전으로 바꿉니다.

Cloud Run 위치

Cloud Run은 리전을 기반으로 합니다. 즉, Cloud Run 서비스를 실행하는 인프라가 특정 리전에 위치해 있으며 해당 리전 내의 모든 영역에서 중복으로 사용할 수 있도록 Google이 관리합니다.

Cloud Run 서비스를 실행하는 리전을 선택하는 데 있어 중요한 기준은 지연 시간, 가용성 또는 내구성 요구사항입니다. 일반적으로 사용자와 가장 가까운 리전을 선택할 수 있지만 Cloud Run 서비스에서 사용하는 다른 Google Cloud 제품 위치도 고려해야 합니다. 여러 위치에서 Google Cloud 제품을 함께 사용하면 서비스 지연 시간과 비용에 영향을 미칠 수 있습니다.

Cloud Run은 다음 리전에서 사용할 수 있습니다.

등급 1 가격 적용

asia-east1(타이완)
asia-northeast1(도쿄)
asia-northeast2(오사카)
europe-north1(핀란드) 낮은 CO₂
europe-southwest1(마드리드)
europe-west1(벨기에) 낮은 CO₂
europe-west4(네덜란드)
europe-west8(밀라노)
europe-west9(파리) 낮은 CO₂
me-west1(텔아비브)
us-central1(아이오와) 낮은 CO₂
us-east1(사우스캐롤라이나)
us-east4(북 버지니아)
us-east5(콜럼버스)
us-south1(댈러스)
us-west1(오리건) 낮은 CO₂

등급 2 가격 적용

asia-east2(홍콩)
asia-northeast3(대한민국 서울)
asia-southeast1(싱가포르)
asia-southeast2 (자카르타)
asia-south1(인도 뭄바이)
asia-south2(인도 델리)
australia-southeast1(시드니)
australia-southeast2(멜버른)
europe-central2(폴란드 바르샤바)
europe-west10(베를린)
europe-west12(토리노)
europe-west2(영국 런던) 낮은 CO₂
europe-west3(독일 프랑크푸르트) 낮은 CO₂
europe-west6(스위스 취리히) 낮은 CO₂
me-central1(도하)
me-central2(담맘)
northamerica-northeast1(몬트리올) 낮은 CO₂
northamerica-northeast2(토론토) 낮은 CO₂
southamerica-east1(브라질 상파울루) 낮은 CO₂
southamerica-west1(칠레 산티아고) 낮은 CO₂
us-west2(로스앤젤레스)
us-west3(솔트레이크시티)
us-west4(라스베이거스)

Cloud Run 서비스를 이미 만들었다면 Google Cloud 콘솔의 Cloud Run 대시보드에서 리전을 확인할 수 있습니다.

코드 샘플 검색

사용할 코드 샘플을 검색하려면 다음 안내를 따르세요.

샘플 앱 저장소를 로컬 머신에 클론합니다.
Node.js
```
git clone https://github.com/GoogleCloudPlatform/nodejs-docs-samples.git
```
또는 zip 파일로 샘플을 다운로드하고 압축을 풀 수 있습니다.
Python
```
git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
```
또는 zip 파일로 샘플을 다운로드하고 압축을 풀 수 있습니다.
Java
```
git clone https://github.com/GoogleCloudPlatform/java-docs-samples.git
```
또는 zip 파일로 샘플을 다운로드하고 압축을 풀 수 있습니다.

Cloud Run 샘플 코드가 포함된 디렉터리로 변경합니다.

Node.js

cd nodejs-docs-samples/run/filesystem/

Python

cd python-docs-samples/run/filesystem/

자바

cd java-docs-samples/run/filesystem/

코드 이해하기

일반적으로 컨테이너 내에서 단일 프로세스 또는 애플리케이션을 실행해야 합니다. 컨테이너당 단일 프로세스를 실행하면 다시 시작 관리, 프로세스가 실패할 경우 컨테이너 종료, 신호 전달 및 좀비 하위 프로세스 제거와 같은 PID 1 책임 관리와 같은 여러 프로세스의 수명 주기 관리에 대한 복잡성이 줄어듭니다. 하지만 Cloud Run에서 네트워크 파일 시스템을 사용하려면 다중 프로세스 컨테이너를 사용하여 파일 시스템 마운트 프로세스와 애플리케이션을 모두 실행해야 합니다. 이 튜토리얼에서는 프로세스 실패 시 컨테이너를 종료하고 PID 1 책임을 관리하는 방법을 보여줍니다. 마운트 명령어에는 재시도를 처리하는 기능이 내장되어 있습니다.

프로세스 관리자를 사용하여 컨테이너의 진입점으로 여러 프로세스를 실행하고 관리할 수 있습니다. 이 튜토리얼은 좀비 프로세스를 정리하고 신호 전달을 수행하는 init 대체인 tini를 사용합니다. 특히 이 init 프로세스는 종료 시 SIGTERM 신호가 애플리케이션에 전파되도록 합니다. SIGTERM 신호는 애플리케이션의 단계적 종료를 위해 포착될 수 있습니다. Cloud Run의 컨테이너 수명 주기에 대해 자세히 알아보세요.

Dockerfile로 환경 구성 정의

이 Cloud Run 서비스를 사용하려면 기본적으로 하나 이상의 추가 시스템 패키지가 필요합니다. RUN 명령어는 tini를 init-process로 설치하고 FUSE 어댑터인 gcsfuse를 설치합니다. 시스템 패키지 사용 튜토리얼에서 Cloud Run 서비스의 시스템 패키지 작업에 대해 자세히 알아보세요.

다음 안내에서는 작업 디렉터리를 만들고, 소스 코드를 복사하고, 앱 종속 항목을 설치합니다.

ENTRYPOINT는 CMD 명령어 앞에 추가되는 init-process 바이너리를 지정합니다(이 경우에는 시작 스크립트). 그러면 단일 tini 프로세스가 실행된 다음 수신된 모든 신호를 해당 하위 프로세스의 루트가 되는 세션으로 프록시 처리합니다.

CMD 명령어는 시작 스크립트인 이미지를 실행할 때 실행할 명령어를 설정합니다. 또한 ENTRYPOINT의 기본 인수도 제공합니다. CMD 및 ENTRYPOINT의 상호작용 방법을 알아보세요.

Node.js

run/filesystem/gcsfuse.Dockerfile

GitHub에서 보기 의견 보내기


# Use the official Node.js image.
# https://hub.docker.com/_/node
FROM node:20-slim

# Install system dependencies
RUN apt-get update && apt-get install -y \
    curl \
    gnupg \
    lsb-release \
    tini && \
    gcsFuseRepo=gcsfuse-`lsb_release -c -s` && \
    echo "deb https://packages.cloud.google.com/apt $gcsFuseRepo main" | \
    tee /etc/apt/sources.list.d/gcsfuse.list && \
    curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | \
    apt-key add - && \
    apt-get update && \
    apt-get install -y gcsfuse && \
    apt-get clean

# Set fallback mount directory
ENV MNT_DIR /mnt/gcs

# Copy local code to the container image.
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY package*.json ./

# Install production dependencies.
RUN npm install --only=production

# Copy local code to the container image.
COPY . ./

# Ensure the script is executable
RUN chmod +x /app/gcsfuse_run.sh

# Use tini to manage zombie processes and signal forwarding
# https://github.com/krallin/tini
ENTRYPOINT ["/usr/bin/tini", "--"]

# Pass the wrapper script as arguments to tini
CMD ["/app/gcsfuse_run.sh"]

Python

run/filesystem/gcsfuse.Dockerfile

GitHub에서 보기 의견 보내기

# Use the official lightweight Python image.
# https://hub.docker.com/_/python
FROM python:3.11-buster

# Install system dependencies
RUN set -e; \
    apt-get update -y && apt-get install -y \
    tini \
    lsb-release; \
    gcsFuseRepo=gcsfuse-`lsb_release -c -s`; \
    echo "deb https://packages.cloud.google.com/apt $gcsFuseRepo main" | \
    tee /etc/apt/sources.list.d/gcsfuse.list; \
    curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | \
    apt-key add -; \
    apt-get update; \
    apt-get install -y gcsfuse \
    && apt-get clean

# Set fallback mount directory
ENV MNT_DIR /mnt/gcs

# Copy local code to the container image.
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY . ./

# Install production dependencies.
RUN pip install -r requirements.txt

# Ensure the script is executable
RUN chmod +x /app/gcsfuse_run.sh

# Use tini to manage zombie processes and signal forwarding
# https://github.com/krallin/tini
ENTRYPOINT ["/usr/bin/tini", "--"]

# Pass the startup script as arguments to Tini
CMD ["/app/gcsfuse_run.sh"]

자바

run/filesystem/gcsfuse.Dockerfile

GitHub에서 보기 의견 보내기

# Use the official maven/Java 11 image to create a build artifact.
# https://hub.docker.com/_/maven
FROM maven:3-eclipse-temurin-17-alpine as builder

# Copy local code to the container image.
WORKDIR /app
COPY pom.xml .
COPY src ./src

# Build a release artifact.
RUN mvn package -DskipTests

# Use Eclipse Temurin for base image.
# https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds
FROM eclipse-temurin:18-jdk-focal

# Install system dependencies
RUN set -e; \
    apt-get update -y && apt-get install -y \
    gnupg2 \
    tini \
    lsb-release; \
    gcsFuseRepo=gcsfuse-`lsb_release -c -s`; \
    echo "deb https://packages.cloud.google.com/apt $gcsFuseRepo main" | \
    tee /etc/apt/sources.list.d/gcsfuse.list; \
    curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | \
    apt-key add -; \
    apt-get update; \
    apt-get install -y gcsfuse && apt-get clean

# Set fallback mount directory
ENV MNT_DIR /mnt/gcs

# Copy the jar to the production image from the builder stage.
COPY --from=builder /app/target/filesystem-*.jar /filesystem.jar

# Copy the statup script
COPY gcsfuse_run.sh ./gcsfuse_run.sh
RUN chmod +x ./gcsfuse_run.sh

# Use tini to manage zombie processes and signal forwarding
# https://github.com/krallin/tini
ENTRYPOINT ["/usr/bin/tini", "--"]

# Run the web service on container startup.
CMD ["/gcsfuse_run.sh"]

시작 스크립트에서 프로세스 정의

시작 스크립트는 Cloud Storage 버킷에 액세스할 수 있는 마운트 지점 디렉터리를 만듭니다. 그런 다음 gcsfuse 명령어를 사용하여 Cloud Storage 버킷을 서비스의 마운트 지점에 연결한 후 애플리케이션 서버를 시작합니다. gcsfuse 명령어에는 재시도 기능이 내장되어 있습니다. 따라서 추가 bash 스크립팅은 필요하지 않습니다. 마지막으로 wait 명령어는 모든 백그라운드 프로세스의 종료를 수신 대기하고 스크립트를 종료합니다.

Node.js

run/filesystem/gcsfuse_run.sh

GitHub에서 보기 의견 보내기

#!/usr/bin/env bash
set -eo pipefail

# Create mount directory for service
mkdir -p $MNT_DIR

echo "Mounting GCS Fuse."
gcsfuse --debug_gcs --debug_fuse $BUCKET $MNT_DIR
echo "Mounting completed."

# Start the application
node index.js &

# Exit immediately when one of the background processes terminate.
wait -n

Python

run/filesystem/gcsfuse_run.sh

GitHub에서 보기 의견 보내기

#!/usr/bin/env bash
set -eo pipefail

# Create mount directory for service
mkdir -p $MNT_DIR

echo "Mounting GCS Fuse."
gcsfuse --debug_gcs --debug_fuse $BUCKET $MNT_DIR
echo "Mounting completed."

# Run the web service on container startup. Here we use the gunicorn
# webserver, with one worker process and 8 threads.
# For environments with multiple CPU cores, increase the number of workers
# to be equal to the cores available.
# Timeout is set to 0 to disable the timeouts of the workers to allow Cloud Run to handle instance scaling.
exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app

자바

run/filesystem/gcsfuse_run.sh

GitHub에서 보기 의견 보내기

#!/usr/bin/env bash
set -eo pipefail

# Create mount directory for service
mkdir -p $MNT_DIR

echo "Mounting GCS Fuse."
gcsfuse --debug_gcs --debug_fuse $BUCKET $MNT_DIR
echo "Mounting completed."

# Start the application
java -jar filesystem.jar

# Exit immediately when one of the background processes terminate.
wait -n

파일 작업

Node.js

파일 시스템과 상호작용하는 방법은 index.js를 참조하세요.

Python

파일 시스템과 상호작용하는 방법은 main.py를 참조하세요.

자바

파일 시스템과 상호작용하는 방법은 FilesystemApplication.java를 참조하세요.

서비스 제공

Cloud Storage 버킷을 만들거나 기존 버킷을 재사용합니다.
```
gsutil mb -l REGION gs://BUCKET_NAME
```
BUCKET_NAME을 Cloud Storage 버킷의 이름(my-fuse-bucket)으로 바꿉니다. Cloud Storage 버킷 이름은 전역에서 고유해야 하며 이름 지정 요구사항이 적용됩니다.

-l을 설정하여 버킷의 위치를 지정합니다. 예를 들면 us-central1입니다. 성능을 극대화하고 리전 간 네트워킹 요금을 방지하려면 Cloud Storage 버킷이 액세스해야 하는 Cloud Run 서비스와 동일한 리전에 있는지 확인합니다.
서비스 ID로 사용할 서비스 계정을 만듭니다.
```
gcloud iam service-accounts create fs-identity
```

서비스 계정에 Cloud Storage 버킷에 대한 액세스 권한을 부여합니다.

gcloud projects add-iam-policy-binding PROJECT_ID \
     --member "serviceAccount:fs-identity@PROJECT_ID.iam.gserviceaccount.com" \
     --role "roles/storage.objectAdmin"

소스에서 배포하려면 추가 Dockerfile을 삭제하고 튜토리얼 Dockerfile 이름을 바꿉니다.
```
rm Dockerfile
cp gcsfuse.Dockerfile Dockerfile
```
컨테이너 이미지를 빌드하여 Cloud Run에 배포합니다.
```
gcloud run deploy filesystem-app --source . \
    --execution-environment gen2 \
    --allow-unauthenticated \
    --service-account fs-identity \
    --update-env-vars BUCKET=BUCKET_NAME
```
이 명령어는 Cloud Run 서비스를 빌드 및 배포하고 2세대 실행 환경을 지정합니다. 소스에서 배포하면 Dockerfile을 기반으로 이미지가 빌드되고 이미지가 Artifact Registry 저장소(cloud-run-source-deploy)에 푸시됩니다.

소스 코드에서 배포에 대해 자세히 알아보기

디버깅

배포에 실패하면 Cloud Logging에서 자세한 내용을 확인합니다.

마운트 프로세스의 모든 로그를 사용하려면 시작 스크립트(gcsfuse_run.sh)에서 --foreground 플래그를 마운트 명령어와 함께 사용합니다.

  gcsfuse --foreground --debug_gcs --debug_fuse GCSFUSE_BUCKET MNT_DIRECTORY &

--debug_http를 추가하여 HTTP 요청/응답 디버그를 출력합니다.
--debug_fuse를 추가하여 FUSE 관련 디버깅 출력을 사용 설정합니다.
--debug_gcs를 추가하여 GCS 요청 및 타이밍 정보를 출력합니다.

자세한 내용은 문제 해결 가이드를 참조하세요.

사용해 보기

전체 서비스를 시도해봅니다.

브라우저에서 위의 배포 단계로 제공된 URL로 이동합니다.
Cloud Storage 버킷에 새로 생성된 파일이 표시됩니다.
파일을 클릭하여 콘텐츠를 확인합니다.

이러한 서비스를 계속 개발하려면 이들 서비스에 다른 Google Cloud 서비스에 대한 제한적인 Identity and Access Management(IAM) 액세스 권한이 있으며 다른 여러 서비스에 액세스하려면 추가 IAM 역할이 부여되어야 합니다.

비용 토론

Cloud Storage 가격은 데이터 스토리지, 스토리지 클래스에 저장된 데이터의 양, 버킷의 위치, 네트워크 사용량, 버킷에서 읽거나 버킷 간에 이전한 데이터 양에 따라 크게 달라집니다. Cloud Storage FUSE에서 발생하는 청구에 대해 자세히 알아보세요.

Cloud Run은 메모리, CPU, 요청 수, 네트워킹에 대해 가장 가까운 100ms로 반올림된 리소스 사용량에 따라 가격 책정됩니다. 따라서 비용은 서비스 설정, 요청 수, 실행 시간에 따라 달라집니다.

예를 들어 아이오와(us-central1)에서 호스팅되는 표준 스토리지 버킷에 저장된 데이터 1TiB의 비용은 월별 GiB당 $0.02, 즉 약 1,024GiB * $0.02 = $20.48입니다. 이 예상치는 이그레스 비용을 부정하기 위해 동일한 리전에서 호스팅되는 Cloud Run 서비스와 Cloud Storage 버킷에 따라 달라집니다.

개별 가격 책정 페이지를 방문하여 최신 가격을 확인하거나 Google Cloud 가격 계산기에서 예상 비용을 확인하고 검색해 보세요.

삭제

이 튜토리얼용으로 새 프로젝트를 만든 경우 이 프로젝트를 삭제합니다. 기존 프로젝트를 사용한 경우 이 튜토리얼에 추가된 변경사항은 제외하고 보존하려면 튜토리얼용으로 만든 리소스를 삭제합니다.

프로젝트 삭제

비용이 청구되지 않도록 하는 가장 쉬운 방법은 튜토리얼에서 만든 프로젝트를 삭제하는 것입니다.

프로젝트를 삭제하려면 다음 안내를 따르세요.

주의: 프로젝트를 삭제하면 다음과 같은 효과가 발생합니다.

프로젝트의 모든 항목이 삭제됩니다. 이 문서의 태스크에 기존 프로젝트를 사용한 경우 프로젝트를 삭제하면 프로젝트에서 수행한 다른 작업도 삭제됩니다.
커스텀 프로젝트 ID가 손실됩니다. 이 프로젝트를 만들 때 앞으로 사용할 커스텀 프로젝트 ID를 만들었을 수 있습니다. appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 보존하려면 전체 프로젝트를 삭제하는 대신 프로젝트 내에서 선택한 리소스만 삭제합니다.

여러 아키텍처, 튜토리얼, 빠른 시작을 살펴보려는 경우 프로젝트를 재사용하면 프로젝트 할당량 한도 초과를 방지할 수 있습니다.

Google Cloud 콘솔에서 리소스 관리 페이지로 이동합니다.
리소스 관리로 이동
프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.

튜토리얼 리소스 삭제

이 튜토리얼에서 배포한 Cloud Run 서비스를 삭제합니다.
```
gcloud run services delete SERVICE-NAME
```
여기서 SERVICE-NAME은 선택한 서비스 이름입니다.

Google Cloud 콘솔에서 Cloud Run 서비스를 삭제할 수도 있습니다.
튜토리얼 설정 중에 추가한 gcloud 기본 리전 구성을 삭제합니다.
```
 gcloud config unset run/region
```
프로젝트 구성을 삭제합니다.
```
 gcloud config unset project
```
이 튜토리얼에서 만든 다른 Google Cloud 리소스를 삭제합니다.
- Cloud Storage 버킷 삭제
- Artifact Registry에서 가져온 gcr.io/PROJECT_ID/filesystem-app이라는 서비스 컨테이너 이미지를 삭제합니다.
- 서비스 계정 fs-identity@PROJECT_ID.iam.gserviceaccount.com을 삭제합니다.

다음 단계

Cloud Storage FUSE 자세히 알아보기
다중 프로세스 컨테이너의 init 프로세스 선택에 대해 자세히 알아보기