Héberger une application Vue.js via des buckets S3

## Héberger une application Vue.js via des buckets S3

**Pauline Gilg, développeuse front end**

Université de Strasbourg - DNum (Direction du Numérique)

Note:
				- Université de Strasbourg, Direction du Numérique (DNum), Pôle DIP (Développement, Intégration et Paramétrage)
				- Le DIP = une équipe d'une quinzaine de développeurs, qui développe et maintient des applications de services aux étudiants, aux enseignants et aux chercheurs, ainsi qu'aux services métiers de l'université
				- Je travaille au DIP depuis 3 ans, mon 1er projet = Campulse
				- Le sujet de ma présentation = étude d'un cas concret de déploiement d'une application à l'Université sur S3

---

### 🧩 Le projet [Campulse](https://etu-campulse.fr)

![](images/campulse.png)

Note:
				- Plateforme web pour les associations étudiantes et les Services de la Vie Universitaire (SVU)
				- Fonctionnalités principales : annuaire des associations, outil de signature de chartes, de gestion des demandes de subventions, suivi administratif

---

### 🏦 Financement et mutualisation

- Financement : programme "Services numériques aux étudiants" (France Relance) avec exigence de partage des livrables
				- Passage du code source partagé à une solution clé en main SaaS via le consortium ESUP
				- Mutualisation des services numériques : coûts, compétences et temps de développement optimisés
				- Club utilisateur actif enrichissant l’application selon les besoins de l’ensemble de l’ESR

Note:
				- Le projet a été financé avec comme consigne le partage du livrable (code source)
				- Partager uniquement le code source n’était pas suffisant : les universités partenaires souhaitaient une solution clé en main adaptée à leurs ressources
				- Nous avons fait le choix de proposer une solution SaaS via le consortium ESUP = solution unique dans l’ESR
				- Mutualisation = Optimisation des coûts, du temps de développement et des compétences
				- Club utilisateur qui contribue activement à faire évoluer l’application selon les besoins de tous
				- Groupe de travail multi-établissements qui planche sur les évolutions à venir pour la v2, v3, et plus loin

---

### 🇫🇷 Une portée nationale

- Projet multi-établissements (12+ universités)
				- Toulouse Jean Jaurès, Clermont Auvergne, Unicaen, Rennes 2, Tours, Nantes, Rouen, Picardie, Lille, Montpellier 3
				- Et d'autres à venir !

Note:
				- Le projet a rencontré un fort succès, témoin d'un besoin d'outillage des SVU au niveau national
				- Pas toujours de moyens humains et financiers dans les SVU
				- Option SaaS privilégiée pour mise à dispo massive

---

### 🏗️ Architecture technique

![](images/archi.png)

Note:
				- L'application est construite avec :
				- Front end en Vue.js + infos slide suivante
				- Back end en Django + BDD PostgreSQL
				- Le front consomme une API REST exposée par le back
				- Découplage strict entre front et back
				- Cela permet une flexibilité pour le développement, la configuration, le déploiement, la maintenance et la personnalisation
				- Loads balancers qui répartissent la charge
				- Toute cette architecture est distribuées en SaaS

---

### 🧩 Vue.js, késako ?

- **Framework** front end JavaScript
				- **Build** : compilation de l’app en fichiers statiques (HTML, JS, CSS minifiés)
				- **Données dynamiques** : l’interface réagit aux données de manière réactive
				- Fonctionne en **SPA** (*Single Page Application*) : une seule page, navigation sans rechargement

Note:
				- Framework JavaScript front end (un des 3 principaux frameworks JavaScript avec React et Angular)
				- Les fichiers statiques que nous allons devoir servir en production sont compilés lors d'un build
				- Données dynamiques : pour l'affichage des données récupérées depuis l'API
				- Single Page Application : paramétrage nécessaire côté serveur pour rediriger vers la bonne page

---

- 📦 Produit du *build* : un dossier `/dist` prêt à être servi comme un site web statique :

```
				dist/
				├── index.html
				├── assets/
				│   ├── logo.abc123.svg
				│   ├── style.456def.css
				│   └── app.789ghi.js
				```

---

### 🎨 Enjeux de l'hébergement front

* Autonomie des établissements pour la personnalisation de l'interface (images, couleurs, textes, polices)
				* 2 instances par établissement (préprod / prod)
				* Scalabilité horizontale : pouvoir déployer facilement une nouvelle instance
				* Sécurité

