Cedar Private Space から Fir Private Space にアプリを移行する
最終更新日 2025年04月15日(火)
Cedar Private Space から Fir Private Space にアプリを移行する
このガイドは、最小限のダウンタイムでアプリケーションを Cedar 世代で実行されている Heroku Private Spaces から新しい Fir 世代に移行するのに役立ちます。
これらの異なる世代間でアプリを直接転送することはできません。Fir においては、特に Cloud Native Buildpack (CNB) の導入、ARM ベースのインフラストラクチャ、IPv6 のデフォルト採用など、アーキテクチャ上の大きな違いがあるため、アプリは手動で移行する必要があります。
Docker アプリおよび Monorepo アプリは Fir ではサポートされていません。 Shield Space は Fir のロードマップに含まれています。
Cedar 世代と Fir 世代間のすべての該当する違いを確認するには、Heroku の世代に関する記事を参照してください。
Premier または Signature Success Plan の Heroku Enterprise の顧客は、Customer Solutions Architecture (CSA) チームに、移行に関する詳細なガイダンスを要求できます。ここでエキスパートコーチングセッションについて学習するか、または Salesforce の担当者にお問い合わせください。
移行の前に
カスタムメンテナンスページを設定する
既存の Cedar Space アプリのカスタムページを設定して、アプリを移行している間のメンテナンスモード中にユーザーに表示されるようにします。
ダウンタイムの計画
ダウンタイムを最小限に抑えるために、移行の数日前に DNS エントリの TTL 値を 1 分 (60秒) に減らします。移行プロセスには、Fir Space で実行中の新しいアプリを指定するように DNS エントリを更新することが含まれます。DNS の更新を伝播させるための若干のダウンタイムを計画してください。
データを Fir Space 内の Private 層データサービスに移行するときにも、一定期間のダウンタイムが必要です。
Fir に対するアプリケーションの互換性を確認する
移行する前に、Fir プラットフォームの主な特性に対するアプリケーションの互換性を評価します。
Cloud Native Buildpack (CNB): Fir は CNB のみを使用します。クラシック Cedar buildpack を使用するアプリケーションの場合は、CNB を使用するように移行する必要があります。Cloud Native Buildpack を設定する方法を確認し、ビルドプロセスを調整します。
Graviton (ARM) アーキテクチャ: Fir dyno は現在、ARM ベースの Graviton プロセッサー上で実行されます。アプリケーションコードおよびすべての依存関係が ARM アーキテクチャと互換性があることを確認します。x86 固有のバイナリまたは依存関係により、Fir 世代でのデプロイ中にビルドエラーが発生する可能性があります。
デフォルトの IPv6 ネットワーク: Fir Spaces のデフォルトは IPv6 ネットワークです。アプリケーションおよび接続されているサービスが、IPv6 に正しくバインドし、IPv6 経由で動作できることを確認します。
アドオンの可用性と要件を確認する
新しい Fir アプリケーションでアドオンを再プロビジョニングする必要があります。アドオンの可用性と統合は、Fir Space によって異なる場合があります。Heroku Elements Marketplace で Fir Gen Apps
をフィルタリングするか、各アドオンの要素のページで「Supported Generations」(サポート対象の世代) セクションを確認すると、アドオンが Fir と互換性があることを確認できます。
サードパーティの OTel ネイティブの可観測性プラットフォームはすぐに使用できますが、syslog 形式に依存するツールはまだ Fir との互換性がありません。
移行プロセス
次の手順は、Cedar Space から Fir Space への一般的な移行プロセスを説明するものです。
- ダッシュボードから新しい Fir Space を作成するか、
--generation fir
フラグをheroku spaces:create
の CLI コマンドと共に使用して、Fir 世代を指定します。 - 新しいスペース内のダッシュボードまたは CLI から新しい Heroku アプリを作成します。
- コードを調整してデプロイします。アプリケーションのデプロイプロセスを更新して、Fir プラットフォームと互換性のある Cloud Native Buildpack (CNB) を使用するようにします。ビルドプロセスを十分にテストします。CNB 互換コードを新しいアプリにデプロイします。ARM アーキテクチャとの互換性を確認します。
- Fir と互換性のあるアドオンをプロビジョニングし、dyno を拡張します。リソースを自動的に構成するデプロイメソッドを使用した場合は、プロビジョニングされたアドオンと Dyno formation が Fir に対して正しいことを確認します。
- Heroku Data Services を移行します (推奨)。Fir Space 内のアプリは、スペース外のデータサービス (Cedar 環境内のサービスなど) にも接続できますが、これらのサービスを Fir Space に移行すると、ネットワークの分離とセキュリティ上のメリットが得られます。
- Heroku Postgres: ダウンタイムを最小限に抑えるために、フォロワーの切り替え方式を使用します。この方式では、新しいプライベートデータベースがプロビジョニングしているときに既存のデータベースの動作を続行することができます。古いデータベースに関連付けられているデータクリップを新しいデータベースに再割り当てする必要があります。これらのデータクリップを復旧するには、help.heroku.com 経由でサポートチケットを開いてください。
- Heroku Key-Value Store: アプリがメンテナンスモードの間にフォーク方式を使用して移行します。
- Heroku Kafka: メンテナンスモード中にこの手順に従って移行します。
- カスタムドメインと SSL を構成します。一部のアプリでは、ダウンタイムを短縮するために、既存の Cedar Space アプリと新しい Fir Space アプリの両方に同じドメインを一時的に割り当てることが許可される場合があります。新しい Fir アプリに対してこの「ドメイン強制」をリクエストするには、Heroku サポートにお問い合わせください。それができないことが確認されたら、Cedar アプリからカスタムドメインを削除し、メンテナンス期間中に新しい Fir アプリにそれらを追加します。
- DNS を更新します。新しいスペースアプリのエンドポイントを指定するように DNS エントリを更新します。伝播を確認した後、DNS TTL 値を通常の状態に戻します。
- 新しい Fir アプリを監視します。ログを監視してエラーを確認し、パフォーマンスのメトリクスを確認します。
Heroku Postgres を移行した場合、古いデータベースのプロビジョニングを解除する前に、古いデータベースから新しいデータベースにデータクリップを関連付けるようサポートに連絡したことを確認します。
データサービスを移行しておらず、まだ Cedar アプリにアタッチされている場合は、古いアプリを削除しないでください。アプリを削除すると、関連付けられているデータサービスもプロビジョニングが解除され、削除されます。