Personalizar o plano de migração para serviços do 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, apresentamos uma descrição do conteúdo do plano de migração e os tipos de personalização que você pode analisar 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
Confira a seguir a estrutura completa do plano de migração. Nas próximas seções, explicaremos a estrutura, o que representa 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
Na seção globalSettings, há uma descrição dos requisitos básicos dos pods que executam sites do IIS
da VM. O processo de descoberta pesquisa as configurações gerais
na VM de origem e as usa para preencher essa seção. As configurações
contêm campos presentes nas definições de imagens específicas, conforme descrito na
seção a seguir, e afetam todas as imagens ao mesmo tempo.
Seção image
Na seção image seguinte a globalSettings, há uma descrição da 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 depender 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 adicionar ou remover membros de msvcRuntimes para modificar a lista de ambientes de execução
no plano de migração:
Veja a lista completa de valores possíveis: o ambiente de execução de 2015 também é compatível com as versões 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. Para modificar as variáveis de ambiente PATH, edite os
membros de pathEnvVarAdditionalEntries:
pathEnvVarAdditionalEntries:
- "C:\\myDllsFolder"
- "C:\\ProgramData\\SomeSoftware"
Editar a seção "image"
Você pode editar a seção image nos seguintes casos:
Alguns recursos sugeridos não são necessários aos sites migrados. Isso acontece quando a VM de origem é usada para outras finalidades além de hospedar sites do IIS.
Você modificou as seções do IIS no 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 a imagem base do Windows que você usa (por
exemplo, 1909). É muito raro ter que editar esse campo.
Seção images
Uma única imagem de saída é especificada em cada subitem da seção images.
No zip de artefatos, cada uma das 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.
Isso 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 monitoram a inatividade e o status "Pronto" dos contêineres gerenciados. O monitoramento da sondagem de integridade pode reduzir a inatividade dos contêineres migrados e aprimorar o controle.
Os estados de integridade desconhecidos podem levar a degradação de disponibilidade, monitoramento de disponibilidade com falsos positivos e possível perda de dados. Sem uma sondagem de integridade, o kubelet apenas deduz a integridade de um contêiner e pode enviar o tráfego a uma instância de contêiner que não está pronta. Se a instância não estiver pronta, isso poderá causar perda de tráfego. O kubelet também pode não detectar quando há contêineres em estado travado e deixar de reiniciá-los.
Para realizar uma sondagem de integridade, é preciso executar uma pequena instrução de script
quando o contêiner é iniciado. O script verifica em cada período se há condições
de sucesso, ou seja, aquelas definidas pelo tipo de sondagem usada. O período é definido no plano
de migração por um campo periodSeconds. É possível definir as sondagens manualmente
durante a personalização do plano de migração.
Há três tipos de sondagens disponíveis para configuração. Todas elas 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. Especifique uma sondagem de prontidão para começar a enviar tráfego a um pod somente quando a sondagem for bem-sucedida. A sondagem de prontidão pode agir de maneira semelhante à de atividade. No entanto, a sondagem de prontidão indica que um pod será iniciado sem receber nenhum tráfego e começará a receber tráfego apenas depois que ela for bem-sucedida.
Sondagem de inicialização: o kubelet usa esse tipo de sondagem para saber quando um aplicativo de contêiner foi iniciado. Se essa sondagem foi configurada, ela desativa as verificações de atividade e prontidão até ser bem-sucedida, garantindo que elas 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. As duas usam um script do 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 flag 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 banco de dados, mecanismo de geração de registros, proxy etc.) para funcionar corretamente.
Para executar serviços adicionais no contêiner migrado, insira entradas na
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 indicados para currentcontrolset e software se referem às chaves no
hive do registro HKEY_LOCAL_MACHINE\System\CurrentControlSet
ou 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 específicas do IIS
As configurações do IIS são divididas naquelas relacionadas a determinados sites,
que fazem parte da especificação da imagem, e naquelas relacionadas a todos os sites,
seguintes à seção gloabalIis.
Seção sites
A seção sites descreve os sites que são migrados para uma imagem específica. Várias imagens podem conter o mesmo site.
Se você quiser usar o
Cloud Load Balancing, Ingress ou Cloud Service Mesh para trabalhar 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
A seção apppools descreve 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, o formato da diretiva
será:
RUN c:\windows\system32\inetsrv\appcmd.exe set apppool \"DefaultAppPool\" \"/-processModel.identityType:NetworkService\";O Migrate to Containers adiciona automaticamente diretivas de leitura da ACL à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 de maneira explícita.
Para mais informações, consulte Definir ACLs.
Campo enablegmsa
O campo enablegmsa é o açúcar sintático no plano de migração. Trata-se de
um atalho para substituir o campo identity do pool de aplicativos.
Os valores aceitos no campo enablegmsa são:
auto(padrão): converte o contêiner migrado para usar o 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é interpretado com a definiçãoNetworkServicesem exceção.
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 a conexão da carga de trabalho do contêiner migrado com 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, e torná-la acessível a todos os
sites, edite as strings de conexão logo após 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 (opcional). O Migrate to Containers é compatível apenas com o valorSystem.Data.SqlCliente 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 já foi mostrado. Por exemplo, quando as strings de
conexão estão em uma seção criptografada do arquivo applicationhost.config.
Consulte as orientações de como determinar as strings de conexão que serão adicionadas ao plano de migração em Recuperando cadeias de conexão em tempo de 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 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 referência a uma fonte de dados externa. É necessário fazer a migração manual dessas dependências 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 de autorização.
- A autenticação do Windows verifica os usuários do Active Directory.
- A autorização do Windows é o mecanismo que especifica os tipos de acesso dos usuários 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 a autenticação de todos os
sites, edite globalIis conforme o exemplo a seguir. Para definir a autorização ou
a 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.