如何将Azure应用设置或连接字符串传入Angular应用？

我来帮你搞定这个Angular动态配置API地址的问题——刚好我之前用Pulumi部署.NET+Angular栈的时候遇到过一模一样的需求，下面给你几个实用的方案，你可以根据自己的部署场景选：

方案1：部署时动态生成环境文件（适合允许部署阶段构建的场景） #

这个方案是在Pulumi部署流程中，先替换Angular环境文件里的占位符，再执行构建，这样编译后的前端包就自带了正确的API地址，不用手动改代码。

步骤： #

1. 创建环境模板文件：在你的Angular项目src/environments下新建environment.prod.template.ts，内容如下：

export const environment = {
  production: true,
  API_URL: "{{API_URL}}"
};

2. Pulumi中替换占位符并构建：在你的Pulumi代码（比如TypeScript）里，读取模板文件，用实际部署的API端点替换占位符，然后触发Angular构建：

import * as pulumi from "@pulumi/pulumi";
import * as fs from "fs";
import * as path from "path";
import * as childProcess from "child_process";

// 假设你的.NET API部署后输出了端点地址（替换成你实际的Pulumi输出变量）
const apiEndpoint = yourApiService.endpoint;

// 读取模板文件内容
const envTemplatePath = path.join(__dirname, "../angular-app/src/environments/environment.prod.template.ts");
const envTemplate = fs.readFileSync(envTemplatePath, "utf8");

// 替换占位符为实际API地址
const prodEnvContent = apiEndpoint.apply(url => envTemplate.replace("{{API_URL}}", url));

// 写入最终的environment.prod.ts
const prodEnvPath = path.join(__dirname, "../angular-app/src/environments/environment.prod.ts");
fs.writeFileSync(prodEnvPath, prodEnvContent);

// 执行Angular生产构建
childProcess.execSync("ng build --configuration production", { 
  cwd: path.join(__dirname, "../angular-app"),
  stdio: "inherit" // 可选：显示构建日志
});

// 部署构建后的dist文件夹到静态托管服务（比如Azure Static Web Apps）
const staticSite = new azure.staticwebapp.StaticSite("angular-frontend", {
  location: yourResourceGroup.location,
  resourceGroupName: yourResourceGroup.name,
  buildProperties: {
    appLocation: ".",
    outputLocation: "dist/your-angular-app-name",
  },
  // 其他必要配置...
});

方案2：运行时加载动态配置文件（适合复用预构建包的场景） #

如果你想完全复用已经构建好的Angular包，不想每次部署都重新编译，可以让前端在启动时加载一个动态生成的配置文件，这样Pulumi只需要替换这个配置文件即可。

步骤： #

1. 添加运行时配置加载逻辑：
   • 在Angular项目的src/assets下新建一个空的config.json（作为模板）：

   { "API_URL": "" }
   

   • 在app.module.ts中添加初始化逻辑，启动时加载这个配置文件：

   import { APP_INITIALIZER, NgModule } from '@angular/core';
   import { HttpClientModule, HttpClient } from '@angular/common/http';
   
   export function initializeApp(http: HttpClient) {
     return () => http.get('/assets/config.json')
       .toPromise()
       .then(config => (window as any).appConfig = config);
   }
   
   @NgModule({
     imports: [HttpClientModule],
     providers: [
       {
         provide: APP_INITIALIZER,
         useFactory: initializeApp,
         deps: [HttpClient],
         multi: true
       }
     ]
   })
   export class AppModule { }
   

   • 修改环境文件，从全局配置中读取API地址：

   export const environment = {
     production: true,
     get API_URL() {
       return (window as any).appConfig?.API_URL || 'http://default-api-url';
     }
   };
   

2. Pulumi中动态生成并上传配置文件：
   在Pulumi代码里生成包含正确API地址的config.json，然后上传到静态托管服务的assets目录：

   import * as azure from "@pulumi/azure-native";
   
   // 假设你已经有了存储账户和静态文件容器
   const storageAccount = azure.storage.StorageAccount.get("staticStorage", "your-account-id");
   const staticContainer = azure.storage.BlobContainer.get("frontendContainer", "your-container-id");
   
   // 生成配置文件内容
   const configContent = pulumi.interpolate`{"API_URL": "${apiEndpoint}"}`;
   
   // 上传config.json到assets目录
   new azure.storage.Blob("app-config", {
     accountName: storageAccount.name,
     containerName: staticContainer.name,
     source: new pulumi.asset.StringAsset(configContent),
     contentType: "application/json",
     blobName: "assets/config.json"
   });
   

方案3：利用托管服务的环境变量注入（适合用托管服务构建的场景） #

如果你的Angular部署在Azure Static Web Apps、AWS Amplify这类托管服务上，它们支持在部署时传递前缀为NG_APP_*的环境变量，这些变量会在构建时自动注入到Angular应用中。

步骤： #

1. 修改Angular环境文件：

   export const environment = {
     production: true,
     API_URL: process.env.NG_APP_API_URL || 'http://default-api-url'
   };
   

2. Pulumi中设置托管服务的环境变量：
   以Azure Static Web Apps为例：

   const staticSite = new azure.staticwebapp.StaticSite("angular-frontend", {
     // 其他配置...
     environmentVariables: {
       NG_APP_API_URL: apiEndpoint.apply(url => url)
     }
   });
   

   这样托管服务在构建你的Angular应用时，会自动把NG_APP_API_URL的值替换到环境文件中。

这三个方案里，方案2最适合“无需重建应用”的需求，完全复用预构建包；方案1和3更简单，适合允许部署阶段构建的场景。你可以根据自己的部署架构选最适合的。

内容的提问来源于stack exchange，提问作者Ben Rauzi