Il y a plusieurs options pour créer son site web. Plusieurs services offrent de l’hébergement avec leur outil de conception propriétaire. Je pense entre autres à Squarespace ou Wix. Pour ma part j’ai choisi le logiciel WordPress depuis longtemps. Ça me permet d’héberger moi-même mon site mais avec un beau thème de mon choix. CNET fait une liste plus exhaustive des plateformes les plus populaires selon les types de sites web.

Problématique

Un premier défi que j’ai rencontré en hébergeant mes sites WordPress était le fait que mes sites finissaient par tomber. J’avais rencontré ce genre de problèmes dans le passé en hébergeant mon propre serveur Asterisk. Des bots sur internet sont programmés pour attaquer systématiquement les services disponibles publiquement tels que des sites WordPress. Le problème était un peu gênant. Je redémarrerais Apache et MySQL pour ensuite constater quelques semaines plus tard que le site était encore tombé.

En plus je serais routinièrement contraint de nettoyer des pourriels dans les commentaires et de supprimer les comptes d’utilisateurs qui en fait n’étaient que des bots publicitaires.

Solutions

Une première solution qui m’a dépannée était de placer le serveur derrière un wouff, euh non je veux dire un WAF :p. Haha je sais, je suis très drôle :). Personnellement j’ai utilisé le WAF de AWS. L’attrait qu’avait pour moi cette solution est qu’elle est facilement jumelable au CDN de AWS qui me permettait d’avoir des performances intéressantes pour un tarif basé sur l’utilisation. Par contre j’ai appris plus tard que CloudFlare offre ce service aussi gratuitement avec leur offre de CDN qui est aussi très bien semble-t-il.

Statique :O

Un collègue m’a mentionné dernièrement qu’il voulait construire son site statique avec GoHugo. J’avoue que l’idée d’utiliser un site statique me semblait un peu ordinaire et limitée. Notamment toutes les fonctions de traitement du coté serveur sont inopérantes. Donc plus de formulaire de commentaires et plus de formulaire de recherche dans le blogue. Et plus de publication facile de nouveaux articles ou de mises à jour spontanée.

D’un autre coté mon site web et mon blogue ne sont pas mis a jour si souvent de toute façon et les commentaires se trouvent plus souvent qu’autrement dans les réseaux sociaux. Un point que j’ai trouvé intéressant était l’idée que l’usage d’un site statique généré a partir de WordPress permet de dédier son serveur local de WordPress comme d’un environnement de test. Jusqu’à maintenant je desservais tous mes sites à partir de la même machine sur laquelle je développais.

Réalisation

J’ai donc fait un peu de recherche et j’ai trouvé cette extension de WordPress: Simply Static. Comme j’utilisais déjà Cloudfront je savais que l’hébergement de mon site statique avec S3 serait relativement simple. J’ai donc suivi un tutoriel. Ce dernier spécifiait quelques configurations élémentaires a faire:

Pour ce qui est de l’hébergement du site je savais déjà que je voulais l’héberger sur S3 comme la tarification est intéressante et que j’exploite déjà plusieurs services chez Amazon. Voici une documentation expliquant comment héberger un site statique sur S3 avec CloudFront:

Utiliser CloudFront pour diffuser un site Web statique hébergé sur Amazon S3

Pour terminer cette description de solution, je veux mentionner que même en mode d’hébergement statique, des plugin s’exécutant du coté client peuvent être utilisés pour remplir certaines fonctions laissées de coté. Par exemple un collègue qui héberge aussi son propre blogue utilise Remarkbox.

Et après quelques semaines?

Les performances, la sécurité, la disponibilité et le coût d’hébergement du site sur S3 sont excellents. Il y a bien sûr le fardeau de générer et transférer sur S3 la nouvelle version du site chaque fois qu’un article est ajouté ou que le site est modifié mais c’est sans doute automatisable.  Peut-être un sujet pour une autre fois. En tout et pour tout un site statique c’est tout de même un compromis très intéressant pour ceux qui sont prêts à repenser leurs façons de faire!

