翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 高度な移行シナリオ
このセクションでは、複雑な IIS デプロイの高度な移行シナリオについて説明します。
## Application Request Routing (ARR) によるマルチサイト移行
**eb migrate** コマンドは、移行中に ARR 設定を自動的に検出して保持します。ユーザーの IIS `applicationHost.config` 内の ARR 設定を識別すると、ターゲット EC2 インスタンスに ARR を再インストールして設定するために必要な PowerShell スクリプトが生成されます。
### ARR 設定の検出
移行プロセスでは、IIS の 3 つの主要な設定セクションを調べます。
+ `system.webServer/proxy`: コア ARR プロキシ設定
+ `system.webServer/rewrite`: URL 書き換えルール
+ `system.webServer/caching`: キャッシュ設定
例えば、ポート 80 で実行されている `RouterSite` が、それぞれポート 8081 で実行されている `APIService` と 8082 で実行されている `AdminPortal` へのリクエストをプロキシする一般的な ARR 設定を考えてみましょう。
```
```
次の図は、これらのルールが IIS サーバーのポート 80 の背後で非表示になり、EC2 セキュリティグループを介して公開されない方法を示しています。Application Load Balancer はポート 80 にのみアクセスでき、そこからのすべてのトラフィックはポート 80 のターゲットグループにルーティングされます。
次のコマンドは、この設定を移行できます。
```
PS C:\migrations_workspace> eb migrate --sites "RouterSite,APIService,AdminPortal" `
--copy-firewall-config
```
### ARR 移行プロセス
移行プロセスでは、いくつかのステップを介して ARR 設定が保持されます。
設定のエクスポート
このツールは、既存の ARR 設定を 3 つのキー設定セクションから `ebmigrateScripts` ディレクトリに保存されている個別の XML ファイルにエクスポートします。
```
ebmigrateScripts\
├── arr_config_proxy.xml
├── arr_config_rewrite.xml
└── arr_config_caching.xml
```
インストールスクリプト
ARR 設定を処理するために 2 つの PowerShell スクリプトが生成されます。
1. `arr_msi_installer.ps1`: ARR モジュールをダウンロードしてインストールします
1. `arr_configuration_importer_script.ps1`: エクスポートされた ARR 設定をインポートします
デプロイマニフェストの統合
スクリプトは、`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"
}
}
}
]
}
}
```
### ロードバランサーの統合
移行プロセスは、可能な限り ARR ルールを Application Load Balancer (ALB) リスナールールに変換します。例えば、上記の ARR 設定は、EC2 インスタンスで内部ルーティングを維持しながら、URL パスパターンに基づいてトラフィックをルーティングする ALB ルールをもたらします。
結果として得られる環境は、 AWSのエラスティックインフラストラクチャを活用しながら、ARR ルーティングロジックを維持します。Application Load Balancer が外部トラフィック分散を管理している間 ARR は内部ルーティングを処理し、アプリケーションは以前と同じように動作し続けます。
## ホストベースのルーティングを使用した ARR なしのマルチサイト移行
Application Request Routing (ARR) は IIS の複数のサイトを管理するための一般的なアプローチですが、Application Load Balancer のホストベースのルーティング機能を活用することで、ARR なしでマルチサイトデプロイを Elastic Beanstalk に直接移行することもできます。このアプローチにより、追加のルーティングレイヤーを無くすことで、複雑さを軽減し、パフォーマンスを向上させることができます。
### ホストベースのルーティングの概要
このアプローチでは、各 IIS サイトが EC2 インスタンスの外部に公開され、Application Load Balancer は、ホストヘッダーに基づいてトラフィックを適切なポートに直接ルーティングします。これにより、アプリケーション間の分離を維持しながら ARR の必要性をなくします。
3 つのサイトを持つマルチサイト IIS 設定を考慮します。それぞれに独自のホスト名バインディングがあります。
```
```
これらのサイトは、EC2 セキュリティグループを介してポート 8081、8082、および 8083 で公開されます。Application Load Balancer は、ロードバランサーリスナールール設定に基づいてそれらにルーティングします。
### 移行プロセス
ARR を使用せずにこの設定を Elastic Beanstalk に移行するには、次の例の **eb migrate** コマンドを使用します。
```
PS C:\migrations_workspace> eb migrate --sites "Default Web Site,InternalAPI,ReportingPortal"
```
移行プロセスでは、ホストヘッダーに基づいてトラフィックを適切なターゲットグループに送信するホストベースのルーティングルールを使用して Application Load Balancer が自動的に設定されます。各ターゲットグループは、EC2 インスタンスの対応するポートにトラフィックを転送します。
1. ホストヘッダー www.example.com → ポート 8081 のターゲットグループ
1. ホストヘッダー api.internal → ポート 8082 のターゲットグループ
1. ホストヘッダー reports.internal → ポート 8083 のターゲットグループ
### SSL/TLS 設定
SSL/TLS を使用してアプリケーションを保護するには、次の手順を実行します。
1. AWS Certificate Manager(ACM) を使用してドメインの証明書をリクエストします。
1. これらの証明書を使用して、Application Load Balancer で HTTPS リスナーを設定します。
1. 環境設定を更新して、次の設定オプション設定を持つ HTTPS リスナーを含めます。
```
option_settings:
aws:elb:listener:443:
ListenerProtocol: HTTPS
SSLCertificateId: arn:aws:acm:region:account-id:certificate/certificate-id
InstancePort: 80
InstanceProtocol: HTTP
```
この設定では、SSL 終了はロードバランサーで発生し、トラフィックは HTTP 経由でインスタンスに転送されます。これにより、クライアントとの安全な接続を維持しながら、証明書の管理が簡素化されます。
### ベストプラクティス
セキュリティグループ
Application Load Balancer セキュリティグループから IIS サイトが使用するポート (この例では 8081、8082、8083) でのみインバウンドトラフィックを許可するようにセキュリティグループを設定します。
ヘルスチェック
各ターゲットグループのヘルスチェックを設定して、トラフィックが正常なインスタンスにのみルーティングされるようにします。まだ存在しない場合は、アプリケーションごとにヘルスチェックエンドポイントを作成します。
モニタリング
CloudWatch アラームを設定して、各ターゲットグループの正常性とパフォーマンスを個別にモニタリングします。これにより、個々のアプリケーションに固有の問題を特定できます。
スケーリング
自動スケーリングポリシーを設定するときは、すべてのアプリケーションのリソース要件を検討してください。1 つのアプリケーションでリソースのニーズが大幅に異なる場合は、別の環境への移行を検討してください。
## 仮想ディレクトリ管理
**eb migrate** コマンドは、IIS アプリケーションを Elastic Beanstalk に移行する間、仮想ディレクトリ構造を保持します。
### デフォルトのアクセス許可設定
仮想ディレクトリを移行する場合、**eb migrate** は ReadAndExecute に以下へのアクセスを付与することで、アクセス許可のベースラインセットを確立します。
+ IIS\_IUSRS
+ IUSR
+ 認証されたユーザー
例えば、一般的な仮想ディレクトリ構造を検討します。
```
```
### パスワードで保護された仮想ディレクトリ
**eb migrate** でパスワードで保護された仮想ディレクトリが発生した場合、警告を発行し、手動による介入が必要です。
次の設定例では、この例に続く警告レスポンスが発生します。
```
```
```
[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"
}
```
### ベストプラクティス
移行を計画、実行、モニタリング、検証するには、以下のベストプラクティスに従います。
移行前の計画
移行前に、既存のアクセス許可と認証要件を文書化します。本番環境にデプロイする前に、開発環境でカスタムアクセス許可スクリプトをテストします。
共有コンテンツ管理
共有コンテンツディレクトリの場合、すべての必要なファイルシステムのアクセス許可がカスタムスクリプトを介して適切に設定されていることを確認します。共有ストレージ要件には、[Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/) の使用を検討してください。
モニタリングと検証
移行後にアプリケーションログをモニタリングして、仮想ディレクトリへの適切なアクセスを確認します。次の部分に特に注意してください。
+ アプリケーションプール ID アクセス
+ カスタムサービスアカウントのアクセス許可
+ ネットワーク共有接続
+ 認証の失敗
## カスタムアプリケーションプール設定
**eb migrate** コマンドは、デフォルトではカスタムアプリケーションプール設定をコピーしません。カスタムアプリケーションプール設定を保持するには、次の手順に従ってカスタムマニフェストセクションを作成して適用します。
1. 移行アーティファクトのアーカイブを作成します。
```
PS C:\migrations_workspace> eb migrate --archive
```
1. カスタム PowerShell スクリプトを作成して、アプリケーションプールを設定します。
```
# 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 = @"
"@
$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."
```
1. `aws-windows-deployment-manifest.json` ファイルを更新して、カスタムスクリプトを含めます。
```
{
"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"
}
}
}
]
}
}
```
1. 更新されたアーカイブディレクトリを使用して環境を作成します。
```
PS C:\migrations_workspace> eb migrate `
--archive-dir '.\migrations\latest\upload_target\'
```
`--archive-dir` 引数は、新しいアーカイブの作成を回避するために、以前に作成したソースコードを使用するように **eb migrate** に指示します。
## 以前のバージョンのデプロイ
**eb migrate** は、Elastic Beanstalk のタイムスタンプ付きディレクトリとアプリケーションバージョンを通じて移行の履歴を維持します。各移行では、必要に応じてデプロイできる一意の 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
```
**eb migrate** を使用して `upload_target.zip`フ ァイルをデプロイできます。
```
PS C:\migrations_workspace> eb migrate --zip .\migrations\latest\upload_target.zip
```