Nixpacks è un progetto open-source gestito da Railway. È una delle soluzioni per creare automaticamente l’immagine del container dei un’applicazione in base al repository. I Nixpack sono script che vengono eseguiti quando l’applicazione viene distribuita per installare le dipendenze e configurare l’ambiente.
Da Kinsta, consigliamo di utilizzare i Nixpack perché utilizzano meno risorse e supportano più di 20 linguaggi. È possibile scegliere i Nixpack nel momento in cui si aggiunge un’applicazione oppure modificando l’opzione Ambiente di build nelle impostazioni dell’applicazione (Impostazioni > Informazioni di base > Modifica informazioni).
Linguaggi supportati
Nixpacks supporta i seguenti linguaggi:
- Clojure
- Cobol
- Crystal
- C#/.NET
- Dart
- Deno
- Elixir
- F#
- Go
- Haskell
- Java
- Lunatic
- Node
- PHP
- Python
- Ruby
- Rust
- Staticfile
- Swift
- Scala
- Zig
Per utilizzare una versione diversa di un linguaggio, bisogna impostare la versione nei file dell’applicazione.
Con i Nixpacks, di solito non è necessario scegliere o aggiungere diversi provider per la compilazione perché vengono rilevati automaticamente. Se per l’applicazione sono necessari altri provider, è possibile definirli in un file di configurazione di Nixpacks.
Se si desidera utilizzare un linguaggio non supportato da Nixpacks o da buildpacks, è necessario utilizzare un Dockerfile. Quando si aggiunge un’applicazione, è possibile selezionare l’opzione Usa Dockerfile per configurare l’immagine del container.
Configurare Nixpacks
Per l’esecuzione, alcune applicazioni non richiedono alcuna configurazione, altre richiedono comandi e opzioni specifiche, come ad esempio:
Variabili d’ambiente: potrebbe essere necessario impostare alcune variabili d’ambiente per eseguire l’applicazione.
Processi: Kinsta può rilevare automaticamente il comando del processo web. Se necessario, è possibile modificarlo e definire altri processi.
Processi in un Procfile: è possibile definire i processi in un Procfile all’interno del codice dell’applicazione.
Le directory binarie di Nixpacks
Con Nixpacks, le directory binarie possono differire dalle directory binarie predefinite per il linguaggio dell’applicazione. La tabella che segue mostra le directory binarie utilizzate per alcuni dei linguaggi più comuni:
| Lingua | Directory |
|---|---|
| Node.js | /nix/var/nix/profiles/default/bin/node |
| Rubino | /nix/var/nix/profiles/default/bin/ruby |
| Python | /nix/var/nix/profiles/default/bin/python |
| Java | /nix/var/nix/profiles/default/bin/java |
| Scala | Scala non ha un percorso binario predefinito specifico come altri linguaggi compilati. Quando si compila un programma Scala, questo genera un bytecode che viene eseguito sulla Java Virtual Machine (JVM).
Le classi compilate in Scala sono solitamente memorizzate in una struttura di directory che rispecchia la struttura dei pacchetti del codice. È qualcosa di simile all’organizzazione delle classi in Java. Di default, quando si compila un file sorgente Scala, i file .class compilati vengono inseriti nella stessa directory del codice sorgente (all’interno di una struttura di sottodirectory basata sulle dichiarazioni del pacchetto). Se necessario, si possono installare gli strumenti di runtime di Scala utilizzando un Dockerfile invece di utilizzare un Nixpack. |
| PHP | /nix/var/nix/profili/default/bin/php |
| Go | Go non ha un percorso binario predefinito specifico come altri linguaggi compilati. Quando si compila un programma Go, di default l’eseguibile binario risultante viene solitamente collocato nella stessa directory del codice sorgente.
Se necessario, è possibile installare gli strumenti di runtime di Go utilizzando un Dockerfile invece di utilizzare un Nixpack. |