buildpack
この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。
最終更新日 2019年09月20日(金)
Table of Contents
buildpack はデプロイされたコードを slug に変換する役目を担い、slug は dyno 上で実行することができます。 buildpack は一連のスクリプトで構成され、プログラミング言語に応じて、スクリプトは依存関係の取得や、生成されたアセットまたはコンパイル済みコードの出力などを行います。 この出力は slug コンパイラによって slug にアセンブルされます。
Heroku による Ruby、Python、Java、Clojure、Node.js、Scala、Go、および PHP のサポートは、オープンソースの一連の buildpack によって実装されます。
正式にサポートされる buildpack
Heroku は、Heroku のすべてのアプリが slug のコンパイル中にデフォルトで使用できる、正式にサポートされている buildpack 一式を維持管理しています。
これらの buildpack はオープンソースで、GitHub 上で利用できます。すべての Heroku 開発者に役立つと思われる変更がある場合は、プルリクエストの送信を受け付けております。
buildpack | ショートハンド | ドキュメント | ランタイムのバージョン |
---|---|---|---|
Ruby | heroku/ruby | ドキュメント | ランタイムのバージョン |
Node.js | heroku/nodejs | ドキュメント | ランタイムのバージョン |
Clojure | heroku/clojure | ドキュメント | ランタイムのバージョン |
Python | heroku/python | ドキュメント | ランタイムのバージョン |
Java | heroku/java | ドキュメント | ランタイムのバージョン |
Gradle | heroku/gradle | ドキュメント | ランタイムのバージョン |
JVM | heroku/jvm | ドキュメント | ランタイムのバージョン |
Grails 3.x | heroku/gradle | ドキュメント | ランタイムのバージョン |
Scala | heroku/scala | ドキュメント | ランタイムのバージョン |
Play 2.x | heroku/scala | ドキュメント | ランタイムのバージョン |
PHP | heroku/php | ドキュメント | ランタイムのバージョン |
Go | heroku/go | ドキュメント | ランタイムのバージョン |
デフォルトでは、これらの buildpack は一致が検出されるまでこの順に検索され、アプリのコンパイルに使用されます。ビルドに成功した場合、検出された buildpack は今後のアプリケーションへのプッシュ用に永続的に設定されます (以下に説明するように heroku buildpacks:set
を手動で実行した場合と同じです)。
Heroku で正式にサポートされている buildpack の対象とならない言語またはフレームワークをサポートするために、カスタム buildpack を使用することができます。既知のサードパーティ buildpack については、「サードパーティ buildpack の使用」を参照してください。
アプリケーションでの buildpack の設定
アプリケーションによって使用される buildpack は、buildpack 値を設定することによって変更できます。 アプリケーションが次回プッシュされるとき、新しい buildpack が使用されます。
$ heroku buildpacks:set heroku/php
Buildpack set. Next release on random-app-1234 will use heroku/php.
Run `git push heroku master` to create a new release using this buildpack.
アプリの作成中に buildpack を指定することもできます。
$ heroku create myapp --buildpack heroku/python
app.json
での buildpack の設定
buildpack を app.json
内で明示的に設定することで、Heroku ボタンによって作成されるアプリケーションがカスタム buildpack を使用できるようにすることが可能です。
アプリからの buildpack の削除:
アプリから buildpack を簡単に削除できます。
$ heroku buildpacks:remove heroku/nodejs
buildpack がアプリケーションに設定されていない場合、次回の git push heroku
の実行時に検出プロセスが再実行されます。
検出の失敗
設定された buildpack が (検出スクリプト)で定義したとおりに) アプリを処理できない場合、エラーを受け取ります。たとえば、Heroku の Ruby buildpack はアプリケーションの種類を正しく特定するために、アプリケーションのルートフォルダに Gemfile
が存在することを想定していますが、アプリケーションの buildpack が heroku/ruby
に設定されて Gemfile
が存在しない場合、アプリケーションはビルドに失敗します。
この状況は、以前にアプリケーションのタイプの自動検出 (つまりアプリケーションでの検出される buildpack の自動設定) の原因となったファイルを、削除または名前変更した場合に発生することもあります。
たとえば、PHP で記述されたアプリケーションをプッシュするとき、そのアプリケーションに、composer.json
の他にアセット処理のための NPM パッケージと共に package.json
が含まれていた場合、アプリケーションはデフォルトの buildpack が検出のために呼び出される順序が原因で、最初のプッシュで Node.js アプリケーションとして検出されます。
この場合に package.json
を削除してもアプリケーションに使用される buildpack は自動的に再設定されず、buildpack は heroku/nodejs
に「ピン留め」され、package.json
がない状態で git push
を試行すると次のエラーとなります。
-----> Using set buildpack heroku/nodejs
! Push rejected, failed to detect set buildpack heroku/nodejs
ここでは手動で buildpack を消去するか目的の buildpack を設定する (この例では heroku/php
に設定する) 必要があります。
正式な buildpack の使用
Heroku による buildpack の自動検出が不十分な場合、または複数の buildpack が必要な場合、次のようなコマンドを実行することによって、デフォルトの buildpack の 1 つを実行するようアプリを設定できます。
$ heroku buildpacks:set heroku/ruby
Buildpack set. Next release on random-app-1234 will use heroku/ruby.
Run `git push heroku master` to create a new release using this buildpack.
この例では Heroku に対し、次回のデプロイ時に (変更しない限りそれ以降の毎回のデプロイ時に) 正式な Ruby buildpack の最新のリリースバージョンを使用するように強制できます。heroku/ruby
の代わりに、上記の正式な buildpack の表に一覧表示されている他の省略表現識別子を使用することもできます。
省略表現の形式では、#
表記による buildpack のブランチ、タグ、またはバージョンの指定がサポートされません。正式な buildpack の最新バージョン以外が必要な場合は、buildpack URL を使用する必要があります。
サードパーティ buildpack の使用
Heroku の正式な buildpack がアプリの要件をサポートしない場合、何百種類ものサードパーティ製のカスタム buildpack が Elements Marketplace または CLI 経由で入手できます。 検索するには、次を実行します。
$ heroku buildpacks:search elixir
Buildpack Category Description
─────────────── ───────── ───────────────────────────
hashnuke/elixir languages Heroku Buildpack for Elixir
$ heroku buildpacks:info hashnuke/elixir
description: Heroku Buildpack for Elixir
category: languages
license: MIT License
support: https://github.com/HashNuke/heroku-buildpack-elixir/issues
source: https://github.com/HashNuke/heroku-buildpack-elixir
readme:
$ heroku buildpacks:set hashnuke/elixir
Buildpack set. Next release on agile-plains-12843 will use hashnuke/elixir.
Run git push heroku master to create a new release using this buildpack.
サードパーティ buildpack には Heroku で管理されていないソフトウェアが含まれており、これらは Heroku によって正式にサポートされていません。使用する buildpack のソースを検査し、作業を慎重に進めてください。
新しいアプリを作成するとき、buildpack のネームスペース/名前またはサードパーティ buildpack の Git URL を指定できます。
$ heroku create myapp --buildpack https://github.com/some/buildpack.git
既存のアプリについても同様に実行できます。
$ heroku buildpacks:set https://github.com/some/buildpack.git -a myapp
buildpack の URL にタグまたはブランチをオプションで指定できます (外部コードを使用する場合に好ましい安全対策です)。
$ heroku buildpacks:set https://github.com/some/buildpack.git#01applications
正式な buildpack の完全な Git URL を指定することもできます。こうすることで、最新リリースバージョンの代わりに buildpack の master
Git ブランチが使用されます。最新の Git バージョンには予期しない変更が含まれていることがあるため、正式な buildpack の heroku/…
構文を使用することを強くお勧めします。
次のコマンドにより、アプリのデフォルトの Heroku buildpack を使用するように戻すことができます。
$ heroku buildpacks:clear
buildpack の参照
buildpack 値は Git リポジトリまたは TAR 書庫の URL のいずれかを指し示すことができます。buildpack を S3 上でホストすることは、buildpack の高可用性を保持するための良い方法であることがあります。
使用する buildpack のソースが Git リポジトリにある場合、buildpacks:set
コマンドを呼び出すときに Git オブジェクト (コミットの SHA、ブランチ名、タグ名など) を URL に追加することによって、使用する buildpack の特定のタグまたはブランチを指定することができます。たとえば次のようになります。
-
https://github.com/heroku/heroku-buildpack-nodejs.git#somedevbranch
-
https://github.com/heroku/heroku-buildpack-ruby.git#v9861
複数の buildpack の使用
アプリケーションのビルド時に単一の buildpack では十分ではないシナリオが多数存在します。典型的なシナリオとしては、PgBouncer を使用したデータベース接続プールや、Ruby、Python、または PHP アプリケーションと組み合わせた Node.js ライブラリを使用したアセット処理などがあります。
このような場合、「Using Multiple Buildpacks for an App」(アプリのための複数の buildpack の使用) のガイドに従ってください。
buildpack の作成
Heroku でまだサポートされていない言語またはフレームワークを使用する場合、カスタム buildpack を作成できます。作業を開始するには、次の記事を参照してください。
- buildpack の構造について学習するには、「Buildpack API」を参照してください。
ビルドマニフェスト
ビルドマニフェスト (ソース管理にチェックインしてパッケージのインストールを容易にするもの) を作成する場合は、heroku.yml の詳細を確認してください。
その他のコンパイルおよびデプロイ方法
- Herokuに直接 docker イメージをデプロイできます。
- プラットフォーム API を介して slug を手動で作成およびデプロイできます。