Customize migration plan for Apache servers

You should review the migration plan file that resulted from creating a migration. Customize the file before executing the migration. The details of your migration plan are used to extract the workload container artifacts from the source.

This document describes the contents of the migration and the kinds of customizations that you might consider before you execute the migration and generate deployment artifacts.

Before you begin

This topic assumes that you've already created a migration and have the migration plan file.

Edit the migration plan

You can edit the migration plan by using the migctl tool or the Google Cloud console.

migctl

You must download the migration plan before you can edit it:

Download the migration plan.
```
migctl migration get my-migration
```
Edit the downloaded migration plan, my-migration.yaml, in a text editor.
When your edits are complete, save and upload the revised migration plan:
```
migctl migration update my-migration --main-config my-migration.yaml
```
Repeat these steps if more edits are necessary.

Console

Edit the migration plan in the Google Cloud console by using the YAML editor.

Open the Migrate to Containers page in the Google Cloud console.

Go to the Migrate to Containers page.
Click the Migrations tab to display a table containing the available migrations.
In the row for your desired migration, select the migration Name to open the Details tab.
Select the YAML tab.

Note: You can also select Download Migration Plan to download a local copy.
Edit the migration plan as necessary.
When you are done editing, you can either:
1. Save the migration plan. You will then have to manually execute the migration to generate the migration artifacts. Use the procedure shown in Executing a migration.
2. Save and generate the artifacts. Execute the migration by using your edits to generate the migration artifacts. The process is the same as described in Executing a migration. You can then monitor the migration as described in Monitoring a migration.

CRD

You must download the migration plan, edit it, then apply it. The migration plan is stored inside the appXGenerateArtifactsConfig field of the AppXGenerateArtifactsFlowSpec CRD.

Get the name of the AppXGenerateArtifactsFlow:

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

The naming pattern is returned in the form of appx-generateartifactsflow-id.

Get the migration plan by name and write to a file named my-plan.yaml:

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

Edit the migration plan as necessary.

Apply the file:

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

Migration plan structure

The migration plan for Apache2 workloads has the following structure which you can customize, as described in the following sections.

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

Configure security policies on directories

In the directories section, you can apply specific configurations to enforce security policies on certain directories. To fill in and edit this section of the plan, use the syntax for the Directory directive.

Load and install modules

In the loadModules section, you can specify the modules that you want to load and install. Migrate to Containers automatically detects the required modules by scanning the original configuration for the LoadModule directive.

Supported Modules

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

Specify and configure virtual hosts

In the virtualHosts section, Migrate to Containers copies all the directives enclosed in a <VirtualHost> and </VirtualHost> block.

In the address field, the IP address of the site is replaced with *.

Under originalConfig, the DocumentRoot field specifies the path from which Apache serves the requested files. For each path specified in DocumentRoot, Migrate to Containers does the following:

It compresses each path a separate tar file.
It copies the tar file in the artifacts for extraction.
It changes the permissions for the user in the Docker image with the ADD --chown option in the Dockerfile.

Review the PHP extensions

Migrate to Containers automatically detects the PHP modules installed in your VM and includes them under the php section of the migration plan. Review this section and add or remove modules as needed.

What's next

Learn how to execute the migration.