Чи є користь для мого середовища розробки в контейнері Docker?

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

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

Я не дуже використовував Docker, але теоретично це здається, що я міг налаштувати своє середовище розробників у контейнер Windows, а потім просто переслати його (наприклад, скопіювати на свій ноутбук, поставити в нову інсталяцію Windows), і це повинно бути безболісно. .

Чи можливо те, що я описую? Чи є якісь недоліки, такі як продуктивність, надійність? Інші готчі?

Це не рідкість, але Docker насправді не є правильним інструментом для її вирішення. В основному контейнери (включаючи Docker) призначені для забезпечення виконання програми для одного процесу , наприклад веб-сервера, а не для багатопроцесорного сценарію, такого як середовище розробника. Це можна зробити, але це не дуже елегантне рішення.

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

• Знайдіть або створіть базовий VM-образ на основі бажаного смаку ОС. Це можна зробити безпосередньо з інсталятором ISO, або хтось у вас на робочому місці може вже мати такий.
• Після того, як базове зображення буде побудовано, додайте всі необхідні інструменти розробника та налаштування. Зніміть або збережіть це як окреме зображення.
• Тепер ви можете запустити це зображення, RDP або віддалений в нього та працювати, поки не дістанетесь до точки, коли ви "завалиться", а потім просто збережіть потрібні файли (зобов’язатись керувати джерелом тощо), а потім збити відімкніть зображення та почніть знову з будь-якого із двох створених знімків / зображень. Це можна зробити за лічені секунди, порівняно до дня старомодним способом.
• У будь-якій точці лінії створюйте додаткові знімки, коли ви стикаєтесь із ситуаціями, до яких, можливо, ви захочете відкати, щоб відтворити проблему тощо.

Vagrant - це також фантастичний інструмент для того, щоб робити більшу частину вищезазначеного більш структуровано.

Побічною перевагою всього цього є те, що тепер у вас є стандартизовані умови, якими можна ділитися з усією командою, економлячи всі зусилля. Це особливо чудово для швидких посадки нових людей.

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

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

Хоча ви могли - теоретично - зібрати все своє середовище розробників всередині одного контейнера, докер не мав цього робити.

Натомість вам слід розгорнути кожну службу в окремі контейнери, використовуючи 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мого автомата або у виробництві; Файли журналу об'єднуються в один простий для читання файл, і можна реплікувати локально майже кожен функціонал з гарантією, що, якщо він працює на моєму ноутбуці, він буде працювати.

Я використовую віртуальні віртуальні віртуальні машини для подібних речей.

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

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