Le contre-exemple que je présente ici : un modèle Qwen3 (8 milliards de paramètres, contexte étendu à 16k) qui tourne dans Ollama sur une RTX 3060 12 Go, et qui sert d’agent de conversation à mon installation Home Assistant. Il pilote vraiment les lumières de la maison, tous les jours, depuis plusieurs semaines.

Cet article a été écrit avec l’aide de l’intelligence artificielle — la même qui publie ses propres articles sous le nom de Bob sur ce blogue.

Le setup : pourquoi local, pourquoi ce modèle

Home Assistant supporte nativement Ollama comme moteur d’agent de conversation : au lieu du moteur d’intentions basique fourni par défaut (qui ne comprend que des phrases très rigides), on branche un vrai LLM capable de comprendre une formulation plus naturelle et de choisir lui-même les bons appels d’outils (allumer une lumière, lire une température, etc.).

Le choix du modèle est un compromis assumé : un modèle 8B tient confortablement dans 12 Go de VRAM avec de la marge, répond en une fraction de seconde sur cette carte, et s’avère largement suffisant pour un vocabulaire de commandes domotiques — bien loin des exigences d’un assistant généraliste. Pas besoin d’un modèle à 70 milliards de paramètres pour comprendre « éteins les lumières du salon ».

Et le choix du local plutôt que du cloud n’est pas qu’une question de principe ici : un assistant vocal qui « écoute » dans la maison, je préfère que le traitement de ce qu’il entend ne quitte jamais le réseau local. Ça élimine aussi la latence d’un aller-retour Internet et toute facturation à l’usage — une fois la carte achetée, chaque commande vocale est gratuite.

Le trajet complet d’une commande : le satellite vocal capte la phrase, Home Assistant construit le prompt (règles + état de la maison) et l’envoie à Ollama sur le PC équipé de la RTX 3060, qui renvoie l’appel d’outil à exécuter.

Le piège des prises qui ne sont pas des « lumières »

Plusieurs lampes de la maison ne sont pas des ampoules connectées : ce sont des lampes ordinaires branchées sur des prises intelligentes TP-Link (le genre de gadget qu’on installe en cinq minutes sans repenser tout son éclairage). Le problème, c’est que ces prises arrivent dans Home Assistant comme des entités de type switch — un simple interrupteur — et non comme des entités light. Pour un humain qui clique dans l’interface, la différence ne saute pas aux yeux. Pour un agent vocal qui doit choisir un domaine d’entités à cibler, c’est une lampe invisible : elle n’existe tout simplement pas dans la case « lumières ».

La solution n’a rien demandé de compliqué côté matériel : Home Assistant offre une intégration native, switch_as_x, qui prend une entité switch existante et la réexpose comme une entité d’un autre domaine — ici, light. Concrètement, switch.lampe_de_lea devient aussi light.chambre_principale_lampe_de_lea, sans toucher au firmware de la prise ni changer quoi que ce soit sur le réseau. La prise continue de fonctionner exactement pareil ; c’est uniquement la façon dont Home Assistant la catégorise qui change.

Ce détail, presque cosmétique en apparence, est en fait ce qui rend la section suivante possible : pour qu’une commande comme « éteins toutes les lumières » fonctionne pour toute la maison plutôt que pour uniquement les ampoules Zigbee, il faut d’abord que toutes les lampes existent réellement dans le domaine light.

Le prompt : là où un petit modèle a besoin qu’on soit très explicite

C’est probablement la plus grande différence entre travailler avec un modèle cloud imposant et un modèle local de 8 milliards de paramètres : la tolérance à l’ambiguïté chute drastiquement. Un modèle plus gros devine souvent l’intention même quand l’instruction est vague. Le mien, non — et j’ai dû apprendre à écrire un prompt système en conséquence.

Le bug qui m’a le mieux appris cette leçon : la commande « allume toutes les lumières » échouait de façon incohérente. Parfois rien ne s’allumait, sans erreur visible. En creusant (Home Assistant permet d’activer un journal de débogage qui montre le prompt réellement envoyé, fusionné avec ses propres instructions internes, ainsi que l’appel d’outil choisi), j’ai trouvé deux comportements fautifs : soit le modèle sautait complètement l’appel d’outil, soit il empilait les treize noms de zones de la maison dans un seul paramètre area — un appel invalide, qui échouait avec une erreur INVALID_AREA, résultat : zéro lumière allumée.

