Configuration
Pour garantir une certaine facilité de navigation dans les fichiers de notre GitHub, nous avons créé une structure de dossiers assez intuitive. En effet, dans notre répository, on peut trouver un dossier pour chaque service. Cela rend la navigation plus simple quand on cherche un certain fichier de configuration, il suffit alors d'aller dans le dossier concernant le service du fichier recherché et dans la plupart des cas, il est trouvé très rapidement.
Cependant, pour certains services (les plus imposants généralement), nous avons dû ajouter des sous-dossiers pour faciliter la recherche des fichiers. Prenons pour exemple le dossier SERVICE INTERNE. Ce service contient énormément de sous-services comme du partage de fichiers, de la résolution de nom, un SOA et une DB. Si nous avions mis tous les fichiers de ces sous-services dans un seul et même dossier se serait la pagaille. C'est pour cela que nous avons créé des sous-dossiers dans le cas des plus gros services comme le service interne.
Dernièrement, cette organisation permet aussi de faciliter la localisation des Dockerfile. En effet, ceux-ci sont stockés à la racine du dossier concernant leur service.
Lors de la configuration des services, on essaye de respecter des conventions quand on crée ou édite des fichiers:
- Commenter les fichiers de configuration pour augmenter leurs compréhension.
- Donner des noms logiques et compréhensifs aux fichiers (quand il n'y a pas de nomenclature pour ces derniers => noms des fichiers de zones DNS ou sites web).
- Aérer et bien indenter le code.
Explication + schéma de toutes les étapes depuis l'édition d'un fichier de configuration en local jusqu'au déploiement dans un container sur un VPS.
Lors de la configuration d'un service, beaucoup d'étapes sont à prendre en compte. Voici comment nous passons d'un fichier de configuration à un service déployé sur le VPS:
Différentes étapes:
-
Modification ou création d'un fichier de configuration pour n'importe quel service. Le membre du groupe sauvegarde juste son travail dans le dossier correspondant au service.
-
Création de l'image sur base du Dockerfile. Le membre du groupe crée l'image grace à la commande
docker buildà partir dur Dockerfile. Si il a créé un nouveau fichier il faut qu'il ajoute des directives dans le Dockerfile pour que la nouvelle image créée utilise son nouveau fichier de configuration. -
Conteneurisation de l'image créée grâce à la commande
docker runou via l'interface graphique de Docker Desktop. Après avoir créé le conteneur on peut tester si la configuration fonctionne correctement. Si c'est le cas, on peut passer à l'étape suivante sinon on peut revenir au point 1 et recommencer. -
Mise en ligne de l'image sur DockerHub avec la commande
docker push. Une fois l'image mise en ligne, elle est accessible partout sur internet. -
On télécharge l'image, précédemment pushée, depuis DockerHub.
-
Finallement, on peut éxecuter l'image dans un conteneur avec la même commande qu'au point 3:
docker run.
Nous utilisons donc les Dockerfiles pour faciliter la configuration des services grâce à l'automatisation de la création des images. Cela permet de repartir d'une image "saine" assez simplement.
Voici pour chaque service, le niveau d'avancement:
- Analyse: Terminée ✔️
- Configuration: Terminée ✔️
- Documentation: Terminée ✔️
- Sécurisation: En cours Problème avec le DNSSec ❌
- Analyse: Terminée ✔️
- Configuration: PAS PRISE EN COMPTE
- Documentation: Terminée ✔️
- Sécurisation: En cours ❌
❌ SERVICE PAS PRIS EN COMPTE ❌
- Analyse: PAS PRISE EN COMPTE
- Configuration: En cours Finalisation avec l'installation des postes clients ❌
- Documentation: En cours ❌
- Sécurisation: PAS PRISE EN COMPTE
- Analyse: ✔️
- Configuration: En cours ❌
- Documentation: PAS PRISE EN COMPTE
- Sécurisation: Pas encore commencée ❌
- Analyse: ✔️
- Configuration: En cours ❌
- Documentation: En cours ❌
- Sécurisation: En cours ❌