Comment installer WordPress avec Docker Compose

Un serveur exécutant Ubuntu 18.04, avec un utilisateur non root doté des privilèges + sudo + et d’un pare-feu actif. Pour savoir comment les configurer, veuillez consulter ce https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04 (Guide de configuration du serveur initial)].

Docker installé sur votre serveur, en suivant les étapes 1 et 2 de Comment installer et Utilisez Docker sur Ubuntu 18.04.

Docker Compose est installé sur votre serveur en suivant l’étape 1 de la procédure https://www.digitalocean.com/community/tutorials/how-to-install-docker-compose-on-ubuntu-18-04. Comment installer Docker Compose sur Ubuntu 18.04].

Un nom de domaine enregistré. Ce tutoriel utilisera * example.com * tout au long. Vous pouvez en obtenir un gratuitement à l’adresse Freenom ou utiliser le registre de domaine de votre choix.

Les deux enregistrements DNS suivants sont configurés pour votre serveur. Vous pouvez suivre this introduction to DigitalOcean DNS pour savoir comment les ajouter à un compte DigitalOcean, si c’est ce que vous ' re utilisant:

Un enregistrement A avec ++ pointant sur l’adresse IP publique de votre serveur.

Un enregistrement A avec + www. + Pointant vers l’adresse IP publique de votre serveur.

Directives: *

+ listen +: Ceci dit à Nginx d’écouter sur le port + 80 +, ce qui nous permettra d’utiliser le plugin webroot de Certbot pour nos demandes de certificat . Notez que nous n’avons pas encore inclus le port + 443 + - nous mettrons à jour notre configuration pour inclure SSL une fois que nous aurons obtenu nos certificats.

+ nom_serveur +: Ceci définit le nom de votre serveur et le bloc serveur à utiliser pour les demandes adressées à votre serveur. Assurez-vous de remplacer «++» dans cette ligne par votre propre nom de domaine.

+ index +: La directive + index + définit les fichiers qui seront utilisés comme index lors du traitement des requêtes adressées à votre serveur. Nous avons modifié l’ordre de priorité par défaut ici, en déplaçant + index.php + devant le signe + index.html + afin que Nginx donne la priorité aux fichiers nommés + index.php + lorsque cela est possible.

+ root +: notre directive + root + nomme le répertoire racine des requêtes adressées à notre serveur. Ce répertoire, + / var / www / html +, est https://github.com/docker-library/wordpress/blob/07958d19ed465fb7fe50626be740d88a2c2260a7/php7.2/fpm-alpine/Dockerfile#L53 à titre de point de montage] au moment de la construction, consultez les instructions figurant dans notre WordPress Dockerfile. Ces instructions Dockerfile garantissent également que les fichiers de la version WordPress sont montés sur ce volume.

Blocs de localisation: *

+ location ~ / .well-known / acme-challenge +: Ce bloc d’emplacement gérera les requêtes adressées au répertoire + .well-known +, où Certbot placera un fichier temporaire pour valider que le DNS de notre domaine est résolu en notre serveur. Avec cette configuration en place, nous pourrons utiliser le plug-in webroot de Certbot pour obtenir des certificats pour notre domaine.

+ location / +: dans ce bloc d’emplacement, nous utiliserons une directive + try_files + pour rechercher les fichiers correspondant aux requêtes URI individuelles. Au lieu de renvoyer par défaut un statut + Not Found + 404, nous laisserons le contrôle au fichier + index.php + de WordPress avec les arguments de la requête.

+ location ~ \ .php $ +: Ce bloc location gérera le traitement PHP et transmettra ces requêtes à notre conteneur + wordpress +. Parce que notre image WordPress Docker sera basée sur la https://github.com/docker-library/php/blob/e63194a0006848edb13b7eff5a7f9d790d679428/7alpine3.9/fpm/Dockerfile [+ php: fpm + image], nous allons également inclure les options de configuration spécifiques au protocole FastCGI dans ce bloc. Nginx nécessite un processeur PHP indépendant pour les requêtes PHP: dans notre cas, ces requêtes seront gérées par le processeur + php-fpm + inclus dans l’image + php: fpm +. De plus, ce bloc d’emplacement inclut des directives, des variables et des options spécifiques à FastCGI qui soumettront les requêtes à l’application WordPress s’exécutant dans notre conteneur + wordpress +, définiront l’index préféré pour l’URI de la requête analysée et l’analyse des requêtes d’URI.

