この記事では、WordPressのインストールを通常のインストールからコンテナーに移行する方法を見ていきます。見逃した方のために、前回の記事で、使用する予定の一般的なプロセスの概要を説明しました。
WordPressのコンテナ化は一見簡単そうです。これは標準のLAMPスタックですが、避けたい落とし穴がいくつかあります。コンテナは実際には2つのものです。保存中のコンテナイメージと実行時のLinuxプロセスです。ビルドと実行の両方の部分を見てみましょう。
編集者注：この記事では、podmanビルドを使用してRed Hat EnterpriseLinux8でコンテナーをビルドすることを前提としています。他のディストリビューションまたは他のツールチェーンで手順を使用できる場合がありますが、いくつかの変更が必要になる場合があります。
ビルド
WordPressにはPHPとWebサーバーが必要です。最も一般的な構成は、PHP FastCGI Process Manager（php-fpm）およびPHPインタープリターでApache（またはNginx）を使用することです。実際、汎用コンテナイメージは、WordPressやMediaWikiを含むほとんどすべてのPHPベースのアプリケーション用に構築できます。 Red Hat UniversalBaseImageを使用してビルドする方法の例を次に示します。
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"]
ubi-init イメージは、systemdを実行するようにすぐに構成されます in 実行時のコンテナ。これにより、インストール時にいくつかのコマンドを簡単に実行でき、Linuxディストリビューションに組み込まれている対象分野の専門知識に依存できます。私が何年も議論してきたように、コンテナ画像とサプライチェーンの衛生状態は、私たちが作成できる絶対最小の個々の画像よりも重要です（コンテナのヒント：優れたサプライチェーンの衛生状態はベース画像のサイズを軽減できますか？）。個々の画像ではなく、サプライチェーンの合計サイズを考慮する必要があるため、ubi-initを選択しました。 画像。
Containerfileがいかに単純であるかに注目してください。これは、サービスを正しく開始するためにパッケージャーに依存しているためです。参照：Linuxディストリビューションはまだコンテナと重要ですか？
これはかなり単純なビルドなので、実行時にトリッキーなものに移りましょう。
[次のこともお勧めします：docker-composeからPodmanポッドへの移動]
実行
従来のサービスと同様に、従来のサーバーでは、systemdを使用してコンテナを実行します コンテナホストを起動するとき、またはコンテナが強制終了されたときに、それらを起動する便利な方法を提供します（上の表の回復可能性）。 systemdユニットファイルを分析して、設計上の決定と、コンテナーでサービスを実行することの利点のいくつかをよりよく理解しましょう。
[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
まず、このコンテナ全体を読み取り専用で、–rmを使用して実行していることに注意してください。 オプション、それを一時的なものにします。コンテナは停止するたびに削除されます。これにより、コード、構成、およびデータを分割して外部マウントに保存する必要があります。そうしないと、失われます。これにより、コンテナを強制終了して、通常のサービスのように構成ファイルの変更を取得することもできます（これについては後で詳しく説明します）。 Apache、PHP FPM、およびMariaDBはコンテナー内で並行して実行されるため、プライベートソケットを介して通信できるので便利です。このような単純なサービスの場合、MariaDBとApacheを別々にスケーリングする必要がないため、それらを分割する必要はありません。
コード、構成、およびデータを別々のディレクトリに分割し、マウントをバインドしていることに注意してください。メインのApache、PHP、およびPHP FPMバイナリは、httpd-phpから取得されます。 コンテナイメージはRedHatUniversal Base Imageに基づいて構築されていますが、WordPressコードはコード/ワードプレスバインドマウントから取得されます。多くのコンテナでは、すべてのコードはコンテナイメージから取得されます（後でリクエストトラッカーを参照）。 code / wordpressディレクトリには、wordpress.orgからダウンロードしたWordPressPHPコードが格納されています。個人データやカスタマイズは、code/wordpressディレクトリに保存されません。それでも、WordPressが実行時にそれ自体を自動更新できるように、意図的にそれを別個の書き込み可能なバインドマウントにしました。これは、コンテナの一般的なベストプラクティスとは異なりますが、絶え間ない攻撃を受け、セキュリティ更新プログラムを頻繁に受信する人気のある公開Webサービスにとって非常に便利な機能です。このように設計すると、コンテナイメージを再構築しなくても、無線で更新できます。サービスを可能な限り無人にすることは間違いなく役に立ちます。
次に、構成行を確認します。カスタマイズされたすべての構成ファイルは、コンテナーの読み取り専用にバインドマウントされます。これは、従来のLAMPサーバー（仮想マシンまたはベアメタル）からの確実なセキュリティアップグレードです。これにより、wp-config.phpを変更しようとする一部のWordPressプラグインの使用が防止されますが、ほとんどのシステム管理者はとにかくこれらを無効にしたいと考えています。これはできた 一部のユーザーが本当にこれらのプラグインを必要としている場合は、読み取り/書き込みを行う必要があります。
次に、データディレクトリに注目してください。マウントの3つの異なるサブディレクトリをバインドします。それらはすべて書き込み可能です：
- data / wp-content –このディレクトリには、個人データとカスタマイズが含まれています。これには、WordPressテーマ、プラグイン、アップロードされたファイル（画像、ビデオ、mp3など）などが含まれます。これはWordPressマルチユーザー（MU）サイトであるため、複数のサイトがデータをここに保存することにも注意してください。 WordPress管理者は、必要に応じてログインして新しいサイトを作成できます。
- データ/ログ–アクセス/エラーを追跡したり、分析を行ったりできるように、Apacheログをコンテナーの外部に配置する必要があります。誰かがハッキングした場合にもこれらを使用でき、何が起こったのかを再構築する必要があります。ここでは、書き込み専用のマウントオプションが役立つ場合があります。
- data / mariadb –これはMariaDBの書き込み可能なディレクトリです。ほとんどのシークレットはデータベースに保存されており、このディレクトリにはmysqlユーザー/グループに対して正しく設定された権限があります。これにより、通常のLAMPサーバーと同様に、コンテナー内で同等のプロセスレベルの分離が可能になります。このMariaDBインスタンスにはWordPressデータしか含まれていないため、セキュリティが少しアップグレードされます。ハッカーはWordPressに侵入して、独自の個別のMariaDBインスタンスを持つWikiやRequestTrackerにアクセスすることはできません。
次に、–tempfsを見てみましょう。 マウントします。これらはsystemdを有効にします 読み取り専用コンテナで正しく実行するため。これらのマウントに書き込まれたデータは、コンテナが停止すると自動的に削除されます。これにより、バインドマウント以外のすべてが完全に一時的なものになります。 /var/log/messagesをキャプチャするために他の変更を加えることができます または必要に応じて他のログ。
WordPress内のバックアップについては、UpdraftPlusに依存しています。 UpdraftPlusには、テーマ、プラグイン、ファイル、データベースなど、WordPressMUサイトからすべてをバックアップできるという利点があります。 DropboxやpCloudなどのリモートストレージに（WebDavを介して）バックアップをプッシュすることもできます。これは、WordPressなどの高レベルのアプリケーションで一般的なデザインパターンです。多くの場合、データベース、CRMなどには、独自のバックアップユーティリティまたはサードパーティのバックアップソフトウェアのエコシステムがあります。この既存のソフトウェアに依存することは、コンテナでも引き続き役立ちます。
[コンテナを使い始めますか？この無料コースをチェックしてください。コンテナ化されたアプリケーションのデプロイ：技術的な概要。 ]
まとめ
これらのアプリケーションを最終的にコンテナ化するのに非常に長い時間がかかりましたが、その努力は報われました。この種のプロジェクトを簡単/中程度/難しい評価の観点から考えるのは良いことです。また、少なくともリフトアンドシフト、リファクタリング、および書き換えを検討することも役立ちます。ご覧のとおり、これらの移行には多大な労力が必要になる可能性があります。これが、計画が非常に重要である理由の大きな部分です。
また、いくつかの優れたセキュリティとパフォーマンスの実践も強調しました。また、コード、構成、およびデータを分離することで、Unixのモジュール性の信条に固執しました。
WordPressを移動したので、今度はアンティを少し上げます。このシリーズの次の記事では、MediaWikiのコンテナ化について説明します。それを消化する機会があったら、リクエストトラッカーでスイングします。
このシリーズは、CrunchTools.comの「Linuxサービスをコンテナに移動するためのハッカーガイド」に基づいており、許可を得て再発行されています。