Accéder au contenu
Développeurs et professionnels

Déployer un générateur de pages à colorier en quelques minutes avec Cloud Run

28 juillet 2022
https://storage.googleapis.com/gweb-cloudblog-publish/original_images/image4_Lp4nmH7_p11Lh54.gif
Laurent Picard

Developer Advocate

Essayer GCP

Les nouveaux clients peuvent explorer et évaluer Google Cloud avec des conditions exceptionnelles.

Essayer

? Bonjour

Avez-vous déjà implémenté un script de traitement d'images ? L'avez-vous partagé ou exécuté sur plusieurs ordinateurs ? Combien de fois avez-vous dû mettre à jour son programme ou sa doc d'installation ? Avez-vous fini par en faire un service ou une application en ligne ? Le déploiement de services de traitement est un besoin récurrent, mais sa mise en place peut rebuter plus d'un développeur. Les technologies serverless vous permettent de résoudre ce défi, facilement et efficacement.

Dans cet article, vous verrez comment…

  • créer un service de traitement d'images générant des pages à colorier

  • le rendre disponible en ligne en utilisant un minimum de ressources

  • avec une latence minimale en profitant des centres de données Google Cloud français

…tout cela en moins de 200 lignes de Python et JavaScript.

?️ Outils

Pour implémenter et déployer un générateur de pages à colorier, quelques outils suffisent :

  • Une bibliothèque de traitement d'images

  • Un socle de développement web

  • Un serveur web

  • Une solution serverless pour rendre l'application disponible 24h/24 et 7j/7

? Architecture

Voici une architecture possible, basée sur Cloud Run :

Architecture serving a web app with Cloud Run

Et voici le flux d'échanges :

  • 1 - L'utilisateur ouvre l'application web : le navigateur envoie la requête correspondante.

  • 2 - Cloud Run retourne le code HTML de l'application.

  • 3 - Le navigateur demande les ressources supplémentaires nécessaires.

  • 4 - Cloud Run sert les fichiers CSS, JavaScript et les autres ressources.

  • A - L'utilisateur fournit une image : le client l'envoie au point d'entrée /api/coloring-page.

  • B - Le serveur traite l'image et renvoie le résultat, que l'utilisateur peut ensuite visualiser, télécharger ou imprimer depuis le navigateur.

? Couches logicielles

Il existe de multiples possibilités pour implémenter une telle architecture.

Voici un exemple de couches logicielles Python :

Schema

Schema

Elles comprennent :

  • Gunicorn : un serveur HTTP WSGI adéquat pour la production

  • Flask : un socle de développement web très populaire

  • scikit-image : une riche bibliothèque de traitement d'images

Pour commencer, définissez les dépendances de l'applicatif dans un fichier nommé requirements.txt :

CloudRun

? Traitement d'images

Comment supprimer les couleurs d'une image ? Une possibilité consiste à détecter les contours des objets qui la composent et à supprimer tout le reste. Cela peut être effectué via un filtre de Sobel, un filtre de convolution qui détecte les régions dans lesquelles l'intensité de l'image varie le plus.

Créez un fichier Python nommé main.py, définissez une fonction, puis utilisez un filtre de Sobel et d'autres fonctions de scikit-image :

Cloud run

Remarque : Les bibliothèques NumPy et Pillow sont automatiquement installées en tant que dépendances de scikit-image.

À titre d'exemple, voici comment le logo de Cloud Run est traité à chaque étape :

Colored input transformed into edge-detected grayscale output
Transformation d'une entrée colorée en échelle de gris avec détection des bords.

✨ Application Web

Partie serveur

Pour exposer les deux points d'entrée (GET / et POST /api/coloring-page), définissez des routes Flask dans main.py :
Cloud Run

Partie cliente

Du côté du navigateur, écrivez une fonction JavaScript qui appelle le point d'entrée /api/coloring-page et récupère l'image traitée :
Cloud Run

La base de votre application est là. Il ne reste plus qu'à ajouter un mélange de HTML + CSS + JS pour fournir l'expérience utilisateur souhaitée.

Développement local

Pour développer et tester l'application en local, une fois l'environnement configuré (e.g. venv pour Python), assurez-vous d'avoir les dépendances nécessaires :

CloudRun

Ajoutez le bloc suivant au fichier main.py. Il ne s'exécutera que lors d'un lancement manuel :

Cloudrun

Lancez manuellement l'application :

Cloudrun

Flask démarre un serveur web local :

Cloudrun

Remarque : Dans ce mode, vous utilisez un serveur web local de développement (i.e. non adapté à la production). Vous allez ensuite configurer le déploiement pour servir votre application avec Gunicorn, un serveur de production.

Vous êtes prêt. Ouvrez localhost:8080 dans votre navigateur, testez, affinez et itérez.

? Déploiement

Une fois votre application prête, vous pouvez définir comment elle sera servie avec cette seule ligne dans un fichier nommé Procfile :

Cloudrun

