Buildpacks

Kinsta propose Buildpacks, un projet open source maintenu par Heroku, comme l’une des options permettant de déterminer et de créer automatiquement un conteneur pour votre application en fonction de votre dépôt. Les buildpacks sont des scripts qui sont utilisés quand votre application est déployée pour installer les dépendances de votre application et configurer votre environnement.

Vous pouvez choisir Buildpacks lors de l’ajout d’une application ou en modifiant l’option Environnement de construction dans les réglages de l’application (Réglages > Détails basiques > Modifier les détails).

Langages pris en charge

Nous prenons en charge les langages d’application suivants pour les Buildpacks :

Si vous souhaitez utiliser une version de langage différente pour votre application, vous devrez configurer la version dans les fichiers de votre application.

Si vous souhaitez utiliser un langage qui n’est pas un langage Buildpack supporté, vous pouvez d’abord vérifier s’il s’agit d’un langage supporté avec Nixpacks. Si ce n’est pas le cas, vous devez utiliser un Dockerfile. Quand vous ajoutez votre application, vous pouvez sélectionner l’option Utiliser Nixpacks pour configurer l’image du conteneur ou Utiliser Dockerfile pour configurer l’image du conteneur.

Configurer les Buildpacks

Certaines applications ne nécessitent aucune configuration, mais certaines nécessitent des commandes et des options spécialisées pour être utilisées, par exemple :

Variables d’environnement – Vous devrez peut-être configurer certaines variables d’environnement pour utiliser votre application.

Processus – Kinsta peut détecter automatiquement votre commande de processus web. Vous pouvez la modifier si nécessaire, et vous pouvez définir des processus supplémentaires.

Processus dans un Procfile – Vous pouvez définir vos processus dans un Procfile au sein du code de votre application.

Ajouter ou modifier des Buildpacks

Vous pouvez gérer les buildpacks sur la page des Réglages de votre application. Pour ajouter des buildpacks supplémentaires, cliquez sur Ajouter un buildpack. Pour supprimer ou modifier la commande des buildpacks de votre application, cliquez sur Modifier les buildpacks.

Quand vous ajoutez un buildpack, il est automatiquement ajouté à la fin de la liste des buildpacks, vous devrez donc peut-être modifier l’ordre de vos buildpacks. Vous pouvez faire glisser et déposer les buildpacks pour modifier leur commande dans la modale/popup Modifier les buildpacks.

Répertoires binaires des buildpacks

Avec les buildpacks, les répertoires binaires peuvent différer des répertoires binaires par défaut pour le langage de l’application. Le tableau ci-dessous affiche les répertoires binaires utilisés pour chaque langage du buildpack :

LanguageRépertoire
Node.js/layers/heroku_nodejs-engine/dist/bin/node
Ruby/usr/bin/ruby
Python/usr/bin/python
Java/layers/heroku_jvm/openjdk/bin/java
ScalaScala n’a pas de chemin binaire spécifique par défaut comme certains autres langages compilés. Quand vous compilez un programme Scala, il génère du bytecode qui s’utilise sur la machine virtuelle Java (JVM).

Les classes Scala compilées sont généralement stockées dans une structure de répertoire qui reflète la structure de paquetage de votre code. Cette structure est similaire à celle des classes Java. Par défaut, quand vous compilez un fichier source Scala, les fichiers .class compilés sont placés dans le même répertoire que le code source (dans une structure de sous-répertoire basée sur les déclarations de paquetage).

Si nécessaire, vous pouvez installer les outils d’exécution de Scala en utilisant un Dockerfile au lieu d’un buildpack.

PHP/workspace/.heroku/php/bin/
GoGo n’a pas de chemin binaire spécifique par défaut comme certains autres langages compilés. Quand vous compilez un programme Go, l’exécutable binaire résultant est généralement placé dans le même répertoire que votre code source par défaut.

Si nécessaire, vous pouvez installer les outils d’exécution de Go en utilisant un Dockerfile au lieu d’un buildpack.

Définir la version de langage d’un Buildpack

Quand vous sélectionnez l’option Utiliser les Buildpacks pour configurer l’image du conteneur, si vous ne spécifiez pas de version dans le code de votre application, le Buildpack utilisera la dernière version disponible. Si vous souhaitez utiliser une version différente pour votre application, vous devrez définir la version dans les fichiers de votre application.

La méthode pour définir la version varie selon le langage. Nous avons inclus ci-dessous des exemples pour les langages actuellement prises en charge.

Go

Pour spécifier votre version de Go, incluez ce qui suit dans le fichier go.mod de votre application :

// +heroku goVersion go1.11
go 1.21.1

Java

Pour spécifier votre version de Java, incluez ce qui suit dans le fichier system.properties de votre application :

java.runtime.version=11

Node.js

Pour spécifier votre version Node.js et votre version npm, incluez ce qui suit dans le fichier package.json de votre application :

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

React

Si vous utilisez React et que vous souhaitez spécifier votre version de React, remplacez ou ajoutez la version de React dans les dépendances de votre fichier package.json :

"react": "^17.0.2"

Pour définir également les versions de Node.js et de npm dans votre application React, incluez les réglages suivants dans le fichier package.json de votre application :

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

PHP

Pour spécifier votre version de PHP, incluez ce qui suit dans le fichier composer.json de votre application:

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

Python

Pour spécifier votre version de Python, incluez ce qui suit dans le fichier runtime.txt de votre application :

python-3.10.13

Vous pouvez également spécifier des versions de modules dans le fichier requirements.txt :

Django==4.1
virtualenv==20.18.0

Ruby

Pour spécifier votre version de Ruby, incluez ce qui suit dans votre Gemfile:

ruby "3.0.6"

Scala

Pour spécifier votre version Scala, incluez ce qui suit dans le fichier build.sbt de votre application :

scalaVersion := "3.2.2"
Cet article vous a été utile ?