最終更新日 2023年12月14日(木)

はじめに

この記事では最新の Heroku スタックを使用するようにアプリをアップグレードする方法について説明します。スタックの概要、使用可能なスタック、アプリケーションで現在使用しているスタックの判別方法については、「スタック」の記事​を参照してください。

Heroku アプリをビルドすると、アプリケーションのソースコードが、取得された依存関係や、言語とフレームワークのようなビルドの出力と共に、slug​ と呼ばれるバンドルにアセンブルされます。この slug は通常、ビルドされた時点のスタックとの互換性しかないため、以前にデプロイされていたアプリは、新しいスタックと互換性を持たせるために再ビルドする必要があります。

既存のアプリのスタックの変更は、標準的なアプリのデプロイと非常によく似たプロセスです。まず、ビルド中に使用されるターゲットスタックで変更を要求するために、アプリのスタック設定が更新されます。次に、新しい slug が作成されてターゲットが新しいスタックと互換性を持つように、新しいビルドをトリガーする必要があります。この新しいビルドは、標準ビルドとまったく同じようにデプロイされます。たとえば、スタックのアップグレードを実行するためのダウンタイムはありません。また、同じ方法でロールバックを実行できます。

一般的なアップグレード戦略

アプリケーションで現在使用しているスタックを特定したら、移行先のスタックを決定する必要があります。通常は、最新の使用可能なスタックに移行することを常にお勧めします。

まず、現在実行中のスタックと移行先のスタックの間でどのような変更点があるかを確認し、変更点ごとに、以前のスタックからのアップグレードに関しての推奨事項を確認する必要があります。「スタック」の記事​のスタック一覧のリンクから、アップグレードに関する注意事項が記載されたスタックごとの詳細ページにアクセスできます。

本番アプリを新しいスタックにアップグレードする前に、まずは、(次のセクションで詳しく説明するように) 新しいスタックでテストアプリを作成するか、既存のステージングアプリまたは開発アプリでアップグレードを試すことを強くお勧めします。

新しいスタックでのアプリのテスト

レビューアプリを使用して目的のスタックでアプリの一時バージョンを作成するか、目的のスタックを使用する新しいアプリを手動で作成してそこにコードをデプロイすることができます。

Review Apps (推奨)

組織でレビューアプリ​を使用する場合は、app.json​ のスタック定義を次のように変更するブランチを作成して新しいスタックをテストすることをお勧めします。

{
   "stack": "heroku-22"
}

このブランチをプッシュし、それに対するプルリクエストを作成すると、アプリは新しいスタックにレビューアプリとしてデプロイされ、そこでアプリを徹底的にテストすることができます。

手動で作成したテストアプリ

既存のアプリケーションから新しいテストアプリを作成して、別のスタックでコードベースをテストすることもできます。

新しいテストアプリの作成

既存のアプリのコードベースから heroku create​ を実行しますが、このとき、別個のテストアプリを別の名前で Git リモートに作成する引数を指定します。

$ heroku create --remote heroku-22 --stack heroku-22 <your app name>-heroku-22

このコマンドは次のことを行います。

• “<your app name>-heroku-22​” という名前の新しいアプリを作成します。
• 新しく作成したアプリのベースイメージを Heroku-22 スタックに設定します。
• “heroku-22​” という名前の新しい Git リモートをセットアップします。

この時点で、Git リポジトリに少なくとも 2 つのリモートが含まれています。既存の本番アプリを指す heroku​ と、作成したばかりの新しいアプリを指す heroku-22​ です。これらのアプリのいずれかに変更をプッシュしても、それぞれの他のアプリには影響しません。

アドオンと環境設定の移行

アプリが完全に機能するためには、アドオン​と環境設定​もミラーリングする必要があります。

既存のアプリのアドオンを一覧表示するには、次のように実行します。

$ heroku addons --remote heroku

表示されたアドオンごとに、対応するアドオンをテストアプリに作成します。

$ heroku addons:create --remote heroku-22 <add-on>

次に、既存のアプリの環境設定と、プロビジョニングしたアドオンによってすでに設定されている新しいアプリの環境設定を調べます。

$ heroku config --shell --remote heroku
…
$ heroku config --shell --remote heroku-22
…

既存のアプリに存在する環境設定で、テストアプリでまだ設定されていないものがあれば、テストアプリで設定します。

$ heroku config:set --remote heroku-22 <name>=<value>

テストアプリのデプロイ

ソースをテストアプリのリモートにプッシュします。

$ git push heroku-22 main
Counting objects: 67, done.
...
-----> Ruby app detected
-----> Compiling Ruby/Rack
...

アプリがデプロイされたら、それが正しく動作していることを確認する必要があります。そうでない場合は、必要な変更を行います。そのスタックバージョンのスタックのアップグレードに関する注意事項に記載されていない問題が発生し、支援が必要な場合は、件名にスタック名を記入してサポートチケットを開きます。