Note:
				- Important pour les établissements de pouvoir transposer leur identité visuelle, de manière autonome
				- 2 instances pour tester les personnalisations et les nouvelles fonctionnalités
				- Scalabilité horizontale : pouvoir facilement ajouter une nouvelle instance dans le futur
				- Sécurité : garantir que chaque instance soit bien isolée et déployée par son établissement

---

### 💡 Solution proposée

- Côté établissement :
					- Personnalisation de l'interface
					- Enregistrement des mises à jour en préprod et/ou prod
				- Côté infrastructure :
					- Détection des mises à jour
					- Build avec personnalisation
					- Hébergement des fichiers statiques dans des buckets S3

Note:
				- Des 2 côtés : un dépôt Git
				- Les 2 dépôts peuvent communiquer grâce à des tokens (trigger/access tokens) et des appels API (webhooks)

---

### 🏛️ Côté établissement

```
				.
				├── css
				│  ├── _custom.scss
				│  └── _fonts.scss
				├── favicon.ico
				├── fonts
				│  └── Open Sans
				│      └── ...
				├── images
				│  └── ...
				├── locales
				│  └── custom.txt
				└── opengraph-image.jpg
				```

Note:
				- Dépôt Git autogéré avec les éléments personnalisables (images, couleurs, textes, polices)
				- *Push* déclenche automatiquement un *webhook* = requête `POST` sur la CI de déploiement côté infrastructure
				- *push event* = preprod / *tag push event* = prod

---

### ⚙️ Côté infra

![](images/ci.png)

Note:
				1. Analyse du *payload* du *webhook* : permet de connaitre le nom de l'établissement, le commiter et le type d'événement (*push* / *tag push*)
				2. Clonage du dépôt de l'établissement
				3. *Build* avec personnalisation et variables d'environnement
				4. Création automatique des buckets S3
				5. Synchronisation des fichiers statiques dans les buckets

---

### 🪣 Gestion des buckets S3

- Gestion des buckets avec `s3cmd`
				- Un *user* S3 (par env) pour les gouverner tous
				- Nom de bucket standardisé : `<etab>(-pprd)-etu-campulse-fr`
				- Stockage des clés S3 dans les secrets de GitLab

Note:
				- s3cmd : outil libre en ligne de commande pour gérer des données sur Amazon S3 et autres services compatibles.
				- Idéal pour les scripts de configuration avancée.

---

### 🪣 Configuration des buckets S3

- Mode *website* pour servir les fichiers statiques
				- ACLs configurés publiquement
				- *MIME types* définis explicitement

Note:
				- Mode website : permet de transformer un bucket en un hébergement statique. On peut y déposer des fichiers et S3 les servira comme un site web classique avec une URL publique, sans serveur web à configurer.
				- MIME types : identifiants qui indiquent au navigateur le type de contenu d’un fichier (par ex. text/html pour une page web ou image/png pour une image). Les déclarer permet au navigateur d’interpréter correctement chaque ressource, évitant ainsi les erreurs d’affichage, de téléchargement ou de sécurité.

---

```
				# Define FRONT_URL
				BASE_URL="https://${INSTITUTION}"
				SUFFIX="-pprd"
				if [ "$DEPLOY_ENV" == "prod" ]; then
					SUFFIX=""
				fi

FRONT_URL="${BASE_URL}${SUFFIX}.etu-campulse.fr"

# Define S3_BUCKET name
				S3_BUCKET=$(echo "${FRONT_URL##*://}" | tr '.' '-')
				```

Note:
				- Par précaution on remplace les points par des tirets. Les points peuvent casser le support du protocole HTTPS.

---

```
				# Configure S3 endpoint with s3cmd
				cat > ~/.s3cfg <<EOL
				[default]
				access_key = "$S3_ACCESSKEYID"
				secret_key = "$S3_SECRETACCESSKEY"
				host_base = "$HOST_BASE"
				host_bucket = %("$S3_BUCKET")s."$HOST_BASE"
				signature_v2 = False
				use_https = True
				EOL
				```

Note:
				- Configuration d'un endpoint pour s3cmd
				- Dans notre architecture : un fichier par environnement, pour accéder et manipuler l'ensemble des buckets

---

```
				# Create S3 bucket if it doesn't exist
				if s3cmd info s3://"$S3_BUCKET" 2>&1 | grep -q "NoSuchBucket"; then
					echo "❌ Bucket '$S3_BUCKET' does not exist"
					echo "🪣 Creating bucket '$S3_BUCKET'..."
					s3cmd mb s3://"$S3_BUCKET"
				fi
				```

Note:
				- Dans notre CI, on vérifie si le bucket existe
				- S'il n'existe pas, on le crée automatiquement

