Azure Static Web App を計画する

最終的な目標は、Azure でアプリをホストすることです。 Azure Static Web Apps を使用すると、必要なすべての Azure リソースのプロビジョニングが自動的に行われます。

しかし、アプリをホストする前に、変更を行う際にアプリをビルドするための何かが必要になります。 これらの変更は、リポジトリへのコミットまた pull request によって行われる可能性があります。 Azure Static Web Apps の主な機能は、アプリケーションをビルドして発行するための GitHub Actions ワークフローを設定することです。

Azure Static Web Apps リソースを作成すると、GitHub Actions ワークフローが作成されます。 ワークフローはすぐにトリガーされ、アプリのビルドと発行が行われます。 また、リポジトリ内の監視対象ブランチに変更を加えるたびに、ワークフローがトリガーされます。

Azure スタティック Web アプリケーション

Web アプリのデプロイには、次の 2 つの自動化された側面があります。 1 つ目は、アプリを構成する基になる Azure リソースのプロビジョニングです。 2 つ目は、アプリケーションをビルドして発行する GitHub Actions ワークフローです。

Azure Static Web Apps で Web にアプリを発行すると、Web アプリとスケーラブルな API のホストが高速になります。 また、GitHub Actions によって提供される統合ビルドおよびデプロイ ワークフローが得られます。

Static Web Apps インスタンスを GitHub に接続する

Azure Static Web Apps は、ソース コードが GitHub に存在するアプリケーションをホストするように設計されています。 Static Web Apps インスタンスを作成する場合は、GitHub にサインインし、アプリのコードが含まれているリポジトリを指定します。

また、アプリを自動的にビルドしてデプロイできるように、リポジトリ内に 3 つのフォルダー パスを指定する必要があります。

アプリのビルド出力は、アプリケーションのビルド出力ディレクトリへの相対パスです。 たとえば、ビルドされた資産を my-app フォルダーに出力するアプリが my-app/dist にあるとします。 この場合、この場所には dist を指定します。

GitHub Actions を使用してソース コードから静的資産へ

GitHub リポジトリにはソース コードが格納されているため、発行する前にビルドする必要があります。

Static Web Apps インスタンスを作成すると、Azure によってリポジトリに GitHub Actions ワークフローが作成されます。 このワークフローによって、追跡するように選択したブランチに対して変更内容をプッシュしたり、pull request を作成したりするたびに、アプリがビルドされます。このビルド プロセスにより、ソース コードが静的資産に変換され、Azure によって提供されます。 ビルドが完了すると、アクションによって資産がデプロイされます。

その GitHub アクションはリポジトリの .github/workflows フォルダーに追加されます。 必要に応じて、このファイルを確認または変更できます。 リソースの作成時に入力した設定は、GitHub アクションのファイルに保存されます。

Azure Functions と統合された API

アプリに API が必要な場合は、それを Azure Functions プロジェクトとしてリポジトリ内に実装できます。 API は自動的にデプロイされ、Static Web Apps インスタンスによってホストされます。 アプリをビルドしてデプロイする GitHub Actions ワークフローによって、指定したフォルダーの名前でリポジトリ内の API が検索されます。

通常、API アプリは api または functions という名前のフォルダーに配置しますが、好きな名前を付けることができます。

API がない場合はどうすればよいでしょうか。 心配はありません。 Azure Static Web Apps によって指定したフォルダー内に API が検出されない場合、API は発行されませんが、アプリは発行されます。

フォールバック ルートを処理する

ページを更新すると 404 エラーが表示されます。これは、/products を提供するために、ブラウザーからホスティング プラットフォームに要求が送信されるためです。 products という名前のサーバーに、提供するページはありません。 幸い、これはフォールバック ルートを作成することで簡単に解決できます。 フォールバック ルートは、一致しないすべてのページ要求をサーバーに照合するルートです。

Azure Static Web Apps では、アプリのビルド出力フォルダーにあるオプションの staticwebapp.config.json ファイルに定義されるカスタム ルーティング規則をサポートしています。

ファイル フィルターでパス ワイルドカードが使用されている次の例に示すように、フォールバック ルートを実装する規則を使用するようにアプリを構成できます。

{
  "navigationFallback": {
    "rewrite": "index.html",
    "exclude": ["/images/*.{png,jpg,gif,ico}", "/*.{css,scss,js}"]
  }
}

この規則では、リソースの要求が見つからない場合に index.html を提供し、exclude 式に示す画像と CSS ファイルを除外するように、Azure Static Web Apps に指示します。

ルート ファイルの場所

staticwebapp.config.json ファイルは、Azure Static Web Apps により、既定で output_location にあると想定されます。 staticwebapp.config.json ファイルをビルド プロセスで output_location にコピーする場合は、他に何も行う必要はありません。 ほとんどのプロジェクトでは、output_location は app_location に対して相対的です。

次のステップ

それでは、Azure Static Web Apps に Web アプリを発行するために何が必要でしょうか。 必要なものは GitHub リポジトリのアプリのみです。