Jak przenieść witrynę Magento 2 z Localhost na serwer?

Proces przenoszenia witryny opartej na Magento 2 z jednego hosta lokalnego na inny nie jest procesem czasochłonnym. Ma jednak wiele drobiazgowych szczegółów i specjalnych aspektów, które należy wziąć pod uwagę przed przystąpieniem do procesu.

W tym poście na blogu sprawimy, że przeniesienie witryny Magento 2 z hosta lokalnego na serwer będzie tak proste, jak Lego. Miejmy wgląd.

Główne kroki

Na początek przyjrzyjmy się głównym etapom przenoszenia:

1. Sprawdzenie poprawności witryny Magento 2 na bieżącym hoście (A);
2. Przygotowanie zdalnego hosta (B);
3. Zdalne sprawdzenie hosta (B);
4. Przygotowanie danych do transferu; 4.1. Zrzut pliku; 4.2. Zrzut bazy danych;
5. Transfer danych;
6. Rozpakowywanie danych; 6.1. Rozpakowywanie plików; 6.2. Import baz danych;
7. Korekta danych dostępowych na zdalnym hoście (B);
8. Korekta uprawnień dostępu do plików i katalogów;
9. Standardowe procedury przed uruchomieniem Magento;
10. Kontrole wydajności Magento na zdalnym hoście (B);
11. Rozwiązanie częstych problemów.

Proste jak Lego: Wytyczne krok po kroku

1. Sprawdzenie poprawności witryny Magento 2 na bieżącym hoście

Tutaj wszystko jest proste: uruchom i sprawdź. Zazwyczaj do takich celów należy stworzyć zamówienie (pełny cykl). Następnie sprawdź:

• Szukaj;
• strony produktów,
• kategorie,
• konto klienta.

Jest to ważny etap, ponieważ pozwala uniknąć zmagań z pytaniami o to, kiedy dokładnie coś przestało działać po przejściu do nowego hosta. Pozwoli to również uniknąć konieczności radzenia sobie z podstawowymi problemami hosta, które można rozwiązać z wyprzedzeniem (A).

Zachęcam do NIE przerzucania na pół działającego Magento bez pilnej potrzeby. Znacznie łatwiej jest poradzić sobie ze wszystkimi problemami na bieżącym hoście (A) przed rozpoczęciem procesu przenoszenia. Sprawdzone i przetestowane – zaoszczędzi Ci to czasu i bólu szyi.

2. Przygotowanie zdalnego hosta (B)

Serwer, na którym wdrożona jest kopia Magento, musi spełniać minimalne wymagania dla Twojej wersji Magento.

Zapoznaj się z oficjalną dokumentacją, aby dowiedzieć się więcej o tych wymaganiach: https://devdocs.magento.com/guides/v2.3/install-gde/system-requirements-tech.html

Środowisko musi zostać skonfigurowane przed przystąpieniem do kolejnych kroków procesu transferu (serwer WWW z wirtualnym hostem, PHP, baza danych).

Niestety, konfiguracja każdej oddzielnej części wykracza poza nawias tego artykułu. Możesz jednak łatwo znaleźć wymagane dodatkowe informacje w Internecie. Więc nie powinno to sprawiać trudności.

Zalecam zwrócenie szczególnej uwagi na obecność wymaganych rozszerzeń PHP.

Jeśli masz jakieś pytania na którymkolwiek etapie tego samouczka, zostaw komentarz. Postaram się odpowiedzieć na wszystkie z nich.

3. Zdalne sprawdzenie hosta (B)

Przed przeniesieniem Magento upewnij się, że działa na nowym hoście, a sam host działa poprawnie. Najpierw sprawdź, czy serwer WWW odpowiada pod podanym adresem (zakładamy, że host został już skonfigurowany).

W moim przykładzie używam standardowej ścieżki, która jest dostępna zaraz po zainstalowaniu Apache2 na serwerze Linux:

> /var/www/html

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

* Tu i dalej, w razie potrzeby polecenia będą uruchamiane przez odpowiednich użytkowników. Jeśli polecenie jest uruchamiane bez nazwy użytkownika, wykonanie polecenia należy rozumieć od bieżącego użytkownika i dostępności odpowiednich uprawnień.

