Skip Navigation
Show nav
Heroku Dev Center Dev Center
  • Get Started
  • ドキュメント
  • Changelog
  • Search
Heroku Dev Center Dev Center
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
    • .NET
  • ドキュメント
  • 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 in or Sign up
View categories

Categories

  • Heroku のアーキテクチャ
    • コンピューティング (dyno)
      • dyno の管理
      • dyno の概念
      • dyno の動作
      • dyno の参照資料
      • dyno のトラブルシューティング
    • スタック (オペレーティングシステムイメージ)
    • ネットワーキングと DNS
    • プラットフォームポリシー
    • プラットフォームの原則
    • Buildpacks
  • 開発者ツール
    • コマンドライン
    • Heroku の VS Code 拡張機能
  • デプロイ
    • Git を使用したデプロイ
    • Docker によるデプロイ
    • デプロイ統合
  • 継続的デリバリーとインテグレーション
    • 継続的統合
  • 言語サポート
    • Node.js
      • Heroku での Node.js の動作
      • Node.js アプリのトラブルシューティング
      • Node.js の操作
    • Ruby
      • Rails のサポート
      • Bundler の使用
      • Ruby の操作
      • Heroku での Ruby の動作
      • Ruby アプリのトラブルシューティング
    • Python
      • Python の操作
      • Python でのバックグラウンドジョブ
      • Heroku での Python の動作
      • Django の使用
    • Java
      • Heroku での Java の動作
      • Java の操作
      • Maven の使用
      • Spring Boot の使用
      • Java アプリのトラブルシューティング
    • PHP
      • Heroku での PHP の動作
      • PHP の操作
    • Go
      • Go の依存関係管理
    • Scala
    • Clojure
    • .NET
      • Working with .NET
  • データベースとデータ管理
    • Heroku Postgres
      • Postgres の基礎
      • Postgres スターターガイド
      • Postgres のパフォーマンス
      • Postgres のデータ転送と保持
      • Postgres の可用性
      • Postgres の特別なトピック
      • Heroku Postgres への移行
    • Heroku Key-Value Store
    • Apache Kafka on Heroku
    • その他のデータストア
  • AI
    • Working with AI
    • Vector Database
    • Heroku Inference
      • AI Models
      • Heroku Inference Quick Start Guides
      • Inference API
      • Inference Essentials
    • Model Context Protocol
  • モニタリングとメトリクス
    • ログ記録
  • アプリのパフォーマンス
  • アドオン
    • すべてのアドオン
  • 共同作業
  • セキュリティ
    • アプリのセキュリティ
    • ID と認証
      • シングルサインオン (SSO)
    • Private Space
      • インフラストラクチャネットワーキング
    • コンプライアンス
  • Heroku Enterprise
    • Enterprise Accounts
    • Enterprise Team
    • Heroku Connect (Salesforce 同期)
      • Heroku Connect の管理
      • Heroku Connect のリファレンス
      • Heroku Connect のトラブルシューティング
  • パターンとベストプラクティス
  • Heroku の拡張
    • Platform API
    • アプリの Webhook
    • Heroku Labs
    • アドオンのビルド
      • アドオン開発のタスク
      • アドオン API
      • アドオンのガイドラインと要件
    • CLI プラグインのビルド
    • 開発ビルドパック
    • Dev Center
  • アカウントと請求
  • トラブルシューティングとサポート
  • Salesforce とのインテグレーション
  • Heroku のアーキテクチャ
  • Buildpacks
  • クラシック buildpack からの Cloud Native Buildpack の作成

クラシック buildpack からの Cloud Native Buildpack の作成

日本語 — Switch to English

最終更新日 2024年12月03日(火)

