Personalizar o plano de migração de servidores Apache

Revise o arquivo do plano de migração gerado ao criar a migração. Personalize o arquivo antes de realizar 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 origem.

Nesta seção, você verá uma descrição do conteúdo da migração e dos 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.

Editar o plano de migração

Para editar o plano de migração, use a ferramenta migctl ou o console do Google Cloud.

migctl

É necessário fazer o download do plano de migração antes de editá-lo:

Faça o download do plano de migração.
```
migctl migration get my-migration
```
Edite o plano de migração transferido por download, my-migration.yaml, em um editor de texto.
Quando tiver terminado as edições, salve e faça upload do plano de migração revisado:
```
migctl migration update my-migration --main-config my-migration.yaml
```
Repita essas etapas se mais alterações forem necessárias.

Console

Edite o plano de migração no console do Google Cloud usando o editor YAML.

Abra a página "Migrate to Containers" no Console do Google Cloud.

Acesse a página do Migrate to Containers.
Clique na guia Migrações para exibir uma tabela com as migrações disponíveis.
Na linha da migração desejada, selecione o Nome da migração para abrir a guia Detalhes.
Selecione a guia YAML.

Observação: também é possível selecionar Fazer o download do plano de migração para fazer o download de uma cópia local.
Edite o plano de migração conforme necessário.
Quando terminar de editar, será possível:
1. salvar o plano de migração. Em seguida, execute manualmente a migração para gerar os artefatos de migração. Use o procedimento mostrado em Como executar uma migração.
2. salvar e gerar os artefatos. Execute a migração usando as edições feitas para gerar os artefatos de migração. O processo é o mesmo descrito em Como executar uma migração. Depois, monitore a migração conforme descrito em Como monitorar uma migração.

CRD

É necessário fazer o download do plano de migração, editá-lo e aplicá-lo. O plano de migração é armazenado dentro do campo appXGenerateArtifactsConfig do CRD AppXGenerateArtifactsFlowSpec.

Consiga o nome do AppXGenerateArtifactsFlow:

kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system -o jsonpath={.status.migrationPlanRef.name} my-migration

O padrão de nomenclatura é retornado na forma de appx-generateartifactsflow-id.

Para encontrar o plano de migração por nome e gravar em um arquivo chamado my-plan.yaml:

kubectl -n v2k-system get appxgenerateartifactsflows.anthos-migrate.cloud.google.com -o jsonpath={.spec.appXGenerateArtifactsConfig} appx-generateartifactsflow-id > my-plan.yaml

Edite o plano de migração conforme necessário.

Aplique o arquivo:

kubectl patch appxgenerateartifactsflows.anthos-migrate.cloud.google.com --type merge -n v2k-system --patch '{"spec": {"appXGenerateArtifactsConfig": '"$(jq -n --rawfile plan my-plan.yaml '$plan')"'}}' appx-generateartifactsflow-id

Estrutura do plano de migração

O plano de migração para cargas de trabalho Apache2 tem a seguinte estrutura que pode ser personalizada, conforme descrito nas próximas seções.

