Newer
Older
Massiles Ghernaout
a validé
Ce dépôt contient une petite infrastructure Docker Swarm capable de bruteforcer des hash MD5 de manière scalable, ainsi qu’une application web pour piloter et monitorer le cluster.
### Sous-projets
- **backend** : API Node.js/Express pour gérer les jobs de bruteforce, l’état du cluster, et le scaling des workers.
- **worker** : service de bruteforce MD5 (conteneurs réplicables dans le Swarm).
- **frontend** : application React permettant d’envoyer des hash, choisir les modes *gentil/normal/agressif* et visualiser l’état du cluster.
- **infra** : configuration Docker Swarm (stack) et scripts éventuels.
- **CI** : workflows d’intégration continue (fichier `.gitlab-ci.yml`).
### Prérequis
- Docker et Docker Swarm initialisé (`docker swarm init`).
- Node.js (pour le développement local du backend et du frontend).
Massiles Ghernaout
a validé
### Auto-scaling
Massiles Ghernaout
a validé
Un **scaler** tourne dans le processus du backend. Il lit périodiquement la file Redis (`jobs:pending`) et le nombre de workers, puis ajuste le nombre de réplicas du service worker Swarm entre un min et un max configurables. Les seuils sont basés sur la charge (jobs par worker) : scale up si (jobs en attente / workers) dépasse un seuil, scale down si ça tombe en dessous d’un seuil plus bas (et qu’aucun job n’est en cours).
Massiles Ghernaout
a validé
Variables d’environnement (optionnelles, sur le service `api_backend`) :
| Variable | Défaut | Description |
|----------|--------|-------------|
| `SCALER_ENABLED` | `true` | Mettre à `false` pour désactiver le scaler (ex. dev local sans Swarm). |
| `SCALER_INTERVAL_MS` | `10000` | Période entre deux évaluations (ms). |
| `SCALER_MIN_REPLICAS` | `1` | Nombre minimum de workers. |
| `SCALER_MAX_REPLICAS` | `10` | Nombre maximum de workers. |
Massiles Ghernaout
a validé
| `SCALER_SCALE_UP_WHEN_JOBS_PER_WORKER_ABOVE` | `4` | Scale up si (jobs en attente / workers) ≥ cette valeur. |
| `SCALER_SCALE_DOWN_WHEN_JOBS_PER_WORKER_BELOW` | `1` | Scale down si (jobs en attente / workers) ≤ cette valeur (et aucun job en cours). |
Massiles Ghernaout
a validé
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
---
### Déploiement via Docker Swarm (stack)
1. Construire les images localement (ou via la CI) :
- `docker build -t md5-swarm-backend:latest ./backend`
- `docker build -t md5-swarm-worker:latest ./worker`
- `docker build -t md5-swarm-frontend:latest ./frontend`
2. Initialiser Swarm si besoin :
- `docker swarm init`
3. Déployer la stack :
- `cd infra`
- `docker stack deploy -c stack.yml md5-swarm`
4. Accéder à l’application :
- Backend : `http://localhost:8080`
- Frontend (proxy Nginx dans le conteneur) : `http://localhost:5173`
La stack crée un service Redis, un backend qui gère la file de jobs dans Redis, un worker scalable pour le bruteforce, et un frontend pour piloter le tout.
---
### Tests & couverture
- **Tests backend** :
- `cd backend`
- `npm test`
- Les tests utilisent le runner intégré de Node.js (`node --test`) avec la collecte de couverture activée.
- **CI GitLab** :
- Le job `build-and-test` dans `.gitlab-ci.yml` exécute les tests backend, le build frontend et extrait le pourcentage de couverture à partir du rapport de Node.
- Le badge en haut de ce README reflète la couverture de la branche par défaut.
---
### Licence
Ce projet est distribué sous licence MIT. Voir le fichier `LICENSE.txt` pour plus de détails.
---
- Durcir la configuration de sécurité (CORS plus restrictif, `helmet`, etc.).
- Ajouter davantage de tests (notamment sur le frontend).
- Documenter en détail les endpoints de l’API et les scénarios d’utilisation côté UI.