やる気を引き出すのに長い時間がかかりましたが、ついにいくつかの個人用Linuxサービスをコンテナ化しました。このシリーズでプロジェクトを文書化しました。この記事では、最後の例であるリクエストトラッカーについて説明します。
最初に、アプリケーションをコンテナーに移行するためのいくつかの一般的な原則について説明しました。次に、WordPressのコンテナ化について見ていき、次にMediaWikiをコンテナに移動する方法について説明しました。そのプロジェクトは、タスクスケジューリングが追加され、最初のプロジェクトよりも少し複雑でした。この最後の記事では、はるかに複雑な移行について検討します。具体的には、リクエストトラッカーについて見ていきます。ビルドと実行の両方がかなり洗練されているため、このサービスは最も注意が必要な場合があります。
編集者注：この記事では、podmanビルドを使用してRed Hat EnterpriseLinux8でコンテナーをビルドすることを前提としています。他のディストリビューションまたは他のツールチェーンで手順を使用できる場合がありますが、いくつかの変更が必要になる場合があります。
移動リクエストトラッカー
ビルド
ベース画像の上に単層の画像で実行されるWordPressやMediaWikiとは異なり、RequestTrackerはベース画像の上に2つの層を使用します。各レイヤーを見て、なぜこのようにしたのかを見てみましょう。
最初のレイヤーは、httpd-phpと非常によく似て構築されています 画像。この画像は、PerlベースのWebアプリケーションに必要なサービスを追加します。 Apache、FastCGIモジュール、Perl、MariaDB、cron、およびトラブルシューティング用のいくつかの基本的なユーティリティが含まれています。
FROM registry.access.redhat.com/ubi8/ubi-init
MAINTAINER fatherlinux <[email protected]>
RUN yum install -y httpd mod_fcgid perl mariadb-server mariadb crontabs cronie iputils net-tools; yum clean all
RUN systemctl enable mariadb
RUN systemctl enable httpd
RUN systemctl enable postfix
RUN systemctl disable systemd-update-utmp.service
ENTRYPOINT ["/sbin/init"]
CMD ["/sbin/init"]
2番目のレイヤーは、物事がかなり洗練される場所です。 Request Trackerは、CPANの多くのPerlモジュールを使用します。これらのモジュールの多くは、gccでコンパイルされています。 インストールには長い時間がかかります。また、Request Trackerを正常にインストールするには、これらの依存関係をすべて特定するのに多くの作業が必要でした。従来は、これをどこかのスクリプトでキャプチャしていましたが、コンテナを使用すると、すべてを1つのContainerfileにまとめることができます。とても便利です。
[お楽しみいただけるかもしれません：コンテナを安全にするための6つのガイド]
このファイルについて次に注意する必要があるのは、それが多段階ビルドであるということです。 PodmanとBuildahは、絶対にマルチステージビルドを実行でき、RequestTrackerなどのアプリケーションに非常に役立ちます。 WordPressやMediaWikiの場合と同様に、ディレクトリにバインドマウントすることもできますが、代わりにマルチステージビルドを選択しました。これにより、アプリケーションを別の場所で再構築する必要がある場合に、移植性と速度が向上します。
マルチステージビルドは、開発サーバーと本番サーバーを単一のビルドファイルにキャプチャすることと考えることができます。歴史的に、開発サーバーは実際には自動化が最も困難でした。 1990年代半ばのCFEngineの初期以来、開発者はバージョン管理の使用を拒否し、サーバーを機能させるために開発サーバーに必要なものを追加しました。多くの場合、ビルドを完了するために何を追加したかさえ知りませんでした。これは、十分にバックアップされた長期間のサーバーがある場合は実際には合理的でしたが、システム管理者が「開発サーバーをアップグレード」する必要がある場合は常に問題が発生しました。新しいオペレーティングシステムを搭載した新しいサーバーでビルドを機能させるのは悪夢でした。
マルチステージビルドでは、すべてのビルド命令と、構築されたキャッシュレイヤーをキャプチャします。この開発用仮想サーバーは、好きな場所で再構築できます。
FROM registry.access.redhat.com/ubi8/ubi-init
FROM localhost/httpd-perl AS localhost/rt4-build
MAINTAINER fatherlinux <[email protected]>
RUN yum install -y expat-devel gcc; yum clean all
RUN cpan -i CPAN
RUN cpan -i -f GnuPG::Interface
RUN cpan -i DBIx::SearchBuilder \
ExtUtils::Command::MM \
Text::WikiFormat \
Devel::StackTrace \
Apache::Session \
Module::Refresh \
HTML::TreeBuilder \
HTML::FormatText::WithLinks \
HTML::FormatText::WithLinks::AndTables \
Data::GUID \
CGI::Cookie \
DateTime::Format::Natural \
Text::Password::Pronounceable \
UNIVERSAL::require \
JSON \
DateTime \
Net::CIDR \
CSS::Minifier::XS \
CGI \
Devel::GlobalDestruction \
Text::Wrapper \
Net::IP \
HTML::RewriteAttributes \
Log::Dispatch \
Plack \
Regexp::Common::net::CIDR \
Scope::Upper \
CGI::Emulate::PSGI \
HTML::Mason::PSGIHandler \
HTML::Scrubber \
HTML::Entities \
HTML::Mason \
File::ShareDir \
Mail::Header \
XML::RSS \
List::MoreUtils \
Plack::Handler::Starlet \
IPC::Run3 \
Email::Address \
Role::Basic \
MIME::Entity \
Regexp::IPv6 \
Convert::Color \
Business::Hours \
Symbol::Global::Name \
MIME::Types \
Locale::Maketext::Fuzzy \
Tree::Simple \
Clone \
HTML::Quoted \
Data::Page::Pageset \
Text::Quoted \
DateTime::Locale \
HTTP::Message \
Crypt::Eksblowfish \
Data::ICal \
Locale::Maketext::Lexicon \
Time::ParseDate \
Mail::Mailer \
Email::Address::List \
Date::Extract \
CSS::Squish \
Class::Accessor::Fast \
LWP::Simple \
Module::Versions::Report \
Regexp::Common \
Date::Manip \
CGI::PSGI \
JavaScript::Minifier::XS \
FCGI \
PerlIO::eol \
GnuPG::Interface \
LWP::UserAgent >= 6.02 \
LWP::Protocol::https \
String::ShellQuote \
Crypt::X509
RUN cd /root/rt-4.4.4;make testdeps;make install
# Deploy
FROM localhost/httpd-perl AS localhost/rt:4.4.4
RUN yum install -y postfix mailx;yum clean all
COPY --from=localhost/rt4-build /opt/rt4 /opt/rt4
COPY --from=localhost/rt4-build /usr/lib64/perl5 /usr/lib64/perl5
COPY --from=localhost/rt4-build /usr/share/perl5 /usr/share/perl5
COPY --from=localhost/rt4-build /usr/local/share/perl5 /usr/local/share/perl5
COPY --from=localhost/rt4-build /usr/local/lib64/perl5/ /usr/local/lib64/perl5/
RUN chown -R root.bin /opt/rt4/lib;chown -R root.apache /opt/rt4/etc
ENTRYPOINT ["/sbin/init"]
CMD ["/sbin/init"]
この多段階ビルドの第2段階では、仮想実稼働サーバーを構築します。これを第2段階に分割することで、gccのような開発ツールをインストールする必要がなくなります。 またはexpat-devel 最終的なプロダクションイメージで。これにより、イメージのサイズが縮小され、ネットワークに公開されたサービスのソフトウェアサプライチェーンのサイズが縮小されます。これにより、誰かがハッキングした場合に、誰かが私たちのコンテナで厄介なことをする可能性も低くなる可能性があります。
この第2段階では、メールユーティリティのみをインストールします。これは、RequestTrackerの本番イメージの第2層を定義します。これらのユーティリティをhttpd-perlにインストールすることもできます。 レイヤーですが、他の多くのPerlアプリケーションはメールユーティリティを必要としません。
マルチステージビルドのもう1つの便利な点は、セキュリティパッチ用にPerlインタープリター、Apache、またはMariaDBを更新するたびにこれらのPerlモジュールをすべて再構築する必要がないことです。
実行
さて、WordPressやMediaWikiのように、実行時に使用するトリックのいくつかを見てみましょう：
[Unit]
Description=Podman container – rt.fatherlinux.com
Documentation=man:podman-generate-systemd(1)
[Service]
Type=simple
ExecStart=/usr/bin/podman run -i --rm --read-only -p 8081:8081 --name rt.fatherlinux.com \
-v /srv/rt.fatherlinux.com/code/reminders:/root/reminders:ro \
-v /srv/rt.fatherlinux.com/config/rt.fatherlinux.com.conf:/etc/httpd/conf.d/rt.fatherlinux.com.conf:ro \
-v /srv/rt.fatherlinux.com/config/MyConfig.pm:/root/.cpan/CPAN/MyConfig.pm:ro \
-v /srv/rt.fatherlinux.com/config/RT_SiteConfig.pm:/opt/rt4/etc/RT_SiteConfig.pm:ro \
-v /srv/rt.fatherlinux.com/config/root-crontab:/var/spool/cron/root:ro \
-v /srv/rt.fatherlinux.com/config/aliases:/etc/aliases:ro \
-v /srv/rt.fatherlinux.com/config/main.cf:/etc/postfix/main.cf:ro \
-v /srv/rt.fatherlinux.com/data/mariadb:/var/lib/mysql:Z \
-v /srv/rt.fatherlinux.com/data/logs/httpd:/var/log/httpd:Z \
-v /srv/rt.fatherlinux.com/data/logs/rt4:/opt/rt4/var:Z \
-v /srv/rt.fatherlinux.com/data/backups:/root/.backups:Z \
--tmpfs /etc \
--tmpfs /var/log/ \
--tmpfs /var/tmp \
--tmpfs /var/spool \
--tmpfs /var/lib \
localhost/rt:latest
ExecStop=/usr/bin/podman stop -t 3 rt.fatherlinux.com
ExecStopAfter=/usr/bin/podman rm -f rt.fatherlinux.com
Restart=always
[Install]
WantedBy=multi-user.target MediaWikiと同様に、すべての構成ファイルは読み取り専用でバインドマウントされ、確実なセキュリティアップグレードを提供します。最後に、データディレクトリは、他のコンテナと同じように読み取り/書き込み可能です。簡単な観察の1つ：リマインダーの画像にコードをバインドマウントしました 、これは、電子メールを送信し、毎週、毎月、および毎年のエントリのチケットを生成する、小さな自家製のスクリプトのセットです。
さらなる分析
コンテナ化されたLinuxサービスのいずれにも固有ではない最後のいくつかのテーマに取り組みましょう。
回復可能性
回復可能性は、慎重に検討する必要があります。 systemdを使用する 、通常のLinuxサービスと同等の確実な回復可能性が得られます。 systemdに注意してください まばたきせずにサービスを再起動します：
podman kill -a
55299bdfebea23db81f0277d45ccd967e891ab939ae3530dde155f550c18bda9
87a34fb86f854ccb86d9be46b5fe94f6e0e15322f5301e5e66c396195480047a
C8092df3249e5b01dc11fa4372a8204c120d91ab5425eb1577eb5f786c64a34b それを見てください！再開されたサービス：
0.0.0.0:80->80/tcp wordpress.crunchtools前二よりも最大未満前に、最新の/ sbinに/ initを1秒：podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
33a8f9286cee localhost/httpd-php:latest /sbin/init 1 second ago Up Less than a second ago 0.0.0.0:80->80/tcp wordpress.crunchtools.com
37dd6d4393af localhost/rt:4.4.4 /sbin/init 1 second ago Up Less than a second ago 0.0.0.0:8081->8081/tcp rt.fatherlinux.com
e4cc410680b1 localhost/httpd-php:latest /sbin/init 1 second ago Up Less than a second ago 0.0.0.0:8080->80/tcp learn.fatherlinux.com ヒントとコツ
これは、構成ファイルを変更する場合に非常に役立ちます。コンテナホストの設定ファイルを編集するか、Ansibleなどを使用して、podman kill -aを使用してすべてのコンテナを強制終了できます。 指図。 systemdを使用しているため 、サービスの再起動を適切に処理します。これはとても便利です。
コンテナ内でソフトウェアを実行するのは難しい場合があります。特に、読み取り専用で実行する場合は注意が必要です。必ずしも設計されていない方法でプロセスを制約しています。そのため、ここにいくつかのヒントとコツがあります。
まず、コンテナにいくつかの標準ユーティリティをインストールすると便利です。このガイドでは、ip-utilsをインストールしました およびnet-tools コンテナのトラブルシューティングを行うためです。たとえば、Request Trackerでは、/etc/aliasesの次のエントリのトラブルシューティングを行う必要がありました。 、メールからチケットを生成します：
professional: "|/opt/rt4/bin/rt-mailgate --queue 'Professional' --action correspond --url http://localhost:8081/"
ツールcurl 、ping 、およびnetstat 外部DNSとCloudflareも使用しているため、すべて非常に便利でした。
次はpodman diff 、これは、コンテナーを読み取り専用として実行するために広く使用しました。コンテナを読み取り/書き込みモードで実行し、podman diffを常にチェックできます。 どのファイルが変更されたかを確認します。次に例を示します：
podman diff learn.fatherlinux.com
C /var
C /var/spool
C /var/spool/cron
A /var/spool/cron/root
C /var/www
C /var/www/html
A /var/www/html/learn.fatherlinux.com
C /root
A /root/.backups Kubernetesへの移行
Podmanは、コンテナの起動以降に変更されたファイルを教えてくれることに注意してください。この場合、関心のあるすべてのファイルはtmpfsまたはバインドマウントのいずれかにあります。これにより、このコンテナを読み取り専用として実行できます。
Kubernetesをよく見ることは、当然の次のステップです。 podman generate kubeなどのコマンドを使用する そこまでの道のりの一部になりますが、永続ボリュームとそれらの永続ボリュームのバックアップを管理する方法を理解する必要があります。今のところ、Podman + systemd 素晴らしい基盤を提供します。コード、構成、データを分割するために行ったすべての作業は、Kubernetesに到達するために必要です。
環境に関する注意事項
私の環境は、4GBのRAM、2つのCPU、および80GBのストレージを備えたLinode.comで実行されている単一の仮想マシンです。コンテナホストとして機能するRHEL8の独自のカスタムイメージをアップロードすることができました。ホスト名を設定し、Cloudflareを介してDNSを指定する以外に、ホストに他の変更を加える必要はありませんでした。重要なデータはすべて/srvにあります 、これにより、障害が発生した場合の交換が非常に簡単になります。最後に、/srv コンテナホストのディレクトリは完全にバックアップされています。
/srvの構成ファイルとディレクトリ構造を確認したい場合 、ここにコードをGitHubに保存しました。
バイアス
みんなと同じように、私には偏見があり、それを開示するのは公平だと思います。 Red Hatに来る前は、キャリアの大部分でLinuxシステム管理者を務めていました。私はLinux、特にRed HatEnterpriseLinuxに偏見を持っています。私はまた、自動化と、そのオートマトンを定期的な寄稿者が利用できるようにする方法の心理学に傾倒しています。
システム管理者としての私の最初の不満の1つは、1000台のLinux Webサーバー（Web 1.0でeCardを実行）を使用するチームで作業していました。 。私たちは素晴らしい自動化を実現しましたが、新しい人々をどのように紹介するかという心理学については誰も考えていませんでした。それは流しまたは水泳でした。
このブログは、人々がそのこぶを乗り越えるのを助けると同時に、それをほとんど自己文書化することを目的としています。自動化の人間の入力とロボットの出力を考慮することは非常に重要だと思います。参照：ブートストラップとルート化のドキュメント：パート1
[無料のチートシート：Kubernetes用語集]
結論
WordPressのような一般的なサービスをコンテナに移動するのはとても簡単なようですが、実際にはそうではありません。この記事で概説されている柔軟で安全なアーキテクチャーは、通常のLAMPサーバーからOCI準拠のコンテナーに移行するための上級Linux管理者またはアーキテクトのスキルをまとめたものです。このガイドでは、Podmanと呼ばれるコンテナエンジンを活用しながら、Kubernetesのサービスを準備しました。コード、構成、データを分離することは、Kubernetesに移行するために必要な手順です。それはすべて、堅実で基本的なLinuxスキルから始まります。
この記事で強調されているいくつかの決定は、コンテナーコミュニティ内のさまざまな誤解に意図的に挑戦します。たとえば、コンテナーでsystemdを使用したり、ソフトウェアサプライチェーン全体に注意を払わずに見つけることができる最小のベースイメージのみに焦点を当てたりします。ただし、最終製品は簡単に使用できます。従来のLAMPサーバーと非常によく似たワークフローを提供し、従来のLinuxシステム管理者に最小限の認知的負荷を要求します。
この記事で行われた設計上の決定のいくつかは妥協であり、不完全です。それでも、私は現代のDevOps文化のプレッシャーと、運用および開発チームの心理学の両方を理解しているため、それらを作成しました。コンテナからより多くの価値を引き出す柔軟性を提供したかったのです。この一連のサービスは、独自のサービスの多くをコンテナーに移行するためのモデルとして役立つはずです。これにより、管理、アップグレード、およびリカバリが簡素化されます。これは、既存のLinux管理者だけでなく、これらのサービスを継承する将来のコホートにも役立ちます。これには、すべての詳細を忘れてしまう将来のバージョンも含まれます。これらのコンテナ化されたサービスは、基本的に、DevOpsカルチャーの成功につながるスタイルで自己文書化されています。
このシリーズは、CrunchTools.comの「Linuxサービスをコンテナに移動するためのハッカーガイド」に基づいており、許可を得て再発行されています。