Aller au contenu principal

Considérations de production

Ce guide couvre les bonnes pratiques de production, la sécurité, la surveillance et les considérations opérationnelles pour l'exécution d'AnonDocs dans des environnements de production.

Bonnes pratiques de sécurité​

Sécurité réseau​

Exécuter derrière un proxy inverse​

Utilisez toujours un proxy inverse (Nginx, Caddy, Traefik) devant AnonDocs :

  • ✅ Terminaison SSL/TLS
  • ✅ Limitation de débit
  • ✅ Protection DDoS
  • ✅ Journalisation des requêtes
  • ✅ Liste blanche IP si nécessaire

Isolation réseau​

Pour les déploiements sensibles :

  • Exécuter dans des segments réseau isolés
  • Utiliser VPN ou réseaux privés pour la communication avec le fournisseur LLM
  • Envisager des déploiements isolés du réseau pour une sécurité maximale

Configuration du pare-feu​

# Autoriser uniquement les ports nécessaires
ufw allow 80/tcp   # HTTP (proxy inverse)
ufw allow 443/tcp # HTTPS (proxy inverse)
ufw deny 3000/tcp # Bloquer l'accès direct à AnonDocs

Authentification et autorisation​

Authentification API​

Implémentez l'authentification pour l'accès à l'API :

// Exemple: middleware de clé API
const authenticate = (req, res, next) => {
  const apiKey = req.headers['x-api-key'];
  if (apiKey !== process.env.API_KEY) {
    return res.status(401).json({ error: 'Non autorisé' });
  }
  next();
};

Limitation de débit​

Configurez la limitation de débit pour prévenir les abus :

# Limitation de débit Nginx
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
    proxy_pass http://localhost:3000;
}

Liste blanche IP​

Pour les déploiements internes uniquement :

location / {
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    deny all;
    proxy_pass http://localhost:3000;
}

Sécurité des données​

Aucune persistance des données​

AnonDocs est conçu pour traiter les données uniquement en mémoire :

  • ✅ Les fichiers sont immédiatement supprimés après le traitement
  • ✅ Aucun stockage en base de données
  • ✅ Aucune persistance du système de fichiers
  • ✅ Tout le traitement se fait en mémoire

Limites sécurisées de téléversement de fichiers​

Configurez les limites de taille de téléversement :

client_max_body_size 50M;

Validation des entrées​

Assurez-vous que toutes les entrées sont validées :

  • Validation du type de fichier
  • Limites de taille de fichier
  • Validation du contenu
  • Détection de fichiers malveillants

Sécurité des variables d'environnement​

Ne jamais valider les secrets​

# .gitignore
.env
.env.production
*.key
*.pem

Utiliser la gestion des secrets​

Pour Kubernetes :

apiVersion: v1
kind: Secret
metadata:
  name: anondocs-secrets
type: Opaque
stringData:
  API_KEY: "your-secret-key"

Pour Docker :

docker run -d \
  --env-file .env.production \
  --env-file .env.secrets \
  anondocs

Rotation régulière des secrets​

  • Rotation des clés API trimestrielle
  • Mise à jour des identifiants du fournisseur LLM
  • Révision régulière des journaux d'accès

Optimisation des performances​

Allocation des ressources​

CPU et mémoire​

# Requêtes/limites de ressources Kubernetes
resources:
  requests:
    memory: "1Gi"
    cpu: "1000m"
  limits:
    memory: "4Gi"
    cpu: "4000m"

Allocation GPU (si disponible)​

resources:
  limits:
    nvidia.com/gpu: 1

Stratégies de mise en cache​

Bien qu'AnonDocs ne stocke pas de données, envisagez :

  • Mise en cache des réponses LLM: Mettre en cache les réponses LLM pour des entrées similaires (attention aux PII)
  • Chargement de modèle: Garder les modèles en mémoire pour une inférence plus rapide
  • Pool de connexions: Réutiliser les connexions du fournisseur LLM

Équilibrage de charge​

Pour la haute disponibilité :

upstream anondocs_backend {
    least_conn;
    server anondocs-1:3000;
    server anondocs-2:3000;
    server anondocs-3:3000;
}

server {
    location / {
        proxy_pass http://anondocs_backend;
    }
}

Surveillance et observabilité​

Surveillance de l'état​

Point de terminaison de vérification de l'état​

# Vérifications automatiques de l'état
curl -f http://localhost:3000/health || alert

Vérifications de l'état Kubernetes​

livenessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 10
  periodSeconds: 5

Journalisation​

Journalisation structurée​

Configurez la journalisation structurée pour une meilleure observabilité :

// Exemple de configuration de journalisation
import winston from 'winston';

