C'est Cloud Run: Configuration pour Windows 7,8,10,11-Winpcsoft.com

Ceci est une partie 3 de la série « This is Cloud Run ». Dans Partie 1, nous avons expliqué ce qu'est Cloud Run et quand le choisir. Dans Partie 2, nous avons parcouru les options de déploiement et la gestion des révisions. Maintenant, réglons-le.

Les valeurs par défaut de Cloud Run sont bonnes. Nous avons couvert cela en partie 1. Mais chaque charge de travail a ses propres besoins, et Cloud Run vous donne les boutons pour les régler. Cet article couvre les paramètres que vous utiliserez le plus souvent.

Processeur et mémoire

Chaque instance Cloud Run obtient une part de processeur et de mémoire. Les valeurs par défaut (1 CPU virtuel, 512 Mio) sont raisonnables pour une API légère, mais vous souhaiterez les ajuster à mesure que vous comprendrez les besoins de votre charge de travail.

Processeur va de 0.08 CPU virtuel (moins d'un dixième de noyau) à 8 Processeurs virtuels. Mémoire va de 128 MiB à 32 Gio. Les deux sont liés: des allocations de processeur plus élevées nécessitent des seuils de mémoire minimaux, et certaines configurations de mémoire nécessitent un minimum de CPU.

Mais la décision la plus importante est la Mode d'allocation du processeur:

Sur demande uniquement (défaut). Le processeur n'est alloué que lorsque votre instance traite activement une requête. Entre les demandes, Le processeur est limité à près de zéro. Vous payez uniquement le temps passé à traiter les demandes. C'est le modèle sans serveur, et c'est le bon choix pour la plupart des API HTTP.
Toujours actif. Le processeur est toujours disponible, même entre les demandes. Cela coûte plus cher, mais cela est requis pour les charges de travail qui fonctionnent en dehors du traitement des demandes: Connexions WebSocket qui maintiennent l'état, threads d'arrière-plan qui traitent les files d'attente, ou des services qui doivent garder les caches en mémoire au chaud.

gcloud exécuter déployer mon service \
  --image mon image \
  --processeur 2 \
  --mémoire 1Gi \
  --pas de limitation du processeur \
  --région us-central1

Le –L'indicateur "no-cpu-throttling" permet un processeur toujours actif. Sans ça (ou avec –limitation du processeur), vous obtenez le mode de demande uniquement par défaut.

La différence de prix est importante. Avec allocation sur demande uniquement, vous payez par vCPU-seconde et GiB-seconde uniquement lors du traitement des requêtes. Avec toujours activé, vous payez pour tout le cycle de vie de l'instance. Pour un service qui gère un trafic HTTP en rafale avec des périodes d'inactivité entre, la demande uniquement peut être considérablement moins chère. Pour un service qui exécute des tâches en arrière-plan ou maintient des connexions WebSocket, toujours activé est la seule option qui fonctionne correctement.

Bilans de santé

Cloud Run n'enverra pas de trafic à une instance tant qu'elle ne sera pas prête. Par défaut, il utilise un Sonde de démarrage TCP: il attend que votre conteneur écoute sur le port attendu, puis le considère prêt.

Pour la plupart des services, ça suffit. Mais si votre application a besoin de temps pour charger les données, caches chaudes, ou établir des connexions à la base de données une fois le port ouvert, tu voudras une coutume Sonde de démarrage HTTP:

startupProbe:
  httpObtenir:
    chemin: /santé
    port: 8080
  initialDelaySeconds: 0
  périodeSecondes: 2
  seuil d'échec: 15

Cela indique à Cloud Run de GET /healthz tous les 2 secondes. Si ça échoue 15 fois, l'instance est marquée comme non saine et redémarrée. Ce n'est que lorsque la sonde réussit que l'instance commence à recevoir du trafic. Cela empêche le 502 errors that happen when a load balancer sends requests to an instance that's technically listening but not yet ready to serve.

Cloud Run prend également en charge sondes de vivacité qui s'exécute en continu après le démarrage. Si une sonde d'activité échoue, Cloud Run redémarre l'instance. Utile pour détecter les processus bloqués, impasses, ou des fuites de mémoire qui ne font pas planter le conteneur mais le rendent insensible.

Pour gRPC services, Cloud Run est compatible avec les sondes de vérification de l'état gRPC suivant les Protocole de vérification de l'état de gRPC.

Délai d'expiration de la demande

Chaque requête Cloud Run possède un temps mort. La valeur par défaut est 300 secondes (5 minutes). Le maximum est 3600 secondes (60 minutes).

gcloud exécuter déployer mon service \
  --image mon image \
  --temps mort 600 \
  --région us-central1

Si votre service traite les téléchargements de fichiers volumineux, génère des rapports, ou exécute des calculs de longue durée, tu voudras l'augmenter. Mais garde à l'esprit: le délai d'attente s'applique par demande. Si une seule demande prend plus de temps que le délai d'attente, Cloud Run y met fin. Les connexions WebSocket sont également soumises à ce délai d'attente, c'est pourquoi la partie 1 a mentionné la limite de connexion d'environ 60 minutes.

Un modèle commun pour les travaux de longue durée: accepter la demande, lancer le traitement de manière asynchrone (via Tâches cloud ou Pub/Sous), et renvoie un 202 immédiatement. Le client interroge le statut ou reçoit un rappel lorsque le travail est terminé. Cela permet de garder le délai d'expiration de votre demande court et votre service réactif.

Si vous atteignez régulièrement le maximum de 60 minutes, c’est un signal auquel votre charge de travail pourrait être mieux adaptée Emplois Cloud Run (pour le traitement par lots) ou une plateforme entièrement différente.

Mise à l'échelle: Instances et concurrence

L'autoscaler de Cloud Run gère trois paramètres associés:

Instances minimales contrôle le nombre d'instances qui restent au chaud lorsqu'il n'y a pas de trafic. La valeur par défaut est 0 (mise à l'échelle à zéro). Le régler sur 1 or higher eliminates cold starts but means you're paying for idle instances. It's the classic serverless trade-off: latence vs. coût. Pour les services de production sensibles à la latence, 1 est souvent le bon numéro. Pour les environnements de développement, 0 maintient votre facture à zéro.

