Archive T206 ‐ AdminII Exercice - dudleydehenau/Ephec GitHub Wiki

AdminII

Labo 1 semaine 05-02-24

Exercice 1.

Suite à l'exécution de la commande docker run hello-world, la machine a recherché si une image était déjà disponible sur la machine portant le nom de hello-world. Vu que non, elle a recherché sur le repository public et l'a téléchargée depuis le repo.
Suite à l'exécution de docker container ls -a, j'ai reçu des informations sur :
- Son identifiant : "0fdb572d187f"
- Son nom : "exciting_agnesi"
- Son état/status : "Excited" (effectivement, je l'ai stoppé)
- Le nom de l'image : "hello-world"
- La commande exécutée : "/hello" Ces informations sont retrouvables dans Docker Desktop.
Suite à la commande docker image ls, je reçois les informations suivantes :
- Repository : le nom de l'image
- TAG : info de la version
- Image ID : un ID unique par image
- Created : date de création de l'image (création au niveau repo, pas de l'image)
- Size : la taille de l'image. Sur Docker, il affiche une information supplémentaire : si celle-ci est utilisée. Afin de ne pas user d'espace disque pour rien, on peut supprimer les images en exécutant la commande docker image rm "id image" -f -f car il faut souvent forcer la manœuvre.

Exercice 2.

Suite à l'exécution de la commande docker run -it ubuntu bash plusieurs questions se posent :
- L'utilisation de "-it" : "-i" permet d'interagir directement dans la machine en y entrant les commandes de manière interactive. "-t" Alloue un terminal pour le container. Pratique avec la commande "-i"
- Dans ce cas-ci, ce sont les commandes bash.
- Dans le container, seule la commande ps tourne. Son PID est 9.
- Je suis logué avec l'utilisateur root.
- Oui, mon container a accès à internet et son résolveur est 192.168.65.7
Suite à la commande suivante docker inspect "id container", j'ai pu récupérer quelques infos comme :
- Mon adresse IP : 172.17.0.2
- J'ai vérifié si des ports étaient ouverts et non. C'est censé se trouver dans la ligne "PortBindings"
Suite à l'exécution de la commande docker run --name=mon-server-web nginx, je vois que :
- Que le port ne semble pas ouvert.
- J'ai donc lancé la commande docker run -p80:80 --name=mon-server-web nginx
- Après un docker container ls, je peux voir que pour accéder au port 80, je dois passer par 0.0.0.0:80 (un localhost quoi).
- Le port est maintenant bien ouvert
- Et j'y ai accès depuis mon navigateur.

Exercice 3.

Pas besoin d'expliquer quelque chose. Les consignes sont assez explicites. J'ai créé une image sans effort.
Celui-ci est un peu plus abstrait. Nous cherchons un moyen plus "léger" d'installer une virtualisation docker avec des paramètres perso préétablis. Pour cela, on ne va pas recréer une image entière. On préférera utiliser une image déjà existante et lui donner une suite d'instructions à exécuter à la création de celle-ci. Et pour cela, on va créer un dossier où à l'intérieur, on va créer :
- Un fichier nommé "Dockerfile" contenant les instructions de création d'image.
- Dans cet exemple, un fichier html qu'on copiera dans le dossier html de la config nginx du docker. J'ai ensuite lancé la commande suivante docker build -t retest "C:\Users\Moi\Desktop\Image perso". "retest" étant le nom de mon image et "Image perso", le répertoire où se trouve mon Dockerfile.
SPOILER : J'ai eu de nombreux bugs de Docker se plaignant qu'il souhaitait un seul argument. Il se trouve que dans mon cas, j'étais obligé de spécifier le répertoire où il devait trouver le Dockerfile. Se trouver dans le repertoire ne suffisait pas. De plus, les accolades étaient obligatoires.

Labo 2 semaine 12-02-24

Exercice 1.

Bind Mount
- Suite à l'utilisation de cette commande docker run -p80:80 --name web2 --mount type=bind,source="C:\Users\Moi\Desktop\test",target=/usr/share/nginx/html/ my_nginx, j'ai donc bien :
  - Ma page qui se lance sur ma machine hôte (localhost:80)
  - Le bind qui fonctionne sur mon dossier test sur le bureau
  - Mon fichier index.html est modifiable dynamiquement :) Tout fonctionne donc comme demandé :) SPOILER : J'ai dû modifier la commande pour qu'elle passe sur ma machine Windows.
