Tutoriel : Utiliser Cloud Storage FUSE avec Cloud Run

Ce tutoriel explique comment installer Cloud Storage en tant que système de fichiers réseau sur un service Cloud Run. La même approche peut être utilisée pour un job Cloud Run.

Le tutoriel utilise l'adaptateur FUSE Open Source pour partager des données entre plusieurs conteneurs et services.

Pour installer un système de fichiers, votre service doit utiliser l'environnement d'exécution de deuxième génération de Cloud Run. Les jobs Cloud Run utilisent automatiquement l'environnement de deuxième génération.

L'environnement d'exécution de deuxième génération permet l'installation des systèmes de fichiers réseau dans un répertoire de conteneur. L'installation d'un système de fichiers permet de partager des ressources entre un système hôte et des instances, et de conserver les ressources après la récupération de mémoire de l'instance.

L'utilisation d'un système de fichiers réseau avec Cloud Run nécessite des connaissances Docker avancées, car votre conteneur doit exécuter plusieurs processus, tels que l'installation du système de fichiers et le processus d'application. Ce tutoriel présente les concepts nécessaires et un exemple fonctionnel. Toutefois, lorsque vous adapterez ce tutoriel à votre propre application, assurez-vous de bien comprendre les implications de toute modification que vous pourriez apporter.

Présentation de la conception

filesystem-architecture

Le schéma montre le service Cloud Run se connectant au bucket Cloud Storage via l'adaptateur gcsfuse FUSE. Le service Cloud Run et le bucket Cloud Storage sont situés dans la même région afin de supprimer le coût de mise en réseau et d'optimiser les performances.

Limites

  • Ce tutoriel ne décrit pas comment choisir un système de fichiers et ne couvre pas l'aptitude en production. Découvrez les différences majeures entre un système de fichiers POSIX et les autres sémantiques de Cloud Storage FUSE.

  • Ce tutoriel n'explique pas comment utiliser un système de fichiers et ne traite pas des modèles d'accès aux fichiers.

Objectifs

  • Créez un bucket Cloud Storage qui servira de partage de fichiers.

  • Créez un Dockerfile avec les packages système et les processus d'initialisation pour gérer les processus d'installation et d'application.

  • Déployez sur Cloud Run et vérifiez l'accès au système de fichiers dans le service.

Coûts

Ce tutoriel utilise des composants facturables de Google Cloud, dont :

Avant de commencer

  1. Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

  2. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

    Accéder au sélecteur de projet

  3. Vérifiez que la facturation est activée pour votre projet Google Cloud. Découvrez comment vérifier si la facturation est activée sur un projet.

  4. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

    Accéder au sélecteur de projet

  5. Vérifiez que la facturation est activée pour votre projet Google Cloud. Découvrez comment vérifier si la facturation est activée sur un projet.

  6. Activer les API Cloud Run, Cloud Storage, Artifact Registry, and Cloud Build .

    Activer les API

  7. Installez et initialisez gcloud CLI.

Rôles requis

Pour obtenir les autorisations nécessaires pour réaliser le tutoriel avec le nombre minimal de rôles requis, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Configurer les paramètres par défaut de gcloud

Pour configurer gcloud avec les valeurs par défaut pour votre service Cloud Run, procédez comme suit :

  1. Définissez le projet par défaut :

    gcloud config set project PROJECT_ID

    Remplacez PROJECT_ID par le nom du projet que vous avez créé pour ce tutoriel.

  2. Configurez gcloud pour la région choisie :

    gcloud config set run/region REGION

    Remplacez REGION par la région Cloud Run compatible de votre choix.

Emplacements Cloud Run

Cloud Run est régional, ce qui signifie que l'infrastructure qui exécute vos services Cloud Run est située dans une région spécifique et gérée par Google pour être disponible de manière redondante dans toutes les zones de cette région.

Lors de la sélection de la région dans laquelle exécuter vos services Cloud Run, vous devez tout d'abord considérer vos exigences en matière de latence, de disponibilité et de durabilité. Vous pouvez généralement sélectionner la région la plus proche de vos utilisateurs, mais vous devez tenir compte de l'emplacement des autres produits Google Cloud utilisés par votre service Cloud Run. L'utilisation conjointe de produits Google Cloud dans plusieurs emplacements peut avoir une incidence sur la latence et le coût de votre service.

Cloud Run est disponible dans les régions suivantes :

Soumis aux tarifs de niveau 1

Soumis aux tarifs de niveau 2

  • asia-east2 (Hong Kong)
  • asia-northeast3 (Séoul, Corée du Sud)
  • asia-southeast1 (Singapour)
  • asia-southeast2 (Jakarta)
  • asia-south1 (Mumbai, Inde)
  • asia-south2 (Delhi, Inde)
  • australia-southeast1 (Sydney)
  • australia-southeast2 (Melbourne)
  • europe-central2 (Varsovie, Pologne)
  • europe-west12 (Turin)
  • europe-west2 (Londres, Royaume-Uni)
  • europe-west3 (Francfort, Allemagne)
  • europe-west6 (Zurich, Suisse) Icône Feuille Faibles émissions de CO2
  • me-central1 (Doha)
  • northamerica-northeast1 (Montréal) icône feuille Faibles émissions de CO2
  • northamerica-northeast2 (Toronto) Icône Feuille Faibles émissions de CO2
  • southamerica-east1 (São Paulo, Brésil) Icône Feuille Faibles émissions de CO2
  • southamerica-west1 (Santiago, Chili)
  • us-west2 (Los Angeles)
  • us-west3 (Salt Lake City)
  • us-west4 (Las Vegas)

