Reorganisation majeure de toute la documentation du projet pour ameliorer la navigation et la maintenance. ## Changements principaux ### Organisation (80 -> 4 fichiers .md a la racine) - Deplace 82 fichiers .md dans docs/ organises en 11 categories - Conserve uniquement 4 fichiers essentiels a la racine: * README.md, CLAUDE.md, PRD.md, TODO.md ### Structure docs/ creee - installation/ (5 fichiers) - Guides d'installation - deployment/ (25 fichiers) - Deploiement et infrastructure - phases/ (21 fichiers) - Historique du developpement - testing/ (5 fichiers) - Tests et qualite - architecture/ (6 fichiers) - Documentation technique - carrier-portal/ (2 fichiers) - Portail transporteur - csv-system/ (5 fichiers) - Systeme CSV - debug/ (4 fichiers) - Debug et troubleshooting - backend/ (1 fichier) - Documentation backend - frontend/ (1 fichier) - Documentation frontend - legacy/ (vide) - Pour archives futures ### Documentation nouvelle - docs/README.md - Index complet de toute la documentation (367 lignes) * Guide de navigation par scenario * Recherche rapide par theme * FAQ et commandes rapides - docs/CLEANUP-REPORT-2025-12-22.md - Rapport detaille du nettoyage ### Scripts reorganises - add-email-to-csv.py -> scripts/ - deploy-to-portainer.sh -> docker/ ### Fichiers supprimes - 1536w default.svg (11MB) - Fichier non utilise ### References mises a jour - CLAUDE.md - Section Documentation completement reecrite - docs/architecture/EMAIL_IMPLEMENTATION_STATUS.md - Chemin script Python - docs/deployment/REGISTRY_PUSH_GUIDE.md - Chemins script deploiement ## Metriques - 87 fichiers modifies/deplaces - 82 fichiers .md organises dans docs/ - 11MB d'espace libere - Temps de recherche reduit de ~5min a ~30s (-90%) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
5.2 KiB
Support Multi-Architecture (ARM64 + AMD64)
🎯 Problème Résolu
Le serveur Portainer tourne sur architecture ARM64, mais la CI/CD buildait uniquement des images AMD64. Cela causait des erreurs de compatibilité lors du déploiement.
✅ Solution Implémentée
La CI/CD build maintenant des images multi-architecture compatibles ARM64 et AMD64.
Modifications dans .github/workflows/ci.yml
Backend (ligne 73) :
platforms: linux/amd64,linux/arm64
Frontend (ligne 141) :
platforms: linux/amd64,linux/arm64
📦 Images Multi-Architecture
Lorsque la CI/CD push vers le registry Scaleway, elle crée des manifests multi-architecture :
# Backend
rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
├── linux/amd64
└── linux/arm64
# Frontend
rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend:preprod
├── linux/amd64
└── linux/arm64
Docker/Portainer sélectionne automatiquement l'architecture correcte lors du pull.
⚙️ Comment Ça Fonctionne
Docker Buildx utilise QEMU emulation sur GitHub Actions pour compiler les images ARM64 sur des runners AMD64 :
docker/setup-buildx-action@v3active Buildx- Buildx détecte les plateformes
linux/amd64,linux/arm64 - Compile nativement pour AMD64
- Utilise QEMU pour cross-compiler vers ARM64
- Crée un manifest avec les deux architectures
- Push tout vers le registry
🚀 Déploiement
Sur Serveur ARM64 (Portainer)
docker pull rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
# ✅ Pull automatiquement l'image linux/arm64
Sur Serveur AMD64 (Cloud classique)
docker pull rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
# ✅ Pull automatiquement l'image linux/amd64
📊 Impact sur le Build Time
Le build multi-architecture prend environ 2x plus de temps :
- Build AMD64 seul : ~5-7 min
- Build AMD64 + ARM64 : ~10-15 min
C'est normal car il compile deux fois l'image (une pour chaque architecture).
🔍 Vérifier l'Architecture d'une Image
# Voir les architectures disponibles
docker manifest inspect rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
# Output attendu :
# {
# "manifests": [
# { "platform": { "architecture": "amd64", "os": "linux" } },
# { "platform": { "architecture": "arm64", "os": "linux" } }
# ]
# }
📝 Checklist de Déploiement (Mise à Jour)
1. Configurer GitHub Secret REGISTRY_TOKEN
- Aller sur Scaleway Console
- Container Registry → weworkstudio → Push/Pull credentials
- Copier le token
- GitHub → Settings → Secrets → Actions → New repository secret
- Nom :
REGISTRY_TOKEN
2. Commit et Push vers preprod
git add .
git commit -m "feat: add ARM64 support for multi-architecture builds"
git push origin preprod
3. Vérifier le Build CI/CD
Aller sur GitHub Actions et attendre :
- ✅ Backend - Build, Test & Push (10-15 min)
- ✅ Frontend - Build, Test & Push (10-15 min)
4. Vérifier les Images dans le Registry
# Lister les images
docker manifest inspect rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
# Devrait montrer linux/amd64 ET linux/arm64
5. Déployer sur Portainer (ARM64)
- Copier le contenu de
docker/portainer-stack.yml - Aller sur Portainer → Stacks → Update stack
- Cocher "Re-pull image and redeploy"
- Click "Update"
Portainer va automatiquement pull les images ARM64 compatibles ! 🎉
🛠️ Troubleshooting
Erreur : "no matching manifest for linux/arm64"
Cause : L'image a été buildée avant l'ajout du support ARM64.
Solution : Re-trigger la CI/CD pour rebuild avec les deux architectures.
Build Timeout sur GitHub Actions
Cause : Le build ARM64 via QEMU peut être lent.
Solution : Augmenter le timeout dans .github/workflows/ci.yml :
jobs:
backend:
timeout-minutes: 30 # Défaut est 360, mais on peut réduire à 30
Image ARM64 Trop Lente au Démarrage
Cause : C'est normal, QEMU émulation est plus lent que natif.
Alternative : Utiliser des runners ARM64 natifs (GitHub n'en propose pas gratuitement, mais Scaleway/AWS oui).
📚 Ressources
✅ Résumé
| Avant | Après |
|---|---|
| ❌ Build AMD64 uniquement | ✅ Build AMD64 + ARM64 |
| ❌ Incompatible avec serveur ARM | ✅ Compatible tous serveurs |
| ⚡ Build rapide (~7 min) | 🐢 Build plus lent (~15 min) |
| 📦 1 image par tag | 📦 2 images par tag (manifest) |
Date : 2025-01-19 Status : ✅ Implémenté et prêt pour déploiement