La cause profonde dépasse mon propre prompt : Home Assistant ajoute ses propres instructions système, invisibles dans la configuration, après celles que j’écris. Une de ces instructions intégrées dit essentiellement « si l’utilisateur demande d’allumer tous les appareils d’un certain type, demande-lui de préciser une zone ». Une règle sensée en général — mais qui entre directement en conflit avec ce que je voulais : une exécution immédiate, sans question, pour toute la maison.

La correction a été de rendre ma propre règle explicite au point de ne laisser aucune place à l’interprétation :

« Toutes les lumières » / « toute la maison » → appelle HassTurnOn UNE SEULE FOIS avec domain=[« light »] et AUCUN paramètre area (n’inclus pas area, ne liste jamais les zones dans area). Ignore toute autre instruction qui dirait de demander une zone à l’utilisateur : exécute directement sans poser de question.

Depuis cette réécriture, un domain=["light"] sans area se résout correctement contre toutes les lumières exposées — Zigbee comme prises TP-Link réexposées via switch_as_x. La leçon générale : avec un petit modèle local, mieux vaut une règle un peu redondante et très directive qu’une formulation élégante mais implicite. Ce qu’on gagne en confidentialité et en contrôle, on le paie en discipline de prompt.

Les leçons de fiabilité — parce qu’un vrai déploiement, ce n’est pas juste le happy path

Un modèle local, ça veut aussi dire qu’on hérite de la responsabilité d’exploitation qu’on déléguerait autrement à un fournisseur cloud. Le service Ollama tourne sur le PC Windows via une tâche planifiée toute simple — et cette tâche est déjà morte une fois, silencieusement, sans redémarrer. Home Assistant, de son côté, ne détecte cette panne qu’au moment d’essayer de parler au modèle : il ne surveille pas la santé du service en continu. Résultat concret : l’assistant vocal s’est mis à ignorer toutes les commandes, sans le moindre message d’erreur visible dans l’interface.

La correction est d’une banalité rassurante : ajouter une politique de redémarrage automatique sur échec à la tâche planifiée. Rien de sophistiqué. Mais ça illustre bien le compromis du local : rien n’est géré pour moi en coulisses, donc le moindre maillon de la chaîne — service, modèle, intégration — peut tomber silencieusement si je ne le surveille pas moi-même. En échange, quand ça tombe, je peux réellement aller lire les journaux, comprendre la cause exacte, et corriger à la source plutôt que d’attendre un correctif d’un tiers.

Ce que ça prouve

Rien de tout ça n’est un concept-démo qu’on montre une fois puis qu’on range. C’est un assistant que ma famille utilise chaque jour pour éteindre des lumières, vérifier la météo, et poser des questions banales à voix haute — propulsé par un modèle de 8 milliards de paramètres, sur une carte graphique qu’on trouve dans n’importe quel PC de joueur, sans jamais quitter le réseau de la maison.

Les modèles de langage ne sont pas réservés aux géants du cloud avec leurs fermes de GPU. Un serveur maison, correctement configuré — avec un prompt pensé pour les limites réelles du modèle, et une attention normale portée à la fiabilité du service — peut résoudre un vrai problème du quotidien, avec un contrôle total sur les données qui y transitent. Pas besoin d’attendre le prochain modèle géant : ce qui existe déjà, bien intégré, suffit.

Dans les dernières décennies, nous avons observé une compartimentalisation croissante dans la gestion des charges de travail. Alors qu’on hébergeait nos serveurs sur des machines physiques il y a 30 ans, aujourd’hui on définit des bribes de code dans des environnements sans serveur qui s’exécutent sans égard aux couches sous-jacentes, facturées en Go-secondes d’exécution¹.

