出典：「Nova typis transacta navigatio」（Linz：sn、1621）、p.12（British Library、G.7237）。
多くの場合、Dockerについての会話中に、私はまったく同意しない意見を聞きます。
「Dockerは本質的に大企業向けに設計されています」
「OSxでは実験的なサポートがあり、Windowsではほとんど動作しません」
「すぐにローカルに展開できるかどうかわかりません」
...などなど。
これらの声明にはいくつかの真実がありますが（以下の神話3と5を参照）、それは小さく、ほとんどの場合、実際の画像は歪んでいます。
また、かなりの数のフレームワークを使用する場合に、1秒あたり1,000万件のリクエストを使用する方法に関する専門用語の記事もあります。 そして、これはわずか3万個のコンテナーの助けを借りて、600個のクラウド仮想マシンでホストされる5万個のマイクロサービスを自動化します...
Dockerが多くの神話に囲まれている理由を推測するのは簡単です。
残念ながら、これらの神話は非常に粘り強いものです。 そして、彼らの主な成果は、開発者を怖がらせ、Dockerの使用を決定するのを防ぐことです。
最も一般的な神話-私が出会って信じたもの-について話し、それらの真実と解決策（もしあれば）を見つけようとします。
神話10：Dockerでは開発できません...
dockerfileを編集できないため
開発には、特別なツールと環境設定が必要です。 同時に、彼らは産業操作で使用されるDockerfileを編集することは不可能であることを私に正しく指摘しました。
コンバットDockerイメージは、産業運用のニーズにのみ設定し、それ以上は設定しないでください。
どうする？ 自分のツールと設定をDockerfileに追加できない場合、Dockerでどのように開発できますか？
バトルDockerfileを自分のDockerfileにコピーして、コピーに必要な変更を加えることができます。 しかし、複製は不快な結果につながる可能性があります。
解決策
Dockerfileをコピーするのではなく、追加の問題が発生する可能性がありますが、Docker機能を使用して、他のイメージに基づいてイメージを作成することをお勧めします。
別のイメージ（「ノード：6」のようなもの）に基づいて、アプリケーションで既に実動イメージを作成しています。 それでは、それに基づいて目的のイメージを作成する「dev.dockerfile」を作成しないのはなぜですか。
Dockerfile
FROM node:6 # ... production configuration
生産ビルド
$ docker build -t myapp .
dev.dockerfile
FROM myapp # ... development configuration
開発ビルド
$ docker build -t myapp:dev -f dev.dockerfile .
これで、実稼働イメージとまったく同じ構成を使用することがわかっているため、dev.dockerfileを必要に応じて変更できます。
それがどのように行われたかを見たいですか？
DockerでNode.jsアプリを構築するためのガイドの一部であるエピソードの作成、開発コンテナーを確認してください。
神話＃9：このコンテナには何も見えない
コンテナの中をまったく見ることができないからです！
Dockerはアプリケーションの仮想化 （コンテナー化 ）であり、本格的な仮想マシンはありません。
しかし、開発者は多くの場合、コンテナを仮想マシンであるかのように操作する必要があります。
ログ（アプリケーションのコンソール出力に加えて）、デバッグメッセージ、およびすべてのイメージ変更が正しく機能したという一般的な信頼が必要です。
コンテナが仮想マシンではない場合、何が起こっているのかをどのように理解できますか？ ファイル、環境変数、その他の必要なものをどのように表示しますか？
解決策
Dockerコンテナーは本格的な仮想マシンではありませんが、Linuxディストリビューションは内部で機能します。
はい、このディストリビューションは非常にクロップできます（たとえば、Alpine Linuxのように）が、少なくとも最も単純なコマンドシェルにアクセスできるため、コンテナーの内部を見ることができます。
一般に、これを行うには2つの方法があります。
方法番号1：作業コンテナーのシェルに接続する
コンテナーが既に実行されている場合は、コンテナーへのフルアクセスを取得するために、docker execコマンドを実行できます。
$ docker exec -it mycontainer /bin/sh
これにより、通常のLinuxディストリビューションを使用してログインしたときに得られるものと同様に、コンテナーのコンテンツにアクセスできます。
方法番号2：シェルをコンテナーコマンドとして実行する
動作中のコンテナがない場合は、シェルを起動コマンドとして使用して新しいコンテナを起動できます。
$ docker run -it myapp /bin/sh
これで、中身を確認できるコマンドシェルを備えた新しいコンテナができました。
それがどのように機能するかを知りたいですか？
Guide to Learning DockerおよびGuide to Building Node.js Apps in Dockerのエピソードを確認してください。
神話＃8：Dockerコンテナー内にコードを記述する必要がある
そして、私は私のお気に入りのエディターを使用できませんか？！
Node.jsコードが実行されたDockerコンテナを初めて見たとき、その機能に非常に興味を持ち、満足していました。
しかし、イメージを作成した後に変更されたコードをコンテナー内に移動する方法を考え始めたとき、喜びはすぐに消えました。
毎回イメージを再作成する必要がありますか？ ただし、時間がかかりすぎるため、このオプションは表示されなくなります。
たぶん、コンテナのコマンドシェルに接続し、vimでコードを作成する必要がありますか？ 私が必要とする間違ったバージョンを使用する必要があるかもしれません。
それが機能するとしましょう。 そして、IDEまたはより良いエディタが必要な場合はどうなりますか？
コンテナコンソールにしかアクセスできない場合、お気に入りのテキストエディタを使用するにはどうすればよいですか？
解決策
Dockerコンテナでは、「ボリュームマウント」オプションを使用して、ホストシステムからディレクトリをマウントできます。
$ docker run -v /dev/my-app:/var/app myapp
このコマンドを使用すると、「/ var / app」はローカルディレクトリ「/ dev / my-app」を指します。 「/ dev / my-app」でホストシステムに加えられた変更（もちろん、お気に入りのエディターを使用）は、コンテナーにすぐに表示されます。
それがどのように機能するかを知りたいですか？
コンテナエピソードの編集コードを確認してください。これは、DockerでNode.jsアプリを構築するためのガイドの一部です。
神話＃7：コンソールデバッガーを使用する必要がある...
そして私は私のIDEにあるものが欲しい
コンテナ内のコードをすでに編集して、コマンドシェルに接続できます。 デバッグの前に残ったステップは1つだけでした。
コンテナー内でデバッガーを実行する必要がありますか？
もちろん、Dockerコンテナー内では、選択したプログラミング言語にコンソールデバッガーを使用できますが、これが唯一のオプションではありません。
IDEまたはお気に入りのエディターからコンテナーでデバッガーを起動する方法は？
解決策
短い答え：「リモートデバッグ」。
詳細な答えは、言語と作業環境に大きく依存します。
たとえば、Node.jsでは、TCP / IP（ポート5858）を介したリモートデバッグを使用できます。 Dockerコンテナー内でコードデバッグを構成するには、「dev.dockerfile」を使用して作成されたイメージの対応するポートを開く必要があります。
dev.dockerfile
# ... EXPOSE 5858 # ...
これで、コンテナのコマンドシェルに接続してNode.jsデバッグサービスを開始し、お気に入りのデバッガーで使用できるようになりました。
Visual Studioのコンテナー内のNode.jsコードのデバッグを見たいですか？
DockerでNode.jsアプリを構築するためのガイドの一部であるVisual Studio Codeエピソードを使用したコンテナーでのデバッグ をご覧ください 。
神話＃6：毎回docker runを実行する必要がある
「ドッカーラン」のすべてのオプションを思い出せません...
間違いなく、Dockerには膨大な数のコマンドラインオプションがあります。 彼の参考文献をスクロールすることは、消えた文明の神話に関するみすぼらしい巻を読むことに似ています。
コンテナを実行するときが来ると、驚くべきことではありませんが、私はしばしば混乱し、怒りさえします。なぜなら、初めて必要なオプションを選択できないからです。
さらに、「docker run」を起動するたびに、イメージから新しいコンテナインスタンスが作成されます。
これは、新しいコンテナが必要な場合に便利です。
ただし、以前に作成したコンテナを実行する場合、「docker run」の結果はまったく気に入らないでしょう。
解決策
コンテナが必要になるたびに「docker run」を実行する必要はありません。
代わりに、コンテナを停止および開始できます。
これにより、実行間でコンテナの状態も維持されます。 ファイルが変更されている場合、これらの変更は停止および再起動後に保存されます。
それがどのように機能するかを知りたいですか？
WatchMeCodeには、このテクニックを使用したDocker 学習ガイドとDockerでのNode.jsアプリ構築 ガイドの多くのエピソードがあります。
しかし、アイデアが初めての場合は、コンテナの1つのインスタンスの停止と起動について説明する基本的なイメージとコンテナ管理を確認することをお勧めします。
神話番号5：macOSおよびWindows用のDockerが実際に機能しない...
そして、私はMac / Windowsを使用しています
数ヶ月前、これは一般に真実でした。
これまで、MacおよびWindows上のDockerでは、仮想環境とデータを交換するために、docker-machineユーティリティと追加のソフトウェアを備えた本格的な仮想マシンを使用する必要がありました。
これは機能しましたが、非常に大きなパフォーマンスの損失と限られた機能セットがありました。
解決策
幸いなことに、Docker開発者は、ベースOSとしてLinuxだけをサポートする必要性を十分に認識しています。
2016年後半には、MacおよびWindows用の公式Dockerリリースがリリースされました。
これらのプラットフォームにDockerをインストールするのは簡単です。 更新は定期的にリリースされ、機能はLinuxのバージョンレベルにほぼ近いため、MacまたはWindowsのDockerで利用できないオプションが最後に必要であったことを覚えていません。
MacまたはWindowsにDockerをインストールしますか？
WatchMeCodeは、両方のプラットフォーム（およびUbuntu Linux！）で無料のインストールエピソードを提供します。
神話＃4：Dockerはコマンドラインでのみ使用できます。
そして、私はGUIを好む
DockerはLinuxの世界から生まれたものであるため、コマンドラインがその主要なインターフェイスであることは驚くことではありません。
ただし、コマンドやオプションが豊富にあると、思いがけない場合があります。 散発的にコンソールを使用する開発者にとって、これは生産性の低下を引き起こす可能性があります。
解決策
Dockerコミュニティの成長に伴い、GUIユーティリティを含むさまざまなユーザーニーズを満たすツールが増えています。
MacおよびWindows用のDockerは、ローカルマシン上のイメージとコンテナーを管理するためのGUIなど、Kitematicと基本的に統合されています。
Kitematicを使用すると、Dockerリポジトリ内の画像の検索、コンテナーの作成、インストール済みおよび実行中のコンテナーの設定の管理が簡単になります。
Kitematicの動作を確認したいですか？
Guide to Learning DockerのKitematicエピソードをご覧ください。
神話＃3：コンテナにデータベースをデプロイできません。
スケーリングには問題があります...そして、データを失います！
コンテナは本質的には一時的なものです。ためらうことなく破棄し、必要に応じて再作成する必要があります。 ただし、データベースのデータがコンテナ内に保存されている場合、削除するとデータが失われます。
さらに、データベース管理システムには、スケーリングの際に、垂直（より強力なサーバー）および水平（より多くのサーバー）の独自の特性があります。
Dockerは水平スケーリングに特化しているようです。容量を増やす必要がある場合、より多くのコンテナが作成されます。 一方、ほとんどのDBMSでは、スケーリング時に特定の設定が必要です。
はい、それだけです。 Dockerに戦闘基地を配置しないことをお勧めします。
それにもかかわらず、Dockerでの私の最初の成功した経験はデータベースに関連していました。
Oracle、正確には。
開発のニーズにはOracleが必要でしたが、仮想マシンにデプロイできませんでした。 私はこの問題にぴったりと取り組み、約2週間始めましたが、成功に近づきさえしませんでした。
そして、Docker用のOracle XEイメージがあることを知ってから30分後に、作業拠点ができました。
私の開発環境。
解決策
Dockerは戦闘データベースをホストするための最良のソリューションではないかもしれませんが、開発者にとっては驚くべき効果があります。
MongoDB、MySQL、Oracle、Redis、および再起動間で状態を保存する必要のある他のシステムで作業しましたが、すべてが私に適していました。
Dockerコンテナの「一時的な性質」について話す場合、外部ボリュームを接続する可能性を忘れてはなりません。
コード編集のストーリーと同様に、ボリュームを接続すると、ローカルマシンにデータを保存し、コンテナで使用するための便利なツールが提供されます。
これで、いつでもコンテナを作成および削除でき、中断したところから続行することがわかります。
神話その2：プロジェクトでDockerを使用することはできません。
Dockerはすべてかゼロか
Dockerを初めて見たとき、私はDockerを使用してすべてを開発、デバッグ、デプロイ、および「デボピット」する（および200個の追加のツールとフレームワークがすべて自動的に動作する）か、Dockerをまったく使用しないと考えました。
Oracle XEの場合はその逆を証明しました。
一見オールオアナッシングのアプローチを必要とするツールやテクノロジーは、過大評価されません。 非常にまれなケースでは、「すべてまたは何も」が実際に真実であることが判明します。 それでも判明した場合、おそらくそのような製品に投資する価値はありません。
解決策
Dockerは、ほとんどの開発者ツールと同様、徐々に使用を開始できます。
小さく始めます。
コンテナで開発データベースを実行します。
次に、コンテナ内にライブラリを作成し、それがどのように機能するかを調べます。
次に、マイクロサービスを作成しますが、必要なコードは数行のみです。
専門家の小さなチームが既に関与しているより深刻なプロジェクトに進みます。
頭でプールに急ぐ必要はありません。
神話その1：Dockerの恩恵を受けることはできません...実際...
Dockerは「エンタープライズ」であり、「開発者」であるため
これは、Dockerに会った後に克服する必要がある最も深刻な精神的障壁でした。
私の理解では、Dockerは、私がこれまでに遭遇することのないスケーラビリティの問題を解決するために、最先端のチーム向けに設計されたツールでした。
そして、私がそう思ったのはまったく驚くことではありません。
ブログや会議では、「DockerとKubernetesを使用して、このような企業が10,000,000個のマイクロサービスを自動化した」などの騒動がときどきあります。
Dockerは企業や開発者にとって優れたツールになる可能性がありますが、通常の開発者（あなたや私のような）はそれを利用できます。
解決策
Dockerをお試しください。
繰り返しますが、小さく始めます。
12 GBのRAMを持つ1つの仮想マシンを起動しました。これは、クライアントの1つに対して3つのWebプロジェクトをホストします。 今日の標準では、これは非常に控えめなサーバーです。 しかし、このサーバーをより効率的に使用する方法として、Docker（純粋なDockerそのもの）を検討します。
私は5人の開発者が部分的に働いている2人目のクライアントを持っています（これらはすべて週40時間動作しません）。 この小さなチームは、Dockerを使用してビルドおよび展開プロセスを自動化します。
現在、私のオープンソースライブラリのほとんどは、Dockerの下のNode.jsで記述されています。
毎日、Dockerを使用して、ラップトップにインストールされているソフトウェアを管理するための新しい、より便利な方法を見つけています。
覚えておいてください：
誇大広告に注意を払わず、神話を信じない
Docker神話は、正当な理由で生まれました。 しかし、それは開発者には役立ちません。
この記事を読んでもまだ疑問がある場合は、Dockerに対する態度を再検討してみてください。
開発者がDockerを効果的に使用する方法について質問がある場合は、 私に連絡してください 。 喜んでお手伝いさせていただきます。
Dockerの基本とそれを使用してアプリケーションを開発する方法を学びたい場合は、WatchMeCodeのDocker 学習ガイド （最初から）およびDockerでのNode.jsアプリ構築ガイドをご覧ください。
元のテキストは次の場所にあります：derickbailey.com/2017/01/30/10-myths-about-docker-that-stop-developers-cold/（ アクティブなリンクが存在しないのは、元のテキストの作成者がすべての訪問者をサードパーティのリソースにリダイレクトするためです。他のサイトのアクティブなリンクからアクセスできます ）。