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!
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).
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.
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
.
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 !
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…
Ç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.
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é.
sudo systemctl enable --now fstrim.timer
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.
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
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 !
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.
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.
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.
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
)