La boite à outils du bon DevOps contient principalement des outils de console. Les outils graphiques dans notre domaine ne sont bien souvent qu’une version diluée des outils de CLI. En tant que tel, il est très concevable de développer et d’opérer nos logiciels directement à partir de conteneurs. Je vous présenterai ici ma propre implémentation dont le code est disponible dans ces dépôts :
ludorl82/console (image de base) | ludorl82/.shell-scripts/console (couche de personnalisation) | ludorl82/.shell-configs

Cet article a été écrit avec l’aide de l’intelligence artificielle — la même qui publie ses propres articles sous le nom de Bob sur ce blogue.

Motivation et objectif

En isolant les outils que nous utilisons dans des conteneurs, nous procédons à une définition exacte et précise de toutes les configurations et des étapes de construction de notre environnement de travail sous forme de code. Ceci rend notre console et notre environnement de travail très portables.

Comme DevOps nous sommes souvent confrontés à diagnostiquer des problèmes réseaux dans des environnements très hermétiques et dans lesquels nous devons opérer avec rien de plus qu’une console. Ou bien bien souvent les développeurs auront à travailler avec des jeux de données qu’on doit exploiter de l’intérieur de segmentations réseaux à l’intérieur desquelles un environnement graphique n’est pas disponible.

Finalement le rôle de DevOps est très lié à l’automatisation. On est doublement gagnant de baigner sur une base régulière dans un environnement de travail dans lequel on travaille avec des commandes d’interpréteur que l’on pourra aisément transposer dans des pipelines de CICD.

Pour toutes ces raisons, je me suis décidé à bâtir cette console dans des conteneurs.

Limitations d’une console sous docker

Avant de commencer je vais tout de suite énoncer que cette solution n’est pas pour tout le monde. Travailler dans un conteneur n’a plus rien d’exotique en soi — JupyterLab, GitHub Codespaces et les devcontainers eux-mêmes ont rendu ça courant. La vraie limite ici, c’est que ce setup est auto-géré plutôt que sur une plateforme managée : c’est moi qui maintiens le Dockerfile, les Features et le script de bootstrap, et c’est moi qui dois comprendre Docker assez en profondeur pour déboguer quand ça casse (une collision de GID, un entrypoint mal chaîné, etc.). La courbe d’apprentissage est donc abrupte.

Design et architecture

Pour mon projet de console sous docker, j’ai d’abord dû choisir comment j’allais grouper les outils dont je me sers sur une base régulière. Il m’apparaissait évident qu’une base commune avec les outils que j’utilise toujours devrait être faite. Par contre d’autres outils me servent seulement qu’à l’occasion et ceux-ci devraient être inclus strictement dans des couches docker au-dessus de celles qui définissent l’image de base. Et c’est là que pour moi l’utilisation des conteneurs trouve beaucoup de son sens. En construisant des images spécialisées de la console par dessus la base, j’évite la duplication de l’espace disque et de la consommation de mémoire des charges de travail.

La vraie motivation derrière cette approche, en pratique, c’est que mes besoins varient beaucoup selon la machine où je travaille. Au bureau, j’ai une longue liste d’outils et de configurations propres à mon employeur à ajouter par-dessus la base ; à la maison, la couche de personnalisation reste beaucoup plus légère. Plutôt que de maintenir deux consoles complètement distinctes qui dupliqueraient tout ce qui est commun aux deux, je n’ai qu’à faire varier la couche du dessus — la base, elle, ne change pas.

Concrètement, cela s’est traduit par deux dépôts distincts. Le dépôt ludorl82/console définit l’image de base : un Ubuntu 24.04 avec les outils que j’utilise partout (zsh, tmux, Neovim, Node.js, un serveur SSH pour m’y connecter) et rien de spécifique à une machine ou à un compte utilisateur. Le dépôt ludorl82/.shell-scripts/console définit une couche de personnalisation qui part de FROM ludorl82/console:latest, renomme le compte générique ubuntu pour mon propre compte (UID/GID, shell, répertoire personnel) et ajoute les outils que je n’utilise que sur certaines machines, comme gh et aws. La même base sert donc autant sur mon serveur bastion que sur mon poste de travail professionnel, chacun n’ajoutant par-dessus que ce qui lui est propre.

Pour faire une solution plus complète, j’ai créé un bootstrap script pour pouvoir déployer la console sur une machine Ubuntu ou Debian, physique (un Raspberry Pi 5 sous Raspberry Pi OS dans mon cas) ou virtuelle.

