Azure Functionsは、ソース管理リポジトリから関数アプリへの変更を継続的にデプロイすることを可能にします。 このワークフローでは、コード更新によってプロジェクトから Azure へのビルド、パッケージング、デプロイメントが行われます。 対応するデプロイプロバイダーやリリース戦略はホスティングプランによって異なります。
| ホスティング プラン | 推奨されるCI/CD提供者 | 展開およびリリースの指針 |
|---|---|---|
| Flex 従量課金 | GitHub Actions または Azure Pipelines | パッケージ展開を使います。 展開スロットはサポートされていません。 CI/CDリリースコントロールを使い、ゼロダウンタイムの展開のために ローリングアップデート を検討しましょう。 |
| Elastic Premium、専用、従量課金 | GitHub Actions または Azure Pipelines | ZIP デプロイを使用しています。 アプリがサポートしている場合は、ステージングスロットにデプロイし、アップデートを検証してからスロットを本番環境に切り替えます。 |
| Azure Container Apps | コンテナビルドおよびデプロイメントのワークフロー | コンテナイメージを展開します。 詳細については、 Azure Container Apps での Azure Functions の概要に関するページを参照してください。 |
この記事の冒頭でホスティングプランを選択すると、機能アプリに適用される継続的デプロイのガイダンスが表示されます。
デプロイメントスロットをサポートするホスティングプランの場合は、本番スロットではなくステージングスロットに継続的デプロイを設定してください。 ステージングで更新を確認し、その後 ステージングスロットを本番環境に切り替えます。 本番スロットに直接接続する場合は、本番レベルのコードのみが統合ブランチに届くようにしてください。
Flex Consumptionの場合は、GitHub ActionsまたはAzure Pipelinesを設定してください。 Flex Consumptionはデプロイスロットをサポートしていないため、デプロイ履歴をソース管理やCI/CDシステムに保持しておき、 悪いデプロイから回復できるようにしましょう。
Azure Container Apps 上の Functions では、コンテナイメージをビルドしてデプロイしてください。 デプロイ スロットは使用できません。 リビジョンを活用し、ゼロダウンタイムリリースのための青緑展開戦略を検討してください。
この記事のデプロイメントセンターのステップは、App Serviceのソース管理統合をサポートする関数型アプリに適用されます。 コンシューマープランでは、この統合はWindowsのみでサポートされています。 Azure CLIを使ってソース管理統合を設定することもできます。
Azure Functions では、アプリへの継続的デプロイのために次のソースがサポートされています。
Azure DevOps のサービスの 1 つである Azure Repos でプロジェクト コードを保持します。 Git と Team Foundation バージョン管理の両方をサポートします。 Azure Pipelines ビルド プロバイダーで使われます。 詳細については、「Azure Repos とは」を参照してください。
関数アプリを外部のGitリポジトリに接続することもできますが、この方法は手動同期が必要です。 デプロイのオプションについて詳しくは、「Azure Functions のデプロイ テクノロジ」をご覧ください。
注意
この記事で説明する継続的デプロイのオプションは、コードのみのデプロイに固有です。 Azure Functions on Azure Container Appsについては、Azure Functions on Azure Container Apps overviewをご覧ください。 プレミアムまたは専用プランでAzure Functionsがホストするカスタムコンテナについては、「コンテナとAzure Functionsで働く」の「コンテナを継続的にAzureにデプロイするのを有効にする」セクションをご覧ください。
Flex ConsumptionはAzure ReposからAzure Pipelinesを使い、GitHubからはGitHub Actionsを使って継続的デプロイをサポートします。 BitbucketやローカルGitのデプロイを含むApp Serviceのソース管理統合はサポートされていません。
Azure Container AppsのFunctionsでは、ソースを希望するリポジトリに保存し、CI/CDワークフローでコンテナイメージを構築しプッシュしてください。 その後、関数アプリを新しいイメージに更新してください。 詳細については、「Azure Container Apps の Functions のデプロイメントと設定」をご覧ください。
要件
Azure の関数のデプロイの単位は関数アプリです。 継続的なデプロイを成功させるには、プロジェクトのディレクトリ構造が、Azure Functions が期待する基本フォルダー構造との互換性を備えている必要があります。 Azure Functions Core Tools、Visual Studio Code、またはVisual Studioを使ってコードプロジェクトを作成すると、Azure Functionsテンプレートが正しいディレクトリ構造のコードプロジェクトを作成します。 関数アプリ内のすべての関数を同時に、同じパッケージにデプロイします。
継続的デプロイを有効にした後、Azureポータル内の関数コードへのアクセスは読み取り専用に設定されます。なぜなら、真実の情報源は別の場所にあるからです。
注意
デプロイ センターでは、インバウンド ネットワーク制限のある関数アプリの継続的デプロイを有効にすることは、サポートされていません。 代わりに、ビルドプロバイダーのワークフローはGitHubやAzure Pipelinesで直接設定してください。 ランナーまたはエージェントは、設定されたアクセス制限の下でアプリのデプロイメントエンドポイントに到達できなければなりません。 エンドポイントがプライベートの場合、ランナーやエージェントもプライベートDNS解決を必要とします。 Azure Pipelinesの場合は、接続されたネットワーク上のセルフホスト型エージェントか、ネットワーク付きのマネージドDevOpsエージェントプールを使いましょう。 GitHub Actionsでは、接続されたネットワーク上のセルフホストランナーか、AzureプライベートネットワーキングでホストされたGitHubホストランナーを使いましょう。
ファンクションアプリに インバウンドネットワーク制限がある場合、ワークフローランナーやエージェントは設定されたアクセス制限の下でアプリのデプロイメントエンドポイントにアクセスできなければなりません。 エンドポイントがプライベートの場合、ランナーやエージェントもプライベートDNS解決を必要とします。 Azure Pipelinesの場合は、接続されたネットワーク上のセルフホスト型エージェントか、ネットワーク付きのマネージドDevOpsエージェントプールを使いましょう。 GitHub Actionsでは、接続されたネットワーク上のセルフホストランナーか、AzureプライベートネットワーキングでホストされたGitHubホストランナーを使いましょう。
CI/CDのワークフローは有効なAzure Functionsコンテナイメージを構築し、そのイメージをコンテナアプリがアクセスできるレジストリにプッシュし、そのイメージからリビジョンを作成する関数アプリを更新する必要があります。 詳細については、「Azure Container Apps の関数アプリを作成する」をご覧ください。
ビルド プロバイダーを選択する
コード プロジェクトのビルドは、デプロイ プロセスの一部です。 具体的なビルド プロセスは、特定の言語スタック、オペレーティング システム、ホスティング プランによって異なります。 ホストによってはローカルでもリモートでも構いません。 詳細については、「リモート ビルド」を参照してください。
重要
セキュリティを強化するためには、Azure PipelinesやGitHub ActionsのようなマネージドIDをサポートするビルドプロバイダーを使いましょう。 App Serviceビルドサービスでは 、基本的な認証を有効にし 、テキストベースの認証情報を使用することが必要です。
Azure Functions では、次のビルド プロバイダーがサポートされています。
Azure Pipelines は、Azure DevOps のサービスの 1 つであり、Azure Repos プロジェクトの既定のビルド プロバイダーです。 また、Azure Pipelines を使用して GitHub からプロジェクトをビルドすることもできます。 Azure Pipelines には、Azure Functions にデプロイするために特別に設計された AzureFunctionApp タスクがあります。 このタスクを使うと、プロジェクトをビルド、パッケージ化、デプロイする方法を制御できます。 Azure Pipelines では、マネージド ID がサポートされています。
ソース管理の統合を有効にする場合は、これらのプロバイダーの長所と制限事項にご留意ください。 特定のプロバイダーを利用するには、リポジトリのソースの種類を変更する必要がある場合があります。
プロジェクトを構築し展開するには、Azure Pipelines または GitHub Actions を使いましょう。 これらのプロバイダーはMicrosoft Entraのアイデンティティをサポートし、Flex Consumption パッケージの展開プロセスを使用しています。
- Azure Repos には Azure Pipelines を使用します。
- GitHubの場合はGitHub Actionsを使いましょう。
App ServiceのビルドサービスはFlex Consumptionには適用されません。
Azure Functionsイメージを構築し、コンテナレジストリにプッシュし、関数アプリを更新して新しいイメージからリビジョンを作成できるコンテナビルドプロバイダーを使いましょう。 エンドツーエンドのGitHub Actionsワークフローについては、「GitHub ActionsでAzure Container Appsにデプロイ」をご覧ください。
継続的なデプロイを構成する
Azureポータルはファンクションアプリのためのデプロイメントセンターを提供し、継続的デプロイの設定を容易にします。 継続的デプロイを構成する詳細な方法は、コードが存在するソース管理リポジトリの種類と、選んだビルド プロバイダーによって異なります。
Azure portal で関数アプリページを参照し、左側のペインにある [デプロイメント] の下の [デプロイセンター] を選択します。
次のサポートされているオプションから、プロジェクト コードが保持されているソース リポジトリの種類を選んでください。
Azure DevOps portal で Azure Pipelines を使用する Azure Repos からのデプロイを定義します。 関数アプリでこれらのデプロイメントを定義しないでください。 Azure ReposからAzure Pipelinesベースのデプロイメントを作成するためのステップバイステップガイドについては、「Azure Pipelinesでの継続配信」をご覧ください。
デプロイが完了すると、サービスは指定されたソースからすべてのコードをアプリにデプロイします。 その時点で、デプロイ ソースの変更により、Azure 内の関数アプリにそれらの変更をデプロイする処理がトリガーされます。
リポジトリ内で継続的デプロイメントを設定するには、以下のいずれかのプロバイダーを使用します:
成功したワークフロー実行ごとに新しいアプリケーションパッケージが展開されます。 Flex Consumptionにはデプロイセンターのソース管理統合が利用できません。
CI/CDのワークフローを設定してコンテナイメージをビルド・プッシュし、そのイメージを関数アプリにデプロイしてください。 イメージが更新されるたびに、Container Apps のリビジョンが作成されます。 詳細については、「GitHub ActionsでAzure Container Appsにデプロイ」をご覧ください。
アプリ作成中の継続的デプロイを有効にする
Azureポータルで関数アプリを作成すると、GitHub Actionsを使ってGitHubから継続的デプロイメントを設定できます。 Create Function AppページのデプロイタブでGitHub Actionsを設定してください。
継続的統合のために別のデプロイソースやビルドプロバイダーを使う場合は、まず関数アプリを作成しましょう。 その後、ポータルに戻り、 デプロイメントセンターで継続的統合を設定します。
Azure Pipelinesの場合は、まず関数アプリを作成し、その後Azure DevOpsでパイプラインを設定してください。
コンテナイメージから関数アプリを作成し、CI/CDワークフローを設定して更新イメージを公開し、リビジョンを作成します。 詳細については、「Azure Container Apps の関数アプリを作成する」をご覧ください。
デプロイの基本認証を無効にする
この節は、App Serviceのデプロイメントエンドポイントを使用するデプロイメントメソッドにのみ適用されます。
場合によっては、ファンクションアプリがデプロイメントエンドポイントへの基本的な認証アクセスを無効にして作成されている場合もあります。 この条件により、デプロイ エンドポイントへのアクセスに Microsoft Entra ID を使用できないすべての方法での発行がブロックされます。 デプロイメントエンドポイントの基本認証を無効にした場合の公開影響は、 Deploy without Basic Authenticationで詳細に説明されています。
重要
基本認証を使う場合、資格情報はクリア テキストで送信されます。 これらの認証情報を保護するためには、基本的な認証を使用する際は暗号化された接続(HTTPS)でのみデプロイメントエンドポイントにアクセスする必要があります。 詳細については、「セキュリティで保護されたデプロイ」を参照してください。
展開エンドポイントの基本認証を有効にするには:
Azure portal で、関数アプリに移動します。
アプリの左側のメニューで、 設定>構成>General 設定を選択します。
[SCM Basic Auth Publishing Credentials]\(SCM 基本認証発行資格情報\) を [オン] に設定し、[保存] を選択します。
SCMの基本認証はフレックス消費パッケージの展開には適用されません。 デフォルトでは、Azure Pipelinesは必要なAzureサービス接続からMicrosoft Entraベアラートークンを使用します。ワークロードのアイデンティティフェデレーションが推奨されます。 GitHub Actionsでは、推奨されているOpenID Connect(OIDC)認証を使用します。 これらの方法はSCMの認証情報公開を避け、基本的な認証よりも安全です。
この基本的な認証設定はFunctions on Azure Container Appsには適用されません。 代わりにCI/CDプロバイダー、コンテナレジストリ、コンテナアプリ間の認証を設定しましょう。