Durante le mie prime due settimane in Cloud Enablers, ho iniziato a dare un’occhiata ai Dev Containers, tra le tante cose…

I Development (o Dev, in forma abbreviata) container sono container utilizzati a scopi di sviluppo. Sono infatti containers già pronti all’uso con tutti i contenuti e i metadata necessari per poter sviluppare al loro interno.

Devo ammettere che al solo leggere la definizione, ho pensato: “Ok, e quindi? perché dovrei sviluppare usando un container?”

Le cose poi, però, si sono fatte più chiare quando ho capito quali sono i benefici nell’utilizzare i Dev Container.

Quali sono i benefici

Usare i Dev Container ti permette di:

• Utilizzare strumenti e versioni di librerie necessarie allo sviluppo coerenti.
• Accelerare il processo di sviluppo.
• Ridurre i conflitti di sistema.
• Facilitare il processo di onboarding.
• Centralizzare l’automazione in termini di implementazione e test.

Con i Dev Container, puoi creare degli ambienti di sviluppo che siano riproducibili, pre-configurati e isolati.

Riproducibili perché, qualunque sia la macchina dove andrai a lavorare, una volta che il container è avviato, lo stato del progetto sarà sempre lo stesso.

Pre-configurati perché puoi specificare quali dipendenze, estensioni del tuo IDE e librerie dovrebbero essere installate per poterti permettere di iniziare a sviluppare immediatamente.

E, in ultimo, isolati perché saranno completamente indipendenti dalla macchina in cui sviluppi e da tutti i software che sono già installati.

Diamo un’occhiata a come è possibile definire un Dev Container.

Dev Container Specification

Il modo in cui è possibile aggiungere i contenuti e i metadata al tuo container è attraverso il Development Container Specification.

Il Dev Container Specification consiste in un file chiamato devcontainers.json.

A seconda dello strumento o del servizio che andrai ad utilizzare, il file JSON dovrà trovarsi in uno dei seguenti path:

• .devcontainer/devcontainer.json
• devcontainer.json
• .devcontainer//devcontainer.json

Io ho utilizzato VS Code, e il formato da utilizzare in questo caso è .devcontainer/devcontainer.json.

Di seguito puoi vedere un esempio di un file devcontainers.json:

{
  "name": "the name of the dev container",
  "image": "mcr.microsoft.com/devcontainers/typescript-node",
  "customizations": {
    "vscode": {
      "extensions": [
        "yoavbls.pretty-ts-errors",
        "infeng.vscode-react-typescript"
      ]
    }
  },
  "features": {
    "ghcr.io/devcontainers/features/aws-cli:1": {},
    "ghcr.io/devcontainers/features/git:1": {},
    "ghcr.io/devcontainers-contrib/features/aws-cdk:2": {},
    "ghcr.io/devcontainers-contrib/features/zsh-plugins:0": {}
  },
  "postCreateCommand": "npm install"
}

Nell’esempio ho riportato giusto qualche parametro utile a comprendere il concetto di Dev Container. Per approfondire i parametri disponibili, è possibile fare riferimento alla documentazione ufficiale qui.

image è il nome dell’immagine che vuoi utilizzare, e che verrà usata per creare il Dev Container. Questo parametro è obbligatorio, a meno che tu non voglia utilizzare un’immagine custom partendo da un Dockerfile: in questo caso, il parametro obbligatorio sarebbe build.dockerfile.

Nel parametro customizations è possibile trovare le informazioni specifiche sul tool. Nel caso di esempio, sto utilizzando VS Code e definendo quali estensioni vorrei installare durante la fase di creazione del container.

Qualsiasi parametro feature rappresenta, invece, un pezzo di codice, o software, che si vuole installare. In questo esempio, si richiede l’installazione di AWS CLI, Git, AWS CDK e la shell zsh.

Se definito, postCreateCommand rappresenta il comando che verrà eseguito dopo che il container è stato creato. Nel mio caso, dopo la sua creazione, richiedo l’esecuzione dell’istruzione npm install.

Tool di supporto più popolari

I Dev Container sono un concetto, uno standard e un formato supportati da diversi tool e servizi. Io ho utilizzato VS Code, ma GitHub Codespace è anche tra quelli più popolari.

Per conoscere l’elenco completo, è possibile consultare qui la documentazione.

Inizi a percepirne i benefici?

Una delle prime cose che ho pensato dopo aver scavato nella doc di questo tema è stata: “Sarebbe fantastico averli in progetti Open source!”

Dev Container e Open source: il match perfetto

Forse sarò io, ma spesso ho lasciato perdere progetti open source davvero interessanti dove avrei potuto contribuire perché avrei avuto bisogno di ore per configurare l’intero ambiente e non è detto che questo sarebbe andato a buon fine. Centinaia di errori da sistemare, è notte fonda e le poche ore di sonno che mi rimangono si riducono sempre di più. Non ne vale la pena.

Immagina invece di clonare un repository open-source, aprire VS Code, lanciare il container con un paio di click in qualche secondo (minuti, nel caso in cui si tratti di progetti più grandi) e una nuova finestra di VS Code si apre, mostrandoti il codice sorgente e sei pronto/a per sviluppare. Che figata è?

Non c’è più bisogno di patire durante l’installazione e la configurazione dell’ambiente, perdere tempo nel cercare nel repo GitHub issue del tipo “non funziona sulla versione X del sistema operativo Y” e, per certo, più persone sarebbero felici di contribuire.

AWS CDK, per esempio, è tra gli strumenti aggiunti alla Dev Container Specification e grazie alla sua inclusione, ho iniziato a contribuire al progetto stesso.

Conclusioni

Con i Dev Container, è possibile creare ambienti di sviluppo riproducibili, pre-configurati e isolati. Questa particolarità li rende perfetti da utilizzare in progetti open source per rendere lo sviluppo facile e veloce per tutte le persone che vogliano contribuire.

I Dev Containers sono uno standard abbastanza nuovo e sono più che certa che sempre più team di sviluppo abbiano iniziato a utilizzarli.

Tuttavia, sarebbe fantastico se anche più progetti open source fornissero una configurazione Dev Container per poter contribuire!

È tutto gente! Fammi sapere cosa ne pensi di questo articolo scrivendo a martina.theindiecoder@gmail.com.

A presto! 🚀

Post originale pubblicato su TheIndieCoder.cloud