Como transferir o site Magento 2 do localhost para o servidor?
Publicados: 2019-06-06O processo de transferência de um site baseado em Magento 2 de um host local para outro não é um processo demorado. No entanto, ele tem vários detalhes minuciosos e aspectos especiais que devem ser levados em consideração antes de mergulhar no processo.
Nesta postagem do blog, tornaremos a transferência de um site Magento 2 do host local para o servidor tão fácil quanto o Lego. Vamos ter um insight.
Índice
- Etapas principais
- Fácil como Lego: orientações passo a passo
- 1. Verificação de sanidade do site Magento 2 no host atual
- 2. Preparando o host remoto (B)
- 3. Verificação de host remoto (B)
- 4. Preparando os dados para transferência
- 4.1. Despejo de arquivo
- 4.2. Despejo de bancos de dados
- 5. Transferência de dados
- 6. Descompactação de dados
- 6.1. Descompactação de arquivos
- 6.2. Importação de bancos de dados
- 7. Correção de dados de acesso no host remoto (B)
- 8. Correção de permissões de acesso a arquivos e diretórios
- 10. Solução de problemas: problemas frequentes
- Problema 1
- Edição nº 2
- Edição nº 3
- Edição nº 4
- Edição nº 5
- Resultado final
Etapas principais
Para começar, vamos dar uma olhada nas principais etapas da transferência:
- Verificação de sanidade do site Magento 2 no host atual (A);
- Preparando o host remoto (B);
- Verificação de host remoto (B);
- Preparando os dados para transferência; 4.1. Despejo de arquivo; 4.2. Despejo de banco de dados;
- Transferência de dados;
- Descompactação de dados; 6.1. Descompactação de arquivos; 6.2. Importação de bases de dados;
- Correção de dados de acesso no host remoto (B);
- Correção de permissões de acesso a arquivos e diretórios;
- Procedimentos padrão antes de lançar o Magento;
- Verificações de desempenho do Magento no host remoto (B);
- Solução de problemas frequentes.
Fácil como Lego: orientações passo a passo
1. Verificação de sanidade do site Magento 2 no host atual
Tudo é fácil aqui: corra e confira. Normalmente, um pedido (ciclo completo) deve ser criado para tais fins. Então verifique:
- procurar;
- páginas de produtos,
- categorias,
- conta do cliente.
Este é um estágio importante, pois permite que você evite lutar com perguntas sobre quando exatamente algo parou de funcionar após a mudança para um novo host. Além disso, isso evitará a necessidade de lidar com os problemas básicos do host que podem ser resolvidos antecipadamente (A).
Eu encorajo você a NÃO transferir pela metade um Magento operando sem qualquer necessidade urgente. É muito mais fácil lidar com todos os problemas no host atual (A) antes de iniciar o processo de transferência. Comprovado e testado – isso economizará tempo e dor no pescoço.
2. Preparando o host remoto (B)
O servidor no qual a cópia do Magento é implantada deve atender aos requisitos mínimos da sua versão do Magento.
Estude a documentação oficial para saber mais sobre esses requisitos: https://devdocs.magento.com/guides/v2.3/install-gde/system-requirements-tech.html
O ambiente deve ser configurado antes de prosseguir para as próximas etapas do processo de transferência (servidor web com host virtual, PHP, banco de dados).
Infelizmente, a configuração de cada parte separada está além dos limites deste artigo. No entanto, você pode encontrar facilmente as informações adicionais necessárias na web. Então, não deve ter dificuldade.
Eu recomendo prestar atenção especial à presença das extensões PHP necessárias.
Se você tiver alguma dúvida em qualquer etapa deste tutorial, por favor, deixe um comentário. Farei o possível para responder a todas elas.
3. Verificação de host remoto (B)
Antes de transferir o Magento, verifique se ele funciona no novo host e se o próprio host funciona corretamente. Primeiro, verifique se o servidor web responde no endereço indicado (assumimos que o host já foi configurado).
No meu exemplo, eu uso o caminho padrão que está disponível logo após a instalação do Apache2 no servidor Linux:
> /var/www/html
sudo -u apache echo "<?php phpinfo();?>" > /var/www/html/index.php
*Aqui e mais adiante, os comandos serão executados pelos usuários correspondentes, se necessário. Se o comando for executado sem um nome de usuário, a execução do comando deve ser feita a partir do usuário atual e da disponibilidade de quaisquer permissões correspondentes.
Se nenhum erro aparecer após a execução deste comando, então tudo correu bem e seu arquivo `index.php` deve estar disponível no seguinte endereço: {host}/index.php. O resultado no seu navegador deve ficar assim (embora muito ainda dependa da sua versão do PHP):
Se algo deu errado e você não vê informações sobre sua versão do PHP, por favor, encaminhe um guia correspondente sobre a configuração de um servidor web que você precisa.
Além disso, recomendo estudar os logs com antecedência – isso economizará muito do seu tempo.
Em seguida, verifique se o serviço de banco de dados foi iniciado e funciona corretamente:
mysql -u root -p
Como resultado, você deve se conectar com sucesso ao MySQL. Use o comando `exit` para sair.
* Digite o login e a senha que você usou ao configurar o MySQL.
Além disso, após conectar-se ao MySQL com sucesso, você precisará verificar os bancos de dados existentes.
SHOW databases;
Os nomes dos bancos de dados que você planeja transferir não devem ser iguais aos que já existem no novo servidor. Caso existam bancos de dados semelhantes, esse problema deve ser resolvido manualmente, excluindo um banco de dados existente, mas não usado, por exemplo, ou renomeando um banco de dados Magento que você pretende transferir. Observe que você deve necessariamente inserir o nome alterado no arquivo de configuração do ambiente Magento `app/etc/env.php`.
Seu resultado deve ter a seguinte aparência:
Além disso, você precisa verificar se o próprio serviço foi iniciado e escuta a porta padrão usando o utilitário netstat :
netstat -vulntp | grep -i mysql
Seu resultado terá a seguinte aparência:
> tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 3366/mysqld
4. Preparando os dados para transferência
4.1. Despejo de arquivo
Antes de criar um dump de arquivo, eu recomendo fortemente que você retire todos os arquivos desnecessários do diretório Magento, se houver, ou seja, dumps antigos, cache, logs, etc.
rm -rf var/cache/* var/page_cache/* var/generation/* var/composer_home/cache/* var/log/* pub/static/*
Isso permitirá que você encurte o processo. Além de evitar a transferência de arquivos desnecessários, você evitará usar o espaço do servidor sem nenhuma necessidade específica.
*NÃO exclua à força `.htaccess` e outros arquivos ocultos, se você usa o servidor web Apache2 (o comando `rf` não os exclui por padrão). Esses arquivos são necessários para a operação correta do Magento.
Agora, vá para o diretório onde está nosso Magento no servidor local (A). No meu exemplo é:
> /Users/sergei/PhpstormProjects
O diretório com o Magento é nomeado em aws-botapi
.
Vamos criar um arquivo para sua posterior transferência para o host remoto (B):
tar -zcf aws-botapi.tar.gz aws-botapi
Você deve verificar se o arquivo foi criado:
ls -la aws-botapi.tar.gz
4.2. Despejo de bancos de dados
Se houver vários bancos de dados separados organizados localmente em seu site Magento, todos eles devem ser transferidos. No meu exemplo, dois bancos de dados são usados. Você pode encontrá-los nas configurações do ambiente Magento `app/etc/env.php` na seção `db => connection => `.
Agora, despeje todos os bancos de dados:
mysqldump -u root -p db1 | gzip > ./db1.sql.gz mysqldump -u root -p db2 | gzip > ./db2.sql.gz
* Use informações como nome de usuário do banco de dados e nome do banco de dados.
5. Transferência de dados
Transfira o dump de arquivos Magento usando o utilitário `scp` (copiando via ssh) ou use qualquer outro meio de sua conveniência (por exemplo, copiando via `ftp`):
scp -i ~/.ssh/myprivatekey.pem aws-botapi.tar.gz [email protected]:/home/ec2-user
Onde,
a) -i ~/.ssh/myprivatekey.pem é o caminho para a chave privada para conexão (ignore isso se você usar apenas senha);
b) ec2-user é o nome de usuário para conexão;
c) 52.12.187.98 é o endereço do servidor;
d) /home/ec2-user é o caminho absoluto no servidor, para onde copiamos os arquivos.
*Se você usar uma porta diferente da padrão, não esqueça de identificá-la usando um parâmetro separado (por exemplo, `-P 6000` para porta 6000).
Após a conclusão da cópia, você verá uma linha do tipo:
> aws-botapi.tar.gz 100% 312MB 4.3MB/s 01:11
Repita as mesmas ações para despejo de arquivos:
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. Descompactação de dados
6.1. Descompactação de arquivos
No servidor (B), vamos navegar até o diretório para o qual copiamos os arquivos. Vamos descompactar os arquivos do Magento para o diretório do host local:
> tar -zxf aws-botapi.tar.gz -C /var/www/html/
Certifique-se de verificar se os arquivos foram descompactados corretamente:
ls -la /var/www/html
Se os arquivos Magento foram descompactados para o subdiretório, transfira-os usando os comandos `mv` ou `cp`.
6.2. Importação de bancos de dados
Conecte-se ao MySQL no servidor (B):
mysql -u root -p
Agora, vamos criar um novo banco de dados:
CREATE DATABASE IF NOT EXISTS db1 CHARACTER SET utf8 COLLATE utf8_general_ci;
*O resultado deve ficar assim:
> Query OK, 1 row affected (0.01 sec)
Faça as ações semelhantes caso você tenha outros bancos de dados.
Em seguida, importe bancos de dados do dump:
gunzip < /home/ec2-user/db1.sql.gz | mysql -u root -p db1 gunzip < /home/ec2-user/db2.sql.gz | mysql -u root -p db2
Conecte-se ao MySQL:
mysql -u root -p
e verifique se todos os bancos de dados estão presentes:
SHOW databases;
A lista de todos os bancos de dados deve estar disponível, incluindo o nosso:
+--------------------+ | Database | +--------------------+ | db1 | | db2 | | information_schema | | mysql | | performance_schema | +--------------------+ 5 rows in set (0.00 sec)
Selecione o banco de dados que acabamos de importar:
USE db1;
e verifique a presença de tabelas:
SHOW tables;
Caso as tabelas não tenham sido criadas ou estejam vazias, verifique o próprio arquivo de despejo e repita todo o processo mais uma vez, exceto a etapa em que um novo banco de dados foi criado (pois já existe).
7. Correção de dados de acesso no host remoto (B)
Os principais dados que devem ser alterados no Magento após serem transferidos são 1) URLs básicos e 2) chaves de acesso ao MySQL:
Alterando URLs básicos
Você precisará alterar todos os caminhos antigos na tabela `core_config_data`. Para começar, vamos localizar esses campos usando a consulta 'valor' que inclui o endereço antigo. Vamos supor que o endereço do site antigo era '1001101010.com', então o comando de pesquisa terá a seguinte aparência:
SELECT * FROM core_config_data WHERE `value` LIKE '%1001101010.com%' \G
*`\G` no final da consulta em vez de `;` tornará os registros mais legíveis.
** Não se esqueça de usar `table_prefix` antes dos nomes das tabelas se ela estiver instalada.
O resultado ficará mais ou menos assim:
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)
Neste ponto, nosso objetivo é alterar o endereço antigo para um novo. Para isso, certifique-se de que ele deve ser alterado em todas as linhas (na maioria das vezes, exceto em alguns casos raros que envolvem a configuração de módulos de terceiros) e execute a seguinte consulta:
UPDATE `core_config_data` SET `value` = replace(value, '1001101010.com', 'mynewdomain.com') WHERE `value` LIKE '%1001101010.com%';
Ele substituirá todas as ocorrências de linhas `1001101010.com` no campo `value` para a linha `mynewdomain.com`.
O resultado deve ser aproximadamente o seguinte (o número de linhas deve ser igual):
> Query OK, 13 rows affected (0.00 sec) > Rows matched: 13 Changed: 13 Warnings: 0
O seguinte pedido:
SELECT * FROM core_config_data WHERE `value` LIKE '%1001101010.com%' \G
Agora, é hora de editar o arquivo do ambiente `app/etc/env.php` (da raiz do Magento; no exemplo, era `/var/www/html/`).
Vamos abri-lo em um programa de edição de texto (eu uso Nano embora seja certamente a questão de preferências pessoais).
nano /var/www/html/app/etc/env.php
Em seguida, edite os dados em `'db' => 'connection'` especificando os dados precisos do novo servidor nos campos 'username' e 'password'.
* IMPORTANTE! Se seu banco de dados estiver localizado em um servidor remoto, não há necessidade de alterar os dados. A única coisa que você precisa fazer é certificar-se de que há acesso do servidor atual a esse banco de dados remoto. (Por exemplo, que foi adicionado à lista de permissões do firewall no servidor de banco de dados).
Use o valor 'localhost' no campo 'host' para entender se a conexão é local ou não.
Em seguida, salve o arquivo.
8. Correção de permissões de acesso a arquivos e diretórios
Para configurar com precisão as permissões de acesso, você precisa saber de qual usuário e com qual grupo seu servidor web é executado.
Mais frequentemente, é `apache` para CentOS ou `www-data` no Ubuntu. Como regra, o nome de usuário é igual ao nome do grupo. No entanto, em servidores diferentes, isso pode ser diferente.
O comando a seguir irá ajudá-lo a descobrir:
ps aux | egrep '(apache|httpd)'
Como resultado, na primeira coluna, você verá o nome de usuário (o nome do grupo provavelmente será o mesmo. No entanto, se você não tiver certeza, use o comando `groups apache`, onde `apache` é o nome de usuário para Confira).
A primeira coisa depois disso, precisaremos transferir todos os arquivos e diretórios dentro do Magento para o usuário do servidor web (é `apache` no exemplo. Para o usuário `www-data` simplesmente substitua `apache:apache` por ` www-data:www-data`, e da mesma forma para outros):
sudo chown -R apache:apache /var/www/html
Em seguida, verifique se as alterações foram aplicadas ou não:
ls -la /var/www/html
Todos os arquivos e diretórios (exceto o pai marcado como `..` deve ter um usuário e o grupo `apache` (se `www-data` for um usuário de servidor web em seu sistema, então ele deve ser marcado como um proprietário):
Agora, é necessário configurar com precisão as permissões de acesso aos arquivos e diretórios do Magento. De acordo com a documentação, a seguinte configuração é altamente recomendada:
*Todos os comandos devem ser executados da raiz do Magento!, consistentemente 1 após 1. No exemplo, a raiz do Magento no servidor é `/var/www/html`.
Use o comando `pwd` para verificar a localização atual.
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
*Se o usuário atual não tiver permissões para executar esses comandos, use o comando `root` ( `sudo` do usuário, como `sudo find …`)
9. Procedimentos padrão antes de lançar o Magento
É hora de verificar se o Magento é iniciado a partir da linha de comando. Para começar, vamos testar a saída padrão dos comandos aos quais você tem acesso:
*Agora, depois de configurar as permissões, qualquer acesso ao Magento será feito pelo mesmo usuário do servidor web que gera arquivos, arquivos de cache, estáticos, etc. Se você ignorar isso, o Magento pode parar de funcionar e você será forçado a restaurar as permissões mais uma vez (a etapa anterior nestas diretrizes).
**Para uma operação precisa, você precisará encontrar o interpretador php
correto em seu servidor. Normalmente, o alias `php` refere-se à versão atualizada. No entanto, muitas vezes você precisará indicar o caminho completo, como `/usr/bin/php72` por exemplo.
***Aqui e além disso, todos os comandos do Magento serão executados a partir do diretório raiz do Magento no servidor (B).
sudo -u apache php bin/magento list
Isso fará com que a lista com os comandos disponíveis na linha de comandos:
Se tudo ocorreu com sucesso, você pode prosseguir para os outros comandos:
*Se antes da transferência você não limpava os diretórios com cache e os arquivos gerados, este é o momento certo para fazer isso usando o seguinte comando:
sudo rm -rf var/cache/* var/page_cache/* var/generation/*
sudo -u apache php bin/magento setup:upgrade
Você pode evitar a execução deste comando, mas ainda assim recomendo certificar-se de que todos os módulos estejam escritos e que nenhum erro ocorra. Como resultado, você verá uma lista com os módulos que foram processados, sem ver nenhum erro no processo.
Execute a compilação para gerar os arquivos Magento necessários:
sudo -u apache php bin/magento setup:di:compile
*Neste ponto, é fundamental detectar todos os erros que ocorreram. Caso contrário, o Magento será executado incorretamente. Se nenhum erro foi encontrado, então tudo está perfeito. ?
Em seguida, gere statics (se o modo de produção estiver ativado. Para verificar seu modo atual, use o seguinte comando:
sudo -u apache php bin/magento deploy:mode:show
sudo -u apache php bin/magento setup:static-content:deploy
*Para gerar estatísticas para uma localidade específica, especifique-a como um parâmetro após o comando. Por exemplo, `sudo -u apache php bin/magento setup:static-content:deploy ru_RU` será usado para a localidade russa.
Parabéns! Você transferiu com sucesso sua loja Magento2 do localhost para operar corretamente em um novo servidor. Agora, abra-o em um navegador inserindo um novo endereço!
10. Solução de problemas: problemas frequentes
Problema 1
Problema:
Se ao copiar o arquivo, você receber uma mensagem do tipo:
scp: /var/www/html/aws-botapi.tar.gz: Permission denied
Em seguida, você deve verificar onde copiou o arquivo no servidor em primeira instância. É muito provável que o usuário que pretende se conectar não tenha permissão para fazer um registro neste diretório (`/var/www/html` no exemplo).
Solução:
Isso pode ser resolvido alterando o diretório onde você tenta copiar ao executar o comando `scp` ou conectando-se ao servidor e ajustando as permissões de acesso a este diretório para o usuário atual:
`sudo chown -R ec2-user /var/www/html` (torna um usuário o proprietário do diretório `/var/www/html` e de todos os arquivos e diretórios incluídos), ou
`sudo chmod -R o+w /var/www/html` (permite que todos (`o-ther`) façam um registro (`w-rite`) no diretório `/var/www/html`).
Use esses comandos com cuidado, pois eles influenciam diretamente a segurança do seu sistema.
Edição nº 2
Problema:
Se ao importar bancos de dados ocorrer o seguinte erro `ERRO 1049 (42000): Banco de dados desconhecido 'db1'` (onde `db1` é o nome de um banco de dados), então seu banco de dados não foi criado.
Solução:
Tente acessar o `mysql` e recrie este banco de dados novamente.
Edição nº 3
Problema:
Se ao alterar o proprietário dos arquivos e diretórios, você vir o comando `chown: invalid user: … `, provavelmente você especificou o usuário do servidor web incorretamente em seu servidor.
Solução:
Consulte os guias correspondentes sobre a configuração do servidor em seu sistema ou use o utilitário `ps aux` para determinar o usuário correto.
Edição nº 4
Problema:
Se houver erros de PHP ao iniciar o Magento em um novo servidor (como regra, isso significa a ausência de algumas extensões PHP)…
Solução:
Isso pode ser resolvido com a instalação das extensões ausentes.
a) `A extensão json do PHP é necessária para usar o NormalizerFormatter do Monolog` ―
A extensão *php-json* está ausente;
b) `PHP Fatal error: Uncaught Error: Classe 'DOMDocument' não encontrada em …` ―
A extensão *php-xml* está ausente;
c) `PHP Fatal error: Classe 'IntlDateFormatter' não encontrada em …` ―
*php-intl* extensão está faltando.
Edição nº 5
Problema:
Se as extensões do PHP estiverem faltando ao executar o comando `composer update`, você verá os seguintes erros:
Por exemplo,
`phpunit/phpunit 6.5.14 requer ext-mbstring * -> a extensão PHP solicitada mbstring está faltando em seu sistema.`
Solução:
Para lidar com esses erros, você precisa simplesmente instalar as extensões PHP às quais o compositor está se referindo. Por exemplo, `yum install php-mbstring`.
Uma lista completa das extensões necessárias para sua versão do Magento 2 pode ser encontrada na documentação oficial.
Resultado final
Estás pronto! Neste artigo, fiz o meu melhor para apresentar etapas fáceis de seguir para transferir seu site Magento 2 do host local para o servidor.
Se você ainda tiver dúvidas ou quiser compartilhar sua opinião, sinta-se à vontade para usar a seção de comentários abaixo. Farei o meu melhor para responder a todas as perguntas e preocupações!