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 de buildpack :
| Language | Ré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 |
| Scala | Scala 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/ |
| Go | Go 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. |