オープンソースで学ぶ最新クラウド技術


はじめに

前回の記事「OpenStack、Docker、OpenShiftの関係を理解する! レッドハット朝活セミナーのご紹介」では、Dockerを利用したコンテナ化アプリケーションについて、2つの利用パターンを紹介しました。
no1

特に上図の左にあるように、1つの仮想マシン(もしくは物理ホスト)に1つのコンテナでアプリケーションをデプロイするというパターンでは、Dockerによるアプリケーションデプロイの安全化/迅速化を実現しつつ、運用管理については、従来の手法を踏襲できるというメリットを紹介しました。

ただし、この場合でも、コンテナの仕組みそのものは正しく理解しておく必要があります。この記事では、Dockerが提供するコンテナの仕組みに関連して、コンテナ環境に特化した特別な仕組みを(できるだけ)使わずに、シンプルな運用管理を実現するポイントを紹介していきます。

プロセス監視

コンテナ環境では、それぞれのコンテナに対して独立したプロセステーブルが用意されるため、コンテナ内部のアプリケーションからは、同じコンテナ内のプロセスしか見えなくなります。ただし、ホストLinuxからは、すべてのコンテナのプロセスを直接に確認することが可能です。

名称未設定

これは、次のような仕組みに基づいています。まず、Dockerからコンテナを起動すると、ホストLinux上では、DockerfileのCMD命令で指定されたコマンドがDockerデーモンの子プロセスとして起動します。この際、このプロセスは、コンテナ内のネームスペース(PID namespace)で「PID=1」を割り当てられます。したがって、コンテナ内部では、最初に実行されたコマンドがPID=1のプロセスとなり、そこから子プロセスがフォークしていく形になります。

名称未設定

一方、ホストLinux上では、最初に実行されたコマンドは、あくまで、Dockerデーモンの子プロセスであり、そこからフォークするすべてのプロセスも通常のプロセスとして認識されます。したがって、ホストLinuxからコンテナ内のプロセスを監視する際は、コンテナの存在は考えずに、Dockerデーモンの子プロセスとして起動する一連のプロセスを通常通りに監視すればよいことになります。

なお、特定のコンテナに含まれるプロセスを確認する際は、dockerコマンドの「topサブコマンド」を使用することができます。

名称未設定

httping等による疎通監視

Dockerでコンテナを起動する際は、-pオプションでポートマッピングを指定することにより、ホストLinuxが受信したパケットをコンテナ内部に転送するように設定します。

名称未設定

このため、外部のクライアントからはコンテナの存在を意識する必要はありません。あくまで、ホストLinux上で直接にアプリケーションが稼働しているかのように見えることになります。したがって、外部からネットワーク経由で、アプリケーションに対する疎通監視を行うときは、ホストLinux上のアプリケーションと同様に監視を行うことが可能です。

また、このような構成の場合、アプリケーション間の通信においてもコンテナを意識する必要はありません。アプリケーション同士は、それぞれのホストLinuxのIPアドレスで通信を行います。アプリケーションの設定では、従来通り、ホストLinuxのホスト名で接続先のアプリケーションを指定することが可能です。

バッチジョブの実行

定期ジョブの実行などで、コンテナ内部でコマンドを実行する必要がある場合は、dockerコマンドのexecサブコマンドを使用します。また、ホストLinuxからファイルを受け渡す際は、コンテナ起動時の -v オプションにより、ホストLinuxのディレクトリをコンテナに割り当てておき、そこを経由して受け渡すのが簡単です。

名称未設定

ただし、実行環境をImmutableに保つという点では、外部からファイルを受け渡す処理は、できるだけ避けることをお勧めします。

次回予告

今回は、プロセス監視、疎通監視、バッチジョブ実行の3つの運用管理タスクについて説明しました。次回は、ログ監視とリソース監視に加えて、アプリケーションの停止処理を意識したDockerイメージの作成について解説します。

レッドハット・エバンジェリスト・プロフィール

中井 悦司

中井 悦司

レッドハット株式会社 クラウドエバンジェリスト
予備校講師から転身、外資系ベンダーでLinux/OSSを中心とするプロジェクト、問題解決をリードするかたわら、多数のテクニカルガイド、雑誌記事など・・・
詳細はこちら »