À ce stade, voici les fichiers présents dans ce projet type :

cloudrun

Vous pouvez maintenant déployer votre application depuis le dossier source :

cloudrun

⚙️ Sous le capot

En ligne de commande, les différentes étapes sont détaillées :

Cloudrun

Cloud Build est indirectement appelé pour conteneuriser votre application. L'un de ses principaux composants est Google Cloud Buildpacks, qui crée automatiquement une image de conteneur prête pour la production à partir de votre code source. Voici les principales étapes :

  • Cloud Build récupère le code source.

  • Buildpacks détecte automatiquement le langage de l'application (Python ici) et utilise l'image de base sécurisée correspondante.

  • Buildpacks installe les dépendances de l'application (définies dans requirements.txt ici).

  • Buildpacks configure l'exposition du service (définie dans Procfile pour Python).

  • Cloud Build transfère l'image du conteneur vers Artifact Registry.

  • Cloud Run crée une nouvelle révision du service basée sur cette image de conteneur.

  • Cloud Run y ​​achemine le trafic de production.

Remarques :

  • Buildpacks prend à ce jour en charge les environnements d'exécution suivants : Go, Java, .NET, Node.js et Python.

  • L'image de base est activement maintenue par Google, analysée pour détecter d'éventuelles vulnérabilités de sécurité et corrigée contre les problèmes connus. Cela signifie que lorsque vous déployez une mise à jour, votre service s'appuie sur une image la plus sécurisée possible.

  • Si vous avez besoin de créer votre propre image de conteneur, par exemple avec un environnement d'exécution personnalisé, vous pouvez ajouter votre propre Dockerfile que Buildpacks utilisera directement.

? Mises à jour

Après une utilisation de l'application à plus grande échelle, quelques problèmes remontent.

Tout d'abord, l'application ne gère pas les photos prises dans des orientations non natives. Vous pouvez résoudre ce problème en utilisant les données d'orientation EXIF :

Cloudrun

Ensuite, le traitement est trop sensible aux détails dans l'image de départ : les textures dans les peintures, ou le bruit dans les images, peuvent générer de nombreux bords dans l'image à l'arrivée. Vous pouvez améliorer l'algorithme de traitement en ajoutant une étape de débruitage en amont :

Cloudrun

Cette étape supplémentaire rend l'image à colorier plus propre et réduit la quantité d'encre utilisée en cas d'impression :

CloudRun

Redéployez ; l'application est automatiquement mise à jour :

Cloudrun

? C'est en prod

L'application est visible en tant que service dans Cloud Run :

Cloudrun

Le tableau de bord du service donne un aperçu de son utilisation :

Cloudrun

Et voilà, votre application de traitement d'images est en production !

Cloudrun

? C'est serverless

L'utilisation de Cloud Run dans cette architecture présente de nombreux avantages :

  • Votre application est disponible 24h/24 et 7j/7.

  • L'environnement est entièrement géré : vous pouvez vous concentrer sur votre code et ne pas vous soucier de l'infrastructure.

  • Votre application est automatiquement disponible en HTTPS.

  • Cloud Run adapte automatiquement le nombre d'instances en fonction du trafic et la facturation n'inclut que les ressources utilisées lors de l'exécution de votre code.

  • Si l'application n'est pas utilisée, Cloud Run réduit le nombre d'instances à zéro. Pas de trafic ? Pas de coût !

  • En cas de montée du trafic (votre app a du succès !), Cloud Run augmente la capacité avec le nombre d'instances nécessaires.

  • Vous pouvez contrôler les performances et les coûts en ajustant de nombreux paramètres : processeur, mémoire, concurrence, instances minimales, instances maximales, etc.

  • Chaque mois, la tranche gratuite de Cloud Run offre les premières 50 heures de vCPU, 100 Gio-heures de mémoire et 2 millions de requêtes.

? Ça tourne en France

Les services Cloud Run peuvent être déployés dans de nombreuses régions à travers le monde, y compris en France :

  • La région française vient d'être inaugurée et a pour code europe-west9.

  • Choisir des régions au plus près des utilisateurs finaux offre des temps de latence encore plus faibles.

  • Cerise sur le gâteau : europe-west9 est une région à faible émission de carbone ?.

L'application web GCPing (https://gcping.com) permet de tester en conditions réelles le temps de réponse entre votre ordinateur et les différentes régions Google Cloud. Voici un aperçu de la latence observée depuis Paris :

https://storage.googleapis.com/gweb-cloudblog-publish/images/Screen_Shot_2022-07-28_at_14.55.09.max-1900x1900.png

? Code source

Le projet comprend seulement 7 fichiers et moins de 200 lignes de code (Python + JavaScript).

Vous pouvez réutiliser cette démo comme base pour créer votre propre application de traitement d'images :

  • Retrouvez le code source sur GitHub.

  • Pour déployer vous-même l'application, étape par étape, en quelques minutes, consultez "Deploying from scratch".

? Plus !

Publié dans