$ heroku open --remote heroku-22
$ heroku logs --remote heroku-22

テストアプリの削除

テストアプリが正しく動作することを検証し終わったら、次のようにしてテストアプリを削除できます。

$ heroku apps:destroy --remote heroku-22

アプリのアップグレード

スタックの設定

Heroku CLI からアップグレードするには、本番アプリで stack:set​ コマンドを使用します。

$ heroku stack:set heroku-22 -a <app name>
Setting stack to heroku-22... done
You will need to redeploy ⬢ <app-name> for the change to take effect.
Run git push heroku main to trigger a new build on ⬢ <app-name>.

以前にビルドしたアプリの場合、これでアプリのスタックがすぐに変更されるわけではありません。変更を有効にするには、(選択したスタックをターゲットにする) 新しいビルドが必要です。コードがデプロイされたことがないアプリ (アドオンのみのアプリなど) の場合、スタックの変更はすぐに有効になるため、新しいデプロイは不要です。

ソースの保留中のリリースに変更がない場合は、変更のない空のコミットを作成して新しいビルドをトリガーできます。

$ git commit --allow-empty -m "Upgrading to heroku-22"
[main 973c3f7] Upgrading to heroku-22

新しいリリースを作成するには、本番アプリにプッシュします。

$ git push heroku main

これで本番アプリが最新のスタックで稼働するようになったので、すべてが想定どおりに動作しているかどうか検証する必要があります。

app.json の更新

app.json​ を使用している場合、レビューアプリと Heroku CI の実行で同じスタックが使用されるよう、このファイルでもスタックを指定する必要があります。

{
   "stack": "heroku-22"
}

パイプラインプロモーション

Heroku Pipelines​ 機能を使用している場合、アプリをプロモート​すると、その slug がターゲットアプリにコピーされ、元のアプリのスタックと一致するようにターゲットアプリのスタックが上書きされます。そのため、ダウンストリーム (本番) アプリで直接、stack:set​ を使用する必要はありません。代わりに、ステージングアプリのスタックをアップグレードし、アプリが期待どおりに実行されていることを検証してから、通常どおりパイプラインプロモーションを実行します。

Dashboard 経由のアップグレード

Heroku Dashboard​ からアップグレードするには、アプリの設定ページに移動して Upgrade Stack​ (スタックのアップグレード) ボタンをクリックします。アップグレードすることを確認すると、スタックが最新バージョンに設定されます。

以前にビルドしたアプリの場合、スタックのアップグレードは保留中であることが示され、アップグレードは次回のデプロイで有効になります。コードがデプロイされたことがないアプリ (アドオンのみのアプリなど) の場合、スタックの変更はすぐに有効になるため、新しいデプロイは不要です。

ロールバック

スタックの変更後にアプリが動作しない場合、カスタマーサポートに連絡して問題のデバッグおよび解決が済むまでスタックを元に戻すことができます。

まず、以前のスタックを使用していた最後のリリースのリリースバージョンが必要です。

$ heroku releases
=== production-app Releases
v13  Deploy 973c3f7                  joe@example.com   2022/06/12 10:55:16
v12  Deploy ddb317d                  jill@example.com  2022/06/09 15:33:59
...

次に、そのリリースにロールバックします。

$ heroku rollback v12

これで、本番アプリは再び以前のスタック上で実行されるようになります。

別の方法として、ロールバック機能を使用しない場合は、heroku stack:set <original-stack-name>​ を使用してスタックを元に戻してから、もう一度デプロイを実行してスタックのダウングレードを完了することができます。

一般的な問題

古い buildpack のバージョン

アプリに対して定義された buildpack は、何通りかの形式の buildpack 参照​を使用して指定できます。特定の buildpack バージョンのタグ/ブランチ/SHA に固定すると、新しいスタックに対応した互換性の修正があっても自動的に適用されず、これが原因で新しいスタックでビルドが失敗する可能性があります。

次を使用して、現在の buildpack を一覧表示します。

$ heroku buildpacks

#​ とそれに続く Git 参照 (例: コミット SHA、ブランチ名、またはタグ名) で終わる buildpack URL がある場合は、バージョンサフィックスを含まない buildpack URL に置き換える必要があります。詳細は、「buildpack の参照​」を参照してください。

サードパーティの buildpack

ほとんどのサードパーティの buildpack が、新しいスタックで動作することを想定しています。アプリでサードパーティの buildpack を使用していて、アプリのビルドに問題が発生した場合、ビルドキャッシュ​を消去することをお勧めします。

$ heroku plugins:install heroku-builds
$ heroku builds:cache:purge

ビルドキャッシュを消去してもうまくいかない場合は、buildpack の GitHub ページで問題をオープンすることをお勧めします。

スタック固有の問題

よく発生する各スタックに固有の問題については、当該スタックの詳細ページの「新着情報」および「アップグレードに関する注意事項」のセクションを参照してください。

• Heroku-20
• Heroku-22