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 os artefatos de contêiner da carga de trabalho da VM de origem.

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

Para seguir este tópico, é necessário criar uma migração e ter o arquivo do plano de migração resultante.

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:

  1. 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.

  2. 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.

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.

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, Entrada ou Anthos 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 de identitytype. Nesse caso, identitytype é sempre interpretado como sendo definido como NetworkService.

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:

  • name especifica o nome da conexão.
  • providername especifica o tipo de provedor de dados. O Migrate to Containers é compatível apenas com um valor de System.Data.SqlClient. é compatível com o provedor de dados do .NET Framework:
    • System.Data.SqlClient
    • System.Data.OleDb
    • System.Data.Odbc
    • System.Data.OracleClient
  • connectionstring especifica 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.

Veja 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:

  • providers especifica o provedor dos protocolos de segurança.
  • user especifica o nome de usuário.
  • access especifica as permissões do usuário. Os tipos de acesso são os verbos HTTP (POST, GET, PUT, PATCH, DELETE).
  • role especifica um papel de permissão específico.

A seguir