Volume Docker
- J'ai ensuite lancé cette commande : docker volume inspect mon-volume ce qui m'a permis de voir ceci "Mountpoint": "/var/lib/docker/volumes/mon-volume/_data". J'ai donc mon volume qui a bien été configuré.
- J'ai ensuite ouvert un shell (docker exec -it web5 /bin/bash) et j'ai modifié le index.html.
- J'ai lancé un deuxième serveur nginx avec le même volume et ils affichent bien la même page.

Exercice 2.

Réseau par défaut
- Après avoir exécuté un docker inspect web-server, dans l'interface réseaux, il est noté bridge. J'ai d'ailleurs remarqué que mes deux machines sont sur le même subnet.
- Oui, j'arrive à communiquer entre les deux machines grâce à un ping.
- Après un ping google.com, j'ai pu voir que j'ai effectivement accès à internet.
Réseaux définis par l'utilisateur
- Réseaux créé avec la commande : docker network create my-net
- Checker s'il existe : docker network ls
- Je vérifie la config : docker network inspect my-net et j'ai pu voir que mon subnet est "172.18.0.0/16", un autre subnet que les autres machines.
- Cette machine arrive pourtant à ping mes deux autres containers et à accéder à internet normalement.
- Après avoir lancé un second container, j'ai bien réussi à ping les autres machines. J'ai aussi constaté qu'il n'était pas obligatoire de réécrire l'IP. Docker met en place une résolution DNS :)

Exercice 3.

Docker Compose
- J'ai copié le fichier YAML en modifiant le contenu :
```
version: "3"
name: tp2
services:
  web1:
    image: my_nginx
    ports:
      - 80:80
    networks:
      - my-ne
    volumes:
      - web-volume:/usr/share/nginx/html/
  web2:
    image: my_nginx
    ports:
      - 81:80
    volumes:
      - web-volume:/usr/share/nginx/html/
    networks:
      - my-ne
volumes:
  mon-volume:

networks:
  my-ne:
```
  SPOILER : Je le fourni pur, c'est celui qui a marché chez moi mais il arrive que des caractères invisibles s'immiscent dedans. Le format YAML est très très capricieux.
- Ensuite, je suis allé dans le répertoire où mon fichier docker-compose.yml était stocké et j'ai lancé la commande docker compose up
- J'ai pu voir qu'il ne créait aucun volume ni de réseaux étant donné qu'ils existaient déjà :)
- Pour vérifier que tout fonctionnait bien, j'ai changé la page HTML dans un des containers (docker exec -it /bin/bash) et cela a fonctionné.
- Les adresses respectives de mes deux containers sont 172.19.0.3 et 172.19.0.2. J'arrive à ping entre les deux containers.
- J'ai ensuite éteint les deux machines en exécutant docker compose down

Exercice 4.

Mise en application simple

Voici le fichier YAML de l'exercice récapitulatif :

version: "3"
name: tp2ex4
services:
  ContainerA:
    image: my_nginx
    ports:
      - 80:80
    networks:
      - Réseau1
    volumes:
      - Volume1:/app
      - C:\Users\Dudley\Desktop\dossierPartage:/src
  ContainerB:
    image: my_nginx
    ports:
      - 81:80
    volumes:
      - Volume1:/app1
      - Volume2:/app2
    networks:
      - Réseau1
      - Réseau2
  ContainerC:
    image: my_nginx
    ports:
      - 82:80
    volumes:
      - Volume2:/app
    networks:
      - Réseau2
volumes:
  Volume1:
  Volume2:

networks:
  Réseau1:
  Réseau2:

Exemple du cours théorique
- Les données sont partagées avec l'hôte (bind) pour ce qui est du serveur web. Pour ce qui est de la base de données, c'est avec un volume que les données sont stockées.
- Les deux sont sur le même réseau. Ils lancent tous les deux une image différente (serveur web et base de données). Le seul conteneur ayant un port ouvert est le serveur web (3000:80).

Labo 3 - Semaine du ???

Exercice 1.

Pour mettre a jour, j'execute sudo apt update puis sudo apt upgrade
Pour changé le port ssh, on se rend /etc/ssh/sshd_config et eon change la ligne port 22 avec le port de notre choix.
J'ai créer un user avec sudo adduser deesdee. et, une fois le mdp choisi, je lui ai rajouté les permission avec ces deux commandes sudo usermod -aG docker deesdee et sudo usermod -aG sudo deesdee
Je désactive l'accès root en allant dans ce fichier /etc/ssh/sshd_config en ajoutant la ligne PermitRootLogin no
J'ai décidé d'utiliser ufw, je l'install (sudo apt install ufw), je bloque toutes les netrées et autorise les sortie (sudo ufw default deny incoming et sudo ufw default allow outgoing), je met en place sudo ufw allow 8989/tcp et sudo ufw allow 8989/udp et enfin, j'active le parefeu (sudo ufw enable).
Installation de fail2ban : sudo apt install fail2ban. Ensuite, on va le configurer. Le fichier de configuration (/etc/fail2ban/jail.conf) :

