【Docker】コンテナの分割単位

基本方針

基本的には1つのコンテナに1つのサービスを載せるという1コンテナ1プロセスが良いでしょう。ただ、関連するプロセスだったり子プロセスだったり厳密に言えばプロセスが複数載るケースは多いですがそこはざっくりと捉えると良いでしょう。Docker公式でも「1つのコンテナに1つの関心事に集中すべき」と記載があります。

定期実行ジョブ

スケジューラ機能を持つアプリの場合

1コンテナ1プロセスでもちろん良い。

スケジューラ機能を持たないアプリの場合

多くの場合「cron」を使うことになります。アプリと合わせて2つのプロセスになるがcronとアプリを同じコンテナに載せるのが複雑な構成にならず良いでしょう。

Webアプリケーション

下記の単位でコンテナを分けることが多いでしょう。

• Webサーバー（リバースプロキシ）
• アプリケーションサーバー
• データストア（データベースサーバー）

Webサーバー（リバースプロキシ）

例えば、Railsとかであれば直接PumaやUnicornなどのアプリケーションサーバーにアクセスさせることは稀です。(ローカル開発でよくあるポート3000のやつ）

一旦、NgnixなどのWebサーバーがリバースプロキシとしてリクエストを受けてそれをPumaなりUnicornなりに転送する構成が一般的です。

用途としては様々ですが、「アクセスの負荷分散」だったりとか「セキュリティ上の都合」だったりとか、「キャッシュ目的」だったり、「SSL導入」だったりとか様々な理由でこういう構成になっていたりします。

場合によっては

以下のようなコンテナを追加している案件は過去にありました。前述しましたが、一つのコンテナは一つの役割ということを意識するようにすると良いでしょう。これ以外の用途が発生してきた場合にも積極的に新しいコンテナを追加しましょう。

• バッチコンテナ
• コンソールコンテナ（コンソールなどを使いたい場合に用意する。）
• S3の代替コンテナ（minioなどを使っているケースが多いです。）

プロダクション環境でのコンテナの配置方法

1台のホストマシン（物理サーバ）で全てのDockerコンテナを動作させるのは稀です。システムトラフィックの増減や可用性、信頼性要件を鑑みて複数の物理サーバからなる分散環境を構築することが主です。

コンテナオーケストレーションやKubenetesの知識を学ぶ必要があります。(AWSを使うのであれば、ECS、Fargate、EKSなどの知識が必要になってくるでしょう。）