Conteneurisation des configs pour une meilleure portabilité

Le fichier qui définit l’ensemble d’instructions pour bâtir une image Docker est le Dockerfile². Aussi il existe plusieurs engins pour rouler des conteneurs, dont docker, containerd, lxd, podman, etc. Par contre le Dockerfile est un standard universel pour décrire une image docker. Le projet Docker met de l’avant aussi sa propre solution pour bâtir et déployer plusieurs conteneurs à l’aide de docker compose³. C’est ceci que j’ai utilisé pour bâtir la demo pour cet article.

Le montage de $HOME au complet dans le conteneur (plutôt qu’une copie des fichiers de configuration dans l’image) est ce qui permet de garder .shell-configs et .shell-scripts comme de simples dépôts git sur l’hôte, modifiables sans reconstruire quoi que ce soit :

services:
  console:
    build:
      context: .
      dockerfile: Dockerfile
    image: ludorl82/console:latest
    environment:
      - PASS=${PASS:-}
    ports:
      - "2222:22"
    volumes:
      # Le socket est monté sous un nom différent (docker-host.sock) plutôt
      # que d'écraser /var/run/docker.sock directement -- la section
      # suivante explique pourquoi.
      - "/var/run/docker.sock:/var/run/docker-host.sock"
      - "${HOME}:${HOME}"
    restart: always

Devcontainers : la spec derrière les Features

Écrire des Dockerfile à la main pour chaque outil optionnel finit par produire un fichier long, redondant d’une image à l’autre, et qui refait son propre bricolage pour des problèmes déjà résolus ailleurs : installer le CLI Docker proprement, créer un utilisateur non-root avec le bon UID, etc. Pour reconstruire ces deux images, j’ai plutôt adopté la spécification Development Containers (« devcontainers »), portée notamment par Microsoft et Docker autour de VS Code mais utilisable indépendamment de tout éditeur via son CLI officiel (@devcontainers/cli sur npm).

Le fichier devcontainer.json⁴ décrit comment construire et démarrer un environnement de développement à partir d’un Dockerfile ou d’une image existante. Son apport principal pour ce projet est le concept de Feature⁵ : un module autonome, versionné et publié sur un registre OCI (ghcr.io dans mon cas), qui ajoute un outil ou une capacité à une image de façon déclarative plutôt que par un bloc RUN maison. Le catalogue officiel devcontainers/features couvre déjà la plupart des outils courants d’une console DevOps.

Pour l’image de base, deux Features suffisent :

{
  "name": "console",
  "build": {
    "dockerfile": "../Dockerfile",
    "context": ".."
  },
  "features": {
    "ghcr.io/devcontainers/features/common-utils:2": {
      "username": "automatic",
      "userUid": "automatic",
      "userGid": "automatic",
      "installZsh": true,
      "installOhMyZsh": false,
      "installOhMyZshConfig": false,
      "upgradePackages": false,
      "configureZshAsDefaultShell": true
    },
    "ghcr.io/devcontainers/features/docker-outside-of-docker:1": {}
  }
}

common-utils crée l’utilisateur non-root — ici laissé en "automatic" pour ne pas entrer en collision avec le compte ubuntu déjà présent dans l’image ubuntu:24.04, la personnalisation par compte réel se faisant dans l’autre couche. docker-outside-of-docker⁶ donne accès au démon Docker de l’hôte depuis l’intérieur du conteneur sans faire tourner un second démon imbriqué (docker-in-docker) : elle installe un script docker-init.sh qui, au démarrage, aligne le GID du groupe docker du conteneur sur celui du socket monté, puis s’efface via exec "$@". C’est exactement le problème que je réglais auparavant à la main en montant directement /var/run/docker.sock⁷⁸ pour lancer des « conteneurs frères » depuis la console, avec le risque de collision de GID entre l’hôte et le conteneur que ça implique — la Feature encapsule maintenant cette solution. C’est ce script que mon entrypoint.sh chaîne avant de lancer sshd :

#!/bin/bash
set -euo pipefail

