Parlerò dell'approccio all'organizzazione di ambienti di sviluppo locali isolati sul mio workstation. Questo approccio è stato sviluppato a causa dei seguenti fattori:

per diverse lingue sono necessarie IDE e toolchain diversi;
in diversi progetti possono essere utilizzate versioni diverse di toolchain e librerie.

L'approccio consiste nel portare avanti lo sviluppo all'interno di contenitori LXD eseguiti localmente sul laptop o sulla workstation con il reindirizzamento dell'output grafico all'host.

Configurazione con esempio Ubuntu 20.04.

Riflessioni sulle opzioni e sulle motivazioni sono incluse alla fine dell'articolo.

1. Installazione di LXD

In Ubuntu 20.04 LXD non è più disponibile per l'installazione come pacchetto deb, solo tramite snap:

$ snap install lxd

Dopo l'installazione, è necessario eseguire l'inizializzazione:

$ lxd init

L'unico parametro che modifico è storage backend — utilizzo dir come il più semplice. Poiché non utilizzo snapshot e copie, gli avvertimenti in documentazione non mi spaventano:

Allo stesso modo, il backend directory deve essere considerato come un'opzione di ultima risorsa.
Supporta tutte le principali funzionalità di LXD, ma è terribilmente lento e inefficiente poiché non può eseguire
copia istantanea o snapshot e deve copiare l'intero spazio di archiviazione dell'istanza ogni volta.

2. Configurazione del profilo LXD

Profili in LXD — sono insiemi di parametri applicati a più contenitori. Per le mie esigenze, mi basta un profilo predefinito creato. default con le seguenti modifiche:

$ lxc profile device add default X0 disk source=/tmp/.X11-unix/X0 path=/tmp/.X11-unix/X0 — affinché le applicazioni nei contenitori possano interagire con il server X11 host;
$ lxc profile set default environment.DISPLAY :0 — per impostare correttamente la variabile d'ambiente DISPLAY nei contenitori;
$ lxc profile set default raw.idmap "both 1000 1000" — per una corretta mappatura degli identificatori..

3. Creazione e configurazione del contenitore

Creare un contenitore basato sull'immagine images:ubuntu/20.04:

$ lxc launch images:ubuntu/20.04 dev1

Preferisco le immagini del repository, https://images.linuxcontainers.orgpoiché contengono meno software preinstallato. Per questo motivo ho aggiunto un prefisso images: al nome dell'immagine. Creare un contenitore basato su un'immagine del repository Ubuntu può essere fatto nel seguente modo: $ lxc launch ubuntu/20.04 dev1.

Accesso alla shell di root del contenitore:

$ lxc exec dev1 -- bash

Installerò Firefox e VS Code (dal repository seguendo le istruzioni.):

$ apt update
$ apt install curl gpg firefox

$ curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > packages.microsoft.gpg
$ install -o root -g root -m 644 packages.microsoft.gpg /usr/share/keyrings/
$ echo "deb [arch=amd64 signed-by=/usr/share/keyrings/packages.microsoft.gpg] https://packages.microsoft.com/repos/vscode stable main" > /etc/apt/sources.list.d/vscode.list

$ apt update
$ apt install code

Attiverò il contenitore per maggiore chiarezza

poweroff

Bonus! È piuttosto semplice dedicare una GPU a un contenitore in modo che le applicazioni in esecuzione possano utilizzare la scheda grafica. Per farlo, è necessario:

aggiungere un dispositivo $ lxc config device add dev1 mygpu gpu;
installare i driver grafici nel contenitore — gli stessi che sono installati sull'host.

4. Utilizzo del contenitore

Se il contenitore non è ancora avviato, è necessario avviarlo:

lxc start dev1

Avvio di VS Code con un utente non privilegiato ubuntu:

lxc exec dev1 -- sudo --login --user ubuntu code

Avvio di Firefox:

lxc exec dev1 -- sudo --login --user ubuntu firefox

Le finestre delle applicazioni verranno visualizzate sull'host, ma le esecuzioni avverranno all'interno del contenitore — simile alla gestione della grafica tramite ssh.

Non spengo i contenitori attivi manualmente, poiché non vedo motivo di farlo — mi limito a chiudere le finestre delle applicazioni in esecuzione.

5. Conclusione

Preferisco non utilizzare un sistema operativo ospite per lo sviluppo, in quanto richiederebbe l'installazione di strumenti di sviluppo, versioni di debug delle librerie, la configurazione di componenti di sistema in modo specifico e altre manipolazioni. Tutto ciò può portare a comportamenti imprevisti di altri software non correlati allo sviluppo, o addirittura dell'intero sistema operativo. Ad esempio, le modifiche nella configurazione di OpenSSL potrebbero far sì che il sistema operativo smetta di avviarsi correttamente.

Ho provato diversi strumenti per l'isolamento degli ambienti di sviluppo:

macchine virtuali (KVM, VirtualBox, ecc.) — l'opzione più ovvia, ma consuma risorse significativamente maggiori; tuttavia, per lo sviluppo su Windows (se l'host è Linux) non ci sono alternative;
strumenti di sviluppo cloud eseguiti sulla macchina locale (Cloud9 in un contenitore o macchina virtuale, Eclipse Che, ecc.) — non sono progettati per questo tipo di utilizzo, richiedono configurazioni e manutenzioni aggiuntive, e sono meglio utilizzati come previsto — nel cloud;
I contenitori Docker sono, a mio avviso, pensati per altro e non risultano molto comodi per prototipare rapidamente con software che non è ancora confezionato in contenitori separati.

L'approccio scelto mi piace per la sua semplicità e basso tasso di ingresso. All'interno dei contenitori si possono adottare approcci specifici per i progetti: impostare tutto manualmente o utilizzare automazione (Puppet, Ansible, ecc.), anche per implementare un'infrastruttura basata su Docker. Utilizzo anche contenitori LXD per eseguire software specifico che richiede l'installazione di molte dipendenze o un'altra versione del sistema operativo: in questo caso, posso creare un contenitore con la versione del sistema operativo necessaria, ad esempio $ lxc launch images:ubuntu/16.04 dev16.

È importante ricordare che, in termini di isolamento, la containerizzazione presenta una superficie d'attacco più ampia rispetto alla virtualizzazione: il host e il contenitore condividono lo stesso kernel, e una vulnerabilità in esso potrebbe consentire a software dannoso di uscire dal contenitore. Per esperimenti con software sospetto, è meglio utilizzare meccanismi di isolamento più appropriati.

Link utili

Un articolo approfondito su Habr Funzionalità di base di LXD — sistemi di contenitori in Linux.
Portale del progetto LXD, è importante non confondere LXD con LXC: sono cose diverse ma interconnesse.
Blog di Simos Xenitellis — questo blog contiene una grande quantità di informazioni pratiche utili su LXD.
Immagini pronte di macchine virtuali Windows 10 per sviluppatori — Microsoft raccoglie periodicamente nuove build e le distribuisce con una licenza speciale.

Fonte: habr.com