Skip to content

TP9 cmd

PasRP-Theo edited this page Jun 8, 2025 · 2 revisions

TP WoodyToys - High Throughput Guide

1. Préparation initiale

Récupération du code source

# Cloner le repository GitHub du service WoodyToys
git clone [URL_DU_REPO_GITHUB]
cd woodytoys-service

# Examiner la structure des fichiers
ls -la
cat docker-compose.yml

Analyse des flux de données

Avant de commencer, documenter les flux :

  • FrontendAPI FlaskBase de données
  • UtilisateurFrontend (port 80/443)
  • APIDB (connexions internes)

2. Adaptation du docker-compose.yml pour Docker Stack

Problème avec la directive build

Pourquoi build ne convient pas dans Docker Swarm :

  • Docker Swarm exécute les conteneurs sur différents nœuds
  • La directive build nécessite le code source sur chaque nœud
  • Les images doivent être pré-construites et disponibles dans un registry

Modification du docker-compose.yml

version: '3.8'

services:
  frontend:
    image: votre-username/woodytoys-frontend:latest
    deploy:
      replicas: 1
    ports:
      - "80:80"
    networks:
      - woodytoys-net

  api:
    image: votre-username/woodytoys-api:latest
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.role == worker
    networks:
      - woodytoys-net
    environment:
      - DB_HOST=database

  database:
    image: votre-username/woodytoys-db:latest
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.role == manager
    networks:
      - woodytoys-net
    volumes:
      - db-data:/var/lib/mysql

networks:
  woodytoys-net:
    driver: overlay

volumes:
  db-data:

3. Construction et publication des images

Script build_push.sh adapté

#!/bin/bash

# Variables
DOCKER_USERNAME="votre-username"
VERSION="latest"

# Build et push du frontend
docker build -t $DOCKER_USERNAME/woodytoys-frontend:$VERSION ./frontend
docker push $DOCKER_USERNAME/woodytoys-frontend:$VERSION

# Build et push de l'API
docker build -t $DOCKER_USERNAME/woodytoys-api:$VERSION ./api
docker push $DOCKER_USERNAME/woodytoys-api:$VERSION

# Build et push de la DB
docker build -t $DOCKER_USERNAME/woodytoys-db:$VERSION ./database
docker push $DOCKER_USERNAME/woodytoys-db:$VERSION

echo "Toutes les images ont été publiées sur Docker Hub"

Commandes de déploiement

# Rendre le script exécutable
chmod +x build_push.sh

# Construire et publier les images
./build_push.sh

# Déployer sur le swarm
docker stack deploy -c docker-compose.yml woodytoys

# Vérifier le déploiement
docker stack services woodytoys
docker service ls

4. Tests de performance initiaux

Mesure des performances

# Test simple de temps de réponse
time wget -r http://votre-url-swarm

# Test plus détaillé avec curl
curl -w "@curl-format.txt" -o /dev/null -s http://votre-url-swarm

# Créer le fichier curl-format.txt
cat > curl-format.txt << EOF
     time_namelookup:  %{time_namelookup}\n
        time_connect:  %{time_connect}\n
     time_appconnect:  %{time_appconnect}\n
    time_pretransfer:  %{time_pretransfer}\n
       time_redirect:  %{time_redirect}\n
  time_starttransfer:  %{time_starttransfer}\n
                     ----------\n
          time_total:  %{time_total}\n
EOF

# Test de charge avec Apache Bench (si disponible)
ab -n 100 -c 10 http://votre-url-swarm/

5. Augmentation des réplicas

Mise à jour du nombre de réplicas

# Augmenter les réplicas de l'API (sans arrêter le service)
docker service update --replicas 3 woodytoys_api

# Augmenter les réplicas du frontend
docker service update --replicas 2 woodytoys_frontend

# Vérifier les changements
docker service ls
docker stack services woodytoys

Tests après augmentation des réplicas

# Relancer les tests de performance
time wget -r http://votre-url-swarm
curl -w "@curl-format.txt" -o /dev/null -s http://votre-url-swarm

# Comparer avec les résultats précédents

6. Améliorations Docker Swarm

Ajout de healthchecks pour l'API

# Dans docker-compose.yml, service api:
api:
  image: votre-username/woodytoys-api:latest
  deploy:
    replicas: 3
  healthcheck:
    test: ["CMD", "curl", "-f", "http://localhost:5000/health"]
    interval: 30s
    timeout: 10s
    retries: 3
    start_period: 40s

Contraintes de placement

# Database sur un nœud spécifique
database:
  deploy:
    placement:
      constraints:
        - node.labels.database == true

# API sur les workers
api:
  deploy:
    placement:
      constraints:
        - node.role == worker