Nombre maximal d'instances limite la mesure dans laquelle Cloud Run peut évoluer. La valeur par défaut est 100. Cela vous protège d’une mise à l’échelle incontrôlée (et une facture surprenante) lors de pics de trafic inattendus. Mais réglez ceci de manière réfléchie: si votre service communique avec une base de données avec un pool de 20 connexions, 100 les instances essayant toutes de se connecter le submergeront. Match your max instances to your backend's capacity.

Concurrence contrôle le nombre de requêtes qu'une seule instance gère simultanément. La valeur par défaut est 80. This is one of Cloud Run's key advantages over the old Cloud Functions 1st gen model, qui a traité une requête par instance. Avec concurrence à 80, une seule instance peut servir 80 requêtes simultanées avant que Cloud Run ne lance une autre instance.

Réduisez la simultanéité pour les charges de travail gourmandes en CPU où chaque requête nécessite une puissance de traitement dédiée. Élevez-le (jusqu'à 1000) pour les gestionnaires légers liés aux E/S qui passent la plupart de leur temps à attendre les appels réseau. Définir la simultanéité sur 1 mimics the one-request-per-instance model if your code isn't thread-safe.

gcloud exécuter déployer mon service \
  --image mon image \
  --min-instances 1 \
  --nombre maximum d'instances 10 \
  --concurrence 80 \
  --région us-central1

Et souviens-toi Boost du processeur de démarrage de la partie 1: Cloud Run double temporairement le processeur lors de l'initialisation de l'instance pour préparer les instances plus rapidement. Combiné avec des instances minimales, cela fait des démarrages à froid un problème pour la plupart des charges de travail.

Variables d'environnement et secrets

Cloud Run prend en charge deux mécanismes pour transmettre la configuration à vos conteneurs, et il est important d'utiliser le bon pour le travail.

Variables d'environnement sont destinés à une configuration non sensible: drapeaux de fonctionnalités, Points de terminaison de l'API, niveaux de journalisation, noms d'hôte de base de données. Définissez-les au moment du déploiement avec –définir-env-vars:

gcloud exécuter déployer mon service \
  --image mon image \
  --set-env-vars "DB_HOST=10.0.0.1,LOG_LEVEL=info,ENV=production" \
  --région us-central1

Cela fait suite au 12-Application Facteur méthodologie: la configuration vit dans l'environnement, pas dans le code.

Secrets sont destinés aux informations d'identification sensibles: Clés API, mots de passe de base de données, Certificats TLS, Secrets des clients OAuth. Ceux-ci devraient jamais être de simples variables d'environnement. Les variables d'environnement simples sont visibles dans la console Cloud Run., apparaître dans les journaux de débogage, et peut s'infiltrer dans les rapports d'erreurs. Plutôt, les stocker dans Gestionnaire de secrets et référencez-les au moment du déploiement:

gcloud exécuter déployer mon service \
  --image mon image \
  --set-secrets "API_KEY=my-api-key:dernier" \
  --set-secrets "/secrets/tls.key=tls-private-key:dernier" \
  --région us-central1

Les secrets peuvent être montés en tant que variables d'environnement ou en tant que fichiers. Le premier exemple ci-dessus monte le secret en tant que variable d'environnement appelée API_KEY. Le second le monte sous forme de fichier dans /secrets/tls.key. Les secrets sont versionnés, accès contrôlé via IAM, et journalisé par audit. Si un secret est compromis, vous le faites pivoter dans Secret Manager et vous le redéployez. Aucun changement de code.

Montages de volumes

Les instances Cloud Run sont éphémères, mais parfois vous avez besoin d'un stockage temporaire ou d'un accès aux fichiers partagés. Cloud Run prend en charge trois types de supports de volumes:

Volumes en mémoire are tmpfs-style mounts backed by your instance's RAM. They're fast but volatile (disparu lorsque l'instance se termine) et comptez sur votre limite de mémoire. Utile pour le traitement des fichiers temporaires, comme télécharger un fichier, le transformer, et télécharger le résultat:

gcloud exécuter déployer mon service \
  --image mon image \
  --nom du volume ajouté = scratch,type = en mémoire,limite de taille = 256 Mi \
  --ajouter-volume-mount volume=scratch,chemin de montage=/tmp/work \
  --région us-central1

FUSE de stockage en nuage monte un Stockage en nuage bucket en tant que système de fichiers local. Votre code lit et écrit les fichiers normalement, et FUSIBLE GCS traduit ces opérations en appels d'API Cloud Storage:

gcloud exécuter déployer mon service \
  --image mon image \
  --nom du volume ajouté = modèles,type = stockage cloud,bucket = mes-ml-modèles \
  --ajouter-volume-mount volume=modèles,chemin de montage=/mnt/modèles \
  --région us-central1

Le piège: c'est finalement cohérent. Pas de verrouillage de fichier, la dernière écriture gagne. Idéal pour lire les ressources partagées (Modèles ML, fichiers de configuration) ou écrire des artefacts (journaux, exportations). Pas bon pour les écritures simultanées dans le même fichier.

NFS via le magasin de fichiers vous donne pleinement POIX-système de fichiers réseau conforme avec verrouillage de fichier approprié. Latence inférieure à celle de GCS FUSE pour les lectures aléatoires. Nécessite Connectivité VPC depuis Magasin de fichiers les instances sont en direct sur votre VPC. Idéal pour les charges de travail nécessitant un accès partagé en lecture/écriture avec une cohérence au niveau des fichiers.

Pour la plupart des services Cloud Run, tu n'en auras pas besoin. Mais quand tu le fais (pipelines de traitement d'images, Diffusion de modèles ML, configuration partagée entre les instances), ils vous évitent de créer des solutions de contournement.

Configuration réseau

Les paramètres réseau par défaut de Cloud Run sont simples: votre service est public, et il se connecte à Internet pour le trafic sortant. Mais quand tu as besoin de plus de contrôle, il y a trois zones à configurer.

Entrée

Paramètres d'entrée contrôlez qui peut joindre votre service:

Tous (défaut). Accepte le trafic de n'importe où sur Internet. Amende pour les API publiques et les applications Web.
Interne. N'accepte que le trafic provenant de votre VPC ou depuis d'autres services Google Cloud (comme Pub/Sous, Planificateur de cloud, ou Tâches cloud). Le service est invisible sur l'Internet public. Utilisez-le pour les services backend qui ne doivent jamais être appelés directement par des clients externes.
Interne + Équilibrage de charge cloud. Identique à l'interne, mais accepte également le trafic via un Équilibreur de charge d'application externe global. C'est le chemin vers les domaines personnalisés, Mise en cache CDN avec Cloud CDN, et protection WAF avec Armure de Nuage. Vous verrez ce modèle d'équilibrage de charge réapparaître dans les sections Domaines personnalisés et Cloud Armor ci-dessous..

gcloud exécuter déployer mon service \
  --image mon image \
  --entrée interne \
  --région us-central1

Sortie et connectivité VPC

Par défaut, vos instances Cloud Run se connectent directement à Internet. Mais si votre service doit atteindre des ressources privées (un Nuage SQL base de données, un Mémoire Instance Redis, une API interne), il a besoin d'un accès VPC.

Deux options:

Connecteurs d'accès au VPC sans serveur. L'approche originale. Vous créez une ressource de connecteur qui relie Cloud Run et votre VPC. Travaux, mais ajoute un saut de réseau et a des limites de débit.
Sortie directe du VPC. La nouvelle approche. Les instances Cloud Run sont placées directement sur votre sous-réseau VPC. Aucun connecteur nécessaire, pas de saut supplémentaire, pas de goulot d'étranglement du débit. Il s'agit du chemin recommandé pour les nouveaux déploiements.

Si tu reparts à neuf, optez pour la sortie directe du VPC. Si vous disposez de services existants utilisant des connecteurs, ils continueront à travailler, mais envisagez de migrer lorsque cela vous convient.

Domaines personnalisés

Chaque service Cloud Run reçoit une URL *.run.app avec HTTPS automatique. Mais pour la production, you'll want your own domain. Deux chemins:

Mappage de domaine Cloud Run. L'option la plus simple. Mapper un domaine directement à votre service Cloud Run. Les certificats SSL sont provisionnés et renouvelés automatiquement. Fonctionne pour les configurations simples où vous avez juste besoin que api.example.com pointe vers votre service.
Équilibreur de charge d'application externe global. L'option la plus performante. Vous donne la mise en cache CDN, Cloud Armor WAF, routage multirégion, et routage basé sur des URL vers différents services. Plus de configuration, mais il débloque des fonctionnalités que le mappage de domaine à lui seul ne peut pas fournir.

Configuration de la sécurité

Les paramètres de sécurité par défaut de Cloud Run sont solides (couvert en partie 1). Mais pour les services de production, vous souhaiterez personnaliser quelques paramètres.

Comptes de services

Chaque service Cloud Run s'exécute comme un compte de service, qui détermine les ressources Google Cloud auxquelles il peut accéder. Par défaut, Cloud Run utilise le compte de service de calcul par défaut du projet, qui dispose généralement d'autorisations étendues.

Pour la production, créer un compte de service dédié par service avec seulement les autorisations dont il a besoin. Si votre service lit depuis Cloud Storage et écrit dans Pub/Sub, son compte de service doit avoir storage.objectViewer et pubsub.publisher. Rien de plus. C'est le principe du moindre privilège, et cela limite le rayon de souffle si un service est compromis.

gcloud exécuter déployer mon service \
  --image mon image \
  --compte de service [email protected] \
  --région us-central1

Authentification IAM

Par défaut, Cloud Run nécessite une authentification. Chaque demande doit inclure un jeton d'identité valide, et l'appelant doit avoir le rôle rôles/run.invoker sur le service. Il s'agit de la bonne valeur par défaut pour la communication de service à service.

Pour les services destinés au public (Apis, webhooks, applications Web), vous vous désabonnez explicitement en accordant le rôle rôles/run.invoker à tous les utilisateurs:

gcloud run services add-iam-policy-binding mon-service \
  --member="allUsers" \
  --role="roles/run.invoker" \
  --région us-central1

Mais même avec l'accès non authentifié activé, vous pouvez implémenter votre propre couche d'authentification dans votre code d'application. Cloud Run gère la sécurité des transports (HTTPS) et identité au niveau de la plateforme (la vérification de l'invocateur IAM). Votre application gère l'identité au niveau de l'application: connexions utilisateur, Clés API, Validation JWT.

