azure-search-openai-demo 容器化部署实战在 Azure Container Apps 上运行 RAG 聊天应用【免费下载链接】azure-search-openai-demoA sample app for the Retrieval-Augmented Generation pattern running in Azure, using Azure AI Search for retrieval and Azure OpenAI large language models to power ChatGPT-style and QA experiences.项目地址: https://gitcode.com/GitHub_Trending/az/azure-search-openai-demo本篇指南聚焦 azure-search-openai-demo 项目的 Azure Container Apps 部署路径完整讲解 azdAzure Developer CLI单 Host 限制下的azure.yaml配置切换、从登录到azd up的六步部署流程、DEPLOYMENT_TARGET与AZURE_CONTAINER_APPS_WORKLOAD_PROFILE两个关键环境变量的底层作用以及工作负载配置文件的选型与私有端点支持现状。读完本文你将能独立完成该 RAG 示例在 Container Apps 上的部署、按需切换回 App Service并理解整套 Bicep 条件资源编排的工作原理。azd 的单 Host 限制为什么azure.yaml里只能有一个部署目标Azure Container Apps 与 Azure App Service 是两种截然不同的托管形态而azd在解析项目清单时存在一个已知限制azure.yaml 文件中只能存在一个host选项。因此该仓库采用了默认启用一种、另一种注释保留的策略。打开仓库根目录的 azure.yaml可以看到 backend 服务的声明第 817 行services: backend: project: ./app/backend language: py # Please check docs/azure_container_apps.md for more information on how to deploy to Azure Container Apps host: containerapp docker: remoteBuild: true # Please check docs/azure_app_service.md for more information on how to deploy to Azure App Service # host: appservice默认情况下host: containerapp生效host: appservice被注释掉。如果你拿到的是旧版本仓库或者希望改用 App Service就需要在这两种 host 之间手动切换对应操作见 docs/azure_app_service.md。值得留意的是不同的 host 会触发不同的 azd hooksappservice对应prepackagehook而containerapp对应prebuildhook两者的执行内容完全一致都是在打包镜像前构建前端hooks: # This hook is called when App Service is the host prepackage: posix: shell: sh run: cd ../frontend;npm install;npm run build # This hook is called when Azure Container Apps is the host prebuild: posix: shell: sh run: cd ../frontend;npm install;npm run build从源码结构看这个设计保证了无论走哪条部署路径前端都会先被编译成静态产物再一并打进后端镜像Dockerfile 中COPY ./ /app即包含构建完成的前端目录。部署到 Azure Container Apps 的完整步骤1. 在 azure.yaml 中确认 host 为 containerapp将 azure.yaml 中host: containerapp保持启用取消注释同时注释掉host: appservice。若此前是 App Service 部署请务必完成这一步否则 azd 会按错误的目标执行部署。2. 登录 Azure 账号azd auth login该命令会弹出浏览器完成 Azure 身份认证认证信息将被 azd 持久化使用。3. 创建新的 azd 环境azd env new输入的名称将直接用作资源组名称。命令会在.azure目录下创建对应文件夹并将其设为后续所有 azd 调用的活动环境。4. 设置部署目标为 containerappsazd env set DEPLOYMENT_TARGET containerapps这一步虽然看似可选因为默认值就是containerapps但显式设置能确保环境变量被写入当前 azd 环境的.env文件避免依赖默认值带来的不确定性。其背后的默认值定义在 infra/main.parameters.jsondeploymentTarget: { value: ${DEPLOYMENT_TARGETcontainerapps} }5.可选按需定制部署这是可以自由发挥的节点通过设置其他 azd 环境变量你可以选择复用现有 Azure 资源、启用可选功能如认证 auth、视觉 vision 等或部署到免费/低成本层级。6. 预配资源并部署代码azd up该命令会完成三件事预配 Azure 资源、将应用部署到这些资源上、并根据./data目录中的文件构建搜索索引postprovisionhook 会依次执行 scripts/auth_update.sh 与 scripts/prepdocs.sh。重要成本提示azd up创建的资源会立即产生费用尤其是 AI Search 资源。即使你在命令完全执行完之前中断这些资源仍可能持续计费。不使用时请运行azd down或手动删除资源以避免不必要的支出。深入 DEPLOYMENT_TARGETBicep 中的条件资源编排DEPLOYMENT_TARGET并非只在 azd 层面生效它会被注入 infra/main.bicep 的参数体系进而决定整套 Bicep 模块的部署分支。核心逻辑如下参数声明infra/main.bicepdeploymentTarget string appservice作为参数默认值实际值由main.parameters.json注入派生资源名deploymentTarget containerapps时才会生成 ACA 用户分配托管身份acaIdentityName、托管环境acaManagedEnvironmentName和容器注册表containerRegistryName的名称infra/main.bicep条件模块分支App Service 计划与 backend 模块仅在deploymentTarget appservice时部署infra/main.bicep 与 infra/main.bicep而 ACA 身份、容器应用环境、backend 容器应用及认证模块仅在deploymentTarget containerapps时部署infra/main.bicep统一出口无论走哪条分支最终都通过BACKEND_URI输出后端地址前端与后端 API 的联调入口保持一致infra/main.bicep。Container Apps 部署路径由三个模块协同完成infra/main.bicep模块文件职责infra/core/security/aca-identity.bicep创建用户分配托管身份供容器应用访问 Azure AI Search、存储等资源infra/core/host/container-apps.bicep预配 Container Apps 托管环境managed environment与 Azure 容器注册表ACRinfra/core/host/container-app-upsert.bicep创建或更新 backend 容器应用本身注入环境变量与镜像其中 container-app-upsert.bicep 还提供了一套容器规格参数默认值为 0.5 vCPU、1.0Gi 内存、最小 1 副本、最大 10 副本infra/core/host/container-app-upsert.bicep。后端镜像启动命令为 Gunicorn 绑定0.0.0.0:8000运行 FastAPI 应用Dockerfile因此容器应用的目标端口targetPort被配置为 80 并转发到容器内的 8000。定制工作负载配置文件Workload ProfileContainer Apps 支持两种计费与调度模型Consumption按量计费与Dedicated专用工作负载。本项目的默认工作负载配置文件是Consumption对应 infra/main.parameters.jsonazureContainerAppsWorkloadProfile: { value: ${AZURE_CONTAINER_APPS_WORKLOAD_PROFILEConsumption} }如需改用 D4 等专用工作负载配置文件在部署前执行azd env set AZURE_CONTAINER_APPS_WORKLOAD_PROFILE D4可用的工作负载配置文件类型以 Bicep 中的allowed约束为准infra/core/host/container-apps.bicep包括Consumption, D4, D8, D16, D32, E4, E8, E16, E32, NC24-A100, NC48-A100, NC96-A100其中D系列为通用计算型、E系列为内存优化型、NC*系列为 GPU 加速型A100。请注意专用工作负载配置文件与 Consumption 计划的计费模型不同选用前务必核对 Azure Container Apps 的计费文档避免产生预期外的成本。从源码还可以看到一个易被忽略的细节当托管环境启用私有入口usePrivateIngress且用户仍指定Consumption时Bicep 会自动将生效的工作负载配置文件升级为D4infra/core/host/container-apps-environment.bicep因为私有入口要求至少一个非 Consumption 配置文件承载流量。该文件同时定义了工作负载数组非私有入口场景仅保留Consumption私有入口场景则额外挂载名为Warm的专用配置文件infra/core/host/container-apps-environment.bicep。私有端点Private endpoints支持现状需要特别提醒的是Azure Container Apps 的私有端点Private endpoints功能目前仍处于私有预览阶段本项目暂不支持。因此如果你的部署场景强依赖 VNet 内的私有端点隔离当前版本应优先考虑 App Service 部署路径参见 docs/azure_app_service.md或者关注 Azure Container Apps 官方功能的正式发布状态后再做迁移。从 infra/main.bicep 可以看到仓库其实已经为两条路径分别预留了私有端点连接变量containerAppsPrivateEndpointConnection与appServicePrivateEndpointConnection但 Container Apps 侧的支持落地仍受制于平台能力的发布节奏。部署后的验证与运维建议azd up成功完成后可按下述思路验证与运维访问验证通过azd env get-values查看BACKEND_URI输出浏览器打开前端地址确认 ChatGPT 式问答界面可正常与后端交互资源清理验证完毕后及时执行azd down删除资源组及全部资源防止 AI Search、容器环境等持续计费环境隔离不同目标环境使用azd env new分别创建DEPLOYMENT_TARGET、AZURE_CONTAINER_APPS_WORKLOAD_PROFILE等变量均按环境独立存储于.azure/env目录切换环境不会互相污染Host 切换回滚若需从 Container Apps 切回 App Service反向操作即可——将 azure.yaml 中的host: containerapp注释掉、取消host: appservice注释并执行azd env set DEPLOYMENT_TARGET appservice后重新azd up其余步骤与本文完全对称。小结Azure Container Apps 是 azure-search-openai-demo 的默认部署目标其部署链路由 azure.yaml 的host字段、DEPLOYMENT_TARGET环境变量与 infra/main.bicep 的条件模块共同驱动。掌握azd env set的变量注入方式与 Bicep 分支逻辑即可在 Consumption/Dedicated 工作负载、Container Apps/App Service 之间自由切换同时务必留意成本控制与私有端点暂不支持这两条边界条件。【免费下载链接】azure-search-openai-demoA sample app for the Retrieval-Augmented Generation pattern running in Azure, using Azure AI Search for retrieval and Azure OpenAI large language models to power ChatGPT-style and QA experiences.项目地址: https://gitcode.com/GitHub_Trending/az/azure-search-openai-demo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
