As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Usar o Elastic Beanstalk .NET na plataforma Windows
Este tópico descreve como configurar, criar e executar suas aplicações Web ASP.NET e .NET Core Windows no Elastic Beanstalk.
AWS Elastic Beanstalk oferece suporte a várias plataformas para diferentes versões da estrutura de programação.NET e do Windows Server. Consulte [.NET no Windows Server com IIS](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) no documento *Plataformas do AWS Elastic Beanstalk * para obter uma lista completa.
O Elastic [Beanstalk fornece](command-options.md) opções de configuração que você pode usar para personalizar o software executado EC2 nas instâncias do seu ambiente do Elastic Beanstalk. Você também pode configurar as variáveis do ambiente exigidas pela aplicação, permitir a alternância de logs para o Amazon S3 e definir configurações de framework .NET.
As opções de configuração estão disponíveis no console do Elastic Beanstalk para [modificar a configuração de um ambiente em execução](environment-configuration-methods-after.md). Para evitar a perda da configuração do ambiente quando você terminá-la, você pode usar [configurações salvas](environment-configuration-savedconfig.md) para salvar as configurações e depois aplicá-las a outro ambiente.
Para salvar as configurações no código-fonte, você pode incluir [arquivos de configuração](ebextensions.md). As definições em arquivos de configuração são aplicadas sempre que você cria um ambiente ou implementa a aplicação. Você também pode usar arquivos de configuração para instalar pacotes, executar scripts e realizar outras operações de personalização da instância em implantações.
As configurações aplicadas no console do Elastic Beanstalk substituem as mesmas configurações em arquivos de configuração, caso elas existam. Isso permite que você tenha configurações padrão em arquivos de configuração e as substitua por configurações específicas de ambiente no console. Para obter mais informações sobre precedência e outros métodos de alteração das configurações, consulte [Opções de configuração](command-options.md).
## Configurar o ambiente .NET no console do Elastic Beanstalk
É possível usar o console do Elastic Beanstalk para habilitar a alternância de logs para o Amazon S3, configurar variáveis que a aplicação pode ler no ambiente e alterar as configurações de framework .NET.
**Como configurar seu ambiente .NET no console do Elastic Beanstalk**
1. Abra o console do [Elastic](https://console.aws.amazon.com/elasticbeanstalk) Beanstalk e, **na** lista Regiões, selecione sua. Região da AWS
1. No painel de navegação, selecione **Ambientes** e selecione o nome do ambiente na lista.
1. No painel de navegação, escolha **Configuration (Configuração)**.
1. Na categoria de configuração **Updates, monitoring, and logging (Atualizações, monitoramento e logs)**, escolha **Edit (Editar)**.
### Opções de contêiner
+ **Target .NET runtime (runtime de .NET de destino)**: defina como `2.0` para executar CLR v2.
+ **Enable 32-bit applications (Habilitar aplicações 32 bits)**: defina como `True` para executar aplicações de 32 bits.
### Opções de log
A seção Log Options tem duas configurações:
+ **Instance profile (Perfil da instância)**: especifica o perfil da instância que tem permissão para acessar o bucket do Amazon S3 associado à sua aplicação.
+ **Habilitar a rotação de arquivos de log para o Amazon S3** — Especifica se os arquivos de log das EC2 instâncias da Amazon do seu aplicativo são copiados para o bucket do Amazon S3 associado ao seu aplicativo.
### Propriedades de ambiente
A seção **Propriedades do ambiente** permite que você especifique as configurações do ambiente nas EC2 instâncias da Amazon que estão executando seu aplicativo. Essas definições são passadas para o aplicativo como pares de chave-valor. Use `System.GetEnvironmentVariable` para leitura. Chaves idênticas podem existir em `web.config` e como propriedades do ambiente. Use o namespace `System.Configuration` para ler valores de `web.config`.
```
NameValueCollection appConfig = ConfigurationManager.AppSettings;
string endpoint = appConfig["API_ENDPOINT"];
```
Consulte [Variáveis de ambiente e outras configurações de software](environments-cfg-softwaresettings.md) para obter mais informações.
## O namespace aws:elasticbeanstalk:container:dotnet:apppool
Você pode usar um [arquivo de configuração](ebextensions.md) para definir opções de configuração e executar outras tarefas de configuração de instância durante implantações. Opções de configuração podem ser [específicas da plataforma](command-options-specific.md) ou aplicáveis a [todas as plataformas](command-options-general.md) no serviço Elastic Beanstalk como um todo. As opções de configuração são organizadas em *namespaces*.
A plataforma .NET define opções no namespace `aws:elasticbeanstalk:container:dotnet:apppool` que você pode usar para configurar o runtime do .NET.
O arquivo de configuração de exemplo a seguir mostra as configurações de cada uma das opções disponíveis neste namespace:
**Example .ebextensions/dotnet-settings.config**
```
option_settings:
aws:elasticbeanstalk:container:dotnet:apppool:
Target Runtime: 2.0
Enable 32-bit Applications: True
```
O Elastic Beanstalk oferece muitas opções de configuração para personalizar o ambiente. Além de arquivos de configuração, você também pode definir opções de configuração usando o console, configurações salvas, a EB CLI ou a AWS CLI. Consulte [Opções de configuração](command-options.md) para obter mais informações.
# Migrar entre versões principais da plataforma do Windows Server do Elastic Beanstalk
AWS Elastic Beanstalk teve várias versões principais de sua plataforma Windows Server. Esta página aborda as principais melhorias para cada versão principal e o que deve ser considerado antes de migrar para uma versão mais recente.
A plataforma do Windows Server está na versão 2 (v2) no momento. Se o aplicativo usar qualquer versão de plataforma do Windows Server anterior à v2, recomendamos migrar para a v2.
## Novidades das versões principais da plataforma do Windows Server
### Plataforma do Windows Server V2
A versão 2 (v2) da plataforma Windows Server do Elastic Beanstalk foi [lançada em fevereiro de 2019](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2019-02-21-windows-v2.html). A V2 aproxima o comportamento da plataforma Windows Server das plataformas Linux do Elastic Beanstalk de várias maneiras importantes. A V2 é totalmente compatível com a v1, o que facilita a migração da v1.
Agora, a plataforma do Windows Server oferece suporte a:
+ *Versionamento*: cada versão obtém um novo número de versão, e você pode fazer referência às versões anteriores (que ainda estão disponíveis para você) ao criar e gerenciar ambientes.
+ *Integridade aprimorada*: para obter detalhes, consulte [Relatórios e monitoramento de integridade aprimorados no Elastic Beanstalk](health-enhanced.md).
+ Implantações *imutáveis* e *contínuas com um lote adicional*: para obter detalhes sobre as políticas de implantação, consulte [Implantar aplicações em ambientes do Elastic Beanstalk](using-features.deploy-existing-version.md).
+ *Atualizações imutáveis*: para obter detalhes sobre os tipos de atualização, consulte [Alterações de configuração](environments-updating.md).
+ *Atualizações gerenciadas de plataforma*: para obter detalhes, consulte [Atualizações gerenciadas de plataforma](environment-platform-update-managed.md).
**nota**
Os novos recursos de implantação e atualização dependem da integridade aprimorada. Habilite a integridade aprimorada para usá-los. Para obter mais detalhes, consulte [Habilitar relatórios de integridade aprimorada do Elastic Beanstalk](health-enhanced-enable.md).
### Plataforma do Windows Server V1
A versão 1.0.0 (v1) da plataforma Windows Server do Elastic Beanstalk foi lançada em outubro de 2015. Essa versão altera a ordem na qual o Elastic Beanstalk processa comandos em [arquivos de configuração](ebextensions.md) durante a criação e as atualizações do ambiente.
As versões de plataformas anteriores não têm um número de versão no nome da pilha de soluções:
+ Windows Server 2012 R2 de 64 bits executando IIS 8.5
+ Windows Server Core 2012 R2 de 64 bits executando IIS 8.5
+ Windows Server 2012 de 64 bits executando IIS 8
+ Windows Server 2008 R2 de 64 bits executando IIS 7.5
Em versões anteriores, a ordem de processamento dos arquivos de configuração é inconsistente. Durante a criação do ambiente, `Container Commands` executam depois que o código-fonte do aplicativo é implantado no IIS. Durante uma implantação em um ambiente em execução, os comandos de contêiner executam antes da implantação da nova versão. Durante uma expansão, os arquivos de configuração não são processados.
Além disso, o IIS inicia antes da execução dos comandos de contêiner. Esse comportamento levou alguns clientes a implementar soluções em comandos de contêiner, pausando o servidor IIS antes da execução dos comandos e reiniciando-o após a conclusão.
A versão 1 corrige a inconsistência e aproxima o comportamento da plataforma Windows Server ao das plataformas baseadas em Linux do Elastic Beanstalk. Na plataforma v1, o Elastic Beanstalk sempre executa comandos de contêiner antes de iniciar o servidor IIS.
As pilhas de soluções da plataforma v1 têm um `v1` após a versão do Windows Server:
+ Windows Server 2012 R2 v1.1.0 de 64 bits executando IIS 8.5
+ Windows Server Core 2012 R2 v1.1.0 de 64 bits executando IIS 8.5
+ Windows Server 2012 v1.1.0 de 64 bits executando IIS 8
+ Windows Server 2008 R2 v1.1.0 de 64 bits executando IIS 7.5
Além disso, a plataforma v1 extrai o conteúdo do pacote de origem do aplicativo em `C:\staging\` antes da execução de comandos de contêiner. Após a conclusão dos comandos de contêiner, o conteúdo dessa pasta é compactado em um arquivo .zip e implantado no IIS. Esse fluxo de trabalho permite que você modifique o conteúdo do pacote de origem do aplicativo com comandos ou com um script antes da implantação.
## Migrar de versões principais anteriores da plataforma do Windows Server
Leia esta seção sobre considerações de migração antes de atualizar seu ambiente. Para atualizar a plataforma de seu ambiente para uma versão mais recente, visite [Atualizar a versão de plataforma do ambiente Elastic Beanstalk](using-features.platform.upgrade.md).
### De V1 para V2
A plataforma v2 do Windows Server não oferece suporte a .NET Core 1.x e 2.0. Se você está migrando o aplicativo do Windows Server v1 para v2 e o aplicativo usa uma dessas versões do .NET Core, atualize o aplicativo para uma versão do .NET Core que ofereça suporte a v2. Para obter uma lista de versões compatíveis, consulte [.NET no Windows Server com IIS](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) nas *Plataformas do AWS Elastic Beanstalk *.
Se o aplicativo usar uma imagem de máquina da Amazon (AMI), crie uma nova AMI personalizada com base em uma AMI da plataforma Windows Server v2. Para saber mais, consulte [Usar uma imagem de máquina Amazon personalizada (AMI) no ambiente Elastic Beanstalk](using-features.customenv.md).
**nota**
Os recursos de implantação e atualização que são novos no Windows Server v2 dependem da integridade aprimorada. Ao migrar um ambiente para v2, a integridade aprimorada é desabilitada. Habilite-a para usar esses recursos. Para obter mais detalhes, consulte [Habilitar relatórios de integridade aprimorada do Elastic Beanstalk](health-enhanced-enable.md).
### Da pré-V1
Além das considerações sobre a migração de v1, se você estiver migrando o aplicativo de uma pilha de soluções do Windows Server anterior à v1 e estiver usando comandos de contêiner, remova todos os comandos adicionados para resolver as inconsistências de processamento ao migrar para uma versão mais recente. A partir da v1, é garantido que os comandos de contêiner sejam executados completamente antes da origem do aplicativo implantado e antes do início do IIS. Isso permite que você faça qualquer alteração na origem em `C:\staging` e modifique os arquivos de configuração do IIS durante esta etapa sem problemas.
Por exemplo, você pode usar o AWS CLI para baixar um arquivo DLL para a fonte do seu aplicativo a partir do Amazon S3:
`.ebextensions\copy-dll.config`
```
container_commands:
copy-dll:
command: aws s3 cp s3://amzn-s3-demo-bucket/dlls/large-dll.dll .\lib\
```
Para obter mais informações sobre o uso de arquivos de configuração, consulte [Personalização avançada de ambiente com arquivos de configuração (`.ebextensions`)](ebextensions.md).
# Executar vários aplicativos e aplicativos ASP.NET Core com um manifesto de implantação
É possível usar um manifesto de implantação para informar o Elastic Beanstalk como implantar a aplicação. Ao usar esse método, você não precisa usar `MSDeploy` para gerar um pacote de origem para uma única aplicação ASP.NET que é executada no caminho raiz do seu site. Em vez disso, você pode usar um arquivo de manifesto para executar várias aplicações em caminhos diferentes. Ou, como alternativa, você pode dizer ao Elastic Beanstalk para implantar e executar a aplicação com o ASP.NET Core. Também é possível usar um manifesto de implantação para configurar um grupo de aplicações para executar suas aplicações.
Os manifestos de implantação adicionam suporte para [aplicações .NET Core](#dotnet-manifest-dotnetcore) ao Elastic Beanstalk. Você pode implantar uma aplicação .NET Framework sem um manifesto de implantação. No entanto, as aplicações .NET Core exigem um manifesto de implantação para execução no Elastic Beanstalk. Ao usar um manifesto de implantação, você cria um arquivo do site para cada aplicação e, em seguida, empacota os arquivos do site em um segundo arquivo ZIP que contém o manifesto de implantação.
Os manifestos de implantação também adicionam a capacidade de [executar vários aplicativos em diferentes caminhos](#dotnet-manifest-multiapp). Um manifesto de implantação define um conjunto de alvos de implantação, cada um com um arquivamento do site e um caminho em que o IIS deve executá-lo. Por exemplo, você pode executar uma API da Web no caminho `/api` para atender a solicitações assíncronas e um aplicativo web no caminho raiz que consome a API.
É possível usar um manifesto de implantação para [configurar sites do IIS com vinculações personalizadas e caminhos físicos](#dotnet-manifest-websites). Isso permite configurar sites que recepcionam portas ou nomes de host específicos antes de implantar aplicações.
Você também pode usar um manifesto de implantação para [executar várias aplicações usando grupos de aplicações no IIS ou no Kestrel](#dotnet-manifest-apppool). Você pode configurar um grupo de aplicativos para reiniciar seus aplicativos periodicamente, executar aplicativos de 32 bits ou usar uma versão específica do runtime do .NET Framework.
Para uma personalização completa, você pode [escrever seus próprios scripts de implantação](#dotnet-manifest-custom) no Windows PowerShell e informar ao Elastic Beanstalk quais scripts executar para instalar, desinstalar e reiniciar seu aplicativo.
Os manifestos de implantação e os recursos relacionados exigem uma plataforma do Windows Server [versão 1.2.0 ou posterior](dotnet-v2migration.md).
Para obter informações detalhadas sobre todas as opções de configuração, propriedades e recursos avançados disponíveis, como ignorar redefinições do IIS, consulte a [referência do esquema do manifesto de implantação](dotnet-manifest-schema.md).
**Topics**
+ [Aplicativos .NET Core](#dotnet-manifest-dotnetcore)
+ [Executar vários aplicativos](#dotnet-manifest-multiapp)
+ [Configurar sites do IIS](#dotnet-manifest-websites)
+ [Usar o Roteamento de solicitação de aplicação (ARR)](#dotnet-manifest-arr)
+ [Configurar grupos de aplicativos](#dotnet-manifest-apppool)
+ [Definir implantações personalizadas](#dotnet-manifest-custom)
+ [Referência de esquema de manifesto de implantação](dotnet-manifest-schema.md)
## Aplicativos .NET Core
É possível usar um manifesto de implantação para executar aplicações .NET Core no Elastic Beanstalk. .NET Core é uma versão multiplataforma do .NET que é fornecida com uma ferramenta de linha de comando (`dotnet`). Você pode usá-lo para gerar uma aplicação, executá-lo localmente e prepará-lo para publicação.
Para executar uma aplicação .NET Core no Elastic Beanstalk, execute `dotnet publish` e empacote a saída em um arquivo ZIP, sem incluir os diretórios. Coloque o arquivo do site em um pacote de origem com um manifesto de implantação com um destino de implantação do tipo `aspNetCoreWeb`.
O seguinte manifesto de implantação executa um aplicativo .NET Core em um arquivo de site chamado `dotnet-core-app.zip` no caminho raiz.
**Example aws-windows-deployment-manifest.json - Núcleo.NET**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"archive": "dotnet-core-app.zip",
"iisPath": "/"
}
}
]
}
}
```
Inclua o arquivo de manifesto e de site em um arquivo ZIP para criar um pacote de origem.
**Example dotnet-core-bundle.zip**
```
.
|-- aws-windows-deployment-manifest.json
`-- dotnet-core-app.zip
```
O arquivo do site contém o código do aplicativo compilado, as dependências e o arquivo `web.config`.
**Example dotnet-core-app.zip**
```
.
|-- Microsoft.AspNetCore.Hosting.Abstractions.dll
|-- Microsoft.AspNetCore.Hosting.Server.Abstractions.dll
|-- Microsoft.AspNetCore.Hosting.dll
|-- Microsoft.AspNetCore.Http.Abstractions.dll
|-- Microsoft.AspNetCore.Http.Extensions.dll
|-- Microsoft.AspNetCore.Http.Features.dll
|-- Microsoft.AspNetCore.Http.dll
|-- Microsoft.AspNetCore.HttpOverrides.dll
|-- Microsoft.AspNetCore.Server.IISIntegration.dll
|-- Microsoft.AspNetCore.Server.Kestrel.dll
|-- Microsoft.AspNetCore.WebUtilities.dll
|-- Microsoft.Extensions.Configuration.Abstractions.dll
|-- Microsoft.Extensions.Configuration.EnvironmentVariables.dll
|-- Microsoft.Extensions.Configuration.dll
|-- Microsoft.Extensions.DependencyInjection.Abstractions.dll
|-- Microsoft.Extensions.DependencyInjection.dll
|-- Microsoft.Extensions.FileProviders.Abstractions.dll
|-- Microsoft.Extensions.FileProviders.Physical.dll
|-- Microsoft.Extensions.FileSystemGlobbing.dll
|-- Microsoft.Extensions.Logging.Abstractions.dll
|-- Microsoft.Extensions.Logging.dll
|-- Microsoft.Extensions.ObjectPool.dll
|-- Microsoft.Extensions.Options.dll
|-- Microsoft.Extensions.PlatformAbstractions.dll
|-- Microsoft.Extensions.Primitives.dll
|-- Microsoft.Net.Http.Headers.dll
|-- System.Diagnostics.Contracts.dll
|-- System.Net.WebSockets.dll
|-- System.Text.Encodings.Web.dll
|-- dotnet-core-app.deps.json
|-- dotnet-core-app.dll
|-- dotnet-core-app.pdb
|-- dotnet-core-app.runtimeconfig.json
`-- web.config
```
## Executar vários aplicativos
Você pode executar vários aplicativos com um manifesto de implantação definindo vários alvos de implantação.
O seguinte manifesto de implantação configura dois aplicativos .NET Core. A aplicação `WebApiSampleApp` implementa uma API simples da Web e atende a solicitações assíncronas no caminho `/api`. O aplicativo `DotNetSampleApp` é um aplicativo web que atende solicitações no caminho raiz.
**Example aws-windows-deployment-manifest.json - vários aplicativos**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "WebAPISample",
"parameters": {
"appBundle": "WebApiSampleApp.zip",
"iisPath": "/api"
}
},
{
"name": "DotNetSample",
"parameters": {
"appBundle": "DotNetSampleApp.zip",
"iisPath": "/"
}
}
]
}
}
```
Um aplicativo de exemplo com vários aplicativos está disponível em:
+ **Pacote de origem implantável -** [-v2.zip dotnet-multiapp-sample-bundle](samples/dotnet-multiapp-sample-bundle-v2.zip)
+ **Código fonte** - [dotnet-multiapp-sample-source-v2.zip](samples/dotnet-multiapp-sample-source-v2.zip)
## Configurar sites do IIS
É possível configurar sites do IIS com vinculações personalizadas e caminhos físicos usando o manifesto de implantação. Isso é útil quando é necessário configurar sites que recepcionam em portas específicas, usam nomes de host personalizados ou veiculam conteúdo de diretórios específicos.
O manifesto de implantação a seguir configura um site personalizado do IIS que recepciona HTTP com um número de porta específico e um caminho físico personalizado:
**Example aws-windows-deployment-manifest.json - Configuração do site IIS**
```
{
"manifestVersion": 1,
"iisConfig": {
"websites": [
{
"name": "MyCustomSite",
"physicalPath": "C:\inetpub\wwwroot\mysite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "mysite.local"
}
]
}
]
},
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"appBundle": "dotnet-core-app.zip",
"iisWebSite": "MyCustomSite",
"iisPath": "/"
}
}
]
}
}
```
Neste exemplo:
+ Um site chamado "MyCustomSite" é criado com um caminho físico personalizado
+ O site tem uma associação HTTP na porta 8080 com um nome de host específico
+ A aplicação ASP.NET Core é implantada nesse site personalizado usando o parâmetro `iisWebSite`
## Usar o Roteamento de solicitação de aplicação (ARR)
Os módulos Application Request Routing (ARR) e URL Rewrite estão pré-instalados e disponíveis no Elastic Beanstalk Windows. AMIs Esses módulos permitem cenários avançados de roteamento e manipulação de URL por meio da configuração do IIS usando a configuração de ebextensions ou aplicações.
O exemplo a seguir mostra um manifesto de implantação simples que configura um site com uma porta personalizada, combinado com uma configuração ebextensions que configura o roteamento do ARR básico:
**Example aws-windows-deployment-manifest.json - Configuração simples de ARR**
```
{
"manifestVersion": 1,
"iisConfig": {
"websites": [
{
"name": "ARRSite",
"physicalPath": "C:\\inetpub\\wwwroot\\arrsite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "localhost"
}
]
}
]
},
"deployments": {
"aspNetCoreWeb": [
{
"name": "BackendApp",
"parameters": {
"appBundle": "backend-app.zip",
"iisWebSite": "ARRSite",
"iisPath": "/backend"
}
}
]
}
}
```
A configuração do ARR é feita por meio de ebextensions. A configuração a seguir define as regras básicas de roteamento do ARR:
**Example .ebextensions/arr-config.config - Configuração básica do ARR**
```
files:
"C:\\temp\\configure-arr.ps1":
content: |
# Enable ARR proxy at server level
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/proxy' -Name 'enabled' -Value 'True'
# Clear any existing global rules to avoid conflicts
Clear-WebConfiguration -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/rewrite/globalRules'
# Add global rule to route all requests to backend
Add-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
-Filter 'system.webServer/rewrite/globalRules' `
-Name '.' `
-Value @{
name = 'Route_to_Backend'
stopProcessing = 'True'
match = @{ url = '^(?!backend/)(.*)' }
action = @{
type = 'Rewrite'
url = 'http://localhost:8080/backend/{R:1}'
}
}
container_commands:
01_configure_arr:
command: powershell -ExecutionPolicy Bypass -File "C:\\temp\\configure-arr.ps1"
waitAfterCompletion: 0
```
Essa configuração cria um site na porta 8080 e configura o ARR para rotear todas as solicitações recebidas para a aplicação de backend executada nesse site.
## Configurar grupos de aplicativos
Você pode oferecer suporte a várias aplicações no seu ambiente Windows. Duas abordagens estão disponíveis:
+ Você pode usar o modelo de out-of-process hospedagem com o servidor web Kestrel. Com esse modelo, você configura várias aplicações para serem executadas em um grupo de aplicações.
+ Você pode usar o modelo de hospedagem no processo. Com esse modelo, você usa vários grupos de aplicações para executar várias aplicações com apenas uma aplicação em cada grupo. Se você estiver usando o servidor IIS e precisar executar várias aplicações, deverá usar essa abordagem.
Para configurar o Kestrel para executar várias aplicações em um grupo de aplicações, adicione `hostingModel="OutofProcess"` ao arquivo `web.config`. Considere os seguintes exemplos:
**Example web.config - para o modelo de hospedagem Kestrel out-of-process**
```
```
**Example aws-windows-deployment-manifest.json - vários aplicativos**
```
{
"manifestVersion": 1,
"deployments": {"msDeploy": [
{"name": "Web-app1",
"parameters": {"archive": "site1.zip",
"iisPath": "/"
}
},
{"name": "Web-app2",
"parameters": {"archive": "site2.zip",
"iisPath": "/app2"
}
}
]
}
}
```
O IIS não suporta várias aplicações em um grupo de aplicações porque ele usa o modelo de hospedagem no processo. Portanto, você precisa configurar várias aplicações atribuindo cada aplicação a um grupo de aplicações. Em outras palavras, atribua apenas uma aplicação a um grupo de aplicações.
Você pode configurar o IIS para usar grupos de aplicações diferentes no arquivo `aws-windows-deployment-manifest.json`. Faça as seguintes atualizações conforme você se refere ao próximo arquivo de exemplo:
+ Adicione uma `iisConfig` seção que inclua uma subseção chamada `appPools`.
+ No bloco `appPools`, liste os grupos de aplicações.
+ Na seção `deployments`, defina uma seção `parameters` para cada aplicação.
+ Para cada aplicação, a seção `parameters` especifica um arquivo, um caminho para executá-la e um `appPool` no qual executá-la.
O manifesto de implantação a seguir configura dois grupos de aplicações que reiniciam sua aplicação a cada 10 minutos. Eles também anexam suas aplicações a uma aplicação web .NET Framework que é executada no caminho especificado.
**Example aws-windows-deployment-manifest.json - um aplicativo por pool de aplicativos**
```
{
"manifestVersion": 1,
"iisConfig": {"appPools": [
{"name": "MyFirstPool",
"recycling": {"regularTimeInterval": 10}
},
{"name": "MySecondPool",
"recycling": {"regularTimeInterval": 10}
}
]
},
"deployments": {"msDeploy": [
{"name": "Web-app1",
"parameters": {
"archive": "site1.zip",
"iisPath": "/",
"appPool": "MyFirstPool"
}
},
{"name": "Web-app2",
"parameters": {
"archive": "site2.zip",
"iisPath": "/app2",
"appPool": "MySecondPool"
}
}
]
}
}
```
## Definir implantações personalizadas
Para controle ainda maior, você pode personalizar totalmente a implantação de um aplicativo definindo uma *implantação personalizada*.
Esse manifesto de implantação instrui o Elastic Beanstalk PowerShell a executar scripts no modo de 32 bits. Ele especifica três scripts: um `install` script (`siteInstall.ps1`) que é executado durante a inicialização e as implantações da instância, um `uninstall` script (`siteUninstall.ps1`) que é executado antes de instalar novas versões durante as implantações e um `restart` script (`siteRestart.ps1`) que é executado quando você seleciona [Reiniciar o App Server](environments-dashboard-actions.md) no console de gerenciamento. AWS
**Example aws-windows-deployment-manifest.json - implantação personalizada**
```
{
"manifestVersion": 1,
"deployments": {
"custom": [
{
"name": "Custom site",
"architecture" : 32,
"scripts": {
"install": {
"file": "siteInstall.ps1"
},
"restart": {
"file": "siteRestart.ps1"
},
"uninstall": {
"file": "siteUninstall.ps1"
}
}
}
]
}
}
```
Inclua todos os artefatos necessários para executar o aplicativo em seu pacote de origem com o manifesto e os scripts.
**Example ustom-site-bundleC.zip**
```
.
|-- aws-windows-deployment-manifest.json
|-- siteInstall.ps1
|-- siteRestart.ps1
|-- siteUninstall.ps1
`-- site-contents.zip
```
# Referência de esquema de manifesto de implantação
O manifesto de implantação é um arquivo JSON que define como o Elastic Beanstalk deve implantar e configurar suas aplicações Windows. Esta seção fornece uma referência abrangente para todas as propriedades e opções de configuração compatíveis no esquema do manifesto.
## Estrutura do manifesto
O manifesto de implantação segue um esquema JSON específico com a seguinte estrutura de nível superior:
**Example Estrutura básica do manifesto**
```
{
"manifestVersion": 1,
"skipIISReset": false,
"iisConfig": {
"websites": [...],
"appPools": [...]
},
"deployments": {
"msDeploy": [...],
"aspNetCoreWeb": [...],
"custom": [...]
}
}
```
### Propriedades de nível superior
`manifestVersion`(obrigatório)
*Tipo*: número
*Padrão*: 1
*Valores válidos:* 1
Especifica a versão do esquema do manifesto. Atualmente, apenas a versão 1 é compatível.
`skipIISReset` (opcional)
*Tipo*: booliano
*Padrão:* falso
Controla se o IIS é redefinido durante as implantações da aplicação. Esse sinalizador afeta ambos os tipos de implantação: `msDeploy` e `aspNetCoreWeb`.
*Comportamento:*
+ *Não especificado ou `false` (padrão):* as redefinições do IIS são realizadas durante as operações de instalação, desinstalação e atualização. Esse é o comportamento tradicional.
+ *`true`:* as redefinições do IIS são ignoradas durante as operações de implantação.
*Benefícios:*
+ *Tempo de inatividade reduzido*: as aplicações sofrem menos interrupções de serviço durante as implantações.
+ *Implantações mais rápidas*: elimina o tempo necessário para que o IIS seja totalmente reiniciado e reinicializado.
Ao usar`skipIISReset`, a [RestartAppServer](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RestartAppServer.html)operação executa uma redefinição do IIS independentemente dessa configuração de sinalizador.
*Exemplo:*
```
{
"manifestVersion": 1,
"skipIISReset": true,
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"archive": "dotnet-core-app.zip",
"iisPath": "/"
}
}
]
}
}
```
`deployments`(obrigatório)
*Tipo:* Objeto
Contém as configurações de implantação para suas aplicações. Esse objeto pode incluir os tipos de implantação `msDeploy`, `aspNetCoreWeb` e `custom`.
`iisConfig` (opcional)
*Tipo:* Objeto
Define as configurações do IIS a serem aplicadas antes da implantação das aplicações. Oferece suporte à configuração do site e do grupo de aplicações.
## Configuração do IIS
A seção `iisConfig` permite que você defina as configurações do IIS antes de implantar suas aplicações. Isso inclui a configuração de grupos de aplicações com configurações específicas e a configuração de sites do IIS com associações personalizadas.
### Sites do IIS
Sites do IIS permitem que você defina configurações personalizadas do site, incluindo caminhos físicos e associações de rede, antes de implantar suas aplicações.
**Considerações importantes para criar sites diferentes do IIS**
*Ordem de configuração de sites:* os sites são configurados sequencialmente na ordem em que aparecem na matriz `websites`. A plataforma processa cada configuração do site em sequência, portanto, garanta o pedido adequado se você tiver dependências entre os sites.
*Firewall e acesso à porta:* somente a porta 80 é automaticamente exposta por meio da configuração padrão de firewall do Elastic Beanstalk para Windows. Se você configurar sites para usar portas não padrão, deverá definir regras de firewall personalizadas por meio de ebextensions ou scripts de implantação personalizados para permitir acesso externo a essas portas.
**Example Configuração de site**
```
{
"iisConfig": {
"websites": [
{
"name": "MyCustomSite",
"physicalPath": "C:\inetpub\wwwroot\mysite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "mysite.local"
},
{
"protocol": "https",
"port": 8443
}
]
}
]
}
}
```Propriedades do site
`name`(obrigatório)
*Tipo:* string
O nome do site do IIS. Esse nome é usado para identificar o site no Gerenciador do IIS e deve ser exclusivo na configuração do IIS.
`physicalPath`(obrigatório)
*Tipo:* string
O caminho físico no servidor no qual os arquivos do site são armazenados. Esse caminho deve estar acessível ao processo de trabalho do IIS.
`bindings`(obrigatório)
*Tipo*: matriz
*Itens mínimos:* 1
Uma variedade de configurações de vinculação que definem como o site responde a solicitações de rede. Cada associação especifica um protocolo, uma porta e um nome de host opcional.
#### Associações de sites
As associações de sites definem os endpoints de rede nos quais o site do IIS escutará as solicitações recebidas.
`protocol`(obrigatório)
*Tipo:* string
*Valores válidos:* “http”, “https”
O protocolo usado para a vinculação.
`port`(obrigatório)
*Tipo*: inteiro
*Intervalo válido: 1-65535*
O número da porta na qual o site receberá solicitações.
`hostName` (opcional)
*Tipo:* string
O nome do host (nome de domínio) para a associação.
### Grupos de aplicações
Os grupos de aplicações fornecem isolamento entre aplicações e permitem que você defina as configurações de runtime para grupos de aplicações.
**Example Configuração do grupo de aplicações**
```
{
"iisConfig": {
"appPools": [
{
"name": "MyAppPool",
"enable32Bit": false,
"managedPipelineMode": "Integrated",
"managedRuntimeVersion": "v4.0",
"queueLength": 1000,
"cpu": {
"limitPercentage": 80,
"limitAction": "Throttle",
"limitMonitoringInterval": 5
},
"recycling": {
"regularTimeInterval": 1440,
"requestLimit": 10000,
"memory": 1048576,
"privateMemory": 524288
}
}
]
}
}
```Propriedades do grupo de aplicações
`name`(obrigatório)
*Tipo:* string
O nome do grupo de aplicações. Esse nome é usado para referenciar o grupo nas configurações de implantação.
`enable32Bit` (opcional)
*Tipo*: booliano
Permite que uma aplicação de 32 bits seja executada em uma versão de 64 bits do Windows. Defina como `true` para aplicações legadas que exigem compatibilidade de 32 bits.
`managedPipelineMode` (opcional)
*Tipo:* string
*Valores válidos:* “Integrado”, “Clássico”
Especifica o modo de processamento de solicitações para o grupo de aplicações.
`managedRuntimeVersion` (opcional)
*Tipo:* string
*Valores válidos:* “Sem código gerenciado”, “v2.0", “v4.0"
Especifica a versão do .NET Framework para o grupo de aplicações.
`queueLength` (opcional)
*Tipo*: inteiro
Número máximo de solicitações que o HTTP.sys enfileira para o grupo de aplicações antes de rejeitar solicitações adicionais.
#### Configuração da CPU
O objeto `cpu` configura os limites de uso da CPU e o monitoramento do grupo de aplicações.
`limitPercentage` (opcional)
*Tipo*: número
Porcentagem máxima de tempo de CPU que os processos de trabalho no grupo de aplicações podem consumir.
`limitAction` (opcional)
*Tipo:* string
*Valores válidos:* "NoAction“, “KillW3wp”, “Throttle”, "” ThrottleUnderLoad
Ação a ser realizada quando o limite de CPU for atingido.
`limitMonitoringInterval` (opcional)
*Tipo*: número
Período de redefinição (em minutos) para monitoramento da CPU e limites de controle de utilização.
#### Configuração de reciclagem
O objeto `recycling` configura quando e como os processos de trabalho do grupo de aplicações são reciclados.
`regularTimeInterval` (opcional)
*Tipo*: inteiro
Intervalo de tempo (em minutos) após o qual o grupo de aplicações é reciclado. Defina como 0 para desabilitar a reciclagem baseada em tempo.
`requestLimit` (opcional)
*Tipo*: inteiro
Número máximo de solicitações que o grupo de aplicações processa antes da reciclagem.
`memory` (opcional)
*Tipo*: inteiro
Quantidade de memória virtual (em kilobytes) que aciona a reciclagem do processo de trabalho.
`privateMemory` (opcional)
*Tipo*: inteiro
Quantidade de memória privada (em kilobytes) que aciona a reciclagem do processo de trabalho.
## Tipos de implantação
O objeto `deployments` contém matrizes de configurações de implantação para diferentes tipos de aplicações. Cada tipo de implantação tem propriedades e casos de uso específicos.
### MSDeploy implantações
MSDeploy as implantações são usadas para aplicativos do.NET Framework tradicionais que podem ser implantados usando o Web Deploy ()MSDeploy.
**Example MSDeploy configuração de implantação**
```
{
"deployments": {
"msDeploy": [
{
"name": "WebApp",
"description": "Main web application",
"parameters": {
"appBundle": "webapp.zip",
"iisPath": "/",
"appPool": "DefaultAppPool"
}
}
]
}
}
```MSDeploy propriedades de implantação
`name`(obrigatório)
*Tipo:* string
Nome exclusivo da implantação. Esse nome deve ser exclusivo entre todas as implantações no manifesto.
`description` (opcional)
*Tipo:* string
Descrição legível por humanos da implantação.
`parameters`(obrigatório)
*Tipo:* Objeto
Parâmetros de configuração para a MSDeploy operação.
`scripts` (opcional)
*Tipo:* Objeto
PowerShell scripts para execução em vários estágios do ciclo de vida da implantação.
#### MSDeploy parâmetros
`appBundle`(obrigatório)
*Tipo:* string
Caminho para o pacote de aplicações (arquivo ZIP) em relação ao arquivo de manifesto. Esse pacote contém os arquivos da aplicação a serem implantados.
`iisWebSite` (opcional)
*Tipo:* string
*Padrão:* “Site padrão”
O site do IIS no qual implantar a aplicação. Por padrão, as aplicações são implantadas no “Site padrão”. Opcionalmente, você pode especificar um nome de site diferente, como aquele configurado na seção `iisConfig.websites`.
`iisPath` (opcional)
*Tipo:* string
*Padrão:* “/”
Caminho do diretório virtual no IIS em que a aplicação será implantada. Use “/” para o caminho raiz ou “/api” para um subdiretório.
`appPool` (opcional)
*Tipo:* string
Nome do grupo de aplicações para executar essa aplicação.
### Implantações do ASP.NET Core
As implantações ASP.NET Core são projetadas especificamente para aplicações .NET Core e o .NET 5\$1.
**Example Configuração da implantação de ASP.NET Core**
```
{
"deployments": {
"aspNetCoreWeb": [
{
"name": "CoreAPI",
"description": "ASP.NET Core Web API",
"parameters": {
"appBundle": "coreapi.zip",
"iisPath": "/api",
"appPool": "CoreAppPool"
}
}
]
}
}
```
As implantações do ASP.NET Core usam a mesma estrutura de propriedades das MSDeploy implantações, com a principal diferença sendo o ambiente de tempo de execução e o modelo de hospedagem usados para o aplicativo.Parâmetros da implantação de ASP.NET Core
`appBundle`(obrigatório)
*Tipo:* string
Caminho até o pacote de aplicações em relação ao arquivo manifesto. Pode ser um arquivo ZIP ou um caminho de diretório contendo a aplicação ASP.NET Core publicada.
`iisWebSite` (opcional)
*Tipo:* string
*Padrão:* “Site padrão”
O site do IIS no qual implantar a aplicação ASP.NET Core. Por padrão, as aplicações são implantadas no “Site padrão”. Opcionalmente, você pode especificar um nome de site diferente, como aquele configurado na seção `iisConfig.websites`.
`iisPath` (opcional)
*Tipo:* string
*Padrão:* “/”
Caminho de diretório virtual no IIS para a aplicação ASP.NET Core.
`appPool` (opcional)
*Tipo:* string
Grupo de aplicações da aplicação ASP.NET Core. O grupo será configurado adequadamente para hospedagem de ASP.NET Core.
### implantações personalizadas
As implantações personalizadas fornecem controle total sobre o processo de implantação por meio de PowerShell scripts. Esse tipo de implantação é útil para cenários complexos que exigem instalação, configuração ou lógica de implantação personalizadas.
**Example Configuração de implantação personalizada**
```
{
"deployments": {
"custom": [
{
"name": "CustomService",
"description": "Custom Windows service deployment",
"architecture": 32,
"scripts": {
"install": {
"file": "install-service.ps1"
},
"restart": {
"file": "restart-service.ps1"
},
"uninstall": {
"file": "uninstall-service.ps1",
"ignoreErrors": true
}
}
}
]
}
}
```Propriedades de implantação personalizadas
`name`(obrigatório)
*Tipo:* string
Nome exclusivo da implantação personalizada.
`description` (opcional)
*Tipo:* string
Descrição da implantação personalizada.
`architecture` (opcional)
*Tipo*: inteiro
*Padrão:* 32
*Valores válidos:* 32, 64
A especificação de arquitetura para o modo de execução de scripts do PowerShell
`scripts`(obrigatório)
*Tipo:* Objeto
PowerShell scripts que definem o comportamento da implantação. Implantações personalizadas oferecem suporte a tipos de script adicionais em comparação com outros tipos de implantação.
## Scripts de implantação
Os scripts de implantação são PowerShell scripts executados em pontos específicos durante o ciclo de vida da implantação. Diferentes tipos de implantação oferecem suporte a diferentes conjuntos de eventos de scripts.
### Eventos de script
Os seguintes eventos de scripts estão disponíveis dependendo do tipo de implantação:Scripts de implantação padrão (MSDeploy e aspNetCore Web)
`preInstall`
É executado antes que a aplicação seja instalada ou atualizada.
`postInstall`
É executado depois que a aplicação é instalada ou atualizada.
`preRestart`
É executado antes que a aplicação seja reiniciada.
`postRestart`
É executado depois que a aplicação é reiniciada.
`preUninstall`
É executado antes da desinstalação da aplicação.
`postUninstall`
É executado após a desinstalação da aplicação.Scripts de implantação personalizados (somente implantações personalizadas)
`install`
Script de instalação principal para implantações personalizadas. Esse script é responsável pela instalação da aplicação ou serviço.
`restart`
Script para reiniciar a aplicação ou serviço. Chamado quando o ambiente é reiniciado.
`uninstall`
Script para desinstalar a aplicação ou serviço. Chamado durante o encerramento do ambiente ou a remoção da aplicação.
### Propriedades do script
Cada script é definido como um objeto com as seguintes propriedades:
`file`(obrigatório)
*Tipo:* string
Caminho para o arquivo de PowerShell script em relação ao arquivo de manifesto. O script deve ter uma extensão `.ps1`.
`ignoreErrors` (opcional)
*Tipo*: booliano
*Padrão:* falso
Quando definido como `true`, a implantação continua mesmo se o script falhar. Use para scripts não críticos ou operações de limpeza.
**Example Exemplo de configuração de script**
```
{
"scripts": {
"preInstall": {
"file": "backup-config.ps1",
"ignoreErrors": true
},
"postInstall": {
"file": "configure-app.ps1"
}
}
}
```
# Usando o EC2 Fast Launch com ramificações da plataforma Windows
O recurso EC2 Fast Launch reduz os tempos de execução de instâncias do Windows em seus ambientes do Elastic Beanstalk. O objetivo deste tópico é orientar sobre como usar esse recurso com ambientes do Elastic Beanstalk. A partir da versão 2.16.2 da plataforma Windows, lançada em [22 de janeiro de 2025,](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2025-01-22-windows.html) os lançamentos da plataforma Elastic Beanstalk incluem base com o Fast Launch ativado. AMIs EC2
## Disponibilidade padrão de lançamento EC2 rápido
As versões mais recentes da plataforma Windows do Elastic Beanstalk AMIs incluem EC2 base com o Fast Launch ativado automaticamente, sem custos adicionais. No entanto, quando versões mais recentes da plataforma são lançadas, o EC2 Fast Launch pode não permanecer ativado automaticamente com base nas versões mais antigas AMIs da plataforma.
Recomendamos atualizar para a versão mais recente da plataforma Windows para usar o base AMIs com o EC2 Fast Launch ativado automaticamente. No entanto, se precisar continuar usando sua versão de plataforma existente, você pode habilitar manualmente o EC2 Fast Launch na AMI básica do seu ambiente. Para instruções, consulte [Configurando manualmente o EC2 Fast Launch](#dotnet-ec2fastlaunch-manual).
## Configurando manualmente o EC2 Fast Launch
**nota**
A ativação manual do EC2 Fast Launch pode gerar custos adicionais em comparação com o uso de versões da plataforma com o EC2 Fast Launch ativado automaticamente. Para obter mais informações sobre os custos do EC2 Fast Launch, consulte a página [Gerenciar custos dos recursos subjacentes do EC2 Fast Launch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-manage-costs.html) no *Guia EC2 do usuário da Amazon*.
Siga estas etapas para habilitar o EC2 Fast Launch em uma AMI baseada no Windows usada pelo seu ambiente do Elastic Beanstalk:
**Para habilitar manualmente o EC2 Fast Launch para seu ambiente Elastic Beanstalk**
1. Identifique a AMI base do seu ambiente:
Siga as etapas em [Criar uma AMI personalizada](using-features.customenv.md) para identificar o ID da AMI base do seu ambiente. Observe que não é necessário criar uma AMI personalizada. Basta seguir as etapas para localizar o ID da sua AMI base atual.
1. Ative o EC2 Fast Launch na AMI:
Use as instruções em [Habilitar o EC2 Fast Launch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-configure.html) no *Guia EC2 do usuário da Amazon* para configurar o EC2 Fast Launch para sua AMI.