Tous les ans depuis le milieu des années 2000, AWS se réinvente et ajoute de nouveaux services à son arc en repoussant chaque fois les limites du possible. Chaque année, les prix reliés à l’ensemble de leurs services baissent, validant ainsi les clients dans leur choix pour le long terme. Comme dans beaucoup de secteurs des technologies de l’information, l’infrastructure et les services de plateformes du cloud public sont dominés par un joueur qui a su innover avant les autres.

Lire mon article publié sur le [ blogue de Gologic ].

Dans cette deuxième partie, nous allons automatiser le déploiement de l’infrastructure du réducteur d’URL présenté précédemment, à laquelle nous allons ajouter quelques morceaux. Je vous présenterai l’architecture et les coûts totaux et je vous guiderai dans son déploiement avec Terraform. Suite à ce laboratoire vous aurez un réducteur d’URL que vous pourrez gérer facilement avec la console de AWS.

Architecture et coûts

Comme dans le labo précédent, nous allons créer notre redirecteur d’URL à l’aide d’objets S3 attribués de la métadonnée Website Redirect Location. Nous allons aussi profiter de la facilité de gérer nos paramètres du redirecteur d’URL avec le AWS Systems Manager (SSM). Les fonctions lambda viendront appliquer les changements du magasin de paramètres dans les objets de redirection du compartiment S3 avec des évènements de CloudWatch. Les fonctions lambda seront déclenchées lorsqu’il y aura un ajout, une mise à jour ou une suppression d’un paramètre dans SSM.

Les coûts rattachés à cette architecture sont sensiblement les mêmes que ceux du premier laboratoire. Les paramètres standard sont gratuits comme nous ne faisons pas d’appel d’API. Les évènements Cloudwatch standard sont gratuits aussi. L’utilisation des fonctions lambda rattachée à ce projet rentreront sans doute dans la limite de 1M de requêtes gratuites par mois.

Voici donc la liste des coûts:

• Route 53: l’enregistrement d’un domaine ~17$ / année pour un .ca
• S3: stockage négligeable, coût pour 1M de GET 0,60$ / mois
• CloudFront: bande passante négligeable, coût pour 1M de GET: 1$ / mois

Une seule limite importante se présente toutefois. Une limite de 1000 paramètres par compte par région existe. Donc si vous voulez créer plus de 1000 URLs courtes, vous devrez demander une augmentation de limite au support de AWS.

Avant de commencer

Pour compléter ce laboratoire, nous devons avoir un domaine dont les DNS sont configurés dans Route 53. Des explications à ce sujet sont fournies dans le premier billet. Vous devrez aussi installer la console en ligne de commande de AWS. Les instructions pour l’installer sont disponibles ici. Finalement vous devez installer Terraform disponible ici.

Pour que Terraform puisse déployer l’infrastructure dans votre compte AWS, vous devez configurer le client tel qu’indiqué ici avec une clé disposant minimalement des permissions décrites dans le fichier suivant.

Vous aurez aussi besoin de l’utilitaire git.

Terraform

Dans ce laboratoire, nous allons déployer notre redirecteur d’URL avec Terraform. Il s’agit là d’un outil d’orchestration d’infrastructure qui permet de décrire l’infrastructure désirée sous forme de fichiers texte en faisant abstraction de l’ordre dans lequel les éléments d’infrastructure doivent être déployés. C’est pourquoi on réfère communément à cette pratique comme faire de l’infrastructure en code (« infrastructure as code »).

Terraform permet donc de déployer l’infrastructure, mais il permet aussi de détruire de l’infrastructure. En fait, il garde une trace du déploiement qu’il a fait dans des fichiers d’état qui peuvent être directement sur la machine du DevOps ou bien dans un endroit centralisé.

Comme nous avons déjà déployé de l’infrastructure pour le réducteur d’URL dans le premier laboratoire, nous commencerons donc par importer ce que nous avons fait dans le plan Terraform. Une fois que ça sera fait, nous pourrons déployer les morceaux manquants en appliquant le plan.

