Nixpacks
Kinsta propose Nixpacks, un projet open source maintenu par Railway, comme l’une des options pour créer automatiquement l’image du conteneur de votre application sur la base de votre référentiel. Les Nixpacks sont des scripts qui sont exécutés lorsque votre application est déployée pour installer les dépendances de votre application et configurer votre environnement.
Nous vous recommandons d’utiliser les Nixpacks car ils utilisent moins de ressources et prennent en charge plus de 20 langages. Vous pouvez choisir Nixpacks 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 de base > Modifier les détails).
Langages supportés
Nixpacks prend en charge les langages suivants :
- Clojure
- Cobol
- Crystal
- C#/.NET
- Dart
- Deno
- Elixir
- F#
- Go
- Haskell
- Java
- Lunatic
- Node.js
- PHP
- Python
- Rust
- Swift
- Scala
- Zig
Pour utiliser une version différente de langage, définissez la version dans les fichiers de votre application.
Lorsque vous utilisez Nixpacks, il n’est généralement pas nécessaire de choisir ou d’ajouter différents fournisseurs pour la compilation car ils sont automatiquement détectés. Si des fournisseurs supplémentaires sont nécessaires pour l’application, vous pouvez les définir dans un fichier de configuration de Nixpacks.
Si vous souhaitez utiliser un langage qui n’est pas un langage Nixpacks ou buildpacks pris en charge, vous devez utiliser un fichier Dockerfile. Lorsque vous ajoutez votre application, vous pouvez sélectionner l’option Utiliser un fichier Docker pour configurer l’image du conteneur.
Configurer Nixpacks
Certaines applications ne nécessitent aucune configuration, mais d’autres néessitent des commandes et des options spécialisées pour être exécutées, telles que :
Variables d’environnement – Vous devrez peut-être définir certaines variables d’environnement pour exécuter votre application.
Processus – Kinsta peut détecter automatiquement la commande de votre 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.
Répertoires binaires Nixpacks
Avec les Nixpacks, les répertoires binaires peuvent différer des répertoires binaires par défaut pour le langage d’application. Le tableau suivant montre les répertoires binaires utilisés pour certains des langages les plus courants :
Langage | Répertoire |
---|---|
Node.js | /nix/var/nix/profiles/default/bin/node |
Ruby | /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 n’a pas de chemin binaire spécifique par défaut comme d’autres langages compilés. Lorsque vous compilez un programme Scala, il génère du bytecode qui s’exécute 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, lorsque 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 à l’aide d’un fichier Docker au lieu d’utiliser un Nixpack. |
PHP | /nix/var/nix/profiles/default/bin/php |
Go | Go n’a pas de chemin binaire par défaut spécifique comme certains autres langages compilés. Lorsque vous compilez un programme Go, l’exécutable binaire résultant est généralement placé par défaut dans le même répertoire que votre code source.
Si nécessaire, vous pouvez installer les outils d’exécution de Go à l’aide d’un fichier Docker au lieu d’utiliser un Nixpack. |
Définir la version de langage d’un Nixpack
Lorsque vous sélectionnez l’option Utiliser les Nixpacks pour configurer l’image du conteneur, si vous ne spécifiez pas de version dans le code de votre application, le Nixpack utilisera la dernière version disponible. Si vous souhaitez utiliser une version de langage différente pour votre application, vous devrez définir la version dans les fichiers de votre application ou, selon la langue, avec une variable d’environnement.
Les méthodes disponibles pour définir la version varient selon le langage. Vous trouverez ci-dessous des exemples pour les langages les plus courants.
Go
Pour spécifier votre version de Go, incluez ce qui suit dans le fichier go.mod de votre application :
go 1.18
Java
Pour spécifier votre version de Java, définissez la variable d’environnement NIXPACKS_JDK_VERSION
et assurez-vous que la variable est disponible pendant le processus de construction.
Si vous utilisez Gradle, pour spécifier la version, définissez la variable d’environnement NIXPACKS_GRADLE_VERSION
et assurez-vous qu’elle est disponible pendant le processus de construction.
Node.js
Pour spécifier votre version de Node.js, effectuez l’une des opérations suivantes :
Incluez les éléments suivants dans le fichier package.json de votre application :
"engines": {
"node": "18"
}
Définissez la variable d’environnement NIXPACKS_NODE_VERSION
et assurez-vous qu’elle est disponible pendant le processus de construction.
PHP
Pour spécifier votre version de PHP, incluez ce qui suit dans le fichier composer.json de votre application :
{
"require": {
"php": "8.2"
}
}
Python
Pour spécifier votre version de Python, faites l’une des choses suivantes :
- Incluez ce qui suit dans le fichier runtime.txt de votre application :
python-3.10.6
- Incluez ce qui suit dans un fichier .python-version dans votre dépôt :
3.10.6
- Définissez la variable d’environnement
NIXPACKS_PYTHON_VERSION
et assurez-vous qu’elle est disponible pendant le processus de construction.
Scala
Pour spécifier votre version de Scala, incluez ce qui suit dans le fichier build.sbt de votre application :
scalaVersion := "3.2.2"