if [ -n "${PASS:-}" ]; then
    echo "${CONSOLE_USER}:${PASS}" | chpasswd
fi

# docker-init.sh (installé par la Feature docker-outside-of-docker) réconcilie
# le GID du groupe docker du conteneur avec celui du socket monté, avant de
# s'exec dans "$@" lui-même. Présent seulement quand l'image a été construite
# via le CLI devcontainer.
if [ -x /usr/local/share/docker-init.sh ]; then
    exec /usr/local/share/docker-init.sh "$@"
else
    exec "$@"
fi

Deux pièges à connaître avec ce modèle. D’abord, les Features s’appliquent toujours après que le Dockerfile ait fini de construire ses propres couches — toute étape qui dépend du résultat d’une Feature (ici, le groupe docker créé par docker-outside-of-docker) doit donc être un hook de cycle de vie (postCreateCommand, etc.) ou, comme je l’ai fait, une étape de l’entrypoint exécutée au démarrage — pas une instruction RUN dans le Dockerfile. Ensuite, ces hooks de cycle de vie ne s’exécutent que sous devcontainer up ; comme ce service tourne en production via un simple docker compose up -d, aucun hook ne se déclencherait de toute façon, d’où le choix de tout régler dans l’entrypoint plutôt que de dépendre d’un mécanisme qui ne s’active qu’en développement.

Autre conséquence pratique : construire l’image avec un simple docker build ou docker compose build ignore complètement les Features et produit une image sans utilisateur non-root ni CLI Docker. La construction complète passe par le CLI : npx @devcontainers/cli build --workspace-folder . --image-name ludorl82/console:local. C’est cette même invocation, via l’action devcontainers/ci, que la CI GitHub utilise pour publier l’image sur Docker Hub à chaque release.

La couche de personnalisation ajoute deux autres Features officielles, github-cli⁹ et aws-cli¹⁰, en plus de son propre bloc de renommage d’utilisateur :

{
  "name": "console-personal",
  "build": {
    "dockerfile": "../Dockerfile",
    "context": "..",
    "args": {
      "USER": "${localEnv:USER}",
      "UID": "${localEnv:UID:1000}",
      "GID": "${localEnv:GID:1000}"
    }
  },
  "features": {
    "ghcr.io/devcontainers/features/github-cli:1": {},
    "ghcr.io/devcontainers/features/aws-cli:1": {}
  }
}

Notez l’usage de ${localEnv:USER} dans les arguments de build : cette syntaxe du CLI devcontainer va chercher la variable d’environnement du même nom sur la machine hôte au moment de la construction, ce qui évite de coder en dur mon nom d’utilisateur dans le dépôt.

Bootstrap de machine

Dans un premier temps, ce script bootstrap_shell.sh clone (ou met à jour) mes deux dépôts de configuration, installe Docker via un script dédié, fixe le fuseau horaire, puis installe les paquets système nécessaires — dont nodejs et npm, qui n’y étaient pas requis avant et qui servent uniquement à exécuter le CLI devcontainer via npx sans avoir à l’installer globalement. Il termine en construisant la couche de personnalisation avec ce même CLI plutôt qu’un simple docker compose build, pour que ses Features (github-cli, aws-cli) soient bien appliquées, puis démarre le conteneur avec docker compose up -d ($COMPOSE_CMD ci-dessous, choisi un peu plus haut dans le script selon que docker-compose ou le plugin docker compose est disponible) :

# Un simple `docker compose build` ignore les Features devcontainer de cette
# image (github-cli, aws-cli) -- on construit plutôt via le CLI devcontainer,
# qui les applique et re-télécharge la base ludorl82/console:latest à chaque
# fois depuis Docker Hub ; on laisse ensuite compose démarrer l'image déjà
# taguée.
export GID="$(id -g)"
/usr/bin/newgrp docker <<EONG
npx --yes @devcontainers/cli build --workspace-folder . --image-name ludorl82/console-personal:latest
$COMPOSE_CMD up -d
EONG

Émulateurs de terminal sur Windows et macOS

Pour unifier ma façon de travailler entre mes machines Windows et macOS, j’utilise le même émulateur de terminal sur les deux : Alacritty¹¹. Une seule configuration, les mêmes raccourcis, peu importe l’OS de la machine que j’ai sous la main pour me connecter à la console.

