よくある質問と回答(FAQ)¶
あなたの質問がここになければ、 docs@docker.com まで遠慮なくお送りください。あるいは、 リポジトリをフォークし 、ドキュメントのソースを自分自身で編集し、それらで貢献することもできます。
Docker を使うには、どれだけの費用がかかりますか？¶
Docker は 100% 自由に使えます。オープンソースであり、何も支払わなくても利用できます。
オープンソースのライセンスは何を使っていますか？¶
Apache License Version 2.0 を使っています。こちらをご覧ください：https://github.com/docker/docker/blob/master/LICENSE
Mac OS X や Windows で Docker は動きますか？¶
現時点の Docker は Linux 上でしか動きません。しかし VirtualBox を使えば、仮想マシン上で Docker を動かせるため、どちらの環境でも便利に扱えるでしょう。具体的な方法は Mac OS X と Microsoft Windows のインストールガイドをご覧ください。どちらの場合でも、 OS 上に仮想マシン内で Docker Machine を実行するための、小さな Linux ディストリビューションをインストールします。
注釈
Docker Machine を通して仮想マシン上の Docker デーモンをリモート操作する場合は、ドキュメントのサンプルで docker コマンドの前にある sudo を 入力しないでください 。
コンテナと仮想マシンの違いは何ですか？¶
相互補完します。仮想マシンはハードウェア・リソースの塊を割り当てるのに一番便利です。コンテナの操作はプロセス・レベルであり、ソフトウェアのデリバリをまとめることができるため、軽量かつパーフェクトです。
なぜ Docker は LXC に技術を追加しようとしたのですか？¶
Docker 技術は LXC の置き換えではありません。 「LXC」は Linux カーネルの機能を参照しており（特に名前空間とコントロール・グループ）、あるプロセスから別のプロセスに対するサンドボックスを可能とし、リソースの割り当てを制御するものです。これらはカーネル機能のローレベルを基礎としています。一方、Docker は複数の強力な機能を持つハイレベルなツールです。
マシンをまたがるポータブルなデプロイ 。Docker はアプリケーションを構築するためのフォーマットを定義し、その全ての依存関係を１つのオブジェクトにすることで、 Docker が利用可能なあらゆるマシン上に移動できるようにします。そして、アプリケーションが同じような環境で動作できるようにするのを保証します。LXC によって実装されるプロセスはサンドボックス（砂場）であり、ポータブルなデプロイの準備としては、重要な環境です。しかしながら、ポータブルなデプロイには十分とは言えません。もしあなたが私にカスタム LXC 設定を施したアプリケーションを送ってきたとしても、おそらく私のマシン上では動作しないでしょう。なぜなら、マシン固有の情報が紐付いているからです。例えばネットワーク、ストレージ、ログ保存、ディストリビューション等です。Docker は、これらマシン固有の情報を抽象化しますので、同じ Docker コンテナであれば間違いなく実行できます。マシンが異なり、環境が変わっていたとしても、コンテナに対して変更を加える必要がありません。
アプリケーション中心型 。Docker が最適化されているのはマシンに対してというよりも、アプリケーションのデプロイに対してです。これは API やユーザ・インターフェース、設計哲学やドキュメントにも反映されています。対照的に
lxcの場合は、コンテナを軽量なマシンとして扱うための補助スクリプトに注力しています。ここで言うマシンというのは、基本的なサーバのことであり、より速く起動し、メモリを必要としない環境です。私たちは LXC よりもコンテナのほうが、より多くの利点があると考えています。
自動構築（ Automatic Build ） 。Docker には、 開発者向けにソース・コードからコンテナを自動的に構築する機能 があります。これは構築ツールやパッケージングにあたるアプリケーションの依存性を完全に管理します。マシンの設定に関係無く、
make、maven、chef、puppet、salt、 Debian パッケージ、 RPM 、ソースの tar ボール等を自由に扱えます。
バージョン管理 。Docker には Git のようにコンテナのバージョン推移を追跡する機能があり、バージョン間の差分を調べ、新しいバージョンをコミットしたり、ロールバックしたり等ができます。また履歴を辿ることで、誰によって何が組み込まれたかを把握できます。そのため、開発元からプロダクションのサーバに至るまでの流れを完全に追跡できます。また Docker には
git pullのようにアップロード回数とダウンロード回数を記録する機能があるため、コンテナの新しいバージョンを送信するとは、単に差分を送信するだけです。
再利用可能なコンポーネント 。コンテナは特別なコンポーネントを「 ベース・イメージ 」として利用できます。これは手動もしくは自動構築の一部で使えます。例えば、望ましい Python 環境を用意しておけば、10以上もの異なるアプリケーションの基盤になります。あるいは、望ましい PostgreSQL をセットアップしておけば、自分の将来のプロジェクトで再利用可能になるでしょう。このような使い方ができます。
共有 。Docker は Docker Hub というパブリック・レジストリにアクセスします。そこでは数千人もの人たちが便利なイメージをアップロードしています。Redis 、 CouchDB 、PostgreSQL といったイメージから、IRC バウンサーや Rails アプリケーション・サーバや、Hadoop 向けや、様々なディストリビューション向けのベース・イメージがあります。また、公式の「標準ライブラリ（standard library）」には レジストリ という名前の、Docker チームによって管理されている便利なコンテナがあります。レジストリ自身はオープンソースでアリ、誰もが自分自身でレジストリに対して、プライベートなコンテナの保管や転送が可能になります。例えば内部のサーバへデプロイすることも可能です。
ツールのエコシステム 。Docker はコンテナの作成と開発のために、自動化・カスタマイズ化の API を定義しています。Docker を互換性のある非常に多くのツールと連携できます。PaaS 風のデプロイ（ Dokku、Deis、Flynn）、複数ノードのオーケストレーション（Maestro、Salt、Mesos、OpenStack Nova）、ダッシュボード管理（docker-ui、Openstack Horizon、Shipyard）、設定管理（Chef、Puppet）、継続的インテグレーション（Jenkins、Strider、travis）等です。コンテナを基盤としたツール標準として、Docker は自身を迅速に起動できます。
Docker コンテナと仮想マシンの違いは何ですか？¶
StackOverflow の回答に、素晴らしい 違いについての説明 があります。
コンテナを終了するとデータが失われますか？¶
コンテナのアプリケーションがディスクに書き込んだあらゆるデータは、コンテナを削除しない限りデータも削除されることはありません。コンテナを停止したとしても、コンテナのファイルシステムは一貫性を保ちます。
Docker コンテナは、どれだけスケールできますか？¶
今日に世界中で大きなサーバ・ファームのいくつかは、コンテナを基盤としています。Google や Twitter のように大きなウェブのデプロイ環境や、Heroku や dotCloud のように全てをコンテナ技術上で実行します。これら数百から数千、もしくは数百万ものコンテナを並列で実行します。
Docker コンテナにどうやって接続しますか？¶
現時点で推奨する方法は、Docker ネットワーク機能を通してコンテナに接続する方法です。詳細については Docker ネットワークの働き をご覧ください。
またサービスのポータビリティをフレキシブルにするには、 アンバサダ・リンク・パターン も便利です。
Docker コンテナで複数のプロセスを実行するには？¶
http://supervisord.org/ のようなスーパーバイザや、 runit 、 s6 、daemontools によって実現できます。Docker はプロセス管理用デーモンを起動し、その後、追加プロセスをフォークして実行します。プロセス管理デーモンが動く限り、コンテナも同様に動き続けます。具体的な例については、 supervisord の使い方 をご覧ください。
どのプラットフォーム上で Docker は動きますか？¶
Linux:
Ubuntu 12.04, 14.04 等
Fedora 19/20+
RHEL 6.5+
CentOS 6+
Gentoo
ArchLinux
openSUSE 12.3+
CRUX 3.0+
等
Cloud:
Amazon EC2
Google Compute Engine
Microsoft Azure
Rackspace
等
Docker のセキュリティ問題はどこに報告したらよいですか？¶
プロジェクトのセキュリティ・ポリシーについては こちら から確認できます。セキュリティ問題については、こちらの メールボックス までお知らせください。
なぜ Docker の DCO で署名してからコミットする必要があるのでか？¶
DCO (Developer's Certificate of Origin) については、 こちらのブログ投稿 をご覧ください。
イメージの構築時、望ましいシステムライブラリや同梱物はありますか？¶
このディスカッションの詳細については docker-dev メーリングリストの議論 をご覧ください。
全てのプログラムは擬似的に第三者のライブラリに依存しています。よくあるのは、動的なリンクや、ある種のパッケージ依存性です。そのため、複数のプログラムが同じライブラリを必要とするなら、インストールは一度で済みます。
しかしながら、いくつかのプログラムは、特定バージョンのライブラリに依存するため、自分自身でサード・パーティー製のライブラリを同梱しています。例えば、Node.js は OpenSSL を同梱していますし、MongoDB は V8 と Boost （他にも）を同梱しています。
Docker イメージの作成にあたり、ライブラリの同梱は使い易いものです。しかし、システム・ライブラリに含まれるデフォルトのものを使わず、自分自身でプログラムを構築すべきでしょうか？
システム・ライブラリに関する重要なポイントは、ディスクやメモリ使用量の節約のためではありません。セキュリティのためなのです。全ての主要なディストリビューションは深刻なセキュリティを抱えています。そのため、専用のセキュリティ・チームを持ち、脆弱性が発見されれば対処を行い、一般に情報を開示します（これら手順の具体例は Debian Security Information をご覧ください）。しかし、上流の開発者によっては、常に同じ手順が踏まれるわけではありません。
Docker イメージの構築時、ソースからプログラムを構築する前に、同梱したいライブラリがあるのであれば、上流の開発者がセキュリティの脆弱性に関する便利な情報を提供しているかどうか、彼らが適時ライブラリを更新するかどうか確認すべきです。彼らが対処しないならば、あなたが自分自身（そして、あなたのイメージの利用者）でセキュリティ脆弱性を対処することになります。
他人によって作成されたパッケージを使う場合も同様です。パッケージに関するセキュリティのベスト・プラクティスと同様に、チャンネルが情報を提供しているか確認すべきでしょう。「全てが中に入っている」（all-in-one） .deb や .rpm のダウンロードとインストールをする場合、OpenSSLライブラリの脆弱性である Heartbleed バグを抱えているものをコピーされていないかどうか、それを確認する方法はありません。
なぜ Dockerfile で DEBIAN_FRONTEND=noninteractive なのですか？¶
Docker イメージを Debian と Ubuntu 上で構築する時、次のようなエラーがでることがあります。
unable to initialize frontend: Dialog
イメージの構築時、これらのエラーが出ても処理を中断しませんが、インストール時のプロセスでダイアログ・ボックスを表示しようとしても、実行できなかったという情報を表示しています。通常、これらのエラーは安全であり、無視して構いません。
Dockerfile の中で環境変数 DEBIAN_FRONTEND を変更して使い、これらエラーの回避のために使っている方がいます。
ENV DEBIAN_FRONTEND=noninteractive
これはインストール時にダイアログ・ボックスを開こうとして、エラーがあっても停止しないようにします。
これは良い考えかもしれませんが、一方で影響がある かも しれません。 DEBIAN_FRONTEND 環境変数はイメージからコンテナを構築するにあたり、全てのイメージに対し変更設定が継承されます。対象のイメージを使おうとする人たちが、ソフトウェアをインタラクティブに設定する時に、インストーラは何らダイアログ・ボックスを表示しないため、問題が起こりうる場合があります。
このような状況のため、 DEBIAN_FRONTEND を noninteractive に指定するのは「お飾り」の変更であるため、私たちはこのような変更を 推奨しません 。
本当にこの値を変更する必要がある場合は、あとで デフォルト値 に差し戻してください。
実行中のコンテナ上のサービスにリクエストを送ると Connection reset by peer が出るのはなぜ？¶
このメッセージが表示される主な理由は、サービスは既にローカルホスト上に結びついているからです。その結果、コンテナの外から届いたリクエストは破棄されます。この問題を解決するには、ローカルホスト上のサービスの設定を変更し、サービスが全ての IP アドレスからのリクエストを受け付けるようにします。この設定の仕方が分からなければ、各 OS のドキュメントをご覧ください。
docker-machine 利用時に Cannot connect to .... というエラーが出ます¶
エラー「Cannot connect to the Docker daemon. Is the docker daemon running on this host」が表示されるのは、Docker クライアントが仮想マシンに接続できない時です。つまり、 docker-machine 配下で動く仮想マシンが動作していないか、クライアントが操作時点でマシンを適切に参照できない場合を表します。
docker-machine ls コマンドを使って docker マシンが動作しているかどうかを各西、必要があれば docker-machine start コマンドで起動します。
$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
default - virtualbox Stopped Unknown
$ docker-machine start default
Docker クライアントはマシンと通信する必要があります。これには docker-machine env コマンドを使います。実行例：
$ eval "$(docker-machine env default)"
$ docker ps