Nixpacks

Ultimo aggiornamento 18 marzo 2024

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.js
PHP
Python
Rust
Swift
Scala
Zig

Per utilizzare una versione del linguaggio diversa, 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.

Impostare la versione di linguaggio di un Nixpack

Quando si seleziona l’opzione Usa Nixpacks per configurare l’immagine del container, se non si specifica una versione nel codice dell’applicazione, il Nixpack utilizzerà l’ultima versione disponibile. Se si desidera utilizzare una versione di linguaggio diversa per l’applicazione, sarà necessario impostare la versione nei file dell’applicazione o, a seconda del linguaggio, con una variabile d’ambiente.

I metodi disponibili per impostare la versione variano a seconda del linguaggio. Di seguito abbiamo incluso degli esempi per i linguaggi più comuni.

Go

Per specificare la versione di Go, includere quanto segue nel file go.mod dell’applicazione:

go 1.18

Java

Per specificare la versione di Java, impostare la variabile d’ambiente NIXPACKS_JDK_VERSION e assicurarsi che la variabile sia disponibile durante il processo di build.

Se si sta usando Gradle, per specificare la versione, impostare la variabile d’ambiente NIXPACKS_GRADLE_VERSION e assicurarsi che sia disponibile durante il processo di build.

Node.js

Per specificare la versione di Node.js, eseguire una delle seguenti operazioni:

Includere quanto segue nel file package.json dell’applicazione:

"engines": {
"node": "18"
}

Impostare la variabile d’ambiente NIXPACKS_NODE_VERSION e assicurarsi che la variabile sia disponibile durante il processo di build.

PHP

Per specificare la versione di PHP, includere quanto segue nel file composer.json dell’applicazione:

{
  "require": {
    "php": "8.2"
  }
}

Python

Per specificare la versione di Python, eseguire una delle seguenti operazioni:

Includere quanto segue nel file runtime.txt dell’applicazione:
python-3.10.6
Includere quanto segue in un file .python-version nel repository:
3.10.6
Impostare la variabile d’ambiente NIXPACKS_PYTHON_VERSION e assicurarsi che la variabile sia disponibile durante il processo di build.

Scala

Per specificare la versione di Scala, includere quanto segue nel file build.sbt della tua applicazione:

scalaVersion := "3.2.2"