Jeśli po uruchomieniu tej komendy nie pojawią się żadne błędy, wszystko poszło dobrze i Twój plik `index.php` musi być dostępny pod adresem: {host}/index.php. Wynik w Twojej przeglądarce powinien wyglądać tak (chociaż wiele nadal zależy od Twojej wersji PHP):

Jeśli coś poszło nie tak i nie widzisz informacji o Twojej wersji PHP, skorzystaj z odpowiedniego przewodnika po konfiguracji serwera WWW, którego potrzebujesz.

Zalecam również wcześniejsze zapoznanie się z dziennikami – zaoszczędzi to sporo czasu.

Następnie sprawdź, czy usługa bazy danych została uruchomiona i działa poprawnie:

 mysql -u root -p

W rezultacie powinieneś pomyślnie połączyć się z MySQL. Użyj polecenia `exit`, aby wyjść.

* Wpisz login i hasło użyte podczas konfiguracji MySQL.

Co więcej, po pomyślnym połączeniu się z MySQL, będziesz musiał sprawdzić istniejące bazy danych.

 SHOW databases;

Nazwy baz danych, które planujesz przenieść, nie mogą być takie same, jak te, które już istnieją na nowym serwerze. W przypadku, gdy istnieją podobne bazy danych, problem ten należy rozwiązać ręcznie, usuwając na przykład istniejącą, ale nieużywaną bazę danych lub zmieniając nazwę bazy danych Magento, którą zamierzasz przenieść. Zauważ, że musisz koniecznie wpisać zmienioną nazwę w pliku konfiguracyjnym środowiska Magento `app/etc/env.php`.

Twój wynik powinien wyglądać następująco:

Ponadto musisz sprawdzić, czy sama usługa została uruchomiona i nasłuchuje standardowego portu za pomocą narzędzia netstat :

 netstat -vulntp | grep -i mysql

Twój wynik będzie wyglądał następująco:

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

4. Przygotowanie danych do transferu

4.1. Zrzut pliku

Przed utworzeniem zrzutu plików gorąco zachęcam do usunięcia wszystkich niepotrzebnych plików z katalogu Magento, jeśli takie są, tj. stare zrzuty, pamięć podręczna, logi itp.

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

Pozwoli ci to skrócić proces. Poza tym, że unikniesz przesyłania niepotrzebnych plików, unikniesz korzystania z miejsca na serwerze bez szczególnej potrzeby.

*NIE usuwaj na siłę `.htaccess` i innych ukrytych plików, jeśli używasz serwera WWW Apache2 (polecenie `rf` nie usuwa ich domyślnie). Pliki te są wymagane do poprawnego działania Magento.

Teraz przejdź do katalogu, w którym znajduje się nasze Magento na lokalnym serwerze (A). W moim przykładzie jest to:

 > /Users/sergei/PhpstormProjects

Katalog z Magento jest nazwany pod aws-botapi .

Stwórzmy archiwum do jego dalszego przesłania na zdalny host (B):

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

Należy sprawdzić, czy archiwum zostało utworzone:

 ls -la aws-botapi.tar.gz

4.2. Zrzut baz danych

Jeśli istnieje kilka osobnych baz danych, które są rozmieszczone lokalnie w Twojej witrynie Magento, wszystkie muszą zostać przeniesione. W moim przykładzie używane są dwie bazy danych. Można je znaleźć w konfiguracjach środowiska Magento `app/etc/env.php` w sekcji `db => connection => `.

Teraz zrzuć wszystkie bazy danych:

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

* Użyj takich informacji jak nazwa użytkownika bazy danych i nazwa bazy danych.

5. Transfer danych

Przenieś zrzut plików Magento za pomocą narzędzia `scp` (kopiowanie przez ssh) lub użyj dowolnych innych środków według własnego uznania (na przykład kopiowanie przez `ftp`):

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

Gdzie,

a) -i ~/.ssh/myprivatekey.pem to ścieżka do klucza prywatnego do połączenia (zignoruj ​​to, jeśli używasz wyłącznie hasła);

b) ec2-user to nazwa użytkownika do połączenia;

c) 52.12.187.98 to adres serwera;

d) /home/ec2-user to bezwzględna ścieżka na serwerze, do której kopiujemy pliki.

*Jeśli używasz portu innego niż standardowy, nie zapomnij zidentyfikować go za pomocą oddzielnego parametru (na przykład `-P 6000` dla portu 6000).