Table of Contents

  • 例
  • インストールパック
  • CNB を作成する
  • buildpack.toml を更新する
  • bin/detect をコピーする
  • bin/compile を bin/build にコピーする
  • クラシック変数を削除する
  • $YQ_BUILD_DIR を変更する
  • 環境変数を直接参照する
  • $PATH 操作を削除する
  • キャッシュコピーを削除して早期に終了する
  • CNB レイヤー設定を行う
  • 複数のチップアーキテクチャのサポートを追加する
  • ローカルでのテスト
  • パッケージ化と公開
  • Heroku Fir でのテスト
  • 次のステップ

Heroku の Fir 世代のアプリ​は、新しい buildpack 世代である Cloud Native Buildpack (CNB)​ を使用します。CNB は業界標準のツールと適切に連携するオープンスタンダードおよび仕様です。Cloud Native Buildpack は、クラシック buildpack​ と同じ機能、機能性、優れた開発者エクスペリエンスを提供し、ローカルでの実行機能、堅牢なキャッシング、コンポーザビリティの向上など、いくつかの改善が加えられています。Heroku のクラシック buildpack と Cloud Native Buildpack は設計や主旨は似ていますが、直接的な互換性はありません。そのため、クラシック buildpack は Fir 世代のアプリでの使用はサポートされません。

通常、開発者はコミュニティが作成したクラシック buildpack を使用して、Cedar 世代のアプリでビルドをカスタマイズします。同様のカスタマイズを Fir のビルドに適用するには、同等の CNB を使用する必要があります。同等の Cloud Native Buildpack がまだ存在しない、利用可能なクラシック buildpack は多数あります。この記事では、そのギャップを埋め、既存のクラシック buildpack から Heroku Fir で使用するための CNB を作成するプロセスについて説明することを目的としています。

例

heroku-buildpack-yq​ は、yq​ をダウンロードしてインストールする bash で記述されたシンプルなクラシック buildpack です。yq​ は json、yaml、toml ファイルを解析するバイナリです。執筆時点では、同等の Cloud Native Buildpack はありません。

この buildpack の bin/detect は常に渡されるため、条件ロジックはありません。

#!/usr/bin/env bash
# bin/detect <build-dir>

echo 'yq'
exit 0

この buildpack の bin/compile スクリプトには、以下のようないくつかの機能があります。

  • YQ_VERSION 環境変数による yq バージョン選択
  • yq バイナリをキャッシュして、ビルドごとにインターネットからダウンロードされないようにします。
  • yq バイナリを $PATH に追加して、ランタイムとそれ以降の buildpack の両方でコマンドラインから使用できるようにします。
#!/usr/bin/env bash
# bin/compile <build-dir> <cache-dir> <env-dir>

set -euo pipefail

BUILD_DIR=$1
CACHE_DIR=$2
ENV_DIR=$3
BUILDPACK_DIR=$(cd "$(dirname "$(dirname "${BASH_SOURCE[0]}")")" && pwd)

YQ_BUILD_DIR="$BUILD_DIR/.yq"
YQ_CACHE_DIR="$CACHE_DIR/.yq"

YQ_VERSION="4.44.3"
if [ -f "$ENV_DIR/YQ_VERSION" ]; then
  YQ_VERSION=$(cat "$ENV_DIR/YQ_VERSION")
fi

YQ_URL="https://github.com/mikefarah/yq/releases/download/v${YQ_VERSION}/yq_linux_amd64.tar.gz"

if [[ -f "$YQ_CACHE_DIR/yq-version" ]] && grep -q "$YQ_VERSION" "$YQ_CACHE_DIR/yq-version" ; then
  echo "Using yq $YQ_VERSION from cache"
  cp -R "${YQ_CACHE_DIR}" "${YQ_BUILD_DIR}"
else
  echo "Downloading yq $YQ_VERSION from $YQ_URL"
  mkdir -p "${YQ_BUILD_DIR}"
  curl -sSf --location --retry 3 --retry-connrefused --connect-timeout 10 "${YQ_URL}" | tar -zx -C "${YQ_BUILD_DIR}"
  mv "${YQ_BUILD_DIR}/yq_linux_amd64" "${YQ_BUILD_DIR}/yq"
  printf "%s" "$YQ_VERSION" > "$YQ_BUILD_DIR/yq-version"
  rm -rf "${YQ_CACHE_DIR}"
  cp -R "${YQ_BUILD_DIR}" "${YQ_CACHE_DIR}"
