web-dev-qa-db-ja.com

Dockerコンテナーで開発環境を実行することにはメリットがありますか？

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

開発環境には多くの依存関係（追加のMSBuild構成ファイル、VS拡張機能、npm、Javaなど）など）があるため、Windowsの再インストールは苦痛です。私が一人でいるとは想像していません複雑なシステムであり、バックアップを設定するには、おそらく1日程度かかります。

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

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

docker
12
Jim W says reinstate Monica

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

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

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

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

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

元の質問に戻りますが、Dockerは実際にはこれを目的としていませんが、十分に小さな開発環境（PHPなど））がある場合は、コンテナで実行できます。メリットは、イメージがはるかに小さいことです（Windowsの場合、100 MB未満に対して多くのGBになる可能性がありますVM））。

13
Dan1701

私はこの種のもののためにVirtualBox VMを使用します。

開発環境をコンテナに移植することの移植性は便利ですが、本当に素晴らしいのは、アップグレードを試みる前にスナップショットを作成できることです。失敗した場合、フォールバックして再起動しても問題ありません。

Qtのような複数のバージョンを頻繁に使用していて、2つのバージョンを共存させる方法を理解したくないので、これを行うことも役立ちます。代わりに、それらを異なるVMに置くだけで、何かを間違ってインストールしたので、対話について心配する必要はありません。

2
Michael Kohne

1つのDockerコンテナーではなく、n個のDockerコンテナーであり

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

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

例を挙げましょう。これは私の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）、a Java jetty残りのWebサービスを提供するコンテナ、そして最後に非常にシンプルなSMTP postfixコンテナ。

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

2
Edoardo