- Red Hat Enterprise Linux(RHEL)のイメージモードは、ブート可能コンテナとしてRHELを構築、配布、管理するプロセスを簡素化する
- 開発、運用、およびソリューション提供者は、同じコンテナネイティブのツールと技術を使ってアプリケーションと基盤となるオペレーティングシステムを管理できる
ブート可能コンテナ vs. アプリケーションコンテナの構築
- 一般的なアプリケーションコンテナと同様に、Podman、Docker、または buildkit のような既存のコンテナ技術を使ってブート可能コンテナを構築できる
- イメージは、Quay.io、Docker Hub、GitHub Container Registry、または内部コンテナレジストリのようなコンテナレジストリに保存できる
- ブート可能コンテナはコンテナ技術の自然な進化形であり、完全なオペレーティングシステムと Linux カーネルを含めて、包括的なコンテナネイティブのワークフローとユーザー体験を提供する
Containerfile の使用
- Containerfile（Dockerfile とも呼ばれる）はコンテナイメージの構築に必要なすべての情報を含み、これにはベースイメージ、ソフトウェアパッケージのインストール手順、Git リポジトリからのファイルコピーなどが含まれる
- ブート可能コンテナを構築するためのワークフローとツールは、アプリケーションコンテナと本質的に同じである
- ただし、ブート可能コンテナを構築する際に適用すべきいくつかのベストプラクティスがある
lint のベストプラクティス
- Containerfile の最後の段階で
bootc container lint コマンドを実行することが推奨される
- このコマンドはコンテナイメージ内部で複数の検査を実行し、問題がある場合はエラーを発生させる
- たとえば、
/usr/lib/modules に複数のカーネルがあるかを確認し、/usr/lib/bootc/kargs.d 内のファイル構文を検査し、/etc および /usr/etc の衛生状態を点検する
GitHub Actions とディスク容量
- GitHub Actions を使ってコンテナを構築する際、ブート可能コンテナイメージのサイズが大きいため、ディスク容量に関する問題に直面する可能性がある
- こうした問題を解決するため、ワークフローファイルに
/opt/hostedtoolcache ディレクトリを削除するステップを追加し、ディスク容量を確保できる
/var を理解する
/var は永続的かつ変更可能なマシンローカルのデータと状態のためのディレクトリであり、アップデート中もコンテナイメージの /var の内容は変更されない- したがって、アプリケーションが
/var にデータを書き込む場合は、読み取り専用マウントの問題を避けるため、/usr/share のような別のディレクトリへ移動する必要がある
useradd コマンドの使用
- パッケージングスクリプトで
useradd を呼び出す場合、/etc/passwd がローカルで変更されると状態ドリフトが発生する可能性がある
- こうした問題を避けるため、
systemd の DynamicUser=yes オプションを使い、動的ユーザー生成を検討できる
- ただし、複雑なケースでは
DynamicUser=yes への移行が難しいことがあり、その場合は systemd-sysusers を使ってユーザーを作成するのがよい
Quadlet を使ったコンテナの組み込み
systemd でコンテナ化されたワークロードを実行することは、信頼性の高いデプロイのためのシンプルかつ強力な方法である- Podman は
systemd との統合のために Quadlet というツールを提供しており、これによってコンテナ化されたワークロードを宣言的に管理できる
- Quadlet はイメージモードと完全に統合されており、起動時にアプリケーションコンテナイメージを事前取得するため、論理的にバインドされたイメージを利用できる
まとめ
- イメージモードを使うことで、RHEL ホストの運用方法にパラダイムシフトが起こる
- クラウドネイティブツールを使ってオペレーティングシステムを構築、配布、管理でき、システムの大部分が読み取り専用でマウントされるイミュータブルOSを扱うことになる
まだコメントはありません。