Azure Developer CLI (azd) では、Azure Functionsへのコードとコンテナーのデプロイがサポートされます。 どちらのモードでも、azure.yaml にある専用の function ホストを使用してください:
- コードデプロイ では、ビルドされた関数コードを zip アーカイブとしてパッケージし、関数アプリにアップロードします。
- コンテナーデプロイは、コンテナー イメージをビルドまたは解決し、必要に応じAzure Container Registry (ACR) に発行し、イメージを実行するように Function App を更新します。
Azure FunctionsとAzure App ServiceはどちらもMicrosoft.Web/sitesリソース プロバイダーを使用し、コンテナーのデプロイ フローは内部メカニズムをいくつか共有します。 ただし、これらは同じazdホストではありません。 Functions は host: function を使用し、Functions独自のパッケージングとリモート ビルドの挙動を持ち、App Service のデプロイ スロット ワークフローは使用しません。
デプロイ モードを選択する
azd は、サービス構成からデプロイ モードを選択します。
| コンフィギュレーション | デプロイ モード |
|---|---|
Docker 以外の language をサポートし、docker.path を持たないソース project |
コードのデプロイ |
language: docker |
コンテナーのデプロイ |
ソース言語を持つ docker.path 値 |
コンテナーのデプロイ |
事前構築済み image |
コンテナーのデプロイ |
プロビジョニングされた関数アプリは、サービス構成と同じモードを使用する必要があります。 関数アプリがコンテナー用に構成されているが、azure.yaml がコードのデプロイを選択した場合、またはその逆の場合、azd deploy はアップロードの前に停止し、不一致を報告します。
関数コードをデプロイする
ソースプロジェクト、サポートされている言語、host: function を指定して、コード ベースの関数サービスを構成します:
services:
api:
project: ./src/api
language: ts
host: function
azd deploy 中に、azd がプロジェクトをビルドし、.funcignore 除外を適用し、zip アーカイブを作成して、Azure Functions デプロイ API を使用してパッケージをアップロードします。
Bicep または Terraform では、コードベースの Function App をプロビジョニングし、azd-service-name にサービス名を指定してタグを付ける必要があります。ただし、azure.yaml 内で resourceName を使用してリソースを識別する場合はこの限りではありません。 コードとしてのインフラストラクチャを使用して、ホスティング プラン、ランタイム、ストレージ、ID、ネットワーク、アプリケーション設定を構成します。
コードのデプロイ用にリモート ビルドを構成する
最上位のサービス remoteBuild プロパティは、Flex 従量課金プランのコード ベースの Function Apps にのみ適用されます。 Azure Functionsが Oryx を使用してアップロードされたパッケージをビルドするかどうかを制御します。
services:
api:
project: ./src/api
language: python
host: function
remoteBuild: true
Flex Consumption の remoteBuild を省略すると、azd は言語とパッケージの内容に基づいて既定値を選択します。
| Language | 既定の動作 |
|---|---|
| JavaScript または TypeScript |
.funcignoreがnode_modulesを除外する場合、または.funcignore ファイルが存在しない場合に、リモート ビルドを使用します。 それ以外の場合は、ローカルにビルドされたパッケージを使用します。 |
| Python | リモート ビルドを使用します。 |
| Go | ローカルでビルドします。 Go Function Apps では、リモート ビルドはサポートされていません。 |
| その他の対応言語 | ローカルでビルドされたパッケージを使用します。 |
JavaScript と TypeScript の場合、明示的に設定された remoteBuild 値は、そのファイルが存在する場合に .funcignore と一致する必要があります。
node_modules が remoteBuild: true を除外する場合は .funcignore を設定します。 パッケージに node_modules が含まれている場合、.funcignore を remoteBuild: false に設定する。
Flex 以外のプランの最上位 remoteBuild プロパティは設定しないでください。 サポートされている別のプランで Oryx ビルドを有効にするには、インフラストラクチャで関数アプリの設定として ENABLE_ORYX_BUILD=true と SCM_DO_BUILD_DURING_DEPLOYMENT=true を構成してください。
コンテナー化された関数をデプロイする
Dockerfile を使用するソース プロジェクトの場合は、language: docker を設定するか、ソース言語を保持して docker.path を指定する。
次の例では、Dockerfile を含む TypeScript プロジェクトを使用します。
services:
api:
project: ./src/api
language: ts
host: function
docker:
path: ./Dockerfile
ローカル プロジェクトを使用せずに事前構築済みイメージをデプロイすることもできます。
services:
api:
host: function
image: myregistry.azurecr.io/functions/api:1.0
既成のイメージを使用する場合は、language を省略するか、docker に設定します。
imageをprojectと組み合わせないでください。
コンテナのデプロイ中に、azd:
- ローカルまたはリモートでイメージをビルドするか、設定された事前ビルド済みイメージを読み込みます。
- 発行が必要な場合は、プロジェクト用に構成された ACR インスタンスにイメージを発行します。
- 関数アプリの
linuxFxVersionをDOCKER|<image>に更新します。 - Function App のメイン サイトに展開します。
最上位のサービス remoteBuild プロパティはコンテナーには適用されません。 ACR タスクを使用してコンテナ イメージをビルドするには、docker.remoteBuild を使用します。
services:
api:
project: ./src/api
language: docker
host: function
docker:
path: ./Dockerfile
remoteBuild: true
コンテナー対応の関数アプリをプロビジョニングする
azd deploy はイメージ参照を更新しますが、コード ベースの関数アプリをコンテナー ベースの関数アプリに変換しません。 インフラストラクチャは、展開前に互換性のあるサイトをプロビジョニングする必要があります。
| Requirement | Details |
|---|---|
| Linux Function App | Azure Functions Premium または専用 (App Service) プランで Linux 関数アプリをプロビジョニングします。 Flex Consumption では、カスタム コンテナーはサポートされていません。 このhost: functionワークフローは、Azure Container Apps でホストされている Azure Functions ではなく、Microsoft.Web/sitesを対象とします。 |
| コンテナー サイトの構成 |
functionapp、linux、containerを含むようにサイトの種類を設定します。
linuxFxVersion値を使用してDOCKER\|<image>を初期化します。
azd deploy がそれを置き換えるため、プレースホルダー画像で十分です。 |
| コンテナー レジストリ | ソースからのビルドを行う場合は、ACR インスタンスをプロビジョニングし、AZURE_CONTAINER_REGISTRY_ENDPOINT インフラストラクチャ出力を通じてそのログイン サーバーを公開するか、docker.registry をそのサービス用に構成します。 完全修飾された事前構築済みのコンポーネント image は、別の発行レジストリなしで直接使用できます。 |
| レジストリ アクセス | 公開が必要な場合、画像を公開するエンティティに、宛先レジストリへのプッシュ アクセスの許可を付与します。 別途、デプロイされたイメージをプルするように Function App を構成します。 プライベート ACR イメージの場合は、Function App のマネージド ID にプル アクセス権を付与し、マネージド ID 資格情報を使用するようにサイトを構成します。 別のプライベート レジストリの場合は、インフラストラクチャで適切なプル資格情報を構成します。 |
| 関数の設定 | Bicepまたは Terraform を使用して、FUNCTIONS_EXTENSION_VERSION、FUNCTIONS_WORKER_RUNTIME、AzureWebJobsStorageなどの必要な設定を構成します。 |
| リソース検出 |
azd-service-name 内のサービス名に一致する値を持つ azure.yaml タグを適用するか、resourceName を明示的に設定します。 |
サービス レベルのfunction設定は、env ホストではサポートされていません。 代わりに、インフラストラクチャで Function App の設定を定義します。
デプロイ スロットについて理解する
azd は、function サービスをメインの Function App サイトに常にデプロイします。 Function App のスロットを検出したり、その入力要求を行ったり、そこにデプロイしたりすることはありません。
AZD_DEPLOY_{SERVICE}_SLOT_NAMEなどの App Service スロット設定は、Function App のデプロイには影響しません。
スロットベースの Functions リリース プロセスが必要な場合は、組み込みの host: function ワークフローの外でスロットとデプロイを管理してください。
関数と App Service ホストの比較
関数とApp Service は Microsoft.Web/sites リソース タイプを共有していますが、ワークロードに合ったホストを選択してください:
| Behavior |
function ホスト |
appservice ホスト |
|---|---|---|
| Workload | イベント駆動型の Azure Functions | Web アプリと API |
| コードのデプロイ | Azure Functions zip デプロイ フローを使用します | App Service デプロイ フローを使用する |
| コンテナーのデプロイ | サイトがコンテナー ベースであることを検証した後、Function App イメージを更新します | サイトがコンテナー対応であることを検証した後に Web アプリ イメージを更新します |
| リモート コード ビルド | Flex Consumption Function Apps のサービス レベルの remoteBuild オプションをサポート |
Functions remoteBuild オプションを使用しません |
| デプロイ スロット | 常にメイン サイトに展開する |
azd App Service スロット ワークフローをサポートします |
サービスレベル env |
サポートされていません。代わりに、インフラストラクチャの Function App 設定を使用してください | インフラストラクチャでアプリの設定を構成する |