IMA4 2017/2018 P20
Sommaire
Solution de messagerie à base de conteneurs
Présentation générale
Description
Un système de messagerie électronique se compose de quatre éléments fondamentaux :
- le Mail Transfert Agent ou MTA : permet d’acheminer le courriel d’un serveur à un autre. Le protocole généralement utilisé est le SMTP.
- le serveur du protocole entrant : permet la réception et la distribution du courriel. Les plus généralement utilisés sont POP3 et IMAP.
- le Mail Delivery Agent ou MDA : agent en charge de la gestion des boîtes aux lettres. Il est chargé de livrer le courriel dans la boîte du destinataire.
- le Mail User Agent ou MUA : logiciel client de messagerie qui fournit un environnement pour la gestion du courriel.
Le but de ce projet est d'utiliser la technologie des conteneurs pour le déploiement de la solution de messagerie.
Les conteneurs sont en train de révolutionner le marché et les pratiques de la virtualisation. A des VMs, certes efficaces, mais lourdes qui s’appuient sur des hyperviseurs et qui demandent des OS invités, ils opposent un mode de virtualisation « light », directement enraciné dans le kernel de l’OS hôte. La virtualisation à base de conteneurs est une méthode de virtualisation dans laquelle la couche de virtualisation s'exécute au sein même du système d’exploitation. Cette approche permet d'améliorer les performances, puisqu'un seul et unique système d'exploitation (l'hôte) se charge des appels matériels. Elle permet également d'héberger sur un serveur beaucoup plus d'instances virtualisées que la virtualisation traditionnelle.
Objectifs
Permettre de déployer facilement un système de messagerie pour quelques utilisateurs grâce à la technologie des conteneurs. A partir de scripts Shell, on devra être capables de créer, lister ou supprimer des comptes de messagerie sur le serveur de messagerie.
Analyse du projet
Positionnement par rapport à l'existant
L'architecture de notre système de messagerie serait la suivante :
Ainsi, nous aurions :
- Un conteneur avec le système principal contenant :
- Un serveur SMTP pour la réception des différents courriels et la redistribution
- Le Webmail
- Un conteneur pour chaque compte de messagerie contenant :
- Un serveur SMTP pour recevoir et envoyer les courriels
- Un Mail Delivery Agent pour stocker les messages dans le système de fichiers du conteneur
- Un serveur IMAP pour qu'un client de messagerie puisse récupérer les messages stockés
Il n'existe pas, à notre connaissance, de solution de messagerie à base de conteneur autre que sous forme de projet en cours de développement ou proposée par des particuliers.
Analyse du premier concurrent : PEPS
PEPS est une solution open source moderne de messagerie, partage de fichiers et serveur de collaboration encore en cours de développement qui tient à rivaliser à Gmail ou Dropbox en innovant. La particularité de cette solution est son chiffrement bout à bout qui permet d'éviter le stockage des clés de chiffrement sur le serveur. Il n'y a donc que l'expéditeur et les destinataires qui peuvent lire les messages échangés.
La partie serveur de cette solution se déploie sous forme de conteneur grâce à Docker.
Cette solution propose son propre Webmail et la gestion des comptes de messagerie est faite directement à partir de ce logiciel.
Nous n'avons pas trouvé d'informations concernant le déploiement de la partie utilisateur.
Analyse du second concurrent : docker-mailserver
docker-mailserver est un serveur mail fonctionnel à déployer sous forme de conteneur développé par un particulier. Le serveur est déployé en une ligne de commande et la création d'une adresse de messagerie se fait par l'utilisation d'un script Shell.
Cette solution ne propose que la partie serveur d'une solution de messagerie.
Scénario d'usage du produit ou du concept envisagé
Michel lance sa start-up avec son ami Robert. Il décide tout de suite de mettre en place un système de messagerie. Il déploie dans un premier temps le conteneur dans lequel se trouve le système principal de messagerie sur son serveur et effectue quelques réglages nécessaires. Ensuite, sa Start-up comptant 4 employés, il déploie 4 conteneurs utilisateurs, un pour chaque compte de messagerie. Le script createAccount.sh fourni avec la solution lui permet d'attribuer très rapidement, pour chaque conteneur, une adresse de messagerie.
Les utilisateurs peuvent alors consulter et échanger des mails à partir du Webmail à l'adresse lastartupdemichel.org. Leurs adresses de messagerie ont été créé par le script sous la forme box@nom_utilisateur.lastartupdemichel.org. Ils peuvent aussi accéder au conteneur associé à leur compte de messagerie par SSH.
Michel peut vérifier que les comptes de messagerie ont bien été créé en utilisant le script listAccount.sh qui liste tous les comptes de messagerie du système. Si un employé venait à quitter la Start-up, il pourrait supprimer le compte de messagerie associé à l'employé en utilisant le script deleteAccount.sh qui lui permet de supprimer un compte de messagerie, dont il précisera le nom d'utilisateur, en une ligne de commande.
Question difficile
Quel est l'interêt de l'utilisation des conteneurs par rapport aux solutions traditionnelles de messagerie ?
Réponse à la question difficile
L'utilisation de la technologie des conteneurs permettrait un déploiement rapide et facile du système de messagerie. Les utilisateurs pourraient se créer un compte de messagerie en deux ou trois lignes de code plutôt que de devoir entrer toutes leurs informations sur le web comme nous le faisons traditionnellement.
Préparation du projet
Cahier des charges
Structure :
- Solution de messagerie fonctionnelle
- Utilisation de la technologie des conteneurs pour le déploiement de la solution :
- Un conteneur principal contenant un serveur SMTP pour la réception des différents courriels et la redistribution et une application Webmail
- Un conteneur utilisateur par compte de messagerie contenant un serveur SMTP pour recevoir et envoyer les courriels, un facteur pour stocker les messages dans le système de fichiers du conteneur et un serveur IMAP pour qu'un client de messagerie puisse récupérer les messages stockés
Utilisation :
- Scripts shell permettant la création, la suppression et le listing des comptes de messagerie sur le serveur de messagerie
Point de vue Réseau :
- Tous les éléments disposent d'une adresse IPv6 routée
- Le système principal dispose d'une adresse IPv4 routée
- Les conteneurs disposent d'une adresse IPv4 privée
- Un domaine Internet est dédié au système
- Chaque conteneur reçoit les courriels pour un sous-domaine
- Le Mail exchanger des sous-domaines donne l'adresse IPv4 du système principal sur internet
Choix techniques : matériel et logiciel
- Gestion des conteneurs : Docker CE, Docker Compose
- Mail Transfert Agent : Postfix
- Serveur IMAP : courier-imap
- Mail Delivery Agent : Procmail
- Mail User Agent :
Liste des tâches à effectuer
Calendrier prévisionnel
Réalisation du Projet
Feuille d'heures
Tâche | Prélude | Heures S1 | Heures S2 | Heures S3 | Heures S4 | Heures S5 | Heures S6 | Heures S7 | Heures S8 | Heures S9 | Heures S10 | Total |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Analyse du projet | 5H | |||||||||||
Wiki | 2H | 2H | ||||||||||
Documentation | 2H | 4H | 5H | |||||||||
Mise en place de l'environnement de travail | 5H | 8H | 6H | |||||||||
Prise en main des différents logiciels | 5H | |||||||||||
Constitution du conteneur principal | ||||||||||||
Constitution du conteneur utilisateur | ||||||||||||
Écriture des scripts | ||||||||||||
Test de la solution |
Prologue
- Analyse du projet :
- Recherches sur les systèmes de messagerie
- Recherches sur la technologie des conteneurs
- Recherche de concurrents
- Écriture d'un premier scénario d'utilisation
- Wiki :
- Remplissage de la partie Présentation générale et Analyse de projet
- Réponse à la question difficile suite à la présentation orale
Semaine 1
Documentation sur :
- Mise en place d'un système de messagerie en général
- Postfix
- Courier-imap
- Procmail
Semaine 2
- Documentation sur :
- Docker CE et Docker Compose : Installation et guides d'utilisation
- Wiki :
- Modification du scénario d'utilisation
- Remplissage de la partie Préparation du projet
Semaine 3
Prise en main des logiciels :
- Docker CE
- Docker Compose
- Docker Machine
Semaine 4
Documentation : Mise en place d'un serveur DNS
Semaine 5
Mise en place de l'environnement de travail :
- Activation de la communication série sur la Raspberry Pi :
La communication série n'étant pas activée par défaut sur la version installée de Raspbian, il faut monter la carte SD sur un ordinateur puis modifier les fichiers cmdline.txt et config.txt. On vérifie que l'option console=serial0,115200 est bien présente dans la ligne du fichier cmdline.txt et on ajoute enable_uart=1 à la fin du fichier config.txt. On peut maintenant accéder à la Raspberry Pi grâce à Minicom par la commande minicom -o -8 -b 115200 -D /dev/ttyUSB0
- Connexion de la Raspberry Pi à internet par Wifi :
Pour connecter la Raspberry Pi en Wifi, on modifie le fichier /etc/wpa_supplicant/wpa_supplicant.conf en y ajoutant à la fin :
network={ ssid="nomDeLaBox" psk="cléDeSécurité" key_mgmt=WPA-PSK }
en remplaçant "nomDeLaBox" et "cléDeSécurité" par les informations de la box à laquelle on souhaite se connecter.
- Activation du serveur SSH :
Maintenant que la Raspberry Pi est connectée à internet, on active le serveur SSH afin de pouvoir y accéder par ssh plutôt que de devoir utiliser minicom. Pour ce faire, on lance les commandes : update-rc.d ssh enable et invoke-rc.d ssh start. La Raspberry Pi est désormais accessible par ssh.
Semaine 6
Mise en place de l'environnement de travail :
- Installation de machines virtuelles :
Installation de deux machines virtuelles sous Ubuntu grâce à Virtualbox qui serviront de clients pour la solution de messagerie. Ces machines virtuelles ont été installé sur un ordinateur personnel et sont accessibles à distance. Celles-ci ont leur interface réseau configurée en accès par pont de sorte à posséder une adresse IP privée. Installation d'openssh-server pour l'accès à distance.
- Attribution d'adresses IP privées fixes aux différentes machines utilisées :
A travers l'interface graphique du routeur personnel, on réserve une adresse IPv4 privée fixe pour le système principal (Raspberry Pi) et pour les deux clients (machines virtuelles créées précédemment) . Il faut ensuite attribuer ces adresses aux machines utilisées. Sur la Raspberry, l’OS étant Raspbian Jessie, le fichier réseau à modifier n’est pas /etc/network/interfaces mais /etc/dhcpcd.conf. On ajoute dans ce dernier :
interface wlan0 static ip_address=192.168.0.11/24 static routers=192.168.0.254 static domain_name_servers=192.168.0.254
192,168,0,11 étant l’adresse réservée sur le routeur. Puis le fichier /etc/resolv.conf dans lequel on remplace l’adresse présente par celle du routeur.
- Redirection d’un port du routeur pour le ssh :
A travers l’interface graphique du routeur, on redirige un port vers l’adresse privée fixe de la Raspberry pour pouvoir y accéder en ssh depuis l’extérieur. On précise ce port dans le fichier /etc/ssh/sshd_config sur la Raspberry. On peut désormais accéder à la Raspberry à partir n'importe quel endroit par ce port.
- Réservation et configuration d'un nom de domaine :
Réservation du nom de domaine mcreteur.fr pour le système de messagerie. Ajout d'un enregistrement de type A faisant pointer le nom de domaine mcreteur.fr sur l'adresse IPv4 publique fixe du routeur personnel utilisé. Création du sous domaine smtp.mcreteur.fr qui sera dédié au serveur smtp installé sur la Rapsberry. Ajout d’un enregistrement de type A faisant pointer le sous domaine smtp.mcreteur.fr sur l’adresse IPv4 publique fixe du routeur personnel utilisé. Ajout d’un enregistrement de type MX pour le sous-domaine smtp.mcreteur.fr pour préciser que le serveur mail du domaine mcreteur.fr correspond au serveur smtp.mcreteur.fr
- Changement du nom d’hôte de la Raspberry :
On attribue le sous domaine smtp.mcreteur.fr en modifiant le fichier /etc/hostname en remplaçant raspberrypi par smtp pour faire de smtp le nom de la machine. Puis le fichier /etc/hosts en remplaçant l’occurence raspberrypi par smtp.mcreteur.fr smtp pour préciser le FQDN et le hostname.
On peut vérifier que le serveur mail du domaine mcreteur.fr est bien géré par le sous domaine smtp.mcreteur.fr :
Semaine 7
Mise en place de l'environnement de travail :
- Installation de l’environnement Docker sur les différents machines utilisées :
- Installation de Docker CE :
- Installation des packages nécessaires à l’utilitaire apt pour utiliser un dépôt à travers HTTPS :
sudo apt-get install \ apt-transport-https \ ca-certificates \ curl \ gnupg2 \ software-properties-common
- Ajout de la clé GPG officielle Docker : Pour la Raspberry :
curl -fsSL https://download.docker.com/linux/$(. /etc/os-release; echo "$ID")/gpg | sudo apt-key add -
Pour les VM sous Ubuntu :
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
- Utilisation du dépôt stable :
Pour la Raspberry :
echo "deb [arch=armhf] https://download.docker.com/linux/$(. /etc/os-release; echo "$ID") \ $(lsb_release -cs) stable" | \ sudo tee /etc/apt/sources.list.d/docker.list
Pour les VM sous Ubuntu :
sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable"
- Mise à jour des packets :
sudo apt-get update
- Installation de la dernière version de Docker CE :
sudo apt-get install docker-ce
- Installation de Docker Compose :
sudo apt-get install docker-compose
- Mise en place d’un cluster Docker swarm :
Afin de pouvoir déployer les conteneurs sur toutes les machines utilisées d’un seul coup à partir du serveur, on met en place un cluster avec Docker Swarm. Sur le système principal, on lance la commande :
docker swarm init --advertise-addr 192.168.0.11
qui permet de mettre en place le cluster à l’adresse IP 192.168.0.11 qui est celle du système principal. Le système principal est alors un manager du cluster. La commande entrée nous renvoi la commande à utiliser sur les autres machines pour rejoindre le cluster.
Sur les deux machines virtuelles, on entre alors la commande la commande indiquée pour rejoindre le cluster en tant que worker, les machines virtuelles étant les clients du système.
Une fois la commande entrée sur les deux clients, on peut vérifier que toutes les machines sont bien connectées au cluster :