fi

mkdir -p "$BUILD_DIR/.profile.d"
echo "export PATH=\"$HOME/.yq:\$PATH\"" >> "$BUILD_DIR/.profile.d/heroku-buildpack-yq.sh"
echo "export PATH=\"$BUILD_DIR/.yq:\$PATH\"" >> "$BUILDPACK_DIR/export"

同等の yq CNB を生成するには、いくつかの手順を実行する必要があります。

この記事は単なる例であり、すべての buildpack のユースケースを網羅した包括的なガイドではありません。CNB の機能、性能、使用方法をより深く理解するために、チュートリアルや仕様などの公式 CNB ドキュメントを読むことを強くお勧めします。

インストールパック

Cloud Native Buildpack チームは、pack​ という CNB の操作に便利な CLI を提供しています。続行するにはこのツールが必要になります。インストール手順については、こちら​を参照してください。

CNB を作成する

新しい CNB を作成するには、pack​ を使用します。pack buildpack new​ で基本的な骨組みを構築します。

$ pack buildpack new heroku-examples/yq --path buildpack-yq
$ cd buildpack-yq

生成された CNB には、buildpack.toml​ と 2 つの bash スクリプトである bin/detect​ および bin/build​ が含まれます。CNB は任意の言語で記述できますが、変換を簡素化するためにこの CNB では bash を使用します。

buildpack.toml を更新する

pack buildpack new​ で生成された基本的な buildpack.toml​ は、このシナリオで必要とするものとは少し異なります。次のような変更を加えることができます。

  • api​ バージョンを Heroku Fir でサポートされている最新の CNB buildpack API バージョンの 0.10​ に更新します。
  • 古いパックバージョンとの互換性を向上させるために、id = "*"​ を指定して [[stacks]]​ テーブルを追加します。
  • [[targets]]​ を更新して linux/arm64​ と linux/amd64​ の両方を含めます。Heroku Fir アプリは linux/arm64 上で実行されるため、Heroku Fir で使用するには arm64 が必須です。amd64 エントリはオプションですが、CNB をローカルでテストするのに役立ちます。

新しい buildpack.toml は次のようになります。

# buildpack.toml
api = "0.10"

[buildpack]
id = "heroku-examples/yq"
version = "0.0.1"
name = "yq"

[[stacks]]
id = "*"

[[targets]]
os = "linux"
arch = "arm64"

[[targets]]
os = "linux"
arch = "amd64"

bin/detect をコピーする

yq​ Heroku クラシック buildpack の bin/detect は常に exit 0​ を渡すため、Cloud Native Buildpack 仕様と完全に互換性があります。yq Heroku クラシック buildpack から yq Cloud Native Buildpack に bin/detect​ をコピーできます。

#!/usr/bin/env bash
# bin/detect

echo 'yq'
exit 0

bin/compile を bin/build にコピーする

Cloud Native Buildpack の仕様で、bin/build​ はビルドプロセスを開始するためのエントリポイントです。このエントリポイントは、bin/compile​ を使用する Heroku のクラシック buildpack API​ とは異なります。クラシック buildpack から CNB の bin/build に bin/compile​ をコピーします。

#!/usr/bin/env bash
# bin/build

set -euo pipefail

BUILD_DIR=$1
CACHE_DIR=$2
ENV_DIR=$3
BUILDPACK_DIR=$(cd "$(dirname "$(dirname "${BASH_SOURCE[0]}")")" && pwd)

YQ_BUILD_DIR="$BUILD_DIR/.yq"
YQ_CACHE_DIR="$CACHE_DIR/.yq"

YQ_VERSION="4.44.3"
if [ -f "$ENV_DIR/YQ_VERSION" ]; then
  YQ_VERSION=$(cat "$ENV_DIR/YQ_VERSION")
