一般に、開発者はビジネス要件を満たすことに関心があります。彼/彼女は特定のスタックまたはフレームワークの専門知識を持っているかもしれません。しかし、彼/彼女はdockerとそれがさまざまな配備方法（swarm、kube、mesosなど）を学ぶように努力すべきでしょうか？
簡単に言えば、開発者がdockerを気にする必要があるのはなぜですか？
PS：この投稿の親の質問は、開発チームにdockerを導入することの影響です
一般に、開発者はビジネス要件を満たすことに関心があります。彼/彼女は特定のスタックまたはフレームワークの専門知識を持っているかもしれません。しかし、彼/彼女はdockerとそれがさまざまな配備方法（swarm、kube、mesosなど）を学ぶように努力すべきでしょうか？
簡単に言えば、開発者がdockerを気にする必要があるのはなぜですか？
PS：この投稿の親の質問は、開発チームにdockerを導入することの影響です
回答:
おそらくあなたが探している答えではありませんが、それでも答えは:)
Dockerとその展開方法について学ぶことは、コード言語、バージョン管理システム、コンパイラ、テストインフラストラクチャなどと同様に、プロジェクトまたはチーム開発環境の一部にすることで、実際にビジネス要件に含めることができ、そのチームまたはそのプロジェクトでは、これらのすべてについて知って使用する必要があるため、（ほとんどの場合）「自分で作成」することはできません。
「開発者」が実際に開発チームの過半数または全体を意味する場合、状況は少し複雑になります。実際にツールをサポートする開発者がいない状態でツールを開発環境にプッシュすることは、本当に難しいでしょう。時間をかけて、まずチームの技術的リーダーシップからそのようなサポーターを1人作成します。
補足：チームのすべての開発者がDockerエキスパートになる必要はありません。簡単なチートシート対応コマンドにラップされた事前に確立された使用法のレシピにより、開発者は多くの場合、特に大規模なチームでは、内部の仕組みについてあまり知らなくても、Dockerベースのソリューションを使用できます。最終製品の構築方法に関する詳細をすべて知らなくてもコードを提供できるように。
私の視点をお伝えします。他の開発者がdockerを使用する意思があり、すでに専門家を構築しているため、開発者はdockerに注意する必要があります。彼らは、開発者としてDevOpsエンジニアの役割を喜んで引き受けます。したがって、DevOpsのOps部分は、現在専門家が構築しているものです。
最近では、この完全なパッケージを単独で監視して本番環境に導入するために、テストの開発、オーケストレーション、自動化、ジョブの自動化、ツールの構築を行える人がますます増えています。これらは、開発者コミュニティの間でdockerやその他のツールを推進している人たちです。
また、市場の流れは、仮想化、自動スケーリング、自動化、機械学習、Dockerのこれらすべてへの適合に向かっています。Dockerを使用することが非常に必須になりました。企業は、これらすべての責任を負う1人の男に2倍の費用を支払う用意があります。そのような男の需要があると、供給も開始されます。これは従業員と雇用者の観点からです。
技術的には、私が働いた組織では、開発チームとDevOpsチームが別々にいますが、彼らはデリバリーに非常に密接に協力しています。DevOpsのエンジニアと開発者は、ここでスキルセットの大部分を共有しているため、職務の交渉が時折行われます。
開発者ができる最低限のことは、自分のバイナリを共有することですが、Dockerコンテナー内で実行するためにバイナリが使用されることと、Dockerの動作を理解する必要があることを理解する必要があります。kubes、swarms、mesosなどの場合、開発者は何が使用されているかを気にすることさえないかもしれませんが、Dockerの基本は開発者に非常によく理解されているはずです。マイクロサービス。アプリケーションがその考え方（Dockerの基本を必要とする）から構築されている場合、DevOpsエンジニアはそれをそこから取り上げ、自動スケーリング、オーケストレーション、テスト、デプロイ、監視を行うことができます。
また、ほとんどの場合、1つのサイズですべての種類のものが収まることはありません。開発者はDockerフレンドリーなアプリの構築方法を明確に知らず、DevOpsエンジニアはアプリ構築プロセスの内部をまったく正しく知りません。したがって、ほとんどの場合、組織はこれらの両方のタスクを同じ人に与えてスピードアップします。個別のものがある場合、アプリをより未来的でdocker / cloud / scalingに対応させるために、DevOpsチームから開発チームへの継続的なフィードバックメカニズムが必要です。
Dockerやその他のコンテナー化テクノロジーについてではありません。
Docker、rktなどのコンテナーは、静的バイナリーと同様の方法でアプリケーションを配信するための単なる方法です。内部に必要なすべてが含まれ、エンドユーザーがランタイム以外何も必要としない配置を構築しています。
これらのソリューションはJavaのファットJARに似ており、（理論的には）必要なものはすべてランタイム（JRE）がプリインストールされ、すべてがJust Works™です。
開発者が理解する必要がある理由（そのようなツールの操作方法を学ぶ必要はなく、なぜこれが必要なのかを理解するだけです）オーケストレーションツールを使用すると、「従来の」デプロイメントに比べていくつかの利点が得られます。
EngineYardはそれについて良い記事を書いています。つまり、サーバーが停止した場合は、肩をすくめて新しいものが表示されるのを待ちます。あなたはそれらを牛として扱い、何十、何百、何千ものそれらを走らせており、人が落ちたとき、あなたもあなたのクライアントもそのことに気付くべきではありません。
オーケストレーションツールは、クラスター内のすべてのアプリケーション（ポッド/ジョブなど）のステータスを監視することでそれを実現し、サーバーの1つが応答を停止（停止）すると、そのサーバーで実行されていたすべてのアプリケーションを別の場所に自動的に移動します。
オーケストレーションのおかげで、1つのサーバーで複数のアプリケーションを実行でき、オーケストレーターがリソースを追跡します。必要に応じてアプリケーションを再配置します。
オーケストレーターの自動フェイルオーバー処理のおかげで、カスタムイメージをそのままクラウドで実行できます。更新が必要な場合は、新しいイメージをビルドし、起動構成を設定して、そのイメージをすぐに使用してロールするだけです。すべてがあなたのために処理されます：
TL; DR要点はDockerではなく、オーケストレーションです。Dockerは、適切なオーケストレーションに必要なtarball / fat JARの拡張バージョンです。
たとえば、2014年に発行され、回答に完全に一致するようにタイトルが付けられたブログ投稿のいくつかの引数を次に示します。
- 環境への新しいテクノロジーのはるかに柔軟な導入
- テストされた最終的なコードをコミットしてから、最終的な本番サーバーで実行するまでには、依然として大きな問題があります。Dockerはこの最後のステップを大幅に簡素化します
- Dockerは、実行しているLinuxの種類に関係なく、レガシーOSを維持することを簡単にします
送信元：https : //thenewstack.io/why-you-should-care-about-docker/
Dockerコンテナーでプロダクションを実行している場合、それらのコンテナーは、アプリを実行している同じ開発者によって作成されていることが重要です。他に誰がどの外部依存関係が必要であるかなどを知るのにより良い場所です...？
また、CDのどの段階でもパイプラインが失敗する可能性があります。特に、Dockerイメージのビルド手順の場合は、ファイルが見つからないか、必要なライブラリである場合があります。
仕事では、すべての開発者をdockerに紹介し、アプリを提供するためにdockerfileを構築するための基本を説明しました。また、パイプラインを簡単にして、名前とdockerfileを追加するだけで、アプリが自動的にビルドされるようにしましたそれを実行している技術に関係なく、次のプッシュ。
Dockerクイックスタートは、devOpsチームが開発者にディストリビューションの選択を指導した後（その多くはのようなことを知らないalpine）、実際にそうするための素晴らしい導入です。
私たちの仕事は、ツールに簡単にアクセスできるようにすることです。残りの作業は、何か問題が発生したときに修正できるようにするためです。Dockerは実際には開発プロセスの一部であり、devOpsチームは私たちのニーズに一致する十分に簡単なDockerイメージを提供しているため、新しいアプリを作成して支援なしでデプロイするのに数分しかかかりません。
まあ、テストにVMを使用したことがある場合は、コンテナとdockerを使用してみてください。実際には、テストに最適であり、LXCの代わりに使用する方がはるかに簡単です。