Aller au contenu principal

Autres technologiques

attention

Cette section a été générée avec l'aide de l'IA afin de vous aider et de personnaliser le guide en fonction de vos projets. Elle n'a pas été testée et sert de point de départ. Il est possible que des ajustements soient nécessaires selon la structure de votre application.

Vous pouvez d'ailleurs utiliser l'IA pour vous aider à débugger et configurer votre Dockerfile et docker-compose.yml.

Le guide principal est basé sur un projet ASP.NET MVC et/ou API et/ou Blazor. Si vous utilisez des frameworks différents, les sections Installation de Docker, AWS, Variables d'environnement, DNS et SSL restent identiques. Seuls le Dockerfile, le docker-compose.yml et le Caddyfile changent.

Voici deux pistes d'ajustement pour des projets Vue + API .NET ou Nuxt.

Vue.js + API .NET

Cette architecture utilise deux services: un frontend Vue.js servi comme fichiers statiques et une API .NET.

Dockerfile pour le frontend Vue.js

MonProjet.Vue/Dockerfile
# Build des assets
FROM node:22-alpine AS build
WORKDIR /src
COPY MonProjet.Vue/package*.json ./
RUN npm ci
COPY MonProjet.Vue/ ./
RUN npm run build

# Servir les fichiers statiques avec Caddy
FROM caddy:alpine AS final
COPY --from=build /src/dist /srv
info

Ici, on utilise directement une image Caddy pour servir les fichiers statiques du frontend. Pas besoin d'un serveur Node.js en production pour une application Vue — ce sont de simples fichiers HTML/JS/CSS.

attention

Adaptez MonProjet.Vue/ au nom de votre dossier de projet Vue.js et vérifiez que le dossier de sortie est bien dist (c'est le défaut de Vite).

Dockerfile pour l'API .NET

Le Dockerfile de l'API est le même que dans le guide principal. Référez-vous à la section Créer un Dockerfile.

docker-compose.yml

docker-compose.yml
services:
postgres:
image: postgres:17-alpine
container_name: monprojet_postgres
environment:
- POSTGRES_DB=${POSTGRES_DB}
- POSTGRES_USER=${POSTGRES_USER}
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
volumes:
- pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB"]
interval: 5s
timeout: 5s
retries: 5
restart: unless-stopped

api:
build:
context: .
dockerfile: MonProjet.Api/Dockerfile
container_name: monprojet_api
environment:
- ASPNETCORE_HTTP_PORTS=8080
- ConnectionStrings__AppDatabaseConnection=${APP_DATABASE_CONNECTION}
expose:
- "8080"
depends_on:
postgres:
condition: service_healthy
restart: unless-stopped

client:
build:
context: .
dockerfile: MonProjet.Vue/Dockerfile
container_name: monprojet_client
expose:
- "80"
depends_on:
- api
restart: unless-stopped

caddy:
image: caddy:alpine
container_name: monprojet_caddy
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy_data:/data
- caddy_config:/config
depends_on:
- client
- api
restart: unless-stopped

volumes:
pgdata:
caddy_data:
caddy_config:
info

Le service client utilise l'image Caddy intégrée dans son Dockerfile pour servir les fichiers statiques. Le service caddy à la racine agit comme reverse proxy pour router les requêtes vers le bon service.

Caddyfile

:80 {
handle /api/* {
reverse_proxy api:8080
}

handle {
reverse_proxy client:80
}
}
  • Les requêtes commençant par /api/ sont envoyées à l'API .NET
  • Toutes les autres requêtes sont envoyées au frontend Vue.js
attention

Adaptez le préfixe /api/ selon la configuration de vos routes API. En production, remplacez :80 par votre nom de domaine pour activer le HTTPS automatique (voir SSL).


Nuxt

Nuxt utilise le moteur Nitro qui fournit un serveur intégré capable de gérer le rendu côté serveur (SSR) et les routes API. Pas besoin d'un serveur .NET séparé.

L'exemple ci-dessous utilise Prisma comme ORM et MariaDB comme base de données.

Dockerfile pour Nuxt

Dockerfile
# Build
FROM node:22-alpine AS build
WORKDIR /src
COPY package*.json ./
COPY prisma ./prisma/
RUN npm ci
COPY . .
RUN npm run build

# Production
FROM node:22-alpine AS final
WORKDIR /app
COPY --from=build /src/.output .output
EXPOSE 3000
CMD ["node", ".output/server/index.mjs"]
info
  • Le dossier prisma/ est copié avant npm ci afin que le script postinstall (prisma generate) puisse trouver le schéma Prisma.
  • Contrairement à Vue.js, Nuxt a besoin d'un serveur Node.js en production pour le rendu côté serveur (SSR). C'est pourquoi l'image finale utilise node:22-alpine et non une image Caddy.

docker-compose.yml

docker-compose.yml
services:
mariadb:
image: mariadb:11
container_name: monprojet_mariadb
environment:
- MARIADB_DATABASE=${MARIADB_DATABASE}
- MARIADB_USER=${MARIADB_USER}
- MARIADB_PASSWORD=${MARIADB_PASSWORD}
- MARIADB_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD}
volumes:
- dbdata:/var/lib/mysql
healthcheck:
test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
interval: 5s
timeout: 5s
retries: 5
restart: unless-stopped

client:
build:
context: .
dockerfile: Dockerfile
container_name: monprojet_client
environment:
- DATABASE_URL=${DATABASE_URL}
expose:
- "3000"
depends_on:
mariadb:
condition: service_healthy
restart: unless-stopped

caddy:
image: caddy:alpine
container_name: monprojet_caddy
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy_data:/data
- caddy_config:/config
depends_on:
- client
restart: unless-stopped

volumes:
dbdata:
caddy_data:
caddy_config:

Caddyfile

:80 {
reverse_proxy client:3000
}

En production, remplacez :80 par votre nom de domaine pour activer le HTTPS automatique (voir SSL).

Fichier .env

.env
MARIADB_DATABASE=monprojet_db
MARIADB_USER=monprojet_user
MARIADB_PASSWORD=motdepasse
MARIADB_ROOT_PASSWORD=motdepasse_root
DATABASE_URL="mysql://monprojet_user:motdepasse@mariadb:3306/monprojet_db"
attention
  • mariadb dans l'URL réfère au nom du service dans docker-compose.yml, pas à localhost.
  • Prisma utilise le protocole mysql:// pour se connecter à MariaDB.
  • N'oubliez pas de créer un fichier .env avec des mots de passe forts sur le serveur également (voir Variables d'environnement).