fi

YQ_URL="https://github.com/mikefarah/yq/releases/download/v${YQ_VERSION}/yq_linux_amd64.tar.gz"

if [[ -f "$YQ_CACHE_DIR/yq-version" ]] && grep -q "$YQ_VERSION" "$YQ_CACHE_DIR/yq-version" ; then
  echo "Using yq $YQ_VERSION from cache"
  cp -R "${YQ_CACHE_DIR}" "${YQ_BUILD_DIR}"
else
  echo "Downloading yq $YQ_VERSION from $YQ_URL"
  mkdir -p "${YQ_BUILD_DIR}"
  curl -sSf --location --retry 3 --retry-connrefused --connect-timeout 10 "${YQ_URL}" | tar -zx -C "${YQ_BUILD_DIR}"
  mv "${YQ_BUILD_DIR}/yq_linux_amd64" "${YQ_BUILD_DIR}/yq"
  printf "%s" "$YQ_VERSION" > "$YQ_BUILD_DIR/yq-version"
  rm -rf "${YQ_CACHE_DIR}"
  cp -R "${YQ_BUILD_DIR}" "${YQ_CACHE_DIR}"
fi

mkdir -p "$BUILD_DIR/.profile.d"
echo "export PATH=\"$HOME/.yq:\$PATH\"" >> "$BUILD_DIR/.profile.d/heroku-buildpack-yq.sh"
echo "export PATH=\"$BUILD_DIR/.yq:\$PATH\"" >> "$BUILDPACK_DIR/export"

クラシック変数を削除する

クラシック buildpack の一部のディレクトリ変数は、CNB のコンテキストでは不要です。$BUILD_DIR​、$CACHE_DIR​、$ENV_DIR​、$BUILDPACK_DIR​、$YQ_CACHE_DIR​ 宣言は削除できるため、bin/build​ は次のようになります。

#!/usr/bin/env bash
# bin/build

set -euo pipefail

YQ_BUILD_DIR="$BUILD_DIR/.yq"

YQ_VERSION="4.44.3"
if [ -f "$ENV_DIR/YQ_VERSION" ]; then
  YQ_VERSION=$(cat "$ENV_DIR/YQ_VERSION")
fi

YQ_URL="https://github.com/mikefarah/yq/releases/download/v${YQ_VERSION}/yq_linux_amd64.tar.gz"

if [[ -f "$YQ_CACHE_DIR/yq-version" ]] && grep -q "$YQ_VERSION" "$YQ_CACHE_DIR/yq-version" ; then
  echo "Using yq $YQ_VERSION from cache"
  cp -R "${YQ_CACHE_DIR}" "${YQ_BUILD_DIR}"
else
  echo "Downloading yq $YQ_VERSION from $YQ_URL"
  mkdir -p "${YQ_BUILD_DIR}"
  curl -sSf --location --retry 3 --retry-connrefused --connect-timeout 10 "${YQ_URL}" | tar -zx -C "${YQ_BUILD_DIR}"
  mv "${YQ_BUILD_DIR}/yq_linux_amd64" "${YQ_BUILD_DIR}/yq"
  printf "%s" "$YQ_VERSION" > "$YQ_BUILD_DIR/yq-version"
  rm -rf "${YQ_CACHE_DIR}"
  cp -R "${YQ_BUILD_DIR}" "${YQ_CACHE_DIR}"
fi

mkdir -p "$BUILD_DIR/.profile.d"
echo "export PATH=\"$HOME/.yq:\$PATH\"" >> "$BUILD_DIR/.profile.d/heroku-buildpack-yq.sh"
echo "export PATH=\"$BUILD_DIR/.yq:\$PATH\"" >> "$BUILDPACK_DIR/export"

$YQ_BUILD_DIR を変更する

