Odoo sur Google Cloud : comment bien l'héberger

La réponse courte

Pour héberger Odoo sur Google Cloud, faites-le tourner sur une VM Compute Engine avec un type de machine x86 standard, comme e2-standard-2. Mettez Postgres sur la même VM ou sur Cloud SQL avec une IP privée. N'ouvrez que les ports 80 et 443, et connectez-vous via IAP au lieu d'un SSH public. Envoyez les sauvegardes de la base et des fichiers vers un bucket Cloud Storage où la VM peut écrire, mais ni lire ni supprimer. Évitez les types shared-core pour la production, et testez une restauration avant la mise en ligne.

Beaucoup d'entreprises ont déjà un projet Google Cloud, alors Odoo y va aussi. Google Cloud a des régions sur chaque continent. Il offre aussi beaucoup de façons de mal régler Odoo, juste un peu. Ce guide vous donne les commandes exactes pour chaque étape Google Cloud.

Pour l'installation elle-même (Odoo, Postgres, le fichier de configuration et le proxy), suivez notre guide sur Odoo sur un VPS. Cette page couvre ce qui change sur Google Cloud.

Vous pouvez lancer toutes les commandes gcloud ci-dessous depuis votre propre ordinateur avec la Google Cloud CLI, ou depuis Cloud Shell dans la console. Remplacez les noms en majuscules par les vôtres. La plupart des commandes demandent une zone ou une région. Réglez-les une fois pour ne plus avoir à les donner :

gcloud config set project PROJECT_ID
gcloud config set compute/region europe-west1
gcloud config set compute/zone europe-west1-b

Quel type de machine choisir

Le minimum pour démarrer : 2 vCPU, 4 Go de mémoire et 50 Go de disque. Cela fait tourner Odoo et Postgres sur une seule VM pour une petite équipe. La mémoire compte plus que le CPU : chaque worker a besoin de sa part, et Postgres veut la sienne. Pour plus d'utilisateurs, de gros imports ou Cloud SQL, notre guide sur le nombre de workers Odoo dont vous avez besoin montre comment bien dimensionner.

Pourquoi pas un type shared-core

Les types e2-micro, e2-small et e2-medium sont « shared-core ». Ils montrent 2 vCPU au système, mais vous n'en avez en continu qu'une partie :

• e2-micro : un quart de vCPU
• e2-small : la moitié d'un vCPU
• e2-medium : un vCPU

Ils peuvent utiliser les 2 vCPU complets par courtes pointes, de 30 secondes à 2 minutes, et seulement de temps en temps. Odoo travaille toute la journée, tant que les gens l'utilisent. Quand la pointe se termine, Odoo ralentit donc.

Les types shared-core conviennent pour une copie de test que peu de gens utilisent.

Des types standard pour la production

Choisissez un type standard avec des vCPU complets. Quelques exemples, tous avec 2 vCPU et 8 Go de mémoire :

• e2-standard-2. Un bon choix par défaut pour une petite équipe.
• n2-standard-2. Une puce plus récente et plus rapide.
• n4-standard-2. Le plus récent des trois. Il n'accepte que Hyperdisk (voir la note sur le disque plus bas).

Si Postgres tourne sur la même VM et que la base est grosse, un type « highmem » donne plus de mémoire par vCPU. Par exemple, n4-highmem-2 a 2 vCPU et 16 Go.

Uniquement x86, si vous pensez confier le travail plus tard

Google Cloud vend aussi des types de machine Arm : Tau T2A, et les types Axion comme C4A et N4A. Notre logiciel bring your own server tourne uniquement sur des serveurs x86. Si vous pensez nous confier le travail Odoo plus tard, restez sur des types x86 comme ceux ci-dessus.

Image

Utilisez Ubuntu 22.04 LTS (famille d'images ubuntu-2204-lts, projet ubuntu-os-cloud) ou Debian 12 (famille d'images debian-12, projet debian-cloud). wkhtmltopdf, qu'Odoo utilise pour imprimer les PDF, a des paquets officiels pour les deux : Ubuntu 22.04 (jammy) et Debian 12 (bookworm). Imprimez une facture avant la mise en ligne.

Disque

Gardez tout sur le disque de démarrage, ou sur un autre persistent disk. N'utilisez pas Local SSD pour les données : c'est un disque temporaire.

Le type de disque dépend du type de machine :

• E2 et N2 : utilisez pd-balanced.
• N4 : utilisez hyperdisk-balanced. N4 n'accepte pas du tout Persistent Disk.

