Há benefícios em executar meu ambiente de desenvolvimento em um contêiner Docker?

Eu desenvolvo principalmente usando o Visual Studio no Windows. O problema é que, depois de um tempo, o Windows fica atolado e eu tenho que reinstalar o Windows. Da mesma forma, mudar para novas máquinas é um problema.

Reinstalar o Windows é doloroso porque meu ambiente de desenvolvimento possui muitas dependências (como arquivos de configuração extras do MSBuild, extensões VS, npm, Java etc.). Não imagino que esteja sozinho em ter um sistema complexo, e configurá-lo novamente provavelmente levaria um dia no mínimo.

Eu realmente não usei o Docker, mas em teoria parece que eu poderia configurar meu ambiente de desenvolvimento em um contêiner do Windows e depois enviá-lo (por exemplo, copiar para o meu laptop, instalar uma nova instalação do Windows) e deve ser indolor .

O que estou descrevendo é possível? Existem desvantagens, como desempenho, confiabilidade? Outras dicas?

Este não é um problema incomum, mas o Docker não é realmente a ferramenta certa para resolvê-lo. Os contêineres em geral (incluindo o Docker) destinam-se a fornecer um tempo de execução do aplicativo para um único processo , como um servidor Web, não para um cenário de vários processos, como um ambiente de desenvolvimento. Em pode ser feito, mas não é uma solução muito elegante.

Uma abordagem melhor (e mais comum) é criar VMs por meio de um hipervisor tradicional como o VirtualBox ou o Hyper-V (já que você está no Windows). Um fluxo de trabalho típico é:

• Encontre ou crie uma imagem de VM básica com base no seu sabor preferido do SO. Isso pode ser feito diretamente com o ISO do instalador, ou alguém no seu local de trabalho já pode ter um.
• Depois que a imagem base for criada, adicione todas as ferramentas e configurações de desenvolvimento necessárias. Instantâneo ou salve-o como uma imagem separada.
• Agora você pode executar esta imagem, RDP ou remota nela, e trabalhar até chegar a um ponto em que você "fica atolado" e depois salva os arquivos que precisa (comprometa-se com o controle de origem etc.) afaste a imagem e comece novamente a partir de um dos dois instantâneos / imagens que você criou. Isso pode ser feito em segundos, versus até um dia à moda antiga.
• A qualquer momento, crie capturas instantâneas adicionais quando encontrar situações nas quais você poderá reverter para reproduzir um problema etc.

O Vagrant também é uma ferramenta fantástica para executar grande parte do exposto de maneira mais estruturada.

Um benefício colateral de tudo isso é que agora você tem ambientes padronizados que podem ser compartilhados com toda a equipe, economizando o esforço de todos. Isso é especialmente excelente para a rápida entrada de pessoas novas.

De volta à sua pergunta original, o Docker não se destina realmente a isso, mas se você tivesse um ambiente de desenvolvimento pequeno o suficiente (por exemplo, PHP no Linux), poderia fazê-lo em um contêiner, e o benefício seria uma imagem muito menor (potencialmente menos de 100 MB vs muitos GB para uma VM do Windows com disco virtual).

não em um contêiner de docker, mas sim em n contêineres de docker.

Embora você possa, teoricamente, montar todo o seu ambiente de desenvolvimento em um único contêiner, o docker não foi feito para isso.

Em vez disso, você deve implantar cada serviço em contêineres separados, usando a janela de encaixe , gerenciando toda a infraestrutura em um único arquivo, onde cada serviço terá seu próprio arquivo de log, espaço de usuário, rede, etc.

Deixe-me dar um exemplo, este é um rascunho do meu 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

Há um proxy nginx (myproxy), dois bancos de dados postgres semelhantes (mydb1 e 2), um antigo servidor de aplicativos web java (www), um contêiner java jetty que fornece um serviço da web restante e, finalmente, um contêiner postfix SMTP muito simples.

Tudo começa - geralmente :) - com docker-compose up, na minha máquina de desenvolvimento ou na produção; os arquivos de log são agregados em um arquivo fácil de ler e é possível replicar localmente quase todas as funcionalidades com a garantia de que, se funcionar no meu laptop, funcionará.

Eu uso VMs do VirtualBox para esse tipo de coisa.

A portabilidade de ter seu ambiente de desenvolvimento em um contêiner é útil, mas o mais legal é que eu posso capturar uma imagem antes de qualquer tentativa de atualização e, se eu estragar tudo, não há problema em voltar atrás e começar de novo.

Também acho útil fazer isso porque frequentemente trabalho com várias versões de coisas como Qt, e não sinto vontade de descobrir como coexistir as duas versões - em vez disso, apenas as coloco em VMs diferentes e Não preciso me preocupar com interações porque instalei algo incorretamente.