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
  • Ruby
  • Rust
  • Staticfile
  • 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.

Documentation similaire