Atelier

Lesson 11 — Multi-agents et mise en production

Déployer l'agent sur Cloud Run

5 min read

This content is not translated yet. Showing the original version.

Déployer l'agent sur Cloud Run

Où faire tourner un agent ?

OptionCe que vous gérezBon pour
Cloud Runun conteneur ; Google gère serveurs et mise à l'échelleAPI d'agent, webhooks (WhatsApp, chat), contrôle total
Vertex AI Agent Enginele code de l'agent ; sessions, mémoire et mise à l'échelle sont géréesaller vite sur un agent ADK, avec services managés
Gemini Enterpriserien côté infra : l'agent est proposé aux employés dans l'interfaceassistant interne, après déploiement sur l'une des options ci-dessus

Nous prenons Cloud Run : c'est le plus transparent, et le même conteneur peut recevoir les webhooks d'une messagerie, à la manière d'un agent de commande sur WhatsApp comme Watpilot.

flowchart LR
  CL["Client (app, webhook messagerie)"] -->|"HTTPS + jeton IAM"| CR["Cloud Run : serveur API ADK"]
  CR --> GM["Gemini sur Vertex AI"]
  CR --> SM["Secret Manager"]
  CR --> DB["Base de sessions (ex. Cloud SQL)"]
  CR --> TR["Cloud Trace et Cloud Logging"]

Le chemin le plus court : adk deploy cloud_run

ADK sait construire le conteneur et le déployer pour vous :

terminal
export PROJECT_ID="mon-projet"
export REGION="europe-west1"

gcloud services enable run.googleapis.com aiplatform.googleapis.com \
  cloudbuild.googleapis.com artifactregistry.googleapis.com --project "$PROJECT_ID"

adk deploy cloud_run \
  --project "$PROJECT_ID" \
  --region "$REGION" \
  --service_name assistant-commandes \
  --trace_to_cloud \
  ./assistant_commandes \
  -- --no-allow-unauthenticated

Les options après -- sont transmises telles quelles à gcloud run deploy : ici, on interdit les appels anonymes.

Appeler l'agent déployé

Le serveur API d'ADK expose notamment /apps/{app}/users/{user}/sessions/{session} pour créer une session et /run pour envoyer un message :

terminal
URL=$(gcloud run services describe assistant-commandes --region "$REGION" --format 'value(status.url)')
TOKEN=$(gcloud auth print-identity-token)

curl -s -X POST -H "Authorization: Bearer $TOKEN" \
  "$URL/apps/assistant_commandes/users/u1/sessions/s1"

curl -s -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  "$URL/run" -d '{
    "app_name": "assistant_commandes", "user_id": "u1", "session_id": "s1",
    "new_message": {"role": "user", "parts": [{"text": "Il vous reste du café ?"}]}
  }'

Votre agent est déployé avec le service de sessions en mémoire et Cloud Run démarre une deuxième instance sous la charge. Que constate un client ?

Avant d'ouvrir aux clients

PointPourquoiComment
Sessions persistantesconversations cohérentes entre instances et redémarrages--session_service_uri vers une base ou Vertex AI
Accès privépersonne n'appelle votre agent (ni ne consomme votre budget) sans autorisation--no-allow-unauthenticated + IAM, ou une passerelle
Compte de service dédiémoindre privilègeun compte avec seulement les rôles nécessaires (ex. utilisateur Vertex AI)
Plafondséviter l'emballement des coûtsmax_llm_calls, --max-instances, alertes budgétaires
Tracesdéboguer en production--trace_to_cloud, journaux structurés
Jeu de testsne pas casser ce qui marchaitadk eval ou vos propres cas, à relancer avant chaque déploiement

Quelles mesures réduisent le risque qu'un agent déployé coûte beaucoup plus que prévu ? (plusieurs réponses)

Exercice : préparer la mise en production

Écrivez la commande adk deploy cloud_run complète pour un déploiement de production : service privé, traces, au plus 3 instances, sessions stockées dans une base PostgreSQL dont l'URL est fournie par la variable SESSION_DB_URL, et Gemini via Vertex AI. Puis listez les deux vérifications à faire juste après.

Voir la solution
terminal
adk deploy cloud_run \
  --project "$PROJECT_ID" \
  --region "$REGION" \
  --service_name assistant-commandes \
  --trace_to_cloud \
  --session_service_uri "$SESSION_DB_URL" \
  ./assistant_commandes \
  -- --no-allow-unauthenticated --max-instances=3 \
     --service-account="agent-commandes@${PROJECT_ID}.iam.gserviceaccount.com"

Avec, dans assistant_commandes/.env (ou en variables du service) : GOOGLE_GENAI_USE_VERTEXAI=TRUE, GOOGLE_CLOUD_PROJECT et GOOGLE_CLOUD_LOCATION, sans clé d'API.

Vérifications juste après :

  1. Un appel sans jeton échoue (curl "$URL/list-apps" doit renvoyer 401 ou 403), et le même appel avec jeton réussit.
  2. Une conversation en deux messages garde le contexte, et sa trace apparaît dans Cloud Trace avec les appels d'outils.

Remarque : l'URL de la base contient un mot de passe. Pour un vrai projet, préférez une connexion sans mot de passe (authentification IAM) ou un secret monté ; la formation Terraform citée en tête de leçon montre comment câbler tout cela proprement.

Je sais faire

  • Choisir entre Cloud Run, Agent Engine et Gemini Enterprise pour un cas donné
  • Déployer un agent ADK avec adk deploy cloud_run en service privé
  • Appeler l'agent déployé avec un jeton d'identité
  • Vérifier sessions persistantes, plafonds et traces avant l'ouverture aux clients
Next