const logger = winston.createLogger({
  format: winston.format.json(),
  transports: [
    new winston.transports.File({ filename: 'error.log', level: 'error' }),
    new winston.transports.File({ filename: 'combined.log' })
  ]
});

Rétention des journaux​

  • Conserver les journaux pour les exigences de conformité (par exemple, 90 jours)
  • Ne jamais journaliser de données sensibles ou de PII
  • Utiliser la rotation des journaux pour gérer l'espace disque

Collecte de métriques​

Métriques clés à surveiller​

  • Taux de requêtes et latence
  • Taux d'erreurs
  • Temps de réponse du fournisseur LLM
  • Utilisation de la mémoire et du CPU
  • Profondeur de la file d'attente de traitement
  • Temps de traitement des blocs

Intégration Prometheus​

# Exemple de point de terminaison de métriques
/metrics:
  prometheus: true

Sauvegarde et reprise après sinistre​

Sauvegardes de configuration​

# Sauvegarder la configuration
cp .env.production .env.production.backup

Infrastructure as Code​

Stocker les configurations de déploiement dans le contrôle de version :

  • Fichiers Docker Compose
  • Manifestes Kubernetes
  • Scripts d'infrastructure
  • Modèles de configuration

Plan de reprise après sinistre​

  1. Documentation: Documenter votre architecture de déploiement
  2. Stratégie de sauvegarde: Sauvegardes régulières des configurations
  3. Tests de récupération: Tester régulièrement les procédures de récupération
  4. Réponse aux incidents: Avoir un plan pour les incidents de sécurité

Considérations de conformité​

Conformité RGPD​

AnonDocs est conçu pour la conformité RGPD :

  • ✅ Aucune conservation des données
  • ✅ Traitement local uniquement
  • ✅ Open source et auditable
  • ✅ Aucun partage de données avec des tiers

Considérations HIPAA​

Pour les déploiements dans le secteur de la santé :

  • Déployer dans une infrastructure conforme HIPAA
  • Utiliser des connexions chiffrées (TLS)
  • Implémenter des contrôles d'accès
  • Maintenir des journaux d'audit
  • Évaluations de sécurité régulières

Audits de sécurité réguliers​

  • Réviser les dépendances pour les vulnérabilités
  • Effectuer des tests d'intrusion
  • Révisions de code de sécurité
  • Mettre à jour régulièrement les dépendances

Bonnes pratiques opérationnelles​

Stratégie de mise à jour​

Épinglage de version​

FROM node:18-alpine
# Épingler des versions spécifiques pour la stabilité

Procédures de mise à jour​

  1. Tester les mises à jour dans l'environnement de préproduction
  2. Réviser le journal des modifications pour les changements cassants
  3. Sauvegarder la configuration avant la mise à jour
  4. Déployer pendant les fenêtres de maintenance
  5. Surveiller après le déploiement

Planification de la capacité​

Surveiller l'utilisation des ressources​

  • Suivre le CPU et la mémoire dans le temps
  • Identifier les schémas d'utilisation de pointe
  • Planifier la croissance

Déclencheurs de mise à l'échelle​

Configurer des alertes pour :

  • Utilisation élevée du CPU (>80%)
  • Utilisation élevée de la mémoire (>85%)
  • Augmentation du taux d'erreurs
  • Temps de réponse lents

Documentation​

Maintenir la documentation pour :

  • Architecture de déploiement
  • Détails de configuration
  • Contacts d'urgence
  • Procédures de récupération
  • Problèmes connus et solutions de contournement

Dépannage des problèmes de production​

Problèmes courants​

Utilisation élevée de la mémoire​

  • Réduire CHUNK_SIZE
  • Désactiver ENABLE_PARALLEL_CHUNKS
  • Utiliser des modèles LLM plus petits
  • Mise à l'échelle horizontale

Temps de réponse lents​

  • Vérifier les performances du fournisseur LLM
  • Réviser la latence réseau
  • Optimiser le traitement des blocs
  • Envisager des stratégies de mise en cache

Erreurs de connexion​

  • Vérifier que le fournisseur LLM est accessible
  • Vérifier la connectivité réseau
  • Réviser les règles de pare-feu
  • Tester les points de terminaison de l'état

Réponse aux incidents​

  1. Identifier: Déterminer l'étendue du problème
  2. Contenir: Prévenir un impact supplémentaire
  3. Résoudre: Corriger la cause racine
  4. Apprendre: Post-mortem et améliorations

Prochaines étapes​

Pour le support en production, visitez nos Discussions GitHub ou Issues GitHub.

Proudly made byAI SmartTalkAI SmartTalk