# Fail2Ban configuration file

[DEFAULT]
# Options globales

[sshd]
# Configuration pour le service SSH

enabled = true
port = (Port choisi précédement)
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
findtime = 600
bantime = 600

# Autres jails pour d'autres services peuvent suivre...

Après ceci, je redémarre fail2ban sudo systemctl restart fail2ban. Et puis, je vérifie les logs sudo tail -f /var/log/fail2ban.log pour vérifier que fail2ban est bien focntionnel (si vous voyez 'jail 'sshd started', c'est ok)

Exercice 2.

Mise en place de l'autentification ssh par clé.

Preparation

Contexte : Je compte créer les clé avec PuttyGen qui permet assez facilement de crér une clé public et privé. J'ai toujours fait comme ça :) Aussi, je me connecte avec putty sur mon serveur, je n'utiliserais donc pas le cmd dans ce tuto. Aussi, je vais ajouter manuellement la clé dans les fichiers destiné sur mon serveur. J'ai pris ce choix principalement car je suis sur une machine windows et que la commande ssh-copy-ssh

Etape 1

Je me rend donc dans PuttyGen. (qui, si vous avez installé putty, doit déjà être présent sur votre pc) Première chose que je fait, c'est que je modifie le nombre de bits de la clé (en bas a droite, normalement pré-réglé sur 2048) sur la valeur 4096. Je clique ensuite sur généré et bouge ma souris comme demandé par le programme.

Là, on a deux case où on DOIT/(peux) mettre un mot de passe. (J'ai personnellement raté à ce moment là. Les mots de passe était pas identique et j'ai pas eu d'alerte. J'ai donc été jusqu'à la fin de la deuxième étape dans le savoir ...) Il ne faut pas vilider le deux mot de passe.

On est prêt utilser no clé. Première chose, cliquer sur les deux case pour sauver vos clé public et privé. (Si vous avez un cloud, sauver les, si maintenant votre pc viendrais à tomber en passe au court de l'année (genre comme pour moi) vous ne pourez plus vous connecté à votre vps et vous devrez le faire reinitialiser.)

En haut de la page, il y a un encadré avec, au début, noté ssh-rsa. Ce texte, c'est le texte qu'on a besoin pour le serveur. C'est la clé public (formaté pour convenir à la config ssh de notre serveur) Garder le, on va en avoir besoin.

Etape 2

L'étape de la configuration serveur. On va donc set la clé ssh de l'encardé sur nitre serveur. Pour ça, il suffit de se rendre dans le dossir ~/.ssh. Modifier ou créer, si il n'existe pas déjà, notre fichier contenant les clé avec cette commande sudo nano authorized_keys Et dans ce fichier, vous coller simplement là clé (sur une seul ligne) et vous enregistrer. Ensuite, on redémarre le service sudo systemctl restart ssh && sudo systemctl restart sshd Et nous passons à la prochaine étape. SPOILER : Cette étpae n'a aucn chance de vous bloquer, vous avez toujours la possibilité de vous connecté comme avant à ce stade de la configuration.

Etape 3

Maintenant, il faut configurer putty pour qu'il utilise la clé privé au moment de la connection sur le serveur. Pour cela, dans la partie "category" de putty, on va cliqué sur le plus de SSH, puis le + de Auth, et entrer dans les paramètres de "CREDENTIALS". Et là, il suffit de donner le directory de notre clé en dessous de "Private key for auth". (en cliquant sur Browse, c'est plus simple evidement)

Une fois fait, vous pouvvez revenir sur la page de connection de base en cliquant sur "Session" dans les catégories. Pensez à sauvegarder votre config pour ne pas avoir a refaire ceci.

Tentez une connection, si tout se passe bien, vous verrez noté "Authentificating with public key ...." et si pas, vous verrez un message prevenant que la clé n'est pas passé. Si c'est le cas, reparter de l'étape 1.

Etape 4

Maintenant que vous arrivez à vous connecter, on va désactiver la connection sans clé. ça sert a rien d'avoir sécurisé une connection si celle non sécrurisé est encore accessible ... Il suffit de se rendre dans le fichier /etc/ssh/sshd_config. On y rajoute :

PubkeyAuthentication yes

Et on modifie PasswordAuthentication yes en no. On redémarre sudo service ssh restart

Et voilà, nous voila avec une connection sécurisé.

Exercice 3.

Je vérifie mon docker : docker run hello-world
Je met rapidement en place un serveur nginx pour tenter. Je vous laisse vous débrouiller :).