Barème du module

Étape 1 : 4 points Étape 2 : 6 points Étape 3 : 7 points Étape 4 : 3 points

Pour chaque étape :

• OK : les consignes sont respectées, la totalité des points est accordée ;
• POK : les consignes sont partiellement respectées, la moitié de points est accordée ;
• NOK : les consignes sont insuffisamment respectées, aucun point accordé.

Étape 1 : identification des dépendances

Comment les identifier

Les dépendances se manifestent de plusieurs façon. Il y a :

• les dépendances internes, celles qui sont écrites dans votre package.json, Cargo.toml, composer.json, etc.
• les dépendances externes, les paquets/programmes/bibliothèques installés sur l’hôte/la machine/l’ordinateur
  • comme l’exécutable node et sa version, la bibliothèque bcrypt et sa version (c’est un exemple, vous ne devriez pas vous servir de bcrypt)
• les dépendances de service : les API, bases de données et autres services que votre service doit pouvoir joindre à l’exécution
  • ça implique la connaissance d’une version, d’une adresse et d’un secret ;

Parmi les dépendances internes, certaines ne sont utiles qu’au développement ou à la construction : typiquement :

• les bundlers à la vite etwebback ;
• les linters et formateurs à la eslint, prietter ;
• les compilateurs à la tsc.

Ces dépendances sont distinguées des autres pour :

• accélérer les déploiements (et donc faire des économies de temps et d’ARGENT) ;
• peser moins lourd en déploiement (et donc faire des économies d’ARGENT).

Consignes

Dans les dépôts de votre backend et de votre frontend:

1. assurez-vous que vos dépendances internes sont bien distinguées entre nécessaires au développement et nécessaires en toutes circonstances y compris en production.

Dans le dépôt de déploiement, dans un README.md, pour le frontend et le backend :

1. Listez les dépendances externes et leurs versions.
2. Listez les dépendances de services :
   • les URL que vous prévoyez si c’est un service que vous allez déployer (une BDD), ou les URL existants si c’est un service accessible publiquement ;
   • quelles variables d’environnement ou clés de configuration faut-il définir du côté de vos livrables pour qu’ils connaissent URL et secrets.

Étape 2 : écriture scripts/configurations

Les dépendances maintenant identifiées : on sait ce que l’on doit déployer sur nos serveurs, ou pour enrôler de nouveaux développeurs.

Un outil très utile pour préparer un déploiement c’est Docker avec des images de base comme :

• node pour compiler votre FE et BE et faire tourner votre BE (voir votre frontend s’il inclus du SSR) ;
• postgres, mariadb pour votre BDD ;
• caddy, ngnix comme proxy inverse et serveur du FE pré-compilé.

Construction vs. exécution

En général dans un Dockerfile on défini deux images. Dans la première on installe tout ce dont on a besoin pour construire le livrable. Dans la seconde seulement ce qui est nécessaire pour l’exécuter, et on y copie le livrable construit dans la première.

Exemple de Dockefile à deux stages pour du typescript, généré par Copilot, que vous pouvez adapter à vos besoin (en fonction du port que vous utilisez, de votre dossier destination pour le code transpilé, de votre gestionnaire de projet et des variables d’environnement dont vous pouvez avoir besoin) :

Creating a two-stage Dockerfile for a TypeScript project can help you optimize the build process by separating the build environment from the runtime environment. Here’s an example of how you can set this up:

# Stage 1: Build
FROM node:16 AS builder

# Set the working directory
WORKDIR /app

# Copy package.json and package-lock.json
COPY package*.json ./

# Install dependencies
RUN npm install

# Copy the rest of the application code
COPY . .

# Compile TypeScript to JavaScript
RUN npm run build

# Stage 2: Production
FROM node:16-alpine

# Set the working directory
WORKDIR /app

# Copy only the necessary files from the build stage
COPY --from=builder /app/package*.json ./
COPY --from=builder /app/dist ./dist

# Install only production dependencies
RUN npm install --only=production

# Expose the application port
EXPOSE 3000

# Command to run the application
CMD ["node", "dist/index.js"]

Explanation:

1. Stage 1: Build

   • Uses the node:16 image as the base.
   • Sets the working directory to /app.
   • Copies package.json and package-lock.json to the container and installs dependencies.
   • Copies the rest of the application code and compiles TypeScript to JavaScript.

2. Stage 2: Production

   • Uses a smaller node:16-alpine image to keep the final image size small.
   • Sets the working directory to /app.
   • Copies only the necessary files (package.json, package-lock.json, and the compiled dist folder) from the build stage.
   • Installs only production dependencies.
   • Exposes port 3000 and sets the command to run the application.

This setup ensures that your final Docker image is as small as possible and contains only the necessary files to run your application. If you have any questions or need further assistance, feel free to ask!

ref: typescript two stages dockerfile | dans Microsoft 365 Copilot

Consignes

1. Écrivez les Dockerfile pour le FE et le BE dans leur dépôts respectifs.
2. Écrivez un docker-compose.yml dans le dépôt de déploiement, il doit
   • décrire comment déployer votre FE et BE
   • décrire le déploiement d’un proxy inverse (vous avez le droit de faire de votre FE le proxy inverse, en utilisant caddy pour servir le front et rediriger les requêtes sur /api vers le BE par exemple)
3. Écrivez la configuration pour un environnement d’intégration continue (exemple : GitHub Actions, CircleCI) qui vérifie la construction de votre FE et de votre BE.

Étape 3 : préparation machine et déploiement

1. installez Linux sur un serveur
2. configurez le SSH sans mot de passe pour chaque membre du groupe sur votre serveur
3. créez une clé SSH de déploiement par dépôt et enregistrez-la dans la configuration de ces dépôts (sur la forge, sur github, etc.)
4. configurez le par-feu de la machine, de sorte à ne permettre les connexions entrantes que sur les ports 80 (si vous n’avez pas d’IP publique), 443 (si vous avez une IP publique) et 22.
5. installez Docker et Docker Compose
6. clonez FE, BE et dépôt de déploiement
7. lancez votre stack avec docker compose up -d, le FE doit être accessible sur le port 80 si vous n’avez pas d’IP publique ou sur le port 443 en HTTPS si vous avec une IP publique, le BE doit être accessible via /api sur le même port.

Étape 4 : déploiement continu

1. à travers un hook, ou une tâche automatique, faites déployer automatiquement au serveur les nouvelles version de votre FE ou BE.