ホスティング記述ファイルを編集する

ホスティング記述ファイルは、YAML または JSON フォーマットで記述でき、移行元サーバから移行するクライアント、契約、アドオンドメイン、メールボックスなどが列挙されています。ホスティング記述ファイルのサンプルはこちらを参照してください。本トピックでは、使用頻度の高いさまざまなパラメータを構成して移行を成功へと導く方法を説明します。

ウェブコンテンツデータへのパスを指定する

移行元サーバと移行先サーバの両方におけるウェブコンテンツデータへのパスを指定するには、subscriptions セクションで以下のパラメータを使用します。

  • source_webspace_root - 顧客が使用できるすべてのファイルを格納する移行元サーバのディレクトリの絶対パス。契約レベルでのみ指定できます(例:/home/vhosts/example.com)。
  • source_document_root - HTTP 経由で提供するファイルのみ格納するディレクトリの絶対パス。契約レベル、アドオンドメインレベル、またはサブドメインレベルで指定できます(例:/home/vhosts/example.com/httpdocs)。
  • target_document_root - HTTP 経由で提供するファイルを格納する移行先サーバのディレクトリ。移行先サーバでの契約のルートディレクトリを基準とする相対パスで指定します。契約レベル、アドオンドメインレベル、またはサブドメインレベルで指定できます(例:data/www。ドメイン名が example.com で、Plesk の仮想ホストディレクトリが /var/www/vhosts である場合、移行先でのドキュメントルートディレクトリの絶対パスは /var/www/vhosts/example.com/data/www となります)。指定しないと、Plesk のデフォルト値が使用されます。

注:構成ファイルに移行元サーバのアクセス情報が含まれない場合、source_webspace_root のパスと source_document_root のパスは移行先サーバでローカルとして扱われます。

特定のディレクトリまたはファイルを移行対象外にする必要がある場合は、source_webspace_root パラメータと source_document_root パラメータで exclude ディレクティブを使用します。例:

subscriptions:
    -
        name: example.com
        source_webspace_root:           
                path: /home/vhosts/example.com
                exclude:
                    -
                        /bin
                    -   
                        /logs

exclude ルールを記述する構文は、rsync ツールで使用する構文と同じです。詳しくは、rsync のマニュアルの「Include/Exclude Pattern Rules」セクションを参照してください。

移行元サーバの特定のディレクトリにあるウェブコンテンツを、移行先サーバのどのディレクトリに格納するか明確に設定するには、ウェブファイルマッピングを使用します。例:

subscriptions:
    -
        name: example.com
        target_document_root: data/www
        web_files:
            -
                source: /home/vhosts/example.com
                target: "{webspace_root}"
            -
                source: /home/vhosts/example.com/httpdocs
                target: "{document_root}"

target ディレクティブには、移行先サーバでの絶対パスか、以下の表のテンプレート変数を 1 つ以上含むフォーマット文字列を指定します。

以下は、web_files ノードが契約ノードの直下にある場合のテンプレート変数と、それらが契約に対してどのような意味を持つのかを示します。

テンプレート変数 詳細 適用対象

{anon_ftp_incoming}

匿名 FTP でアップロード可能なディレクトリのパス

Linux のみ

{anon_ftp_pub}

匿名 FTP で読取可能なディレクトリのパス

Linux のみ

{cgi_bin}

契約の cgi-bin ディレクトリのパス

Unix のみ

{document_root}

契約のドキュメントルートのパス - HTTP 経由でアクセス可能なディレクトリ

Linux と Windows

{logs}

ログ(Apache のアクセスおよびエラーログなど)が含まれるディレクトリのパス

Linux と Windows

{main_domain_private}

メインドメインのプライベートディレクトリ

Windows のみ

{main_domain_statistics}

メインドメインの統計ディレクトリ(AWStats/Webalizer など)

Windows のみ

{protected_dirs}

保護されたディレクトリの設定が含まれるディレクトリのパス

Linux のみ

{ssl_document_root}

契約のセキュアドキュメントルートのパス - HTTPS 経由でアクセス可能なディレクトリ

Windows のみ

{statistics}

統計ファイルが含まれるディレクトリのパス(AWStats/Webalizer など)

Linux のみ

{webspace_idn}

punycode でエンコードされた契約名

Linux と Windows

{webspace_root}

契約のルートのパス

Linux と Windows

{webspace}

契約名

Linux と Windows

以下は、web_files ノードがアドオンドメインまたはサブドメインノードの直下にある場合のテンプレート変数と、それらがアドオンドメインおよびサブドメインに対してどのような意味を持つのかを示します。

テンプレート変数 詳細 適用対象

