Personalizar o plano de migração de serviços IIS do Windows
Revise o arquivo do plano de migração que foi preenchido durante a criação da migração. É possível personalizá-lo antes de continuar a migração. Os detalhes do plano de migração são usados para extrair da VM de origem os artefatos de contêiner da carga de trabalho.
Nesta seção, descrevemos o conteúdo do plano de migração e os tipos de personalização disponíveis antes de executar a migração e gerar artefatos de implantação.
Antes de começar
Neste documento, consideramos que você já criou um plano de migração e tem o arquivo resultante dele.
Estrutura do plano de migração
Veja a seguir a estrutura completa do plano de migração. Nas próximas seções, explicaremos essa estrutura, o que é cada parte e como modificá-la.
globalSettings:
globalIis:
enablegmsa: string
apppools:
- enable32bitapponwin64: bool
identitytype: string
managedruntimeversion: string
name: string
connectionStrings:
add:
- connectionstring: string
name: string
providername: string
security:
authentication:
windowsAuthentication:
enabled: bool
providers:
- value: string
authorization:
add:
- access_type: string
roles: string
users: string
verbs: string
remove:
- roles: string
users: string
verbs: string
image:
extraFeatures:
- string
target:
baseVersion: string
requirements:
- string
warnings:
- string
msvcRuntimes:
- string
pathEnvVarAdditionalEntries:
- string
images:
- name: string
probes:
enabled: bool
livenessProbe:
probehandler:
exec:
command:
- string
- string
initialdelayseconds: int
timeoutseconds: int
periodseconds: int
successthreshold: int
failurethreshold: int
terminationgraceperiodseconds: optional[int]
readinessProbe:
probehandler:
exec:
command:
- string
- string
initialdelayseconds: int
timeoutseconds: int
periodseconds: int
successthreshold: int
failurethreshold: int
terminationgraceperiodseconds: optional[int]
useractions:
files:
- source: string
target: string
registry:
currentcontrolset:
- path: string
software:
- path: string
workloads:
sites:
site:
- applications:
- applicationpool: string
path: string
virtualdirectories:
- path: string
physicalpath: string
bindings:
- port: int
protocol: string
sslflags: int
connectionstrings:
- connectionstring: string
name: string
providername: string
name: string
security:
authentication:
windowsAuthentication:
enabled: bool
providers:
- value: string
authorization:
add:
- access_type: string
roles: string
users: string
verbs: string
remove:
- roles: string
users: string
verbs: string
serverautostart: bool
version: string
Seção globalSettings
A seção globalSettings descreve os requisitos básicos para pods que executam sites do IIS desta VM. O processo de descoberta pesquisa configurações gerais na VM de origem e as usa para preencher essa seção. Essas configurações contêm campos presentes nas configurações de imagem específicas, conforme descrito na seção a seguir, e afetam todas as imagens ao mesmo tempo.
Seção image
A seção image em globalSettings descreve a lista de recursos do Windows para instalação nos pods. O processo de descoberta preenche essa seção com todos os recursos do Windows que existem na VM original e podem ser instalados em um contêiner do Windows.
Seção msvcRuntimes
Ao migrar um aplicativo, ele pode ter uma dependência de uma ou mais versões específicas do ambiente de execução do Microsoft Visual C++ (MSVCRT). O Migrate to Containers detecta automaticamente os ambientes de execução instalados na VM de origem e os inclui no plano de migração.
É possível modificar a lista de ambientes de execução no plano de migração adicionando ou
removendo membros de msvcRuntimes:
Veja a lista completa de valores possíveis: O ambiente de execução de 2015 também inclui suporte para 2017, 2019 e 2022.
msvcRuntimes:
- MSVC2012_x64
- MSVC2013_x64
- MSVC2015_x64
- MSVC2012_x86
- MSVC2013_x86
- MSVC2015_x86
Seção pathEnvVarAdditionalEntries
Os aplicativos IIS do Windows podem ter entradas de variável de ambiente PATH não padrão, que são detectadas automaticamente na VM de origem e incluídas no plano de migração. É possível modificar as variáveis de ambiente PATH editando os membros de pathEnvVarAdditionalEntries:
pathEnvVarAdditionalEntries:
- "C:\\myDllsFolder"
- "C:\\ProgramData\\SomeSoftware"
Editar a seção de imagem
Convém editar a seção image nos seguintes casos:
Alguns recursos sugeridos não serão requisitados pelos sites migrados. Isso acontece quando a VM de origem tem outros usos além de hospedar sites do IIS.
Você modificou as seções IIS do plano de migração e adicionou configurações que dependem de outros recursos do Windows. Por exemplo, a autenticação do Windows depende do recurso de autenticação do Windows.
Seção target
A seção target especifica qual imagem base do Windows você usa (por exemplo, 1909). Editar esse campo é raramente necessário.
Seção images
Cada subitem da seção images especifica uma única imagem de saída.
No zip de artefatos, cada uma dessas imagens tem um subdiretório separado, com Dockerfile e deployment_spec.yaml próprios. Consulte Como implantar a imagem do contêiner.
Campo name
O campo name descreve o nome da imagem.
Ele afeta o nome do subdiretório da imagem e o arquivo deployment_spec.yaml nos artefatos.
Campo probes
O campo probes descreve a configuração da sondagem de integridade da imagem. Para saber mais sobre as sondagens do kubelet, consulte Configurar sondagens de atividade, prontidão e inicialização.
Editar sondagens de integridade do IIS
As sondagens de integridade podem monitorar a inatividade e o status pronto dos contêineres gerenciados. O monitoramento da sondagem de integridade pode ajudar a reduzir a inatividade dos contêineres migrados e oferecer um monitoramento melhor.
Os estados de integridade desconhecidos podem gerar degradação de disponibilidade, monitoramento de disponibilidade com falsos positivos e possível perda de dados. Sem uma sondagem de integridade, o kubelet só pode pressupor a integridade de um contêiner e enviar o tráfego para uma instância que não está pronta. Se a instância não estiver pronta, isso pode causar perda de tráfego. O kubelet também pode não detectar contêineres que estejam no estado congelado e não os reinicia.
Uma sondagem de integridade funciona executando uma pequena instrução de script quando o contêiner é iniciado. O script verifica se há condições de sucesso, aquelas definidas pelo tipo de sondagem usada em cada período. O período é definido no plano de migração por um campo do periodSeconds. É possível definir essas sondagens manualmente ao personalizar o plano de migração.
Há três tipos de sondagens disponíveis para configuração. Todas as sondagens são "probe v1 core", definidas na referência "probe v1 core", e compartilham a mesma função que os campos correspondentes de "container v1 core".
*Sondagem de atividade: é usada para saber quando reiniciar um contêiner.
Sondagem de prontidão: é usada para saber quando um contêiner está pronto para começar a aceitar tráfego. Para começar a enviar tráfego a um pod somente quando a sondagem for bem-sucedida, especifique uma sondagem de prontidão. Uma sondagem de prontidão pode agir de maneira semelhante a uma sondagem de atividade. No entanto, uma sondagem de prontidão indica que um pod será iniciado sem receber nenhum tráfego e só começará a receber tráfego depois que a sondagem for bem-sucedida.
Sondagem de inicialização: o kubelet usa sondagens de inicialização para saber quando um aplicativo de contêiner foi iniciado. Se uma sondagem for configurada, ela desativará as verificações de atividade e prontidão até que tenha êxito, garantindo que essas sondagens não interfiram na inicialização do aplicativo.
Após a descoberta, a configuração da sondagem é adicionada ao plano de migração. As sondagens podem ser usadas com a configuração padrão, conforme mostrado no exemplo a seguir. A configuração padrão usa o comando exec para as sondagens de atividade e prontidão. Ambas usam um script de PowerShell chamado probe.ps1, que chama a ferramenta de linha de comando appcmd do IIS para verificar o status dos sites do IIS.
As sondagens estão desativadas por padrão. Para ativá-las, defina a sinalização enabled como true.
images: name: IMAGE_NAME probes: enabled: false livenessProbe: probehandler: exec: command: - powershell.exe - C:\m4a\probe.ps1 initialdelayseconds: 0 timeoutseconds: 1 periodseconds: 10 successthreshold: 1 failurethreshold: 3 terminationgraceperiodseconds: null readinessProbe: probehandler: exec: command: - powershell.exe - C:\m4a\probe.ps1 initialdelayseconds: 0 timeoutseconds: 1 periodseconds: 10 successthreshold: 1 failurethreshold: 3 terminationgraceperiodseconds: null
Seção windowsServices
Os contêineres do Windows criados durante uma migração executam e monitoram um único serviço do IIS do Windows. No entanto, algumas cargas de trabalho podem exigir a execução de serviços adicionais (incluindo um banco de dados, mecanismo de geração de registros, proxy etc.) para funcionar corretamente.
Para executar serviços adicionais no contêiner migrado, adicione entradas à
seção windowsServices e copie os binários necessários na
seção useractions.
version: v1
globalSettings:
target:
…
globalIIS:
…
images:
- name: migrated-image-zgwb2
workloads:
sites:
site:
- applications:
...
bindings:
- port: 80
protocol: http
name: Default Web Site
…
windowsServices:
- MyService
useractions:
files:
- source: C:\Program Files\MyService
target: C:\Program Files\MyService
registry:
currentcontrolset:
- key: services\MyService
Seção useractions
A seção useractions especifica outros arquivos e chaves de registro disponíveis para migração.
Por exemplo:
useractions: files: - source: DRIVE:\FOLDER-OR-FILE-PATH target: DRIVE:\FOLDER-OR-FILE-PATH - source: C:\myfolder target: C:\myfolder - source: D:\myfile target: D:\myfile - source: D:\myfile target: C:\myfile ... registry: currentcontrolset: - path: KEY ... software: - path: KEY ...
Os caminhos especificados para currentcontrolset e software são para chaves no
hive do registro HKEY_LOCAL_MACHINE\System\CurrentControlSet
ou no hive do registro HKEY_LOCAL_MACHINE\Software.
Editar a seção useractions
Por padrão, os únicos arquivos copiados para a imagem são os diretórios virtuais dos sites na imagem especificada.
Caso seu código ou suas configurações importem arquivos de fora desse diretório, adicione-os à seção useractions.
Além disso, todos os valores de registro de que o código depende precisam ser adicionados editando a seção useractions registry.
Configurações relacionadas especificamente ao IIS
As configurações relacionadas ao IIS são divididas em configurações relacionadas a sites específicos, que fazem parte da especificação da imagem, e configurações relacionadas a todos os sites, que estão na seção gloabalIis.
Seção sites
A seção sites descreve os sites que são migrados para uma imagem específica. É possível que várias imagens contenham o mesmo site.
Se você quiser usar
Cloud Load Balancing, Ingress ou Cloud Service Mesh para lidar com a configuração SSL, defina protocol como
http:
sites: site: - applications: - path: / virtualdirectories: - path: / physicalpath: '%SystemDrive%\inetpub\wwwroot' bindings: - port: 8080 protocol: http name: Default Web Site
Seção apppools
Na seção apppools, descrevemos os pools de aplicativos criados nos pods migrados.
O campo identitytype especifica a identidade do IIS de um pool de aplicativos como
ApplicationPoolIdentity (padrão), NetworkService, LocalSystem ou
LocalService.
Para mais informações, consulte Noções básicas sobre identidades no IIS e Identidades do pool de aplicativos.
Veja a seguir um exemplo de plano de migração com identitytype:
migrationPlan: applications: iis: applicationhost: apppools: - name: DefaultAppPool # Allowed values include: ApplicationPoolIdentity (default), NetworkService, LocalSystem, LocalService identitytype="NetworkService" - managedruntimeversion: v4.0 name: .NET v4.5 Classic - managedruntimeversion: v4.0 name: .NET v4.5
Quando você executa o plano de migração para gerar os artefatos de contêiner,
o Migrate to Containers adiciona automaticamente as diretivas do Dockerfile necessárias
de acordo com a configuração do campo identitytype.
Por exemplo, se você definir identitytype como NetworkService, a diretiva estará no formulário:
RUN c:\windows\system32\inetsrv\appcmd.exe set apppool \"DefaultAppPool\" \"/-processModel.identityType:NetworkService\";O Migrate to Containers adiciona automaticamente diretivas de leitura do Access Control List às pastas do site de acordo com o identitytype de destino e para o usuário integrado IUSR.
Isso é feito automaticamente para itens do sistema de arquivos do aplicativo em que a conta original do aplicativo foi especificada por herança ou explicitamente.
Para mais informações, consulte Definir ACLs.
Campo enablegmsa
O campo enablegmsa é o açúcar sintético no plano de migração. É um atalho para substituir o campo identity do pool de aplicativos.
Os valores aceitos para o campo enablegmsa são:
auto(padrão): converte o contêiner migrado para usar a gMSA se o Migrate to Containers determinar que a configuração atual não é permitida.all: sempre converte o contêiner migrado para usar o gMSA e ignora a configuração deidentitytype. Nesse caso,identitytypeé sempre interpretado como sendo definido comoNetworkService.
Veja a seguir um exemplo de plano de migração com enablegmsa:
migrationPlan: applications: iis: # Allowed values include: auto (default), all enablegmsa: auto|all
Para saber mais, consulte Configurar seu aplicativo para usar uma gMSA.
Strings de conexão
As strings de conexão definem uma conexão da carga de trabalho do contêiner migrado para um provedor de dados do .NET Framework.
O Migrate to Containers é compatível com strings de conexão no escopo do site e global.
Para adicionar uma string de conexão a um site, edite a definição de site no
plano de migração para definir a propriedade connectionstrings:
sites: site: # Add the site connection strings here. connectionstrings: - name: connectionname1 providername: System.Data.SqlClient connectionstring: Database=connectedDB1;Password=Welcome1;User=admin; - name: connectionname2 providername: System.Data.OleDb connectionstring: Database=connectedDB2;Password=Welcome2;User=admin; - applications: - path: / virtualdirectories: ...
Para adicionar uma string de conexão ao escopo global (tornando-a acessível a todos os sites), edite as strings de conexão diretamente em globalIis:
globalIis: enablegmsa: auto connectionStrings: connectionstring: - name: connectionname3 providername: System.Data.SqlClient connectionstring: Database=connectedDB3;Password=Welcome3;User=admin; applicationhost: ...
Em que:
nameespecifica o nome da conexão.providernameespecifica o tipo de provedor de dados. O Migrate to Containers é compatível apenas com um valor deSystem.Data.SqlClient. é compatível com o provedor de dados do .NET Framework:System.Data.SqlClientSystem.Data.OleDbSystem.Data.OdbcSystem.Data.OracleClient
connectionstringespecifica as strings de conexão usadas para se conectar ao provedor de dados.
Editar as seções de strings de conexão
O Migrate to Containers copia automaticamente as strings de conexão detectadas na VM migrada para o plano de migração.
Algumas strings de conexão podem não ser detectadas e precisam ser adicionadas editando o plano de migração, conforme mostrado anteriormente. Por exemplo, se as strings de conexão estiverem em uma seção criptografada do arquivo applicationhost.config.
Confira mais orientações sobre como determinar as strings de conexão a serem adicionadas ao plano de migração em Como recuperar strings de conexão no momento da execução na documentação da Microsoft.
Dependências externas da string de conexão
- As strings de conexão podem conter dependências, como uma referência a um arquivo ou a um usuário do Windows associado ao site. É possível adicionar ações personalizadas do usuário ao plano de migração para copiar um arquivo extra no sistema de arquivos. Edite manualmente o Dockerfile para adicionar um usuário do Windows.
- As strings de conexão podem conter dependências, como uma referência a uma fonte de dados externa. Essas dependências precisam ser migradas manualmente para garantir que a carga de trabalho do contêiner migrado tenha acesso à fonte de dados.
Seção security
As seções de segurança contêm as subseções de autenticação e autorização.
- A autenticação do Windows verifica os usuários do Active Directory.
- A autorização do Windows é o mecanismo para especificar quais usuários têm permissão para acessar quais tipos de acesso a um site do IIS. Os tipos de acesso são os verbos HTTP (POST, GET, PUT, PATCH, DELETE).
Assim como nas strings de conexão, para definir a autorização ou autenticação de todos os sites, edite globalIis conforme o exemplo a seguir. Para definir a autorização ou autenticação de um site específico, edite o elemento "site".
globalIis: security: authentication: windowsAuthentication: providers: - NTLM authorization: - add: user:John access: role: - remove: user:Jane access: GET role: ...
Em que:
providersespecifica o provedor dos protocolos de segurança.userespecifica o nome de usuário.accessespecifica as permissões do usuário. Os tipos de acesso são os verbos HTTP (POST, GET, PUT, PATCH, DELETE).roleespecifica um papel de permissão específico.
A seguir
- Saiba como executar a migração.