Buildpacks

Kinsta offre Buildpacks, un progetto open-source gestito da Heroku, come una delle opzioni per determinare e creare automaticamente un container per un’applicazione in base al repository. I Buildpack sono script che vengono eseguiti quando l’applicazione viene distribuita per installare le dipendenze dell’applicazione e configurare l’ambiente.

È possibile scegliere Buildpacks quando si aggiunge un’applicazione o modificando l’opzione Ambiente di build nelle impostazioni dell’applicazione (Impostazioni > Dettagli di base > Modifica dettagli).

Linguaggi supportati

Supportiamo i seguenti linguaggi per le applicazioni Buildpacks:

Se si vuole utilizzare una versione diversa per l’applicazione, sarà necessario impostare la versione nei file dell’applicazione.

Se si vuole utilizzare un linguaggio che non è supportata da Buildpacks, è possibile innanzitutto verificare se è un linguaggio supportato da Nixpacks. In caso contrario, sarà necessario utilizzare un Dockerfile. Quando si aggiunge un’applicazione, è possibile selezionare l’opzione Usa Nixpacks per impostare l’immagine del container o Usa Dockerfile per impostare l’immagine del container.

Configurare i buildpack

Alcune applicazioni non richiedono alcuna configurazione, mentre altre richiedono comandi e opzioni specifiche per essere eseguite, 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 ulteriori processi.

Processi in un Procfile – Potreste voler definire i processi in un Procfile all’interno del codice dell’applicazione.

Aggiungere o modificare i buildpack

È possibile gestire i buildpack nella pagina delle Impostazioni dell’applicazione. Per aggiungere altri buildpack, cliccare su Aggiungi buildpack. Per rimuovere o modificare l’ordine dei buildpack dell’applicazione, cliccare su Modifica buildpack.

Quando si aggiunge un buildpack, questo viene automaticamente aggiunto alla fine dell’elenco dei buildpack, quindi potrebbe essere necessario modificare l’ordine dei buildpack. È possibile trascinare e rilasciare i buildpack per cambiarne l’ordine nella finestra modale/pop-up Modifica buildpack.

Directory binarie di Buildpack

Con i buildpack, le directory binarie possono differire da quelle predefinite per il linguaggio dell’applicazione. La tabella seguente mostra le directory binarie utilizzate per ogni linguaggio di buildpack:

LinguaDirectory
Node.js/layers/heroku_nodejs-engine/dist/bin/node
Rubino/usr/bin/ruby
Python/usr/bin/python
Java/layers/heroku_jvm/openjdk/bin/java
ScalaScala 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. Questo è simile all’organizzazione delle classi Java. Per impostazione predefinita, 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, è possibile installare gli strumenti di runtime di Scala utilizzando un Dockerfile invece di un buildpack.

PHP/workspace/.heroku/php/bin/
GoGo non ha un percorso binario predefinito specifico come altri linguaggi compilati. Quando si compila un programma Go, l’eseguibile binario risultante viene solitamente collocato nella stessa directory del codice sorgente per impostazione predefinita.

Se necessario, è possibile installare gli strumenti di runtime di Go utilizzando un Dockerfile invece di un buildpack.

Impostare la versione del linguaggio di un buildpack

Quando si seleziona l’opzione Usa i Buildpack per impostare l’immagine del container, se non si specifica una versione nel codice dell’applicazione, il Buildpack utilizzerà l’ultima versione disponibile. Se si vuole usare una versione di linguaggio diversa per la propria applicazione, è necessario impostare la versione nei file dell’applicazione.

Il metodo per impostare la versione varia a seconda del linguaggio. Di seguito riportiamo degli esempi per i linguaggi attualmente supportati.

Go

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

// +heroku goVersion go1.11
go 1.21.1

Java

Per specificare la versione di Java, includere quanto segue nel file system.properties dell’applicazione:

java.runtime.version=11

Node.JS

Per specificare la versione di Node.js e la versione di npm, includere quanto segue nel file package.json della tua applicazione:

"engines": {
  "node": "^16.14.0",
  "npm": "^8.3.1"
}

React

Se si usa React e si vuole specificare la versione di React, sostituire o aggiungere la versione di React nel campo dependencies del file package.json:

"react": "^17.0.2"

Per impostare anche le versioni di Node.js e npm nell’applicazione React, includere quanto segue nel file package.json dell’applicazione:

"engines": {
  "node": "^16.14.0",
  "npm": "^8.3.1"
}

PHP

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

{
  "require": {
    "php": "~8.1.0"
  }
}

Python

Per specificare la versione di Python, basta includere quanto segue nel file runtime.txt dell’applicazione:

python-3.10.13

È possibile specificare le versioni dei moduli anche nel file requirements.txt:

Django==4.1
virtualenv==20.18.0

Ruby

Per specificare la versione di Ruby, includere nel Gemfile quanto segue:

ruby "3.0.6"

Scala

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

scalaVersion := "3.2.2"
Questo articolo ti è stato utile?