¿Existen beneficios al ejecutar mi entorno de desarrollo en un contenedor Docker?

Desarrollo principalmente usando Visual Studio en Windows. El problema es que después de un tiempo, Windows se atasca y me enfrento a la necesidad de reinstalar Windows. Del mismo modo, cambiar a máquinas nuevas es un problema.

Reinstalar Windows es doloroso porque mi entorno de desarrollo tiene muchas dependencias (como archivos de configuración MSBuild adicionales, extensiones VS, npm, Java, etc.). No me imagino que estoy solo en tener un sistema complejo, y configurarlo de nuevo probablemente tomaría un día mínimo.

Realmente no he usado Docker, pero en teoría parece que podría configurar mi entorno de desarrollo en un Contenedor de Windows y luego simplemente enviarlo (por ejemplo, copiarlo a mi computadora portátil, instalar una nueva instalación de Windows) y debería ser sencillo. .

¿Es posible lo que estoy describiendo? ¿Hay alguna desventaja, como el rendimiento, la fiabilidad? Otras trampas?

Este no es un problema poco común, pero Docker no es realmente la herramienta adecuada para resolverlo. Los contenedores en general (incluido Docker) están destinados a proporcionar un tiempo de ejecución de la aplicación para un solo proceso , como un servidor web, no para un escenario multiproceso como un entorno de desarrollo. En puede hacerse, pero no es una solución muy elegante.

Un enfoque mejor (y más común) es crear máquinas virtuales a través de un hipervisor tradicional como VirtualBox o Hyper-V (ya que está en Windows). Un flujo de trabajo típico es:

• Encuentre o cree una imagen VM base basada en su sabor de sistema operativo preferido. Esto se puede hacer directamente con el instalador ISO, o alguien en su lugar de trabajo ya puede tener uno.
• Una vez que se construye la imagen base, agregue todas las herramientas y configuraciones de desarrollo que necesite. Capture o guarde esto como una imagen separada.
• Ahora puede ejecutar esta imagen, RDP o control remoto en ella, y trabajar hasta llegar a un punto en el que se "atasque", y luego simplemente guarde los archivos que necesita (comprométase con el control de código fuente, etc.), luego sople aleje la imagen y comience nuevamente desde cualquiera de las dos instantáneas / imágenes que creó. Esto se puede hacer en segundos, en comparación con hasta un día a la antigua usanza.
• En cualquier punto a lo largo de la línea, cree instantáneas adicionales cuando encuentre situaciones en las que desee retroceder para reproducir un problema, etc.

Vagrant también es una herramienta fantástica para hacer mucho de lo anterior de una manera más estructurada.

Un beneficio adicional de todo esto es que ahora tiene entornos estandarizados que se pueden compartir con todo su equipo, ahorrando a todos el esfuerzo. Esto es especialmente bueno para incorporar rápidamente nuevas personas.

Volviendo a su pregunta original, Docker realmente no está destinado a esto, pero si tuviera un entorno de desarrollo lo suficientemente pequeño (digamos PHP en Linux), podría hacerlo en un contenedor, y el beneficio sería una imagen mucho más pequeña (potencialmente menos de 100 MB frente a muchos GB para una VM de Windows con disco virtual).

no en un contenedor acoplable, pero sí en n contenedores acoplables.

Si bien, en teoría, podría ensamblar todo su entorno de desarrollo dentro de un solo contenedor, Docker no estaba destinado a hacer esto.

En su lugar, debe implementar cada servicio en contenedores separados, utilizando Docker Composose , administrando toda su infraestructura en un solo archivo, donde cada servicio tendrá su propio archivo de registro, espacio de usuario, redes, etc.

Déjame darte un ejemplo, este es un borrador de mi 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

Hay un proxy nginx (myproxy), dos bases de datos postgres similares (mydb1 y 2), un antiguo servidor de aplicaciones web java (www), un contenedor java jetty que proporciona un servicio web de descanso y finalmente un contenedor de postfix SMTP muy simple.

Todo comienza, generalmente :), con docker-compose upmi máquina de desarrollo o en producción; los archivos de registro se agregan en un archivo fácil de leer y es posible replicar localmente casi todas las funciones con la garantía de que, si funciona en mi computadora portátil, funcionará.

Utilizo máquinas virtuales VirtualBox para este tipo de cosas.

La portabilidad de tener su entorno de desarrollo en un contenedor es útil, pero lo realmente bueno es que puedo tomar una foto antes de cualquier intento de actualización, y si lo arruino, no hay problema en retroceder y comenzar de nuevo.

También me parece útil hacer esto porque con frecuencia trabajo con múltiples versiones de cosas como Qt, y no tengo ganas de descubrir cómo hacer que las dos versiones coexistan; en cambio, las coloco en diferentes máquinas virtuales y No tengo que preocuparme por las interacciones porque instalé algo incorrectamente.