Comment configurer une machine Picasoft ?
Tu viens d’installer une nouvelle machine physique ou une machine virtuelle, bravo!
Question:
Comment la rendre plus « picasoftienne » ?
Il y a quelques petits trucs à faire pour l’intégrer dans l’infrastructure.
Attention:
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'accès aux identifiants… C’est mieux de faire tout ça à plusieurs, n’hésite pas à organiser une réu tech!
Pour tous les types de machines
Installer sudo
sudo
n’est pas présent dans les versions basiques de Debian.
A Savoir:
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).
Installer un pare-feu
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.
Empêcher les tentatives de bruteforce SSH
Un bruteforce, ou attaque par force brute, est une technique bien bourrine qui consiste à essayer tous les mots de passe possibles pour se connecter, dans l’espoir de deviner le bon. Dans notre cas, ça ne sert à rien puisqu’on utilise l'authentification par clé.
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
.
S'authentifier grâce aux comptes Picasoft
Sur une machine nouvellement créée, il y a le compte root
et quelques autres, mais tu ne peux pas te connecter avec ton login habituel. C’est parce que ton compte est stocké dans un annuaire « central », nommé LDAP, comme expliqué ici.
Il faut donc configurer les machines pour interroger cet annuaire et permettre la connexion grâce aux comptes habituels !
Récupérer les métriques du système d'exploitation
Sur l’instance Grafana de Picasoft, on peut voir de très beaux graphes concernant les machines : CPU utilisé, mémoire libre…
Note:
Comment ça marche ?
Il y a une section dédiée à la « métrologie » chez Picasoft : l’art de « mesurer » l’infrastructure.
Pour l’heure…
Permettre aux machines d'envoyer des mails
Ça, c’est pas indispensable sur les machines virtuelles mais ça l’est sur les hyperviseurs! Dans tous les cas, si le fonctionnement du mail t’intéresse, jette un œil.
Note:
Les machines utilisent beaucoup le mail pour faire des rapports : accès sudo
non-autorisés, liste des paquets mis à jour… Mais ces mails sont « envoyés » localement à l’utilisateur root
, autant dire : jamais consultés.
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.
Activer le « trimming » automatique des SSD
Le trim est une commande lancée sur les SSD permettant de leur dire d’effacer les blocs non utilisés. Cela permet d’optimiser la performance et la longévité des disque. Nous utilisons la manière périodique de trimmer en activant le timer systemd dédié.
- snippet.sh
sudo systemctl enable --now fstrim.timer
Spécifique aux hyperviseurs
Configurer un serveur DNS secondaire
Note:
DNS est le système qui permet notamment de faire le lien entre nom de domaine (e.g. team.picasoft.net
) et adresse IP (e.g. 91.224.148.60
). C’est donc une des pièces les plus importantes de l’infrastructure ; si le serveur DNS ne marche plus, rien ne marche!
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.
Métriques Proxmox
Notre système de métrologie récupère des métriques un peu partout sur l’infrastructure, notamment sur l’état de santé de Proxmox.
Lien:
→ Récupérer les métriques d'une nouvelle installation Proxmox</bootnote
#
# Spécifique aux machines virtuelles
### Configurer les backups
Premier réflexe : des données = des sauvegardes. Heureusement, Proxmox fait ça pour nous, et tout seul !
<bootnote web>→ Configurer les backups sur une machine virtuelle
Installer Docker
C’est grâce à Docker que l’on fait tourner nos services ; la première chose à faire, c’est de l’installer et de le configurer !
Récupérer les fichiers de configuration des services
Sur toutes nos machines virtuelles, on lance forcément Traefik, notre 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.
Lancer Traefik et exporter ses métriques
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.
Lien:
→ Premier lancement de Traefik sur une machine.
→ S’inspirer de la page générique d'export de métriques et du fichier existant pour configurer les métriques Traefik.
Lancer la collecte des logs avec Promtail
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.
Exposer le démon Docker via TLS
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.
Note:
L'outil qui produit des graphes des services utilise les démons Docker des machines à distance.
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 ?
Lien:
→ Exposer et sécuriser le démon Docker
→ Ajouter le démon dans le service de génération des graphes (voir config.json
)