14
21

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

Dockerが本番環境使用に厳しい理由

Last updated at Posted at 2020-01-03

Dockerはとてもシンプルで動作も軽いため開発/テスト/デモ環境などで使用している方も多いと思います。しかし本番環境ではどうでしょうか。
Webサーバーのようにいくつも稼働させて、何台かダウンしてもOKのような環境では有効だと思いますが、そのような用途ばかりではありませんよね。

Dockerをモノリシックな本番環境で利用できるか検証した際、気になった点をメモしましたので、一例としてご参考いただければと。

理由その1.MACアドレスが固定できない。

Dockerは非常にインターフェース周りで柔軟な構成が簡単に組めることが魅力ですが、まだまだ改善の余地があります。

Dockerはインターフェースが一つの時は以下のようにMACを指定できます。

docker run -itd --name hoge -p 8060:8080 --network=net1 --mac-address 00:00:00:00:00:31 --ip 172.19.0.6

しかしながら、2つ以上インターフェースがある場合、MACを指定できません。起動後、後から追加/変更する場合もMACの指定はできません。docker network connect コマンドオプションにはMACを指定するオプションがないためです。(ここではコマンドで説明しましたが、composeを使用しても同様だと思います。)

docker network connect --ip 172.20.0.6 net2

本番で仮想環境を利用する際、MACを固定することは意外に重要です。
例えばMACアドレスがNodeを識別する方法として利用されている場合、コンテナが昨日と違うMACアドレスで起動してしまうとインストールされているアプリケーションがライセンスされたノードで起動していないと判断して停止する場合もありえます。

よって、以下のような条件の環境ではDockerは本番に不向きと言えそうです。

  • インターフェースを複数利用する。
  • MACアドレスを利用している。

理由その2.仮想ネットワークルーティング機能が弱い。

皆さんご存知の通り、Dockerで -p コマンドを使ってポートフォワードを行うことができます。(dockerではpublishと呼ばれているようです)

これは内部的にはホストのiptablesを利用しています。そのためiptablesの機能的、パフォーマンス的限界がDockerのネットワーキングの限界になります。

以下、パフォーマンステストをした際、気になった点をまとめました。

 

  • パケットロスが見られる。

今回のテストにおいて、ポートフォワードされないパケットが見られました。こちらはテスト環境に依存するかもしれませんので、一例として「そういうことがあった」ぐらいに気に留めてもらえればと思います。ここでもこれ以上、詳しく触れません。

 

  • -pコマンドを利用してportをマップする機能は若干不安定。

まずは簡単に機能の説明を。
ご存知の通り、Dockerでは -p <ホストのポート>:<コンテナのポート>のように指定してpublishすることができます。

docker run -p 80:8080 nginx

上記の例ではホストの80ポート宛てのパケットはnginxが稼働しているコンテナの8080ポートにフォワードされます。

実はこの設定は-p 13000-15999:13000-15999のように範囲を指定して大量のポートをマッピングすることができます。

このポートのレンジが数百程度であればよいのですが、数千を超えてくるとDockerがメモリを食い尽くしてコマンドが失敗します
(簡単に再現しますので、お手持ちのDockerで是非試してみてください。メモリ無くなりますが。。。)

理由は以下のような点が挙げられます。

  1. iptablesへ1ポートづつマッピングを追加している
  2. 1ポートのマッピングにつき、一定量のメモリを確保するプロセスが起動する

 
よって、メディアサーバー、UC、TURN、P2Pなど大量のポートをサービスに使用する場合、ではDockerは現在の所、不向きと言えるかもしれません。

回避策としては以下のようなものがあります。

回避策1.メモリを食い尽くす挙動を止める。
回避策2.大量のポートをマップする場合はpublish機能は使わない。host networkを使う。

回避策1はStackOverflowなどで有志が設定いじって回避しようと頑張っていますが、やり方によって副作用があるかもしれませんのでお勧めしません。

回避策2については、私の師でもあるDocker Captain、Bret Fisherに訊いたところ、このように使うなと言われました。
ホスト<->複数コンテナでの柔軟なポートマッピングがそもそもしたいんですけど。。。

コミュニティに対してはネットワーク周りの改善してくれと今後も言っていく予定です。

お手軽な仮想スイッチやルーターの機能があればいいな~。

 
何かフィードバックありましたら是非よろしくお願いします。
今後も気になった点はアップデートしていく予定です。

14
21
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
14
21

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?