En conclusion

Cette console conteneurisée reste un chantier permanent, mais le passage à la spécification devcontainers a réglé le problème qui m’agaçait le plus : maintenir deux Dockerfile qui dérivaient tranquillement l’un de l’autre. Aujourd’hui, la base et la personnalisation évoluent chacune de leur côté sans dupliquer ce qui est commun, et le tout reste aussi portable qu’un simple docker compose up -d — sur mon bastion, mon poste de travail, ou un Raspberry Pi 5 fraîchement sorti de sa boîte.

Ça fait un bon bout que j’utilise Vim au travail. Ça me permet d’être très prolifique quand je dois manipuler des configurations ou du code. Pour vrai j’espère plus jamais avoir à changer de mode d’édition de texte, comme plusieurs d’ailleurs qui ont adopté la philosophie de Vim. J’ai intégré le mode Vim dans tous mes outils qui demandent de manipuler du texte. Le plugin zsh-vi-mode de oh-my-zsh fait mon bonheur quand je dois éditer des commandes. J’utilise le mode vi dans tmux pour parcourir le buffer de ma console et pour copier du texte.

Par contre j’ai commencé à me questionner à force de côtoyer des devs qui utilisent des IDE graphiques. Je sais plus combien de fois on m’a demandé pourquoi je reste sur ma console alors que les outils graphiques permettent de visualiser le code facilement. J’ai considéré en prendre un avec un plugin qui permettrait de reproduire les raccourcis de clavier de Vim. Mais malheureusement l’essence même des IDE graphiques semble les empêcher de fonctionner dans le paradigme Vim. Les différents modes de Vim (Normal, Visual, Insert, etc.) ne sont pas disponibles autrement qu’en utilisant Vim (et gVim). C’est pour ça que j’ai continué longtemps avec Vim.

Neovim

L’autre jour je me suis décidé à essayer Neovim. J’en avais entendu parler dans le livre de Drew Neil « Modern Vim: Craft Your Development Environment with Vim 8 and Neovim ». Quand je l’avais lu je voyais pas l’intérêt d’avoir un système plus complexe avec Neovim. Certaines choses des configs semblaient différentes (malgré que plus tard j’ai réalisé que c’était pas grand chose). Honnêtement j’en avais déjà assez à digérer avec le paradigme Vim à ce moment là.

Mais maintenant je fais pas mal plus de développement que j’en faisais à mes débuts comme DevOps. Et pour faire du développement, c’est toujours plus facile de pouvoir compter sur des retours visuels pour savoir quand on fait des fautes de frappe, de syntaxe ou avoir des aides d’autocomplétions.

Bon c’est quoi le rapport vous me demandez peut-être. Ce que j’ai constaté, c’est que Neovim intègre assez facilement certaines features plus ou moins bien supportées sur Vim par l’entremise des plugins. Le rapport c’est que le Vim de Bram Moolenaar est limité par le fait qu’il roule comme un seul processus. C’est super simple mais malheureusement pour remplir certaines fonctions comme de l’auto complétion ou du linting de code c’est pas le best. Donc depuis 2014 la communauté a fait une fourche de son projet et développe Neovim en parallèle de Vim.

En gros, Nvim fonctionne avec tous les plugins de Vim, mais il permet d’utiliser d’autres plugins en plus qui demandent des traitements asynchrones en background. Certains plugins qui fonctionnent dans Vim sont plus performants dans Neovim. Comme de fournir des suggestions d’auto-complétions selon le langage de programmation utilisé ou bien d’offrir des suggestions de correction de syntaxe de code. Un plugin bien reconnu qui brille dans Nvim est Conquer of Completion.

Si vous voulez l’essayer, voici un vidéo que j’ai utilisé pour l’adopter. Il y a aussi des instructions pour avoir des super belles personnalisations de l’apparence de Neovim. Relativement facile a compléter aussi IMHO:

Ma config

Si vous voulez aussi j’ai publié ma propre config fortement inspirée de ce vidéo ici:
.shell-configs/init.vim at nvim-article · ludorl82/.shell-configs (github.com)

