Ci sono vantaggi nell'esecuzione del mio ambiente di sviluppo in un contenitore Docker?

Questo non è un problema raro, ma Docker non è davvero lo strumento giusto per risolverlo. I contenitori in generale (inclusa Docker) hanno lo scopo di fornire un runtime dell'applicazione per un singolo processo , ad esempio un server web, non per uno scenario multi-processo come un ambiente di sviluppo. In può essere fatto, ma non è una soluzione molto elegante.

Un approccio migliore (e più comune) è quello di creare macchine virtuali tramite un hypervisor tradizionale come VirtualBox o Hyper-V (dato che sei su Windows). Un tipico flusso di lavoro è:

• Trova o crea un'immagine di base VM basata sul tuo SO preferito. Questo può essere fatto direttamente con l'ISO dell'installatore, oppure qualcuno sul posto di lavoro potrebbe averne già uno.
• Una volta creata l'immagine di base, aggiungi tutti gli strumenti e le impostazioni di sviluppo che ti servono. Istantanea o salvarla come immagine separata.
• Ora puoi eseguire questa immagine, RDP o remoto, e lavorare finché non arrivi ad un punto in cui ti "impantanati" e poi risparmi semplicemente i file che ti servono (esegui il commit del controllo del codice sorgente, ecc.) , quindi soffiare via l'immagine e ricominciare da una delle due istantanee / immagini che hai creato. Questo può essere fatto in pochi secondi, rispetto a un giorno alla vecchia maniera.
• In qualsiasi punto della linea, crea istantanee aggiuntive quando incontri situazioni alle quali potresti voler eseguire il rollback per riprodurre un problema, ecc.

Vagrant è anche uno strumento fantastico per fare molto di quanto sopra in un modo più strutturato.

Un vantaggio collaterale di tutto questo è che ora disponi di ambienti standardizzati che possono essere condivisi con tutto il tuo team, risparmiando a tutti lo sforzo. Questo è particolarmente utile per le nuove persone che si imbarcano rapidamente.

Tornando alla tua domanda iniziale, Docker non è realmente inteso per questo, ma se tu avessi un ambiente dev abbastanza piccolo (ad esempio PHP su Linux), potresti farlo in un contenitore, e il vantaggio sarebbe molto più piccolo immagine (potenzialmente inferiore a 100 MB rispetto a molti GB per una VM Windows con disco virtuale).

non in un contenitore finestra mobile ma sì in n contenitori docker.

Mentre potevi - teoricamente - assemblare l'intero ambiente di sviluppo all'interno di un singolo contenitore, la finestra mobile non era pensata per fare questo.

Invece dovresti distribuire ciascun servizio in contenitori separati, usando docker compose , gestendo l'intera infrastruttura in un unico file , dove ogni servizio avrà il proprio file di registro, spazio utente, networking, ecc.

Lasciatemi fare un esempio, questa è una bozza del mio 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

C'è un proxy nginx (myproxy), due database postgres simili (mydb1 e 2), un vecchio java web application server (www), un java jetty container che fornisce un servizio web di riposo e infine un semplice contenitore SMTP postfisso .

Tutto si avvia - di solito :) - con docker-compose up , sulla mia macchina di sviluppo o in produzione; i file di registro sono aggregati in un unico file di facile lettura ed è possibile replicare localmente quasi tutte le funzionalità con la garanzia che, se funziona sul mio laptop, funzionerà.

Io uso VirtualBox VM per questo genere di cose.

La portabilità di avere l'ambiente di sviluppo in un contenitore è utile, ma la cosa veramente bella è che posso eseguire l'istantanea della cosa prima di qualsiasi tentativo di aggiornamento, e se lo rovino, non è un problema ricadere e ricominciare.

Trovo anche utile farlo perché lavoro spesso con più versioni di cose come Qt, e non ho voglia di capire come far convivere le due versioni - invece, le ho appena inserite VM diverse e non devo preoccuparmi delle interazioni perché ho installato qualcosa in modo non corretto.