Si vous avez déjà créé un service Cloud Run, vous pouvez afficher la région dans le tableau de bord Cloud Run de la console Google Cloud.

Récupérer l'exemple de code

Pour récupérer l’exemple de code à utiliser, procédez comme suit :

  1. Clonez le dépôt de l'exemple d'application sur votre machine locale :

    Python 

    git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git

    Vous pouvez également télécharger l'exemple en tant que fichier ZIP et l'extraire.

    Java

    git clone https://github.com/GoogleCloudPlatform/java-docs-samples.git

    Vous pouvez également télécharger l'exemple en tant que fichier ZIP et l'extraire.

  2. Accédez au répertoire contenant l'exemple de code Cloud Run :

    Python 

    cd python-docs-samples/run/filesystem/

    Java 

    cd java-docs-samples/run/filesystem/

Comprendre le code

Normalement, vous devez exécuter un seul processus ou une seule application dans un conteneur. L'exécution d'un seul processus par conteneur réduit la complexité de gestion du cycle de vie de plusieurs processus : gestion des redémarrages, arrêt du conteneur en cas d'échec d'un processus, et responsabilités PID 1 telles que le transfert de signal et récupération d'enfant zombie. Toutefois, pour utiliser des systèmes de fichiers réseau dans Cloud Run, vous devez utiliser des conteneurs multiprocessus afin d'exécuter à la fois le processus d'installation du système de fichiers et l'application. Ce tutoriel explique comment arrêter le conteneur en cas d'échec du processus et gérer les responsabilités PID 1. La commande d'installation dispose d'une fonctionnalité intégrée de gestion des nouvelles tentatives.

Vous pouvez utiliser un gestionnaire de processus pour exécuter et gérer plusieurs processus en tant que point d'entrée du conteneur. Ce tutoriel utilise tini, un remplacement d'initialisation qui nettoie les processus zombie et effectue le transfert du signal. Plus précisément, ce processus d'initialisation permet au signal SIGTERM lors de l'arrêt de se propager à l'application. Le signal SIGTERM peut être détecté pour l'arrêt optimal de l'application. Apprenez-en plus sur le cycle de vie d'un conteneur sur Cloud Run.

Définir la configuration de votre environnement avec le fichier Dockerfile

Ce service Cloud Run nécessite un ou plusieurs packages système supplémentaires qui ne sont pas disponibles par défaut. L'instruction RUN installe tini en tant que processus d'initialisation et gcsfuse, l'adaptateur FUSE. Pour en savoir plus sur l'utilisation des packages système dans votre service Cloud Run, consultez le tutoriel Utiliser des packages système.

Les instructions suivantes permettent de créer un répertoire de travail, de copier le code source et d'installer les dépendances de l'application.

ENTRYPOINT spécifie le binaire du processus d'initialisation qui précède les instructions CMD, dans ce cas il s'agit du script de démarrage. Cette opération lance un processus d'initialisation unique, puis sert de proxy pour tous les signaux reçus vers une session racine de ce processus enfant.

L'instruction CMD définit la commande à exécuter lors de l'exécution de l'image, le script de démarrage. Elle fournit également des arguments par défaut pour ENTRYPOINT. Découvrez comment CMD et ENTRYPOINT interagissent.

Python

run/filesystem/gcsfuse.Dockerfile 
# 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 http://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"]

Java

run/filesystem/gcsfuse.Dockerfile 
# Use the official maven/Java 11 image to create a build artifact.
# https://hub.docker.com/_/maven
FROM maven:3.8.6-jdk-11 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 AdoptOpenJDK 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 http://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"]

Définir les processus dans le script de démarrage

Le script de démarrage crée le répertoire de point d'installation, où le bucket Cloud Storage sera accessible. Le script associe ensuite le bucket Cloud Storage au point d'installation du service à l'aide de la commande gcsfuse, puis démarre le serveur d'applications. La commande gcsfuse dispose d'une fonctionnalité de nouvelle tentative intégrée. Un script bash supplémentaire n'est donc pas nécessaire. Enfin, la commande wait permet d'écouter les processus en arrière-plan à fermer, puis quitte le script.

Python

run/filesystem/gcsfuse_run.sh 
#!/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 &

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

Java

run/filesystem/gcsfuse_run.sh 
#!/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

Utiliser des fichiers

Python

Consultez la section concernant main.py pour interagir avec le système de fichiers.

Java

Consultez la section concernant FilesystemApplication.java pour interagir avec le système de fichiers.

