Dans cet article, nous examinons comment migrer une installation WordPress d'une installation normale vers un conteneur. Au cas où vous l'auriez manqué, dans un article précédent, nous avons donné un aperçu du processus général que nous avons l'intention d'utiliser.
Conteneuriser WordPress semble si simple. C'est une pile LAMP standard, mais il y a quelques pièges que nous voulons éviter. Les conteneurs sont en réalité deux choses :les images de conteneur au repos et les processus Linux au moment de l'exécution. Examinons les deux parties :la création et l'exécution.
Note de l'éditeur :dans le cadre de cet article, nous supposons que vous allez créer vos conteneurs sur Red Hat Enterprise Linux 8 à l'aide de podman build. Vous pourrez peut-être utiliser les instructions sur d'autres distributions ou avec d'autres chaînes d'outils, cependant, certaines modifications peuvent être nécessaires.
Construire
WordPress a besoin de PHP et d'un serveur Web. La configuration la plus courante consiste à utiliser Apache (ou Nginx) avec PHP FastCGI Process Manager (php-fpm) et un interpréteur PHP. En fait, une image de conteneur à usage général peut être construite pour presque toutes les applications basées sur PHP, y compris WordPress et MediaWiki. Voici un exemple montrant comment en créer un avec Red Hat Universal Base Image :
FROM registry.access.redhat.com/ubi8/ubi-init
MAINTAINER fatherlinux <[email protected]>
RUN yum install -y mariadb-server mariadb php php-apcu php-intl php-mbstring php-xml php-json php-mysqlnd crontabs cronie iputils net-tools;yum clean all
RUN systemctl enable mariadb
RUN systemctl enable httpd
RUN systemctl disable systemd-update-utmp.service
ENTRYPOINT ["/sbin/init"]
CMD ["/sbin/init"]
L'ubi-init l'image est configurée par défaut pour exécuter systemd dans le conteneur lorsqu'il est exécuté. Cela facilite l'exécution de quelques commandes lors de l'installation et s'appuie sur l'expertise en la matière intégrée dans la distribution Linux. Comme je le dis depuis des années, la qualité de l'image du conteneur et l'hygiène de la chaîne d'approvisionnement sont plus importantes que les images individuelles les plus petites que nous puissions produire (Container Tidbits:Can Good Supply Chain Hygiene Mitigate Base Image Sizes?). Nous devons prendre en compte la taille totale de votre chaîne d'approvisionnement, et non les images individuelles, j'ai donc choisi le ubi-init photo.
Remarquez à quel point le Containerfile est simple. C'est parce que nous comptons sur les conditionneurs pour démarrer correctement les services. Voir aussi :Les distributions Linux ont-elles encore de l'importance avec les conteneurs ?
C'est une construction assez simple, alors passons aux choses délicates au moment de l'exécution.
[ Vous pourriez également aimer : Passer de docker-compose à des pods Podman ]
Exécuter
Comme les services traditionnels, sur des serveurs traditionnels, exécutant nos conteneurs avec systemd nous donne un moyen pratique de les démarrer lorsque nous démarrons notre hôte de conteneur ou lorsque le conteneur est tué (récupération dans le tableau ci-dessus). Découvrons notre fichier d'unité systemd pour mieux comprendre les décisions de conception et certains des avantages de l'exécution de services dans des conteneurs :
[Unit]
Description=Podman container - wordpress.crunchtools.com
[Service]
Type=simple
ExecStart=/usr/bin/podman run -i --read-only --rm -p 80:80 --name wordpress.crunchtools.com \
-v /srv/wordpress.crunchtools.com/code/wordpress:/var/www/html/wordpress.crunchtools.com:Z \
-v /srv/wordpress.crunchtools.com/config/wp-config.php:/var/www/html/wordpress.crunchtools.com/wp-config.php:ro \
-v /srv/wordpress.crunchtools.com/config/wordpress.crunchtools.com.conf:/etc/httpd/conf.d/wordpress.crunchtools.com.conf:ro \
-v /srv/wordpress.crunchtools.com/data/wp-content:/var/www/html/wordpress.crunchtools.com/wp-content:Z \
-v /srv/wordpress.crunchtools.com/data/logs/httpd:/var/log/httpd:Z \
-v /srv/wordpress.crunchtools.com/data/mariadb/:/var/lib/mysql:Z \
--tmpfs /etc \
--tmpfs /var/log/ \
--tmpfs /var/tmp \
localhost/httpd-php
ExecStop=/usr/bin/podman stop -t 3 wordpress.crunchtools.com
ExecStopAfter=/usr/bin/podman rm -f wordpress.crunchtools.com
Restart=always
[Install] WantedBy=multi-user.target
Tout d'abord, notez que nous exécutons l'intégralité de ce conteneur en lecture seule et avec le –rm option, le rendant éphémère. Le conteneur est supprimé à chaque arrêt. Cela nous oblige à diviser notre code, notre configuration et nos données et à les enregistrer sur des supports externes, sinon ils seront perdus. Cela nous donne également la possibilité de tuer le conteneur pour récupérer les modifications du fichier de configuration comme un service normal (plus à ce sujet plus tard). Apache, PHP FPM et MariaDB s'exécutent côte à côte dans le conteneur, ce qui leur permet de communiquer facilement via des sockets privés. Pour un service aussi simple, il n'est pas nécessaire de mettre à l'échelle MariaDB et Apache séparément, il n'est donc pas nécessaire de les séparer.
Notez que nous divisons le code, la configuration et les données dans des répertoires distincts et que nous relions les montages. Les principaux binaires Apache, PHP et PHP FPM proviennent du httpd-php image de conteneur construite sur Red Hat Universal Base Image, tandis que le code WordPress provient du montage de liaison code/wordpress. Dans de nombreux conteneurs, tout le code proviendra de l'image du conteneur (voir Request Tracker plus loin). Le répertoire code/wordpress contient uniquement le code PHP de WordPress téléchargé depuis wordpress.org. Aucune de nos données personnelles ou personnalisations n'est enregistrée dans le répertoire code/wordpress. Pourtant, nous en avons délibérément fait un montage de liaison distinct et inscriptible pour permettre à WordPress de se mettre à jour automatiquement au moment de l'exécution. Ceci est contraire aux meilleures pratiques typiques avec les conteneurs, mais une fonctionnalité très pratique pour un service Web public populaire qui est constamment attaqué et reçoit fréquemment des mises à jour de sécurité. L'architecturer de cette manière nous donne des mises à jour en direct sans avoir à reconstruire l'image du conteneur. Rendre les services aussi autonomes que possible est certainement utile.
Maintenant, regardez les lignes de configuration. Chaque fichier de configuration personnalisé est monté en liaison dans le conteneur en lecture seule. Il s'agit d'une mise à niveau de sécurité solide par rapport aux serveurs LAMP traditionnels (machines virtuelles ou bare metal). Cela empêche l'utilisation de certains plugins WordPress qui tentent de modifier wp-config.php, mais la plupart des administrateurs système voudront quand même les désactiver. Cela pourrait être mis en lecture-écriture si certains de nos utilisateurs ont vraiment besoin de ces plugins.
Ensuite, notez le répertoire de données. Nous lions mount trois sous-répertoires différents. Tous sont accessibles en écriture :
- data/wp-content – Ce répertoire contient nos données personnelles et nos personnalisations. Cela inclut des éléments tels que les thèmes WordPress, les plugins et les fichiers téléchargés (images, vidéos, mp3, etc.). Il convient également de noter qu'il s'agit d'un site WordPress multi-utilisateurs (MU), donc plusieurs sites enregistrent leurs données ici. Un administrateur WordPress pourrait se connecter et créer de nouveaux sites si nécessaire.
- données/journaux :nous voulons que nos journaux Apache se trouvent en dehors du conteneur afin de pouvoir suivre les accès/erreurs ou effectuer des analyses. Nous pourrions également les utiliser si quelqu'un devait pirater, et nous devons reconstituer ce qui s'est passé. Une option de montage en écriture seule pourrait être utile ici.
- data/mariadb – Ceci est notre répertoire inscriptible pour MariaDB. La plupart de nos secrets sont stockés dans la base de données, et ce répertoire a des autorisations définies correctement pour l'utilisateur/groupe mysql. Cela nous donne une isolation équivalente au niveau du processus dans le conteneur, similaire à un serveur LAMP normal. Il y a une petite mise à niveau de sécurité car cette instance MariaDB ne contient que des données WordPress. Les pirates ne peuvent pas pénétrer dans WordPress et accéder à notre Wiki ni à Request Tracker, qui ont leurs propres instances MariaDB distinctes.
Ensuite, regardons le –tempfs monte. Ceux-ci activent systemd pour s'exécuter correctement dans un conteneur en lecture seule. Toutes les données écrites sur ces montages seront automatiquement supprimées lorsque le conteneur s'arrêtera. Cela rend tout ce qui se trouve en dehors de nos montures liées complètement éphémère. D'autres modifications pourraient être apportées pour capturer /var/log/messages ou d'autres journaux si vous le souhaitez.
Pour les sauvegardes dans WordPress, nous comptons sur UpdraftPlus. UpdraftPlus offre l'avantage de tout sauvegarder à partir d'un site WordPress MU, y compris les thèmes, les plugins, les fichiers et la base de données. Il peut même pousser la sauvegarde vers un stockage distant comme Dropbox ou pCloud (via WebDav). Il s'agit d'un modèle de conception courant avec des applications de niveau supérieur telles que WordPress. Souvent, les bases de données, les CRM, etc. auront leurs propres utilitaires de sauvegarde ou écosystèmes de logiciels de sauvegarde tiers. S'appuyer sur ce logiciel existant est toujours utile dans les conteneurs.
[ Vous débutez avec les conteneurs ? Découvrez ce cours gratuit. Déploiement d'applications conteneurisées :présentation technique. ]
Récapitulation
Il m'a fallu beaucoup de temps pour enfin conteneuriser ces applications, mais l'effort a porté ses fruits. Il est bon de penser à ce type de projet en termes de notes facile/modéré/difficile. Il est également utile d'envisager au moins le lift-and-shift, la refactorisation et la réécriture. Comme vous pouvez le voir, ces migrations peuvent nécessiter beaucoup d'efforts. C'est en grande partie pourquoi la planification est si importante.
J'ai également mis l'accent sur certaines bonnes pratiques en matière de sécurité et de performances. J'ai également respecté les principes Unix de modularité avec la séparation du code, de la configuration et des données.
Maintenant que nous avons déplacé WordPress, il est temps de monter un peu la barre. Le prochain article de cette série se penche sur la conteneurisation de MediaWiki. Une fois que vous aurez eu l'occasion de digérer celle-ci, nous nous pencherons sur Request Tracker.
Cette série est basée sur "A Hacker's Guide to Moving Linux Services into Containers" sur CrunchTools.com et est republiée avec autorisation.