Différences

Ci-dessous, les différences entre deux révisions de la page.

--- technique:infrastructure:setup_machine [2021/11/25 00:32] – qduchemi
+++ technique:infrastructure:setup_machine [2022/09/23 10:05] (Version actuelle) – [Comment configurer une machine Picasoft ?] rdelaage
@@ Ligne 1: / Ligne 1: @@
 {{indexmenu_n>25}}
 # Comment configurer une machine Picasoft ?
@@ Ligne 9: / Ligne 8: @@
 Il y a quelques petits trucs à faire pour l'intégrer dans l'infrastructure. =)
-<bootnote warning>Certains articles sont assez techniques, d'autres assez simples. Certains nécessitent juste une connexion SSH, d'autres une maîtrise de Git, certains l'[[technique:adminsys:secu:password_store:start|l'accès aux identifiants]]... C'est mieux de faire tout ça à plusieurs, n'hésite pas à organiser une réu tech!</bootnote>
+<bootnote warning>Certains articles sont assez techniques, d'autres assez simples. Certains nécessitent juste une connexion SSH, d'autres une maîtrise de Git, certains [[asso:tuto:vaultwarden|l'accès aux identifiants]]... C'est mieux de faire tout ça à plusieurs, n'hésite pas à organiser une réu tech!</bootnote>
 ## Pour tous les types de machines
+### Installer sudo
+`sudo` n'est pas présent dans les versions basiques de Debian.
+<bootnote learn>
+`sudo` (_SUperuser DO_) est un programme permettant de lancer une commande avec les droits d'administrateur sans connaître le mot de passe du super-utilisateur (`root`). Traditionnellement, les membres du groupe `sudo` ont le droit de le faire. L'association d'un membre au groupe `sudo` est réalisée grâce à l'annuaire LDAP (voir plus bas).
+</bootnote>
 ### Installer un pare-feu
@@ Ligne 17: / Ligne 24: @@
 Le pare-feu est une sécurité basique qui n'autorise les connexions sur la machine que sur certains ports connus d'avance. Notre pare-feu n'est pas très poussé ce n'est jamais une mauvaise idée de réduire la surface d'attaque.
-→ [[technique:adminsys:secu:firewall|Installation d'un pare-feu basique]]
+<bootnote web>→ [[technique:adminsys:secu:firewall|Installation d'un pare-feu basique]]</bootnote>
 ### Empêcher les tentatives de bruteforce SSH
@@ Ligne 25: / Ligne 32: @@
 Mais dès qu'une machine est exposée sur Internet avec le port SSH (22) ouvert, elle se fait attaquer de tous côtés par des bots. C'est toujours une bonne idée de les bannir pour que toute connexion des IP attaquantes soit refusée a priori. C'est le boulot de l'outil `fail2ban`.
-→ [[technique:adminsys:secu:fail2ban|Installer fail2ban sur les machines]]
+<bootnote web>→ [[technique:adminsys:secu:fail2ban|Installer fail2ban sur les machines]]</bootnote>
 ### S'authentifier grâce aux comptes Picasoft
@@ Ligne 33: / Ligne 40: @@
 Il faut donc configurer les machines pour interroger cet annuaire et permettre la connexion grâce aux comptes habituels !
-→ [[technique:adminsys:tips:auth_ldap|Activer l'authentification LDAP sur les machines]]
+<bootnote web>→ [[technique:adminsys:tips:auth_ldap|Activer l'authentification LDAP sur les machines]]</bootnote>
 ### Récupérer les métriques du système d'exploitation
@@ Ligne 45: / Ligne 52: @@
 Pour l'heure...
-→ [[technique:adminsys:monitoring:metrologie:collect:system_metrics|Récupérer les métriques du système d'exploitation]]
+<bootnote web>→ [[technique:adminsys:monitoring:collect:system_metrics|Récupérer les métriques du système d'exploitation]]</bootnote>
 ### Permettre aux machines d'envoyer des mails
@@ Ligne 55: / Ligne 62: @@
 Parfois, on aimerait que les machines nous fassent un rapport sur ce qu'elles font : mise à jour automatiques, échec de backup d'une machine virtuelle... Et le moyen le plus simple est souvent d'envoyer un mail. Pour ce faire, on configure un petit serveur mail local qui renvoie vers notre serveur mail principal.
-→ [[technique:adminsys:tips:mail|Permettre aux machines d'envoyer des mails]]
+<bootnote web>→ [[technique:adminsys:tips:mail|Permettre aux machines d'envoyer des mails]]</bootnote>
 ## Spécifique aux hyperviseurs
@@ Ligne 64: / Ligne 71: @@
 Notre serveur DNS principal tourne sur Alice. On configure traditionnellement un serveur secondaire sur chaque hyperviseur, pour répartir la charge et prévenir les incidents.
-→ [[technique:adminsys:dns:secondaire|Configurer un nouveau serveur DNS secondaire]]
+<bootnote web>→ [[technique:adminsys:dns:secondaire|Configurer un nouveau serveur DNS secondaire]]</bootnote>
 ### Métriques Proxmox
@@ Ligne 70: / Ligne 77: @@
 Notre système de [[technique:adminsys:monitoring:metrologie:stack-picasoft|métrologie]] récupère des métriques un peu partout sur l'infrastructure, notamment sur l'état de santé de Proxmox.
-→ [[technique:adminsys:monitoring:metrologie:collect:proxmox_metrics|Récupérer les métriques d'une nouvelle installation Proxmox]]
+<bootnote web>→ [[technique:adminsys:monitoring:collect:proxmox_metrics|Récupérer les métriques d'une nouvelle installation Proxmox]]</bootnote>
 ## Spécifique aux machines virtuelles
@@ Ligne 79: / Ligne 85: @@
 Heureusement, Proxmox fait ça pour nous, et tout seul !
-→ [[technique:infrastructure:backup|Configurer les backups sur une machine virtuelle]]
+<bootnote web>→ [[technique:infrastructure:backup|Configurer les backups sur une machine virtuelle]]</bootnote>
 ### Installer Docker
@@ Ligne 85: / Ligne 91: @@
 C'est [[technique:tech_team:pres_docker|grâce à Docker]] que l'on fait tourner nos services ; la première chose à faire, c'est de l'installer et de le configurer !
+<bootnote web>
 → [Installation de Docker sur Debian](https://docs.docker.com/engine/install/debian/)
 → [[technique:docker:admin:config|Configuration de Docker pour Picasoft]]
+</bootnote>
-### Exposer le démon Docker via TLS
+### Récupérer les fichiers de configuration des services
-Par défaut, l'installation Docker d'une machine n'est accessible que depuis cette machine : logique. Mais pour certains services, c'est utile de pouvoir communiquer avec le démon Docker depuis une autre machine, par exemple pour demander des informations sur les conteneurs en train de tourner.
+Sur toutes nos machines virtuelles, on lance forcément Traefik, notre [[technique:tech_team:traefik|super reverse proxy]]. Les fichiers de configuration de tous nos services sont stockés sur le Gitlab de l'UTC, il faut donc les récupérer sur la machine.
-<bootnote>[[technique:graph_services|L'outil qui produit des graphes des services]] utilise les démons Docker des machines à distance.</bootnote>
+<bootnote web>→ [[technique:docker:picasoft:dockerfiles#utiliser_le_depot_sur_les_machines|Cloner et configurer le dépôt de configuration des services]]</bootnote>
-Il y a une procédure longue et chiante pour exposer le démon de manière sécurisée (TLS, donc chiffrement) à l'extérieur. Et tant qu'à faire, pourquoi ne pas générer des graphes pour la nouvelle machine ? :-)
+### Lancer Traefik et exporter ses métriques
-→ [[technique:docker:admin:socket-certs|Exposer et sécuriser le démon Docker]]
+Traefik aussi exporte un tas de métriques ! C'est notamment elles qui nous permettent de lever des alertes s'il y a trop d'erreurs sur un service. Traefik étant un service un peu spécial, il y a un peu de configuration à faire.
-→ [Ajouter le démon dans le service de génération des graphes](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/tree/master/pica-graphbot) (voir `config.json`)
-### Récupérer les fichiers de configuration des services
+<bootnote web>
+→ [Premier lancement de Traefik sur une machine](https://gitlab.utc.fr/picasoft/projets/services/traefik/).
-Sur toutes nos machines virtuelles, on lance forcément Traefik, notre [[technique:tech_team:traefik|super reverse proxy]]. Les fichiers de configuration de tous nos services sont stockés sur le Gitlab de l'UTC, il faut donc les récupérer sur la machine.
+→ S'inspirer de la [[technique:adminsys:monitoring:collect:service_metrics|page générique d'export de métriques]] et du fichier existant pour configurer les métriques Traefik.
+</bootnote>
-→ [[technique:docker:picasoft:dockerfiles#utiliser_le_depot_sur_les_machines|Cloner et configurer le dépôt de configuration des services]]
+### Lancer la collecte des logs avec Promtail
-### Lancer Traefik et exporter ses métriques
+Les logs des conteneurs docker et du journal systemd des machines virtuelles sont collectés et envoyés sur la machine `monitoring` afin de pouvoir les centraliser et permettre la rotation et l'analyse des logs. La collecte et l'envoie des logs est fait par le service promtail qui se lance comme tous les autres services Docker.
-Traefik aussi exporte un tas de métriques ! C'est notamment elles qui nous permettent de lever des alertes s'il y a trop d'erreurs sur un service. Traefik étant un service un peu spécial, il y a un peu de configuration à faire.
+<bootnote web>
+→ [Premier lancement de Promtail sur une machine](https://gitlab.utc.fr/picasoft/projets/services/promtail/).
+</bootnote>
-→ [Premier lancement de Traefik sur une machine](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/tree/master/pica-traefik).
+### Exposer le démon Docker via TLS
-→ S'inspirer de la [[technique:adminsys:monitoring:metrologie:collect:service_metrics|page générique d'export de métriques]] et du fichier existant pour configurer les métriques Traefik.
+Par défaut, l'installation Docker d'une machine n'est accessible que depuis cette machine : logique. Mais pour certains services, c'est utile de pouvoir communiquer avec le démon Docker depuis une autre machine, par exemple pour demander des informations sur les conteneurs en train de tourner.
+<bootnote>[[technique:graph_services|L'outil qui produit des graphes des services]] utilise les démons Docker des machines à distance.</bootnote>
+Il y a une procédure longue et chiante pour exposer le démon de manière sécurisée (TLS, donc chiffrement) à l'extérieur. Et tant qu'à faire, pourquoi ne pas générer des graphes pour la nouvelle machine ? :-)
+<bootnote web>
+→ [[technique:docker:admin:socket-certs|Exposer et sécuriser le démon Docker]]
+→ [Ajouter le démon dans le service de génération des graphes](https://gitlab.utc.fr/picasoft/projets/services/graph-bot) (voir `config.json`)
+</bootnote>