通常、クラシック buildpack では buildpack アーティファクトがネストされたビルドディレクトリに保存されます (この例では YQ_BUILD_DIR="$BUILD_DIR/.yq"​)。Cloud Native Buildpack では、アーティファクトの保存方法が少し異なります。buildpack ファイルは /layers/​ にネストされたディレクトリとして「layers」に保存されます。

$YQ_BUILD_DIR​ の割り当てを YQ_BUILD_DIR="${CNB_LAYERS_DIR}/yq"​ に更新します。これは /layers/heroku-examples_yq/yq/​ に解決されます。bin/build​ スクリプトは次のようになります。

#!/usr/bin/env bash
# bin/build

set -euo pipefail

YQ_BUILD_DIR="${CNB_LAYERS_DIR}/yq"

YQ_VERSION="4.44.3"
if [ -f "$ENV_DIR/YQ_VERSION" ]; then
  YQ_VERSION=$(cat "$ENV_DIR/YQ_VERSION")
fi

YQ_URL="https://github.com/mikefarah/yq/releases/download/v${YQ_VERSION}/yq_linux_amd64.tar.gz"

if [[ -f "$YQ_CACHE_DIR/yq-version" ]] && grep -q "$YQ_VERSION" "$YQ_CACHE_DIR/yq-version" ; then
  echo "Using yq $YQ_VERSION from cache"
  cp -R "${YQ_CACHE_DIR}" "${YQ_BUILD_DIR}"
else
  echo "Downloading yq $YQ_VERSION from $YQ_URL"
  mkdir -p "${YQ_BUILD_DIR}"
  curl -sSf --location --retry 3 --retry-connrefused --connect-timeout 10 "${YQ_URL}" | tar -zx -C "${YQ_BUILD_DIR}"
  mv "${YQ_BUILD_DIR}/yq_linux_amd64" "${YQ_BUILD_DIR}/yq"
  printf "%s" "$YQ_VERSION" > "$YQ_BUILD_DIR/yq-version"
  rm -rf "${YQ_CACHE_DIR}"
  cp -R "${YQ_BUILD_DIR}" "${YQ_CACHE_DIR}"
fi

mkdir -p "$BUILD_DIR/.profile.d"
echo "export PATH=\"$HOME/.yq:\$PATH\"" >> "$BUILD_DIR/.profile.d/heroku-buildpack-yq.sh"
echo "export PATH=\"$BUILD_DIR/.yq:\$PATH\"" >> "$BUILDPACK_DIR/export"

環境変数を直接参照する

クラシック buildpack では、環境変数はファイルとして $ENV_DIR​ に保存されますが、CNB の場合はよりシンプルです。環境変数を環境から直接読み取ることができるため、yq のバージョン検出ロジックが大幅に簡素化されます。次のブロックを変更します。

YQ_VERSION="4.44.3"
if [ -f "$ENV_DIR/YQ_VERSION" ]; then
  YQ_VERSION=$(cat "$ENV_DIR/YQ_VERSION")
fi

変更後は次のようになります。

YQ_VERSION="${YQ_VERSION:-4.44.3}"-

$PATH 操作を削除する