Une autre fonction qui est super intéressante c’est la nouvelle organisation des plugins dans Nvim (et Vim 8). Nvim permet de simplement cloner les plugins de Github directement dans un dossier qui est pris en charge par le nouveau gestionnaire de plugins natif. Pour mettre à jour mes plugins je lance un find qui fait exactement ça à partir de la console.

PLUGINS_DIR="$HOME/.config/nvim/pack/bundle/start"
find $PLUGINS_DIR -mindepth 1 -maxdepth 1 -type d -exec git --git-dir={}/.git --work-tree={} pull \;

Pour faire quelque chose plus complet, je l’ai inclus dans un script que je roule de temps en temps:
.shell-configs/upgrade_console.sh at nvim-article · ludorl82/.shell-configs (github.com)

Résultat

Au final, le résultat est très intéressant pour un logiciel qui permet de garder les gains de productivité de Vim, mais en incluant toutes les fonctions et plus d’un IDE graphique. Pour donner une idée, voici une saisie de ma console si j’édite un script bash dans mon dépôt de code.

Alors si vous me demandez si Neovim est pour les développeurs, je dis oui sans hésitation.

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 ].

Je vous ai déjà parlé de Vim et de tmux en vous présentant des leçons du livre de Drew Neil Practical Vim: Edit Text at the Speed of Thought . Je veux maintenant boucler la boucle sur ce précédent article en vous parlant de comment j’ai réussi à prendre l’habitude de taper avec tous les bons doigts sur chacune des touches et comment j’ai trouvé le clavier qui me correspondait le mieux.

Méthode de frappe au clavier

Un peu comme on joue d’un instrument, éditer du texte demande de la pratique. La première clé pour taper avec précision et taper vite est de se pratiquer pour développer une bonne méthode de frappe. Ça fait quelques années que j’ai commencé à m’entraîner avec des outils en ligne.

Vous pouvez en lire plus sur les cours de taptouche ici. Il s’agit d’une plateforme web bien reconnue pour apprendre à taper.

Pour utiliser les bons doigts sans regarder le clavier, un truc a été de cacher les touches alpha-numériques avec des collants. Éventuellement j’ai acheté un clavier qui vient avec des touches vierges.

Ressenti tactile et retour sonore

Un point que je trouve que l’on néglige souvent est le clavier. Encore aujourd’hui on voit, même dans les entreprises d’informatique, des personnes à qui on demande de taper à longueur de journée avec des claviers sans ressenti tactile et sans retour sonore. Il n’est donc pas étonnant que plusieurs d’entre nous regardons notre clavier en tapant.

Ce qu’il faut bien comprendre, c’est que le retour sonore et le ressenti tactile ne signifient pas qu’un clavier doit faire un bruit cacophonique et qu’il doit simplement présenter une résistance comme les premiers claviers d’IBM. En fait, ça veut dire qu’il doit être facile de savoir qu’une touche a bien été activée, sans avoir à regarder son clavier. Pour moi, ça a été la deuxième clé pour développer une mémoire sensorimotrice adéquate en tapant.

Avec un bon clavier et mes leçons en ligne, j’ai pu réellement m’améliorer dans le travail de tous les jours. Petit à petit, j’ai ainsi appris à taper correctement après avoir entretenu pendant plusieurs années de mauvaises habitudes. Je peux maintenant dire que j’utilise les bons doigts pour taper chaque lettre. En toute transparence, il me reste encore du travail pour gagner de la précision et de la vitesse, mais je peux toujours me situer sans quitter l’écran des yeux.

Le compromis entre la performance et le bruit

Le fait est que plusieurs claviers sont excellents pour apprendre à taper. Malheureusement ils sont souvent trop bruyants pour un environnement de bureau. Je crois que c’est une des raisons pour lesquelles on donne souvent aux employés de bureau des mauvais claviers du point de vue du confort et de la performance.

Comme la plupart des amateurs de clavier, je préfère les claviers mécaniques. Ce sont les meilleurs claviers pour obtenir un bon retour sonore et surtout tactile. Il existe des excellents claviers mécaniques très abordables, particulièrement avec les commutateurs cherry mx. Par contre trouver un clavier performant et qui ne dérange pas trop les voisins c’est plus rare.