Po zakończeniu kopiowania zobaczysz linię tego rodzaju:

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

Powtórz te same czynności dla zrzutu plików:

 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. Rozpakowanie danych

6.1. Rozpakowywanie plików

Na serwerze (B) przejdźmy do katalogu, do którego skopiowaliśmy archiwa. Rozpakujmy pliki Magento do katalogu lokalnego hosta:

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

Upewnij się, że pliki zostały poprawnie rozpakowane:

 ls -la /var/www/html

Jeśli pliki Magento zostały rozpakowane do podkatalogu, prześlij je za pomocą poleceń `mv` lub `cp`.

6.2. Import baz danych

Połącz się z MySQL na serwerze (B):

 mysql -u root -p

Teraz utwórzmy nową bazę danych:

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

*Wynik powinien wyglądać tak:

 > Query OK, 1 row affected (0.01 sec)

Wykonaj podobne czynności, jeśli masz inne bazy danych.

Następnie zaimportuj bazy danych ze zrzutu:

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

Połącz się z MySQL:

 mysql -u root -p

i sprawdź, czy wszystkie bazy danych są obecne:

 SHOW databases;

Musi być dostępna lista wszystkich baz danych, w tym nasza:

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

Wybierz bazę danych, którą właśnie zaimportowaliśmy:

 USE db1;

i sprawdź obecność tabel:

 SHOW tables;

W przypadku, gdy tabele nie zostały utworzone lub są puste, sprawdź sam plik zrzutu i powtórz cały proces jeszcze raz z wyjątkiem kroku, w którym została utworzona nowa baza danych (ponieważ już istnieje).

7. Korekta danych dostępowych na zdalnym hoście (B)

Główne dane, które należy zmienić w Magento po przesłaniu to 1) podstawowe adresy URL oraz 2) klucze dostępu do MySQL:

Zmiana podstawowych adresów URL

Będziesz musiał zmienić wszystkie stare ścieżki w tabeli `core_config_data`. Na początek zlokalizujmy te pola za pomocą zapytania „wartość”, które zawiera stary adres. Załóżmy, że stary adres witryny to „1001101010.com”, wtedy polecenie wyszukiwania będzie wyglądało następująco:

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

*`\G` na końcu zapytania zamiast `;` poprawi czytelność rekordów.

** Nie zapomnij użyć `table_prefix` przed nazwami tabel, jeśli zostały zainstalowane.

Wynik będzie wyglądał tak:

 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)

W tym momencie naszym celem jest zmiana starego adresu na nowy. W tym celu upewnijmy się, że należy to zmienić we wszystkich wierszach (tak jest w większości przypadków, z wyjątkiem rzadkich przypadków, które dotyczą konfiguracji modułów 3rd party) i uruchom następujące zapytanie:

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

Zamieni on wszystkie wystąpienia wierszy „1001101010.com” w polu „wartość” na wiersz „mojanowadomena.com”.

Wynik powinien wyglądać następująco (liczba wierszy powinna być równa):

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

Następująca prośba:

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

Teraz nadszedł czas, aby przejść do edycji pliku środowiska `app/etc/env.php` (z katalogu głównego Magento; w przykładzie był to `/var/www/html/`).

Otwórzmy go w programie do edycji tekstu (ja używam Nano , choć to na pewno kwestia osobistych preferencji).

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

Następnie edytuj dane w `'db' => 'connection'` określając dokładne dane z nowego serwera w polach 'username' i 'password'.

* WAŻNE! Jeśli Twoja baza danych znajduje się na zdalnym serwerze, nie ma potrzeby zmiany danych. Jedyne, co musisz zrobić, to upewnić się, że bieżący serwer ma dostęp do tej zdalnej bazy danych. (Na przykład, że został dodany do białej listy zapory na serwerze bazy danych).

Użyj wartości „localhost” w polu „host”, aby zrozumieć, czy połączenie jest lokalne, czy nie.

Następnie zapisz plik.

8. Korekta praw dostępu do plików i katalogów

Aby dokładnie ustawić uprawnienia dostępu, musisz wiedzieć, od którego użytkownika iz jaką grupą działa Twój serwer sieciowy.

Najczęściej jest to „apache” dla CentOS lub „www-data” w Ubuntu. Z reguły nazwa użytkownika jest równa nazwie grupy. Jednak na różnych serwerach może się to różnić.

