Comment configurer ci/cd pour déployer automatiquement une application node.js sur cloud run

Déployer automatiquement une application Node.js sur Cloud Run via une pipeline CI/CD est devenu pour moi l’un des meilleurs investissements temps/fiabilité. Après plusieurs projets où j’ai bricolé des scripts puis migré vers des pipelines plus robustes, j’ai une méthode claire et reproductible que je partage ici : pourquoi choisir Cloud Run, les prérequis, et surtout une configuration CI/CD simple (GitHub Actions) pour construire, tester et déployer automatiquement votre app.

Pourquoi Cloud Run pour une app Node.js ?

Cloud Run m’attire pour plusieurs raisons concrètes :

Il s’appuie sur des conteneurs : vous avez la même image en dev et en prod.
Il est serverless : pas de gestion d’instances, montée en charge automatique et facturation à la milliseconde.
Integration facile avec Google Container Registry (GCR) ou Artifact Registry, IAM, et autres services GCP.
Déploiement simple via gcloud ou directement via l’API Cloud Run.

Cela dit, Cloud Run nécessite que votre app tourne dans un conteneur. Si vous n’avez pas encore containerisé votre application Node.js, c’est la première étape.

Prérequis

Avant de commencer, voici ce que j’installe et configure :

Un projet Google Cloud Platform (GCP) avec la facturation activée.
L’API Cloud Run activée (Cloud Run API), ainsi que Cloud Build si vous comptez l’utiliser.
Un registre d’images : Artifact Registry (préféré) ou Docker Hub / GCR.
Un repo Git (ici j’utilise GitHub) où se situe mon code.
Des secrets de déploiement (clé de service GCP) stockés dans GitHub Secrets ou un autre secret manager.
Un Dockerfile fonctionnel à la racine du projet.

Exemple de Dockerfile minimal pour Node.js

Voici le Dockerfile que j’utilise souvent pour des applications Node 16+ :

Dockerfile

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
ENV PORT=8080
EXPOSE 8080
CMD ["node", "server.js"]

Cloud Run attend généralement que votre conteneur écoute le port défini par la variable d’environnement PORT, donc vérifiez votre code Node pour utiliser process.env.PORT.

Stratégie CI/CD : GitHub Actions + Artifact Registry + gcloud

Pour automatiser, j’aime la simplicité de GitHub Actions. Le flux que je mets en place :

On déclenche la pipeline sur push vers main (ou sur PR pour une build de test).
On exécute des tests unitaires / linters.
On construit l’image Docker et on la pousse vers Artifact Registry.
On déploie l’image sur Cloud Run via gcloud.

Voici les étapes clés et un exemple de fichier GitHub Actions (.github/workflows/deploy.yml).

Exemple de workflow GitHub Actions

Copiez-collez et adaptez, en remplaçant PROJECT_ID, REGION et les noms d’artefacts.

.github/workflows/deploy.yml

name: CI/CD Cloud Run

on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v4

    - name: Set up Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '18'

    - name: Install dependencies and run tests
      run: npm ci && npm test

    - name: Configure gcloud
      uses: google-github-actions/setup-gcloud@v1
      with:
        project_id: ${{ secrets.GCP_PROJECT }}
        service_account_key: ${{ secrets.GCP_SA_KEY }}
        export_default_credentials: true

    - name: Build and push image to Artifact Registry
      run: |
        IMAGE=LOCATION-docker.pkg.dev/${{ secrets.GCP_PROJECT }}/my-repo/my-app:${{ github.sha }}
        gcloud builds submit --tag $IMAGE

    - name: Deploy to Cloud Run
      run: |
        gcloud run deploy my-app \\
          --image $IMAGE \\
          --region ${{ secrets.GCP_REGION }} \\
          --platform managed \\
          --allow-unauthenticated

Points importants :

Je stocke GCP_PROJECT, GCP_REGION et la clé JSON du compte de service (GCP_SA_KEY) dans les GitHub Secrets.
La variable LOCATION pour Artifact Registry dépend de votre région (ex. europe-west1-docker.pkg.dev ou e.g. europe-west1-docker.pkg.dev selon la config).
J’utilise gcloud builds submit qui lance Cloud Build pour builder l’image et la pousser directement dans Artifact Registry (pratique, pas besoin de Docker local dans l’action).

Créer le compte de service et les permissions

Pour que GitHub Actions puisse déployer, il faut un compte de service GCP avec des droits :

roles/run.admin (déployer Cloud Run)
roles/iam.serviceAccountUser (utiliser des comptes de service si nécessaire)
roles/storage.admin ou roles/artifactregistry.writer (pousser des images)
roles/cloudbuild.builds.editor (si vous utilisez Cloud Build)

J’extrais la clé JSON de ce compte et la place dans GitHub Secrets sous GCP_SA_KEY. Attention à la rotation régulière des clés et privilégiez Workload Identity si vous souhaitez une sécurité encore meilleure.

Bonnes pratiques et astuces que j’applique

Builds reproductibles : utilisez un tag d’image lié au commit (par ex. ${{ github.sha }}) et gardez un tag latest uniquement si nécessaire.
Tests avant build : lancer les tests unitaires et le linting dans la pipeline évite de déployer des erreurs en prod.
Review Apps : pour chaque PR, vous pouvez construire et déployer sur un service Cloud Run éphémère (ou une révision dédiée) pour preview. J’ai mis en place des workflows qui ajoutent l’URL en commentaire GitHub.
Variables d’environnement et secrets : stockez les credentials sensibles dans Secret Manager et montez-les via variables d’environnement dans Cloud Run plutôt que de les baked dans l’image.
Rollback : conservez les tags d’images pour revenir facilement à une version stable si nécessaire.
Monitoring : activez Cloud Monitoring et Cloud Logging ; j’ajoute aussi des alertes sur les latences et erreurs 5xx.

Déploiements progressifs (canary) et révisions

Cloud Run supporte les révisions : chaque déploiement crée une nouvelle révision que vous pouvez router. Pour un déploiement canary, j’utilise des commandes gcloud pour répartir le trafic entre deux révisions (ex. 10% nouveauté / 90% stable). Cela se gère via --traffic à la commande gcloud run services update-traffic ou via l’UI.

Workflow alternatif : Google Cloud Build + Triggers

Si vous préférez ne pas utiliser GitHub Actions, GCP propose Cloud Build triggers qui déclenchent une build sur push/PR. L’avantage est d’avoir tout dans l’écosystème GCP (moins de stockage de secrets externes), et la configuration peut rester dans un cloudbuild.yaml. J’ai utilisé cette approche pour des projets internes où la sécurité et la visibilité centralisée étaient prioritaires.

Erreurs courantes et comment je les résous

Le conteneur ne démarre pas : vérifier les logs Cloud Run, s’assurer que le serveur écoute process.env.PORT et que la commande CMD est correcte.
Permission denied lors du push : vérifiez que le compte de service a bien les rôles Artifact Registry/Cloud Build.
Timeouts : ajustez la valeur request timeout de Cloud Run si vos endpoints ont des traitements longs ou externalisez ces jobs asynchrones.
Volumes / fichiers persistants : Cloud Run est éphémère — si vous avez besoin de stockage persistant, utilisez Cloud Storage ou une base de données gérée.

Si vous voulez, je peux adapter ce guide à votre repo : je peux examiner votre Dockerfile, proposer un workflow GitHub Actions spécifique, ou convertir la pipeline pour GitLab CI / CircleCI. Partagez un lien vers votre repo (privé ou public) et je vous fais une version sur-mesure.