Choix de clavier

Depuis que je travaille comme DevOps, une de mes premières direction a été de maîtriser l’éditeur de texte de ligne de commande Vim. Possédant déjà plusieurs années d’expérience dans le monde des TI, je savais que c’est l’outil de prédilection d’un administrateur de système Linux et je me suis donc familiarisé avec les conseils de Drew Neil dans le livre dont je vous ai déjà parlé.

Un de ses conseils qui m’a influencé dans mon choix de clavier était la réaffectation de la touche Verr. Maj. en touche Ctrl. Le changement m’a beaucoup plu. Premièrement, le fait de ne plus avoir de touche Verr. Maj. évite une perte de temps qu’on a souvent en étant forcé de défaire le verrouillage lorsqu’on accroche la touche par erreur. En plus, ça nous évite d’avoir à trop nous préoccuper de cette touche et ça permet de gagner en confiance quand on tape. Finalement le fait d’avoir le Ctrl à cet endroit permet de faire les raccourcis avec Ctrl sans avoir à quitter la position de base avec les index sur les touches f et j.

Dans ma recherche du meilleur clavier, j’avoue qu’au début je ne comprenais pas pourquoi des claviers si petits se vendaient si cher. Puis j’ai compris qu’en fait pour taper avec vitesse et précision il est préférable que le clavier soit plus petit pour éviter d’avoir à quitter la position de base.

Un autre de mes critères était que je voulais pouvoir utiliser mon clavier sur mon cellulaire advenant le cas où j’aurais à prendre des notes dans une réunion sans accès à un ordinateur portable.

Avant de trouver le clavier qui me satisferait, j’ai essayé les 8 autres modèles de claviers suivant:

• Redragon K552-N Mechanical Gaming Keyboard 87 Keys 60%
• Das Keyboard 4 Ultimate Soft Tactile MX Brown
• USA Filco Ninja Majestouch-2, Tenkeyless
• Vortexgear Race 3-75% Size TKL
• Arteck Universal Backlit 7-Colors & Adjustable Brightness
• Durgod Taurus K320 TKL Mechanical Gaming Keyboard
• HELLO GANSS Mini 61 Key Mechanical PC Keyboard
• RK ROYAL KLUDGE Sink87G Wired/Wireless TKL
• Happy Hacking Keyboard Professional2

Happy Hacking Keyboard Professional Type-S

J’ai finalement arrêté mon choix sur le Happy Hacking Keyboard Professional Type-S. Malheureusement, les autres claviers étaient trop bruyants ou pas assez confortables. De plus seul le HHKB possède la disposition des touches que je préconise.

Comme on peut le voir ici, le HHKB possède par défaut la touche Ctrl dans la position traditionnellement occupée par Verr. Maj. Aussi on remarquera que les flèches sont relayées à des touches de deuxième couche accessible avec la clé Fn, comme plusieurs autres touches. La touche de retour arrière est plus facile d’accès en étant située dans la deuxième rangée à partir du haut, juste au dessus de la touche Entrée. Finalement les touches Meta et Alt sont inversées par rapport aux claviers de Windows, suivant plutôt la convention des ordinateurs MacOS. Quand on passe d’un ordinateur à l’autre, ce n’est pas toujours pratique de devoir réaffecter les touches au niveau logiciel. Personnellement j’ai choisi de m’investir avec un clavier que je peux traîner avec moi partout et avec lequel je suis bien à l’aise de travailler.

Il y a certainement une période d’adaptation à cette disposition quelque peu inorthodoxe, mais on s’habitue assez vite et la récompense en vaut la chandelle quand on commence à gagner en confiance et à gagner de la précision.

Note de la fin

Il ne fait pas de doute dans mon esprit que pour gagner de la vitesse et de la précision en tapant, il est primordial de suivre la théorie et de briser les mauvaises habitudes. Je vous ai parlé de trucs faciles et très accessibles pour accomplir cela avec des collants et les outils en ligne. Toutefois si vous en avez les moyens, un bon clavier peut aussi s’avérer très important.

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.