Importation de l’infrastructure existante

Si vous avez commencé par faire le premier laboratoire nous commencerons par importer ce que vous venez de faire dans le plan Terraform. Sinon, je vous invite à passer tout de suite à l’étape de déploiement.

Dans le laboratoire d’avant, nous avons créé une zone hébergée dans Route 53, un compartiment de site web statique dans S3 et une distribution CloudFront. La documentation de Terraform est très bien faite, alors je vous la fournit pour ces 3 ressources:
www.terraform.io/docs/providers/aws/r/s3_bucket.html#import
www.terraform.io/docs/providers/aws/r/cloudfront_distribution.html#import
www.terraform.io/docs/providers/aws/r/route53_zone.html#import

Dans mon cas, voici les trois commandes que je vais devoir lancer:

terraform import aws_s3_bucket.short_urls_bucket lrl.io
terraform import aws_cloudfront_distribution.short_urls_cloudfront EOYGSDES71UW4
terraform import aws_route53_zone.short_url_domain Z1D633PJN98FT9

Pour appliquer ces commandes à votre cas, vous devrez substituer mon domaine court avec le vôtre. Ensuite il vous faudra trouver l’identifiant de votre distribution CloudFront et celui de votre zone hébergée de Route 53. Les commandes suivantes vous retournerons ces valeurs.

aws cloudfront list-distributions | grep Id
aws route53 list-hosted-zones-by-name --dns-name lrl.io

Il faut toutefois avoir initialisé le plan avant de pouvoir importer quoique ce soit. Je vous invite donc pour l’instant à simplement recueillir votre identifiant de distribution CloudFront et celui de votre zone hébergée de Route 53.

Déploiement

Cloner le dépôt de code

Nous commencerons d’abord par télécharger le code dans lequel se trouve définie l’infrastructure de notre projet.

git clone https://github.com/ludorl82/aws-lambda-short-url.git

Initialiser le plan

Ensuite, nous continuerons en initialisant le plan Terraform.

cd aws-lambda-short-url
terraform init

Pour des fins de simplicité, nous créons ici le plan sur notre propre station de travail, mais il est bon de savoir qu’il est recommandé de sauvegarder le plan dans un espace de stockage sur le nuage tel que dans un compartiment S3. Ceci évite de devoir tout détruire manuellement si nous perdons les fichiers d’état de Terraform et que nous voulons apporter des modifications à l’infra.

Une fois le plan initialisé nous devrions avoir reçu un message de succès comme celui-ci.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Valider le code (au besoin)

Il est possible que le code Terraform doive être mis à jour avec les nouvelles versions du logiciel. Dans le cas qui nous concerne, j’ai utilisé la version suivante de Terraform.

$ terraform -version
Terraform v0.12.12
+ provider.archive v1.3.0
+ provider.aws v2.33.0

Si vous utilisez une version plus récente et que vous avez des erreurs, vous pouvez soit réparer le code avec la commande terraform validate ou bien télécharger la même version que moi de Terraform de leur section d’archives.

Une fois que vous avez initialisé le projet avec succès, vous pouvez maintenant déployer l’infrastructure. Si vous avez déjà créé votre réducteur d’URL manuellement selon l’architecture décrite dans le billet précédent, alors je vous invite à lire la section sur l’importation de l’infrastructure existante dans le plan et de lancer vos commandes d’importation maintenant.

Définir les variables (optionnel)

Pour éviter d’être questionné sur les valeurs que vous souhaitez donner à vos variables chaque fois que vous lancez le plan, vous pouvez définir ces dernières dans un fichier de variables comme ci-bas.

echo 'region = "ca-central-1"' > short_urls.tfvars
echo 'short_url_domain = "lrl.io"' >> short_urls.tfvars
echo 'base_domain_url = "https://www.ludoviclamarre.ca"' >> short_urls.tfvars
echo 'default_url = "https://www.ludoviclamarre.ca"' >> short_urls.tfvars

