ローカルホストからサーバーに Magento 2 サイトを転送する方法は?

Magento 2 ベースのサイトをあるローカル ホストから別のローカル ホストに転送するプロセスは、時間のかかるプロセスではありません。 ただし、プロセスに入る前に考慮すべき重要な詳細と特別な側面がいくつかあります.

このブログ投稿では、Magento 2 サイトを localhost からサーバーに転送することを、レゴと同じくらい簡単にします。 洞察してみましょう。

主な手順

まず、転送の主な手順を見てみましょう。

1. 現在のホスト (A) での Magento 2 サイトのサニティ チェック。
2. リモートホストの準備 (B);
3. リモート ホスト チェック (B);
4. データ転送の準備。 4.1. ファイル ダンプ; 4.2. データベースのダンプ;
5. データ転送;
6. データの解凍; 6.1. ファイルの解凍; 6.2. データベースのインポート;
7. リモート ホスト (B) のデータ修正にアクセスします。
8. ファイルとディレクトリへのアクセス許可の修正。
9. Magento を起動する前の標準的な手順。
10. リモート ホスト (B) での Magento のパフォーマンス チェック。
11. よくある問題の解決。

レゴのように簡単: ステップバイステップのガイドライン

1. 現在のホストでの Magento 2 サイトの健全性チェック

ここではすべてが簡単です。実行して確認するだけです。 通常、このような目的のために注文 (完全なサイクル) を作成する必要があります。 次に確認します。

• 探す;
• 製品ページ、
• カテゴリ、
• お客様のアカウント。

これは重要な段階です。新しいホストに移動した後、何かが動作を停止した正確な時期に関する質問と格闘することを避けることができるからです。 また、これにより、事前に解決できる基本的なホストの問題 (A) に対処する必要がなくなります。

緊急の必要性がない限り、Magento を半分ずつ動作させないように転送しないことをお勧めします。 転送プロセスを開始する前に、現在のホスト (A) ですべての問題に対処する方がはるかに簡単です。 実証済みでテスト済み - これにより、時間と首の痛みの両方を節約できます。

2. リモートホスト (B) の準備

Magento コピーがデプロイされるサーバーは、Magento バージョンの最小要件を満たしている必要があります。

これらの要件の詳細については、公式ドキュメントを参照してください: https://devdocs.magento.com/guides/v2.3/install-gde/system-requirements-tech.html

転送プロセスの次のステップに進む前に、環境をセットアップする必要があります (仮想ホスト、PHP、データベースを備えた Web サーバー)。

残念ながら、各パーツの構成は、この記事の範囲を超えています。 ただし、必要な追加情報は Web 上で簡単に見つけることができます。 だから、それは難しいことではありません。

必要な PHP 拡張機能の存在に特に注意を払うことをお勧めします。

このチュートリアルのステップについて質問がある場合は、コメントを残してください。 私はそれらすべてに答えるために最善を尽くします。

3. リモートホストチェック (B)

Magento を移行する前に、新しいホストで Magento が動作し、ホスト自体が正常に動作することを確認してください。 最初に、Web サーバーが指定されたアドレスで応答することを確認します (ホストは既に構成されていると想定しています)。

この例では、Linux サーバーに Apache2 をインストールした直後に利用できる標準パスを使用します。

> /var/www/html

 sudo -u apache echo "<?php phpinfo();?>" > /var/www/html/index.php

*ここから先は、必要に応じて対応するユーザーからコマンドが実行されます。 コマンドがユーザー名なしで実行される場合、コマンドの実行は、現在のユーザーおよび対応する権限の可用性からのものであることを意味する必要があります。

このコマンドを実行してもエラーが表示されない場合は、すべて問題なく、ファイル `index.php` が次のアドレスで利用できるはずです: {host}/index.php。 ブラウザーの結果は次のようになります (ただし、PHP のバージョンによって大きく異なります)。

問題が発生し、PHP バージョンに関する情報が表示されない場合は、必要な Web サーバーの構成に関する対応するガイドに対処してください。

また、事前にログを調べることをお勧めします。これにより、時間を大幅に節約できます。

次に、データベース サービスが起動され、適切に動作することを確認します。

 mysql -u root -p