Autorisation binaire

Autorisation binaire applique les politiques de temps de déploiement: seules les images de conteneurs signées par votre pipeline CI/CD peuvent être déployées. Cela empêche quelqu'un de déployer une image non testée directement en production, même s'ils disposent des autorisations IAM pour le faire.

Il s'agit d'un niveau de gouvernance qui a du sens pour les organisations ayant des exigences de conformité ou des processus stricts de gestion du changement..

Armure de Nuage

Armure de Nuage est le WAF de Google Cloud (Pare-feu d'applications Web). Il se trouve devant votre service Cloud Run et peut appliquer:

Listes d'autorisation et de refus d'adresses IP
Restrictions géographiques
Limitation du tarif par client
Règles WAF préconfigurées (Injection SQL, XSS, etc.)

Cloud Armor nécessite un Équilibreur de charge d'application externe global devant votre service Cloud Run. Si vous utilisez l'URL *.run.app par défaut sans équilibreur de charge, Cloud Armor isn't available. Mais si votre service est destiné au public et gère des données sensibles, l'équilibreur de charge + La combinaison Cloud Armor vaut la configuration supplémentaire.

Conclusion

Cloud Run vous offre suffisamment de boutons de configuration pour vous adapter aux charges de travail réelles. Mais vous n’êtes pas obligé de tous les toucher en même temps.

Le modèle que je recommande: commencer par les valeurs par défaut. Déployez votre service, voir comment il se comporte dans un trafic réel, puis ajustez. Augmentez la mémoire si vous atteignez les limites. Réduisez la concurrence si les requêtes sont gourmandes en CPU. Ajoutez un bilan de santé si votre démarrage est lent. Créez un compte de service dédié avant de passer en production. Chaque changement prend effet lors du prochain déploiement, avec zéro temps d'arrêt. Rien n'est permanent.

Si partie 1 il s'agissait de si Cloud Run a sa place dans votre architecture, et partie 2 il s'agissait de mettre votre code dessus, cet article concerne pour qu'il fonctionne bien pour vos besoins spécifiques. Commencez simplement. Ajoutez de la complexité lorsque votre charge de travail l'exige, pas avant.

Si vous venez juste de rejoindre la série, Partie 1 est le point de départ.

Ressources

C'est Cloud Run: La configuration a été initialement publiée dans Google Developer Experts sur Medium, où les gens poursuivent la conversation en soulignant et en répondant à cette histoire.