IRONSTACK : Automatisation, validation applicative profonde et CI/CD Local pour infrastructures sécurisées.

 

⚙️ Bâtir un Framework d'Automatisation Hardened Sans Cloud : Les Coulisses d'IRONSTACK 

À l'ère du tout-cloud, une idée fausse persiste : une infrastructure moderne, agile et hautement automatisée devrait nécessairement dépendre d'un fournisseur managé tiers (AWS, Azure ou GCP). Pourtant, dans les secteurs à fortes contraintes de sécurité où la souveraineté des données, l'isolation réseau et la conformité GRC sont absolues le cloud n'est tout simplement pas une option.

Pour répondre à ce cas d'usage critique, j'ai relevé un défi de 3 jours : concevoir et déployer IRONSTACK, une mini-production On-Premise durcie dotée d'un orchestrateur intelligent et d'une validation de santé automatisée, le tout tournant entièrement sur du hardware local (Homelab).

Pour ce projet j'ai construit l'infrastructure et la couche de contrôle logiciel qui permettent de la valider et de la déployer de manière ultra-fiable.

🧭 Contexte et Principes d'Architecture 

Dans les environnements hautement sécurisés, le déploiement doit être déterministe, isolé et auditable. L'architecture d'IRONSTACK a été pensée de manière pour limiter la surface d'attaque et garantir l'étanchéité des flux :

Client  ──► [ Nginx Ingress (Port 8080) ] ──► [ Dockerized Services ] ──► [ PostgreSQL DB ]

                          ▲                             │

                          └─────── [ Python Orchestrator ] ─────┘

                                   (Health & Logic Audit)

 Les piliers du durcissement (Hardening) Isolation  

• Les services applicatifs tournent dans des conteneurs Docker strictement confinés sur un hôte Linux (Ubuntu/Debian) épuré, où les services inutiles sont coupés et l'accès SSH n'est autorisé que via des clés privées avec un pare-feu (ufw) restrictif.
• Contrôle des flux (Ingress) : Un proxy inverse Nginx centralise le trafic, gère le routage vers les services et standardise la collecte des logs d'accès.
• Persistance souveraine : Déploiement de PostgreSQL dans un conteneur isolé utilisant des volumes Docker persistants pour assurer le contrôle total et la survie des données stockées.

🧠 La Couche de Contrôle Logiciel infra_manager.py 

Pour IRONSTACK,J'ai développé une véritable Suite d'Outillage (Tooling Suite) en Python 3.12 agissant comme le cerveau de la pile.

Le script infra_manager.py lit un blueprint d'infrastructure (config.yaml) et s'interface directement avec l'API Docker via docker-py.

La touche "Pro" : L'Audit Applicatif Réel (SQL Handshake) 

La plupart des orchestrateurs de base se contentent de vérifier si le conteneur Docker est marqué comme Running. IRONSTACK va plus loin. L'orchestrateur effectue un test de santé applicatif profond (Health-Check) : il initie une poignée de main SQL réelle pour s'assurer que la base de données accepte activement les connexions applicatives avant de déclarer la production opérationnelle.

La gestion des erreurs est robuste, le code est entièrement documenté et commenté en anglais (standard obligatoire en environnement international), et l'utilisation de la bibliothèque standard logging remplace les print naïfs par des traces horodatées exploitables :

2026-04-27 14:10:00 [INFO] IRONSTACK_CORE: ✔ [DOCKER] postgres_container est opérationnel.

2026-04-27 14:10:00 [INFO] IRONSTACK_CORE: ✔ [DB] PostgreSQL accepte les connexions SQL.

2026-04-27 14:10:00 [INFO] IRONSTACK_CORE: ✔ [DOCKER] nginx_ingress est opérationnel.

2026-04-27 14:10:00 [INFO] IRONSTACK_CORE: 🚀 RÉSULTAT : Infrastructure validée et prête pour la production.

 RÉSULTAT : Infrastructure validée et prête pour la production.

 🚀 Industrialisation et Pipeline CI/CD 100% Local C'est ici que réside la vraie force du projet : prouver qu'on peut appliquer le meilleur de la philosophie DevOps/GitOps sans dépendre de solutions SaaS ou Cloud.

Pour ce faire, j'ai installé et configuré un GitHub Actions Self-Hosted Runner s'exécutant localement sur la machine hôte. Le workflow automatisé (.github/workflows/main.yml) sécurise chaque commit selon 3 étapes clés :

Linting & Qualité du code : Analyse statique de la syntaxe Python pour éliminer les bugs avant l'exécution.

Deterministic Build : Construction automatique de l'image Docker de notre application.

Continuous Deployment (CD) : Déploiement automatisé et redémarrage à chaud sur le hardware local, suivi immédiatement de la routine de validation de notre orchestrateur Python.

Structure modulaire du projet 

IRONSTACK/

├── .venv/                  # Environnement virtuel Python isolé

├── infra_manager.py        # Logique d'orchestration centrale

├── config.yaml             # Blueprint de configuration de l'infrastructure

├── requirements.txt        # Dépendances (docker-py, PyYAML, psycopg2-binary)

├── nginx/                  # Configuration du Proxy Ingress Durci

└── db/                     # Définition du service persistant PostgreSQL

Obsession de la Qualité et de la Fiabilité 

 En intégrant du linting, de la gestion d'erreurs structurée, du logging industriel et des pipelines d'intégration continue, permet un DevOps mindset mature appliqué à l'infrastructure.

Réalité Technique 

Le projet propose des étapes claires de durcissement des permissions, une isolation stricte via environnement virtuel Python (.venv) et un système qui tourne sur du vrai hardware.

Évolutions futures Pour pousser l'expérience encore plus loin, l'architecture d'IRONSTACK est prête à accueillir une couche d'observabilité visuelle via un troisième conteneur dédié comme Portainer pour la gestion visuelle des ressources ou Grafana pour le monitoring de l'état de santé du système.

📂 Explorer le Code Source Le projet complet, le code de l'orchestrateur, les fichiers de configuration de services ainsi que le guide complet de déploiement étape par étape sont disponibles en accès libre :

👉 Découvrir le dépôt GitHub d'IRONSTACK : https://github.com/jeanlucndato/IRONSTACK-Hardened-On-Prem-Automation-Framework