# Ajouter un label à un nœud pour la DB
docker node update --label-add database=true nom-du-noeud

7. Mise en place du cache Redis

Ajout de Redis au docker-compose.yml

services:
  redis:
    image: redis:alpine
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.role == manager
    networks:
      - woodytoys-net

Modification du code API Flask

# Ajouter dans requirements.txt
echo "redis" >> api/requirements.txt

# Exemple de code pour l'API (à adapter selon votre structure)
import redis
from flask import Flask, jsonify

app = Flask(__name__)
r = redis.Redis(host='redis', port=6379, db=0)

@app.route('/api/products')
def get_products():
    # Vérifier le cache d'abord
    cached_products = r.get('products')
    
    if cached_products:
        return jsonify(eval(cached_products))  # Attention: utiliser json.loads en réalité
    
    # Si pas en cache, récupérer de la DB
    products = fetch_from_database()
    
    # Mettre en cache pour 60 secondes
    r.setex('products', 60, str(products))
    
    return jsonify(products)

Redéploiement avec Redis

# Reconstruire l'image API avec Redis
docker build -t votre-username/woodytoys-api:latest ./api
docker push votre-username/woodytoys-api:latest

# Mettre à jour la stack
docker stack deploy -c docker-compose.yml woodytoys

# Vérifier que Redis fonctionne
docker service logs woodytoys_redis

8. Tests de performance avec cache

# Tests après implémentation du cache
time wget -r http://votre-url-swarm

# Test spécifique sur l'endpoint avec cache
curl -w "@curl-format.txt" -o /dev/null -s http://votre-url-swarm/api/products

# Test de la mise en cache (deux appels successifs)
time curl http://votre-url-swarm/api/products
time curl http://votre-url-swarm/api/products  # Devrait être plus rapide

9. Configuration CDN avec Gcore

Étapes sur Gcore

  1. Créer un compte sur gcore.com
  2. Ajouter votre domaine
  3. Configurer le CNAME pour les ressources statiques
  4. Obtenir l'URL du CDN

Modification du code HTML

<!-- Remplacer les liens vers les ressources statiques -->
<!-- Au lieu de : -->
<link rel="stylesheet" href="/static/css/style.css">
<script src="/static/js/app.js"></script>

<!-- Utiliser : -->
<link rel="stylesheet" href="https://votre-cdn-url.gcore.com/static/css/style.css">
<script src="https://votre-cdn-url.gcore.com/static/js/app.js"></script>

Configuration DNS

# Ajouter un enregistrement CNAME
# static.votre-domaine.com CNAME votre-cdn-url.gcore.com

10. Tests finaux et documentation

Campagne de mesures complète

# Script de test automatisé
cat > performance-test.sh << EOF
#!/bin/bash
echo "=== Test de performance WoodyToys ==="
echo "Date: $(date)"
echo ""

echo "1. Test temps de réponse global:"
time wget -q -O /dev/null http://votre-url-swarm

echo ""
echo "2. Test détaillé avec curl:"
curl -w "@curl-format.txt" -o /dev/null -s http://votre-url-swarm

echo ""
echo "3. Test API avec cache:"
time curl -s -o /dev/null http://votre-url-swarm/api/products

echo ""
echo "4. Test ressources statiques CDN:"
time curl -s -o /dev/null https://votre-cdn-url.gcore.com/static/css/style.css
EOF

chmod +x performance-test.sh
./performance-test.sh

11. Commandes de monitoring

# Surveiller les services
watch docker service ls

# Logs des services
docker service logs -f woodytoys_api
docker service logs -f woodytoys_frontend
docker service logs -f woodytoys_redis

# Statistiques des conteneurs
docker stats

# État du swarm
docker node ls
docker stack ps woodytoys

12. Nettoyage (si nécessaire)

# Supprimer la stack
docker stack rm woodytoys

# Nettoyer les images inutilisées
docker system prune -f

# Supprimer les volumes (attention aux données!)
docker volume prune -f

Points clés à documenter sur votre Wiki

  1. Schéma des flux de données avec les différents composants
  2. Résultats des mesures de performance avant/après chaque optimisation
  3. Impact des réplicas sur les performances
  4. Efficacité du cache Redis avec chiffres à l'appui
  5. Amélioration apportée par le CDN sur les ressources statiques
  6. Solutions pour améliorer les performances DB (réplication, sharding, index, etc.)

Solutions pour améliorer les performances DB

  • Réplication Master-Slave : lecture sur slaves, écriture sur master
  • Sharding : distribution des données sur plusieurs serveurs
  • Index optimisés : améliorer les requêtes SELECT
  • Connection pooling : réutiliser les connexions
  • Cache de requêtes : mise en cache au niveau DB

Clone this wiki locally