Floci : l’émulateur AWS local open source sans compte

La semaine dernière, un client m’appelle. Panique totale. Son pipeline CI crache des erreurs Lambda depuis le mardi, et il ne comprend pas pourquoi. Dix minutes plus tard, j’ai la réponse : LocalStack a changé ses règles, le compte gratuit ne suffit plus pour son usage. Autant dire que je l’avais senti venir, ce coup-là. Depuis mars, l’émulateur AWS local le plus connu du marché réclame un compte, un jeton, et interdit l’usage commercial sur sa formule gratuite. Pour un indépendant comme moi qui fait tourner des tests S3 et DynamoDB sur son vieux portable du boulot, c’est le genre de nouvelle qui donne envie de jeter le clavier par la fenêtre.

Et puis Korben a parlé de Floci. Un emulateur aws local sous licence MIT, sans compte, sans jeton, qui reprend carrément le port 4566, les variables d’environnement et les scripts d’init de LocalStack. J’ai testé. Je vous raconte, y compris le piège qui m’a fait perdre une heure un vendredi soir.

Floci, l’émulateur aws local qui ne vous demande pas votre carte d’identité

Je ne suis pas certain à 100% que les gens de LocalStack aient mesuré l’ampleur du retour de bâton, mais d’après mon expérience en atelier, quand tu taxe brutalement une communauté de devs fauchés, tu la retrouve trois mois plus tard en train de forker ton outil. Floci, c’est exactement ça, mais en version assumée et propre. Licence MIT. Aucun télémétrie, aucun appel à la maison, aucun token à coller dans un fichier YAML à 23h un dimanche.

Le projet reprend volontairement la compatibilité avec LocalStack. Et là, franchement, c’est du boulot intelligent. Le port 4566 par défaut, les variables comme AWS_ENDPOINT_URL, les scripts placés dans /etc/localstack/init/ready.d/… Tout ce que vous avez écrit pour LocalStack, vous le recopiez tel quel, et ça tourne. Mine de rien, ce seul point justifie à lui tout seul de basculer, parce que personne n’a envie de réécrire sa CI un samedi matin.

Alors oui, ce n’est pas non plus un clone parfait. Il manque des services. Plein de services, même. Mais pour S3, DynamoDB et Lambda, ce qui couvre 80% de mes besoins de test, ça marche. Et ça marche sans que j’aie à remplir un formulaire avec mon adresse mail pro.

Ce que Floci ne fait pas (et qu’il faut savoir avant de s’emballer)

Un émulateur, ce n’est pas AWS. C’est un mec qui imite AWS au karaoké. Il connaît les paroles, il a la bonne gestuelle, mais il ne sera jamais la vraie chanteuse. Donc oubliez IAM fin, oubliez CloudFront, oubliez à peu près tout ce qui touche au réseau et aux politiques de sécurité avancées. Floci se concentre sur les services de dev basiques, ceux dont on a besoin pour valider qu’un bout de code déclenche bien une écriture S3 ou une insertion DynamoDB.

Et pour être honnête, c’est exactement ce qu’on lui demande.

Installation : dix minutes, un café, et c’est plié

Je vais vous éviter les tutos interminables. Voilà comment je l’ai installé sur ma machine de test, une Debian qui a vu des choses que vous ne voulez pas imaginer.

• Récupération du binaire ou de l’image Docker depuis le dépôt officiel du projet
• Lancement sur le port 4566, comme LocalStack, histoire de ne rien casser dans les scripts existants
• Variables d’environnement pointant vers http://localhost:4566 pour l’endpoint AWS
• Credentials bidon (test / test), comme avec LocalStack, ça passe sans broncher

Sur Windows, évidemment, ça a été une autre histoire. Parce que Windows a encore tout cassé avec sa dernière MAJ, comme d’habitude. Le chemin des volumes Docker qui saute, WSL qui décide de plus voir le port, un pare-feu qui se réveille en pleine nuit pour bloquer le 4566… Bref. Si vous êtes sur Windows, prévoyez le double de temps, c’est le tarif habituel.

