Parlerò di un approccio all'organizzazione di ambienti di sviluppo locali isolati sulla mia workstation. L’approccio è stato sviluppato sotto l’influenza dei seguenti fattori:

• Linguaggi diversi richiedono IDE e toolchain diversi;
• Progetti diversi possono utilizzare versioni diverse di toolchain e librerie.

L'approccio consiste nello sviluppo all'interno di contenitori LXD eseguiti localmente su un laptop o workstation con output grafico reindirizzato all'host.

Configurazione di esempio Ubuntu 20.04.

Alla fine dell'articolo vengono fornite riflessioni su opzioni e ragioni.

1. Installazione dell'LXD

В 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 cambio è storage bakend - Io uso dir come quello più semplice. Poiché non utilizzo immagini e copie, gli avvisi in documentazione Non mi spaventano:

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

2. Impostazione del profilo LXD

Profili in LXD — si tratta di insiemi di parametri applicati a più contenitori. Per le mie esigenze mi basta il solo profilo creato di default default con le seguenti modifiche:

• $ lxc profile device add default X0 disk source=/tmp/.X11-unix/X0 path=/tmp/.X11-unix/X0 — in modo che le applicazioni nei contenitori possano interagire con il server host X11;
• $ lxc profile set default environment.DISPLAY :0 - in modo che la variabile ambientale DISPLAY è stato installato correttamente nei contenitori;
• $ lxc profile set default raw.idmap "both 1000 1000" - per il corretto mappatura degli identificatori.

3. Creazione e impostazione di un contenitore

Creazione di un contenitore basato su un'immagine images:ubuntu/20.04:

$ lxc launch images:ubuntu/20.04 dev1

Preferisco le immagini dal repository https://images.linuxcontainers.org, poiché hanno meno software preinstallato. Per questo motivo ho aggiunto il prefisso images: al nome dell'immagine. La creazione di un contenitore basato su un'immagine dal repository Ubuntu può essere eseguita come segue: $ lxc launch ubuntu/20.04 dev1.

Accesso alla shell root del contenitore:

$ lxc exec dev1 -- bash

Installerò Firefox e VS Code (dal repository secondo 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

Includerò un contenitore per chiarezza.

poweroff

Bonus! È abbastanza semplice inserire una GPU in un contenitore in modo che le applicazioni in esecuzione al suo interno possano utilizzare la scheda grafica. Per fare questo è necessario:

• Aggiungi dispositivo $ lxc config device add dev1 mygpu gpu;
• installa i driver della scheda video nel contenitore, gli stessi installati sull'host.

4. Utilizzando un contenitore

Se il contenitore non è ancora in esecuzione, è necessario avviarlo:

lxc start dev1

Esecuzione di VS Code come utente non root ubuntu:

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

Avvia Firefox:

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

Le finestre dell'applicazione verranno visualizzate sull'host, ma verranno eseguite all'interno del contenitore, in modo simile all'inoltro della grafica tramite ssh.

Non chiudo manualmente i contenitori in esecuzione, perché non ne vedo molto il motivo: mi limito a chiudere le finestre delle applicazioni in esecuzione.

5. Заключение

Preferisco non utilizzare un sistema operativo host per lo sviluppo, poiché ciò richiederebbe l'installazione di strumenti di sviluppo, versioni di debug delle librerie, la configurazione dei componenti di sistema in un modo specifico e altre manipolazioni. Tutto ciò può portare a comportamenti imprevisti in altri software non di sviluppo o persino nell'intero sistema operativo. Ad esempio, le modifiche alla configurazione di OpenSSL possono causare l'arresto corretto dell'avvio del sistema operativo.

Ho provato diversi strumenti per isolare gli ambienti di sviluppo:

• le macchine virtuali (KVM, VirtualBox, ecc.) sono l'opzione più ovvia, ma consumano molte più risorse, sebbene non ci siano altre opzioni per lo sviluppo sotto Windows (se l'host è Linux);
• strumenti di sviluppo cloud in esecuzione su una macchina locale (Cloud9 in un contenitore o macchina virtuale, Eclipse Che, ecc.) - non sono sviluppati per questa modalità operativa, richiedono configurazione e manutenzione aggiuntive, è meglio usarli per lo scopo previsto scopo: nel cloud;
• I contenitori Docker sono ancora destinati a qualcos'altro; a mio avviso non sono molto convenienti per la prototipazione rapida utilizzando software non ancora confezionato in contenitori separati.

L'approccio scelto mi colpisce per la sua semplicità e la bassa barriera all'ingresso. Nei container stessi è possibile utilizzare approcci specifici del progetto: installare e configurare tutto manualmente oppure utilizzare l'automazione (Puppet, Ansible, ecc.), persino distribuire Infrastruttura basata su Docker. Utilizzo anche i contenitori LXD per eseguire software specifico che richiede l'installazione di un gran numero di dipendenze o di una versione del sistema operativo diversa: in questo caso puoi creare un contenitore con la versione del sistema operativo desiderata, ad esempio $ lxc launch images:ubuntu/16.04 dev16.

È importante ricordare che in termini di isolamento, la containerizzazione ha una superficie di attacco maggiore rispetto alla virtualizzazione: l'host e il contenitore condividono un unico core, una vulnerabilità in cui può consentire al malware di fuoriuscire dal contenitore. Quando si sperimenta software dubbio, è meglio utilizzare meccanismi di isolamento più appropriati.

Link utili

• Articolo capiente su Habré Funzionalità di base dei sistemi contenitore LXD - Linux
• Portale del progetto LXD, è importante non confondere LXD con LXC: sono cose diverse, ma correlate.
• Blog Simos Xenitellis - questo blog contiene molte informazioni utili e applicate su LXD.
• Immagini già pronte di macchine virtuali Windows 10 per sviluppatori — Microsoft raccoglie periodicamente nuove build e le distribuisce con una licenza speciale.

Fonte: habr.com