miniblue est un émulateur Azure local, open source, qui promet de créer et tester des ressources Azure sans compte cloud. Après un vrai essai en sandbox, mon verdict est simple : ça vaut le coup pour prototyper des appels ARM et des services applicatifs courants, mais il faut accepter des limites nettes sur l’authentification, Docker et la fidélité à Azure.
miniblue, c’est quoi ?
miniblue se présente comme un équivalent Azure de LocalStack, mais avec une approche plus petite : un binaire Go, deux ports locaux, pas de compte Microsoft, pas de tenant réel. Le serveur expose une API HTTP sur le port 4566 et un endpoint HTTPS sur le port 4567 pour la partie metadata utilisée par Terraform.
L’idée est pratique pour les devs qui écrivent du code contre Azure, mais ne veulent pas dépendre d’un abonnement cloud à chaque test. On peut créer un groupe de ressources, stocker un secret Key Vault, écrire un blob, insérer un document Cosmos DB, puis tout jeter.
Dans le README, le projet annonce 27 services. Dans mon run, l’endpoint de santé en déclarait 29, dont Resource Groups, Blob, Table, Queue, Key Vault, Cosmos DB, Service Bus, Functions, DNS, Event Grid, App Configuration, PostgreSQL, MySQL, SQL, Redis, ACI, AKS, ACR, Load Balancer et Application Gateway.
| Point testé | Résultat observé |
|---|---|
| Langage | Go 1.26 |
| Installation testée | Build depuis le dépôt cloné |
| API locale | HTTP 4566, HTTPS 4567 |
| Services actifs | 29 annoncés par /health |
| Stockage d’état | Mode fichier avec persistance locale |
| Docker dans ma sandbox | Non disponible, ACI et AKS en mode limité |
Installation de miniblue
J’ai cloné le dépôt GitHub dans /tmp, lu le README, le go.mod, le Makefile, les exemples Python et Terraform. Le projet se compile avec Go 1.26. Ma sandbox n’avait ni Go, ni Docker, ni Terraform installés au départ, donc j’ai téléchargé Go 1.26 dans un dossier temporaire, puis j’ai compilé les deux binaires du projet.
Les commandes importantes étaient :
git clone https://github.com/moabukar/miniblue /tmp/miniblue
cd /tmp/miniblue
go build -ldflags="-s -w" -o /tmp/miniblue-test/bin/miniblue ./cmd/miniblue
go build -ldflags="-s -w" -o /tmp/miniblue-test/bin/azlocal ./cmd/azlocal
/tmp/miniblue-test/bin/miniblue --version
Le binaire a répondu miniblue v0.7.0-2-g543d173. Le CLI azlocal liste des commandes proches de l’Azure CLI : group, keyvault, storage, network, cosmosdb, servicebus, appconfig, functionapp, dns, eventgrid, acr, postgres, redis, sql, mysql, aci, aks, containerapp, table, queue, reset et health.
J’ai lancé le serveur avec la persistance fichier activée. Les logs sont utiles : miniblue indique où il met son certificat, confirme l’API HTTP, puis prévient quand Docker n’est pas disponible. Dans mon environnement, les conteneurs ACI étaient donc simulés seulement côté ARM, et AKS restait en backend stub.
miniblue à l’usage
Pour ne pas faire un simple test de démarrage, j’ai exécuté deux chemins.
Premier chemin : le CLI azlocal. J’ai demandé l’état du serveur, créé un groupe de ressources, créé un compte de stockage, tenté un conteneur et un blob, puis stocké un secret Key Vault. La santé du serveur était bonne : status: running, service_count: 29.
Voici une version courte des commandes utilisées :
azlocal health
azlocal group create --name scout-rg --location westeurope
azlocal storage account create --resource-group scout-rg --name scoutstore
azlocal storage container create --account scoutstore --name reports
azlocal keyvault secret set --vault scoutvault --name db-password --value not-a-real-secret
azlocal keyvault secret show --vault scoutvault --name db-password
Ce que ça a produit : un groupe de ressources avec provisioningState: Succeeded, un compte de stockage avec endpoints Blob, File, Queue et Table, puis un secret Key Vault relu immédiatement avec sa valeur. C’est exactement le genre de boucle qui aide en développement local.
Mais j’ai aussi vu une limite concrète : les commandes Blob via azlocal storage container create et azlocal storage blob upload ont renvoyé AuthenticationFailed. Ce n’est pas un blocage total du moteur Blob, car l’exemple Python du dépôt passe par des appels HTTP directs et réussit à créer un conteneur, écrire config.json, puis relire son contenu JSON. La limite observée est donc plutôt dans le chemin CLI Blob avec signature ou authentification, au moins dans ce contexte de test.
Deuxième chemin : l’exemple Python fourni par le dépôt. Après installation de requests dans un venv temporaire, j’ai lancé examples/python/example.py. Là, le scénario est plus parlant : création d’un Resource Group, stockage et lecture d’un secret Key Vault, écriture et lecture d’un blob JSON, puis insertion et récupération d’un document Cosmos DB.
La sortie finale disait : All calls went to miniblue, not real Azure. Les métriques du serveur confirmaient les requêtes, avec un backend de stockage fichier et 24 requêtes au moment de la mesure.
Est-ce que miniblue marche vraiment ?
Oui, pour une partie très utile du besoin. Le serveur démarre vite, expose un endpoint de santé lisible, garde un état local, répond à des appels HTTP proches d’Azure, et permet de vérifier du code applicatif sans toucher au cloud.
J’ai aussi lancé un test ciblé du dépôt :
go test ./tests -run TestHealth -v
Résultat : le test TestHealthEndpoint passe. Les logs rappellent toutefois la même limite Docker : ACI est en mode stub et AKS ne passe pas en vrai backend Kubernetes sans Docker.
Pour un freelance sécu ou DevOps, la nuance est importante. miniblue accélère les tests locaux, les pipelines CI et les démos, mais il ne remplace pas un staging Azure pour valider IAM, réseau, certificats, politiques ou comportements exacts de services managés.
Ce que j’aime dans miniblue
J’aime le format binaire unique. Pas besoin de monter une grosse stack pour tester quelques appels. C’est agréable quand on écrit des tests d’intégration qui doivent tourner vite en CI.
J’aime aussi le CLI azlocal. Même s’il n’est pas parfait, il rend le produit concret tout de suite. Pour créer un groupe de ressources ou poser un secret Key Vault, on n’a pas besoin d’écrire un client maison.
Autre bon point : les exemples sont simples. L’exemple Python ne fait pas semblant. Il écrit vraiment dans plusieurs services et relit les valeurs. Pour évaluer un outil de dev local, c’est beaucoup plus utile qu’une démo marketing.
Enfin, les logs sont francs. Quand Docker manque, miniblue le dit. Quand le backend AKS n’est pas réel, il le dit. Cette honnêteté aide à éviter les faux positifs.
Les limites de miniblue
La première limite est la fidélité. Certains services sont des représentations ARM ou des mocks utiles, pas des backends complets. Pour valider une logique métier, c’est souvent suffisant. Pour valider une posture de sécurité Azure, ce n’est pas suffisant.
La deuxième limite est l’écart entre chemins d’usage. Dans mon test, le Blob via exemple Python a fonctionné, mais le Blob via azlocal a échoué avec AuthenticationFailed. Un dev peut contourner avec des appels directs, mais ça mérite d’être durci si le CLI devient l’interface principale.
La troisième limite est la dépendance à Docker pour certains usages réalistes. Sans Docker, ACI et AKS restent limités. Dans une CI sans privilèges conteneur, il faudra donc bien choisir les services testés.
Enfin, le projet est jeune. Le README parle de 27 services, l’API de santé en annonce 29, et certaines commandes méritent plus de messages d’aide. Rien de rédhibitoire, mais il faut le prendre comme un outil en évolution.
Faut-il adopter miniblue ?
Mon verdict : essayer, clairement. Adopter en CI pour des tests applicatifs ciblés, oui, si vos besoins Azure sont proches des services déjà bien couverts. Passer votre chemin si vous cherchez une simulation exacte d’Azure, surtout sur IAM, réseau avancé ou Kubernetes réel.
Pour une équipe plateforme ou un freelance DevOps, miniblue réduit le coût et la friction des tests locaux. Je l’utiliserais comme filet rapide avant des tests plus lourds sur un vrai abonnement Azure.
Le bon usage : écrire des tests qui créent quelques ressources, posent des secrets, manipulent des blobs, valident des payloads Cosmos DB, puis réinitialisent l’état. Le mauvais usage : croire qu’un passage vert sur miniblue garantit un déploiement Azure réel.
FAQ
miniblue remplace-t-il Azure en local ?
Non. miniblue remplace une partie des appels Azure pour développer et tester plus vite. Il ne reproduit pas toute la plateforme Azure ni ses garanties de sécurité.
Peut-on utiliser miniblue sans compte Azure ?
Oui. C’est même son intérêt principal : les credentials sont locaux et les appels restent sur la machine de dev ou la CI.
miniblue est-il prêt pour la CI ?
Oui pour des tests ciblés et rapides, surtout autour des API applicatives. Il faut toutefois documenter les services réellement utilisés et garder des tests de staging sur Azure pour les comportements critiques.