Gardez de la place pour le filestore et trois jours de sauvegardes locales. Vous pouvez agrandir un disque plus tard, mais jamais le réduire.

Région

Choisissez la région avec soin. Vos données vivent dans la région choisie. Mettez la VM et Cloud SQL dans la même région. Le bucket de sauvegarde va exprès dans une deuxième région, comme le montre la suite.

Où mettre Postgres

Vous avez deux bonnes options :

• Sur la même VM. Simple, et très bien pour beaucoup d'équipes. Suivez le guide VPS tel quel.
• Sur Cloud SQL for PostgreSQL. Google gère le serveur de base de données, les correctifs et la restauration à un instant donné. Les étapes sont ci-dessous.

Donner une adresse privée à Cloud SQL

Cloud SQL ne doit avoir qu'une IP privée, dans votre réseau VPC. Pour cela, le réseau a besoin du « private services access ». Ce guide utilise le réseau default. Lancez ceci une fois :

gcloud services enable servicenetworking.googleapis.com sqladmin.googleapis.com compute.googleapis.com

gcloud compute addresses create google-managed-services-default \
  --global \
  --purpose=VPC_PEERING \
  --prefix-length=16 \
  --network=default

gcloud services vpc-peerings connect \
  --service=servicenetworking.googleapis.com \
  --ranges=google-managed-services-default \
  --network=default

La première commande active les API. La deuxième réserve un bloc d'adresses privées pour les services de Google. La troisième relie ce bloc à votre réseau. Il vous faut le rôle Compute Network Admin pour cela.

Créer la base

gcloud sql instances create odoo-db \
  --database-version=POSTGRES_16 \
  --edition=enterprise \
  --cpu=2 --memory=8GB \
  --region=europe-west1 \
  --network=default \
  --no-assign-ip \
  --storage-type=SSD \
  --storage-size=50 \
  --backup-start-time=01:00 \
  --retained-backups-count=14 \
  --enable-point-in-time-recovery \
  --retained-transaction-log-days=7 \
  --ssl-mode=ENCRYPTED_ONLY \
  --deletion-protection

Ce que font ces options :

• --edition=enterprise choisit l'édition Enterprise. À partir de Postgres 16, Cloud SQL choisit Enterprise Plus, sauf si vous dites autre chose. Enterprise Plus utilise d'autres types de machine et n'accepte ni --cpu ni --memory.
• --network=default --no-assign-ip donne à la base une IP privée et aucune IP publique.
• --backup-start-time=01:00 fait une sauvegarde chaque nuit à 01:00 UTC.
• --retained-backups-count=14 en garde 14. La valeur par défaut pour Enterprise est 7.
• --enable-point-in-time-recovery vous permet de restaurer à n'importe quelle seconde des 7 derniers jours. 7 jours, c'est le maximum qu'Enterprise garde.
• --ssl-mode=ENCRYPTED_ONLY refuse les connexions sans SSL. La valeur par défaut accepte les deux.
• --deletion-protection empêche quiconque de supprimer la base par erreur.
• Ajoutez --availability-type=regional si vous voulez une copie de secours dans une deuxième zone.

Le stockage grandit tout seul quand il se remplit. Il ne rétrécit jamais.

Trouvez l'adresse privée de la base :

gcloud sql instances describe odoo-db --format="value(ipAddresses[0].ipAddress)"

Nous l'appelons CLOUD_SQL_IP dans la suite.

Créer l'utilisateur de base de données odoo

Odoo a besoin de son propre utilisateur, qui peut créer des bases. N'utilisez pas l'utilisateur admin postgres au quotidien.

Cloud SQL crée l'utilisateur postgres sans mot de passe. Donnez-lui-en un :

gcloud sql users set-password postgres --instance=odoo-db --prompt-for-password

Sur la VM Odoo, connectez-vous avec psql et créez l'utilisateur :

psql "host=CLOUD_SQL_IP user=postgres dbname=postgres sslmode=require"

CREATE ROLE odoo WITH LOGIN CREATEDB PASSWORD 'a-long-random-password';

L'utilisateur postgres n'est pas un vrai superuser Postgres, mais il peut créer des rôles comme celui-ci. Nous créons odoo en SQL, pas avec gcloud sql users create. Un utilisateur créé avec gcloud rejoint le groupe cloudsqlsuperuser et peut aussi créer des rôles, ce dont Odoo n'a pas besoin.

Vérifiez que odoo peut se connecter à la base postgres. Odoo s'y connecte pour le chat et pour les tâches planifiées :

