Découvrez la nouvelle fonctionnalité de Cloud Run qui permet de monter un bucket Cloud Storage en tant que volume de conteneur.
Introduction
Pour héberger un site web statique sur un service serverless tel que Cloud Run, vous aurez probablement besoin de fichiers stockés dans un bucket. Une nouvelle fonctionnalité de Google Cloud Platform simplifie désormais cette opération comme jamais auparavant. Petit rappel pour ceux qui ne connaissent pas Cloud Run : il s'agit d'un service managé pour exécuter des workloads conteneurisés sur l'infrastructure scalable de Google. Dans cet article, nous prenons l'exemple d'un site statique, mais les cas d'usage de cette fonctionnalité sont infinis.
Problématique
Jusqu'à récemment, accéder au stockage objet depuis Cloud Run passait par des outils tiers ou des bibliothèques clientes cloud intégrées à votre application. Si ces approches faisaient le travail, elles alourdissaient souvent la livraison applicative en matière de scalabilité et de maintenance.
Avec l'arrivée récente du montage Cloud Storage dans Cloud Run, vous pouvez désormais monter des buckets Cloud Storage en tant que volumes au sein de vos conteneurs Cloud Run, sans recourir à des bibliothèques supplémentaires.
Maintenant que les améliorations et leurs bénéfices sont posés, passons à notre cas d'usage : héberger un site web statique avec Cloud Run et le montage de volumes Cloud Storage.
Solution
Commencez par créer un projet pour héberger l'application et le bucket de stockage. Depuis votre terminal préféré, définissez quelques variables d'environnement pratiques et configurez gcloud.
export GCP_PROJECT=my-cloud-run-static-site
export REGION=us-east4
gcloud projects create $GCP_PROJECT
gcloud config set project $GCP_PROJECT
Activez ensuite les API Cloud Run, Cloud Build et Artifact Registry afin de pouvoir utiliser ces services.
gcloud services enable run.googleapis.com \
cloudbuild.googleapis.com \
artifactregistry.googleapis.com
Récupérons à présent le code de notre site statique.
git clone https://github.com/waymanls/my-cloud-run-static-site.git
Si l'on examine le contenu du fichier index.html, on constate que les images sont placées sous le chemin /images. Nous y ferons appel plus loin dans le tutoriel. Pour l'instant, créons le bucket Cloud Storage qui hébergera nos ressources statiques, puis chargeons-y notre image JPEG.
gcloud storage buckets create gs://$GCP_PROJECT-bucket --location=$REGION
gcloud storage cp beach.jpeg gs://$GCP_PROJECT-bucket/beach.jpeg
Créons ensuite notre dépôt Artifact Registry.
gcloud artifacts repositories create $GCP_PROJECT-repo \
--repository-format=docker \
--location=$GCP_REGION
Le dépôt Artifact Registry étant en place, nous allons construire et publier l'image du conteneur via Cloud Build.
gcloud builds submit --tag $REGION-docker.pkg.dev/$GCP_PROJECT/$GCP_PROJECT-repo/$GCP_PROJECT-svc
Une fois l'image publiée dans le dépôt, nous pouvons l'utiliser pour créer une application Cloud Run de seconde génération.
gcloud run deploy $GCP_PROJECT-svc --image $REGION-docker.pkg.dev/$GCP_PROJECT/$GCP_PROJECT-repo/$GCP_PROJECT-svc \
--execution-environment=gen2 --allow-unauthenticated
Place au dernier composant de notre exemple : rattacher le bucket Cloud Storage en tant que volume de conteneur. L'opération s'effectue en mettant à jour notre service Cloud Run. Les valeurs de configuration sont ici fournies via les options de la commande gcloud, mais elles peuvent aussi être transmises dans un fichier YAML de service. Comme vous le verrez dans la commande ci-dessous, nous reprenons le chemin images défini précédemment dans notre fichier index.html comme chemin de base et nom de notre volume de conteneur.
gcloud run services update $GCP_PROJECT-svc \
--execution-environment=gen2 \
--add-volume=name=images,type=cloud-storage,bucket=$GCP_PROJECT-bucket \
--add-volume-mount=volume=images,mount-path=/usr/share/nginx/html/images
Au terme de ces étapes, vous obtenez une application Cloud Run qui monte un bucket Cloud Storage comme volume au sein du service Cloud Run et accède à un objet depuis ce volume.
Nettoyage
Une fois la démonstration terminée, il est recommandé de supprimer le projet avec la commande suivante.
gcloud projects delete $GCP_PROJECT
L'intérêt de cette méthode : connecter nativement vos workloads serverless Cloud Run aux ressources statiques d'un object store, sans plus dépendre des bibliothèques clientes cloud ni des services tiers.