auto_clea
This commit is contained in:
4NK Dev
parent
bc9bd7b92a
commit
4dad51241c
@ -20,3 +20,6 @@ Voir `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `SECURITY.md`.
|
||||
## Licence
|
||||
|
||||
Voir `LICENSE` (MIT).
|
||||
|
||||
### Documentation centralisée
|
||||
- Voir `/home/debian/4NK_env/docs/sdk_storage/`
|
||||
|
||||
@ -1,35 +0,0 @@
|
||||
# Améliorations Récentes - SDK Storage
|
||||
|
||||
## Date: 20 Septembre 2025
|
||||
|
||||
### 🔧 Améliorations Majeures
|
||||
|
||||
#### 1. Installation des Outils Système
|
||||
**Ajouté dans le Dockerfile:**
|
||||
```dockerfile
|
||||
RUN apt-get update && apt-get upgrade -y && \
|
||||
apt-get install -y ca-certificates dnsutils jq curl git wget telnet npm coreutils && \
|
||||
npm install -g wscat && \
|
||||
rm -rf /var/lib/apt/lists/* /root/.npm
|
||||
```
|
||||
|
||||
#### 2. Optimisation de l'Image
|
||||
- Mise à jour des packages système
|
||||
- Installation des outils de diagnostic
|
||||
- Nettoyage des caches pour réduire la taille
|
||||
|
||||
#### 3. Configuration des Services
|
||||
- Port: 8081 (mappé sur 8081)
|
||||
- Healthcheck: Vérification de la connectivité
|
||||
- Logs: Niveau optimisé
|
||||
|
||||
### 📊 État Actuel
|
||||
- **Statut:** ✅ Running
|
||||
- **Port:** 8081 accessible
|
||||
- **Outils:** Tous les outils système installés
|
||||
- **Logs:** Optimisés
|
||||
|
||||
### 🔄 Prochaines Étapes
|
||||
- Tests de connectivité storage
|
||||
- Monitoring des performances
|
||||
- Optimisations supplémentaires
|
||||
@ -1,40 +0,0 @@
|
||||
## Analyse détaillée
|
||||
|
||||
### Périmètre
|
||||
|
||||
Service Rust `sdk_storage` (Tide) offrant stockage clé/valeur avec TTL optionnel.
|
||||
|
||||
### Stack
|
||||
|
||||
- **Langage**: Rust 2021
|
||||
- **Serveur**: `tide@0.16`, runtime `async-std`
|
||||
- **Utilitaires**: `serde`, `serde_json`, `hex`, `env_logger`
|
||||
- **Tests**: `tempfile`, `surf` (h1-client)
|
||||
|
||||
### API
|
||||
|
||||
- POST `/store` { key(hex64), value(hex), ttl? (s) }
|
||||
- GET `/retrieve/:key`
|
||||
|
||||
### Build et image
|
||||
|
||||
- Docker: build dans `rust:1`, exécution `debian:stable-slim`, utilisateur non‑root, `RUST_LOG=info`.
|
||||
- Expose: 8081; `CMD ["--permanent"]` (clé sans TTL).
|
||||
|
||||
### Risques et points d’attention
|
||||
|
||||
- Validation stricte des formats hex requis (taille/charset) à documenter et tester.
|
||||
- Absence de persistance volumée par défaut: fournir stratégie de stockage (répertoire, montage, quotas).
|
||||
- Logging et rotation à cadrer si charge élevée.
|
||||
|
||||
### Actions proposées
|
||||
|
||||
- Documenter schéma d’erreurs (HTTP, payload) et ajouter tests d’intégration dans `tests/`.
|
||||
- Ajouter option de répertoire de stockage configurable et exemple `.env.example`.
|
||||
- Mettre en place CI rust (build, test, fmt, clippy, audit).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,50 +0,0 @@
|
||||
# Configuration SDK Storage
|
||||
|
||||
## Variables d'environnement
|
||||
|
||||
Le service `sdk_storage` peut être configuré via les variables d'environnement suivantes :
|
||||
|
||||
### Variables principales
|
||||
|
||||
- **`STORAGE_DIR`** : Répertoire de stockage des données (défaut: `./storage`)
|
||||
- **`PORT`** : Port d'écoute du serveur HTTP (défaut: `8080`)
|
||||
- **`NO_TTL_PERMANENT`** : Si définie, les requêtes sans TTL sont traitées comme permanentes
|
||||
|
||||
### Exemples d'utilisation
|
||||
|
||||
```bash
|
||||
# Configuration personnalisée
|
||||
export STORAGE_DIR="/var/lib/sdk_storage"
|
||||
export PORT="8080"
|
||||
export NO_TTL_PERMANENT="1"
|
||||
|
||||
# Lancement du service
|
||||
./sdk_storage
|
||||
```
|
||||
|
||||
## Changements récents
|
||||
|
||||
### v0.2.2 - Configuration externalisée
|
||||
|
||||
- **Ajout** : Support des variables d'environnement pour `STORAGE_DIR` et `PORT`
|
||||
- **Modification** : Remplacement de `127.0.0.1` par `0.0.0.0` dans les tests
|
||||
- **Amélioration** : Configuration plus flexible pour les déploiements Docker
|
||||
|
||||
### Tests
|
||||
|
||||
Les tests utilisent maintenant `0.0.0.0:0` au lieu de `127.0.0.1:0` pour une meilleure compatibilité avec les environnements Docker.
|
||||
|
||||
## Configuration Docker
|
||||
|
||||
```yaml
|
||||
environment:
|
||||
- STORAGE_DIR=/app/storage
|
||||
- PORT=8080
|
||||
- NO_TTL_PERMANENT=1
|
||||
```
|
||||
|
||||
## API Endpoints
|
||||
|
||||
- `GET /health` - Vérification de santé
|
||||
- `POST /store` - Stockage de données
|
||||
- `GET /retrieve/{key}` - Récupération de données
|
||||
@ -1,39 +0,0 @@
|
||||
# Documentation du projet sdk_storage
|
||||
|
||||
Ce dossier documente l'API HTTP, l'architecture et les décisions techniques.
|
||||
|
||||
## API
|
||||
|
||||
- POST `/store` : stocke une valeur hex pour une clé hex 64 chars, `ttl` optionnel (secondes). Quand `--permanent` est passé au binaire, l'absence de `ttl` rend la donnée permanente.
|
||||
- GET `/retrieve/:key` : retourne `{ key, value }` où `value` est encodée en hex.
|
||||
|
||||
## Architecture
|
||||
|
||||
- Service `StorageService` (voir `src/lib.rs`) encapsule la logique de stockage, récupération et nettoyage TTL.
|
||||
- `src/main.rs` démarre Tide avec état `StorageService` et une boucle de nettoyage périodique (60s).
|
||||
|
||||
Voir aussi:
|
||||
- `architecture.md`
|
||||
- `configuration.md`
|
||||
- `guides_principaux.md`
|
||||
- `guides_techniques.md`
|
||||
- `guides_test.md`
|
||||
- `tests_monitoring.md`
|
||||
- `reseau_de_relais.md`
|
||||
- `developpement.md`
|
||||
- `depannage.md`
|
||||
- `performance.md`
|
||||
- `api_json_spec.md`
|
||||
- `api_contrats.md`
|
||||
- `release_guide.md`
|
||||
- `ci_docker_registry.md`
|
||||
|
||||
## REX technique
|
||||
|
||||
- Docker
|
||||
- Build local: `docker build -t sdk_storage:local .`
|
||||
- Run: `docker run --rm -p 8081:8081 -v $PWD/storage:/app/storage sdk_storage:local`
|
||||
- Par défaut `--permanent` est activé via CMD, override possible: `docker run ... sdk_storage -- --permanent`
|
||||
|
||||
- Refactor initial de la logique depuis `main.rs` vers `lib.rs` pour testabilité et séparation des responsabilités.
|
||||
- Durées TTL maintenant validées dans le handler, calcul d'expiration converti en `SystemTime` avant l'appel service.
|
||||
@ -1,21 +0,0 @@
|
||||
# Contrats API
|
||||
|
||||
## Garanties de Contrat
|
||||
- Content-Type JSON, réponses structurées.
|
||||
- Clé: 64 hex (validation stricte), sinon 400.
|
||||
- Valeur: hex valide, sinon 400.
|
||||
- Conflit de clé: 409 si la clé existe déjà.
|
||||
- TTL: min 60, max 31 536 000; par défaut 86 400 si non `--permanent`.
|
||||
- Récupération:
|
||||
- 200 avec `{ key, value }` si trouvée.
|
||||
- 400 si clé invalide.
|
||||
- 404 si absente.
|
||||
|
||||
## Couverture de Tests
|
||||
- Stockage et récupération (succès).
|
||||
- Conflit de clé.
|
||||
- Suppression des expirés via nettoyage.
|
||||
- HTTP `/store`: succès, conflit, clé invalide, valeur invalide.
|
||||
- HTTP `/retrieve`: succès, clé invalide, clé absente.
|
||||
|
||||
Voir `api_json_spec.md` pour les schémas et contraintes détaillés.
|
||||
@ -1,113 +0,0 @@
|
||||
# Spécification JSON des API
|
||||
|
||||
## Généralités
|
||||
- Content-Type: `application/json; charset=utf-8`
|
||||
- Encodage des valeurs: chaînes hexadécimales minuscules (0-9a-f).
|
||||
- Modèle d'erreur: corps `{ "message": string }` avec code HTTP approprié.
|
||||
|
||||
## POST /store
|
||||
- Objet requête: `StoreRequest`
|
||||
- Objet réponse (succès/erreur): `ApiResponse`
|
||||
|
||||
### Schéma JSON (StoreRequest)
|
||||
```json
|
||||
{
|
||||
"$schema": "http://json-schema.org/draft-07/schema#",
|
||||
"title": "StoreRequest",
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["key", "value"],
|
||||
"properties": {
|
||||
"key": {
|
||||
"type": "string",
|
||||
"description": "Clé hexadécimale 64 caractères (32 octets).",
|
||||
"pattern": "^[0-9a-fA-F]{64}$"
|
||||
},
|
||||
"value": {
|
||||
"type": "string",
|
||||
"description": "Valeur encodée en hexadécimal.",
|
||||
"pattern": "^[0-9a-fA-F]+$"
|
||||
},
|
||||
"ttl": {
|
||||
"type": "integer",
|
||||
"minimum": 60,
|
||||
"maximum": 31536000,
|
||||
"description": "Durée de vie en secondes. Si absent: défaut 86400 sauf si mode --permanent (aucune expiration)."
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Règles de validation et sémantique
|
||||
- `key`: exactement 64 caractères hex (
|
||||
32 octets).
|
||||
- `value`: chaîne hex valide, longueur paire recommandée (représentation d'octets).
|
||||
- `ttl`:
|
||||
- min: 60, max: 31 536 000.
|
||||
- si absent et binaire lancé sans `--permanent`: valeur par défaut 86 400.
|
||||
- si absent et binaire lancé avec `--permanent`: aucune expiration.
|
||||
|
||||
### Réponses
|
||||
- 200 OK: `ApiResponse` (message de succès)
|
||||
- 400 Bad Request: `ApiResponse` (clé/ttl/valeur invalides)
|
||||
- 409 Conflict: `ApiResponse` (clé déjà existante)
|
||||
- 500 Internal Server Error: `ApiResponse`
|
||||
|
||||
### Schéma JSON (ApiResponse)
|
||||
```json
|
||||
{
|
||||
"$schema": "http://json-schema.org/draft-07/schema#",
|
||||
"title": "ApiResponse",
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["message"],
|
||||
"properties": {
|
||||
"message": { "type": "string" }
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## GET /retrieve/:key
|
||||
## GET /health
|
||||
- Aucune donnée d'entrée.
|
||||
- Réponse 200 avec `ApiResponse` `{ "message": "ok" }`.
|
||||
|
||||
- Paramètre de chemin: `key` (hex 64).
|
||||
- Objet réponse (succès): `RetrieveResponse`
|
||||
- Objet réponse (erreur): `ApiResponse`
|
||||
|
||||
### Contraintes
|
||||
- `key` doit respecter `^[0-9a-fA-F]{64}$`.
|
||||
|
||||
### Réponses
|
||||
- 200 OK: `RetrieveResponse`
|
||||
- 400 Bad Request: `ApiResponse` (clé invalide)
|
||||
- 404 Not Found: `ApiResponse` (clé inconnue)
|
||||
- 500 Internal Server Error: `ApiResponse`
|
||||
|
||||
### Schéma JSON (RetrieveResponse)
|
||||
```json
|
||||
{
|
||||
"$schema": "http://json-schema.org/draft-07/schema#",
|
||||
"title": "RetrieveResponse",
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"required": ["key", "value"],
|
||||
"properties": {
|
||||
"key": {
|
||||
"type": "string",
|
||||
"description": "Clé hexadécimale 64 caractères.",
|
||||
"pattern": "^[0-9a-fA-F]{64}$"
|
||||
},
|
||||
"value": {
|
||||
"type": "string",
|
||||
"description": "Valeur encodée en hexadécimal.",
|
||||
"pattern": "^[0-9a-fA-F]+$"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Codes d'état et messages
|
||||
- Les messages d'erreur sont informatifs mais ne divulguent pas d'informations sensibles.
|
||||
- Les champs `message` sont destinés à l'humain; ne pas les parser côté client.
|
||||
@ -1,13 +0,0 @@
|
||||
# Architecture
|
||||
|
||||
## Flux de Données
|
||||
|
||||
- Entrées: requêtes HTTP `/store`, `/retrieve/:key`.
|
||||
- Traitements: validation clés/TTL, encodage hex, stockage FS hiérarchique, métadonnées TTL.
|
||||
- Sorties: réponses JSON normalisées.
|
||||
|
||||
## Composants
|
||||
|
||||
- Service `StorageService` (I/O disque, TTL, nettoyage).
|
||||
- Serveur HTTP Tide (routes, état partagé).
|
||||
- Nettoyage périodique (60s) basé sur fichiers `.meta`.
|
||||
@ -1,11 +0,0 @@
|
||||
# CI - Variables pour Registre Docker
|
||||
|
||||
Le workflow `.gitea/workflows/docker.yml` requiert ces secrets:
|
||||
|
||||
- `DOCKER_REGISTRY`: registre cible (ex: registry.git.4nkweb.com/4nk)
|
||||
- `DOCKER_USERNAME`: utilisateur du registre
|
||||
- `DOCKER_PASSWORD`: mot de passe/token
|
||||
|
||||
Configurer ces secrets dans les paramètres du dépôt (ou de l’organisation) côté Gitea.
|
||||
|
||||
La cible d’image est `DOCKER_REGISTRY/sdk_storage:latest` (et multi-arch si activé).
|
||||
@ -1,8 +0,0 @@
|
||||
# Configuration
|
||||
|
||||
## Services Disponibles
|
||||
- HTTP sur port 8081
|
||||
|
||||
## Variables d'Environnement
|
||||
- `RUST_LOG` (optionnel): niveau de logs.
|
||||
- Pour Docker, monter `/app/storage` si persistance souhaitée.
|
||||
@ -1,15 +0,0 @@
|
||||
# Démarrage Rapide
|
||||
|
||||
## Prérequis
|
||||
- Rust stable et Cargo
|
||||
- Optionnel: Docker
|
||||
|
||||
## Installation
|
||||
- `cargo build`
|
||||
|
||||
## Lancement
|
||||
- `cargo run -- --permanent`
|
||||
|
||||
## Docker (optionnel)
|
||||
- Build: `docker build -t sdk_storage:local .`
|
||||
- Run: `docker run --rm -p 8081:8081 -v $PWD/storage:/app/storage sdk_storage:local`
|
||||
@ -1,12 +0,0 @@
|
||||
# Dépannage
|
||||
|
||||
## Problèmes Courants
|
||||
1. Ports déjà utilisés: changer le port de publication Docker.
|
||||
2. Permissions storage: vérifier l'UID/GID et droits du volume.
|
||||
3. Clés invalides: s'assurer d'un hex 64 caractères.
|
||||
|
||||
## Logs détaillés
|
||||
- Exécuter avec `RUST_LOG=info`.
|
||||
|
||||
## Healthchecks
|
||||
- Ajouter une route `/health` (évolution possible) ou ping sur `/retrieve` avec clé connue.
|
||||
@ -1,13 +0,0 @@
|
||||
# Développement
|
||||
|
||||
## Structure du Projet
|
||||
- `src/lib.rs`: service métier
|
||||
- `src/main.rs`: serveur HTTP Tide
|
||||
- `tests/`: scénarios d'intégration
|
||||
|
||||
## Ajout d'un Nouveau Service
|
||||
- Créer une abstraction dédiée dans `src/lib.rs` ou module séparé.
|
||||
- Câbler dans `main.rs` via `tide::with_state` si nécessaire.
|
||||
|
||||
## Modification de la Configuration
|
||||
- Mettre à jour `docs/configuration.md` et secrets CI/CD.
|
||||
@ -1,5 +0,0 @@
|
||||
# Guides Principaux
|
||||
|
||||
- Concepts de base: clés hex 64, valeurs hex, TTL en secondes.
|
||||
- API: `/store` (POST), `/retrieve/:key` (GET).
|
||||
- Persistance: système de fichiers, sous-dossiers par préfixe de clé.
|
||||
@ -1,6 +0,0 @@
|
||||
# Guides Techniques
|
||||
|
||||
- `StorageService`: abstraction des opérations de stockage.
|
||||
- TTL: sérialisé dans `*.meta` (UNIX timestamp secondes).
|
||||
- Nettoyage: parcours des dossiers, suppression données expirées.
|
||||
- Journalisation: sorties standard, intégration possible avec superviseur.
|
||||
@ -1,5 +0,0 @@
|
||||
# Guides de Test
|
||||
|
||||
- Tests unitaires recommandés sur `StorageService` via répertoires temporaires.
|
||||
- Tests d'intégration HTTP optionnels via client HTTP.
|
||||
- Stratégies: cas TTL min/max, clés invalides, conflits de clé.
|
||||
@ -1,9 +0,0 @@
|
||||
# Performance
|
||||
|
||||
## Ressources Recommandées
|
||||
- Disque rapide si grand volume d'écritures.
|
||||
- Mémoire suffisante pour buffers I/O.
|
||||
|
||||
## Optimisations
|
||||
- Paramétrer la taille des blocs et la stratégie de fsync selon contraintes.
|
||||
- Éviter les collisions de clés, supervision du cleanup TTL.
|
||||
@ -1,21 +0,0 @@
|
||||
# Guide de Release
|
||||
|
||||
## Préparation
|
||||
- S’assurer que la suite `cargo test` est verte.
|
||||
- Mettre à jour `CHANGELOG.md` avec la version cible.
|
||||
|
||||
## Tagging
|
||||
- Créer un tag annoté: `git tag -a vX.Y.Z -m 'vX.Y.Z'`
|
||||
- Pousser le tag: `git push origin vX.Y.Z`
|
||||
|
||||
## CI
|
||||
- Build binaire (workflow release) déclenché sur tag `v*.*.*`.
|
||||
- Build/push image Docker via workflow `docker.yml` (variables `DOCKER_*` requises).
|
||||
|
||||
## Assets
|
||||
- Binaires disponibles via artefacts CI.
|
||||
- Images Docker taggées `latest` (et potentiellement `vX.Y.Z` selon configuration).
|
||||
|
||||
## Post-release
|
||||
- Mettre à jour la documentation si nécessaire.
|
||||
- Ouvrir une issue pour les améliorations/retours.
|
||||
@ -1,10 +0,0 @@
|
||||
# Réseau de Relais
|
||||
|
||||
## Architecture Mesh
|
||||
- À définir selon déploiement.
|
||||
|
||||
## Ajout de Nœuds Externes
|
||||
- Procédure à documenter si nécessaire.
|
||||
|
||||
## Configuration Externe
|
||||
- Ports, sécurité, endpoints à exposer.
|
||||
@ -1,9 +0,0 @@
|
||||
# Tests et Monitoring
|
||||
|
||||
## Tests
|
||||
- Unitaires et intégration via `cargo test`.
|
||||
|
||||
## Monitoring
|
||||
- Healthcheck HTTP: endpoint `/health` retourne `{ "message": "ok" }` et code 200.
|
||||
- Exposer métriques avec un reverse proxy/sidecar si nécessaire.
|
||||
- Configurer l'orchestrateur pour vérifier périodiquement `/health`.
|
||||
Loading…
x
Reference in New Issue
Block a user