デプロイ

Angularアプリケーションをリモートサーバーにデプロイする用意をする場合、様々なオプションがあります。

CLIによる自動デプロイ

AngularのCLIコマンドであるng deployはあなたのプロジェクトに紐づいたdeploy CLI builderを実行します。 多数のサードパーティのビルダーが異なるプラットフォームで機能するよう実装しています。 ng addによって、それらのいずれかをあなたのプロジェクトに追加することが可能です。

デプロイ機能が入ったパッケージを追加すると、選択されたプロジェクトに対するdeployセクションを伴うワークスペースの設定(angular.jsonファイル)が自動的に更新されます。 その後、そのプロジェクトにデプロイするためにng deployコマンドを使うことが可能です。

例えば、以下のコマンドはFirebaseにプロジェクトを自動的にデプロイすることが可能です。

      
ng add @angular/fireng deploy
    

コマンドは対話的です。 このケースでは、Firebaseアカウントを持っているか作成しなくてはならず、それを使用して認証しなくてはなりません。 あなたのアプリケーションをビルドし、プロダクションの資材をFirebaseにアップロードする前に、デプロイするFirebaseプロジェクトを選択するよう、本コマンドはあなたを指示します。

以下の表では異なるプラットフォームのデプロイ機能を実装するツールをリストアップしています。 各パッケージのdeployコマンドは異なるコマンドラインオプションを要求します。 以下のパッケージ名に関連付けられたリンクをたどることで、より詳細を読むことができます。

もし自己管理されたサーバーにデプロイする場合や、お気に入りのクラウドプラットフォームのビルダーがない場合、ng deployコマンドを使うことを許容するビルダーを作成するか、アプリケーションを手動でデプロイする方法を学ぶためのこのガイドを読み通すかのどちらかの方法を取る事が可能です。

リモートサーバーへの手動デプロイ

あなたのアプリケーションを手動でデプロイする場合、プロダクションビルドを作成し、出力ディレクトリをwebサーバーかコンテンツデリバリネットワーク(CDN)にコピーしてください。 デフォルトでは、ng buildはproduction設定を使用します。 ビルド設定をカスタマイズする場合、プロダクション最適化がデプロイの前に適用されていることを確認したいかもしれません。

ng buildはデフォルトでdist/my-app/にビルドの中間生成物を出力しますが、このパスは@angular-devkit/build-angular:browserビルダーのoutputPathで設定可能です。 このディレクトリをサーバーにコピーし、そのディレクトリでサービスを動かすよう設定してください。

これは最小限のデプロイの解決法ですが、あなたのアプリケーションをサーバーで正しくサービス提供するためには少数の必要条件があります。

サーバーの設定

このセクションはサーバーであなたのAngularアプリケーションを実行するのに必要かもしれない設定の変更について取り上げます。

ルーティングされたアプリケーションはindex.htmlにフォールバックしなければなりません。

クライアントサイドレンダリングのAngularアプリケーションはすべてのコンテンツが静的でビルド時に生成されるため、静的HTMLサーバーによるサービス提供のための候補としては完璧です。

もしアプリケーションがAngularのルーターを使っているならば、持っていないファイルを要求した時、アプリケーションのホストページ(index.html)を返すよう設定しなければなりません。

ルーティングされたアプリケーションは「ディープリンク」をサポートするべきです。 ディープリンクはアプリケーションの中のコンポーネントへの経路を指定したURLです。 例えば、http://my-app.test/users/42はid42のユーザーを表示するユーザー詳細ページへのディープリンクです。

ユーザーが最初にindexページをロードし、それから起動中のクライアント内からそのURLに移動するのは問題ありません。 Angularのルーターはクライアントサイドでナビゲーションを実行し、新しいHTMLを要求しません。

しかし、電子メール内のディープリンクをクリックしたり、ブラウザのアドレスバーにディープリンクを入力したり、既にディープリンクに紐づけられたページをブラウザでリフレッシュするときさえも、実行しているアプリケーションの外部ですべてブラウザ自身によって処理されます。 Angularのルーターを迂回して、ブラウザは/users/42に対するサーバーへの直接のリクエストを作成します。

静的なサーバーはhttp://my-app.test/に対するリクエストを受け取ると決まってindex.htmlを返します。 しかし、デフォルトでほとんどサーバーはindex.htmlを代わりに返すよう設定されていないかぎりhttp://my-app.test/users/42を拒否して404 - Not Foundエラーを返します。 フォールバックルートを設定するか、サーバー上で404ページをindex.htmlにする設定することで、Angularはディープリンクに関するサービスを提供し、正しいルートを表示することができます。 いくつかのサーバーはこのフォールバックの挙動を"Single-Page Application"(SPA)モードと呼びます。

一度ブラウザがアプリケーションをロードすると、Angularのルーターはどのページにあるのかを判断するためにURLを読み込み、/users/42を正しく表示しようとします。

http://my-app.test/does-not-existのような"本当の"404ページについて、サーバーはいかなる追加の設定も必要としません。 Angularのルーターで実装された404ページは正しく表示されるでしょう。

異なるサーバーからデータをリクエストする(CORS)

アプリケーション自身のホストサーバー以外のサーバーにネットワークリクエストを行う際、Web開発者はクロスオリジンリソース共有エラーに遭遇するかもしれません。 ブラウザはサーバーが明示的に許可していない限りそのようなリクエストを禁止します。

これらのエラーに関してAngularまたはクライアントアプリケーションでできることは何もありません。 サーバーはアプリケーションのリクエストを受け付けるよう設定されていなければなりません。 特定のサーバーでCORSを有効にする方法はenable-cors.orgを読んでください。

プロダクションの最適化

ng buildは特に設定を行わない限りproduction設定を使います。この設定はビルド最適化機能を有効にします。

CLIのビルドオプションとそれらの効果についてより多く知るためにng buildを参照してください。

開発時のみの機能

ng serveを使ってローカルでアプリケーションを起動するとき、Angularは開発用の設定を使用することで、 実行時に以下が使用可能になります:

• expression-changed-after-checkedの検出のような安全な追加のチェック。
• より詳細なエラーメッセージ。
• デバッグ関数およびAngular DevToolsをサポートするグローバルなng変数のような追加のデバッグユーティリティ。

これらの機能は開発中は便利ですが、アプリに追加のコードが必要で、プロダクションでは望まれません。 エンドユーザーのためのバンドルサイズにネガティブな影響を与えないよう、これらの機能を安全に使うために、Angular CLIは プロダクションをバンドリングする際のバンドルから開発時のみのコードを削除します。

ng buildによるアプリケーションのビルドでは最適なバンドルサイズにするために出力からこれらの機能を取り除くproductionをデフォルトで用います。

--deploy-url

--deploy-urlは画像、スクリプト、スタイルシートといった資材のための関連するURLを解決するためのベースとなるパスをコンパイル時に指定するのに使われるコマンドラインオプションです。

      
ng build --deploy-url /my/assets
    

--deploy-urlの効果と目的は<base href>と重なります。両者とも初期のスクリプト、スタイルシート、遅延して読み込まれるスクリプト、cssリソースのために使用できます。

<base href>実行時に一か所で定義することができる<base href>とは違い、--deploy-urlはビルド時にアプリケーションでハードコーディングされる必要があります。 可能であれば<base href>の方が好ましいです。