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
|
## Licence
|
||||||
|
|
||||||
Voir `LICENSE` (MIT).
|
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