---

```
				# Sync files to S3 bucket
				s3cmd sync \
				--acl-public \ # Make files public
				--no-mime-magic \ # Disable automatic MIME type detection
				--guess-mime-type \ # Enable file extension MIME type detection
				source-repo/dist/ s3://"$S3_BUCKET"/

# Configure S3 bucket
				s3cmd ws-create s3://"$S3_BUCKET" \
				--ws-index=index.html --ws-error=index.html

# Deployment complete!
				```

Note:
				- s3cmd sync : synchronise le contenu d’un dossier local avec un bucket S3 (upload les fichiers manquants ou modifiés)
				- --acl-public : rend les fichiers copiés accessibles publiquement
				- --no-mime-magic : désactive l’utilisation de la lib python-magic pour détecter le type MIME (ça peut éviter des erreurs ou incohérences)
				- --guess-mime-type : force s3cmd à deviner le type MIME à partir de l’extension du fichier (par ex. .html → text/html)

---

### 🗺️ Exposition du front

- Infrastructure sur **Kubernetes**
				- **Istio** fait office de reverse proxy aux buckets S3
				- Routes *SPA* de Vue.js réécrites pour renvoyer vers `/`

Note:
				- Istio : outil pour gérer les microservices dans un cluster Kubernetes
				- Ici utilisé comme reverse proxy (serveur "passe-plats" qui fait passer les demandes des utilisateurs vers un autre serveur)
				- Pas d'exposition directe des buckets
				- Flexibilité dans la configuration qui s'adapte à chaque instance

---

<pre><code data-line-numbers="2-3|16-20|21-27|37-41" class="language-yaml">
				apiVersion: networking.istio.io/v1
				kind: VirtualService
				metadata:
				  name: {{ include "campulse.fullname" . }}-front
				  labels:
					{{- include "campulse.labels" . | nindent 4 }}
				  annotations:
					link.argocd.argoproj.io/frontend: 'https://{{ .Values.frontBaseURL }}'
				spec:
				  hosts:
				  - {{ .Values.frontBaseURL }}
				  gateways:
				  - istio-gateway/wildcard-pprd-etu-campulse-fr-gateway
				  http:
				  - match:
					- port: 80
					redirect:
					  scheme: https
					  port: 443
				  - match:
					- uri:
						prefix: /assets
					- uri:
						exact: /favicon.ico
					- uri:
						regex: '.*\.(css|gif|ico|jpg|js|png|swf|txt|svg|woff|ttf|eot|woff2)$'
					route:
					- destination:
						host: {{ .Values.bucketURL }}
						port:
						  number: 443
					headers:
					  request:
						set:
						  host: {{ .Values.bucketURL }}
				  - match:
					- uri:
						regex: "/(.*)"
					rewrite:
					  uri: /
					headers:
					  request:
						set:
						  host: {{ .Values.bucketURL }}
					route:
					- destination:
						host: {{ .Values.bucketURL }}
						port:
						  number: 443
				</code></pre>

Note:
				- Fichier de configuration Istio, ressource VirtualService qui sert à gérer et contrôler le routage du trafic (reverse proxy)
				- Redirige automatiquement tout le trafic HTTP (port 80) vers HTTPS (port 443) pour sécuriser les connexions
				- Toutes les requêtes visant des ressources statiques telles que les images, polices, ou fichiers CSS/JS restent accessibles directement depuis leur emplacement d’origine
				- Toute requête est réécrite vers /, ce qui est typiquement utilisé pour les applications monopage (SPA), cela permet, par exemple, qu’une requête vers /dashboard ou /profile renvoie le fichier index.html (et donc l’application front-end), qui gérera ensuite le routage côté client.

---

### 💡 Avantages de cette solution

- **Scalabilité** : 2 buckets par établissement, facilement déployables
				- **Sécurité** : pas de clé SSH dans la CI, accès S3 uniquement
				- **Simplicité** : console S3 facile à utiliser pour gérer l'ensemble des buckets à partir de 2 endpoints
				- **Pertinence** : fichiers statiques, non sensibles

---

### 🧪 Conclusion

- Hébergement **statique, sécurisé, multi-locataire**
				- Parfaitement adapté aux contextes institutionnels
				- Allie **automatisation**, **personnalisation** et **robustesse**
				- Compatible avec des pipelines DevOps modernes

Note:
				- Fonctionne aussi avec des VM dans le cas d'une archi en transition

---

### 🙏 Merci !

Merci d’avoir suivi la présentation, vos questions et retours sont les bienvenus.

Contact : pgilg@unistra.fr