Déployer un générateur de pages à colorier en quelques minutes avec Cloud Run
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 :
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
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 :
? 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 :
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 :
✨ 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 :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 :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 :
Ajoutez le bloc suivant au fichier main.py. Il ne s'exécutera que lors d'un lancement manuel :
Lancez manuellement l'application :
Flask démarre un serveur web local :
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 :
À ce stade, voici les fichiers présents dans ce projet type :
Vous pouvez maintenant déployer votre application depuis le dossier source :
⚙️ Sous le capot
En ligne de commande, les différentes étapes sont détaillées :
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 :
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 :
Cette étape supplémentaire rend l'image à colorier plus propre et réduit la quantité d'encre utilisée en cas d'impression :
Redéployez ; l'application est automatiquement mise à jour :
? C'est en prod
L'application est visible en tant que service dans Cloud Run :
Le tableau de bord du service donne un aperçu de son utilisation :
Et voilà, votre application de traitement d'images est en production !
? 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 :
? 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 !
Essayez la démo et générez vos propres pages à colorier.
En savoir plus sur Cloud Run.
Pour plus de contenu cloud, vous pouvez me suivre sur Twitter (@PicardParis) ou LinkedIn (in/PicardParis).