{cgi_bin}

アドオンドメイン/サブドメインの cgi-bin ディレクトリのパス

Linux のみ

{document_root}

アドオンドメイン/サブドメインのドキュメントルートのパス

Linux と Windows

{logs}

アドオンドメイン/サブドメインのログ(Apache のアクセスおよびエラーログなど)が含まれるディレクトリのパス

Linux のみ

{protected_dirs}

アドオンドメイン/サブドメインの保護されているディレクトリの設定が含まれるディレクトリのパス

Linux のみ

{site_idn}

punycode でエンコードされたアドオンドメイン/サブドメイン名

Linux と Windows

{site}

アドオンドメイン/サブドメイン名

Linux と Windows

{statistics}

アドオンドメイン/サブドメインの統計ファイルが含まれるディレクトリのパス(AWStats/Webalizer など)

Linux と Windows

{webspace_anon_ftp_incoming}

親契約の匿名 FTP でアップロード可能なディレクトリのパス

Linux のみ

{webspace_anon_ftp_pub}

親契約の匿名 FTP で読取可能なディレクトリのパス

Linux のみ

{webspace_cgi_bin}

親契約の cgi-bin ディレクトリのパス

Linux のみ

{webspace_document_root}

親契約のドキュメントルートのパス

Linux と Windows

{webspace_idn}

punycode でエンコードされた親契約名

Linux と Windows

{webspace_logs}

親契約のログ(Apache のアクセスおよびエラーログなど)が含まれるディレクトリのパス

Linux と Windows

{webspace_protected_dirs}

親契約の保護されたディレクトリの設定が含まれるディレクトリのパス

Linux のみ

{webspace_root}

契約のルートのパス

Linux と Windows

{webspace_ssl_document_root}

親契約のセキュアドキュメントルートのパス - HTTPS 経由でアクセス可能なディレクトリ

Windows のみ

{webspace_statistics}

親契約の統計ファイルが含まれるディレクトリのパス(AWStats/Webalizer など)

Linux のみ

{webspace}

親契約の名前

Linux と Windows

メールコンテンツデータへのパスを指定する

移行元サーバから移行先サーバへメールコンテンツを移行するメカニズムは、Linux と Windows で異なります。

Linux では、移行するメールボックスについての情報を mail_users セクションに指定する必要があります。

mail_users:
  -
    name: johndoe
    password: 123qwe
    directory: /var/qmail/mailnames/johndoe

ここで "directory" には、移行元サーバでメールボックスコンテンツが格納されているディレクトリ、または移行先サーバへ手動で移行した後にメールボックスコンテンツが配置されたディレクトリの絶対パスを指定します。

Windows では、ホスティング記述ファイルには何も指定する必要がありません。すべてのメールコンテンツは Plesk のバックアップおよび復元メカニズムを使用して移行されます。

注:Windows の場合、Plesk Migrator には、移行先サーバに手動で移行されたメールコンテンツをインポートするための機能が搭載されていません。メールコンテンツを移行するには、移行元サーバへのアクセスが必要です。

データベースへのパスを指定する

Plesk Migrator では、他のパネルからの移行時に、MySQL および Microsoft SQL Server データベースをコピーすることができます。データベースコンテンツのコピーには 2 つの方法があります。

  • データベースサーバへのアクセス権が付与されている場合、コンテンツを直接コピーする。
  • データベースダンプファイルからコンテンツを復元する。

データベースサーバからコンテンツを直接コピーするには、Plesk マイグレータの構成ファイルにサーバを記述し、サーバへのアクセス情報も指定する必要があります。databases セクションで server パラメータを使用します。

databases:
  -
    server: mysql-db
    name: wordpress_9
    users:
      -
        login: exdbuser1
        password: 123qwe
  -
    server: mssql-db
    name: drupal_2
    users:
      -
        login: exdbuser2
        password: 123qwe

または

-
    name: wordpress_9
    dump: wordpress_9.sql
    users:
      -
        login: exdbuser1

データベースダンプファイルからコンテンツを復元するには、ダンプを特定のフォーマットで作成する必要があります。

  • MySQL の場合、ダンプは mysqldump ユーティリティなどで作成できます。
  • Microsoft SQL Server の場合、T-SQL の "BACKUP" コンストラクトを使用します。

ダンプを復元するには、以下のように dump オプションを指定します。

-
  name: wordpress_9
  dump: wordpress_9.sql
  user:
    login: exdbuser1

注:Microsoft SQL Server データベースの移行が可能なのは、移行元サーバ上の Microsoft SQL Server インスタンスのホスト名が移行先サーバで解決可能である場合のみです。