Projet : sftpud

Ce week-end je n’étais pas en Allemagne, du coup j’ai voulu pisser du code pour une fois que j’avais le loisir de le faire. J’ai eu l’idée de me lancer un petit challenge : coder quelque chose, n’importe quoi, from zero to github, en 24 à 48h. NOTE: il s’avère que j’ai en fait perdu environ 2h de ma vie à regarder X-Men: Dark Phoenix. Quelle daube. SPOILER ALERT: au final, j’ai mis bout à bout 6h, de zéro à ce que vous trouverez sur Github. L’idée derrière sftpud m’est venu en découvrant ce projet. Je suis tombé dessus hier ou avant-hier et quand j’ai lu le code, j’ai été un peu déçu car je m’attendais à découvrir un code qui m’apprendrait à utiliser du VPN dans AWS sans serveurs, mais il s’avère que le script principal utilise des scripts Python pour lancer une EC2, puis déroule un autre script sh, qui se charge finalement d’installer et de paramétrer OpenVPN sur l’EC2 créée précédemment.

Ansible, PostgreSQL et les extensions

PostgreSQL est un SGBD formidablement puissant et très divers en matière de fonctionnalités. Certains le considèrent d’ailleurs comme le SGBD open source le plus avancé au monde, dixit par exemple le site officiel. En plus de ces fonctionnalités, il comporte un système d’extensions et chacune d’entre elles peut être déployée sur une base de donnée. Notamment via Ansible :-) Pour cet article, j’ai monté l’instance de test via terraform, histoire de pratiquer un peu. Monter l’infra via terraform et déployer la couche logicielle via Ansible, c’est un peu une best practice que j’essaie d’appliquer de plus en plus. L’architecture du projet est la suivante, générée via ansible-init :

Edito : 03/08/2019

Voilà deux semaines que je n’ai plus rien écrit. Il m’a donc semblé de circonstance, avant de publier de nouveaux articles, de vous proposer un petit édito rapide pour vous narrer mes dernières aventures. J’ai commencé mon nouveau job il y a deux semaines. Donc, comme je ne vous l’ai pas encore dit, je suis maintenant Team leader de l’équipe ops de Lyon chez Smile. Ce job a plusieurs facette puisque je conserve l’aspect tech du job, à laquelle s’ajoute maintenant une partie management, partie qui s’avère d’ailleurs passionnante. Deux semaines donc que j’y suis et je trouve ça vraiment énorme : le job est génial, l’équipe est top, les outils/workflows sont juste magiques, il y a du logiciel libre de partout, les projets sont hyper intéressants et dynamisants… Du cloud, du devops, une bonne ambiance : mon paradis, je dirais !

Adista, la fin

Hello ! Hier soir, après 5 ans et 7 mois de bons et loyaux services, j’ai quitté mes fonctions d’administrateur IT open source dans la société Adista pour voguer vers de nouvelles aventures. J’en garderai toujours un excellent souvenir, c’était une bonne boîte. J’y ai appris énormément de choses techniques, et j’y ai grandi humainement grâce à un management de qualité ;-) Une mention toute spéciale à l’équipe du RUN open source de Saint-Étienne qui fût ma famille pendant ces années. Les amis, bosser avec vous, tant dans les jours calmes que dans les tempêtes, fût une expérience hors du commun et un privilège.

Juju : le verdict

J’en ai parlé sur les réseaux sociaux, je me suis finalement décidé à tester Juju. Au départ, j’étais même très enthousiaste et je pensais faire un article-tuto sur la configuration et l’utilisation de Juju et de conjure-up. Mais quelques heures de tests, cafouillages, scratch, d’autres tests, me voilà moins enthousiaste, disons plus mesuré. Il m’est donc apparu qu’il serait plus profitable de faire un article sur mon ressenti et mon retour, et c’est ce que je vous propose ci-dessous. Qu’est-ce que c’est Juju est un outil de configuration/déploiement automatique de stack logicielles. Il permet de déployer via des charms des ensembles de composants dans un cloud de votre choix parmi les suivants:

Terraform : configurer un provider LXD

Ces derniers temps, je m’intéresse de plus en plus au concept d'infrastructure as code, comme vous avez pu le ressentir dans mes articles. C’est donc tout naturellement que je commence à aborder Terraform. Il va me servir à construire l’infrastructure, tandis qu’Ansible me permettra de la piloter. Terraform peut exploiter de nombreux providers, dont une liste se trouve ici pour les providers officiels, c’est à dire développés et maintenus par Hashicorp et ici pour ceux qui le sont pas. On appelle ces derniers les community providers. Mon premier provider est tout naturellement LXD, qui fait partie des community providers. Il faut donc l’installer autrement que via terraform.

LXD, Ansible & DNSMasq

Quand on a un porte-conteneur LXD qui est piloté via ansible, c’est qu’on aime bien automatiser les choses. On peut avoir disons, une tâche de création de conteneurs, mais il faut encore mettre à jour la configuration SSH avec les hosts créés au fur et à mesure. Evidemment, cela peut se faire avec un playbook qui va écrire la configuration SSH au moyen de récupération de variables… C’est déjà lourd. La véritable solution résiderait plutôt dans le fait de ne créer la configuration SSH qu’une seule fois et ne plus la modifier. C’est possible avec DNSmasq et un peu de configuration LXD.

i3 : Mon DE préféré

i3 est un desktop manager léger mais pourtant extrêmement fonctionnel dont la principale qualité est de proposer un tiling parfait. C’est à dire qu’en tout temps, vos fenêtres ne se superposent pas. Vous disposez néanmoins de bureaux virtuels pour pouvoir être efficace au maximum et laisser certaines fenêtres (au hasard, vscode) utiliser tout votre écran. Il vient avec une configuration plutôt simpliste puisque située entièrement dans un fichier plat : ~/.config/i3/config. De base, tout se fait via la touche nommée $mod dans la nomenclature i3, c’est à dire soit Alt, soit Win, cela est choisi au premier démarrage du DE.

Objectif 2019 : Finally, serverless (1)

Dans cet article, j’expliquais en quoi une architecture serverless était mon objectif pour l’année 2019 et où est-ce que j’en étais. Voici un nouvel article sur mon avancement. Dans l’article mentionné précédemment donc, j’expliquais le workflow pour lancer un conteneur Docker dans Fargate. Je vais détailler ici de tout le workflow ou presque à savoir : Créer un référentiel Docker ECR Y pousser son image Créer un cluster ECS (Fargate) Créer une définition de tâche qui se sert de mon image Créer un service associé à cette définition de tâche Et ensuite ? Dans cet article, je vous propose d’étudier chacune des premières étapes pour vous guider à travers ce workflow afin de vous expliquer comment j’y suis parvenu.

Une note sur web_cv

Comme promis dans l’édito précédent, je vais vous présenter ici mon projet web_cv, ce que c’est, où ça en est et quel est son objectif. Si vous me suivez un peu, vous connaissez sans doute mon cv en ligne. Mais voilà, il est vieillissant, en PHP, et surtout, il est statique. C’est à dire qu’il n’y a aucune base de données derrière. Chaque fois que je rajoute une compétence ou un diplôme, c’est un array ou un champs de plus dans le code PHP. Je commit, puis je met à jour la DocumentRoot sur le conteneur via une tâche Ansible. Pas très 2019, tout ça.