TP_Docker/TP3/exo2-dockerfile/QUESTIONS.md

# Réponses aux questions sur Docker - TP3

## 1. Pourquoi choisir un OS minimal ? Quels sont les avantages ?

J'ai choisi Alpine Linux comme base de mon image Docker car c'est un OS ultra léger qui présente plein d'avantages pour les conteneurs.

D'abord, la taille fait une énorme différence ! Une image Alpine fait environ 5-8 Mo alors qu'une image Ubuntu standard peut facilement atteindre 300 Mo. Pendant les TPs, j'ai remarqué que mes builds avec Alpine prenaient beaucoup moins de temps, et c'était vraiment pratique quand je devais faire plusieurs essais pour corriger des erreurs.

L'aspect sécurité est aussi super important. Avec moins de composants installés, il y a moins de risques de vulnérabilités. On nous a expliqué en cours que chaque package supplémentaire augmente potentiellement la surface d'attaque. C'est logique : moins de code = moins de bugs possibles = moins de failles de sécurité.

Les performances sont bien meilleures aussi. J'ai testé les deux approches et les conteneurs basés sur Alpine démarrent presque instantanément et utilisent moins de RAM. Sur mon vieux PC, ça fait une grande différence, surtout quand je lance plusieurs conteneurs en même temps pour les TPs.

Et puis, quand on travaille en équipe ou qu'on déploie sur différents environnements, le fait de pouvoir transférer rapidement les images est un gros plus. Avec des images légères, le push/pull vers Docker Hub prend quelques secondes au lieu de plusieurs minutes.

## 2. Quel est l'intérêt d'utiliser des variables d'environnement ?

Avant ce TP, je ne comprenais pas vraiment l'intérêt des variables d'environnement, mais maintenant je trouve ça super pratique !

Le principal avantage que j'ai découvert, c'est la flexibilité. Dans mon Dockerfile, j'ai défini SCHOOL="IUT" et LEVEL="1.8", mais j'aurais pu facilement les changer au lancement avec un simple `-e SCHOOL=AUTRE_ECOLE`. Ça évite d'avoir à recréer complètement l'image pour chaque petite modification de configuration.

C'est aussi beaucoup plus propre de séparer le code de la configuration. Le prof nous a expliqué que c'est un principe des "12-factor apps" qu'on utilise dans le développement moderne. Dans un vrai projet, au lieu de coder en dur les URLs ou les identifiants de base de données, on utiliserait des variables d'environnement.

J'ai trouvé ça particulièrement utile pendant les tests. Je pouvais lancer le même conteneur avec différentes configurations juste en changeant les variables. Par exemple, pour tester avec différents niveaux d'accès ou différentes configurations de serveur.

Un autre point important qu'on a abordé en cours, c'est la sécurité. Si j'avais besoin de stocker un mot de passe ou une clé API, je ne voudrais surtout pas les mettre directement dans mon Dockerfile (qui pourrait être partagé sur GitHub). Avec les variables d'environnement, on peut les injecter au moment du déploiement.

## 3. À quoi sert le healthcheck dans un contexte de production ?

Le healthcheck a été une découverte pour moi pendant ce TP. Dans notre code, j'ai configuré un healthcheck qui vérifie toutes les minutes si le serveur web répond correctement.

J'ai compris que dans le monde réel, ce n'est pas parce qu'un conteneur tourne que l'application fonctionne correctement. Par exemple, Apache pourrait être démarré mais bloqué ou incapable de traiter des requêtes. Le healthcheck permet de détecter ces situations avant que les utilisateurs ne rencontrent des problèmes.

Ce qui m'a impressionné, c'est l'intégration avec les outils d'orchestration. Notre prof nous a expliqué que dans un environnement Kubernetes, les conteneurs qui échouent à leur healthcheck peuvent être automatiquement redémarrés ou remplacés. C'est comme avoir un administrateur système qui surveille constamment l'application, mais de façon automatisée !

Dans notre TP, j'ai utilisé wget pour vérifier que le serveur répond, mais j'imagine qu'en entreprise, on pourrait faire des tests plus sophistiqués comme vérifier que la connexion à la base de données fonctionne ou que certaines fonctionnalités clés sont disponibles.

J'ai aussi appris que les healthchecks jouent un rôle important pendant les déploiements. Par exemple, lors d'une mise à jour, le nouveau conteneur ne recevra du trafic que lorsque son healthcheck sera positif, ce qui évite d'envoyer des utilisateurs vers une application qui n'est pas encore prête.

## 4. Comment pourriez-vous optimiser davantage cette image ?

Après avoir terminé le TP, j'ai réfléchi à plusieurs façons d'améliorer mon image Docker :

Une technique que j'aimerais essayer est le build multi-étapes. D'après ce que j'ai compris, ça permet d'utiliser un premier conteneur pour les opérations de build (comme la compilation ou la préparation des fichiers), puis de copier uniquement les résultats dans l'image finale. Ça permettrait d'avoir une image de production encore plus légère.

J'ai aussi remarqué que j'utilisais "httpd:alpine3.21" sans vraiment réfléchir. Il serait plus professionnel de choisir précisément la version dont j'ai besoin en fonction des fonctionnalités et des correctifs de sécurité disponibles. Le prof nous a expliqué que c'est important pour la reproductibilité des builds.

Mon Dockerfile contient plusieurs commandes RUN séparées. Je pourrais les combiner pour réduire le nombre de couches et optimiser la taille. Par exemple, toutes les opérations d'installation et de configuration pourraient être dans une seule instruction RUN.

J'ai appris pendant le cours qu'il n'est pas recommandé de faire tourner les applications en tant que root dans les conteneurs. Je pourrais donc ajouter des directives USER pour exécuter Apache avec un utilisateur sans privilèges. Ça limiterait les dégâts en cas de faille de sécurité.

Enfin, même si Apache est très répandu, j'ai découvert que Nginx pourrait être une alternative plus légère pour servir des fichiers statiques. Ça pourrait être intéressant d'essayer de refaire le même exercice avec Nginx pour comparer les performances et la taille des images.