fix
All checks were successful
CI/CD Pipeline / Backend - Build, Test & Push (push) Successful in 6m17s
CI/CD Pipeline / Frontend - Build, Test & Push (push) Successful in 14m45s
CI/CD Pipeline / Integration Tests (push) Has been skipped
CI/CD Pipeline / Deployment Summary (push) Successful in 2s
CI/CD Pipeline / Discord Notification (Failure) (push) Has been skipped
CI/CD Pipeline / Discord Notification (Success) (push) Successful in 2s
All checks were successful
CI/CD Pipeline / Backend - Build, Test & Push (push) Successful in 6m17s
CI/CD Pipeline / Frontend - Build, Test & Push (push) Successful in 14m45s
CI/CD Pipeline / Integration Tests (push) Has been skipped
CI/CD Pipeline / Deployment Summary (push) Successful in 2s
CI/CD Pipeline / Discord Notification (Failure) (push) Has been skipped
CI/CD Pipeline / Discord Notification (Success) (push) Successful in 2s
This commit is contained in:
David
parent
7dadd951bb
commit
2e5dcec05c
4
.github/workflows/ci.yml
vendored
4
.github/workflows/ci.yml
vendored
@ -70,7 +70,7 @@ jobs:
|
||||
labels: ${{ steps.meta.outputs.labels }}
|
||||
cache-from: type=registry,ref=${{ env.REGISTRY }}/xpeditis-backend:buildcache
|
||||
cache-to: type=registry,ref=${{ env.REGISTRY }}/xpeditis-backend:buildcache,mode=max
|
||||
platforms: linux/amd64
|
||||
platforms: linux/amd64,linux/arm64
|
||||
|
||||
# ============================================
|
||||
# Frontend Build, Test & Deploy
|
||||
@ -138,7 +138,7 @@ jobs:
|
||||
labels: ${{ steps.meta.outputs.labels }}
|
||||
cache-from: type=registry,ref=${{ env.REGISTRY }}/xpeditis-frontend:buildcache
|
||||
cache-to: type=registry,ref=${{ env.REGISTRY }}/xpeditis-frontend:buildcache,mode=max
|
||||
platforms: linux/amd64
|
||||
platforms: linux/amd64,linux/arm64
|
||||
build-args: |
|
||||
NEXT_PUBLIC_API_URL=${{ secrets.NEXT_PUBLIC_API_URL || 'http://localhost:4000' }}
|
||||
NEXT_PUBLIC_APP_URL=${{ secrets.NEXT_PUBLIC_APP_URL || 'http://localhost:3000' }}
|
||||
|
||||
176
ARM64_SUPPORT.md
Normal file
176
ARM64_SUPPORT.md
Normal file
@ -0,0 +1,176 @@
|
||||
# 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)** :
|
||||
```yaml
|
||||
platforms: linux/amd64,linux/arm64
|
||||
```
|
||||
|
||||
**Frontend (ligne 141)** :
|
||||
```yaml
|
||||
platforms: linux/amd64,linux/arm64
|
||||
```
|
||||
|
||||
## 📦 Images Multi-Architecture
|
||||
|
||||
Lorsque la CI/CD push vers le registry Scaleway, elle crée des **manifests multi-architecture** :
|
||||
|
||||
```bash
|
||||
# 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 :
|
||||
|
||||
1. `docker/setup-buildx-action@v3` active Buildx
|
||||
2. Buildx détecte les plateformes `linux/amd64,linux/arm64`
|
||||
3. Compile nativement pour AMD64
|
||||
4. Utilise QEMU pour cross-compiler vers ARM64
|
||||
5. Crée un manifest avec les deux architectures
|
||||
6. Push tout vers le registry
|
||||
|
||||
## 🚀 Déploiement
|
||||
|
||||
### Sur Serveur ARM64 (Portainer)
|
||||
|
||||
```bash
|
||||
docker pull rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
|
||||
# ✅ Pull automatiquement l'image linux/arm64
|
||||
```
|
||||
|
||||
### Sur Serveur AMD64 (Cloud classique)
|
||||
|
||||
```bash
|
||||
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
|
||||
|
||||
```bash
|
||||
# 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](https://console.scaleway.com/registry/namespaces)
|
||||
- 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`
|
||||
|
||||
```bash
|
||||
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](https://github.com/VOTRE_USERNAME/xpeditis/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
|
||||
|
||||
```bash
|
||||
# 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)
|
||||
|
||||
1. Copier le contenu de `docker/portainer-stack.yml`
|
||||
2. Aller sur Portainer → Stacks → Update stack
|
||||
3. Cocher "Re-pull image and redeploy"
|
||||
4. 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` :
|
||||
|
||||
```yaml
|
||||
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
|
||||
|
||||
- [Docker Buildx Multi-Platform](https://docs.docker.com/build/building/multi-platform/)
|
||||
- [GitHub Actions ARM64 Support](https://github.blog/changelog/2024-06-03-github-actions-arm64-linux-and-windows-runners-are-now-generally-available/)
|
||||
- [Scaleway Container Registry](https://www.scaleway.com/en/docs/containers/container-registry/)
|
||||
|
||||
## ✅ 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
|
||||
257
CICD_REGISTRY_SETUP.md
Normal file
257
CICD_REGISTRY_SETUP.md
Normal file
@ -0,0 +1,257 @@
|
||||
# 🔧 Configuration CI/CD - Registry Scaleway
|
||||
|
||||
## ✅ Bonne Nouvelle !
|
||||
|
||||
La CI/CD est **déjà configurée** dans `.github/workflows/ci.yml` pour :
|
||||
- ✅ Build les images Docker (backend + frontend)
|
||||
- ✅ **Support multi-architecture (AMD64 + ARM64)** 🎉
|
||||
- ✅ Push vers le registry Scaleway
|
||||
- ✅ Créer les tags corrects (`preprod`)
|
||||
|
||||
## ⚙️ Configuration Requise
|
||||
|
||||
Pour que la CI/CD puisse push vers le registry Scaleway, il faut configurer le secret GitHub.
|
||||
|
||||
### Étape 1 : Obtenir le Token Scaleway
|
||||
|
||||
1. Aller sur [console.scaleway.com](https://console.scaleway.com)
|
||||
2. **Container Registry** → `weworkstudio`
|
||||
3. Cliquer sur **Push/Pull credentials**
|
||||
4. Créer ou copier un token d'accès
|
||||
|
||||
### Étape 2 : Ajouter le Secret dans GitHub
|
||||
|
||||
1. Aller sur votre repo GitHub : https://github.com/VOTRE_USERNAME/xpeditis
|
||||
2. **Settings** → **Secrets and variables** → **Actions**
|
||||
3. Cliquer sur **New repository secret**
|
||||
4. Créer le secret :
|
||||
- **Name** : `REGISTRY_TOKEN`
|
||||
- **Value** : Coller le token Scaleway
|
||||
5. Cliquer **Add secret**
|
||||
|
||||
### Étape 3 : Vérifier les Autres Secrets (Optionnels)
|
||||
|
||||
Pour le frontend, vérifier ces secrets (si vous utilisez des URLs différentes) :
|
||||
|
||||
| Secret Name | Description | Exemple |
|
||||
|-------------|-------------|---------|
|
||||
| `NEXT_PUBLIC_API_URL` | URL de l'API backend | `https://api.preprod.xpeditis.com` |
|
||||
| `NEXT_PUBLIC_APP_URL` | URL du frontend | `https://app.preprod.xpeditis.com` |
|
||||
| `DISCORD_WEBHOOK_URL` | Webhook Discord pour notifications | `https://discord.com/api/webhooks/...` |
|
||||
|
||||
**Note** : Si ces secrets ne sont pas définis, la CI/CD utilisera les valeurs par défaut (`http://localhost:4000` et `http://localhost:3000`).
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Déclencher la CI/CD
|
||||
|
||||
Une fois le secret `REGISTRY_TOKEN` configuré :
|
||||
|
||||
### Option 1 : Push sur preprod (Recommandé)
|
||||
|
||||
```bash
|
||||
# Committer les derniers changements
|
||||
git add .
|
||||
git commit -m "feat: add automatic migrations and Docker fixes"
|
||||
|
||||
# Push sur la branche preprod
|
||||
git push origin preprod
|
||||
```
|
||||
|
||||
La CI/CD se déclenchera automatiquement et :
|
||||
1. ✅ Build l'image backend (AMD64 + ARM64)
|
||||
2. ✅ Build l'image frontend (AMD64 + ARM64)
|
||||
3. ✅ Push vers le registry Scaleway
|
||||
4. ✅ Envoie une notification Discord (si configuré)
|
||||
|
||||
**Note** : Le build multi-architecture prend ~10-15 min (au lieu de ~5-7 min pour AMD64 seul). Voir [ARM64_SUPPORT.md](ARM64_SUPPORT.md) pour plus de détails.
|
||||
|
||||
### Option 2 : Re-run un Workflow Existant
|
||||
|
||||
1. Aller sur GitHub → **Actions**
|
||||
2. Sélectionner le dernier workflow
|
||||
3. Cliquer sur **Re-run all jobs**
|
||||
|
||||
---
|
||||
|
||||
## 📊 Vérifier que ça fonctionne
|
||||
|
||||
### 1. Vérifier les Logs GitHub Actions
|
||||
|
||||
1. GitHub → **Actions**
|
||||
2. Cliquer sur le workflow en cours
|
||||
3. Vérifier les étapes :
|
||||
- ✅ `Build and push Backend Docker image`
|
||||
- ✅ `Build and push Frontend Docker image`
|
||||
|
||||
**Logs attendus** :
|
||||
```
|
||||
Building image...
|
||||
Pushing to rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
|
||||
✓ Image pushed successfully
|
||||
```
|
||||
|
||||
### 2. Vérifier sur Scaleway Console
|
||||
|
||||
1. [console.scaleway.com](https://console.scaleway.com)
|
||||
2. **Container Registry** → `weworkstudio`
|
||||
3. Vérifier que vous voyez :
|
||||
- ✅ `xpeditis-backend:preprod`
|
||||
- ✅ `xpeditis-frontend:preprod`
|
||||
|
||||
### 3. Vérifier avec Docker CLI
|
||||
|
||||
```bash
|
||||
# Login au registry
|
||||
docker login rg.fr-par.scw.cloud/weworkstudio
|
||||
|
||||
# Vérifier que les images existent (multi-architecture)
|
||||
docker manifest inspect rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
|
||||
docker manifest inspect rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend:preprod
|
||||
|
||||
# Si vous voyez du JSON avec "manifests": [{ "platform": { "architecture": "amd64" }}, { "platform": { "architecture": "arm64" }}]
|
||||
# Les images multi-architecture existent ✅
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Tags Créés par la CI/CD
|
||||
|
||||
La CI/CD crée automatiquement ces tags :
|
||||
|
||||
| Image | Tag | Quand |
|
||||
|-------|-----|-------|
|
||||
| `xpeditis-backend` | `preprod` | À chaque push sur `preprod` |
|
||||
| `xpeditis-frontend` | `preprod` | À chaque push sur `preprod` |
|
||||
| `xpeditis-backend` | `latest` | Si `preprod` est la branche par défaut |
|
||||
| `xpeditis-frontend` | `latest` | Si `preprod` est la branche par défaut |
|
||||
|
||||
**Configuration actuelle dans `.github/workflows/ci.yml`** :
|
||||
|
||||
```yaml
|
||||
tags: |
|
||||
type=ref,event=branch # Tag avec le nom de la branche
|
||||
type=raw,value=latest,enable={{is_default_branch}} # Tag 'latest' si branche par défaut
|
||||
```
|
||||
|
||||
Pour la branche `preprod`, cela crée :
|
||||
- `rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod`
|
||||
- `rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend:preprod`
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Problèmes Courants
|
||||
|
||||
### Erreur : "denied: requested access to the resource is denied"
|
||||
|
||||
**Cause** : Le secret `REGISTRY_TOKEN` n'est pas configuré ou invalide
|
||||
|
||||
**Solution** :
|
||||
1. Vérifier que le secret existe : GitHub → Settings → Secrets → Actions
|
||||
2. Régénérer un token sur Scaleway Console
|
||||
3. Mettre à jour le secret dans GitHub
|
||||
|
||||
---
|
||||
|
||||
### Erreur : "manifest unknown: manifest unknown"
|
||||
|
||||
**Cause** : L'image n'existe pas dans le registry
|
||||
|
||||
**Solution** :
|
||||
1. Vérifier que la CI/CD s'est exécutée sans erreur
|
||||
2. Vérifier les logs de l'étape `Build and push Docker image`
|
||||
3. Re-run le workflow si nécessaire
|
||||
|
||||
---
|
||||
|
||||
### Erreur : "server gave HTTP response to HTTPS client"
|
||||
|
||||
**Cause** : Configuration Docker incorrecte
|
||||
|
||||
**Solution** :
|
||||
Le registry Scaleway utilise toujours HTTPS. Si vous voyez cette erreur, vérifier que l'URL du registry est correcte :
|
||||
```yaml
|
||||
registry: rg.fr-par.scw.cloud/weworkstudio # ✅ Correct
|
||||
registry: rg.fr-par.scw.cloud # ❌ Incorrect
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Après Configuration
|
||||
|
||||
Une fois le secret configuré et la CI/CD exécutée :
|
||||
|
||||
### 1. Portainer Pourra Pull les Images
|
||||
|
||||
Dans Portainer, lors de l'update du stack :
|
||||
```yaml
|
||||
xpeditis-backend:
|
||||
image: rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
|
||||
# ✅ Cette image existe maintenant dans le registry
|
||||
|
||||
xpeditis-frontend:
|
||||
image: rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend:preprod
|
||||
# ✅ Cette image existe maintenant dans le registry
|
||||
```
|
||||
|
||||
### 2. Workflow Automatique
|
||||
|
||||
À chaque push sur `preprod` :
|
||||
1. ✅ CI/CD build les images
|
||||
2. ✅ CI/CD push vers le registry
|
||||
3. ✅ Portainer peut pull les nouvelles images
|
||||
4. ✅ Notification Discord envoyée
|
||||
|
||||
**Plus besoin de build et push manuellement !**
|
||||
|
||||
---
|
||||
|
||||
## 📝 Résumé des Actions à Faire
|
||||
|
||||
- [ ] **Étape 1** : Obtenir le token Scaleway (Console → Container Registry → Push/Pull credentials)
|
||||
- [ ] **Étape 2** : Ajouter le secret `REGISTRY_TOKEN` dans GitHub (Settings → Secrets → Actions)
|
||||
- [ ] **Étape 3** : Push sur `preprod` pour déclencher la CI/CD
|
||||
- [ ] **Étape 4** : Vérifier sur GitHub Actions que le workflow réussit
|
||||
- [ ] **Étape 5** : Vérifier sur Scaleway Console que les images sont là
|
||||
- [ ] **Étape 6** : Update le stack Portainer avec re-pull image
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Liens Utiles
|
||||
|
||||
- [Scaleway Console](https://console.scaleway.com/registry/namespaces)
|
||||
- [GitHub Actions (votre repo)](https://github.com/VOTRE_USERNAME/xpeditis/actions)
|
||||
- [Docker Login Action](https://github.com/docker/login-action)
|
||||
- [Docker Build Push Action](https://github.com/docker/build-push-action)
|
||||
- [ARM64 Support Documentation](ARM64_SUPPORT.md) - Multi-architecture builds
|
||||
|
||||
---
|
||||
|
||||
## ✅ Confirmation que tout fonctionne
|
||||
|
||||
Une fois tout configuré, vous devriez voir dans GitHub Actions :
|
||||
|
||||
```
|
||||
✓ Checkout code
|
||||
✓ Setup Node.js
|
||||
✓ Install dependencies
|
||||
✓ Lint code
|
||||
✓ Run unit tests
|
||||
✓ Build application
|
||||
✓ Set up Docker Buildx
|
||||
✓ Login to Scaleway Registry
|
||||
✓ Extract metadata for Docker
|
||||
✓ Build and push Backend Docker image
|
||||
→ Pushing to rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
|
||||
→ Image pushed successfully
|
||||
✓ Deployment Summary
|
||||
✓ Discord Notification (Success)
|
||||
```
|
||||
|
||||
Et dans Portainer, l'update du stack réussira sans erreur de pull ! 🎉
|
||||
|
||||
---
|
||||
|
||||
**Date** : 2025-11-19
|
||||
**Version** : 1.0
|
||||
**Statut** : Configuration requise pour activer la CI/CD
|
||||
199
DEPLOYMENT_READY.md
Normal file
199
DEPLOYMENT_READY.md
Normal file
@ -0,0 +1,199 @@
|
||||
# 🚀 Xpeditis - Prêt pour Déploiement
|
||||
|
||||
## ✅ Tous les Problèmes Résolus
|
||||
|
||||
### 1. Migrations Automatiques ✅
|
||||
- **Problème** : Tables manquantes (`notifications`, `webhooks`, etc.)
|
||||
- **Solution** : Script `apps/backend/startup.js` exécute les migrations au démarrage Docker
|
||||
- **Fichiers** :
|
||||
- [apps/backend/startup.js](apps/backend/startup.js) - Script Node.js qui attend PostgreSQL + lance migrations
|
||||
- [apps/backend/Dockerfile](apps/backend/Dockerfile) - Modifié pour utiliser `startup.js`
|
||||
|
||||
### 2. Configuration Portainer Synchronisée ✅
|
||||
- **Problème** : Variables d'environnement manquantes dans Portainer stack
|
||||
- **Solution** : Ajout de toutes les variables depuis `docker-compose.dev.yml`
|
||||
- **Fichiers** :
|
||||
- [docker/portainer-stack.yml](docker/portainer-stack.yml) - Configuration complète et corrigée
|
||||
|
||||
### 3. Erreurs YAML Corrigées ✅
|
||||
- **Problème** : `DATABASE_LOGGING must be a string, number or null`
|
||||
- **Solution** : Conversion de tous les booléens et nombres en strings
|
||||
- **Documentation** : [PORTAINER_YAML_FIX.md](PORTAINER_YAML_FIX.md)
|
||||
|
||||
### 4. Support ARM64 Ajouté ✅
|
||||
- **Problème** : Serveur Portainer est ARM64, images CI/CD étaient AMD64 uniquement
|
||||
- **Solution** : Build multi-architecture (AMD64 + ARM64)
|
||||
- **Fichiers** :
|
||||
- [.github/workflows/ci.yml](.github/workflows/ci.yml) - Ajout `platforms: linux/amd64,linux/arm64`
|
||||
- **Documentation** : [ARM64_SUPPORT.md](ARM64_SUPPORT.md), [DOCKER_ARM64_FIX.md](DOCKER_ARM64_FIX.md)
|
||||
|
||||
## 📋 Checklist de Déploiement
|
||||
|
||||
### Préparation (Local)
|
||||
|
||||
- [x] ✅ Migrations automatiques implémentées
|
||||
- [x] ✅ Configuration Portainer synchronisée
|
||||
- [x] ✅ YAML type errors corrigés
|
||||
- [x] ✅ Support ARM64 ajouté
|
||||
- [x] ✅ Documentation complète créée
|
||||
|
||||
### Configuration GitHub (À FAIRE)
|
||||
|
||||
- [ ] **Configurer le secret `REGISTRY_TOKEN`** (REQUIS)
|
||||
1. Aller sur [Scaleway Console](https://console.scaleway.com/registry/namespaces)
|
||||
2. Container Registry → `weworkstudio` → Push/Pull credentials
|
||||
3. Copier le token
|
||||
4. GitHub → Settings → Secrets → Actions → New repository secret
|
||||
5. Name: `REGISTRY_TOKEN`, Value: [token Scaleway]
|
||||
|
||||
- [ ] **Optionnel : Autres secrets**
|
||||
- `NEXT_PUBLIC_API_URL` : `https://api.preprod.xpeditis.com`
|
||||
- `NEXT_PUBLIC_APP_URL` : `https://app.preprod.xpeditis.com`
|
||||
- `DISCORD_WEBHOOK_URL` : URL webhook Discord
|
||||
|
||||
### Déploiement (À FAIRE)
|
||||
|
||||
- [ ] **Commit et push**
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "feat: automatic migrations + ARM64 support + Portainer fixes"
|
||||
git push origin preprod
|
||||
```
|
||||
|
||||
- [ ] **Vérifier CI/CD (GitHub Actions)**
|
||||
- Aller sur [GitHub Actions](https://github.com/VOTRE_USERNAME/xpeditis/actions)
|
||||
- Attendre ~10-15 min (build multi-architecture)
|
||||
- Vérifier que les jobs réussissent :
|
||||
- ✅ Backend - Build, Test & Push
|
||||
- ✅ Frontend - Build, Test & Push
|
||||
|
||||
- [ ] **Vérifier le Registry Scaleway**
|
||||
- Aller sur [Scaleway Console](https://console.scaleway.com/registry/namespaces)
|
||||
- Vérifier que les images existent :
|
||||
- ✅ `xpeditis-backend:preprod`
|
||||
- ✅ `xpeditis-frontend:preprod`
|
||||
- Vérifier qu'elles sont multi-architecture :
|
||||
```bash
|
||||
docker manifest inspect rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
|
||||
# Doit montrer "amd64" ET "arm64"
|
||||
```
|
||||
|
||||
- [ ] **Déployer sur Portainer**
|
||||
1. Copier le contenu de [docker/portainer-stack.yml](docker/portainer-stack.yml)
|
||||
2. Aller sur Portainer → Stacks → Votre stack
|
||||
3. Click "Editor"
|
||||
4. Remplacer tout le contenu
|
||||
5. Cocher "Re-pull image and redeploy"
|
||||
6. Click "Update the stack"
|
||||
|
||||
- [ ] **Vérifier le déploiement**
|
||||
- Backend : `https://api.preprod.xpeditis.com/api/v1/health`
|
||||
- Frontend : `https://app.preprod.xpeditis.com`
|
||||
- Vérifier les logs Portainer :
|
||||
```
|
||||
✅ PostgreSQL is ready
|
||||
✅ Successfully ran X migration(s)
|
||||
✅ Database migrations completed
|
||||
🚀 Starting NestJS application...
|
||||
```
|
||||
|
||||
## 📚 Documentation
|
||||
|
||||
### Guides Techniques
|
||||
- [ARM64_SUPPORT.md](ARM64_SUPPORT.md) - Support multi-architecture détaillé
|
||||
- [DOCKER_ARM64_FIX.md](DOCKER_ARM64_FIX.md) - Résumé du fix ARM64
|
||||
- [PORTAINER_YAML_FIX.md](PORTAINER_YAML_FIX.md) - Fix des erreurs YAML
|
||||
- [CICD_REGISTRY_SETUP.md](CICD_REGISTRY_SETUP.md) - Configuration CI/CD complète
|
||||
- [REGISTRY_PUSH_GUIDE.md](REGISTRY_PUSH_GUIDE.md) - Guide push manuel (fallback)
|
||||
|
||||
### Fichiers Modifiés (Session Actuelle)
|
||||
```
|
||||
.github/workflows/ci.yml # ARM64 support (2 lignes)
|
||||
docker/portainer-stack.yml # Variables + type fixes
|
||||
apps/backend/startup.js # Migrations automatiques (NEW)
|
||||
apps/backend/Dockerfile # CMD vers startup.js
|
||||
```
|
||||
|
||||
### Documentation Précédente (Toujours Valide)
|
||||
- [PORTAINER_MIGRATION_AUTO.md](PORTAINER_MIGRATION_AUTO.md) - Migrations automatiques
|
||||
- [DEPLOYMENT_CHECKLIST.md](DEPLOYMENT_CHECKLIST.md) - Checklist déploiement
|
||||
- [CHANGES_SUMMARY.md](CHANGES_SUMMARY.md) - Résumé exhaustif
|
||||
- [DEPLOY_README.md](DEPLOY_README.md) - Guide déploiement rapide
|
||||
|
||||
## 🎯 Résumé des Images Docker
|
||||
|
||||
### Backend
|
||||
```yaml
|
||||
Image: rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
|
||||
Architectures: linux/amd64, linux/arm64
|
||||
Features:
|
||||
- Migrations automatiques au démarrage
|
||||
- Wait for PostgreSQL (30 retries)
|
||||
- NestJS avec TypeORM
|
||||
- Support multi-architecture
|
||||
```
|
||||
|
||||
### Frontend
|
||||
```yaml
|
||||
Image: rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend:preprod
|
||||
Architectures: linux/amd64, linux/arm64
|
||||
Features:
|
||||
- Next.js 14 production build
|
||||
- Tailwind CSS compilé
|
||||
- Support multi-architecture
|
||||
```
|
||||
|
||||
## ⚡ Performance Attendue
|
||||
|
||||
| Métrique | Valeur |
|
||||
|----------|--------|
|
||||
| Build CI/CD (multi-arch) | ~10-15 min |
|
||||
| Démarrage backend (avec migrations) | ~30-60s |
|
||||
| Démarrage frontend | ~5-10s |
|
||||
| Temps déploiement Portainer | ~2-3 min |
|
||||
|
||||
## 🔧 Troubleshooting
|
||||
|
||||
### Erreur : "no matching manifest for linux/arm64"
|
||||
**Cause** : Images pas encore buildées avec ARM64 support
|
||||
**Solution** : Attendre que la CI/CD se termine après le push
|
||||
|
||||
### Erreur : "relation does not exist"
|
||||
**Cause** : Migrations pas exécutées
|
||||
**Solution** : Vérifier les logs backend, le script `startup.js` doit s'exécuter
|
||||
|
||||
### Erreur : "denied: requested access to the resource is denied"
|
||||
**Cause** : Secret `REGISTRY_TOKEN` pas configuré ou invalide
|
||||
**Solution** : Vérifier le secret dans GitHub Settings → Secrets → Actions
|
||||
|
||||
### Portainer ne peut pas pull les images
|
||||
**Cause 1** : Images pas encore dans le registry (CI/CD pas terminée)
|
||||
**Cause 2** : Registry credentials Portainer invalides
|
||||
**Solution** : Vérifier Portainer → Registries → Scaleway credentials
|
||||
|
||||
## 📊 État du Projet
|
||||
|
||||
| Composant | Status | Version |
|
||||
|-----------|--------|---------|
|
||||
| Backend API | ✅ Prêt | NestJS 10+ |
|
||||
| Frontend | ✅ Prêt | Next.js 14+ |
|
||||
| Database | ✅ PostgreSQL 15 | Migrations auto |
|
||||
| Cache | ✅ Redis 7 | TTL 15min |
|
||||
| Storage | ✅ MinIO/S3 | Compatible |
|
||||
| CI/CD | ✅ GitHub Actions | Multi-arch |
|
||||
| Portainer | ⏳ Attente déploiement | ARM64 ready |
|
||||
|
||||
## 🎉 Prochaine Étape
|
||||
|
||||
**URGENT** : Configurer le secret `REGISTRY_TOKEN` sur GitHub pour débloquer le déploiement.
|
||||
|
||||
Une fois fait :
|
||||
1. Push sur `preprod` → CI/CD build les images → Images disponibles dans registry
|
||||
2. Update stack Portainer → Pull images ARM64 → Déploiement réussi ✅
|
||||
|
||||
---
|
||||
|
||||
**Date** : 2025-11-19
|
||||
**Status** : ✅ Prêt pour déploiement (attente configuration secret GitHub)
|
||||
**Blocage** : Secret `REGISTRY_TOKEN` requis
|
||||
**ETA Déploiement** : ~30 min après configuration secret
|
||||
145
DOCKER_ARM64_FIX.md
Normal file
145
DOCKER_ARM64_FIX.md
Normal file
@ -0,0 +1,145 @@
|
||||
# 🔧 Fix Critique : Support ARM64 pour Portainer
|
||||
|
||||
## 🚨 Problème Identifié
|
||||
|
||||
Votre serveur Portainer tourne sur architecture **ARM64**, mais la CI/CD buildait uniquement des images **AMD64**, causant des erreurs :
|
||||
|
||||
```
|
||||
ERROR: no matching manifest for linux/arm64/v8
|
||||
```
|
||||
|
||||
## ✅ Solution Implémentée
|
||||
|
||||
### Modification de `.github/workflows/ci.yml`
|
||||
|
||||
**Changement Backend (ligne 73)** :
|
||||
```yaml
|
||||
# Avant
|
||||
platforms: linux/amd64
|
||||
|
||||
# Après
|
||||
platforms: linux/amd64,linux/arm64
|
||||
```
|
||||
|
||||
**Changement Frontend (ligne 141)** :
|
||||
```yaml
|
||||
# Avant
|
||||
platforms: linux/amd64
|
||||
|
||||
# Après
|
||||
platforms: linux/amd64,linux/arm64
|
||||
```
|
||||
|
||||
## 📦 Résultat
|
||||
|
||||
Les images Docker sont maintenant **multi-architecture** et fonctionnent sur :
|
||||
- ✅ Serveurs AMD64 (x86_64) - Cloud classique
|
||||
- ✅ Serveurs ARM64 (aarch64) - Raspberry Pi, Apple Silicon, serveurs ARM
|
||||
|
||||
Docker/Portainer détecte automatiquement l'architecture du serveur et pull la bonne image.
|
||||
|
||||
## 🚀 Prochaines Étapes
|
||||
|
||||
### 1. Configurer GitHub Secret
|
||||
|
||||
```bash
|
||||
# Sur Scaleway Console
|
||||
1. Container Registry → weworkstudio → Push/Pull credentials
|
||||
2. Copier le token
|
||||
|
||||
# Sur GitHub
|
||||
1. Settings → Secrets → Actions → New repository secret
|
||||
2. Name: REGISTRY_TOKEN
|
||||
3. Value: [coller le token Scaleway]
|
||||
```
|
||||
|
||||
### 2. Commit et Push
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "feat: add ARM64 support for multi-architecture Docker builds"
|
||||
git push origin preprod
|
||||
```
|
||||
|
||||
### 3. Attendre la CI/CD (~10-15 min)
|
||||
|
||||
GitHub Actions va :
|
||||
1. Build l'image backend pour AMD64 + ARM64
|
||||
2. Build l'image frontend pour AMD64 + ARM64
|
||||
3. Push vers le registry Scaleway
|
||||
|
||||
### 4. Déployer sur Portainer
|
||||
|
||||
```yaml
|
||||
# Portainer Stack (déjà configuré dans docker/portainer-stack.yml)
|
||||
xpeditis-backend:
|
||||
image: rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
|
||||
# ✅ Pull automatiquement l'image ARM64
|
||||
|
||||
xpeditis-frontend:
|
||||
image: rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend:preprod
|
||||
# ✅ Pull automatiquement l'image ARM64
|
||||
```
|
||||
|
||||
1. Copier le contenu de `docker/portainer-stack.yml`
|
||||
2. Update stack dans Portainer
|
||||
3. Cocher "Re-pull image and redeploy"
|
||||
4. ✅ Déploiement réussi !
|
||||
|
||||
## 📊 Impact
|
||||
|
||||
| Métrique | Avant | Après |
|
||||
|----------|-------|-------|
|
||||
| Architectures supportées | AMD64 uniquement | AMD64 + ARM64 |
|
||||
| Compatible serveur ARM | ❌ Non | ✅ Oui |
|
||||
| Temps de build CI/CD | ~7 min | ~15 min |
|
||||
| Taille registry | 1x | 2x (manifest) |
|
||||
|
||||
## 🔍 Vérification
|
||||
|
||||
```bash
|
||||
# Vérifier que les deux architectures sont 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"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## 📚 Documentation Complète
|
||||
|
||||
- [ARM64_SUPPORT.md](ARM64_SUPPORT.md) - Documentation technique complète
|
||||
- [CICD_REGISTRY_SETUP.md](CICD_REGISTRY_SETUP.md) - Configuration CI/CD
|
||||
- [docker/portainer-stack.yml](docker/portainer-stack.yml) - Stack Portainer
|
||||
|
||||
## ✅ Checklist de Déploiement
|
||||
|
||||
- [x] Modifier `.github/workflows/ci.yml` pour ARM64
|
||||
- [x] Créer documentation ARM64_SUPPORT.md
|
||||
- [x] Mettre à jour CICD_REGISTRY_SETUP.md
|
||||
- [ ] Configurer secret `REGISTRY_TOKEN` sur GitHub
|
||||
- [ ] Push sur `preprod` pour trigger CI/CD
|
||||
- [ ] Vérifier build réussi sur GitHub Actions
|
||||
- [ ] Vérifier images dans Scaleway Registry
|
||||
- [ ] Update stack Portainer
|
||||
- [ ] Vérifier déploiement réussi
|
||||
|
||||
---
|
||||
|
||||
**Date** : 2025-11-19
|
||||
**Status** : ✅ Fix implémenté, prêt pour déploiement
|
||||
**Impact** : 🎯 Critique - Résout incompatibilité architecture
|
||||
149
PORTAINER_YAML_FIX.md
Normal file
149
PORTAINER_YAML_FIX.md
Normal file
@ -0,0 +1,149 @@
|
||||
# 🔧 Fix Portainer YAML - Types de Variables d'Environnement
|
||||
|
||||
## ❌ Problème
|
||||
|
||||
Lors du déploiement sur Portainer, vous pouvez rencontrer cette erreur :
|
||||
|
||||
```
|
||||
Deployment error
|
||||
services.xpeditis-backend.environment.DATABASE_LOGGING must be a string, number or null
|
||||
```
|
||||
|
||||
## 📝 Explication
|
||||
|
||||
Dans Docker Compose version 3.x (utilisé par Portainer), **toutes les variables d'environnement doivent être des strings**.
|
||||
|
||||
Les valeurs **booléennes** (`true`, `false`) et **numériques** sans guillemets (`5432`, `10`, `0`) ne sont **PAS acceptées** par Portainer, même si elles fonctionnent en local avec `docker-compose`.
|
||||
|
||||
### Pourquoi ça fonctionne en local ?
|
||||
|
||||
Docker Compose CLI (utilisé en local) est plus permissif et convertit automatiquement les types. Portainer est plus strict et applique la spécification YAML à la lettre.
|
||||
|
||||
## ✅ Solution
|
||||
|
||||
Convertir **toutes** les valeurs non-string en strings avec des guillemets :
|
||||
|
||||
### ❌ Avant (ne fonctionne pas sur Portainer)
|
||||
|
||||
```yaml
|
||||
environment:
|
||||
PORT: 4000 # ❌ Number
|
||||
DATABASE_PORT: 5432 # ❌ Number
|
||||
DATABASE_SYNC: false # ❌ Boolean
|
||||
DATABASE_LOGGING: false # ❌ Boolean
|
||||
REDIS_DB: 0 # ❌ Number
|
||||
BCRYPT_ROUNDS: 10 # ❌ Number
|
||||
SESSION_TIMEOUT_MS: 7200000 # ❌ Number
|
||||
RATE_LIMIT_TTL: 60 # ❌ Number
|
||||
RATE_LIMIT_MAX: 100 # ❌ Number
|
||||
```
|
||||
|
||||
### ✅ Après (fonctionne sur Portainer)
|
||||
|
||||
```yaml
|
||||
environment:
|
||||
PORT: "4000" # ✅ String
|
||||
DATABASE_PORT: "5432" # ✅ String
|
||||
DATABASE_SYNC: "false" # ✅ String
|
||||
DATABASE_LOGGING: "false" # ✅ String
|
||||
REDIS_DB: "0" # ✅ String
|
||||
BCRYPT_ROUNDS: "10" # ✅ String
|
||||
SESSION_TIMEOUT_MS: "7200000" # ✅ String
|
||||
RATE_LIMIT_TTL: "60" # ✅ String
|
||||
RATE_LIMIT_MAX: "100" # ✅ String
|
||||
```
|
||||
|
||||
## 🔍 Variables Modifiées
|
||||
|
||||
Dans `docker/portainer-stack.yml`, les variables suivantes ont été converties en strings :
|
||||
|
||||
| Variable | Avant | Après |
|
||||
|----------|-------|-------|
|
||||
| `PORT` | `4000` | `"4000"` |
|
||||
| `DATABASE_PORT` | `5432` | `"5432"` |
|
||||
| `DATABASE_SYNC` | `false` | `"false"` |
|
||||
| `DATABASE_LOGGING` | `false` | `"false"` |
|
||||
| `REDIS_PORT` | `6379` | `"6379"` |
|
||||
| `REDIS_DB` | `0` | `"0"` |
|
||||
| `BCRYPT_ROUNDS` | `10` | `"10"` |
|
||||
| `SESSION_TIMEOUT_MS` | `7200000` | `"7200000"` |
|
||||
| `RATE_LIMIT_TTL` | `60` | `"60"` |
|
||||
| `RATE_LIMIT_MAX` | `100` | `"100"` |
|
||||
|
||||
## 💡 Comment l'application interprète les valeurs ?
|
||||
|
||||
Ne vous inquiétez pas ! Même si les variables sont des **strings**, l'application NestJS les convertira automatiquement au bon type :
|
||||
|
||||
```typescript
|
||||
// Dans le code NestJS
|
||||
const port = parseInt(process.env.PORT, 10); // "4000" → 4000
|
||||
const dbPort = parseInt(process.env.DATABASE_PORT, 10); // "5432" → 5432
|
||||
const dbSync = process.env.DATABASE_SYNC === 'true'; // "false" → false
|
||||
const redisDb = parseInt(process.env.REDIS_DB, 10); // "0" → 0
|
||||
```
|
||||
|
||||
Le module `@nestjs/config` et les validateurs `class-validator` gèrent cette conversion automatiquement.
|
||||
|
||||
## 🧪 Test de Validation
|
||||
|
||||
Pour vérifier que votre `portainer-stack.yml` est correct :
|
||||
|
||||
```bash
|
||||
# 1. Vérifier la syntaxe YAML
|
||||
docker-compose -f docker/portainer-stack.yml config
|
||||
|
||||
# 2. Vérifier qu'il n'y a pas d'erreurs de validation
|
||||
# (Devrait afficher la configuration sans erreur)
|
||||
```
|
||||
|
||||
Si vous voyez des erreurs comme :
|
||||
- `must be a string`
|
||||
- `must be a number`
|
||||
- `must be null`
|
||||
|
||||
Alors il faut ajouter des guillemets autour de la valeur.
|
||||
|
||||
## 📋 Checklist de Vérification
|
||||
|
||||
Avant de déployer sur Portainer, vérifier que :
|
||||
|
||||
- [ ] Tous les **ports** sont entre guillemets : `"4000"`, `"5432"`, `"6379"`
|
||||
- [ ] Tous les **booléens** sont entre guillemets : `"true"`, `"false"`
|
||||
- [ ] Tous les **nombres** sont entre guillemets : `"10"`, `"0"`, `"7200000"`
|
||||
- [ ] Les **strings** peuvent rester sans guillemets ou avec : `preprod` ou `"preprod"`
|
||||
- [ ] Les **URLs** peuvent rester sans guillemets : `https://api.preprod.xpeditis.com`
|
||||
|
||||
## ⚠️ Exception : PostgreSQL et Redis
|
||||
|
||||
Pour les services PostgreSQL et Redis, certaines valeurs peuvent rester sans guillemets car elles sont utilisées par les images officielles qui sont plus permissives :
|
||||
|
||||
```yaml
|
||||
# PostgreSQL - OK sans guillemets
|
||||
environment:
|
||||
POSTGRES_DB: xpeditis_preprod
|
||||
POSTGRES_USER: xpeditis
|
||||
POSTGRES_PASSWORD: 9Lc3M9qoPBeHLKHDXGUf1
|
||||
|
||||
# Redis - Commande avec guillemets pour la sécurité
|
||||
command: redis-server --requirepass hXiy5GMPswMtxMZujjS2O --appendonly yes
|
||||
```
|
||||
|
||||
Mais pour **votre application backend**, utilisez **toujours des guillemets** pour les valeurs non-string.
|
||||
|
||||
## 🔗 Références
|
||||
|
||||
- [Docker Compose Environment Variables](https://docs.docker.com/compose/environment-variables/)
|
||||
- [Portainer Stack Deployment](https://docs.portainer.io/user/docker/stacks/add)
|
||||
- [YAML Specification](https://yaml.org/spec/1.2/spec.html)
|
||||
|
||||
## 📄 Fichier Corrigé
|
||||
|
||||
Le fichier `docker/portainer-stack.yml` a été corrigé avec toutes les valeurs en strings.
|
||||
|
||||
**Avant déploiement**, vérifier que le fichier ne contient plus de valeurs booléennes ou numériques brutes dans la section `environment` du service `xpeditis-backend`.
|
||||
|
||||
---
|
||||
|
||||
**Date** : 2025-11-19
|
||||
**Version** : 1.1
|
||||
**Statut** : ✅ Corrigé et prêt pour déploiement
|
||||
340
REGISTRY_PUSH_GUIDE.md
Normal file
340
REGISTRY_PUSH_GUIDE.md
Normal file
@ -0,0 +1,340 @@
|
||||
# 🚀 Guide Push Images vers Registry Scaleway
|
||||
|
||||
## ❌ Problème
|
||||
|
||||
Portainer ne peut pas pull les images car elles n'existent pas dans le registry Scaleway :
|
||||
- `rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod`
|
||||
- `rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend:preprod`
|
||||
|
||||
## 📋 Checklist Avant de Push
|
||||
|
||||
- [ ] Docker Desktop est démarré
|
||||
- [ ] Vous avez accès au registry Scaleway
|
||||
- [ ] Les images locales sont à jour avec les dernières modifications
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Solution Étape par Étape
|
||||
|
||||
### Étape 1 : Login au Registry Scaleway
|
||||
|
||||
```bash
|
||||
# Login avec les credentials Scaleway
|
||||
docker login rg.fr-par.scw.cloud/weworkstudio
|
||||
|
||||
# Vous serez invité à entrer :
|
||||
# Username: <votre_username_scaleway>
|
||||
# Password: <votre_token_scaleway>
|
||||
```
|
||||
|
||||
**Si vous n'avez pas les credentials** :
|
||||
1. Aller sur [console.scaleway.com](https://console.scaleway.com)
|
||||
2. Container Registry → weworkstudio
|
||||
3. Generate API token
|
||||
4. Copier le token
|
||||
|
||||
---
|
||||
|
||||
### Étape 2 : Build Backend avec le bon tag
|
||||
|
||||
```bash
|
||||
# Se positionner dans le dossier backend
|
||||
cd apps/backend
|
||||
|
||||
# Build l'image avec le tag Scaleway
|
||||
docker build \
|
||||
--platform linux/amd64 \
|
||||
-t rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod \
|
||||
.
|
||||
|
||||
# Vérifier que l'image est créée
|
||||
docker images | grep xpeditis-backend
|
||||
|
||||
# Devrait afficher :
|
||||
# rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend preprod <IMAGE_ID> <TIME> 337MB
|
||||
```
|
||||
|
||||
⏱️ **Temps estimé** : 2-3 minutes
|
||||
|
||||
---
|
||||
|
||||
### Étape 3 : Push Backend vers Registry
|
||||
|
||||
```bash
|
||||
# Push l'image backend
|
||||
docker push rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
|
||||
|
||||
# Vous devriez voir :
|
||||
# The push refers to repository [rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend]
|
||||
# preprod: digest: sha256:... size: ...
|
||||
```
|
||||
|
||||
⏱️ **Temps estimé** : 3-5 minutes (selon connexion)
|
||||
|
||||
---
|
||||
|
||||
### Étape 4 : Build Frontend avec le bon tag
|
||||
|
||||
```bash
|
||||
# Retour à la racine
|
||||
cd ../..
|
||||
|
||||
# Se positionner dans le dossier frontend
|
||||
cd apps/frontend
|
||||
|
||||
# Build l'image avec le tag Scaleway
|
||||
docker build \
|
||||
--platform linux/amd64 \
|
||||
-t rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend:preprod \
|
||||
.
|
||||
|
||||
# Vérifier que l'image est créée
|
||||
docker images | grep xpeditis-frontend
|
||||
|
||||
# Devrait afficher :
|
||||
# rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend preprod <IMAGE_ID> <TIME> 165MB
|
||||
```
|
||||
|
||||
⏱️ **Temps estimé** : 2-3 minutes
|
||||
|
||||
---
|
||||
|
||||
### Étape 5 : Push Frontend vers Registry
|
||||
|
||||
```bash
|
||||
# Push l'image frontend
|
||||
docker push rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend:preprod
|
||||
|
||||
# Vous devriez voir :
|
||||
# The push refers to repository [rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend]
|
||||
# preprod: digest: sha256:... size: ...
|
||||
```
|
||||
|
||||
⏱️ **Temps estimé** : 2-3 minutes
|
||||
|
||||
---
|
||||
|
||||
### Étape 6 : Vérifier sur Scaleway Console
|
||||
|
||||
1. Aller sur [console.scaleway.com](https://console.scaleway.com)
|
||||
2. Container Registry → weworkstudio
|
||||
3. Vérifier que vous voyez :
|
||||
- ✅ `xpeditis-backend:preprod`
|
||||
- ✅ `xpeditis-frontend:preprod`
|
||||
|
||||
---
|
||||
|
||||
## 🤖 Utilisation du Script Automatisé
|
||||
|
||||
**Option recommandée** : Utiliser le script fourni
|
||||
|
||||
```bash
|
||||
# Rendre le script exécutable
|
||||
chmod +x deploy-to-portainer.sh
|
||||
|
||||
# Option 1 : Build et push tout
|
||||
./deploy-to-portainer.sh all
|
||||
|
||||
# Option 2 : Backend seulement
|
||||
./deploy-to-portainer.sh backend
|
||||
|
||||
# Option 3 : Frontend seulement
|
||||
./deploy-to-portainer.sh frontend
|
||||
```
|
||||
|
||||
Le script fait automatiquement :
|
||||
1. ✅ Vérifie que Docker est démarré
|
||||
2. 🔨 Build les images avec le bon tag
|
||||
3. 📤 Push vers le registry
|
||||
4. 📋 Affiche un résumé
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Vérification des Images sur le Registry
|
||||
|
||||
### Via Docker CLI
|
||||
|
||||
```bash
|
||||
# Vérifier que l'image backend existe
|
||||
docker manifest inspect rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
|
||||
|
||||
# Vérifier que l'image frontend existe
|
||||
docker manifest inspect rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend:preprod
|
||||
|
||||
# Si les commandes retournent un JSON, les images existent ✅
|
||||
# Si erreur "manifest unknown", les images n'existent pas ❌
|
||||
```
|
||||
|
||||
### Via Scaleway Console
|
||||
|
||||
1. Console Scaleway → Container Registry
|
||||
2. Sélectionner `weworkstudio`
|
||||
3. Chercher `xpeditis-backend` et `xpeditis-frontend`
|
||||
4. Vérifier le tag `preprod`
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Erreurs Courantes
|
||||
|
||||
### Erreur 1 : "denied: requested access to the resource is denied"
|
||||
|
||||
**Cause** : Pas authentifié au registry
|
||||
|
||||
**Solution** :
|
||||
```bash
|
||||
docker login rg.fr-par.scw.cloud/weworkstudio
|
||||
# Entrer username et token Scaleway
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Erreur 2 : "no such host"
|
||||
|
||||
**Cause** : URL du registry incorrecte
|
||||
|
||||
**Solution** : Vérifier l'URL exacte dans la console Scaleway
|
||||
|
||||
---
|
||||
|
||||
### Erreur 3 : "server gave HTTP response to HTTPS client"
|
||||
|
||||
**Cause** : Docker essaie d'utiliser HTTP au lieu de HTTPS
|
||||
|
||||
**Solution** :
|
||||
```bash
|
||||
# Vérifier que le registry est en HTTPS
|
||||
# Le registry Scaleway utilise toujours HTTPS
|
||||
# Vérifier votre configuration Docker
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Erreur 4 : Build échoue avec "no space left on device"
|
||||
|
||||
**Cause** : Pas assez d'espace disque
|
||||
|
||||
**Solution** :
|
||||
```bash
|
||||
# Nettoyer les images inutilisées
|
||||
docker system prune -a
|
||||
|
||||
# Vérifier l'espace disponible
|
||||
docker system df
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Après le Push
|
||||
|
||||
Une fois les images pushées :
|
||||
|
||||
1. **Aller sur Portainer** : https://portainer.weworkstudio.com
|
||||
2. **Stacks** → `xpeditis-preprod`
|
||||
3. Cliquer sur **Editor**
|
||||
4. Vérifier que le YAML contient :
|
||||
```yaml
|
||||
xpeditis-backend:
|
||||
image: rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
|
||||
|
||||
xpeditis-frontend:
|
||||
image: rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend:preprod
|
||||
```
|
||||
5. Cocher **✅ Re-pull image and redeploy**
|
||||
6. Cliquer **Update the stack**
|
||||
|
||||
---
|
||||
|
||||
## 📊 Résumé des Commandes
|
||||
|
||||
### Build et Push - Version Complète
|
||||
|
||||
```bash
|
||||
# 1. Login
|
||||
docker login rg.fr-par.scw.cloud/weworkstudio
|
||||
|
||||
# 2. Backend
|
||||
cd apps/backend
|
||||
docker build --platform linux/amd64 -t rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod .
|
||||
docker push rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
|
||||
|
||||
# 3. Frontend
|
||||
cd ../frontend
|
||||
docker build --platform linux/amd64 -t rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend:preprod .
|
||||
docker push rg.fr-par.scw.cloud/weworkstudio/xpeditis-frontend:preprod
|
||||
|
||||
# 4. Vérification
|
||||
cd ../..
|
||||
docker images | grep rg.fr-par.scw.cloud
|
||||
```
|
||||
|
||||
### Build et Push - Version Script
|
||||
|
||||
```bash
|
||||
# Plus simple et recommandé
|
||||
chmod +x deploy-to-portainer.sh
|
||||
./deploy-to-portainer.sh all
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔐 Sécurité
|
||||
|
||||
### Token Scaleway
|
||||
|
||||
**Ne jamais** commit ou partager votre token Scaleway !
|
||||
|
||||
Le token doit être stocké :
|
||||
- ✅ Dans Docker credentials (après `docker login`)
|
||||
- ✅ Dans un gestionnaire de mots de passe
|
||||
- ❌ PAS dans Git
|
||||
- ❌ PAS en clair dans un fichier
|
||||
|
||||
### Rotation des Tokens
|
||||
|
||||
Recommandé de changer le token tous les 90 jours :
|
||||
1. Console Scaleway → API Tokens
|
||||
2. Révoquer l'ancien token
|
||||
3. Créer un nouveau token
|
||||
4. Faire un nouveau `docker login`
|
||||
|
||||
---
|
||||
|
||||
## 📞 Besoin d'Aide ?
|
||||
|
||||
Si les images ne peuvent toujours pas être pullées après ces étapes :
|
||||
|
||||
1. **Vérifier les logs Portainer** :
|
||||
- Stacks → xpeditis-preprod → Logs
|
||||
- Chercher "manifest unknown" ou "access denied"
|
||||
|
||||
2. **Vérifier les permissions** :
|
||||
- Console Scaleway → IAM
|
||||
- Vérifier que votre compte a accès au registry
|
||||
|
||||
3. **Tester manuellement** :
|
||||
```bash
|
||||
# Sur votre machine
|
||||
docker pull rg.fr-par.scw.cloud/weworkstudio/xpeditis-backend:preprod
|
||||
|
||||
# Si ça fonctionne localement mais pas sur Portainer,
|
||||
# le problème vient de l'accès de Portainer au registry
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ✅ Checklist Finale
|
||||
|
||||
Avant de dire que c'est résolu :
|
||||
|
||||
- [ ] `docker login` réussi
|
||||
- [ ] Images backend et frontend buildées
|
||||
- [ ] Images pushées vers le registry Scaleway
|
||||
- [ ] Images visibles sur console.scaleway.com
|
||||
- [ ] `docker manifest inspect` retourne du JSON (pas d'erreur)
|
||||
- [ ] Portainer peut pull les images (pas d'erreur dans les logs)
|
||||
|
||||
---
|
||||
|
||||
**Date** : 2025-11-19
|
||||
**Version** : 1.0
|
||||
**Statut** : Guide complet pour résoudre les problèmes de pull
|
||||
@ -81,23 +81,23 @@ services:
|
||||
- xpeditis-redis
|
||||
environment:
|
||||
NODE_ENV: preprod
|
||||
PORT: 4000
|
||||
PORT: "4000"
|
||||
API_PREFIX: api/v1
|
||||
|
||||
# Database
|
||||
DATABASE_HOST: xpeditis-db
|
||||
DATABASE_PORT: 5432
|
||||
DATABASE_PORT: "5432"
|
||||
DATABASE_USER: xpeditis
|
||||
DATABASE_PASSWORD: 9Lc3M9qoPBeHLKHDXGUf1
|
||||
DATABASE_NAME: xpeditis_preprod
|
||||
DATABASE_SYNC: false
|
||||
DATABASE_LOGGING: false
|
||||
DATABASE_SYNC: "false"
|
||||
DATABASE_LOGGING: "false"
|
||||
|
||||
# Redis
|
||||
REDIS_HOST: xpeditis-redis
|
||||
REDIS_PORT: 6379
|
||||
REDIS_PORT: "6379"
|
||||
REDIS_PASSWORD: hXiy5GMPswMtxMZujjS2O
|
||||
REDIS_DB: 0
|
||||
REDIS_DB: "0"
|
||||
|
||||
# JWT
|
||||
JWT_SECRET: 4C4tQC8qym/evv4zI5DaUE1yy3kilEnm6lApOGD0GgNBLA0BLm2tVyUr1Lr0mTnV
|
||||
@ -120,12 +120,12 @@ services:
|
||||
API_URL: https://api.preprod.xpeditis.com
|
||||
|
||||
# Security
|
||||
BCRYPT_ROUNDS: 10
|
||||
SESSION_TIMEOUT_MS: 7200000
|
||||
BCRYPT_ROUNDS: "10"
|
||||
SESSION_TIMEOUT_MS: "7200000"
|
||||
|
||||
# Rate Limiting
|
||||
RATE_LIMIT_TTL: 60
|
||||
RATE_LIMIT_MAX: 100
|
||||
RATE_LIMIT_TTL: "60"
|
||||
RATE_LIMIT_MAX: "100"
|
||||
|
||||
networks:
|
||||
- xpeditis_internal
|
||||
|
||||
Loading…
Reference in New Issue
Block a user