psql "host=CLOUD_SQL_IP user=odoo dbname=postgres sslmode=require" -c "SELECT current_user;"

Laisser Odoo créer sa base

Créez yourdb en étant connecté en tant que odoo, pour que odoo en soit le propriétaire. Utilisez une fois le gestionnaire de bases d'Odoo, avant de mettre list_db = False, ou lancez ceci en tant qu'utilisateur odoo :

odoo -c /etc/odoo/odoo.conf -d yourdb -i base --stop-after-init

Vérifiez le propriétaire :

psql "host=CLOUD_SQL_IP user=odoo dbname=postgres sslmode=require" -c "\l yourdb"

Si vous préférez la créer en tant que postgres, Postgres 16 demande d'abord que postgres soit membre de odoo :

GRANT odoo TO postgres;
CREATE DATABASE yourdb OWNER odoo ENCODING 'UTF8' LC_COLLATE 'C' TEMPLATE template0;

Relier Odoo à Cloud SQL

Dans odoo.conf :

db_host = CLOUD_SQL_IP
db_port = 5432
db_user = odoo
db_password = a-long-random-password
db_sslmode = require
db_maxconn = 16

db_sslmode = require fait qu'Odoo utilise toujours SSL, ce que la base exige maintenant.

Surveiller la limite de connexions

Chaque processus Odoo garde son propre pool, avec au plus db_maxconn connexions. La valeur par défaut est 64. Comptez un pool par worker, un par worker cron (max_cron_threads, 2 par défaut) et un pour le processus du chat. Avec 4 workers, cela fait 7 pools. Cloud SQL fixe sa propre limite selon la taille de la machine. Vérifiez-la :

psql "host=CLOUD_SQL_IP user=odoo dbname=postgres sslmode=require" -c "SHOW max_connections;"

Le nombre de pools multiplié par db_maxconn doit rester sous ce chiffre. Avec 7 pools et db_maxconn = 16, Odoo peut ouvrir 112 connexions au plus.

Prendre la bonne version du client Postgres

pg_dump refuse de sauvegarder un serveur d'une version majeure plus récente que la sienne. Si Cloud SQL tourne en Postgres 16, la VM Odoo a besoin du client en version 16. Installez-le depuis le dépôt apt de PostgreSQL :

sudo apt install -y postgresql-common
sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh
sudo apt install -y postgresql-client-16

Vérifiez que les deux correspondent :

pg_dump --version
psql "host=CLOUD_SQL_IP user=odoo dbname=postgres sslmode=require" -c "SHOW server_version;"

Les sauvegardes Cloud SQL ne couvrent pas le filestore

Cloud SQL sauvegarde la base de données et peut la restaurer à n'importe quelle seconde de la période de récupération. Il ne sauvegarde pas le filestore. Les pièces jointes et les images vivent sur le disque de la VM, dans /var/lib/odoo/filestore. Il vous faut quand même la sauvegarde Cloud Storage ci-dessous, pour que la base et les fichiers soient sauvegardés ensemble.

Réseau, service account et VM

Un service account pour la VM

La VM a besoin d'une identité dans Google Cloud. Elle lui permet d'envoyer les logs et les mesures du disque et, plus tard, d'écrire les sauvegardes. Chaque nouvelle VM reçoit le « Compute Engine default service account », sauf si vous en choisissez un autre. Ce compte peut avoir le rôle Editor sur tout votre projet. Créez-en un à part, avec seulement ce dont Odoo a besoin :

gcloud iam service-accounts create odoo-server --display-name="Odoo server"
SA=odoo-server@PROJECT_ID.iam.gserviceaccount.com

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:$SA" --role=roles/logging.logWriter
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:$SA" --role=roles/monitoring.metricWriter

Une VM a deux niveaux d'accès : les « scopes » sur la VM et les rôles IAM sur le compte. Les deux doivent autoriser un appel. Google conseille de mettre le scope complet cloud-platform et de contrôler l'accès uniquement avec les rôles IAM. C'est ce que fait la VM ci-dessous.

Règles de pare-feu

La VM reçoit un tag réseau, odoo. Les règles de pare-feu visent ce tag, pas une adresse IP.

Ouvrez les ports web à tout le monde :

gcloud compute firewall-rules create odoo-allow-web \
  --network=default --direction=INGRESS --action=allow \
  --rules=tcp:80,tcp:443 --source-ranges=0.0.0.0/0 \
  --target-tags=odoo

Autorisez SSH uniquement depuis IAP, le tunnel de connexion de Google. IAP se connecte toujours depuis 35.235.240.0/20 :

