Skip Navigation
Show nav
Heroku Dev Center
  • Get Started
  • ドキュメント
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
  • ドキュメント
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku のアーキテクチャ
    • Dyno (アプリコンテナ)
    • スタック (オペレーティングシステムイメージ)
    • ネットワーキングと DNS
    • プラットフォームポリシー
    • プラットフォームの原則
  • コマンドライン
  • デプロイ
    • Git を使用したデプロイ
    • Docker によるデプロイ
    • デプロイ統合
  • 継続的デリバリー
    • 継続的統合
  • 言語サポート
    • Node.js
    • Ruby
      • Bundler の使用
      • Rails のサポート
    • Python
      • Django の使用
      • Python でのバックグランドジョブ
    • Java
      • Maven の使用
      • Java でのデータベース操作
      • Play Framework の使用
      • Java の高度なトピック
      • Spring Boot の使用
    • PHP
    • Go
      • Go の依存関係管理
    • Scala
    • Clojure
  • データベースとデータ管理
    • Heroku Postgres
      • Postgres の基礎
      • Postgres のパフォーマンス
      • Postgres のデータ転送と保持
      • Postgres の可用性
      • Postgres の特別なトピック
    • Heroku Redis
    • Apache Kafka on Heroku
    • その他のデータストア
  • モニタリングとメトリクス
    • ログ記録
  • アプリのパフォーマンス
  • アドオン
    • すべてのアドオン
  • 共同作業
  • セキュリティ
    • アプリのセキュリティ
    • ID と認証
    • コンプライアンス
  • Heroku Enterprise
    • Private Space
      • インフラストラクチャネットワーキング
    • Enterprise Accounts
    • Enterprise Team
    • Heroku Connect (Salesforce 同期)
    • シングルサインオン (SSO)
  • パターンとベストプラクティス
  • Heroku の拡張
    • Platform API
    • アプリの Webhook
    • Heroku Labs
    • アドオンのビルド
      • アドオン開発のタスク
      • アドオン API
      • アドオンのガイドラインと要件
    • CLI プラグインのビルド
    • 開発ビルドパック
    • Dev Center
  • アカウントと請求
  • トラブルシューティングとサポート
  • Heroku のアーキテクチャ
  • buildpack

buildpack

日本語 — Switch to English

この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。

最終更新日 2019年09月20日(金)

Table of Contents

  • 正式にサポートされる buildpack
  • アプリケーションでの buildpack の設定
  • 正式な buildpack の使用
  • サードパーティ buildpack の使用
  • 複数の buildpack の使用
  • buildpack の作成
  • ビルドマニフェスト
  • その他のコンパイルおよびデプロイ方法

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 を手動で作成およびデプロイ​できます。

関連カテゴリー

  • Heroku のアーキテクチャ
設定と環境設定 Heroku と Salesforce プラットフォームを統合する

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Podcasts
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing

Subscribe to our monthly newsletter

Your email address:

  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Heroku Podcasts
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Facebook
  • Instagram
  • Github
  • LinkedIn
  • YouTube
Heroku is acompany

 © Salesforce.com

  • heroku.com
  • Terms of Service
  • Privacy
  • Cookies