Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

高级迁移方案

本节介绍复杂 IIS 部署的高级迁移方案。

使用应用程序请求路由 (ARR) 进行多站点迁移

该eb migrate命令会在迁移期间自动检测并保留 ARR 配置。当它识别出您的 IIS 中的 ARR 设置时applicationHost.config，它会生成必要的 PowerShell 脚本，以便在目标 EC2 实例上重新安装和配置 ARR。

ARR 配置检测

迁移过程将检查 IIS 中的三个关键配置部分：

例如，考虑一个常见的 ARR 配置，其中在端口 80 上RouterSite运行的代理分别向端口 8081 和 8082 发出请求，APIService并在端口 8081 和 8082 上AdminPortal运行：

<!-- Original IIS ARR Configuration -->
<rewrite>
    <rules>
        <rule name="Route to API" stopProcessing="true">
            <match url="^api/(.*)$" />
            <action type="Rewrite" url="http://backend:8081/api/{R:1}" />
        </rule>
        <rule name="Route to Admin" stopProcessing="true">
            <match url="^admin/(.*)$" />
            <action type="Rewrite" url="http://backend:8082/admin/{R:1}" />
        </rule>
    </rules>
</rewrite>

下图描述了这些规则如何隐藏在 IIS 服务器的端口 80 后面，而不是通过 EC2 安全组公开。Application Load Balancer 只能访问端口 80，来自该端口的所有流量都通过端口 80 路由到目标组。

以下命令可以迁移此配置：

PS C:\migrations_workspace> eb migrate --sites "RouterSite,APIService,AdminPortal" `
    --copy-firewall-config

ARR 迁移流程

迁移过程通过几个步骤保留您的 ARR 配置。

负载均衡器集成

迁移过程会尽可能将您的 ARR 规则转换为 Application Load Balancer (ALB) 侦听器规则。例如，上述 ARR 配置生成 ALB 规则，这些规则基于 URL 路径模式路由流量，同时在 EC2 实例上维护内部路由。

由此产生的环境可维护您的 ARR 路由逻辑，同时充分利用其 Amazon弹性基础架构。您的应用程序继续像以前一样运行，ARR 处理内部路由，而 Application Load Balancer 管理外部流量分配。

使用基于主机的路由实现没有 ARR 的多站点迁移

虽然应用程序请求路由 (ARR) 是在 IIS 中管理多个站点的常用方法，但您也可以利用应用程序负载均衡器的基于主机的路由功能，将多站点部署直接迁移到没有 ARR 的 Elastic Beanstalk。这种方法可以省去额外的路由层，从而降低复杂性并提高性能。

基于主机的路由概述

在这种方法中，每个 IIS 站点都暴露在 EC2 实例之外，Application Load Balancer 会根据主机标头将流量直接路由到相应的端口。这消除了对 ARR 的需求，同时保持了应用程序之间的分离。

考虑一个包含三个站点的多站点 IIS 配置，每个站点都有自己的主机名绑定：

<sites>
    <site name="Default Web Site" id="1">
        <bindings>
            <binding protocol="http" bindingInformation="*:8081:www.example.com" />
        </bindings>
    </site>
    <site name="InternalAPI" id="2">
        <bindings>
            <binding protocol="http" bindingInformation="*:8082:api.internal" />
        </bindings>
    </site>
    <site name="ReportingPortal" id="3">
        <bindings>
            <binding protocol="http" bindingInformation="*:8083:reports.internal" />
        </bindings>
    </site>
</sites>

这些站点通过安全组在端口 8081、8082 和 8083 上 EC2 公开。Application Load Balancer 根据负载平衡器侦听器规则配置路由到它们。

迁移过程

要在不使用 ARR 的情况下将此配置迁移到 Elastic Beanstalk，eb migrate请使用以下示例中的命令：

PS C:\migrations_workspace> eb migrate --sites "Default Web Site,InternalAPI,ReportingPortal"

迁移过程会自动使用基于主机的路由规则配置 Application Load Balancer，这些规则根据主机标头将流量引导到相应的目标组。每个目标组将流量转发到您的 EC2 实例上的相应端口：

SSL/TLS 配置

要使用 SSL/TLS 保护您的应用程序，请执行以下步骤：

使用此配置，SSL 终止发生在负载均衡器上，流量将通过 HTTP 转发到您的实例。这简化了证书管理，同时保持了与客户端的安全连接。

最佳实践

虚拟目录管理

在将 IIS 应用程序迁移到 Elastic Beanstalk 时，该eb migrate命令可以保留虚拟目录结构。

默认权限配置

迁移虚拟目录时，通过授予对以下内容的 ReadAndExecute 访问权限来eb migrate建立一组基准权限：

例如，考虑一个典型的虚拟目录结构：

<site name="CorporatePortal">
    <application path="/" applicationPool="CorporatePortalPool">
        <virtualDirectory path="/" physicalPath="C:\sites\portal" />
        <virtualDirectory path="/shared" physicalPath="C:\shared\content" />
        <virtualDirectory path="/reports" physicalPath="D:\reports" />
    </application>
</site>

受密码保护的虚拟目录

当eb migrate遇到受密码保护的虚拟目录时，它会发出警告并需要手动干预。

以下配置示例将导致该示例之后的警告响应。

<virtualDirectory path="/secure" 
                 physicalPath="C:\secure\content"
                 userName="DOMAIN\User"
                 password="[encrypted]" />

[WARNING] CorporatePortal/secure is hosted at C:\secure\content which is password-protected and won't be copied.

要维护密码保护，请创建如下所示的自定义部署脚本：

# PS C:\migrations_workspace> cat secure_vdir_config.ps1

$vdirPath = "C:\secure\content"
$siteName = "CorporatePortal"
$vdirName = "secure"
$username = "DOMAIN\User"
$password = "SecurePassword"

# Ensure directory exists
if (-not (Test-Path $vdirPath)) {
    Write-Host "Creating directory: $vdirPath"
    New-Item -Path $vdirPath -ItemType Directory -Force
}

# Configure virtual directory with credentials
Write-Host "Configuring protected virtual directory: $vdirName"
New-WebVirtualDirectory -Site $siteName -Name $vdirName `
    -PhysicalPath $vdirPath -UserName $username -Password $password