gcloud compute firewall-rules create odoo-allow-iap-ssh \
  --network=default --direction=INGRESS --action=allow \
  --rules=tcp:22 --source-ranges=35.235.240.0/20 \
  --target-tags=odoo

Le réseau default est livré avec des règles qui ouvrent les ports 22 et 3389 à tout internet, pour chaque VM du réseau. Listez-les :

gcloud compute firewall-rules list --filter="network=default"

Si rien d'autre dans le projet n'en a besoin, supprimez-les :

gcloud compute firewall-rules delete default-allow-ssh default-allow-rdp

Les ports d'Odoo (8069 et 8072) restent fermés. Aucune règle ne les ouvre, donc Google Cloud les bloque. Seul nginx, sur la VM, leur parle.

Une adresse fixe

Réservez une IP externe statique, pour que l'adresse ne change pas quand la VM s'arrête et redémarre :

gcloud compute addresses create odoo-ip --region=europe-west1
gcloud compute addresses describe odoo-ip --region=europe-west1 --format="value(address)"

Faites pointer l'enregistrement DNS de votre domaine vers cette adresse avant de demander un certificat à Let's Encrypt.

Créer la VM

gcloud compute instances create odoo-prod \
  --zone=europe-west1-b \
  --machine-type=e2-standard-2 \
  --image-family=ubuntu-2204-lts --image-project=ubuntu-os-cloud \
  --boot-disk-size=50GB --boot-disk-type=pd-balanced \
  --service-account="$SA" --scopes=cloud-platform \
  --tags=odoo \
  --address=odoo-ip \
  --metadata=enable-oslogin=TRUE

Pour un type N4, utilisez --boot-disk-type=hyperdisk-balanced. Pour Debian, utilisez --image-family=debian-12 --image-project=debian-cloud.

enable-oslogin=TRUE active OS Login. Vous vous connectez avec votre compte Google et ses rôles IAM, pas avec des clés SSH stockées sur la VM.

Se connecter via IAP, pas en SSH public

Donnez-vous les rôles pour vous connecter. Les propriétaires du projet les ont déjà :

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=user:[email protected] --role=roles/iap.tunnelResourceAccessor
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=user:[email protected] --role=roles/compute.osAdminLogin
gcloud iam service-accounts add-iam-policy-binding "$SA" \
  --member=user:[email protected] --role=roles/iam.serviceAccountUser

• iap.tunnelResourceAccessor vous permet d'utiliser le tunnel IAP.
• compute.osAdminLogin vous permet de vous connecter avec sudo. Utilisez roles/compute.osLogin pour les personnes qui n'ont pas besoin de sudo.
• iam.serviceAccountUser est nécessaire, car la VM tourne avec le compte odoo-server.

Puis connectez-vous :

gcloud compute ssh odoo-prod --zone=europe-west1-b --tunnel-through-iap

La VM a une IP publique, vous devez donc ajouter --tunnel-through-iap. Sans cette option, gcloud essaie l'adresse publique, et le port 22 y est fermé.

Vérifier ce qui est ouvert

Depuis votre propre ordinateur, pas depuis Cloud Shell, vérifiez que les ports privés sont fermés. Les deux commandes doivent expirer :

nc -vz -w 5 STATIC_IP 22
curl -m 5 http://STATIC_IP:8069

Et que le site répond :

curl -I https://odoo.example.com/web/login

Sauvegardes vers Cloud Storage

Créer le bucket

Mettez le bucket dans une autre région que la VM. Si toute la région a un problème, vos sauvegardes restent à l'abri. Gardez-le dans une région où vos données ont le droit de vivre.

gcloud storage buckets create gs://your-odoo-backups \
  --location=europe-west4 \
  --uniform-bucket-level-access \
  --public-access-prevention \
  --soft-delete-duration=30d

Les noms de bucket sont partagés par tous les clients Google Cloud, alors ajoutez quelque chose d'unique au vôtre. Vous ne pouvez pas déplacer un bucket après l'avoir créé.

• --location=europe-west4 est une deuxième région. Vous pouvez aussi utiliser une bi-région, qui garde deux copies dans deux régions. Par exemple, EUR4 regroupe la Finlande et les Pays-Bas, et NAM4 l'Iowa et la Caroline du Sud.
• --uniform-bucket-level-access veut dire que seul IAM décide qui entre. Il n'y a pas de droits par fichier.
• --public-access-prevention bloque tout lien public vers le bucket.
• --soft-delete-duration=30d garde les fichiers supprimés 30 jours avant qu'ils partent pour de bon. Les nouveaux buckets les gardent 7 jours. Vous pouvez restaurer un fichier en soft delete depuis la console ou avec gcloud.