Sur Linux et Mac, en revanche, ça démarre en cinq secondes. Pas de compte, pas de token, pas de formulaire. Vous lancez, vous codez.

Le test S3 qui m’a rassuré

Premier test : créer un bucket, y déposer un fichier, le relire. Rien de fou. Sauf que j’ai juste copié-collé mon vieux script LocalStack, changé zéro ligne, et que ça a marché du premier coup. Du coup, j’ai fait le malin. J’ai lancé DynamoDB, créé une table avec une clé de partition, inséré trois objets. Nickel. Puis Lambda, avec un petit handler Python qui écrit dans le bucket S3. Et là, ça a tourné aussi.

À ce stade, je me suis dit que c’était trop beau. J’avais raison.

Le piège du volume de données qui change de place

Voilà le truc que personne ne vous dit, et qui m’a coûté une bonne heure de ma vie un vendredi soir. Avec LocalStack, les données persistent dans un volume bien connu, que tout le monde monte au même endroit, et qu’on retrouve les yeux fermés. Floci, lui, a décidé de déplacer ce volume. Autrement dit, si vous montez votre ancien volume LocalStack en pensant retrouver vos buckets et vos tables, vous allez trouver un dossier vide et une envie soudaine de vous reconvertir dans la boulangerie.

Ce n’est pas dramatique, hein. Une fois qu’on sait où ça vit, on ajuste le docker-compose.yml et on repart. Mais si vous migrez un projet existant, testez bien la persistance avant de balancer ça en prod, parce que perdre ses données de test en pleine session de debug, c’est le genre d’expérience qui marque.

• Vérifiez le chemin du volume dans la doc du projet avant de monter l’ancien
• Faites un test d’écriture S3, redémarrez le conteneur, relisez l’objet
• Si les données disparaissent, c’est que vous montez le mauvais chemin, pas que Floci est cassé

Je ne suis pas certain à 100% que ce choix soit volontaire ou juste un oubli de jeunesse, mais dans les deux cas, notez-le quelque part. Ça vous évitera de m’appeler un vendredi à 19h.

Faut-il vraiment quitter LocalStack ?

Là, je vais être tranché. Pour un indépendant, une petite équipe, un dev qui bricole le soir, la réponse est oui. LocalStack a choisi de monétiser son outil, c’est son droit, mais il l’a fait en fermant l’usage commercial de la formule gratuite et en imposant un compte. Autant dire que la promesse « open source » a pris un sérieux coup dans l’aile. Floci arrive avec une licence MIT, pas de compte, pas de token, compatible avec ce que vous avez déjà écrit. Pour moi, le match est plié.

Pour une grosse boîte avec des besoins avancés sur IAM, Step Functions, ou des services exotiques, c’est une autre histoire. LocalStack reste plus complet. Il faudra payer, mais parfois payer pour du support et de la couverture de services, c’est justifié. Chacun voit midi à sa porte.

Mine de rien, ce qui me plaît dans Floci, c’est le signal envoyé. Un projet qui dit « on reprend le port, les variables, les scripts, et on ne vous demande rien », c’est une claque à la concurrence. Et c’est exactement ce que la communauté attendait après l’annonce de mars.

Mon verdict de technicien

Floci n’est pas parfait. Il manque des services, le volume de données change de place, la doc est encore jeune. Mais pour un emulateur aws local de test, il fait le job, sans friction, sans compte, sans jeton. Et ça, pour un indépendant qui teste son code Lambda à 23h dans son salon, ça n’a pas de prix.

Si vous voulez creuser, jetez un œil à l’article original de Korben qui m’a mis sur la piste : Floci, l’émulateur AWS open source qui tourne en local. Et si vous tombez sur le piège du volume, vous saurez à qui vous adresser. Probablement pas à moi un vendredi soir.

Source : article original

Please follow and like us: