Préparer le repository

Créer uniquement la structure nécessaire au projet.

Dans ce chapitre : 4 étapes et 13 preuves de validation.

Étape 19 — Entrer dans le repository

Objectif. Toutes les prochaines commandes partiront du même dossier.

État du projet avant cette étape. Docker fonctionne dans la VM. Il faut maintenant travailler dans le dépôt Git rendu à 42.

Comprendre le changement

La racine du repository est le dossier qui contiendra Makefile et srcs. pwd permet de savoir où l’on est ; ls montre ce qui se trouve ici.

Faire une seule chose

Clone ou ouvre ton repository dans la VM, entre dedans avec cd, puis vérifie le chemin avant de créer quoi que ce soit.

À EXÉCUTER DANSDans la VM · à la racine du repository

pwd
ls -la

Ce que fait chaque partie

pwd affiche le dossier courant.
ls -la affiche aussi les fichiers cachés, dont .git si le dépôt est initialisé.

Résultat attendu

pwd se termine par le nom de ton repository et ls montre .git.

Si cela échoue

Si .git n’apparaît pas, tu n’es peut-être pas dans le dépôt cloné.

Prouver que c’est correct

Preuves de validation 0 / 3

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

pwd affiche le chemin du repository dans la VM.ls -la montre le dossier .git.Tu sais revenir ici avec cd.

Question de soutenance — Qu’est-ce qui ne doit jamais être dans Git ?

La VM, les containers, les volumes, les données et les vrais credentials.

Étape 20 — Créer les fichiers obligatoires de la racine

Objectif. La racine contiendra les quatre documents que 42 attend.

État du projet avant cette étape. Le repository est vide ou presque.

Comprendre le changement

Makefile lancera le projet. README.md présentera le projet. USER_DOC.md expliquera l’usage. DEV_DOC.md expliquera l’installation et la maintenance.

Faire une seule chose

Crée seulement les fichiers vides maintenant. Leur contenu sera écrit quand le projet fonctionnera, afin de documenter des commandes déjà testées.

Fichiers ou emplacements concernés

Makefile
README.md
USER_DOC.md
DEV_DOC.md

À EXÉCUTER DANS🖥️ Dans la VM · 📁 racine du repository

touch Makefile README.md USER_DOC.md DEV_DOC.md

Ce que fait chaque partie

touch : crée chaque fichier s’il n’existe pas, sans écraser son contenu s’il existe.

Résultat attendu

ls montre les quatre fichiers à la racine.

Si cela échoue

Vérifiez pwd : vous devez être à la racine du dépôt et avoir les droits d’écriture.

Prouver que c’est correct

Preuves de validation 0 / 3

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

ls montre les quatre fichiers à la racine.Aucun de ces fichiers n’est sous srcs.Tu peux expliquer en une phrase le rôle de chacun.

Question de soutenance — Qu’est-ce qui ne doit jamais être dans Git ?

La VM, les containers, les volumes, les données et les vrais credentials.

Étape 21 — Créer les dossiers des trois services

Objectif. Chaque futur service aura un endroit clair pour son image et sa configuration.

État du projet avant cette étape. La racine existe, mais aucun dossier Docker n’est encore créé.

Comprendre le changement

requirements contiendra un dossier mariadb, wordpress et nginx. Dans chaque dossier : Dockerfile décrit l’image, conf contient la configuration, tools contient le script de démarrage.

Faire une seule chose

Lance la commande depuis la racine. Ensuite, parcours l’arborescence avec find et retrouve les trois dossiers à l’écran.

Fichiers ou emplacements concernés

srcs/requirements/

À EXÉCUTER DANS🖥️ Dans la VM · 📁 racine du repository

mkdir -p srcs/requirements/{mariadb,wordpress,nginx}/{conf,tools}
touch srcs/docker-compose.yml srcs/.env
touch srcs/requirements/{mariadb,wordpress,nginx}/{Dockerfile,.dockerignore}

Ce que fait chaque partie

mkdir -p : crée toute la hiérarchie ; -p accepte les dossiers déjà présents.
{...} : expansion du shell qui évite de répéter les trois services.
touch : crée Compose, .env, les Dockerfiles et .dockerignore.

Résultat attendu

find srcs -maxdepth 4 -print montre la structure attendue.

Si cela échoue

Si votre shell ne développe pas les accolades, créez les dossiers séparément. Ne lancez pas la commande depuis srcs, sinon vous obtiendrez srcs/srcs.

Prouver que c’est correct

Preuves de validation 0 / 3

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

find srcs montre mariadb, wordpress et nginx.Chaque service possède conf, tools, Dockerfile et .dockerignore.Tu sais dans quel dossier ira la configuration de MariaDB.

Question de soutenance — Qu’est-ce qui ne doit jamais être dans Git ?

La VM, les containers, les volumes, les données et les vrais credentials.

Étape 22 — Préparer les secrets et les données locales

Objectif. Les mots de passe et les futures données auront un emplacement hors de Git.

État du projet avant cette étape. Les dossiers de configuration existent. Il manque encore les valeurs locales qui ne doivent jamais être rendues.

Comprendre le changement

secrets contient les vrais mots de passe utilisés sur ta VM. /home/<login>/data contiendra la base et les fichiers persistants. .gitignore empêche Git de proposer les secrets.

Faire une seule chose

Crée les quatre fichiers secrets vides, ajoute secrets/ à .gitignore, puis crée les deux dossiers de données avec ton vrai login. Ne saisis encore aucun mot de passe dans une commande.

Fichiers ou emplacements concernés

secrets/
.gitignore
/home/<login>/data/

À EXÉCUTER DANS🖥️ Dans la VM · 📁 racine du repository

mkdir -p secrets secrets.example
touch secrets/db_password.txt secrets/db_root_password.txt secrets/wp_admin_password.txt secrets/wp_user_password.txt

Ce que fait chaque partie

mkdir -p : crée les répertoires local et d’exemple.
touch : crée les fichiers que Docker secrets lira plus tard.

Résultat attendu

Les quatre fichiers utilisés par Compose existent localement sous secrets/.

Si cela échoue

Ne saisissez aucune valeur dans une commande susceptible d’être conservée dans l’historique du shell.

À ÉCRIRE DANS📄 .gitignore · contenu minimal à adapter

secrets/
/home/
*.pem
*.key
.DS_Store

Ce que fait chaque partie

secrets/ : exclut toutes les valeurs confidentielles locales.
*.pem et *.key : évitent de publier accidentellement certificats ou clés privées.
/home/ : protège d’un éventuel dossier de données créé au mauvais endroit dans le dépôt.

Résultat attendu

git status ne propose aucun fichier sous secrets/.

Si cela échoue

Si un secret a déjà été commité, .gitignore ne suffit pas : révoquez-le et retirez-le de l’historique.

À EXÉCUTER DANS🖥️ Dans la VM · depuis n’importe quel dossier · remplacez <login>

Avant de copier : remplacez <login> par vos valeurs.

sudo mkdir -p /home/<login>/data/{mariadb,wordpress}
sudo chown -R <login>:<login> /home/<login>/data

Ce que fait chaque partie

sudo mkdir -p : crée les deux chemins de données hôte.
chown -R : donne à votre utilisateur la propriété initiale ; les services pourront ensuite ajuster leurs sous-dossiers si nécessaire.

Résultat attendu

ls -ld /home/<login>/data/* montre deux dossiers.

Si cela échoue

Un chemin littéral contenant <login> est une erreur : remplacez-le. En cas de permission denied, vérifiez sudo et les propriétaires.

Prouver que c’est correct

Preuves de validation 0 / 4

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

git status ne liste aucun fichier sous secrets.Les quatre fichiers secrets existent localement./home/<login>/data contient mariadb et wordpress.Le texte <login> a été remplacé par ton vrai login.

Question de soutenance — Qu’est-ce qui ne doit jamais être dans Git ?

La VM, les containers, les volumes, les données et les vrais credentials.