Google conseille le soft delete plutôt que le versioning des objets, ce guide utilise donc le soft delete. De toute façon, vos fichiers de sauvegarde ne sont jamais écrasés, comme le montrent les étapes suivantes.

Vérifiez les réglages :

gcloud storage buckets describe gs://your-odoo-backups

Supprimer les anciennes sauvegardes à date fixe

Enregistrez ceci sous lifecycle.json :

{
  "rule": [
    {
      "action": { "type": "Delete" },
      "condition": { "age": 30 }
    }
  ]
}

gcloud storage buckets update gs://your-odoo-backups --lifecycle-file=lifecycle.json
gcloud storage buckets describe gs://your-odoo-backups --format="default(lifecycle_config)"

Les sauvegardes de plus de 30 jours sont supprimées. Avec le soft delete, « supprimé » veut d'abord dire « caché ». La copie cachée reste encore 30 jours, puis part pour de bon. Une nouvelle règle peut mettre jusqu'à 24 heures à s'appliquer.

Laisser la VM écrire, et seulement écrire

Donnez au service account de la VM un seul rôle, sur ce bucket uniquement :

gcloud storage buckets add-iam-policy-binding gs://your-odoo-backups \
  --member="serviceAccount:$SA" --role=roles/storage.objectCreator

gcloud storage buckets get-iam-policy gs://your-odoo-backups

roles/storage.objectCreator peut créer des fichiers. Il ne peut ni les lister, ni les lire, ni les écraser, ni les supprimer. Si quelqu'un entre dans le serveur, il ne peut pas effacer vos sauvegardes.

Un piège. Pour les fichiers de plus de 150 Mio, gcloud découpe l'envoi en parties et les assemble à la fin. Assembler et nettoyer les parties demande des droits de lecture et de suppression, que ce rôle n'a pas. Désactivez donc cette option pour l'utilisateur odoo, sur la VM :

sudo -u odoo -H gcloud config set storage/parallel_composite_upload_enabled False
sudo -u odoo -H gcloud config get storage/parallel_composite_upload_enabled

Les gros fichiers s'envoient quand même, simplement en un seul flux.

Si vos règles internes demandent plus, une retention policy peut bloquer les suppressions pendant une durée fixée, même pour un admin. Par exemple, gcloud storage buckets update gs://your-odoo-backups --retention-period=30d. Si vous la verrouillez ensuite avec --lock-retention-period, vous ne pourrez jamais la retirer ni la raccourcir. Testez-la d'abord sur un bucket de test.

La CLI gcloud sur la VM

Votre image a peut-être déjà la Google Cloud CLI. Vérifiez sur la VM :

gcloud --version

Si elle manque, installez-la depuis le dépôt apt de Google :

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
sudo apt-get update && sudo apt-get install -y google-cloud-cli

Sur la VM, gcloud utilise seul le service account. Vous ne stockez jamais de clé sur le serveur.

Le script de sauvegarde

Créez d'abord le dossier local :

sudo mkdir -p /backups
sudo chown odoo:odoo /backups

Enregistrez ceci sous /usr/local/bin/odoo-backup.sh et lancez sudo chmod 755 dessus :

