IMA4 2017/2018 P20

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 :

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	Heures S11	Heures S12/S13	Total
Analyse du projet	5H
Wiki	2H		2H
Documentation		2H	4H		5H
Mise en place de l'environnement de travail						5H	8H	6H		30min	30min
Prise en main des différents logiciels				5H
Constitution du conteneur principal									6H	14H	3H	6H
Constitution du conteneur utilisateur
Écriture des scripts
Test et débogage 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 :

Semaine 8

• Création d'un dépôt git : https://archives.plil.fr/mcreteur/Solution-de-messagerie

• Constitution du conteneur principal :

Maintenant que l'environnement de travail est en place, nous pouvons nous lancer dans le développement de la solution. Nous avons décidé de commencer par le serveur SMTP, donc par l'installation et la configuration de Postfix sur le système principal.

La configuration de Postfix se fait dans les fichiers main.cf qui contient la configuration de Postfix ainsi que master.cf qui contient les services Postfix à démarrer. Nous avons donc téléchargé ces deux fichiers sources pour les modifier nous mêmes et nous demanderons à Docker, grâce à un Dockerfile, de remplacer les fichiers main.cf et master.cf, qui seront présent dans le conteneur à l'installation de Postfix, par ceux que nous avons modifié pour que Postfix soit configuré.

Dans un premier temps, nous avons modifié le fichier master.cf : nous décommentons la ligne "submission inet n - n - - smtpd" afin de séparer le service de transfert de message entre serveurs de messagerie (port 25) du service de soumission de message par les clients de mesagerie (port 587) pour respecter les normes. Nous décommentons aussi certains paramètres de ce service de soumission pour restreindre son utilisation aux machines ou aux clients authentifiés par sasl par exemple pour plus de sécurité.

Dans un second temps, nous modifions le fichier main.cf : nous ajoutons le réseau privé 192.168.0.0 au paramètre mynetworks, on modifie le paramètre inet_protocols en all pour permettre l'utilisation de l'IPv6, on décommente les paramètres alias_database et alias_maps pour pouvoir par la suite, préciser les machines locales et faciliter la distribution du courier. On décommente aussi les paramètres mydestination et myorigin mais nous ne changeons pas les valeurs. Nous ferons en sorte de configurer ces paramètres par un script afin de ne pas perdre en portabilité.

Ensuite, on écrit le script permettant de mettre à jour les paramètres myorigin et mydestination en fonction de la machine sur laquelle est lancé le conteneur. Ce script se résume à postconf -e "myhostname = $HOSTNAME" pour mettre à jour le hostname et postconf -e "mydomain = $DOMAINNAME" pour mettre à jour le nom de domaine.

Enfin, on écrit le Dockerfile : On y précise que l'on veut installer Postfix, que l'on veut remplacer les fichiers main.cf et master.cf installés par défaut, par les notres. On copie le script de configuration de Postfix à l'intérieur du conteneur, on autorise son execution et on l'execute. Finalement, on expose les ports 25 et 587 du conteneur pour pouvoir utiliser les services.

Ces fichiers seront probablement amenés à subir des modifications par la suite.

Semaine 9

Pendant la configuration de Postfix, nous nous sommes posés la question de la sécurisation des échanges de données. Nous avons décidé de certifier notre serveur afin que les échanges soient chiffrés. Nous avons utilisé le Certbot de Let's Encrypt qui fournit des certificats SSL/TLS gratuitement. Avant de pouvoir utiliser ce dernier, il fallait mettre en place un serveur web. Nous avons choisi Nginx. Nous avons tenté d'installer Nginx via un simple Dockerfile sur la Raspberry mais nous avons rencontré un problème d'architecture. Il nous était impossible de lancer un conteneur avec le dockerfile sur la Raspberry bien que Docker y était installé. Après s'être documenté un peu, nous avons décider de changer de système principal et d'opter pour un Ubuntu Server.

