Personalize o plano de migração para serviços IIS do Windows
Reveja o ficheiro do plano de migração preenchido durante a criação da migração. Pode personalizá-lo antes de avançar para a execução da migração. Os detalhes do seu plano de migração são usados para extrair os artefactos do contentor da carga de trabalho da VM de origem.
Esta secção descreve o conteúdo do plano de migração e os tipos de personalizações que pode considerar antes de executar a migração e gerar artefactos de implementação.
Antes de começar
Este documento pressupõe que já criou um plano de migração e tem o ficheiro do plano de migração resultante.
Estrutura do plano de migração
Segue-se a estrutura completa do plano de migração. As secções seguintes abordam esta estrutura, explicam o que é cada parte e como a modificar.
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
A secção globalSettings
A secção globalSettings descreve os requisitos básicos para pods que executam sites do IIS a partir desta VM. O processo de descoberta procura configurações gerais na VM de origem e usa-as para preencher esta secção. Estas configurações
contêm campos presentes nas configurações de imagens específicas, conforme descrito na
secção seguinte, e afetam todas as imagens ao mesmo tempo.
A secção image
A secção image a seguir a globalSettings descreve a lista de
funcionalidades do Windows
a instalar nos pods. O processo de deteção preenche esta secção com todas as funcionalidades do Windows existentes na VM original e que podem ser instaladas num contentor do Windows.
A secção msvcRuntimes
Quando migra uma aplicação, esta pode ter uma dependência de uma versão específica ou de versões do Microsoft Visual C++ Runtime (MSVCRT). A migração para contentores deteta automaticamente os tempos de execução instalados na VM de origem e inclui-os no plano de migração.
Pode modificar a lista de tempos de execução no plano de migração adicionando ou
removendo membros de msvcRuntimes:
A lista completa de valores possíveis é: (O tempo 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
A secção pathEnvVarAdditionalEntries
As aplicações do IIS do Windows podem ter entradas de variáveis de ambiente PATH não predefinidas, que são detetadas automaticamente na VM de origem e incluídas no plano de migração. Pode modificar as variáveis de ambiente PATH editando os membros de pathEnvVarAdditionalEntries:
pathEnvVarAdditionalEntries:
- "C:\\myDllsFolder"
- "C:\\ProgramData\\SomeSoftware"
Edite a secção de imagens
Pode querer editar a secção image nos seguintes casos:
Algumas funcionalidades sugeridas não são necessárias para os sites migrados. Isto acontece se a VM de origem tiver utilizações que não sejam o alojamento de sites do IIS.
Modificou as secções do IIS no plano de migração e adicionou configurações que dependem de funcionalidades adicionais do Windows. (Por exemplo, a autenticação do Windows depende da funcionalidade de autenticação do Windows).
A secção target
A secção target especifica a imagem base do Windows que está a usar (por exemplo, 1909). Raramente precisa de editar este campo.
A secção images
Cada subitem da secção images especifica uma única imagem de saída.
No ZIP de artefactos, cada imagem deste tipo tem um subdiretório separado, com o seu próprio Dockerfile e deployment_spec.yaml (consulte Implementar a imagem do contentor).
O campo name
O campo name descreve o nome da imagem.
Afeta o nome da subdiretoria de imagens e o ficheiro deployment_spec.yaml
nos artefactos.
O campo probes
O campo probes descreve a configuração da sondagem de estado da imagem. Para saber mais sobre as sondas kubelet, consulte o artigo Configure Liveness, Readiness and Startup Probes.
Edite as sondas de funcionamento do IIS
As sondas de estado podem monitorizar a inatividade e o estado de prontidão dos seus contentores geridos. A monitorização da sondagem de saúde pode ajudar a reduzir o tempo de inatividade dos contentores migrados e oferecer uma melhor monitorização.
Os estados de funcionamento desconhecidos podem criar uma degradação da disponibilidade, uma monitorização da disponibilidade com falsos positivos e uma potencial perda de dados. Sem uma sondagem de saúde, o kubelet só pode presumir o estado de um contentor e pode enviar tráfego para uma instância de contentor que não esteja pronta. Se a instância não estiver pronta, pode causar perda de tráfego. O Kubelet também pode não detetar contentores que se encontram num estado congelado e não os reinicia.
Uma sondagem de saúde funciona executando uma pequena declaração com script quando o contentor é iniciado. O script verifica se existem condições bem-sucedidas, que são definidas pelo tipo de teste usado, em todos os períodos. O período é definido no plano de migração por um campo periodSeconds. Pode definir estas sondagens manualmente
quando personalizar o plano de migração.
Existem três tipos de sondas disponíveis para configuração. Todas as sondas são sondas v1 core definidas na referência v1 core de sondas e partilham a mesma função que os campos correspondentes de container v1 core.
*Sondagem de atividade: as sondagens de atividade são usadas para saber quando reiniciar um contentor.
Sondagem de prontidão: as sondagens de prontidão são usadas para saber quando um contentor está pronto para começar a aceitar tráfego. Para começar a enviar tráfego para um pod apenas quando uma sondagem for bem-sucedida, especifique uma sondagem de prontidão. Uma sonda de prontidão pode agir de forma semelhante a uma sonda de atividade. No entanto, uma sondagem de prontidão indica que um pod é iniciado sem receber tráfego e só começa a receber tráfego depois de a sondagem ser bem-sucedida.
Sondagem de arranque: o kubelet usa sondagens de arranque para saber quando uma aplicação de contentor foi iniciada. Se for configurada uma sonda deste tipo, desativa as verificações de atividade e prontidão até ter êxito, garantindo que essas sondas não interferem com o início da aplicação.
Após a deteção, a configuração da sondagem é adicionada ao plano de migração. As sondas podem ser usadas na respetiva configuração predefinida, conforme mostrado no exemplo seguinte. A configuração predefinida usa o comando exec para as sondagens de atividade e
prontidão. Ambos estão a usar um script do PowerShell denominado probe.ps1 que
chama a ferramenta de linha de comandos do IIS appcmd para verificar o estado dos sites do IIS.
As sondas estão desativadas por predefinição. Para as ativar, 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
A secção windowsServices
Os contentores Windows criados durante uma migração executam e monitorizam um único serviço Windows IIS. No entanto, algumas cargas de trabalho podem exigir a execução de serviços adicionais (incluindo uma base de dados, um mecanismo de registo, um proxy e muito mais) para funcionarem corretamente.
Para executar serviços adicionais no contentor migrado, adicione entradas à secção windowsServices e copie os ficheiros binários necessários na secçã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
A secção useractions
A secção useractions especifica ficheiros adicionais e chaves de registo que pode querer migrar.
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
HKEY_LOCAL_MACHINE\System\CurrentControlSet ramo de registo
ou no ramo de registo HKEY_LOCAL_MACHINE\Software.
Edite a secção useractions
Por predefinição, os únicos ficheiros copiados para a imagem são os diretórios virtuais dos sites na imagem especificada.
Se o seu código ou configurações importarem ficheiros de fora deste diretório, deve adicioná-los à secção useractions.
Além disso, quaisquer valores de registo dos quais o seu código dependa devem ser adicionados editando a secção useractions registry.
Definições relacionadas especificamente com o IIS
As definições relacionadas com o IIS estão divididas em definições relacionadas com sites específicos, que fazem parte da especificação de imagens, e definições relacionadas com todos os sites, que seguem a secção gloabalIis.
A secção sites
A secçã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 quiser usar o Cloud Load Balancing, o Ingress ou o Cloud Service Mesh para processar a configuração SSL, tem de definir protocol como http:
sites: site: - applications: - path: / virtualdirectories: - path: / physicalpath: '%SystemDrive%\inetpub\wwwroot' bindings: - port: 8080 protocol: http name: Default Web Site
A secção apppools
A secção apppools descreve os conjuntos de aplicações criados nos pods migrados.
O campo identitytype especifica a identidade do IIS de um conjunto de aplicações como ApplicationPoolIdentity (predefinição), NetworkService, LocalSystem ou LocalService.
Para mais informações, consulte os artigos Compreender as identidades no IIS e Identidades do conjunto de aplicações.
Segue-se um exemplo de um plano de migração que contém 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 executa o plano de migração para gerar os artefactos do contentor, o Migrate to Containers adiciona automaticamente as diretivas do Dockerfile necessárias de acordo com a definição do campo identitytype.
Por exemplo, se definir identitytype como NetworkService, a diretiva tem o seguinte formato:
RUN c:\windows\system32\inetsrv\appcmd.exe set apppool \"DefaultAppPool\" \"/-processModel.identityType:NetworkService\";A migração para contentores adiciona automaticamente diretivas de ACL de leitura às pastas do site de acordo com o identitytype de destino e para o utilizador incorporado IUSR.
Isto é feito automaticamente para itens do sistema de ficheiros da aplicação onde a conta da aplicação original foi especificada por herança ou explicitamente.
Para mais informações, consulte o artigo Defina ACLs.
O campo enablegmsa
O campo enablegmsa é uma simplificação sintática no plano de migração. É um atalho para substituir o campo identity do conjunto de aplicações.
Os valores suportados para o campo enablegmsa são:
auto(predefinição): converte o contentor migrado para usar o gMSA se a opção Migrar para contentores determinar que a respetiva configuração atual não é permitida.all: converta sempre o contentor migrado para usar o gMSA e ignore a definição deidentitytype. Neste caso,identitytypeé sempre interpretado como estando definido comoNetworkService.
Segue-se um exemplo de um plano de migração que contém enablegmsa:
migrationPlan: applications: iis: # Allowed values include: auto (default), all enablegmsa: auto|all
Para saber mais, consulte o artigo Configure a sua app para usar uma gMSA.
Strings de ligação
As strings de ligação definem uma ligação da carga de trabalho do contentor migrado a um fornecedor de dados do .NET Framework.
A migração para contentores suporta strings de ligação ao nível do site e global.
Para adicionar uma string de ligação a um site, edite a definição 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 ligação ao âmbito global (tornando-a acessível a todos os sites), edite as strings de ligação diretamente após globalIis:
globalIis: enablegmsa: auto connectionStrings: connectionstring: - name: connectionname3 providername: System.Data.SqlClient connectionstring: Database=connectedDB3;Password=Welcome3;User=admin; applicationhost: ...
Onde:
nameespecifica o nome da associação.providernameespecifica opcionalmente o tipo de fornecedor de dados. A migração para contentores só suporta um valor deSystem.Data.SqlClient. suporta o fornecedor de dados do .NET Framework:System.Data.SqlClientSystem.Data.OleDbSystem.Data.OdbcSystem.Data.OracleClient
connectionstringespecifica as Strings de ligação usadas para estabelecer ligação ao fornecedor de dados.
Edite as secções de strings de ligação
A migração para contentores copia automaticamente as strings de ligação detetadas na VM migrada para o plano de migração.
Algumas strings de ligação podem não ser detetadas e devem ser adicionadas editando o plano de migração, conforme mostrado anteriormente. (Por exemplo, se as strings de ligação estiverem numa secção encriptada do ficheiro applicationhost.config).
Para receber orientações sobre como determinar que strings de ligação adicionar ao seu plano de migração, consulte o artigo Obter strings de ligação no tempo de execução na documentação da Microsoft.
Dependências externas da string de ligação
- As strings de ligação podem conter dependências, como uma referência a um ficheiro ou a um utilizador do Windows associado ao site. Pode adicionar ações do utilizador personalizadas ao plano de migração para copiar um ficheiro adicional no sistema de ficheiros. Edite manualmente o Dockerfile para adicionar um utilizador do Windows.
- As strings de ligação podem conter dependências, como uma referência a uma origem de dados externa. Estas dependências têm de ser migradas manualmente para garantir que a carga de trabalho do contentor migrado tem acesso à origem de dados.
A secção security
As secções de segurança contêm as subsecções de autenticação e autorização.
- A autenticação do Windows valida os utilizadores do Active Directory.
- A autorização do Windows é o mecanismo para especificar que utilizadores têm autorização para que tipos de acesso a um Website do IIS. Os tipos de acesso são os verbos HTTP (POST, GET, PUT, PATCH, DELETE).
Semelhante às strings de ligação, para definir a autorização ou a autenticação para todos os sites, edite globalIis como no exemplo seguinte. Para definir a autorização ou a autenticação para um site específico, edite o elemento do site.
globalIis: security: authentication: windowsAuthentication: providers: - NTLM authorization: - add: user:John access: role: - remove: user:Jane access: GET role: ...
Onde:
providersespecifica o fornecedor dos seus protocolos de segurança.userespecifica o nome de utilizador.accessespecifica as autorizações do utilizador. Os tipos de acesso são os verbos HTTP (POST, GET, PUT, PATCH, DELETE).roleespecifica uma função de autorização específica.
O que se segue?
- Saiba como executar a migração.