#!/bin/bash
# /usr/local/bin/odoo-backup.sh, run as the odoo user
set -euo pipefail
DB=yourdb
DAY=$(date +%F)
DIR=/backups/$DAY
mkdir -p "$DIR"
pg_dump -Fc "$DB" > "$DIR/$DB.dump"
tar -czf "$DIR/$DB-filestore.tar.gz" -C /var/lib/odoo/filestore "$DB"
gcloud storage cp "$DIR"/* "gs://your-odoo-backups/$DAY/"
find /backups -mindepth 1 -maxdepth 1 -type d -mtime +3 -exec rm -rf {} +

La VM ne peut pas écraser de fichiers dans le bucket. Si le script tourne deux fois le même jour, le deuxième envoi échoue donc. C'est voulu : une sauvegarde déjà dans le bucket ne peut pas être remplacée.

Avec Cloud SQL, pg_dump doit se connecter par le réseau. Remplacez la ligne pg_dump par :

pg_dump -h CLOUD_SQL_IP -U odoo -Fc "$DB" > "$DIR/$DB.dump"

Puis donnez à l'utilisateur odoo son mot de passe dans un fichier .pgpass, dans son dossier personnel :

sudo -u odoo -H bash -c 'echo "CLOUD_SQL_IP:5432:*:odoo:a-long-random-password" > ~/.pgpass && chmod 600 ~/.pgpass'

Le * permet à la même ligne de servir pour toutes les bases, y compris celle du test de restauration.

Le lancer chaque nuit

Créez /etc/systemd/system/odoo-backup.service :

[Unit]
Description=Odoo backup to Cloud Storage
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
User=odoo
ExecStart=/usr/local/bin/odoo-backup.sh

Et /etc/systemd/system/odoo-backup.timer :

[Unit]
Description=Run the Odoo backup every night

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

Activez-le, puis lancez-le une fois à la main et vérifiez le résultat :

sudo systemctl daemon-reload
sudo systemctl enable --now odoo-backup.timer
sudo systemctl start odoo-backup.service
journalctl -u odoo-backup.service -n 20

Depuis votre propre ordinateur, vérifiez que les fichiers sont arrivés :

gcloud storage ls --recursive gs://your-odoo-backups/

Tester une restauration

La VM de production ne peut pas lire le bucket. C'est voulu. Le test de restauration tourne donc sur une deuxième VM, avec son propre service account en lecture seule. Créez le compte et donnez-lui l'accès en lecture au bucket :

gcloud iam service-accounts create odoo-restore --display-name="Odoo restore test"
RSA=odoo-restore@PROJECT_ID.iam.gserviceaccount.com

gcloud storage buckets add-iam-policy-binding gs://your-odoo-backups \
  --member="serviceAccount:$RSA" --role=roles/storage.objectViewer

roles/storage.objectViewer peut lister et lire les fichiers. Il ne peut ni les écrire ni les supprimer.

Créez la VM de test avec ce compte, le même tag et sans IP statique :

gcloud compute instances create odoo-restore-test \
  --zone=europe-west1-b \
  --machine-type=e2-standard-2 \
  --image-family=ubuntu-2204-lts --image-project=ubuntu-os-cloud \
  --boot-disk-size=50GB --boot-disk-type=pd-balanced \
  --service-account="$RSA" --scopes=cloud-platform \
  --tags=odoo \
  --metadata=enable-oslogin=TRUE

Pour vous connecter, donnez-vous aussi roles/iam.serviceAccountUser sur $RSA, comme pour $SA. Installez-y Odoo avec le guide VPS.

Sur la VM de test, en tant qu'utilisateur odoo, récupérez la sauvegarde d'une nuit et restaurez-la :

mkdir -p /tmp/restore && cd /tmp/restore
gcloud storage cp "gs://your-odoo-backups/2026-10-25/*" .
createdb -O odoo yourdb_restored
pg_restore -d yourdb_restored --no-owner --role=odoo yourdb.dump
mkdir -p /var/lib/odoo/filestore/yourdb_restored
tar -xzf yourdb-filestore.tar.gz -C /var/lib/odoo/filestore/yourdb_restored --strip-components=1

Si la copie de test utilise Cloud SQL, ajoutez -h CLOUD_SQL_IP -U odoo à createdb et pg_restore.

Avant de démarrer Odoo sur la copie, neutralisez-la. Une copie de la production garde vos serveurs de messagerie et vos tâches planifiées, elle peut donc envoyer des e-mails à de vrais clients. En tant qu'utilisateur odoo, lancez :

odoo neutralize -c /etc/odoo/odoo.conf -d yourdb_restored

Utilisez odoo-bin au lieu de odoo si vous faites tourner Odoo depuis les sources. Cela désactive dans la copie les serveurs de messagerie sortants, les actions planifiées et les moyens de paiement. Notre guide sur la copie de la production vers le staging explique ce qu'elle couvre et ce qu'elle oublie.

Puis connectez-vous à yourdb_restored et ouvrez quelques pièces jointes. Notre guide sur comment savoir si une sauvegarde Odoo se restaurera explique le test complet.

Recevoir une alerte avant que le disque soit plein

Les logs, le filestore et les sauvegardes locales grossissent. Google Cloud ne voit pas le remplissage de votre disque, sauf si la VM lui envoie ce chiffre. L'Ops Agent s'en charge.

Installez-le sur la VM :

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install
sudo systemctl status google-cloud-ops-agent"*"

Le statut doit montrer les parties logs et mesures en marche. L'agent utilise les rôles logWriter et metricWriter que vous avez donnés au service account.

L'alerte disque

Créez un canal e-mail pour les alertes, et notez son nom :

gcloud beta monitoring channels create --display-name="Odoo alerts" \
  --type=email [email protected]
gcloud beta monitoring channels list --format="value(name,displayName)"

La mesure est agent.googleapis.com/disk/percent_used. Elle a une ligne par partition de disque, nommée par son label device. Trouvez donc d'abord le nom de la partition racine. Dans la console, allez dans Monitoring > Metrics explorer, choisissez VM Instance > Disk > Disk utilization, filtrez sur state = used et regroupez par device. Sur la VM, findmnt -n -o SOURCE / montre la même partition, par exemple /dev/sda1. Utilisez le nom exactement comme Metrics explorer l'affiche.

Trouvez l'ID de la VM :

gcloud compute instances describe odoo-prod --zone=europe-west1-b --format="value(id)"

Enregistrez ceci sous disk-alert.json, avec votre nom de device et l'ID de la VM :

{
  "displayName": "Odoo disk above 80%",
  "combiner": "OR",
  "conditions": [
    {
      "displayName": "Root disk used above 80%",
      "conditionThreshold": {
        "filter": "metric.type=\"agent.googleapis.com/disk/percent_used\" AND resource.type=\"gce_instance\" AND resource.labels.instance_id=\"INSTANCE_ID\" AND metric.labels.state=\"used\" AND metric.labels.device=\"DEVICE\"",
        "aggregations": [
          { "alignmentPeriod": "300s", "perSeriesAligner": "ALIGN_MEAN" }
        ],
        "comparison": "COMPARISON_GT",
        "thresholdValue": 80,
        "duration": "0s",
        "trigger": { "count": 1 }
      }
    }
  ]
}

gcloud monitoring policies create --policy-from-file=disk-alert.json \
  --notification-channels=CHANNEL_NAME

Filtrer sur un seul device écarte les petits disques en lecture seule qu'Ubuntu ajoute pour les paquets snap. Ceux-là sont toujours pleins à 100 %.

Un uptime check

Vérifiez aussi que le site lui-même répond. Dans la console, allez dans Monitoring > Uptime checks > Create Uptime Check et réglez :

• Protocol: HTTPS
• Resource Type: URL
• Hostname: votre domaine Odoo
• Path: /web/login

Laissez l'alerte activée et choisissez votre canal Odoo alerts. Vous recevez un e-mail quand au moins deux régions de contrôle n'arrivent pas à joindre la page pendant une minute.

E-mails sortants

Compute Engine bloque les connexions sortantes vers le port 25 des serveurs extérieurs. Les e-mails d'Odoo envoyés ainsi ne partent jamais. Les ports 587 et 465 sont ouverts. Envoyez donc par un service SMTP sur l'un des deux. Votre fournisseur de messagerie actuel convient. Si vous utilisez Google Workspace, son relais SMTP fonctionne uniquement sur 587 ou 465.

Dans Odoo, activez le mode développeur. Allez dans Settings > Technical > Outgoing Mail Servers. Mettez le serveur SMTP de votre fournisseur, le port 587 avec le chiffrement TLS (STARTTLS) ou le port 465 avec SSL/TLS, et l'utilisateur et le mot de passe SMTP.

Les pièges Odoo sur tout serveur, Google Cloud compris

Websocket. Depuis Odoo 16, le chat et les mises à jour en direct passent par le port 8072. nginx doit y envoyer /websocket, avec les en-têtes d'upgrade.

Proxy mode. Odoo ne fait confiance aux en-têtes transmis que si proxy_mode = True et que la requête contient X-Forwarded-Host. Sans les deux, vos liens sortent en http://.

Gestionnaire de bases. Mettez list_db = False et un admin_passwd solide.

Workers. Mettez workers au-dessus de 0, réglé selon la mémoire. Odoo démarre alors le worker du chat sur gevent_port.

Dans odoo.conf :

proxy_mode = True
list_db = False
admin_passwd = a-long-random-string
workers = 4
gevent_port = 8072

Dans nginx, à côté de votre bloc location / :

map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

location /websocket {
  proxy_pass http://127.0.0.1:8072;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
  proxy_set_header X-Forwarded-Host $http_host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header X-Real-IP $remote_addr;
}

Le bloc map va dans la section http, en dehors de server.

Derrière un load balancer Google Cloud

Vous n'avez pas besoin d'un load balancer pour une seule VM. Si vous utilisez quand même un external Application Load Balancer :

• Il gère les websockets sans réglage en plus. Gardez nginx derrière lui, pour que /websocket aille toujours vers 8072.
• Il garde l'en-tête Host d'origine et envoie X-Forwarded-Proto et X-Forwarded-For, mais pas X-Forwarded-Host. Sans lui, Odoo ignore les autres. nginx doit donc l'ajouter.
• Il termine le HTTPS, donc nginx voit du HTTP simple. Transmettez le protocole du load balancer, pas celui de nginx.
• Le timeout de son backend service est de 30 secondes par défaut. Si les longs rapports ou les connexions du chat coupent, augmentez-le.

Dans les deux blocs location de nginx, utilisez :

proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;

Puis modifiez odoo-allow-web pour que le port 80 soit ouvert seulement au load balancer, pas à tout internet. Le load balancer et ses health checks viennent de 35.191.0.0/16 et 130.211.0.0/22 :

gcloud compute firewall-rules update odoo-allow-web \
  --rules=tcp:80 --source-ranges=35.191.0.0/16,130.211.0.0/22

Avant la mise en ligne

• La VM est d'un type x86 standard (pas shared-core), avec un disque pd-balanced ou hyperdisk-balanced
• La VM tourne avec son propre service account, pas celui par défaut
• Odoo tourne avec workers au-dessus de 0, réglé selon la mémoire du serveur
• /websocket va vers le port 8072, et le chat fonctionne
• proxy_mode = True, et les liens dans les e-mails commencent par https://
• list_db = False et un admin_passwd solide
• Seuls les ports 80 et 443 sont ouverts à internet, default-allow-ssh a disparu, et vous vous connectez via IAP
• Avec Cloud SQL : IP privée uniquement, ENCRYPTED_ONLY, db_sslmode = require, et pg_dump correspond à la version du serveur
• Le certificat SSL se renouvelle tout seul
• Les PDF s'impriment (wkhtmltopdf fonctionne)
• Les e-mails de test arrivent, envoyés sur le port 587 ou 465
• Les logs tournent, l'Ops Agent tourne, et l'alerte disque et l'uptime check préviennent votre adresse e-mail
• Le timer de sauvegarde a tourné, et les fichiers sont dans le bucket, dans une autre région
• Une sauvegarde a été restaurée sur une autre VM, et les pièces jointes s'ouvrent

Gardez Google Cloud, confiez-nous le travail Odoo

Vous pouvez garder Odoo dans votre projet Google Cloud sans le gérer vous-même. Avec bring your own server, la VM reste dans votre projet et dans la région de votre choix. Nous faisons tourner Odoo dessus : déploiements depuis Git, staging, sauvegardes, mises à jour et l'aide d'experts Odoo. Vous gardez la VM en marche et assez grande. Notre logiciel se connecte depuis votre VM vers l'extérieur, vous n'ouvrez donc aucun port pour nous.

Skysize est conçu par d'anciens ingénieurs d'Odoo et certifié ISO 27001.

Parlez à un expert en hébergement Odoo

FAQ

Odoo peut-il tourner sur Google Cloud ? Oui. Utilisez une VM Compute Engine, Postgres sur la VM ou sur Cloud SQL, et des sauvegardes vers Cloud Storage.

Puis-je utiliser Cloud SQL pour Odoo ? Oui. Donnez-lui une IP privée, activez SSL, et créez pour Odoo un utilisateur de base de données qui peut créer des bases. Cloud SQL ne sauvegarde pas le filestore, sauvegardez-le aussi.

Quel type de machine est le meilleur pour Odoo ? Un type avec assez de mémoire pour vos workers et Postgres, et des vCPU complets, comme e2-standard-2 ou n4-standard-2. Évitez les types shared-core comme e2-medium en production.

Odoo peut-il tourner sur des types de machine Arm comme C4A ou T2A ? Ce guide ne les couvre pas. Notre logiciel bring your own server tourne uniquement sur x86, choisissez donc un type x86 si vous pensez nous confier le travail plus tard.

De quel rôle IAM la VM Odoo a-t-elle besoin pour les sauvegardes ? Seulement roles/storage.objectCreator sur votre bucket de sauvegarde. Les restaurations utilisent un service account à part, sur une autre VM, avec roles/storage.objectViewer.

Dois-je ouvrir le port 22 ? Pas à internet. Autorisez le port 22 uniquement depuis la plage d'IAP, 35.235.240.0/20, et connectez-vous avec gcloud compute ssh --tunnel-through-iap.

Pourquoi Odoo n'envoie-t-il pas d'e-mails depuis Compute Engine ? Google Cloud bloque le port 25 sortant vers les serveurs extérieurs. Envoyez par votre fournisseur de messagerie sur le port 587 ou 465.