その結果、MySQL に正常に接続する必要があります。 終了するには「exit」コマンドを使用します。

* MySQL のセットアップ時に使用したログインとパスワードを入力します。

さらに、MySQL に正常に接続したら、既存のデータベースを確認する必要があります。

 SHOW databases;

転送する予定のデータベースの名前は、新しいサーバーに既に存在するものと同じであってはなりません。 類似のデータベースがある場合、この問題は、たとえば、既存の使用されていないデータベースを削除するか、転送する Magento データベースの名前を変更することにより、手動で解決する必要があります。 Magento 環境の設定ファイル `app/etc/env.php` に、変更した名前を必ず入力する必要があることに注意してください。

結果は次のようになります。

また、 netstatユーティリティを使用して、サービス自体が起動され、標準ポートをリッスンしていることを確認する必要があります。

 netstat -vulntp | grep -i mysql

結果は次のようになります。

 > tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 3366/mysqld

4. データ転送の準備

4.1. ファイルダンプ

ファイル ダンプを作成する前に、不要なファイル (古いダンプ、キャッシュ、ログなど) がある場合は、Magento ディレクトリからすべて削除することを強くお勧めします。

 rm -rf var/cache/* var/page_cache/* var/generation/* var/composer_home/cache/* var/log/* pub/static/*

これにより、プロセスを短縮できます。 不要なファイルを転送する必要がなくなるだけでなく、特に必要のないサーバー スペースの使用を避けることができます。

* Apache2 Web サーバーを使用している場合は、`.htaccess` およびその他の隠しファイルを強制的に削除しないでください (デフォルトでは `rf` コマンドはそれらを削除しません)。 これらのファイルは、Magento が正しく動作するために必要です。

次に、Magento がローカル サーバー (A) にあるディレクトリに移動します。 私の例では、次のとおりです。

 > /Users/sergei/PhpstormProjects

Magento を含むディレクトリは、 aws-botapi下に名前が付けられています。

リモートホスト (B) にさらに転送するためのアーカイブを作成しましょう。

 tar -zcf aws-botapi.tar.gz aws-botapi

アーカイブが作成されたことを確認する必要があります。

 ls -la aws-botapi.tar.gz

4.2. データベースのダンプ

Magento サイトにローカルに配置された複数の別個のデータベースがある場合、それらすべてを転送する必要があります。 私の例では、2 つのデータベースが使用されています。 `db => connection => ` セクションの Magento 環境 `app/etc/env.php` の構成でそれらを見つけることができます。

次に、すべてのデータベースをダンプします。

 mysqldump -u root -p db1 | gzip > ./db1.sql.gz mysqldump -u root -p db2 | gzip > ./db2.sql.gz

*データベースのユーザー名やデータベース名などの情報を使用します。

5. データ転送

「scp」ユーティリティを使用して Magento ファイル ダンプを転送する (ssh 経由でコピーする) か、必要に応じて他の手段を使用します (たとえば、「ftp」経由でコピーする)。

 scp -i ~/.ssh/myprivatekey.pem aws-botapi.tar.gz [email protected]:/home/ec2-user

どこ、

a) -i ~/.ssh/myprivatekey.pem は、接続用の秘密鍵へのパスです (パスワードのみを使用する場合は無視してください)。

b) ec2-user は接続用のユーザー名です。

c) 52.12.187.98 はサーバーアドレスです。

d) /home/ec2-userは、ファイルをコピーするサーバー上の絶対パスです。

※標準ポートと異なるポートを使用する場合は、別途パラメータで識別することを忘れないでください（例：6000ポートなら「-P 6000」）。

コピーが完了すると、次のような行が表示されます。

 > aws-botapi.tar.gz 100% 312MB 4.3MB/s 01:11

ファイル ダンプに対して同じアクションを繰り返します。

 scp -i ~/.ssh/myprivatekey.pem db1.sql.gz [email protected]:/home/ec2-user scp -i ~/.ssh/myprivatekey.pem db2.sql.gz [email protected]:/home/ec2-user

6. データの解凍

6.1. ファイルの解凍

サーバー (B) で、アーカイブをコピーしたディレクトリに移動しましょう。 Magento ファイルをローカル ホストのディレクトリに解凍しましょう。

 > tar -zxf aws-botapi.tar.gz -C /var/www/html/

ファイルが正しく展開されていることを確認してください。

 ls -la /var/www/html

Magento ファイルがサブディレクトリに展開されている場合は、「mv」または「cp」コマンドを使用して転送します。

6.2. データベースのインポート

サーバー (B) で MySQL に接続します。

 mysql -u root -p

それでは、新しいデータベースを作成しましょう。

 CREATE DATABASE IF NOT EXISTS db1 CHARACTER SET utf8 COLLATE utf8_general_ci;

*結果は次のようになります。

 > Query OK, 1 row affected (0.01 sec)

他のデータベースがある場合は、同様のアクションを実行してください。

次に、ダンプからデータベースをインポートします。

 gunzip < /home/ec2-user/db1.sql.gz | mysql -u root -p db1 gunzip < /home/ec2-user/db2.sql.gz | mysql -u root -p db2

MySQL に接続します。

 mysql -u root -p

すべてのデータベースが存在することを確認します。

 SHOW databases;

私たちのものを含むすべてのデータベースのリストが利用可能になる必要があります:

 +--------------------+ | Database | +--------------------+ | db1 | | db2 | | information_schema | | mysql | | performance_schema | +--------------------+ 5 rows in set (0.00 sec)

インポートしたデータベースを選択します。

 USE db1;

テーブルの存在を確認します。

 SHOW tables;

テーブルが作成されていないか空の場合は、ダンプ ファイル自体を確認し、新しいデータベースが作成されたときの手順を除いて、プロセス全体をもう一度繰り返します (既に存在するため)。

7. リモートホストでのアクセスデータ修正 (B)

転送後に Magento で変更する必要がある主なデータは、1) 基本 URL と 2) MySQL へのアクセス キーです。

基本 URL の変更

「core_config_data」テーブルの古いパスをすべて変更する必要があります。 まず、古い住所を含む「値」クエリを使用して、これらのフィールドをローカライズしましょう。 古い W​​eb サイトのアドレスが「1001101010.com」だったとします。この場合、検索コマンドは次のようになります。

 SELECT * FROM core_config_data WHERE `value` LIKE '%1001101010.com%' \G

`;` の代わりにクエリの最後に *`\G` を使用すると、レコードが読みやすくなります。

** インストールされている場合は、テーブル名の前に `table_prefix` を使用することを忘れないでください。

結果は次のようになります。

 mysql> SELECT * FROM core_config_data WHERE `value` LIKE '%1001101010.com%' \G *************************** 1. row *************************** config_id: 2 scope: default scope_id: 0 path: web/unsecure/base_url value: http://1001101010.com/

 *************************** 12. row *************************** config_id: 2401 scope: default scope_id: 0 path: web/secure/base_url value: https://1001101010.com/ *************************** 13. row *************************** config_id: 2402 scope: default scope_id: 0 path: web/secure/base_link_url value: https://1001101010.com/ 13 rows in set (0.00 sec)

この時点での目標は、古い住所を新しい住所に変更することです。 この目的のために、実際にすべての行で変更する必要があることを確認し (サードパーティ モジュールの構成を伴うまれなケースを除いて、ほとんどの場合そうです)、次のクエリを実行します。

 UPDATE `core_config_data` SET `value` = replace(value, '1001101010.com', 'mynewdomain.com') WHERE `value` LIKE '%1001101010.com%';

「値」フィールドの「1001101010.com」行はすべて「mynewdomain.com」行に置き換えられます。

結果は次のようになります (行数は同じである必要があります)。

 > Query OK, 13 rows affected (0.00 sec) > Rows matched: 13 Changed: 13 Warnings: 0

次のリクエスト:

 SELECT * FROM core_config_data WHERE `value` LIKE '%1001101010.com%' \G

ここで、環境のファイル `app/etc/env.php` の編集に進みます (Magento ルートから。例では、`/var/www/html/` でした)。

テキスト編集プログラムで開いてみましょう (もちろん個人的な好みの問題ですが、私はNanoを使用しています)。

 nano /var/www/html/app/etc/env.php

次に、'username' フィールドと 'password' フィールドに新しいサーバーからの正確なデータを指定して、`'db' => 'connection'` のデータを編集します。

*重要！ データベースがリモート サーバーにある場合、データを変更する必要はありません。 必要な作業は、現在のサーバーからそのリモート データベースへのアクセスがあることを確認することだけです。 (たとえば、データベース サーバーのファイアウォール ホワイトリストに追加されていること)。

'host' フィールドの 'localhost' 値を使用して、接続がローカルかどうかを確認します。

次に、ファイルを保存します。

8. ファイルやディレクトリのアクセス権の修正

アクセス許可を正確に設定するには、Web サーバーがどのユーザーから、どのグループで実行されているかを知る必要があります。

ほとんどの場合、CentOS の場合は「apache」、Ubuntu の場合は「www-data」です。 原則として、ユーザー名はグループ名と同じです。 ただし、異なるサーバーでは、これは異なる場合があります。

次のコマンドは、それを理解するのに役立ちます。

 ps aux | egrep '(apache|httpd)'

その結果、最初の列にユーザー名が表示されます (グループ名はおそらく同じです。ただし、よくわからない場合は、「groups apache」コマンドを使用してください。見てみな）。

この後、最初に、Magento 内のすべてのファイルとディレクトリを Web サーバー ユーザーに転送する必要があります (この例では「apache」です。「www-data」ユーザーの場合は、「apache:apache」を「apache:apache」に置き換えるだけです)。 www-data:www-data` など):

 sudo chown -R apache:apache /var/www/html

次に、変更が適用されているかどうかを確認します。

 ls -la /var/www/html

すべてのファイルとディレクトリ (`..` としてマークされた親を除く) には、ユーザーと `apache` グループが必要です (`www-data` がシステム内の Web サーバー ユーザーである場合は、オーナー）：

現在、Magento のファイルとディレクトリへのアクセス許可を正確に設定する必要があります。 ドキュメントによると、次のセットアップが強く推奨されます。

*すべてのコマンドはルート Magento から実行する必要があります。一貫して 1 つずつ実行します。例では、サーバー上の Magento ルートは `/var/www/html` です。

現在の場所を確認するには、「pwd」コマンドを使用します。

 find var generated vendor pub/static pub/media app/etc -type f -exec chmod u+w {} + find var generated vendor pub/static pub/media app/etc -type d -exec chmod u+w {} + chmod u+x bin/magento

*現在のユーザーにこれらのコマンドを実行する権限がない場合は、ユーザーの「root」(「sudo find …」などの「sudo」コマンド) を使用します。

9. Magento を起動する前の標準的な手順

コマンドラインから Magento が起動することを確認します。 まず、アクセスできるコマンドの標準出力をテストしましょう。

*権限の設定後、Magento へのアクセスは、ファイル、キャッシュ ファイル、静的などを生成する同じ Web サーバー ユーザーから行われます。これを無視すると、Magento の実行が停止し、権限の復元が強制される場合があります。もう一度 (これらのガイドラインの前のステップ)。

**正確な操作のためには、サーバー上で適切なphpインタープリターを見つける必要があります。 通常、 `php` エイリアスは最新バージョンを参照します。 ただし、多くの場合、たとえば `/usr/bin/php72` のようにフル パスを指定する必要があります。

***これ以降、すべての Magento コマンドはサーバー (B) の Magento ルート ディレクトリから実行されます。

 sudo -u apache php bin/magento list

これにより、コマンドラインで使用可能なコマンドのリストが作成されます。

すべてが成功した場合は、次のコマンドに進むことができます。

*転送前に、キャッシュと生成されたファイルを含むディレクトリをクリアしていない場合は、次のコマンドを使用してこれを行うのが適切な時期です。

 sudo rm -rf var/cache/* var/page_cache/* var/generation/*

 sudo -u apache php bin/magento setup:upgrade

このコマンドの実行を回避できますが、すべてのモジュールが書き込まれ、エラーが発生していないことを確認することをお勧めします。 その結果、処理されたモジュールのリストが表示されますが、処理中にエラーは表示されません。

必要な Magento ファイルを生成するためにコンパイルを実行します。

 sudo -u apache php bin/magento setup:di:compile

*この時点で、発生したすべてのエラーを検出することが重要です。 そうしないと、Magento が正しく動作しません。 エラーが見つからない場合は、すべてが完璧です。 ?

次に、スタティックを生成します (プロダクション モードが有効になっている場合)。現在のモードを確認するには、次のコマンドを使用します。

 sudo -u apache php bin/magento deploy:mode:show

 sudo -u apache php bin/magento setup:static-content:deploy

*特定のロケールの静的を生成するには、コマンドの後にパラメーターとして指定します。 たとえば、ロシア語ロケールには「sudo -u apache php bin/magento setup:static-content:deploy ru_RU」が使用されます。

おめでとう！ Magento2 ストアを localhost から正常に転送して、新しいサーバーで適切に動作させることができました。 次に、新しいアドレスを入力してブラウザで開きます。

10. トラブルシューティング: よくある問題

問題＃1

問題：

アーカイブをコピーするときに、次のようなメッセージが表示された場合:

 scp: /var/www/html/aws-botapi.tar.gz: Permission denied

次に、最初のインスタンスでサーバー上のアーカイブをコピーした場所を確認する必要があります。 接続しようとしているユーザーが、このディレクトリ (例では「/var/www/html」) にレコードを作成する権限を持っていない可能性が高いです。

解決：

これは、` scp ` コマンドを実行するか、サーバーに接続してコピーしようとするディレクトリを変更し、現在のユーザーのこのディレクトリへのアクセス許可を調整することで解決できます。

`sudo chown -R ec2-user /var/www/html` (ユーザーを `/var/www/html` ディレクトリおよび含まれるすべてのファイルとディレクトリの所有者にする)、または

`sudo chmod -R o+w /var/www/html` (ディレクトリ `/var/www/html` でレコード (`w-rite`) を作成するすべて (`o-ther`) を許可します)。

これらのコマンドはシステムのセキュリティに直接影響するため、注意して使用してください。

問題＃2

問題：

データベースのインポート時に「エラー 1049 (42000): 不明なデータベース 'db1'」(「db1」はデータベースの名前) というエラーが発生した場合、データベースは作成されていません。

解決：

`mysql` にアクセスして、このデータベースをもう一度作成し直してください。

問題＃3

問題：

ファイルとディレクトリの所有者を変更するときに、「chown: 無効なユーザー: …」というコマンドが表示される場合は、サーバーで Web サーバー ユーザーを正しく指定していない可能性があります。

解決：

システム内のサーバーの構成に関する対応するガイドを参照するか、「ps aux」ユーティリティを使用して適切なユーザーを決定してください。

問題＃4

問題：

新しいサーバーで Magento を起動したときに PHP エラーが発生した場合 (原則として、PHP 拡張機能がいくつか存在しないことを意味します)…

解決：

これは、不足している拡張機能をインストールすることで解決できます。

a) `Monolog の NormalizerFormatter を使用するには、PHP の json 拡張機能が必要です` ―

*php-json* 拡張子がありません。

b) `PHP Fatal error: Uncaught Error: Class 'DOMDocument' not found in …` ―

*php-xml* 拡張子がありません。

c) `PHP Fatal error: Class 'IntlDateFormatter' not found in …` ―

*php-intl* 拡張子がありません。

問題＃5

問題：

`composer update` コマンドの実行時に PHP 拡張機能が見つからない場合、次のエラーが表示されます。

例えば、

`phpunit/phpunit 6.5.14 には ext-mbstring が必要です * -> 要求された PHP 拡張機能 mbstring がシステムにありません。`

解決：

このようなエラーに対処するには、コンポーザが参照している PHP 拡張機能をインストールするだけです。 たとえば、「yum install php-mbstring」です。

Magento 2 バージョンに必要な拡張機能の完全なリストは、公式ドキュメントに記載されています。

結論

準備万端です！ この記事では、Magento 2 サイトをローカルホストからサーバーに転送するための簡単な手順を提示するために最善を尽くしました.

まだ質問がある場合、または意見を共有したい場合は、下のコメント セクションを使用してください。 不安や疑問に全力でお答えします！