Google Cloud Platform et Amazon Web Services proposent une multitude d'infrastructures pour exécuter une application web. Tester un nouveau service peut toutefois sembler intimidant. Pour se familiariser avec une nouvelle technologie, on commence souvent par lancer une instance minimale depuis la ligne de commande.
Dans cet article, vous découvrirez comment vous initier rapidement à neuf services Google Cloud et AWS grâce aux Quickstarts que j'ai créés. Un Quickstart, dans ce contexte, est un script bas niveau qui vous amène jusqu'au stade Hello World! pour le service concerné, tout en vous aidant à comprendre les processus sous-jacents qui vous y ont mené.
Ces Quickstarts permettent de franchir aisément la première étape, souvent intimidante, où l'on ne maîtrise encore que peu (ou pas du tout) la technologie, pour atteindre le palier rassurant où l'on peut enfin dire : Ça marche !. Vous pourrez ensuite ajouter progressivement les fonctionnalités que vous souhaitez explorer.
Principes de conception des Quickstarts
Chaque Quickstart repose sur les mêmes principes : automatisé, minimal et complet.
Automatisé
L'interface graphique est utile pour un premier coup d'œil, mais les scripts s'imposent au stade Hello, World!, car ils permettent de redéployer le même service à volonté tout en peaufinant et en ajoutant des fonctionnalités.
Minimal
Les scripts Hello, World! sont minimalistes : juste le code nécessaire pour obtenir la réponse HTTP.
GCP utilise le terme Quickstart pour désigner un tutoriel décrivant le chemin le plus rapide pour faire tourner une technologie donnée. Mon dépôt va plus loin en se concentrant sur les scripts exécutables, généralement encore plus simples que ce que l'on trouve dans ces articles.
Chez AWS, un Quick Start est un template CloudFormation permettant de mettre en route une technologie donnée. C'est utile, mais j'ai préféré des scripts shell, car ils aident à comprendre les commandes de plus bas niveau — un point essentiel lorsqu'on construit ensuite un système complet.
Je vois cela comme un Quickstart encore plus rapide.
Complet
Les scripts déploient tout ce qui est nécessaire : rôles IAM, clusters, etc. Les seuls prérequis sont les outils en ligne de commande et l'authentification à un compte cloud. Une fois cela en place, l'objectif est de lancer tout ce qui est requis. Ainsi, en cas de problème, vous pouvez repartir de zéro sans avoir à remettre chaque composant dans un état stable.
Idéalement, les scripts sont rejouables, ce qui permet de déployer du nouveau code par-dessus un déploiement précédent. Certains scripts proposés ici le permettent, d'autres non, car cela aurait demandé trop de code supplémentaire. Pour ces derniers, supprimez l'ancienne instance avant de redéployer, ou lancez chaque nouvelle version avec un nom différent. (Attention aux coûts ! Pensez à supprimer les anciennes instances dès que possible.)
Prérequis
Le fichier README de chaque répertoire détaille les prérequis, parmi lesquels :
gcloud, authentifié (viagcloud init)- L'outil AWS CLI avec ses identifiants.
- Un plugin AWS CLI pour Lightsail.
- L'outil
ebd'Elastic Beanstalk. - L'outil
ecs-clipour ECS, que le script installe pour vous. - Pour le traitement de la sortie des commandes, certains scripts nécessitent
envsubst(à installer via le paquetgettext) ainsi quejq.
Les infrastructures prises en charge
Voici les scripts que j'ai créés pour :
- AWS Elastic Beanstalk
- AWS Lambda
- Amazon Elastic Container Service
- Amazon Lightsail
- Google App Engine Standard Environment
- Google App Engine Flexible Environment
- GCP Cloud Functions
- GCP Cloud Run
- Google Kubernetes Engine
Scripts
Le dépôt git contient un script deploy.sh pour chaque technologie d'infrastructure, dans les sous-répertoires correspondants. Si l'aventure vous tente, vous pouvez tous les exécuter via run_all.sh à la racine.
Si ce travail vous est utile et que vous souhaitez en voir davantage, n'hésitez pas à soumettre une pull request avec votre propre script, ou à ouvrir une issue pour demander celui de votre choix.
Elastic Kubernetes Service serait une suite logique, suivi d'EC2, de Google Compute Engine et des offres d'autres fournisseurs cloud.
Des différences de simplicité
Les technologies d'infrastructure varient en simplicité et en flexibilité.
Pour App Engine Standard Environment et Cloud Functions, le script se résume à une seule commande deploy, suivie d'un accès à une URL connue. Pour d'autres, c'est plus complexe : Cloud Run et ECS exigent par exemple de construire et de pousser un conteneur, tandis que Lambda nécessite en plus un rôle IAM.
Au final, ces différences pèsent peu. Une fois le Hello, World! en marche, ces scripts permettent d'automatiser et de masquer la complexité.
Pour aller plus loin
Pour une explication détaillée des étapes menant au Hello, World!, consultez les articles Quickstart ou Getting Started référencés dans chaque README.