Migrasi multi-situs dengan Application Request Routing (ARR)Migrasi multi-situs tanpa ARR menggunakan perutean berbasis host Manajemen direktori virtual Pengaturan kolam aplikasi kustom Menerapkan versi sebelumnya

Skenario migrasi lanjutan

Bagian ini mencakup skenario migrasi lanjutan untuk penerapan IIS yang kompleks.

Migrasi multi-situs dengan Application Request Routing (ARR)

eb migratePerintah secara otomatis mendeteksi dan mempertahankan konfigurasi ARR selama migrasi. Ketika mengidentifikasi pengaturan ARR di IIS AndaapplicationHost.config, itu menghasilkan PowerShell skrip yang diperlukan untuk menginstal ulang dan mengkonfigurasi ARR pada instance target. EC2

Deteksi konfigurasi ARR

Proses migrasi memeriksa tiga bagian konfigurasi utama di IIS:

system.webServer/proxy: Pengaturan proxy ARR inti
system.webServer/rewrite: Aturan penulisan ulang URL
system.webServer/caching: Konfigurasi caching

Misalnya, pertimbangkan konfigurasi ARR umum di mana proxy port 80 yang RouterSite berjalan meminta APIService dan AdminPortal berjalan pada port 8081 dan 8082 masing-masing:


<!-- 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>

Diagram berikut menggambarkan bagaimana aturan ini tersembunyi di balik port 80 di server IIS dan tidak diekspos melalui Grup EC2 Keamanan. Hanya port 80 yang dapat diakses oleh Application Load Balancer dan semua lalu lintas darinya dialihkan ke grup target di port 80.

Arsitektur Elastic Beanstalk dengan Application Request Routing (ARR)

Perintah berikut dapat memigrasikan konfigurasi ini:


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

Proses migrasi ARR

Proses migrasi mempertahankan konfigurasi ARR Anda melalui beberapa langkah.

Ekspor konfigurasi

Alat ini mengekspor pengaturan ARR Anda yang ada dari tiga bagian konfigurasi kunci ke dalam file XHTML terpisah yang disimpan dalam direktori: ebmigrateScripts


ebmigrateScripts\
├── arr_config_proxy.xml
├── arr_config_rewrite.xml
└── arr_config_caching.xml

Skrip instalasi

Dua PowerShell skrip dihasilkan untuk menangani penyiapan ARR:

arr_msi_installer.ps1: Mengunduh dan menginstal modul ARR
arr_configuration_importer_script.ps1: Mengimpor konfigurasi ARR Anda yang diekspor

Integrasi manifes penerapan

Skrip diintegrasikan ke dalam proses penyebaran melalui entri di: aws-windows-deployment-manifest.json


{
    "manifestVersion": 1,
    "deployments": {
        "custom": [
            {
                "name": "WindowsProxyFeatureEnabler",
                "scripts": {
                    "install": {
                        "file": "ebmigrateScripts\\windows_proxy_feature_enabler.ps1"
                    }
                }
            },
            {
                "name": "ArrConfigurationImporterScript",
                "scripts": {
                    "install": {
                        "file": "ebmigrateScripts\\arr_configuration_importer_script.ps1"
                    }
                }
            }
        ]
    }
}

Integrasi penyeimbang beban

Proses migrasi menerjemahkan aturan ARR Anda ke dalam aturan pendengar Application Load Balancer (ALB) jika memungkinkan. Misalnya, konfigurasi ARR di atas menghasilkan aturan ALB yang merutekan lalu lintas berdasarkan pola jalur URL sambil mempertahankan perutean internal pada instance. EC2

Lingkungan yang dihasilkan mempertahankan logika perutean ARR Anda sambil memanfaatkan infrastruktur elastis. AWS Aplikasi Anda terus berfungsi seperti sebelumnya, dengan ARR menangani perutean internal sementara Application Load Balancer mengelola distribusi lalu lintas eksternal.

Migrasi multi-situs tanpa ARR menggunakan perutean berbasis host

Sementara Application Request Routing (ARR) adalah pendekatan umum untuk mengelola beberapa situs di IIS, Anda juga dapat memigrasikan penyebaran multi-situs langsung ke Elastic Beanstalk tanpa ARR dengan memanfaatkan kemampuan routing berbasis host Application Load Balancer. Pendekatan ini dapat mengurangi kompleksitas dan meningkatkan kinerja dengan menghilangkan lapisan routing tambahan.

Ikhtisar perutean berbasis host