Poniższe polecenie pomoże ci to rozgryźć:

 ps aux | egrep '(apache|httpd)'

W rezultacie w pierwszej kolumnie zobaczysz nazwę użytkownika (nazwa grupy prawdopodobnie będzie taka sama. Jeśli jednak nie masz pewności, użyj polecenia `groups apache`, gdzie `apache` jest nazwą użytkownika, aby Sprawdź to).

Pierwszą rzeczą po tym, będziemy musieli przenieść wszystkie pliki i katalogi wewnątrz Magento do użytkownika serwera WWW (w przykładzie jest to `apache`. Dla użytkownika `www-data` po prostu zamień `apache:apache` na ` www-data:www-data` i podobnie dla innych):

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

Następnie sprawdź, czy zmiany zostały zastosowane, czy nie:

 ls -la /var/www/html

Wszystkie pliki i katalogi (oprócz nadrzędnego oznaczonego jako `..` muszą mieć użytkownika i grupę `apache` (jeśli `www-data` jest użytkownikiem serwera WWW w twoim systemie, to powinien być oznaczony jako właściciel):

Teraz wymagane jest dokładne ustawienie uprawnień dostępu do plików i katalogów Magento. Zgodnie z dokumentacją wysoce zalecana jest następująca konfiguracja:

*Wszystkie polecenia muszą być uruchamiane z roota Magento!, konsekwentnie 1 po 1. W tym przykładzie rootem Magento na serwerze jest `/var/www/html`.

Użyj polecenia `pwd`, aby sprawdzić bieżącą lokalizację.

 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

*Jeśli bieżący użytkownik nie ma uprawnień do uruchamiania tych poleceń, użyj `root ` (polecenie `sudo`, np. `sudo find…`)

9. Standardowe procedury przed uruchomieniem Magento

Czas sprawdzić, czy Magento uruchamia się z wiersza poleceń. Na początek przetestujmy standardowe wyjście poleceń, do których masz dostęp:

*Teraz, po skonfigurowaniu uprawnień, wszelki dostęp do Magento będzie wykonywany przez tego samego użytkownika serwera WWW, który generuje pliki, pliki pamięci podręcznej, statystyki itp. Jeśli to zignorujesz, Magento może przestać działać i będziesz zmuszony przywrócić uprawnienia jeszcze raz (poprzedni krok w niniejszych wytycznych).

**Aby zapewnić prawidłowe działanie, musisz znaleźć odpowiedni interpreter php na swoim serwerze. Zwykle alias `php` odnosi się do aktualnej wersji. Jednak często będziesz musiał wskazać pełną ścieżkę, na przykład `/usr/bin/php72`.

***Tu i dalej wszystkie polecenia Magento będą uruchamiane z katalogu głównego Magento na serwerze (B).

 sudo -u apache php bin/magento list

Spowoduje to wyświetlenie listy z poleceniami dostępnymi w wierszu poleceń:

Jeśli wszystko przebiegło pomyślnie, możesz przejść do kolejnych poleceń:

*Jeżeli przed transferem nie wyczyściłeś katalogów z pamięcią podręczną i wygenerowanymi plikami, to jest to właściwy moment, aby to zrobić za pomocą polecenia:

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

 sudo -u apache php bin/magento setup:upgrade

Możesz uniknąć uruchamiania tego polecenia, ale nadal zalecam upewnienie się, że wszystkie moduły są napisane i nie występują żadne błędy. W rezultacie zobaczysz listę z modułami, które zostały przetworzone, nie widząc żadnych błędów w procesie.

Wykonaj kompilację w celu wygenerowania niezbędnych plików Magento:

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

*W tym momencie bardzo ważne jest wykrycie wszystkich błędów, które wystąpiły. W przeciwnym razie Magento będzie działać nieprawidłowo. Jeśli nie znaleziono żadnych błędów, wszystko jest po prostu idealne. ?

Następnie wygeneruj statystyki (jeśli tryb produkcyjny jest włączony. Aby sprawdzić bieżący tryb, użyj następującego polecenia:

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

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

*Aby wygenerować statystyki dla określonych ustawień narodowych, podaj je jako parametr po poleceniu. Na przykład, `sudo -u apache php bin/magento setup:static-content:deploy ru_RU` zostanie użyte dla rosyjskiej lokalizacji.

Gratulacje! Pomyślnie przeniosłeś swój sklep Magento2 z localhost, aby poprawnie działał na nowym serwerze. Teraz otwórz go w przeglądarce, wpisując nowy adres!

10. Rozwiązywanie problemów: częste problemy

Problem 1

Problem:

Jeśli podczas kopiowania archiwum otrzymasz wiadomość typu:

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

Następnie powinieneś sprawdzić, gdzie w pierwszej kolejności skopiowałeś archiwum na serwerze. Jest bardzo prawdopodobne, że użytkownik, który zamierza się połączyć, nie ma uprawnień do utworzenia rekordu w tym katalogu (w przykładzie `/var/www/html`).

Rozwiązanie:

Można to rozwiązać zmieniając katalog, do którego próbujesz skopiować po uruchomieniu polecenia ` scp ` lub połączeniu z serwerem i dostosowując prawa dostępu do tego katalogu dla bieżącego użytkownika:

`sudo chown -R ec2-user /var/www/html` (ustaw użytkownika na właściciela katalogu `/var/www/html` oraz wszystkich dołączonych plików i katalogów) lub

`sudo chmod -R o+w /var/www/html` (zezwala na wszystkie (`inne`) tworzenie rekordu (`w-rite`) w katalogu `/var/www/html`).

Używaj tych poleceń z ostrożnością, ponieważ mają one bezpośredni wpływ na bezpieczeństwo systemu.

Wydanie #2

Problem:

Jeśli podczas importowania baz danych wystąpi następujący błąd `ERROR 1049 (42000): Nieznana baza danych 'db1'` (gdzie `db1` to nazwa bazy danych), oznacza to, że Twoja baza danych nie została utworzona.

Rozwiązanie:

Spróbuj uzyskać dostęp do `mysql` i ponownie utwórz tę bazę danych.

Wydanie #3

Problem:

Jeśli podczas zmiany właściciela plików i katalogów zobaczysz polecenie `chown: nieprawidłowy użytkownik: … `, prawdopodobnie niepoprawnie określiłeś użytkownika serwera WWW na swoim serwerze.

Rozwiązanie:

Zapoznaj się z odpowiednimi przewodnikami na temat konfiguracji serwera w twoim systemie lub użyj narzędzia `ps aux`, aby określić właściwego użytkownika.

Wydanie #4

Problem:

Jeśli występują błędy PHP podczas uruchamiania Magento na nowym serwerze (z reguły oznacza to brak niektórych rozszerzeń PHP)…

Rozwiązanie:

Można to rozwiązać, instalując brakujące rozszerzenia.

a) `Rozszerzenie json PHP jest wymagane do korzystania z NormalizerFormatter firmy Monolog` ―

Brak rozszerzenia *php-json*;

b) `PHP Błąd krytyczny: Nieprzechwycony błąd: klasa 'DOMDocument' nie została znaleziona w …` ―