apacheServer:
  # Apache configuration for directories on the system
  # Content is the configuration as understood by apache
  directories:
  - Content: |-
      Options FollowSymLinks
      AllowOverride None
      Require all denied
    Path: /
  - Content: |-
      AllowOverride None
      Require all granted
    Path: /usr/share
  - Content: |-
      Options Indexes FollowSymLinks
      AllowOverride None
      Require all granted
    Path: /var/www/
  - Content: "#\tOptions Indexes FollowSymLinks\n#\tAllowOverride None\n#\tRequire
      all granted"
    Path: /srv/
  - Content: |-
      #   AllowOverride None
      #   Require all denied
    Path: /
  # Environment variables used by apache
  envVars:
  - Value: www-data
    Var: APACHE_RUN_USER
  - Value: www-data
    Var: APACHE_RUN_GROUP
  - Value: /var/run/apache2$SUFFIX/apache2.pid
    Var: APACHE_PID_FILE
  - Value: /var/run/apache2$SUFFIX
    Var: APACHE_RUN_DIR
  - Value: /var/lock/apache2$SUFFIX
    Var: APACHE_LOCK_DIR
  - Value: /var/log/apache2$SUFFIX
    Var: APACHE_LOG_DIR
  - Value: C
    Var: LANG
  # The port the service will listen on
  listen:
  - "80"
  - "443"
  # Apache modules to be loaded and installed
  loadModules:
  - Module: access_compat_module
  - Module: alias_module
  - Module: auth_basic_module
  - Module: authn_core_module
  - Module: authn_file_module
  - Module: authz_core_module
  - Module: authz_host_module
  - Module: authz_user_module
  - Module: autoindex_module
  - Module: deflate_module
  - Module: dir_module
  - Module: env_module
  - Module: filter_module
  - Module: mime_module
  - Module: mpm_prefork_module
  - Module: negotiation_module
  - Module: php7_module
  - Module: proxy_module
  - Module: proxy_fcgi_module
  - Module: reqtimeout_module
  - Module: rewrite_module
  - Module: setenvif_module
  - Module: socache_shmcb_module
  - Module: ssl_module
  - Module: status_module
  # The sites to be extracted
  virtualHosts:
  - address: '*:80'
    documentRoot: /var/www/html
    # should the site be enabled in extracted VM
    includeInContainerImage: true
    originalConfig: |-
      # The ServerName directive sets the request scheme, hostname and port that
      # the server uses to identify itself. This is used when creating
      # redirection URLs. In the context of virtual hosts, the ServerName
      # specifies what hostname must appear in the request's Host: header to
      # match this virtual host. For the default virtual host (this file) this
      # value is not decisive as it is used as a last resort host regardless.
      # However, you must set it for any further virtual host explicitly.
      #ServerName www.example.com

      ServerAdmin webmaster@localhost
      DocumentRoot /var/www/html

      # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
      # error, crit, alert, emerg.
      # It is also possible to configure the loglevel for particular
      # modules, e.g.
      #LogLevel info ssl:warn

      ErrorLog ${APACHE_LOG_DIR}/error.log
      CustomLog ${APACHE_LOG_DIR}/access.log combined

      # For most configuration files from conf-available/, which are
      # enabled or disabled at a global level, it is possible to
      # include a line for only one particular virtual host. For example the
      # following line enables the CGI configuration for this host only
      # after it has been globally disabled with "a2disconf".
      #Include conf-available/serve-cgi-bin.conf
    serverName: server-0
  - address: '*:443'
    # The location of the site content (will be copied to the same location the extracted container)
    documentRoot: /var/www/html
    includeInContainerImage: false
    originalConfig: |-
      ServerAdmin admin@example.com
      DocumentRoot /var/www/html
      SSLEngine on
      SSLCertificateFile /etc/ssl/certs/c2d-temporary-self-signed-cert.pem
      SSLCertificateKeyFile /etc/ssl/private/c2d-temporary-self-signed-cert.key

      <Directory /var/www/html>
      Options -Indexes
      AllowOverride FileInfo
      </Directory>
    serverName: server-1
php:
  # list of php modules to be installed in the extracted container (add/remove entries to change what will be installed)
  modules:
  - calendar
  - ctype
  - curl
  - exif
  - ffi
  - fileinfo
  - filter
  - gd
  - gettext
  - iconv
  - json
  - mysqli
  - pcntl
  - pdo
  - pdo_mysql
  - posix
  - shmop
  - sockets
  - sysvmsg
  - sysvsem
  - sysvshm
  - tokenizer
  - xsl

Configurar políticas de segurança em diretórios

Na seção directories, é possível aplicar configurações específicas para aplicar políticas de segurança em determinados diretórios. Para preencher e editar esta seção do plano, use a sintaxe da diretiva Directory.

Carregar e instalar módulos

Na seção loadModules, especifique os módulos que você quer carregar e instalar. O Migrate to Containers detecta automaticamente os módulos necessários ao verificar a configuração original da diretiva LoadModule.

Módulos com suporte

access_compat_module
alias_module
auth_basic_module
authn_core_module
authn_file_module
authz_core_module
authz_host_module
authz_user_module
autoindex_module
deflate_module
dir_module
env_module
expires_module
filter_module
mime_module
mpm_prefork_module
negotiation_module
php7_module
proxy_fcgi_module
proxy_module
remoteip_module
reqtimeout_module
rewrite_module
setenvif_module
socache_shmcb_module
ssl_module
status_module

Especificar e configurar hosts virtuais

Na seção virtualHosts, o Migrate to Containers copia todas as diretivas incluídas em um bloco <VirtualHost> e </VirtualHost>.

No campo address, o endereço IP do site é substituído por *.

Em originalConfig, o campo DocumentRoot especifica o caminho a partir do qual o Apache veicula os arquivos solicitados. Para cada caminho especificado em DocumentRoot, o Migrate to Containers faz o seguinte:

Compacta cada caminho como um arquivo tar separado.
Copia o arquivo tar nos artefatos para extração.
Altera as permissões do usuário na imagem do Docker com a opção ADD --chown no Dockerfile.

Revisar as extensões PHP

O Migrate to Containers detecta automaticamente os módulos de PHP instalados na VM e os inclui na seção php do plano de migração. Revise esta seção e adicione ou remova módulos conforme necessário.

A seguir

Saiba como executar a migração.