Si vous avez importé des ressources dans le plan, assurez-vous de choisir la même région dans laquelle se trouvent ces ressources.

Déployer l’infrastructure

Vous êtes maintenant prêt à déployer votre redirecteur d’URL. Pour ce faire, toujours à partir du répertoire du projet avec vos fichiers Terraform lancez la commande suivante:

terraform apply -var-file="short_urls.tfvars"

Si vous n’avez pas créé de fichier de variable alors on vous demandera les valeurs suivantes:

• Le domaine court que vous souhaitez utiliser (ex. exemple.com)
• L’URL sur laquelle vous souhaitez rediriger la racine du domaine (ex. https://www.monsiteweb.com)
• L’URL sur laquelle renvoyer en cas d’erreur d’adresse (ex. https://erreur.url.com/pasdurlici)
• La région dans laquelle déployer (ex. ca-central-1)

On vous présentera alors l’ensemble des choses qui seront déployées. Vous pouvez alors faire yes.Vous devrez alors attendre plusieurs minutes le temps du déploiement. Finalement, on vous retournera un message de succès.

Outputs:

BaseDomainURL = https://www.monsiteweb.com
DefaultURL = https://erreur.url.com/pasdurlici
ParameterPrefix = exemplecom
Region = ca-central-1
ShortURLDomain = exemple.com

Gérer son réducteur d’URL

Pour cette dernière section, je vous invite à lire le README du dépot de code. C’est dans ce fichier que je tiens à jour cette information étant donné qu’il s’agit d’un projet qui pourra possiblement évoluer dans le temps.

Mot de la fin

J’espère que vous avez apprécié de découvrir Terraform avec moi. Je vous invite à m’écrire si vous avez des questions.

@++

Dans cette publication, je vous partagerai ce que j’en suis venu à préconiser comme environnement de travail comme DevOps. Ces dernières semaines, je me suis fait un malin plaisir à lire plusieurs livres sur les logiciels que nous utilisons à mon travail, mais un de ceux qui m’a procuré le plus de plaisir est un livre sur l’éditeur de texte Vim intitulé Practical Vim: Edit Text at the Speed of Thought. Dans la même collection, j’ai aussi dévoré un autre petit livre, tmux 2: Productive Mouse-Free Development. C’est surtout avec ces deux ouvrages que j’ai défini mon environnement de travail.

Développer avec Vi IMproved

Vim est un éditeur de texte à la fois très connu et méconnu. Ça faisait plusieurs années que je l’utilisais dans le cadre de mes fonctions d’architecte de systèmes lorsque je devais éditer des configurations dans la console, mais ce n’est que dans ces derniers mois que j’en ai vraiment compris l’essence et le plein potentiel. Vim permet d’éditer des fichiers de texte sans environnement graphique comme tous les éditeurs de texte en console, mais Vim est en réalité plus que cela. C’est un véritable outil de production de code.

Le premier mystère de Vim, contrairement à d’autres éditeurs de texte en console est le mode normal qui ne permet pas l’édition de texte. Ce que l’auteur Drew Neil nous explique c’est que Vim traite les fichiers de code que nous créons comme des peintures. Plutôt que de rentrer directement dans l’ajout de texte, qui est peut-être la fonction principale de quelqu’un qui écrit de longs textes, Vim dans le mode normal offre à son utilisateur une interface axée sur les actions répétitives.

Le mode normal permet en fait d’effectuer des opérations que l’on combine à des mouvements. Par exemple, on fait du copier/couper coller, avec les nombreux registres à cet effet, on crée et on utilise des macros que l’on utilise sur différents fichiers. Lorsqu’on combine une opération avec un mouvement, on peut alors répéter facilement l’action avec une touche réservée à cet effet. Si vous connaissez déjà tous les raccourcis clavier de votre système actuel, peut-être que Vim est le défi que vous cherchez pour amener votre productivité au prochain niveau.

Une des forces de Vim est la fondation de toutes les touches permettant à l’utiliser avec le clavier. On dit que Vim est un outil conçu pour ceux qui sont familiers avec la dactylographie. Bien que toutes les touches de Vim sont configurables, par défaut le logiciel est fait pour augmenter la productivité de ceux qui sont habitués à taper sans regarder le clavier suivant la technique de dactylographie enseignée sur les applications telles que Tap’Touche. Vim et tmux peuvent être utilisés avec l’aide de la souris, mais par défaut cette dernière est désactivée.

Gérer ses fenêtres avec tmux 2

Bien que Vim permette de gérer lui-même plusieurs onglets et plusieurs panneaux dans une même session d’édition, nous avons parfois besoin de retourner dans la console pour lancer nos travaux d’automatisation ou bien nous voulons temporairement suspendre le travail dans notre outil pour ouvrir un autre projet. tmux 2 permet de faire cela et bien plus. tmux qui veut dire terminal multiplexer est une solution regorgeant d’avantages pour le travail dans la console. Lorsqu’exécuté sur un environnement de serveur, il permet de faire tourner ses travaux de build et d’automatisation en arrière-plan alors que le client de console SSH peut être déconnecté du serveur. Donc, si on lance une lourde tâche et que la connexion SSH est interrompue, on peut revenir s’attacher sur notre session qui roule encore en arrière-plan. Par exemple, quand on a un laptop et qu’on veut le fermer pour se déplacer, mais qu’on a une job qui roule, c’est très pratique.

Une autre facette intéressante de tmux, qui est liée directement au but de cet article, est la capacité de configurer la disposition de notre environnement de travail ainsi que les applications qui vont être démarrées au lancement de l’environnement. Bien que tout cela se fasse avec tmux nativement, il existe un script qui permette de profiter de tmux simplement sans avoir à gérer trop de configurations. Il s’agit là de tmuxinator. Ce script rend possible la gestion de ses environnements de travail de manière déclarative dans des fichiers YAML.

Une fois dans une session tmux, il est essentiel de connaître les raccourcis clavier du logiciel. Un simple aide-mémoire pour trouver les raccourcis peut suffire, mais je vous invite à lire l’ouvrage de Brian P. Hogan tmux 2: Productive Mouse-Free Development dans lequel il explique les commandes essentielles. Le livre est très succinct et va droit au but. Il décrit tmux 2 et il parle aussi de tmuxinator.

Installer les outils

Tout d’abord, pour installer les outils sur Ubuntu 18.04 nous commencerons comme toujours par mettre à jour le système.

sudo apt update
sudo apt upgrade

Vim est normalement installé de base sur Ubuntu, mais vous pouvez utiliser cette commande pour vous en assurer.

sudo apt install vim

Ensuite pour installer tmux et tmuxinator, il vous faudra installer le gestionnaire de scripts gem qui vous permettra d’installer ce dernier. Des instructions complètes sur l’installation sont disponibles ici:
https://github.com/tmuxinator/tmuxinator#installation

Quand au binaire de tmux, il est disponible dans le gestionnaire de paquets de base de Ubuntu.

sudo apt install tmux
sudo apt install ruby-full
gem install tmuxinator
export EDITOR='vim'
source ~/.bin/tmuxinator.zsh

En plus de profiter des outils précédemment décrits, j’utilise depuis longtemps la console ZSH notamment pour la facilité qu’elle offre pour parcourir les différentes commandes que nous sommes appelées à utiliser au jour le jour. Par dessus ZSH, j’ai aussi ajouté une configuration déjà codée par Robby Russell: Oh My ZSH.

sudo apt install git-core zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

Oh My ZSH offre plusieurs thèmes que je vous invite à explorer sur la page de son développeur.
https://github.com/robbyrussell/oh-my-zsh/wiki/Themes

Vim et tmux à la Ludo

Si vous êtes un DevOps, vous aurez sans doute le réflexe louable de mettre ces outils à votre main. Je vous encourage à le faire en consultant les nombreuses ressources du web, mais à titre d’exemple je vous partage ma configuration personnelle très sommaire avec les instructions qui m’intéressent le plus.

cd ~
wget https://labodeludo.dev/wp-content/uploads/2019/09/20110651/zshrc.tar
wget https://labodeludo.dev/wp-content/uploads/2019/09/20110208/tmux.tar
wget https://labodeludo.dev/wp-content/uploads/2019/09/20111717/vim.tar
for f in {zshrc.tar,tmux.tar,vim.tar}; do tar zxvf $f; done
ln -s .vim/vimrc .vimrc
rm -f {zshrc.tar,tmux.tar,vim.tar}

Maintenant que vous avez changé la console et que vous avez inclus toutes vos configurations, vous pouvez simplement sortir de votre session avec Ctrl-d et ouvrir de nouveau le terminal. Vous aurez alors une console semblable à la suivante. Il vous restera probablement à changer les polices de votre terminal. Personnellement, j’utilise wsl-terminal à la maison sous Windows 10 et iterm2 au travail sur Mac OS. Voici une référence qui m’a été utile pour avoir des polices plus agréables à lire sur Windows avec WSL et Ubuntu.
https://medium.com/@Andreas_cmj/how-to-setup-a-nice-looking-terminal-with-wsl-in-windows-10-creators-update-2b468ed7c326

Une fois rentré dans la console de base, on peut lancer son environnement de choix avec tmuxinator avec la commande mux ide. Pour faciliter l’utilisation de tmux et Vim, je vous recommande aussi de réassigner votre touche de verrouillage de majuscule avec Ctrl. J’ai utilisé ce guide pour le faire.
https://vim.fandom.com/wiki/Map_caps_lock_to_escape_in_Windows

Pour basculer d’une fenêtre à l’autre vous pouvez faire Ctrl-a 2 et Ctrl-a 1.

Dans ma configuration j’ai activé le mode Vim pour parcourir l’historique de la sortie de la console dans tmux en mode copie. Je trouve que ça permet de profiter plus pleinement de l’apprentissage de Vim. J’ai aussi constaté que les différents raccourcis dans Vim pour parcourir le texte sont utilisés dans less. Avec cet apprentissage vous pouvez donc avancer avec la conviction que vous apprenez une méthode de travail qui est au cœur des systèmes avec lesquels vous serez appelé à travailler.

Un petit Cloud9 en passant

Finalement, si comme moi vous aimez parfois pouvoir utiliser du graphique, je vous conseille d’utiliser l’IDE de cloud de AWS. Il s’installe facilement sur un serveur Linux avec la configuration que je vous ai partagée et, en plus, vous aurez un outil graphique pour le copier coller par exemple ou si vous n’avez accès qu’à un fureteur web.

Rien ne vaut la pratique

Je vous encourage encore à vous renseigner sur l’utilisation des différents outils que je vous ai présentés. Dans ma configuration de tmux j’ai modifié la touche de commande avec Ctrl-a. Mis à part ce changement vous pourrez utiliser toutes les références du web sur le sujet. Et à vrai dire, il semble que cette modification soit plus commune que le Ctrl-b affecté par défaut.

Et pour ce qui est de Vim, c’est un sujet très vaste qui pourrait être traité beaucoup plus longtemps, mais dans la réalité c’est en l’utilisant et en pratiquant les différents raccourcis et commandes que vous viendrez à l’adopter.

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.

*** MAJ 2019-10-24 Si vous souhaitez simplement déployer le réducteur d’URL vous pouvez sauter au prochain article.

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

*** MAJ 2019-10-23: 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 bien une redirection 301 en analysant les entêtes tel qu’en fait foie 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.

Des fois 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 pas 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 voulez 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 pas trop long 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 domaines 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 sûr 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 allons demander 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 que c’est fini de se créer, 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 ce que devrait avoir l’air 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 un prochain post, je vous montrerai comment gérer vos URLs courtes avec le AWS Systems Manager et des fonctions Lambda.