brak rozszerzenia *php-xml*;

c) `Błąd krytyczny PHP: klasa 'IntlDateFormatter' nie została znaleziona w …` ―

Brak rozszerzenia *php-intl*.

Wydanie #5

Problem:

Jeśli brakuje rozszerzeń PHP podczas uruchamiania polecenia `composer update`, zobaczysz następujące błędy:

Na przykład,

`phpunit/phpunit 6.5.14 wymaga ext-mbstring * -> w twoim systemie brakuje żądanego rozszerzenia PHP mbstring.`

Rozwiązanie:

Aby poradzić sobie z takimi błędami, wystarczy zainstalować rozszerzenia PHP, do których odnosi się kompozytor. Na przykład `mniam zainstaluj php-mbstring`.

Pełną listę wymaganych rozszerzeń dla Twojej wersji Magento 2 można znaleźć w oficjalnej dokumentacji.

Dolna linia

Wszystko gotowe! W tym artykule zrobiłem co w mojej mocy, aby przedstawić łatwe do wykonania kroki dotyczące przenoszenia witryny Magento 2 z lokalnego hosta na serwer.

Jeśli nadal masz pytania lub chcesz podzielić się swoją opinią, skorzystaj z sekcji komentarzy poniżej. Zrobię co w mojej mocy, aby odpowiedzieć na wszystkie pytania i wątpliwości!