Cloud Native Buildpack 仕様は自動的にレイヤーディレクトリ内の bin​ ディレクトリを $PATH​ 環境変数に追加します。yq​ バイナリを ${CNB_LAYERS_DIR/yq/bin/​ にインストールするため、CNB の実装ではカスタムコードなしで yq​ を $PATH​ に追加します。$PATH​ 操作と Heroku クラシック buildpack の .profile.d​ の行は CNB では必要ありません。これらの行を削除すると、bin/build は次のようになります。

#!/usr/bin/env bash
# bin/build

set -euo pipefail

YQ_BUILD_DIR="${CNB_LAYERS_DIR}/yq"

YQ_VERSION="${YQ_VERSION:-4.44.3}"

YQ_URL="https://github.com/mikefarah/yq/releases/download/v${YQ_VERSION}/yq_linux_amd64.tar.gz"

if [[ -f "$YQ_CACHE_DIR/yq-version" ]] && grep -q "$YQ_VERSION" "$YQ_CACHE_DIR/yq-version" ; then
  echo "Using yq $YQ_VERSION from cache"
  cp -R "${YQ_CACHE_DIR}" "${YQ_BUILD_DIR}"
else
  echo "Downloading yq $YQ_VERSION from $YQ_URL"
  mkdir -p "${YQ_BUILD_DIR}"
  curl -sSf --location --retry 3 --retry-connrefused --connect-timeout 10 "${YQ_URL}" | tar -zx -C "${YQ_BUILD_DIR}"
  mv "${YQ_BUILD_DIR}/yq_linux_amd64" "${YQ_BUILD_DIR}/yq"
  printf "%s" "$YQ_VERSION" > "$YQ_BUILD_DIR/yq-version"
  rm -rf "${YQ_CACHE_DIR}"
  cp -R "${YQ_BUILD_DIR}" "${YQ_CACHE_DIR}"
fi

キャッシュコピーを削除して早期に終了する

Cloud Native Buildpack ではキャッシュの動作が大幅に異なります。キャッシュされたファイルは、個々のキャッシュディレクトリ間でコピーする必要はありません。キャッシュされたレイヤー内のキャッシュされたファイルはビルド中に使用できます。したがって、次の行は削除できます。

  • cp -R "${YQ_CACHE_DIR}" "${YQ_BUILD_DIR}"
  • rm -rf "${YQ_CACHE_DIR}"
  • cp -R "${YQ_BUILD_DIR}" "${YQ_CACHE_DIR}"​

キャッシュされたファイルが検出されたときに早期に終了するように if 条件を変更することもできます。その後、bin/build​ は次のようになります:

#!/usr/bin/env bash
# bin/build

set -euo pipefail

YQ_BUILD_DIR="${CNB_LAYERS_DIR}/yq"

YQ_VERSION="${YQ_VERSION:-4.44.3}"

YQ_URL="https://github.com/mikefarah/yq/releases/download/v${YQ_VERSION}/yq_linux_amd64.tar.gz"

if [[ -f "$YQ_CACHE_DIR/yq-version" ]] && grep -q "$YQ_VERSION" "$YQ_CACHE_DIR/yq-version" ; then
  echo "Using yq $YQ_VERSION from cache"
  exit 0
fi

echo "Downloading yq $YQ_VERSION from $YQ_URL"
mkdir -p "${YQ_BUILD_DIR}"
curl -sSf --location --retry 3 --retry-connrefused --connect-timeout 10 "${YQ_URL}" | tar -zx -C "${YQ_BUILD_DIR}"
mv "${YQ_BUILD_DIR}/yq_linux_amd64" "${YQ_BUILD_DIR}/yq"
printf "%s" "$YQ_VERSION" > "$YQ_BUILD_DIR/yq-version"

CNB レイヤー設定を行う

CNB レイヤーには、いつどのように使用可能にするのかを決定する 3 つのオプションがあります。これらのオプションは .toml ファイルで設定する必要があります。bin/build の末尾に次を追加します。

cat > "${YQ_BUILD_DIR}.toml" << EOL
[types]
build = true
cache = true
launch = true
EOL

build = true​ オプションにより、レイヤーと yq​ バイナリは、この後に実行される buildpack で使用可能になります。cache = true​ オプションにより、レイヤーのコンテンツがどちらもキャッシュに保持され、ビルドごとにキャッシュから復元されます。launch = true​ オプションにより、yq​ は生成されたイメージが起動すると使用可能になります。

複数のチップアーキテクチャのサポートを追加する

Heroku Fir アプリは arm64​ インスタンスで実行されますが、Heroku クラシックは amd64​ インスタンスで実行されます。クラシック buildpack では後者のみがサポートされています。$CNB_TARGET_ARCH​ から読み取り可能なアーキテクチャに基づいて $YQ_URL​ を条件付きに更新することで、amd64​ を追加します。更新された $YQ_URL​ の割り当ては次のようになります。

YQ_URL="https://github.com/mikefarah/yq/releases/download/v${YQ_VERSION}/yq_linux_${CNB_TARGET_ARCH}.tar.gz"

ローカルでのテスト

この時点で、bin/build​ は稼働できる状態となり、次のようになります。

#!/usr/bin/env bash
set -euo pipefail

YQ_BUILD_DIR="${CNB_LAYERS_DIR}/yq"
YQ_VERSION="${YQ_VERSION:-4.44.3}"
YQ_URL="https://github.com/mikefarah/yq/releases/download/v${YQ_VERSION}/yq_linux_${CNB_TARGET_ARCH}.tar.gz"

if [[ -f "$YQ_BUILD_DIR/yq-version" ]] && grep -q "$YQ_VERSION" "$YQ_BUILD_DIR/yq-version" ; then
  echo "Using yq $YQ_VERSION from cache"
  exit 0;
fi

echo "Downloading yq $YQ_VERSION from $YQ_URL"
rm -rf "${YQ_BUILD_DIR}"
mkdir -p "${YQ_BUILD_DIR}"
curl -sSf --location --retry 3 --retry-connrefused --connect-timeout 10 "${YQ_URL}" | tar -zx -C "${YQ_BUILD_DIR}"
mkdir -p "${YQ_BUILD_DIR}/bin"
mv "${YQ_BUILD_DIR}/yq_linux_${CNB_TARGET_ARCH}" "${YQ_BUILD_DIR}/bin/yq"
printf "%s" "$YQ_VERSION" > "${YQ_BUILD_DIR}/yq-version"
cat > "${YQ_BUILD_DIR}.toml" << EOL
[types]
build = true
cache = true
launch = true
EOL

pack コマンドを使用してローカルで試します。

$ pack build yq-cnb-test --buildpack ./buildpack-yq --builder heroku/builder:24

24: Pulling from heroku/builder
Digest: sha256:2324afe304202e81d452bb203eb4edcc7fed682840d0ec3c82f11fdba96cc199
Status: Image is up to date for heroku/builder:24
24: Pulling from heroku/heroku
Digest: sha256:613aa12fc84c16054be6a9501578e06948d76363e2921e4326447fd0e5a770cf
Status: Image is up to date for heroku/heroku:24
===> ANALYZING
Image with name "yq-cnb-test" not found
===> DETECTING
heroku-examples/yq 0.0.1
===> RESTORING
===> BUILDING
Downloading yq 4.44.3 from https://github.com/mikefarah/yq/releases/download/v4.44.3/yq_linux_arm64.tar.gz
===> EXPORTING
Adding layer 'heroku-examples/yq:yq'
Adding layer 'buildpacksio/lifecycle:launch.sbom'
Added 1/1 app layer(s)
Adding layer 'buildpacksio/lifecycle:launcher'
Adding layer 'buildpacksio/lifecycle:config'
Adding label 'io.buildpacks.lifecycle.metadata'
Adding label 'io.buildpacks.build.metadata'
Adding label 'io.buildpacks.project.metadata'
no default process type
Saving yq-cnb-test...
*** Images (96fff73ff596):
      yq-cnb-test
Adding cache layer 'heroku-examples/yq:yq'
Successfully built image yq-cnb-test

このコマンドはイメージをビルドし、結果をローカルの Docker デーモンに保存します。結果のイメージを調べて、yq が機能することを確認します。

$ docker run -it --rm yq-cnb-test yq --version
yq (https://github.com/mikefarah/yq/) version v4.44.3

パッケージ化と公開

pack buildpack package コマンドを使用して、より広範囲に使用できるように buildpack をパッケージ化します。

$ pack buildpack package buildpack-yq --format file
Successfully created package buildpack-yq.cnb and saved to file

CNB パッケージは、パブリックアクセスが可能な場所にアップロードする必要があります。サンプルの CNB ファイルはこちら​の GitHub にあります。

Heroku Fir でのテスト

ローカルで検証してアップロードした後、Heroku Fir プラットフォームで CNB をテストします。新しいディレクトリに新しいアプリを作成します。

$ mkdir yq-cnb-test-app
$ cd yq-cnb-test-app
$ git init
$ heroku apps:create yq-cnb-test --space <your-fir-space>

次に、CNB の URL を参照する project.toml を作成して、カスタム buildpack を設定します。

# project.toml
[_]
schema-version = "0.2"

[[io.buildpacks.group]]
id = "heroku-examples/yq"
uri = "https://github.com/heroku-examples/buildpack-yq/releases/download/v0.0.1/buildpack-yq.cnb"

変更をコミットし、通常どおり Heroku アプリをデプロイします。

$ git add -A
$ git commit -m "Add custom yq buildpack"
$ git push heroku main
Enumerating objects: 3481, done.
Counting objects: 100% (3481/3481), done.
Delta compression using up to 14 threads
Compressing objects: 100% (1954/1954), done.
Writing objects: 100% (3481/3481), 7.91 MiB | 8.61 MiB/s, done.
Total 3481 (delta 1329), reused 3477 (delta 1328), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (1329/1329), done.
remote: Updated 1300 paths from 5dfc83a
remote: Compressing source files... done.
remote: Building source:
remote: Waiting on build...
remote: Waiting on build... (elapsed: 19s)
remote: Extracting source
remote: Downloading buildpack https://github.com/heroku-examples/buildpack-yq/releases/download/v0.0.1/buildpack-yq.cnb
remote: Image with name "yq-cnb-test/builds" not found
remote: heroku-examples/yq 0.0.1
remote: Downloading yq 4.44.3 from https://github.com/mikefarah/yq/releases/download/v4.44.3/yq_linux_arm64.tar.gz
remote: Adding layer 'heroku-examples/yq:yq'
remote: Adding layer 'buildpacksio/lifecycle:launch.sbom'
remote: Added 1/1 app layer(s)
remote: Adding layer 'buildpacksio/lifecycle:launcher'
remote: Adding layer 'buildpacksio/lifecycle:config'
remote: Adding label 'io.buildpacks.lifecycle.metadata'
remote: Adding label 'io.buildpacks.build.metadata'
remote: Adding label 'io.buildpacks.project.metadata'
remote: no default process type
remote: Saving yq-cnb-test/builds...
remote: *** Images (sha256:97f83d6f1a1abf9a5973a8afb44f487e36303607e16aed091a0c264168daef34):
remote:       yq-cnb-test/builds:418d86c2-b29f-4a00-871a-e00db35743d6
remote: Adding cache layer 'heroku-examples/yq:yq'
remote: Uploading cache
remote: Launching...
remote: https://yq-cnb-test-97c732604476.herokuapp.com/ deployed to Heroku
remote: Verifying deploy... done.
To https://git.heroku.com/yq-cnb-test.git
 * [new branch]      main -> main

次のステップ

このガイドのサンプル CNB が公開され、どの Heroku Fir アプリでも使用できるようになりました。ただし、この記事で説明したのは CNB の機能セットの一部についてのみです。Cloud Native Buildpack についての詳細は、以下を参照してください。

  • Cloud Native Buildpack のチュートリアル
  • Cloud Native Buildpack の仕様

関連カテゴリー

  • Buildpacks
公式にサポートされる buildpack buildpack の管理

Information & Support

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

Language Reference

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

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing
  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Github
  • LinkedIn
  • © 2025 Salesforce, Inc. All rights reserved. Various trademarks held by their respective owners. Salesforce Tower, 415 Mission Street, 3rd Floor, San Francisco, CA 94105, United States
  • heroku.com
  • Legal
  • Terms of Service
  • Privacy Information
  • Responsible Disclosure
  • Trust
  • Contact
  • Cookie Preferences
  • Your Privacy Choices