+ emplacement ~ / \. ht +: Ce bloc gérera les fichiers + .htaccess + car Nginx ne les servira pas. La directive + deny_all + garantit que les fichiers + .htaccess + ne seront jamais servis aux utilisateurs.

+ location = / favicon.ico,` + location = / robots.txt + : Ces blocs garantissent que les requêtes envoyées à + / favicon.ico` et + / robots.txt + ne seront pas consignées.

+ emplacement ~ * \. (css | gif | ico | jpeg | jpg | js | png) $ +: ce bloc désactive la journalisation des demandes de ressources statiques et garantit que ces ressources peuvent être mises en mémoire cache, car elles sont généralement coûteuses. servir.

+ image +: Ceci indique à Compose quelle image extraire pour créer le conteneur. Nous épinglons les https://github.com/docker-library/mysql/blob/130abae46a3da1adfc1732a08c3a08c70673e20aa5977/8.0/Dockerfile [+ mysql: + image] ici pour éviter les conflits futurs comme le `+ mysql: le dernier + image ' être mis à jour. Pour plus d’informations sur l’identification des versions et sur la prévention des conflits de dépendance, voir la documentation de Docker à l’adresse Dockerfile.

+ container_name +: Ceci spécifie un nom pour le conteneur.

+ restart +: Ceci définit la politique de redémarrage du conteneur. La valeur par défaut est + no +, mais nous avons configuré le conteneur pour qu’il redémarre sauf s’il est arrêté manuellement.

+ env_file +: Cette option indique à Compose que nous souhaitons ajouter des variables d’environnement à partir d’un fichier appelé + .env +, situé dans notre contexte de construction. Dans ce cas, le contexte de construction est notre répertoire actuel.

+ environment +: cette option vous permet d’ajouter des variables d’environnement, autres que celles définies dans votre fichier + .env +. Nous allons définir la variable + MYSQL_DATABASE + égale à ++ pour donner un nom à notre base de données d’application. Comme il s’agit d’informations non sensibles, nous pouvons les inclure directement dans le fichier + docker-compose.yml +.

+ volumes +: Ici, nous montons un nom nommé volume appelé + dbdata + dans le répertoire + / var / lib / mysql + du conteneur . C’est le répertoire de données standard de MySQL sur la plupart des distributions.

+ command +: Cette option spécifie une commande pour remplacer l’instruction CMD par défaut] pour l’image. Dans notre cas, nous allons ajouter une option à la https://dev.mysql.com/doc/refman/8.0/fr/mysqld.html [+ mysqld +]] de l’image Docker, qui démarre le serveur MySQL sur le serveur récipient. Cette option, + - default-authentication-plugin = mysql_native_password +, définit la variable système + - default-authentication-plugin + sur + mysql_native_password +, spécifiant le mécanisme d’authentification devant régir les nouvelles demandes d’authentification adressées au serveur. Depuis PHP et donc notre image WordPress won’t support https://mysqlserverteam.com/upgrading-to-mysql-8-0-default- authentication-plugin-considérations / [Le nouveau défaut d’authentification de MySQL], nous devons faire cet ajustement pour authentifier l’utilisateur de notre base de données d’application.

+ network +: Ceci spécifie que votre service d’application rejoindra le réseau + app-network +, que nous définirons en bas du fichier.

+ depend_on +: cette option garantit que nos conteneurs commenceront par ordre de dépendance, le conteneur + wordpress + commençant après le conteneur + db +. Notre application WordPress repose sur l’existence de notre base de données d’application et de notre utilisateur. L’expression de cet ordre de dépendance permettra donc à notre application de démarrer correctement.

