Есть ли преимущества для моей среды разработки в контейнере Docker?

Я разрабатываю в основном с помощью Visual Studio на Windows. Проблема в том, что через некоторое время Windows зависает, и мне приходится переустанавливать Windows. Аналогичным образом, переход на новые машины является проблемой.

Переустановка Windows болезненна, потому что моя среда разработки имеет много зависимостей (таких как дополнительные файлы конфигурации MSBuild, расширения VS, npm, Java и т. Д.). Я не думаю, что я одинок в том, чтобы иметь сложную систему, и ее восстановление, вероятно, заняло бы минимум дня.

Я на самом деле не использовал Docker, но теоретически это звучит так, как будто я могу настроить свою среду разработки в контейнере Windows, а затем просто отправить ее (например, скопировать на свой ноутбук, вставить новую установку Windows), и это должно быть безболезненно ,

Возможно ли то, что я описываю? Есть ли недостатки, такие как производительность, надежность? Другие ошибки?

Это не редкая проблема, но Docker на самом деле не самый подходящий инструмент для ее решения. Контейнеры в целом (включая Docker) предназначены для обеспечения времени выполнения приложения для одного процесса , такого как веб-сервер, а не для многопроцессного сценария, такого как среда разработки. В может быть сделано, но это не очень элегантное решение.

Лучшим (и более распространенным) подходом является создание виртуальных машин с помощью традиционного гипервизора, такого как VirtualBox или Hyper-V (поскольку вы работаете в Windows). Типичный рабочий процесс:

• Найдите или создайте базовый образ виртуальной машины на основе предпочтительного варианта ОС. Это можно сделать непосредственно с помощью установщика ISO, или кто-то на вашем рабочем месте может уже иметь его.
• Как только базовый образ будет создан, добавьте все необходимые инструменты и настройки для разработчиков. Снимок или сохранить это как отдельное изображение.
• Теперь вы можете запустить этот образ, RDP или удаленный в нем, и работать до тех пор, пока не доберетесь до точки, где вы «застряли», а затем просто сохраните нужные вам файлы (фиксация с контролем исходного кода и т. Д.), А затем нажмите удалите изображение и начните снова с любого из двух снимков / изображений, которые вы создали. Это можно сделать за считанные секунды, по сравнению со старым способом.
• В любой точке линии создавайте дополнительные снимки, когда вы сталкиваетесь с ситуациями, к которым вы можете откатиться, чтобы воспроизвести проблему и т. Д.

Vagrant также является фантастическим инструментом для выполнения большей части вышеперечисленного в более структурированной форме.

Дополнительным преимуществом всего этого является то, что теперь у вас есть стандартизированные среды, которыми вы можете поделиться со всей вашей командой, что экономит усилия каждого. Это особенно хорошо для быстрого освоения новых людей.

Возвращаясь к исходному вопросу, Docker на самом деле не предназначен для этого, но если бы у вас была достаточно маленькая среда разработки (скажем, PHP на Linux), вы могли бы сделать это в контейнере, и выгода была бы в гораздо меньшем размере изображения (потенциально до 100 МБ против многих ГБ для виртуальной машины Windows с виртуальным диском).

не в одном docker-контейнере, а yes в n-док-контейнерах.

Хотя теоретически вы можете собрать всю свою среду разработки в одном контейнере, 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), две аналогичные базы данных postgres (mydb1 и 2), старый сервер веб-приложений java (www), контейнер java jetty, который предоставляет веб-службу отдыха, и, наконец, очень простой контейнер SMTP-постфикса.

Все запускается - обычно :) - с docker-compose up, либо на моей машине разработчика или в производстве; файлы журналов объединяются в один легко читаемый файл, и можно локально реплицировать почти все функции с гарантией того, что, если он будет работать на моем ноутбуке, он будет работать.

Я использую виртуальные машины VirtualBox для такого рода вещей.

Переносимость создания вашей среды разработки в контейнере удобна, но по-настоящему приятно то, что я могу сделать снимок перед любыми попытками обновления, и, если я его испорчу, нет проблем вернуться к началу и начать заново.

Я также считаю это полезным, потому что я часто работаю с несколькими версиями таких вещей, как Qt, и мне не хочется выяснять, как заставить две версии сосуществовать - вместо этого я просто помещаю их на разные виртуальные машины и Мне не нужно беспокоиться о взаимодействии, потому что я установил что-то неправильно.