Personnaliser le plan de migration pour les serveurs Apache
Vous devez examiner le fichier de plan de migration résultant de la création d'une migration. Personnalisez le fichier avant d'exécuter la migration. Les détails de votre plan de migration sont utilisés pour extraire les artefacts de conteneur de charge de travail de la source.
Ce document décrit le contenu de la migration et les types de personnalisations que vous pouvez envisager avant d'exécuter la migration et de générer des artefacts de déploiement.
Avant de commencer
- Cet article suppose que vous avez déjà créé une migration et que vous disposez du fichier de plan de migration.
Modifier le plan de migration
Vous pouvez modifier le plan de migration à l'aide de l'outil migctl
ou de la console Google Cloud.
migctl
Vous devez télécharger le plan de migration avant de pouvoir le modifier :
Téléchargez le plan de migration.
migctl migration get my-migration
Modifiez le plan de migration téléchargé,
my-migration.yaml
, dans un éditeur de texte.Une fois les modifications effectuées, enregistrez et importez le plan de migration révisé :
migctl migration update my-migration --main-config my-migration.yaml
Répétez ces étapes si d'autres modifications sont nécessaires.
Console
Modifiez le plan de migration dans Google Cloud Console à l'aide de l'éditeur YAML.
Ouvrez la page "Migrate to Containers" dans la console Google Cloud.
Cliquez sur l'onglet Migrations pour afficher un tableau contenant les migrations disponibles.
Sur la ligne de la migration souhaitée, sélectionnez le Nom de la migration pour ouvrir l'onglet Détails.
Sélectionnez l'onglet YAML.
Modifiez le plan de migration si nécessaire.
Une fois les modifications terminées, vous pouvez effectuer l'une des opérations suivantes :
Enregistrez le plan de migration. Vous devrez ensuite exécuter manuellement la migration pour générer les artefacts de migration. Suivez la procédure décrite dans la section Exécuter une migration.
Enregistrez et générez les artefacts. Exécutez la migration en utilisant vos modifications pour générer les artefacts de migration. Le processus est le même que celui décrit dans la section Exécuter une migration. Vous pouvez ensuite surveiller la migration, comme décrit dans la section Surveiller une migration.
CRD
Vous devez télécharger le plan de migration, le modifier, puis l'appliquer.
Le plan de migration est stocké dans le champ appXGenerateArtifactsConfig
de l'objet CRD AppXGenerateArtifactsFlowSpec :
Obtenez le nom de l'élément
AppXGenerateArtifactsFlow
:kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system -o jsonpath={.status.migrationPlanRef.name} my-migration
Le modèle de dénomination est renvoyé au format
appx-generateartifactsflow-id
.Récupérez le plan de migration par nom et écrivez dans un fichier nommé
my-plan.yaml
:kubectl -n v2k-system get appxgenerateartifactsflows.anthos-migrate.cloud.google.com -o jsonpath={.spec.appXGenerateArtifactsConfig} appx-generateartifactsflow-id > my-plan.yaml
Modifiez le plan de migration si nécessaire.
Appliquez le fichier :
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
Structure du plan de migration
Le plan de migration des charges de travail Apache2 présente la structure suivante que vous pouvez personnaliser, comme décrit dans les sections suivantes.
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
Configurer des stratégies de sécurité sur des répertoires
Dans la section directories
, vous pouvez appliquer des configurations spécifiques pour appliquer des règles de sécurité à certains répertoires.
Pour renseigner et modifier cette section du plan, utilisez la syntaxe de l'instruction Directory
.
Charger et installer des modules
Dans la section loadModules
, vous pouvez spécifier les modules que vous souhaitez charger et installer.
Migrate to Containers détecte automatiquement les modules requis en analysant la configuration d'origine pour la directive LoadModule
.
Modules compatibles
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
Spécifier et configurer des hôtes virtuels
Dans la section virtualHosts
, Migrate to Containers copie toutes les instructions incluses dans un bloc <VirtualHost>
et </VirtualHost>
.
Dans le champ address
, l'adresse IP du site est remplacée par *
.
Sous originalConfig
, le champ DocumentRoot
spécifie le chemin d'accès à partir duquel Apache diffuse les fichiers demandés.
Pour chaque chemin d'accès spécifié dans DocumentRoot
, Migrate to Containers effectue les opérations suivantes :
- Il compresse chaque chemin d'accès d'un fichier tar distinct.
- Il copie le fichier tar dans les artefacts pour l'extraction.
- Il modifie les autorisations de l'utilisateur dans l'image Docker avec l'option
ADD --chown
dans le fichier Dockerfile.
Examiner les extensions PHP
Migrate to Containers détecte automatiquement les modules PHP installés dans votre VM et les inclut dans la section php
du plan de migration.
Consultez cette section et ajoutez ou supprimez des modules si nécessaire.
Étapes suivantes
- Découvrez comment exécuter la migration.