Je savais depuis longtemps que je voulais conteneuriser certains de mes services Linux personnels. Même si j'ai une grande expérience de la conteneurisation, je n'ai jamais eu l'impression de travailler sur mes propres applications. Je l'ai enfin fait, et j'en suis ravi !
Le premier article de cette série a présenté les services que j'ai conteneurisés. Il a également discuté de certains des pièges. J'ai envisagé les options de levage et de décalage, de refactorisation et de réécriture. J'ai également attribué aux applications des notes faciles/modérées/difficiles. J'ai ensuite abordé dans la deuxième partie mon expérience de la conteneurisation de WordPress.
Ici, nous abordons MediaWiki, qui sera similaire puisque c'est aussi un service basé sur Apache, PHP FPM, PHP.
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.
Déplacer MediaWiki
Construire
MediaWiki s'exécute dans une image de conteneur construite à partir du même Containerfile. Remarquez une petite chose non mentionnée dans la section WordPress :nous installons crontabs et Cronie . Contrairement à WordPress, qui dispose d'un utilitaire de sauvegarde avancé, avec MediaWiki, nous devons vider la base de données MariaDB pour obtenir des sauvegardes, nous avons donc besoin de cron .
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"]
Autre que l'utilisation de cron , Mediawiki ne s'appuie sur rien de spécial dans le httpd-php image du conteneur.
[ Les lecteurs ont également aimé : Conteneurs sans racine utilisant Podman ]
Exécuter
Voyons maintenant comment nous gérons MediaWiki légèrement différemment de WordPress :
[Unit]
Description=Podman container - learn.fatherlinux.com
[Service]
Type=simple
ExecStart=/usr/bin/podman run -i --read-only --rm -p 8080:80 --name learn.fatherlinux.com \
-v /srv/learn.fatherlinux.com/code/mediawiki:/var/www/html/learn.fatherlinux.com:ro \
-v /srv/learn.fatherlinux.com/config/LocalSettings.php:/var/www/html/learn.fatherlinux.com/LocalSettings.php:ro \
-v /srv/learn.fatherlinux.com/config/learn.fatherlinux.com.conf:/etc/httpd/conf.d/learn.fatherlinux.com.conf:ro \
-v /srv/learn.fatherlinux.com/config/htpasswd:/etc/httpd/conf.d/htpasswd:ro \
-v /srv/learn.fatherlinux.com/config/root-crontab:/var/spool/cron/root:ro \
-v /srv/learn.fatherlinux.com/data/mariadb/:/var/lib/mysql:Z \
-v /srv/learn.fatherlinux.com/data/images/:/var/www/html/learn.fatherlinux.com/images:Z \
-v /srv/learn.fatherlinux.com/data/skins/:/var/www/html/learn.fatherlinux.com/skins:Z \
-v /srv/learn.fatherlinux.com/data/logs/httpd:/var/log/httpd:Z \
-v /srv/learn.fatherlinux.com/data/backups/:/root/.backups:Z \
--tmpfs /etc \
--tmpfs /var/log/ \
--tmpfs /var/tmp \
localhost/httpd-php
ExecStop=/usr/bin/podman stop -t 3 learn.fatherlinux.com
ExecStopPost=/usr/bin/podman rm -f learn.fatherlinux.com
Restart=always
[Install]
WantedBy=multi-user.target
Nous exécutons le conteneur avec –read-only et –rm , tout comme WordPress, le rendant éphémère. Notez que nous lions également le code de montage/mediawiki en lecture seule. Nous aurions pu construire une autre image en couches et intégrer le code MediaWiki dans cette couche, mais nous avons décidé de le lier à la place. De nombreuses applications PHP utilisent un modèle comme WordPress, où le répertoire de code est censé être accessible en écriture au moment de l'exécution. Cette décision de conception nous donne délibérément la possibilité de rendre le répertoire de code en lecture seule ou en écriture en fonction de l'application Web PHP que nous mettons dans un conteneur. Le même httpd-php image peut être utilisée pour chacun d'entre eux, réduisant ainsi la taille de notre chaîne d'approvisionnement en logiciels. Si nous mettons à jour Glibc, OpenSSL, Apache, PHP FPM ou PHP pour résoudre les problèmes de sécurité, toutes nos applications PHP héritent de la nouvelle configuration lorsqu'elles sont redémarrées. Dans un monde parfait, nous reconstruirions continuellement ce httpd-php image dans un système CI/CD avec un bon harnais de test pour des mises à jour continues.
Les fichiers de configuration, comme WordPress, sont montés en liaison dans le conteneur en lecture seule lors de l'exécution. Encore une fois, il s'agit d'une excellente mise à niveau de sécurité par rapport à un serveur LAMP standard.
Il y a plus de répertoires de données montés en liaison dans MediaWiki. Voici pourquoi :
- data/mariadb – C'est simple. Les raisons sont identiques à WordPress.
- données/images :stocke des images, des PDF et d'autres fichiers téléchargés sur le wiki.
- data/skins – Comme WordPress, MediaWiki a été conçu avant les conteneurs. Ils ne pourraient jamais connaître les besoins des technologies futures comme les conteneurs. Contrairement à WordPress, MediaWiki est livré avec des skins pré-remplis dans ce répertoire, qui se trouve dans le répertoire code/mediawiki/skins. Ceci est une copie de ces données combinées avec nos skins personnalisés. Il s'agit d'une liaison en lecture/écriture montée afin que nous puissions ajouter de nouveaux skins si nous le souhaitons. À l'avenir, cela sera probablement résolu avec une option de superposition "-v skins:skins:o" pour Podman. Cela nous permettra de "superposer" nos données personnalisées sur les données de code/mediawiki/skins existantes fournies avec le téléchargement initial du code.
- données/journaux – Comme WordPress, nous voulons accéder à nos journaux en dehors du conteneur.
- données/sauvegardes – Contrairement à WordPress, nous devons utiliser un
crontravail pour vider la base de données MariaDB selon un calendrier. Ces sauvegardes sont placées dans ce répertoire, puis copiées hors site par l'hôte du conteneur.
[ Guide gratuit :Comment expliquer DevOps en langage clair ]
Récapitulation
Donc, c'est le deuxième service - MediaWiki ! Peut-être un peu plus difficile que WordPress, mais rien que vous ne puissiez gérer. Dans ce cas, j'ai ajouté cronie configurations. Il est également évident à quel point systemd est important les paramètres sont.
N'oubliez pas de revenir sur la conteneurisation de WordPress si vous ne l'avez pas déjà fait. Ensuite, nous aborderons la conteneurisation de 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.