Par Ludovic Lamarre, DevOps et architecte de systèmes chez Gologic
Dans cette publication, je vais vous montrer comment on peut créer simplement un réducteur d’URL hébergé dans S3. Pour ce faire, nous aurons besoin d’un petit nom de domaine et d’un compte AWS.
Plan de match
- Enregistrer le domaine court et le configurer dans Route 53
- Créer le compartiment S3 et le configurer en site web statique
- Placer et configurer le CloudFront devant le compartiment
- Créer nos URLs courtes dans S3
L’origine Cloudfront a été modifiée pour pointer sur l’URL de site web statique du compartiment S3 et non sur son URL d’API REST. Nous avons maintenant une redirection 301 en analysant les entêtes tel qu’en fait foi la dernière saisie d’écran.
Un peu de contexte
Les réducteurs d’URL sont très populaires dans le domaine du marketing et du web parce qu’ils permettent de communiquer des adresses faciles à se souvenir pointant sur des ressources précises sur le NET. Par exemple, les réseaux sociaux ont tous leur propre réducteur d’URL, lnkd.in, t.co, g.co et fb.me pour ne nommer qu’eux. Lorsqu’on «post» un lien vers une page externe sur le web, une petite URL est créée automatiquement et elle pointe vers la page en question.
Vous pouvez aussi recourir aux bitly de ce monde pour réduire vos URLs, mais sans rentrer trop dans les détails des différentes facettes de chacun des services, vous devrez sacrifier certaines libertés et certaines possibilités si vous ne payez pas des sommes importantes.
Parfois avec un peu de savoir-faire on peut faire plus. Faire son propre réducteur d’URL c’est un beau projet qui nous permet de survoler les technologies sans serveur du cloud. Si vous suivez ce document jusqu’à la fin, vous aurez construit un petit réducteur d’URL très performant, hautement disponible et demandant peu de maintenance.
Architecture et coûts
Maintenant nous allons créer notre redirecteur d’URL à l’aide d’objets S3 attribués de la métadonnée Website Redirect Location. Devant S3 nous placerons une distribution CloudFront pour maximiser les performances et pour ajouter un certificat SSL à notre outil. Une fois le labo complété, nous aurons donc un redirecteur d’URL sur un point de distribution CloudFront avec HTTPS.
Une des beautés des architectures sans serveur est que le coût est basé strictement à l’utilisation. Donc dans notre cas (Canada Central):
– S3: stockage négligeable, coût pour 1 million de GET 0,60 $/mois
– Amazon CloudFront: bande passante négligeable, coût pour 1 million de GET: 1 $/mois
Quant à l’enregistrement du nom de domaine, ça peut aller de quelques dollars par année à plusieurs centaines. Les .io sont à 39 $/année sur AWS. Vous pouvez aussi choisir d’utiliser un sous-domaine d’un domaine que vous possédez déjà si vous désirez simplement expérimenter.
Déployer le réducteur d’URL
Enregistrer son domaine court
En premier, vous allez devoir vous trouver un nom de domaine court qui répond au besoin. Avec toutes les TLD qui sont maintenant disponibles, ce n’est pas trop difficile de trouver un nom de domaine court. En moyenne, les noms de domaine sont d’environ 13 caractères avec l’extension .com ; moins que ça, c’est bien. Si vous voulez un coup de pouce pour trouver le bon nom de domaine, vous pouvez faire vos recherches notamment dans Domainr qui parcourt toutes les extensions TLD du NET.
Une fois que vous aurez trouvé votre nom de domaine court, vous pouvez l’enregistrer auprès de votre registraire de choix. Ces instructions vous montreront comment enregistrer le domaine avec Amazon. Si vous utilisez un autre registraire que Amazon, vous devrez créer une zone hébergée dans Route 53 et la désigner comme serveur DNS pour votre domaine. Voir ces instructions.
Maintenant que nous avons enregistré notre nom de domaine et que nous avons désigné Route 53 comme serveur DNS pour ce dernier, nous allons voir les entrées telles que celles-ci. Le nom de domaine que je vais utiliser est lrl.io.
Pour être certain que les changements de DNS auprès de votre registraire se sont bien propagés sur le NET, vous devriez faire une requête DIG sur les serveurs de nom de Google par exemple et vérifier que vos entrées NS correspondent.
Créer son compartiment S3
Vous devez ensuite créer un compartiment S3 qui servira de site web statique en suivant ces instructions. Prenez bien note que le compartiment devra avoir le même nom que votre domaine.
Comme page d’index et comme page d’erreur, nous spécifions un objet que nous appelons web. Il fera une redirection sur la page d’accueil de notre domaine. Assurez-vous ensuite que vos fenêtres correspondent à celles-ci.
Maintenant que votre compartiment S3 est configuré en hébergement statique et que Route 53 fait pointer le domaine sur ce dernier, vous pouvez déjà créer des objets dedans et les voir avec votre nom de domaine. Si par exemple vous créez l’objet web dans votre compartiment avec le code suivant à l’intérieur <html><body>Vous avez bien rejoint votre compartiment S3</body></html>, vous devriez être en mesure de voir votre page html s’afficher en naviguant à l’adresse: http://lrl.io/web. Plus loin dans le post, nous allons voir comment ajouter des objets dans S3. Vous pouvez sauter là tout de suite, si vous n’avez pas besoin de HTTPS.
Configurer Cloudfront comme point de terminaison SSL
Pour utiliser le CDN de Amazon comme point de terminaison SSL, nous allons d’abord créer notre certificat dans AWS Certificate Manager, dans la région de Virginie du Nord. Pour ce faire, nous allons dans la console de ACM et nous demandons un certificat public tel que décrit dans la documentation. Comme nous hébergeons les services DNS du domaine dans Route 53, nous pourrons procéder à la validation par DNS en cliquant simplement sur le bouton Créer un enregistrement dans Route 53. Suite à la validation du certificat par entrée DNS ou par email, nous devrions avoir le résultat comme suit.
Maintenant que nous avons créé notre certificat SSL, nous sommes prêts à créer la distribution. Dans AWS CloudFront, nous allons faire Créer Distribution. Nous choisirons de faire une distribution web avec les paramètres tels qu’illustrés ci-bas.
La distribution CloudFront devrait prendre environ 20 minutes à se déployer, mais si vous faites des changements ça prendra encore une vingtaine de minutes. Soyez patients. Une fois le tout créé, nous devrions voir le résultat comme suit.
Finalement, nous devons configurer Route 53 pour pointer sur la distribution CloudFront, car elle est maintenant le point de contact pour nos clients du web. Dans votre zone hébergée de Route 53, vous devez mettre à jour l’entrée comme suit. Vous devrez toutefois patienter que la distribution CloudFront ait terminé de se déployer. Voici à quoi devrait ressembler la zone hébergée de Route 53.
Créer ses URLs courtes
Maintenant, nous pouvons commencer à ajouter les objets qui serviront de point de redirection pour nos URLs courtes. Nous commencerons par créer l’objet web qui sert à rediriger les requêtes sur le domaine racine.
Il reste donc seulement à créer les objets qui vont nous servir d’URL courtes. Pour commencer, on va créer un objet qu’on va appeler web. L’objet ne doit pas avoir d’extension et il peut être complètement vide. Une fois que le fichier est créé, on le charge dans le compartiment.
Ensuite, dans les propriétés de l’objet, nous allons créer une redirection vers notre long nom de domaine.
Nous pouvons confirmer que le domaine court est bien redirigé vers notre longue URL en naviguant sur l’URL courte ou bien en analysant les entêtes de la réponse HTTP telle que ci-dessous avec webconfs.
Maintenant que nous avons redirigé le domaine court sur sa racine, nous pouvons suivre le même processus pour ajouter autant d’URLs courtes qu’il nous plaît.
Mot de la fin
Dans cette publication nous avons donc créé un redirecteur d’URL sans serveur qui se met à jour en téléchargeant des objets dans notre compartiment S3. Dans une prochaine publication, je vous montrerai comment gérer vos URLs courtes avec le AWS Systems Manager et des fonctions Lambda.
Vous êtes passionnés d’infrastructure as code ? Nous aussi ! Participez à notre atelier DevOps Infrastructure as code et développez vos compétences techniques.
À bientôt.
Ludovic Lamarre, DevOps et architecte de systèmes
Avec prêt de 10 ans d’expérience en TI comme architecte de systèmes, j’ai effectué plusieurs migrations vers le cloud en IAAS, PAAS et SAAS. Pour toujours un évangéliste de l’infonuagique, je poursuis maintenant ma carrière dans le DevOps, penchant vers les opérations.