+ image +: Pour cette configuration, nous utilisons https://github.com/docker-library/wordpress/blob/07958d19ed465fb7fef6b6fb7fe50626be740d88a2c2260a7/php7.2/fpm-alpine/Dockerfile [+ -fpm-alpine + 'WordPress image ]. Comme discuté dans https://www.digitalocean.com/community/tutorials/how-to-install-wordpress-with-docker-compose#step-1-%E2%80%94-defining-the-web-server- configuration [Étape 1], l’utilisation de cette image garantit que notre application disposera du processeur `+ php-fpm + requis par Nginx pour gérer le traitement PHP. Il s’agit également d’une image + alpine +, dérivée du projet Alpine Linux, qui nous aidera à réduire la taille globale de notre image. Pour plus d’informations sur les avantages et les inconvénients de l’utilisation des images + alpine + et si cela a du sens pour votre application, voir la discussion complète dans la section * Variantes de l’image * du https://hub.docker.com/_ / wordpress [page d’image WordPress de Docker Hub].

+ env_file +: Encore une fois, nous spécifions que nous voulons extraire des valeurs de notre fichier + .env +, car c’est ici que nous avons défini notre utilisateur et notre mot de passe de base de données d’application.

+ environment +: Ici, nous utilisons les valeurs que nous avons définies dans notre fichier + .env +, mais nous les affectons aux noms de variable attendus par l’image WordPress: + WORDPRESS_DB_USER + et + WORDPRESS_DB_PASSWORD +. Nous définissons également un + WORDPRESS_DB_HOST +, qui sera le serveur MySQL exécuté sur le conteneur + db + accessible sur le port par défaut de MySQL, + 3306 +. Notre + WORDPRESS_DB_NAME + sera la même valeur que celle spécifiée dans la définition du service MySQL pour notre + MYSQL_DATABASE +: '++ `.

+ volumes +: nous montons un volume nommé + wordpress + sur le point de montage + / var / www / html + https://github.com/docker-library/wordpress/blob/07958d19ed465fb7fe50626be740d88a2c2260a7/php7.2/ fpm-alpine / Dockerfile # L53 [créé par l’image WordPress]. L’utilisation d’un volume nommé de cette manière nous permettra de partager notre code d’application avec d’autres conteneurs.

+ network +: ajoutions également le conteneur + wordpress au réseau` + app-network + `.

+ ports +: Cela expose le port + 80 + pour activer les options de configuration définies dans notre fichier + nginx.conf + dans le lien: [Étape 1].

+ volumes +: nous définissons ici une combinaison de volumes nommés et de bind mounts:

+ wordpress: / var / www / html +: Ceci montera notre code d’application WordPress dans le répertoire + / var / www / html +, le répertoire que nous avons défini en tant que + root + dans notre bloc de serveur Nginx.

+. / nginx-conf: / etc / nginx / conf.d +: Ceci liera le répertoire de configuration Nginx de l’hôte au répertoire approprié du conteneur, en veillant à ce que toutes les modifications apportées aux fichiers de l’hôte soient effectuées. reflété dans le conteneur.

+ certbot-etc: / etc / letsencrypt +: Ceci montera les certificats et clés Let Encrypt pertinents pour notre domaine dans le répertoire approprié du conteneur.

+ - webroot +: Ceci indique à Certbot d’utiliser le plugin webroot pour placer les fichiers dans le dossier webroot aux fins d’authentification. Ce plugin dépend de la méthode de validation HTTP-01, qui utilise une requête HTTP pour prouver que Certbot peut accéder aux ressources. depuis un serveur qui répond à un nom de domaine donné.

+ - webroot-path +: Ceci spécifie le chemin du répertoire webroot.

+ - email +: Votre email préféré pour l’enregistrement et la récupération.

+ - agree-tos +: Ceci indique que vous acceptez les conditions d’utilisation ACME.

+ - no-eff-email +: Cela indique à Certbot que vous ne souhaitez pas partager votre courrier électronique avec la Electronic Frontier Foundation (EFF). N’hésitez pas à l’omettre si vous préférez.

+ - staging +: Ceci indique à Certbot que vous souhaitez utiliser l’environnement de transfert de Let Encrypt pour obtenir des certificats de test. L’utilisation de cette option vous permet de tester vos options de configuration et d’éviter les limites possibles des demandes de domaine. Pour plus d’informations sur ces limites, veuillez consulter la documentation rate de Let’Encrypt.

+ -d +: Cela vous permet de spécifier les noms de domaine que vous souhaitez appliquer à votre requête. Dans ce cas, nous avons inclus ++ et + www. +. Assurez-vous de les remplacer par votre propre domaine.