Dalam pendekatan ini, setiap situs IIS diekspos di luar EC2 instance, dan Application Load Balancer mengarahkan lalu lintas langsung ke port yang sesuai berdasarkan header host. Ini menghilangkan kebutuhan akan ARR sambil mempertahankan pemisahan antara aplikasi Anda.

Pertimbangkan konfigurasi IIS multi-situs dengan tiga situs, masing-masing dengan pengikatan nama hostnya sendiri:


<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>

Situs-situs ini diekspos di port 8081, 8082, dan 8083 melalui Grup Keamanan. EC2 Application Load Balancer merutekan ke mereka berdasarkan konfigurasi aturan pendengar Load Balancer.

Arsitektur Elastic Beanstalk tanpa Application Request Routing (ARR)

Proses migrasi

Untuk memigrasikan konfigurasi ini ke Elastic Beanstalk tanpa menggunakan ARR eb migrate gunakan perintah dalam contoh berikut:


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

Proses migrasi secara otomatis mengonfigurasi Application Load Balancer dengan aturan perutean berbasis host yang mengarahkan lalu lintas ke grup target yang sesuai berdasarkan header host. Setiap grup target meneruskan lalu lintas ke port yang sesuai pada EC2 instans Anda:

Header host www.example.com → Grup Sasaran di port 8081
Header host api.internal → Grup Sasaran pada port 8082
Host header reports.internal → Grup Sasaran di port 8083

Konfigurasi SSL/TLS

Untuk mengamankan aplikasi Anda dengan SSL/TLS lakukan langkah-langkah berikut:

Minta sertifikat untuk domain Anda melalui AWS Certificate Manager(ACM).
Konfigurasikan listener HTTPS pada Application Load Balancer Anda menggunakan sertifikat ini.

Perbarui konfigurasi lingkungan Anda untuk menyertakan pendengar HTTPS dengan pengaturan opsi konfigurasi berikut.


option_settings:
  aws:elb:listener:443:
    ListenerProtocol: HTTPS
    SSLCertificateId: arn:aws:acm:region:account-id:certificate/certificate-id
    InstancePort: 80
    InstanceProtocol: HTTP

Dengan konfigurasi ini, penghentian SSL terjadi di penyeimbang beban, dan lalu lintas diteruskan ke instance Anda melalui HTTP. Ini menyederhanakan manajemen sertifikat sambil mempertahankan koneksi aman dengan klien.

Praktik terbaik

Grup keamanan: Konfigurasikan grup keamanan untuk mengizinkan lalu lintas masuk hanya pada port yang digunakan oleh situs IIS Anda (8081, 8082, 8083 dalam contoh ini) dari grup keamanan Application Load Balancer.
Pemeriksaan kondisi: Konfigurasikan pemeriksaan kesehatan untuk setiap grup sasaran untuk memastikan lalu lintas hanya diarahkan ke instance yang sehat. Buat titik akhir pemeriksaan kesehatan untuk setiap aplikasi jika belum ada.
Pemantauan: Siapkan CloudWatch alarm untuk memantau kesehatan dan kinerja masing-masing kelompok sasaran secara terpisah. Ini memungkinkan Anda mengidentifikasi masalah khusus untuk aplikasi individual.
Penskalaan: Pertimbangkan persyaratan sumber daya dari semua aplikasi saat mengonfigurasi kebijakan penskalaan otomatis. Jika satu aplikasi memiliki kebutuhan sumber daya yang berbeda secara signifikan, pertimbangkan untuk memigrasikannya ke lingkungan yang terpisah.

Manajemen direktori virtual

eb migratePerintah mempertahankan struktur direktori virtual saat memigrasikan aplikasi IIS Anda ke Elastic Beanstalk.

Konfigurasi izin default

Saat memigrasi direktori virtual, eb migrate tetapkan sekumpulan izin dasar dengan memberikan akses ke: ReadAndExecute

IIS_IUSRS
IUSR
Pengguna yang Diautentikasi

Misalnya, pertimbangkan struktur direktori virtual yang khas:


<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>

Direktori virtual yang dilindungi kata sandi

Ketika eb migrate menemukan direktori virtual yang dilindungi kata sandi, itu mengeluarkan peringatan dan memerlukan intervensi manual.

Contoh konfigurasi berikut akan menyebabkan respons peringatan yang mengikuti contoh.


<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.

Untuk mempertahankan perlindungan kata sandi, buat skrip penerapan kustom seperti berikut ini:


# 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

Tambahkan skrip ini ke penerapan Anda dengan memasukkannya ke dalam manifes:


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

Manajemen izin khusus

eb migratePerintah ini menyediakan kerangka kerja untuk skrip izin khusus untuk mengakomodasi aplikasi yang memerlukan izin selain default.


