開発環境をDockerコンテナで実行する利点はありますか？

主にWindows上のVisual Studioを使用して開発しています。問題は、しばらくするとWindowsが行き詰まり、Windowsを再インストールする必要に直面することです。同様に、新しいマシンへの切り替えも問題です。

開発環境には多くの依存関係（追加のMSBuild構成ファイル、VS拡張、npm、Javaなど）があるため、Windowsの再インストールは苦痛です。複雑なシステムを持っているのは私一人ではないと思いますが、それを元に戻すにはおそらく1日はかかります。

私は実際にはDockerを使用していませんが、理論的にはWindowsコンテナで開発環境をセットアップし、それを出荷するだけです（たとえば、ラップトップにコピーして新しいWindowsインストールを入れてください） 。

私が説明していることは可能ですか？パフォーマンス、信頼性などの欠点はありますか？他の落とし穴？

これは珍しい問題ではありませんが、Dockerは実際にそれを解決するための適切なツールではありません。一般的なコンテナ（Dockerを含む）は、開発環境などのマルチプロセスシナリオではなく、Webサーバーなどの単一プロセスにアプリケーションランタイムを提供することを目的としています。でき行われますが、非常にエレガントな解決策ではないこと。

より良い（そしてより一般的な）アプローチは、VirtualBoxやHyper-V（Windowsを使用しているため）などの従来のハイパーバイザーを介してVMを作成することです。典型的なワークフローは次のとおりです。

• 好みのOSフレーバーに基づいてベースVMイメージを検索または作成します。これは、インストーラーISOを使用して直接行うことができます。または、職場の誰かが既に持っている場合もあります。
• 基本イメージが構築されたら、必要なすべての開発ツールと設定を追加します。スナップショットを作成するか、これを別の画像として保存します。
• これで、このイメージ、RDP、またはリモートを実行し、「行き詰まった」状態になるまで作業し、必要なファイルを保存して（ソース管理などにコミット）、ブローすることができます。イメージを削除し、作成した2つのスナップショット/イメージのいずれかから再度開始します。これは数秒で実行できますが、従来の方法では最大1日です。
• 問題の再現などのためにロールバックしたい状況が発生した場合、ラインに沿った任意の時点で追加のスナップショットを作成します。

Vagrantは、上記の多くをより構造化された方法で実行するための素晴らしいツールでもあります。

このすべての副次的な利点は、チーム全体で共有できる標準化された環境が得られ、全員の労力が節約されることです。これは、特に新しい人をすばやくオンボーディングするのに最適です。

元の質問に戻りますが、Dockerは実際にはこれを目的としていませんが、開発環境（Linux上のPHPなど）が十分に小さければ、コンテナー内で行うことができ、メリットははるかに小さいイメージ（潜在的に仮想ディスクを備えたWindows VMの場合は100 MBに対して多くのGB）。

1つのDockerコンテナではなく、n個のdockerコンテナにあります。

理論的には、開発環境全体を1つのコンテナー内にアセンブルできますが、dockerはこれを行うことを意図していませんでした。

代わりに、docker composeを使用して各サービスを個別のコンテナーにデプロイし、インフラストラクチャ全体を単一のファイルで管理します。各サービスには、独自のログファイル、ユーザースペース、ネットワークなどがあります。

例を挙げましょう、これは私のドラフトです docker-compose.yml

version: '2'
services:

  myproxy:
    build: myproxy
    container_name: ppproxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
    networks:
      default:
        aliases:
          - www.domain1.it
          - www.domain2.it
          - www.domain4.it

  mydb1:
    build: mydb
    environment:
      DB_USER: sdffdssdf
      DB_PASSWORD:  fdsfsdsdf
      DB_NAME: dbanme1
      DB_ENCODING: UTF-8    
      VIRTUAL_HOST: myhost1.net.lan
      VIRTUAL_PORT: 5432

  mydb2:
    build: mydb
    environment:
      DB_USER: ssdfsdfs
      DB_PASSWORD:  sffdssd
      DB_NAME: dbanme2
      DB_ENCODING: UTF-8    
      VIRTUAL_HOST: myhost2.net.lan
      VIRTUAL_PORT: 5432

  www:
    image: myimages/oldservice:v1.1
    container_name: www
    command: /bin/bash /root/launch
    environment:
        VIRTUAL_HOST: www.domain1.it
        VIRTUAL_PORT: 80
    ports:
      - 80
    depends_on:
      - mydb1
      - mydb1
      - myws

  myws:
    build: myjettycontainer
    environment:
        HTTPS_METHOD: noredirect
        VIRTUAL_HOST: www.domain2.it
        VIRTUAL_PORT: 8080
    ports:
      - 8080
    depends_on:
      - mydb1
      - mydb2
      - myproxy
      - mypostfix

  mypostfix:
    image: catatnight/postfix
    container_name: mailer
    environment:
      maildomain: domain1.it
      smtp_user: mymail:sfsfdfds
    ports:
      - 25

nginxプロキシ（myproxy）、2つの同様のpostgresデータベース（mydb1および2）、古いjava webアプリケーションサーバー（www）、残りのwebサービスを提供するjava jettyコンテナー、最後に非常に単純なSMTP postfixコンテナーがあります。

すべてが起動します-通常:)-でdocker-compose up、私の開発マシン上または本番環境で; ログファイルは読みやすい1つのファイルに集約され、ラップトップで動作する場合に動作することを保証して、ほぼすべての機能をローカルに複製することができます。

この種のことにはVirtualBox VMを使用します。

開発環境をコンテナに入れることの移植性は便利ですが、本当に良いことは、アップグレードを試みる前にそのスナップショットを撮ることができることです。

また、Qtなどの複数のバージョンを頻繁に使用しているため、これを行うと便利です。2つのバージョンを共存させる方法を考えたくないので、代わりに異なるVMに配置し、何かを誤ってインストールしたため、相互作用について心配する必要はありません。