• Mise en place de l'environnement de travail : Nous avons refait tout ce que nous avions fait sur la Raspberry pour que le serveur soit opérationnel à savoir : installation d'openssh server pour le contrôle à distance, redirection d'un port du routeur vers le serveur pour le ssh, réservation d'une adresse privée fixe, création du sous domaine mail.mcreteur.fr et paramètrages DNS associés, changement du nom d'hôte et du FQDN et finalement, installation de Docker et Docker Compose.

• Constitution du conteneur principal : Sur le serveur Ubuntu, nous avons rencontré aucun problème pour le lancement du conteneur. Cependant, le serveur web n'a pas été au point tout de suite et il a fallu de nombreuses modifications et de nombreux tests avant que ce dernier soit fonctionnel. La version finale du Dockerfile permettant de mettre en service le servuer web nginx est la suivante :

On télécharge la dernière version de Nginx, on remplace le fichier de configuration par défaut de Nginx par celui que nous avons créé, on intègre notre page html d'accueil du serveur web au bon endroit et enfin on expose les ports 80 (HTTP) et 443 (HTTPS). Comme pour Postfix, nous avons créé un fichier de configuration pour nginx. Dans ce dernier, on précise que l'on souhaite écouter sur le port 80, que le domaine est mcreteur.fr et on donne le dossier lequel le test pour la certification doit se faire.

Avant de pouvoir lancer le conteneur, il faut rediriger les ports du routeur vers le serveur afin de pouvoir accéder au serveur web. On libère donc les ports 80 et 443 et on les redirige vers le serveur. On lance le conteneur par la commande docker :

   sudo docker run --tty -i -p 80:80 -p 443:443 -v certs:/etc/letsencrypt -v certs-data:/data/letsencrypt mcreteur/certification-letsencrypt:v5

Cette commande permet de lancer le conteneur en mode interactif, en mappant les ports 80 et 443 de l'hôte sur ceux du conteneur et en mappant des volumes dans lesquels seront stockés les certificats. Grâce à cette commande, le serveur web est en ligne et accessible à l'adresse mcreteur.fr. On peut donc désormais lancer la certification par le Certbot par la commande :

   docker run -it --rm  -v certs:/etc/letsencrypt  -v certs-data:/data/letsencrypt  deliverous/certbot  certonly  --webroot --webroot-path=/data/letsencrypt --register-unsafely-without-email --agree-tos  -d mcreteur.fr

Cette commande permet de lancer le conteneur Certbot qui se supprimera lui même après avoir fait ce qu'il a à faire, pour certifier le domaine mcreteur.fr en mappant les mêmes volumes que pour le serveur web. Les premières fois que nous avons lancé ce conteneur, la certification a échoué, l'accès au domaine mcreteur.fr par le port 443 (HTTPS) était refusé par le serveur. En effet, sur le serveur, le port 443 était bloqué. Nous l'avons ouvert par la commande :

   sudo ufw allow out 443/tcp

Une fois le port 443 ouvert, la certification a été réalisé avec succès :

Il a alors fallu modifier le fichier de configuration nginx.conf pour permettre l'accès au serveur web en HTTPS par le port 443. Nous avons alors indiqué au serveur web à travers ce fichier, qu'il fallait en plus d'écouter sur le port 80, écouter aussi sur le port 443 en activant le protocole SSL et en indiquant de nombreux paramètres pour ce protocole. Une fois cela fait, nous pouvons accéder au domaine en HTTPS, la connexion à ce dernier est chiffrée :

Semaine 10

• Mise en place de l'environnement de travail : Nous avons rencontré un léger problème par rapport à l'accès à distance au serveur Ubuntu installé. La connexion à ce dernier par SSH n'était pas possible alors que la redirection du port dédié au SSH sur le routeur n'avait pas changé. Le problème venait au final du fait que les ports du serveur sont fermés par défaut. Nous avons alors ouvert un port pour le SSH de la même manière que la semaine dernière pour les ports dédiés au HTTP/HTTPS. Il faudra donc penser à ouvrir les ports nécessaires pour la communication SMTP et IMAP par la suite.