Transmettre le service

  1. Créez un bucket Cloud Storage ou réutilisez un bucket existant :

    gsutil mb -l REGION gs://BUCKET_NAME

    Remplacez BUCKET_NAME par le nom du bucket Cloud Storage, par exemple my-fuse-bucket. Les noms des buckets Cloud Storage doivent être uniques et sont soumis à des exigences de dénomination.

    Définissez la valeur -l pour spécifier l'emplacement de votre bucket. Exemple :us-central1 Pour optimiser les performances et éviter les frais de mise en réseau interrégional, assurez-vous que le bucket Cloud Storage se trouve dans la même région que les services Cloud Run devant y accéder.

  2. Créez un compte de service qui servira d'identité de service :

    gcloud iam service-accounts create fs-identity

  3. Accordez au compte de service l'accès au bucket Cloud Storage :

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

  4. Pour effectuer un déploiement à partir de la source, supprimez le Dockerfile supplémentaire et renommez le tutoriel Dockerfile :

    rm Dockerfile
cp gcsfuse.Dockerfile Dockerfile

  5. Créez et déployez l'image de conteneur dans Cloud Run :

    gcloud run deploy filesystem-app --source . \
    --execution-environment gen2 \
    --allow-unauthenticated \
    --service-account fs-identity \
    --update-env-vars BUCKET=BUCKET_NAME

    Cette commande crée et déploie le service Cloud Run et spécifie et l'environnement d'exécution de deuxième génération. Le déploiement à partir de la source crée l'image à partir du Dockerfile et la transfère dans le dépôt Artifact Registry : cloud-run-source-deploy.

    En savoir plus sur le déploiement à partir du code source.

Débogage

Si le déploiement échoue, consultez Cloud Logging pour plus d'informations.

Si vous souhaitez que tous les journaux du processus d'installation utilisent l'option --foreground conjointement avec la commande d'installation dans le script de démarrage, gcsfuse_run.sh, utilisez :

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

  • Ajoutez --debug_http pour la sortie de débogage de la requête/réponse HTTP.
  • Ajoutez --debug_fuse pour activer la sortie de débogage liée à fuse.
  • Ajoutez --debug_gcs pour imprimer les informations sur les requêtes et la chronologie GCS.

Découvrez d'autres conseils de dépannage.

Essayez-le !

Pour tester le service complet :

  1. Accédez dans votre navigateur à l'URL fournie par l'étape de déploiement ci-dessus.
  2. Un fichier nouvellement créé doit s'afficher dans votre bucket Cloud Storage.
  3. Cliquez sur le fichier pour en afficher le contenu.

Si vous décidez de poursuivre le développement de ces services, n'oubliez pas qu'ils ont un accès IAM restreint au reste de Google Cloud. Des rôles IAM supplémentaires devront donc leur être attribués afin de pouvoir accéder à de nombreux autres services.

Discussion sur les coûts

Les tarifs de Cloud Storage dépendent fortement du stockage de données, c'est-à-dire la quantité de données stockées par classe de stockage et emplacement de vos buckets, et de l'utilisation du réseau, c'est-à-dire la quantité de données lues dans vos buckets ou transférées entre ceux-ci. Apprenez-en plus sur les frais encourus avec Cloud Storage FUSE.

Cloud Run est facturé en fonction de l'utilisation des ressources, arrondie à la centaine de millisecondes la plus proche pour la mémoire, le processeur, le nombre de requêtes et la mise en réseau. Par conséquent, le coût varie en fonction des paramètres de votre service, du nombre de requêtes et du temps d'exécution.

Par exemple, 1 Tio de données stockées dans un bucket de stockage standard hébergé dans l'Iowa (us-central1) coûte 0,02 $ par mois par Gio, soit environ 1 024 Gio x 0,02 $ = 20,48 $. Cette estimation dépend du fait que le service Cloud Run et le bucket Cloud Storage sont hébergés dans la même région pour annuler les coûts de sortie.

Consultez les pages des tarifs individuels pour obtenir les prix les plus récents ou effectuez une estimation dans le simulateur de coût Google Cloud.

Effectuer un nettoyage

Si vous avez créé un projet pour ce tutoriel, supprimez-le. Si vous avez utilisé un projet existant et que vous souhaitez le conserver sans les modifications du présent tutoriel, supprimez les ressources créées pour ce tutoriel.

Supprimer le projet

Le moyen le plus simple d'empêcher la facturation est de supprimer le projet que vous avez créé pour ce tutoriel.

Pour supprimer le projet :

  1. Dans la console Google Cloud, accédez à la page Gérer les ressources.

    Accéder à la page Gérer les ressources

  2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Supprimer les ressources du tutoriel

  1. Supprimez le service Cloud Run que vous avez déployé dans ce tutoriel :

    gcloud run services delete SERVICE-NAME

    Où SERVICE-NAME est le nom de service que vous avez choisi.

    Vous pouvez également supprimer des services Cloud Run à partir de Google Cloud Console.

  2. Supprimez la configuration régionale gcloud par défaut que vous avez ajoutée lors de la configuration du tutoriel :

     gcloud config unset run/region

  3. Supprimez la configuration du projet :

     gcloud config unset project

  4. Supprimez les autres ressources Google Cloud créées dans ce tutoriel :

Étape suivante