$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"
}

Praktik terbaik

Ikuti praktik terbaik ini untuk merencanakan, menjalankan, memantau, dan memverifikasi migrasi Anda.

Perencanaan pra-migrasi

Dokumentasikan izin dan persyaratan otentikasi yang ada sebelum migrasi. Uji skrip izin khusus di lingkungan pengembangan sebelum menerapkan ke produksi.

Manajemen konten bersama

Untuk direktori konten bersama, pastikan semua izin sistem file yang diperlukan dikonfigurasi dengan benar melalui skrip khusus. Pertimbangkan untuk menggunakan Amazon FSx untuk Windows File Server untuk persyaratan penyimpanan bersama.

Pemantauan dan verifikasi

Pantau log aplikasi setelah migrasi untuk memverifikasi akses yang tepat ke direktori virtual. Berikan perhatian khusus pada bidang-bidang berikut:

Akses identitas kumpulan aplikasi
Izin akun layanan kustom
Konektivitas berbagi jaringan
Kegagalan otentikasi

Pengaturan kolam aplikasi kustom

eb migratePerintah tidak menyalin pengaturan kumpulan aplikasi kustom secara default. Untuk mempertahankan konfigurasi kumpulan aplikasi kustom, ikuti prosedur ini untuk membuat dan menerapkan bagian manifes kustom.

Buat arsip artefak migrasi Anda.


PS C:\migrations_workspace> eb migrate --archive

Buat PowerShell skrip kustom untuk mengkonfigurasi kumpulan aplikasi.


# PS C:\migrations_workspace> cat .\migrations\latest\upload_target\customize_application_pool_config.ps1

$configPath = "$env:windir\System32\inetsrv\config\applicationHost.config"

[xml]$config = Get-Content -Path $configPath

$newPoolXml = @"
<!-- Original IIS Configuration -->
<applicationPools>
    <add name="CustomPool" 
         managedRuntimeVersion="v4.0" 
         managedPipelineMode="Integrated">
        <processModel identityType="SpecificUser" 
                     userName="AppPoolUser" 
                     password="[encrypted]" />
        <recycling>
            <periodicRestart time="00:00:00">
                <schedule>
                    <add value="02:00:00" />
                    <add value="14:00:00" />
                </schedule>
            </periodicRestart>
        </recycling>
    </add>
</applicationPools>
"@
$newPoolXmlNode = [xml]$newPoolXml

# Find the applicationPools section
$applicationPools = $config.SelectSingleNode("//configuration/system.applicationHost/applicationPools")

# Import the new node into the document
$importedNode = $config.ImportNode($newPoolXmlNode.DocumentElement, $true)
$applicationPools.AppendChild($importedNode)

# Save the changes
$config.Save($configPath)

Write-Host "ApplicationHost.config has been updated successfully."

Perbarui aws-windows-deployment-manifest.json file untuk menyertakan skrip kustom Anda.


{
    "manifestVersion": 1,
    "deployments": {
        ...
        "custom": [
            ...,
            {
                "name": "ModifyApplicationPoolConfig",
                "description": "Modify application pool configuration from source machine to remove",
                "scripts": {
                    "install": {
                        "file": "customize_application_pool_config.ps1"
                    },
                    "restart": {
                        "file": "ebmigrateScripts\\noop.ps1"
                    },
                    "uninstall": {
                        "file": "ebmigrateScripts\\noop.ps1"
                    }
                }
            }
        ]
    }
}

Buat lingkungan dengan direktori arsip yang diperbarui.


PS C:\migrations_workspace> eb migrate `
    --archive-dir '.\migrations\latest\upload_target\'

--archive-dirArgumen mengatakan eb migrate untuk menggunakan kode sumber yang sebelumnya dibuat, menghindari pembuatan arsip baru.

Menerapkan versi sebelumnya

The eb migrate mempertahankan riwayat migrasi Anda melalui direktori stempel waktu dan versi aplikasi di Elastic Beanstalk. Setiap migrasi membuat file zip unik yang dapat digunakan jika diperlukan.


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

Tautan latest simbolis selalu menunjuk ke direktori artefak migrasi yang paling baru dibuat. Selain log aplikasi dan kesalahan yang relevan, setiap direktori artefak migrasi juga berisi upload_target.zip file yang dapat Anda gunakan ke Elastic Beanstalk.


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

Anda dapat menyebarkan upload_target.zip file menggunakaneb migrate:


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

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Pemetaan migrasi IIS ke Elastic Beanstalk

Pemecahan masalah dan diagnostik