• Constitution du conteneur principal : Maintenant que nous sommes en possession de certificats TLS/SSL, nous avons indiqué leur chemin (/etc/letsencrypt/live/mcreteur.fr/) dans notre configuration Postfix. Il faudra alors lier le volume Docker les contenant lors de l'exécution du conteneur principal afin qu'ils soient utilisables et ainsi pouvoir réaliser des connexions SMTP chiffrées. Nous avons aussi essayé d'approfondir la multitude de paramètres Postfix existants. Notre configuration de Postfix actuelle reste assez flou, nous pourrons sans doute beaucoup mieux comprendre les différents paramètres lors des tests qui ne sont pour l'instant pas réalisables.

Semaine 11

• Constitution du conteneur principal : Après avoir passé beaucoup de temps sur la configuration de Postfix sans pouvoir réellement tester, nous avons décidé de passer à autre chose. Nous nous sommes alors lancés dans la mise en place du webmail Rainloop. Nous reprenons alors le Dockerfile utilisé pour Nginx puisque nous devrons indiqué au serveur web qu'il doit charger les fichiers de Rainloop. On récupère alors les fichiers d'installation par la commande :

  RUN wget http://repository.rainloop.net/v2/webmail/rainloop-latest.zip

Ensuite, on créé un dossier pour accueillir le webmail, on y décompresse les fichiers d'installations et on supprime l'archive :

  RUN mkdir /var/www/rainloop
  RUN unzip rainloop-latest.zip -d /var/www/rainloop
  RUN rm -rf rainloop-latest.zip

Le dossier /var/www/rainloop sera à partager avec Nginx pour pouvoir avoir le webmail sur notre serveur. Il faut donc modifier les droits sur ces dossiers :

 WORKDIR /var/www/rainloop
 RUN find . -type d -exec chmod 755 {} \; 
 RUN find . -type f -exec chmod 644 {} \; 
 RUN chown -R www-data:www-data .

Ces lignes dans le Dockerfile permettront d'installer correctement Rainloop dans le conteneur. Il faut maintenant modifier la configuration de Nginx pour pouvoir mettre en ligne le Webmail sur notre domaine. On modifie alors le fichier nginx.conf que nous avions créé pour obtenir les certificats. Nous avons dû procéder à de nombreux essais avant d'être capables d'accéder au webmail via l'adresse mcreteur.fr en HTTPS. Au final, nous ne touchons pas à la configuration du serveur HTTP étant donné que nous voulons que le Webmail ne soit accessible qu'en HTTPS mais on modifie le bloc concernant le serveur HTTPS. On indique alors le dossier Rainloop à charger sur lequel nous avons précédemment modifier les permissions. On indique des emplacements pour les fichiers de log et quelques règles PHP. Les paramètres SSL avaient déjà été indiqué. On laisse pour server_name "mcreteur.fr" pour pouvoir accéder au webmail via cette adresse. Après avoir configuré Nginx, on se rend compte qu'il faut installer des bibliothèques PHP dans le conteneur. On indique ces dernières dans le Dockerfile, on créé une image Docker puis on lance le conteneur associé par la commande :

   sudo docker run --tty -i -p 80:80 -p 443:443 -v certs:/etc/letsencrypt -v certs-data:/data/letsencrypt mcreteur/messagerie:v2

Encore une fois, on lie les ports 80 (HTTP) et 443 (HTTPS) du conteneur sur ceux de l'hôte de façon à ce que l'on puisse accéder au serveur Nginx et on monte de nouveau les dossiers de l'hôte Docker dans lesquels sont contenus les certificats. Nous avons alors passé beaucoup de temps sur une erreur PHP que nous indiquait le serveur. Un service PHP n'était pas lancé au démarrage du conteneur ce qui ne permettait pas d'afficher le webmail. Il faut alors lancer la commande :

  service php7.0-fpm start

Sans lancer ce service au démarrage du conteneur, le webmail n'est pas accessible.