Serverless : Déployer des conteneurs sans gérer l'infrastructure avec Cloud Run

Section Un peut de context

Le serverless a étais créer pour répondre a une demande simple :

• Comment déployer une application simplement sans avoir a gérer l'infrastructure sous-jacente ?

Pour ce faire le serverless a étais créer par des grande platforme comme Google Cloud Run, Vercel... et démocratiser dans le cadre de l'utilisation par des petit script utilitaire simple en python de base, puis le support de java et d'autre language est venue sur la suite. Enfin depuis quelque temps maintenant la plus part des serverless propose l'utilisation de container via Docker ce qui rend l'utilisation de ses dernier légitime et facilement utilisable.

Section Le serverless chez Google

Google propose une offre serverless très intéressante, avec une partie gratuite (free-tier) extrêmement généreuse. Pour de nombreux petits projets personnels, l'utilisation reste largement dans les limites de la gratuité.

Vous avez accès à trois propositions différentes pour le service Cloud Run :

• Service : Permet de déployer des applications et d'exposer un endpoint pour interagir avec elles. Le scaling automatique est inclus. Vous pouvez utiliser des images pré-construites, connecter votre dépôt Git pour une dockerisation automatique grâce à des images créées par Google, ou même exécuter du code Python, go, ruby... directement via leur éditeur.

• Jobs : Idéal pour créer des processus traitant des données, des calculs, etc. Un tunnel peut être créé automatiquement pour communiquer avec Cloud SQL de manière sécurisée et automatique, nécessitant peu de configuration. Cependant, vous ne pouvez lancer que des images pré-construites.

• Worker Pools : Les worker pools ont la même mécanique que les services, mais sont utilisés pour des tâches qui n'ont pas besoin d'interaction HTTP, comme des microservices internes ou sensibles.

• Domain Mapping : Grâce à ce service, vous pouvez associer un nom de domaine à vos services Cloud Run exposés via HTTP. Si vous n'en avez pas, vous pouvez créer un domaine personnalisé avec leur nom de domaine ".cloud.run", ce qui vous permet d'appeler vos fonctions plus simplement et de manière professionnelle, tout en les organisant efficacement.

Section Déploiement d'une image déjà build

Dans Cloud Run, tu peux déployer une image Docker déjà build. Cela te permet de gérer toi-même le runtime de tes images, ce qui est particulièrement utile pour des microservices ultra-légers et performants comme ceux en Go ou Rust, avec des images de 20 à 30 Mo ou même en distroless (sans système d'exploitation).

Si tu n'as pas les compétences pour créer des images optimisées ou si tu préfères déléguer cette tâche, Google peut le faire pour toi. Ils utilisent des packages spécifiques pour packager ton application et la stocker dans leur gestionnaire de packages Cloud Artifacts Registry. Ce registre est gratuit sous certaines conditions et limites (nombre d'images stockées et taille). De plus, Artifact Registry propose un système d'analyse de vulnérabilités d'images très facile à exécuter et à configurer, permettant une analyse automatique à chaque nouveau déploiement.

Section Free tier et limite d'utilisation

Attention le servie Cloud Run est un service vraiment trés utile puissant qui vous permet de créer des icroservice trés facilement sans avoir a gérer d'infrastruture type kubernetes, swarm ou autre sur vos serveur ou même vous êvite d'utiliser des service types GKE, EKS... qui peuvent coûter trés chère. En revanche un cloud run peut ou proue optimiser et sans sécuriter met en danger votre portefeuille et peut revenir extrémement chère sans limite d'usage et de barrière de sécuriter.

4 règles pour éviter de payer trop cher

• Désactive le minimum de conteneurs : Pour bénéficier du quota gratuit, désactive le minimum de conteneurs et passe-le à 0. Cela évite d'avoir un conteneur permanent qui consomme des ressources inutilement.

• Désactive le "boost de démarrage" : Désactive le "Startup CPU boost" pour éviter d'allouer des ressources excessives et coûteuses, ce qui réduit le temps de démarrage ("cold start") de ton conteneur.

• Privilégie un accès interne : Si possible, utilise un Ingress pour autoriser uniquement les accès internes à tes projets. Cela évite d'être spammé depuis l'extérieur et réduit les risques de coûts imprévus.

• Choisis des technologies efficaces : Privilégie des technologies comme Go et Rust pour développer tes microservices. Elles sont plus légères, consomment moins de ressources et permettent d'encaisser plus de requêtes API pour un coût réduit. Bien que des technologies comme Java soient intéressantes sur le long terme, elles sont moins adaptées à Cloud Run en raison de leur temps de démarrage ("cold start") plus long et plus gourmand en CPU.