Блог

У нас есть два ASP.Net Веб-сайты Core 3.1 (с разными доменными именами / заголовками хостов), развернутые в Elastic Beanstalk под управлением Windows 2019 Core server и IIS. Мы смогли сделать это, выполнив следующие действия https://aws.amazon.com/blogs/developer/multi-app-support-with-custom-domains-for-net-and-aws-elastic-beanstalk/

Однако оба веб-сайта работают под управлением «DefaultAppPool». ASP.Net Ядро не допускает более одного приложения для каждого пула приложений (ошибка HTTP 500.35 — ASP.NET Ядро не поддерживает несколько приложений в одном пуле приложений).

Итак, мы добавили следующий раздел в aws-windows-deployment-manifest.json

 "iisConfig": {
    "appPools": [
      {
        "name": "AppPool1",
        "managedPipelineMode": "Integrated",
        "managedRuntimeVersion": "v4.0"
      },
      {
        "name": "AppPool2",
        "managedPipelineMode": "Integrated",
        "managedRuntimeVersion": "v4.0"
      }
    ]
  }
 

И EB deployment создал соответствующие пулы приложений в IIS.

Теперь мы не можем назначить пул приложений для каждого веб-сайта. В идеале мы хотели бы использовать команды из модуля веб-администрирования (https://docs.microsoft.com/en-us/powershell/module/webadministration/?view=windowsserver2019-ps ) в сценариях PowerShell ‘install*.ps1’ или в файле ‘.config’ в папке ‘.ebextensions’. Однако модуль веб-администрирования недоступен ни в одном месте и IMPORT-MODULE WebAdministration также не работает. Только модуль администрирования IISAdministration (https://docs.microsoft.com/en-us/powershell/module/iisadministration/?view=windowsserver2019-ps ) доступен во время выполнения скриптов ‘install *.ps1’.

Итак, как назначить пулы приложений для разных ASP.Net Основные веб-сайты в AWS Elastic Beanstalk?

После определения appPools в файле манифеста вы можете назначить их своим приложениям, используя их appPool свойство:

 {
    "manifestVersion": 1,
    "iisConfig": {
        "appPools": [
            {
              "name": "AppPool1",
              "managedPipelineMode": "Integrated",
              "managedRuntimeVersion": "v4.0"
            },
            {
              "name": "AppPool2",
              "managedPipelineMode": "Integrated",
              "managedRuntimeVersion": "v4.0"
            }
          ]
    },
    "deployments": {
        "aspNetCoreWeb": [
            {
                "name": "frontend",
                "parameters": {
                    "appBundle": "./frontend",
                    "iisPath": "/frontend",
                    "appPool": "AppPool1"
                }
            },
            {
                "name": "ext-api",
                "parameters": {
                    "appBundle": "./ext-api",
                    "iisPath": "/ext-api",
                    "appPool": "AppPool2"
                }
            }
        ]
    }
}
 

Очень легко документированный (для Windows Server) секретный соус скрывается на https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/custom-platform-hooks.html

Итак, для нас сработала следующая стратегия. Мы добавили следующее содержимое в файл apppool.config (имя не имеет значения, если оно имеет расширение .config) в файл .ebextensions

 files:
  "c:/Program Files/Amazon/ElasticBeanstalk/hooks/appdeploy/post/config.ps1":
    content: |
      Start-IISCommitDelay
      $site = Get-IISSite "site1"
      $site.Applications["/"].ApplicationPoolName = "AppPool1"
      $site = Get-IISSite "site2"
      $site.Applications["/"].ApplicationPoolName = "AppPool2"
      Stop-IISCommitDelay
 

Это создало сценарий powershell config.ps1 в c:/Program Files/Amazon/ElasticBeanstalk/hooks/appdeploy/post/ папке. Сценарий powershell выполняется после создания нового экземпляра или развертывания новой версии.

Единственный недостаток — config.ps1 создается каждый раз, когда новая версия развертывается на существующем экземпляре. Это не повредит, так как старый файл переименовывается config.ps1.bak и игнорируется процессом развертывания EB. Здесь определенно есть возможности для улучшения (отложим на другой день).

Для завершения приведем весь aws-windows-deployment-manifest.json

 {
  "manifestVersion": 1,
  "iisConfig": {
    "appPools": [
      {
        "name": "AppPool1",
        "managedPipelineMode": "Integrated",
        "managedRuntimeVersion": "v4.0"
      },
      {
        "name": "AppPool2",
        "managedPipelineMode": "Integrated",
        "managedRuntimeVersion": "v4.0"
      }
    ]
  },
  "deployments": {
    "custom": [
      {
        "name": "site1",        
        "scripts": {
          "install": {
            "file": "install1.ps1"
          },
          "restart": {
            "file": "restart.ps1"
          },
          "uninstall": {
            "file": "uninstall1.ps1"
          }
        }
      },
      {
        "name": "site2",        
        "scripts": {
          "install": {
            "file": "install2.ps1"
          },
          "restart": {
            "file": "restart.ps1"
          },
          "uninstall": {
            "file": "uninstall2.ps1"
          }
        }
      }  
    ]
  }
}
 

И вот install1.ps1

 Copy-Item -Path "C:stagingsite1" -Destination "C:inetpub" -Recurse -Force
New-IISSite -Name "site1" -BindingInformation "*:80:*.site1.com" -PhysicalPath "C:inetpubsite1" -Force
 

И uninstall1.ps1

 Remove-IISSite -Name "site1" -Confirm:$False
rm -r "c:inetpubsite1" -Force
 

И restart.ps1

 iisreset /timeout:1
 

install2.ps1 и uninstall2.ps1 похожи на их аналог site1, как указано выше.

Мы ссылались на множество статей в Интернете и обязаны Thank You всем им.