# Set additional permissions as needed
$acl = Get-Acl $vdirPath
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    $username, "ReadAndExecute", "ContainerInherit,ObjectInherit", "None", "Allow"
)
$acl.AddAccessRule($rule)
Set-Acl $vdirPath $acl

将此脚本包含在清单中，将其添加到您的部署中：

{
    "manifestVersion": 1,
    "deployments": {
        "custom": [
            {
                "name": "SecureVirtualDirectory",
                "scripts": {
                    "install": {
                        "file": "secure_vdir_config.ps1"
                    }
                }
            }
        ]
    }
}

自定义权限管理

该eb migrate命令为自定义权限脚本提供了一个框架，以适应需要默认权限以外的权限的应用程序。

$paths = @(
    "C:\sites\portal\uploads",
    "C:\shared\content"
)

foreach ($path in $paths) {
    if (-not (Test-Path $path)) {
        Write-Host "Creating directory: $path"
        New-Item -Path $path -ItemType Directory -Force
    }

    $acl = Get-Acl $path

    # Add custom permissions
    $customRules = @(
        # Application Pool Identity - Full Control
        [System.Security.AccessControl.FileSystemAccessRule]::new(
            "IIS AppPool\CorporatePortalPool", 
            "FullControl", 
            "ContainerInherit,ObjectInherit", 
            "None", 
            "Allow"
        ),
        # Custom Service Account
        [System.Security.AccessControl.FileSystemAccessRule]::new(
            "NT SERVICE\CustomService", 
            "Modify", 
            "ContainerInherit,ObjectInherit", 
            "None", 
            "Allow"
        )
    )

    foreach ($rule in $customRules) {
        $acl.AddAccessRule($rule)
    }
    
    Set-Acl $path $acl
    Write-Host "Custom permissions applied to: $path"
}

最佳实践

遵循这些最佳实践来规划、执行、监控和验证您的迁移。

自定义应用程序池设置

默认情况下，该eb migrate命令不会复制自定义应用程序池设置。要保留自定义应用程序池配置，请按照以下步骤创建和应用自定义清单部分。

该--archive-dir参数告诉eb migrate使用它之前创建的源代码，从而避免创建新的存档。

部署以前的版本

在 Elastic Beanstalk 中通过带有时间戳的目录和应用程序版本来eb migrate维护您的迁移历史记录。每次迁移都会创建一个唯一的 zip 文件，可以根据需要进行部署。

PS C:\migrations_workspace> ls .\migrations\

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d----l        3/18/2025  10:34 PM                latest
d-----        3/16/2025   5:47 AM                migration_1742104049.479849
d-----        3/17/2025   9:18 PM                migration_1742246303.18056
d-----        3/17/2025   9:22 PM                migration_1742246546.565739
...
d-----        3/18/2025  10:34 PM                migration_1742337258.30742

latest符号链接始终指向最近创建的迁移对象目录。除了相关的应用程序和错误日志外，每个迁移工件目录还包含一个可以部署到 Elastic Beanstalk 的upload_target.zip文件。

PS C:\migrations_workspace> ls .\migrations\latest\

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        3/18/2025  10:34 PM                upload_target
-a----        3/18/2025  10:34 PM          13137 application.log
-a----        3/18/2025  10:34 PM              0 error.log
-a----        3/18/2025  10:34 PM        1650642 upload_target.zip

你可以使用以下方法部署upload_target.zip文件eb migrate：

PS C:\migrations_workspace> eb migrate --zip .\migrations\latest\upload_target.zip