Gibt es Vorteile beim Ausführen meiner Entwicklungsumgebung in einem Docker-Container?

Ich entwickle hauptsächlich mit Visual Studio unter Windows. Das Problem ist, dass Windows nach einer Weile festsitzt und ich Windows neu installieren muss. Ebenso ist die Umstellung auf neue Maschinen ein Problem.

Die Neuinstallation von Windows ist schmerzhaft, da meine Entwicklungsumgebung viele Abhängigkeiten aufweist (z. B. zusätzliche MSBuild-Konfigurationsdateien, VS-Erweiterungen, npm, Java usw.). Ich kann mir nicht vorstellen, dass ich mit einem komplexen System allein bin, und die Wiederherstellung würde wahrscheinlich mindestens einen Tag dauern.

Ich habe Docker nicht wirklich verwendet, aber theoretisch klingt es so, als könnte ich meine Entwicklungsumgebung in einem Windows-Container einrichten und sie dann einfach versenden (z. B. auf meinen Laptop kopieren, eine neue Windows-Installation durchführen) und es sollte schmerzlos sein .

Ist das, was ich beschreibe, möglich? Gibt es Nachteile wie Leistung, Zuverlässigkeit? Andere Fallstricke?

Dies ist kein ungewöhnliches Problem, aber Docker ist nicht wirklich das richtige Werkzeug, um es zu lösen. Container im Allgemeinen (einschließlich Docker) sollen eine Anwendungslaufzeit für einen einzelnen Prozess , z. B. einen Webserver, bereitstellen , nicht für ein Szenario mit mehreren Prozessen, z. B. eine Entwicklungsumgebung. In kann getan werden, ist aber keine sehr elegante Lösung.

Ein besserer (und häufigerer) Ansatz besteht darin, VMs entweder über einen herkömmlichen Hypervisor wie VirtualBox oder Hyper-V zu erstellen (da Sie unter Windows arbeiten). Ein typischer Workflow ist:

• Suchen oder erstellen Sie ein Basis-VM-Image basierend auf Ihrer bevorzugten Betriebssystemvariante. Dies kann direkt mit dem ISO-Installateur erfolgen, oder jemand an Ihrem Arbeitsplatz hat möglicherweise bereits einen.
• Fügen Sie nach dem Erstellen des Basis-Images alle erforderlichen Entwicklungswerkzeuge und -einstellungen hinzu. Schnappschuss oder speichern Sie dies als separates Bild.
• Jetzt können Sie dieses Image, RDP oder Remote ausführen und so lange arbeiten, bis Sie an einem Punkt angelangt sind, an dem Sie "festgefahren" sind. Speichern Sie dann einfach die benötigten Dateien (verpflichten Sie sich zur Quellcodeverwaltung usw.) und blasen Sie dann Entfernen Sie das Bild und beginnen Sie erneut mit einem der beiden von Ihnen erstellten Schnappschüsse / Bilder. Dies kann in Sekundenschnelle erfolgen, im Gegensatz zu bis zu einem Tag auf altmodische Weise.
• Erstellen Sie an jedem Punkt der Linie zusätzliche Schnappschüsse, wenn Sie auf Situationen stoßen, in die Sie möglicherweise ein Rollback durchführen möchten, um ein Problem usw. zu reproduzieren.

Vagrant ist auch ein fantastisches Werkzeug, um viele der oben genannten Aufgaben strukturierter zu erledigen.

Ein Nebeneffekt von all dem ist, dass Sie jetzt standardisierte Umgebungen haben, die mit Ihrem gesamten Team geteilt werden können, wodurch jeder die Mühe erspart. Dies ist besonders gut geeignet, um schnell neue Leute zu gewinnen.

Zurück zu Ihrer ursprünglichen Frage, Docker ist nicht wirklich dafür gedacht, aber wenn Sie eine ausreichend kleine Entwicklungsumgebung hätten (z. B. PHP unter Linux), könnten Sie dies in einem Container tun, und der Vorteil wäre ein viel kleineres Image (möglicherweise) unter 100 MB gegenüber vielen GB für eine Windows-VM mit virtueller Festplatte).

Nicht in einem Docker-Container, sondern in n Docker-Containern.

Während Sie theoretisch Ihre gesamte Entwicklungsumgebung in einem einzigen Container zusammenstellen konnten, war Docker nicht dazu gedacht.

Stattdessen sollten Sie jeden Dienst in separaten Containern bereitstellen, Docker Compose verwenden und Ihre gesamte Infrastruktur in einer einzigen Datei verwalten, wobei jeder Dienst über eine eigene Protokolldatei, einen eigenen Benutzerbereich, ein eigenes Netzwerk usw. verfügt.

Lassen Sie mich ein Beispiel geben, dies ist ein Entwurf von mir 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

Es gibt einen Nginx-Proxy (myproxy), zwei ähnliche Postgres-Datenbanken (mydb1 und 2), einen alten Java-Webanwendungsserver (www), einen Java-Jetty-Container, der einen Rest-Webdienst bereitstellt, und schließlich einen sehr einfachen SMTP-Postfix-Container.

Alles startet - normalerweise :) - docker-compose upentweder auf meiner Entwicklungsmaschine oder in der Produktion; Protokolldateien werden zu einer einfach zu lesenden Datei zusammengefasst, und es ist möglich, fast alle Funktionen lokal zu replizieren, mit der Garantie, dass sie funktionieren, wenn sie auf meinem Laptop funktionieren.

Ich benutze VirtualBox-VMs für solche Dinge.

Die Portabilität, Ihre Entwicklungsumgebung in einem Container zu haben, ist praktisch, aber das wirklich Schöne ist, dass ich das Ding vor jedem Upgrade-Versuch als Schnappschuss erstellen kann. Wenn ich es vermassle, ist es kein Problem, zurückzugreifen und erneut zu starten.

Ich finde es auch hilfreich, dies zu tun, da ich häufig mit mehreren Versionen von Dingen wie Qt arbeite und keine Lust habe, herauszufinden, wie die beiden Versionen nebeneinander existieren können. Stattdessen lege ich sie einfach auf verschiedene VMs und Ich muss mich nicht um Interaktionen kümmern, weil ich etwas falsch installiert habe.