Serveur central / coordinateur

Configuration complète du serveur central / coordinateur

Introduction

En préambule, j'indique qu'il y a de fortes chances qu'il y ait quelques "trous dans la raquette" dans cette partie étant donné que je réalise la documentation plus de 3 mois après l'installation initiale. J'ai le souvenir que j'ai passé pas mal de temps et que j'ai rencontré quelques difficultés sur le serveur central.

Mon serveur central est un VPS hébergé chez IONOS, il tourne sous Ubuntu 22.04.1 LTS. Certaines étapes peuvent donc légèrement varier selon votre système.

Configuration système de base

S'agissant d'un serveur cloud publiquement accessible, il est donc important que l'accès à ce serveur soit correctement configuré.

Ajout d'un utilisateur

J'ai commencé par me créer mon propre utilisateur, de manière à avoir mon propre espace dans /home mais aussi dans l'idée de donner un accès distant à d'autres personnes sur le même modèle ultérieurement. Une fois créé, j'ai ajouté mon utilisateur dans le groupe sudo.

adduser quentin
usermod -aG sudo quentin

Sécurisation SSH

J'ai ensuite ajouté la clé publique de la machine depuis laquelle je me connecte en SSH (cat ~/.ssh/id_rsa.pub) dans le fichier ~/.ssh/authorized_keys de mon VPS cloud. Un mkdir /home/USER/.ssh sera surement requis.

Pour faciliter les prochaines connexions, j'ai ajouté les lignes suivantes dans le fichier ~/.ssh/config (macOS) :

# IONOS 
host your_VPS # (j'ai ajouté un alias ici, que j'ai configuré ensuite dans /etc/hosts)
 IdentityFile ~/.ssh/id_rsa
 User quentin

Je peux donc me connecter sans mot de passe à mon VPS via la commande ssh mon_alias. Je vous invite à faire de même avec toutes les machines auxquelles vous vous connectez via SSH, cela simplifie la vie au quotidien.

Une fois cela fait, nous allons pousser plus loin en terme de sécurité en interdisant à la fois le login en root mais également le login via mot de passe.

Pour cela, nous ouvrons le fichier vim /etc/ssh/sshd_config et fixons PermitRootLogin & PasswordAuthentication à no.

Je vous invite vivement à vérifier que le login via clé RSA fonctionne correctement avant d'exécuter la prochaine commande sinon vous risquez d'avoir l'air très très fin après avoir redémarré le démon ssh. Une fois cela fait, nous pouvons redémarrer sshd : /etc/init.d/ssh restart.

Changement du hostname

Je profite de cette configuration de base pour changer le hostname de la machine hostname your_hostname, cela permettra de l'identifier bien plus facilement au niveau de Portainer et du monitoring.

Je vous conseille également d'effectuer un reboot suite à cette étape. Pour éviter tout problème pour la suite mais également pour confirmer que tout est en ordre sachant que nous avons changé des choses relativement bas niveau sur le serveur.

Obtention des certificats TLS

Nous allons avoir besoin de certificats TLS pour exposer de manière sécurisée les différents services que nous allons déployer. Dans mon cas, déployant régulièrement de nouveaux services, j'ai pris l'habitude d'utiliser un certificat avec wilcard : *.quentin.legraverend.fr. C'est pratique car cela me permet de déployer un nouvel applicatif, avec un nouveau nom de domaine (par exemple : nouveau.quentin.legraverend.fr) sans avoir à générer à nouveau des certificats.

Installation de Docker & Portainer Server

Ici encore, les documentations officielles sont mieux réalisées et mieux maintenues que ce que je ne pourrais faire, je vous y renvoie donc pour les installations :

Par ailleurs, dans ce guide, je ne donnerai pas précisément les fichiers de stack (docker-compose.yml) que j'utilise et que j'ai pu faire légèrement évoluer pour adapter à mon use case.

Installation de la stack Elastic

Elasticsearch & Kibana

Il est tout à fait possible d'installer la stack Elastic par l'intermédiaire de Portainer et Docker. Cependant, vu que dans mon cas cette stack sera pérenne et par choix personnel, j'ai préféré installer la stack directement au niveau système.

Je vous renvoie une fois de plus aux documentations officielles pour ce faire :

Logstash n'est pas encore présent sur la plateforme car je n'en ai pas l'utilité

Une fois installées, vous êtes libre de configurer les 2 applications comme vous le souhaitez via les fichiers de configuration adéquats (elasticsearch.yml & kibana.yml).

Quelques spécificités tout de même pour elasticsearch.yml :

discovery.type: single-node # Mon cluster est mono-noeud pour l'instant

# Activation de la security X-Pack
# (true par défaut il me semble car gratuit avec le file realm)
xpack.security.enabled: true

# Configuration de TLS sur l'API HTTP, dans mon cas j'ai effectué
# une copie du crt et de la key précédemment générés dans /etc/elasticsearch/certs
xpack.security.http.ssl:
  enabled: true
  key: certs/elasticsearch.key
  certificate: certs/elasticsearch.crt
  verification_mode: certificate

Même chose pour kibana.yml :

server:
  publicBaseUrl: "https://your_public_base_url"

# Je ne vous remets pas les détails sur le partie TLS (cf. elasticsearch.yml)
server:
  ssl:
    enabled: true
    certificate: /etc/kibana/certs/kibana.crt
    key: /etc/kibana/certs/kibana.key

# Le user avec lequel Kibana se connecte à Elasticsearch
elasticsearch:
  username: "kibana_system"
  password: "password"

Agents de collecte Beats

Une fois que les repos de la stack Elastic sont configurés, l'installation des agents est extrêmement simple :

apt-get install metricbeat
apt-get install filebeat
apt-get install heartbeat-elastic
apt-get install anyotherbeat
# Vous pouvez également installer une version spéficique si vous le souhaitez
apt-get install filebeat:8.4.3

Nous verrons leur configuration dans une partie dédiée car ces agents sont déployés sur la plupart des hosts.

PreviousCore installation NextServeur cloud slave

Last updated 1 year ago

Was this helpful?