Nous avons mis au défi notre communauté sans serveur interne de créer un raccourcisseur d’URL en utilisant la technologie sans serveur et en leur fournisseur Cloud préféré. Dans cet article, nous aimerions vous présenter le gagnant : Urly Wurly.
Après neuf ans de gloire en raccourcissement d’URL, Google a mis fin au célèbre service goo.gl au début de l’année. Cette fin de règne a donné naissance à l’idée de créer et d’exploiter notre propre service de raccourcissement d’URL chez Cloudreach, qui a entraîné le lancement de la Serverless Arena. Vous vous demandez peut-être ce qu’est Serverless Arena ? Au sein de la communauté Serverless interne de Cloudreach, nous avons lancé un concours simple : créer un raccourcisseur d’URL en utilisant votre fournisseur Cloud préféré et en utilisant uniquement la technologie sans serveur. En l’absence d’un meilleur titre, nous avons appelé ce concours « Serverless Arena ».
De nombreux gladiateurs courageux se sont rassemblés dans l’arène, chacun concevant et développant sa propre vision d’un service parfait de raccourcissement d’URL sans serveur, et le testant dans une compétition acharnée. Leurs efforts ont été évalués par un jury impitoyable jusqu’à ce qu’un service victorieux émerge… Urly Wurly. Oui, c’est exact. C’est le gagnant. ?
Urly Wurly est un service de raccourcissement d’URL sans serveur basé sur GCP. Il s’appuie sur le tout nouveau service Cloud Run de Google. Urly Wurly est aussi le nom de l’équipe qui l’a créé. Le nom vient de l’idée de prendre une URL très longue, de la mettre dans une machine magique et d’obtenir quelque chose de court et d’accrocheur. Sans surprise, l’équipe a fini par consacrer la majeure partie de son temps à la conception d’un logo adapté, capable de véhiculer cette idée de manière adéquate. L’équipe a mis son génie créatif à l’épreuve et a finalement abouti au chef-d’œuvre suivant :
Joli, non ?
Avec cet article, nous voulons ouvrir le code source de Urly Wurly, dans l’espoir que vous puissiez tous en bénéficier, que ce soit pour obtenir votre propre raccourcisseur d’URL personnalisé ou simplement pour voir comment nous l’avons mis en œuvre avec une méthode 100 % sans serveur. Vous pouvez vous rendre sur GitHub et forker le référentiel ou simplement jeter un coup d’œil au nôtre.
Qu’est-ce que Urly Wurly ?
Essentiellement, Urly Wurly est un service Web qui effectue deux opérations majeures : il peut accepter une longue URL, la stocker et renvoyer un lien très court dans son propre domaine. Deuxièmement, il peut être appelé avec une URL préalablement raccourcie et rediriger l’appelant vers l’URL longue précédemment stockée.
Cette fonctionnalité peut être consommée via un certain nombre de frontaux différents, tels que :
- Directement depuis le navigateur. Il renverra une petite application Web pour répondre à tous vos besoins de raccourcissement.
- Depuis l’interface CLI. Urly Wurly a publié une gemme ruby, qui peut être utilisée pour raccourcir les URL. Il est également possible d’utiliser cURL, wget ou tout autre client HTTP pour accéder directement au point de terminaison du service.
- Utilisation d’une extension Chrome. Nous avons créé une extension Chrome permettant de placer un bouton de raccourcissement en un clic dans la barre d’outils de Chrome pour faire le travail. Actuellement, nous envisageons toujours de publier l’extension sur le Chrome Web Store.
- Directement depuis Slack en utilisant les commandes Slash. Le service Urly Wurly est doté d’un appel intégré pour prendre en charge ces commandes depuis Slack.
Qu’est-ce que Under the Hood ?
Le backend de Urly Wurly est un serveur Web construit en GoLang. L’application est empaquetée en tant que conteneur Docker qui s’exécute sur GCP Cloud Run. Il utilise la version entièrement gérée de Cloud Run et doit donc être considéré comme sans serveur. Cloud Run intègre une foule de fonctionnalités étonnantes et de bonnes pratiques, tandis que le service est capable de cacher au consommateur les complexités des machines virtuelles et des clusters Kubernetes sous-jacents. Grâce à une mise à l’échelle horizontale fluide, Cloud Run déploie les nouvelles révisions des conteneurs de services de manière bleue et verte, avec des tests automatiques et un retour en arrière intégrés.
La journalisation intégrée, la surveillance, les certificats TLS et le déchargement, l’équilibrage de charge, les déploiements bleu-vert, les contrôles de santé et l’échelle 0 à quasi infinie font tous partie de GCP Cloud Run et sont presque totalement invisibles pour nous. C’est étonnant, car il s’agit selon nous d’un travail indifférencié et lourd. #serverlessrocks
Le conteneur de service Web est complètement sans état. Tous les états de l’application sont stockés sur Google Cloud Storage (GCS). Nous avons choisi GCS pour plusieurs raisons. GCS est sans serveur et incroyablement bon marché. En raison de la nature de notre utilisation, nous optimisons notre utilisation de GCS dès le départ : les URL longues sont stockées comme des objets GCS uniques. Les clés courtes, adaptées à l’URL, de chaque objet sont dérivées des sommes de contrôle codées en base 58 (crc32) des URL stockées. Étant donné que GCS détermine le placement des partitions en fonction des noms des clés des objets et que nos noms de clés sont assez aléatoires, cela compense le débit optimal de GCS dû à la répartition uniforme des clés sur les partitions GCS. Cela permet également de réutiliser des URL déjà stockées, car elles auront les mêmes noms de clés et ne seront stockées qu’une seule fois. Les buckets GCS sont également fournis avec une excellente configuration de surveillance par défaut dans Stackdriver. Nous pouvons facilement déterminer le nombre total de liens stockés en examinant le nombre d’objets dans le bucket. À un stade ultérieur, nous pourrons utiliser des fonctionnalités supplémentaires. La gestion du cycle de vie des objets dans le bucket peut s’avérer utile.
Voici un aperçu de la manière dont les composants de l’infrastructure sous-jacente interagissent entre eux.
Comment le développons-nous ?
L’infrastructure de Urly Wurly est exprimée en TypeScript, qui sera interprété et exécuté comme un certain nombre d’appels d’API basés sur Terraform à GCP par Pulumi. Cela nous donne une belle interface de programmation de haut niveau pour notre infrastructure. Pulumi stocke l’état de Terraform sur son propre service Web, ce qui élimine un autre casse-tête potentiel. Outre les services Cloud Run et le bucket GCS, Pulumi crée également une infrastructure de soutien, comme les déclencheurs et les pipelines GCP Cloud Build, les zones DNS et les liaisons IAM. Il est important de mentionner que nous n’avons pas été en mesure de définir notre infrastructure complète dans Pulumi/Terraform, car certaines des ressources nécessaires ne sont tout simplement pas encore prises en charge par Terraform/Pulumi.
Les poussées vers la branche master déclencheront des constructions d’intégration automatisées sur GCP Cloud Build et les artefacts d’image docker qui en résultent sont stockés sur GCP Container Registry. GCP Cloud Build prendra ensuite en charge le compte de service de GCP Compute Engine pour lancer un déploiement sur GCP Cloud Run. Si le nouveau déploiement passe les contrôles de santé, le trafic sera redirigé vers le nouveau déploiement (bleu/vert). Les poussées vers les branches de développement sont également intégrées et déployées dans un environnement distinct.
Pourquoi est-ce le meilleur service ?
Il dispose de la meilleure « tuyauterie » Internet, qui peut évoluer à l’infini (virtuellement) avec des déploiements sans temps d’arrêt et à un coût quasi nul. Il utilise les meilleurs conteneurs sans serveur de leur catégorie, qui peuvent être portés sur n’importe quel fournisseur Cloud. On pense notamment à Azure Container Instances ou Amazon Web Services Fargate, car ils sont compatibles avec des efforts de portage minimes. Il faut également tenir compte de la beauté époustouflante du logo artisanal de Urly Wurly 😀
Quelle est notre conclusion ?
Les outils GCP sont incroyables ! Vous pouvez commencer très rapidement. Nous avons surtout interagi avec des services assez récents (Cloud Build, Cloud Run). C’est un plaisir absolu de travailler avec Cloud Build. Il dispose même d’une fonctionnalité intégrée qui vous permet d’extraire rapidement le contenu de votre espace de travail, de le télécharger sur GCS et de l’exécuter comme une construction sur Cloud Build (le tout en une seule commande gcloud). Cela permet aux ingénieurs d’intégrer rapidement leur travail à distance (vous pouvez même le déployer sur un déploiement Cloud Run distinct) et de vérifier les modifications avant de les valider dans le contrôle de la source (lorsque les pipelines d’équipe réels sont déclenchés). CI/CD semble avoir un petit cousin : Personal CI, Personal CD.
