JavaをUnixバイナリに近い他の言語と比較して使用する場合、Dockerを使用する開発上の利点は無効になりますか？
私は言った友人がいました：
Docker は素晴らしいです。これを使用して、ローカルマシンで 複製プロダクション およびそのすべての癖を行うことができます。次に、そのインスタンスをすべてのステージングワークフローsuper - quick を介して直接デプロイできます。
これは、開発者がRubyを記述している場合に当てはまります。PHPまたは Go -オペレーティングシステムへの方向バイナリリンクがあった場合。
ただし、 Java を使用する場合、オペレーティングシステムと言語の間に既に virtual レイヤーがあり、基盤となるオペレーティングシステムに関係なく、操作の一貫性を保ちます。
間違いなく、この場合、開発者がローカルでDockerを実行して本番環境を複製する利点は negated です。 （Rubyと比較して、PHPまたはGo）。
私はこれについて議論する用意があり、反対の見解を（証拠とともに）聞くことを切望しています。
JavaをUnixバイナリに近い他の言語と比較して使用すると、Dockerを使用する開発上の利点は無効になりますか？
どういたしまして。
Javaのバージョン1.8.0を開発マシンとサーバーの両方で実行しているとします。ちなみに、Javaを使用する2つのプロジェクトで同時に作業しています。
ある日、JVMにバグが見つかり、作業中の最初のプロジェクトを実行するサーバーが1.8.1に移行されます。ちなみに、2番目のプロジェクトを実行しているサーバーはバグの影響を受けず、システム管理者の別のチームによって管理されており、1.8.1に更新するつもりがない可能性があります。
これで、少なくとも1つのプロジェクトで、別のバージョンのJavaを実行しています。
これはそれほど気になりません（一方のサーバーが1.9に移行し、もう一方のサーバーが古いバージョンを維持するまで）。しかし、これはローカルマシンで本番環境を複製していないことを意味します。忍び寄るバグ。
ファイルシステム、依存関係、セキュリティ設定、ローカル構成、およびLinuxのバージョン自体が本番環境と異なると想像すると、本番環境で失敗するコードを作成する危険にさらされています。このリスクを負う代わりに、仮想化またはDockerを使用して、生産性をほとんどまたはまったく失うことはありません。
「Javaアプリ」をデプロイすることはほとんどありません。 Javaアプリケーションには、さまざまなサポートプログラムが数多くあります。メッセージングにはApache HTTPD、Apache Tomcat、ActiveMQ、FTPデーモン、MySQL、およびいくつかのカスタムサービスを使用して、 Javaを直接操作しないでください。
これは、Eclipse、Ant、Adobe Flex、Groovy、Firefox、Subversionなどの開発ソフトウェアにも含まれていません（かなりの数をスキップしています）。
新しいワークステーションをセットアップするには、丸1日から1週間かかります。この問題を簡単にするために、Dockerへの移行について説明しました。数時間で新しいワークステーションを確実に展開できたら素晴らしいと思います。
展開するときに、20以上のサーバーを維持する必要があることは言うまでもありません。 Dockerはかなり良いように見え始めています！
（20は、一度に1つのサーバーでのみ実行されるアプリではかなり痛いようです...しかし、その1つのサーバーにクラスター（x2）、テスト/ステージング/製品（x3）、内部/外部（x2）、およびプライマリサイトを掛けます/ backupサイト（x2）を使用すると、すぐにアクセスできます）
この質問は、PythonまたはC++では通常、人々を導くリンクされたライブラリが多数あるのとは対照的に、静的にリンクされたバイナリを抽出してどこかで実行できるgolangにも当てはまります。開発環境からドッカーコンテナーを構築するだけです。
ここで回答するポイントは2つあります。
1つありますより良い方法である必要があります、そしてあります：インストール環境だけを使用して、より小さく（より効率的な）Dockerコンテナーを構築できます。これにより、Golangの場合と同様の利点が得られます。 with-environmentコンテナとGolang-just-binariesコンテナ。 Javaの場合、すべてのライブラリjarとシェルスクリプトを含むファットjarまたはインストール可能なアプリを構築できます。 Pythonの場合、auditwheelを使用して、ビルド環境に依存しない自己完結型のホイールを構築できます（静的リンクを使用してC++を使用すると、ほぼ同じ効果が得られます）。
2つ：何のためにdockerが必要ですか？ Java土地では、クラスローダーを使用してさまざまなコンポーネントを大幅に分離できますが、要点はJavaアプリケーションです。いいえJavaアプリケーションは単独で実行されます-dockerで実行されない場合、通常、supervisordまたはsystemdによって監視される必要があります。コンテナの抽象化を使用してホスト自体を仮想化するのではなく、実際にネットワーク全体を仮想化して、コンテナをデプロイしてランダムなホストで実行できるようにする、Kubernetes、Marathon、またはDockerクラウドを入力します。
マイクロサービスは通常、Dockerベースのクラウドで実行されます。これは、Dockerホストをペットではなく牛として、また同様にdockerizedアプリケーションで扱うことができるためです。もちろん、この抽象化は、ホストボリュームをdockerにマウントし、これらのボリュームを持つホストで正確にdockerコンテナーを実行する必要があるとすぐに漏洩します。一部の人々はそれを回避します。
これは本当に良い質問ですが、Dockerを使用した後、私はそれを好転させます。
コンテナー化（Dockerなど）により、JVMのメリットは無効になりますか？
コンテナは、私の経験から得られた、開発に関して私が持っている多くの仮定に本当に挑戦しています。たとえば、誰かがアプリケーションのリソースファイルへのパスをハードコーディングした場合、多くの経験豊富な開発者は、これが問題であることを知っているので、構成可能にする必要があります。しかし、コンテナをターゲットにしている場合、これは本当にそうなのでしょうか？コンテナを構築するときは、ディレクトリ構造が何であるかをコンテナに伝えます。そこでパスを設定しています。それで、2回構成する必要がありますか？メリットは何ですか？それらを一致させないと、うまくいきません...乾燥？
私は最近、JavaおよびDockerを使用してプロトタイプアプリケーションを作成しました。これは基本的にGCイベントを監視し、ヒープの古い部分がしきい値のパーセンテージに達すると、シャットダウンします。Docker（スウォームモード）はその後、新しいものを起動します。基本的に、JVMでの主要なGCサイクルの必要性を排除し、Dockerにそれらを管理させました。期待どおりに機能しませんでした（クライアントがシャットダウンの影響を確認しました）。群衆にライブデモを行うのに十分機能的でした。
興味があれば、実際にコンテナを試してみてください。それは本当に破壊的な技術であり、あなたはそれを理解する必要があるでしょう。 Dockerは開始するのに最適な場所ですが、他のすべての人に適した実行可能な代替手段が少なくとも1つあります（IMO）。