stiti/TP_Docker
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Ajouts

Browse Source
This commit is contained in:
stiti
2025-04-08 17:14:02 +02:00
parent a0e2bb3ee0
commit f05c9725a7
6 changed files with 460 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

65
TP3/exo2-dockerfile/COMMANDS.md Normal file
View File

@@ -0,0 +1,65 @@
# Commandes Docker pour l'exercice 2
## Construction de l'image
```bash
docker build -t apache-static:1.8 .
```
## Lancement d'un conteneur
```bash
docker run -d -p 8080:80 --name apache-static-container apache-static:1.8
# 98f3ffa33561f25e0320a4eeac67e83fe5629e8caf4883f7a35c83b9295e4a5a
```
## Vérification du site web
```bash
curl http://localhost:8080
```
Résultat :
```html
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<title>Stage - Compte à rebours</title>
<style>
body {...
```
## Vérification des variables d'environnement
```bash
docker exec apache-static-container env | grep SCHOOL
docker exec apache-static-container env | grep LEVEL
```
Résultat :
```bash
SCHOOL=IUT
LEVEL=1
```
## Vérification du healthcheck
```bash
docker inspect --format='{{json .State.Health}}' apache-static-container
```
Résultat :
```json
{"Status":"healthy","FailingStreak":0,"Log":[{"Start":"2025-04-08T16:15:36.513084342+02:00","End":"2025-04-08T16:15:36.577562059+02:00","ExitCode":0,"Output":"Connecting to localhost ([::1]:80)\nremote file exists\n"}]}
```
## Publication sur Docker Hub
```bash
# Connexion à Docker Hub
docker login
# Tag de l'image
docker tag apache-static:1.8 username/apache-static:1.8
# Push vers Docker Hub
docker push moncef45/apache-static:1.8
# mon username = moncef45
```
Lien Docker Hub: https://hub.docker.com/u/moncef45

33
TP3/exo2-dockerfile/Dockerfile Normal file
View File

@@ -0,0 +1,33 @@
# Utilisation d'Alpine Linux comme base légère
FROM httpd:alpine3.21
# Définition des labels
LABEL MAINTAINER="moncef" \
VERSION="1.8" \
TP="3"
# Configuration des variables d'environnement
ENV SCHOOL="IUT" \
LEVEL="1.8"
# Exposition du port 80
EXPOSE 80
# Clonage du dépôt Git (temporairement)
RUN apk add --no-cache git && \
git clone https://github.com/MaximePIERRONT/beforeStage.git /tmp/repo && \
cp /tmp/repo/static-site.html /usr/local/apache2/htdocs/index.html && \
# Personnalisation du fichier HTML
sed -i 's/NOM PRENOM/moncef/g' /usr/local/apache2/htdocs/index.html && \
# Nettoyage
rm -rf /tmp/repo && \
apk del git
# Configuration du healthcheck
HEALTHCHECK --interval=1m --timeout=1s \
CMD wget --no-verbose --tries=1 --spider http://localhost/ || exit 1
# Commande de démarrage d'Apache
# Note: Cette commande est déjà définie dans l'image de base et n'est pas nécessaire,
# mais je la laisse pour la clarté
CMD ["httpd-foreground"]

51
TP3/exo2-dockerfile/QUESTIONS.md Normal file
View File

@@ -0,0 +1,51 @@
# 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.