Localhost에서 서버로 Magento 2 사이트를 전송하는 방법은 무엇입니까?

게시 됨: 2019-06-06

한 로컬 호스트에서 다른 로컬 호스트로 Magento 2 기반 사이트를 전송하는 프로세스는 시간이 많이 걸리는 프로세스가 아닙니다. 그러나 프로세스에 뛰어들기 전에 고려해야 할 몇 가지 핵심적인 세부 사항과 특별한 측면이 있습니다.

이 블로그 포스트에서는 마젠토 2 사이트를 localhost에서 서버로 레고처럼 쉽게 옮기도록 하겠습니다. 통찰력을 갖자.

목차

  • 주요 단계
  • Easy as Lego: 단계별 지침
    • 1. 현재 호스트에 대한 Magento 2 사이트 온전성 검사
    • 2. 원격 호스트(B) 준비
    • 3. 원격 호스트 확인(B)
    • 4. 데이터 전송 준비
      • 4.1. 파일 덤프
      • 4.2. 데이터베이스 덤프
    • 5. 데이터 전송
    • 6. 데이터 풀기
      • 6.1. 파일 압축 풀기
      • 6.2. 데이터베이스 가져오기
    • 7. 원격 호스트(B)에서 액세스 데이터 수정
    • 8. 파일 및 디렉토리 접근 권한 정정
    • 10. 문제 해결: 자주 발생하는 문제
      • 문제 #1
      • 문제 #2
      • 문제 #3
      • 문제 #4
      • 문제 #5
  • 결론

주요 단계

우선 전송의 주요 단계를 살펴보겠습니다.

  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. 자주 발생하는 문제의 해결.

Easy as Lego: 단계별 지침

1. 현재 호스트에 대한 Magento 2 사이트 온전성 검사

여기에서 모든 것이 쉽습니다. 실행하고 확인하십시오. 일반적으로 이러한 목적을 위해 주문(전체 주기)을 생성해야 합니다. 그런 다음 다음을 확인하십시오.

  • 검색;
  • 제품 페이지,
  • 카테고리,
  • 고객의 계정.

이것은 새 호스트로 이동한 후 정확히 어떤 것이 작동을 멈췄는지에 관한 질문과 씨름하지 않도록 해주기 때문에 중요한 단계입니다. 또한 사전에 해결할 수 있는 기본 호스트 문제(A)를 처리해야 하는 필요성에서 벗어날 수 있습니다.

긴급한 필요 없이 Magento를 작동 하는 반 으로 전환하지 않는 것이 좋습니다. 전송 프로세스를 시작하기 전에 현재 호스트(A)의 모든 문제를 처리하는 것이 훨씬 쉽습니다. 입증되고 테스트되었습니다. 시간과 목의 통증을 모두 절약할 수 있습니다.

2. 원격 호스트(B) 준비

Magento 복사본이 배포되는 서버는 Magento 버전에 대한 최소 요구 사항을 충족해야 합니다.

이러한 요구 사항에 대해 자세히 알아보려면 공식 문서를 참조하십시오. https://devdocs.magento.com/guides/v2.3/install-gde/system-requirements-tech.html

전송 프로세스의 다음 단계(가상 호스트가 있는 웹 서버, PHP, 데이터베이스)를 진행하기 전에 환경을 설정해야 합니다.

불행히도 각 개별 부품의 구성은 이 기사의 범위를 벗어납니다. 그러나 필요한 추가 정보는 웹에서 쉽게 찾을 수 있습니다. 따라서 어려움이 없어야 합니다.

필요한 PHP 확장의 존재에 특별한 주의를 기울이는 것이 좋습니다.

이 튜토리얼의 단계에 대해 질문이 있으면 의견을 남겨주세요. 최선을 다해 답변해 드리겠습니다.

3. 원격 호스트 확인(B)

Magento를 전송하기 전에 새 호스트에서 작동하고 호스트 자체가 제대로 작동하는지 확인하십시오. 먼저 웹 서버가 명시된 주소에서 응답하는지 확인합니다(호스트가 이미 구성되어 있다고 가정).

내 예에서는 Linux 서버에 Apache2가 설치된 직후 사용 가능한 표준 경로를 사용합니다.

> /var/www/html

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

*여기에서 더 나아가 필요한 경우 해당 사용자로부터 명령이 실행됩니다. 명령이 사용자 이름 없이 실행되는 경우 명령 실행은 현재 사용자 및 해당 권한의 가용성을 의미해야 합니다.

이 명령을 실행한 후 오류가 나타나지 않으면 모든 것이 잘 된 것이며 `index.php` 파일은 {host}/index.php 주소에서 사용할 수 있어야 합니다. 브라우저의 결과는 다음과 같아야 합니다(많은 부분은 여전히 ​​PHP 버전에 따라 다름).

Localhost에서 서버로 Magento 2 사이트를 전송하는 방법은 무엇입니까? | MageWorx Magento 블로그

문제가 발생하여 PHP 버전에 대한 정보가 표시되지 않으면 필요한 웹 서버 구성에 대한 해당 가이드를 참조하십시오.

또한 로그를 미리 연구하는 것이 좋습니다. 이렇게 하면 많은 시간을 절약할 수 있습니다.

그런 다음 데이터베이스 서비스가 시작되고 제대로 작동하는지 확인합니다.

 mysql -u root -p

결과적으로 MySQL에 성공적으로 연결해야 합니다. 종료하려면 'exit' 명령을 사용하세요.

* MySQL을 설정할 때 사용한 로그인과 비밀번호를 입력하십시오.

또한 MySQL에 성공적으로 연결한 후 기존 데이터베이스를 확인해야 합니다.

 SHOW databases;

전송하려는 데이터베이스의 이름은 새 서버에 이미 존재하는 이름과 달라야 합니다. 유사한 데이터베이스가 있는 경우 이 문제는 예를 들어 기존의 사용되지 않는 데이터베이스를 삭제하거나 전송하려는 Magento 데이터베이스의 이름을 변경하여 수동으로 해결해야 합니다. 반드시 Magento 환경 `app/etc/env.php`의 설정 파일에 변경된 이름을 입력해야 합니다.

결과는 다음과 같아야 합니다.

Localhost에서 서버로 Magento 2 사이트를 전송하는 방법은 무엇입니까? | MageWorx Magento 블로그

또한 서비스 자체가 시작되었고 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 웹 서버를 사용하는 경우 `.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 사이트에 로컬로 배열된 여러 개의 개별 데이터베이스가 있는 경우 모든 데이터베이스를 전송해야 합니다. 내 예에서는 두 개의 데이터베이스가 사용됩니다. Magento 환경의 `app/etc/env.php` 구성에서 `db => connection => ` 섹션에서 찾을 수 있습니다.

Localhost에서 서버로 Magento 2 사이트를 전송하는 방법은 무엇입니까? | MageWorx Magento 블로그

이제 모든 데이터베이스를 덤프합니다.

 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` 테이블의 모든 이전 경로를 변경해야 합니다. 먼저 이전 주소가 포함된 '값' 쿼리를 사용하여 이러한 필드를 현지화해 보겠습니다. 이전 웹 사이트 주소가 '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)

이 시점에서 우리의 목표는 이전 주소를 새 주소로 변경하는 것입니다. 이를 위해 모든 행에서 실제로 변경되어야 하는지 확인하고(제3자 모듈의 구성과 관련된 일부 드문 경우를 제외하고는 대부분 변경됨) 다음 쿼리를 실행합니다.

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

`value` 필드의 `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'`의 데이터를 편집합니다.

* 중요! 데이터베이스가 원격 서버에 있는 경우 데이터를 변경할 필요가 없습니다. 당신이해야 할 유일한 일은 현재 서버에서 해당 원격 데이터베이스에 대한 액세스가 있는지 확인하는 것입니다. (예를 들어, 데이터베이스 서버의 방화벽 화이트리스트에 추가되었습니다).

연결이 로컬인지 여부를 이해하려면 '호스트' 필드에 'localhost' 값을 사용합니다.

다음으로 파일을 저장합니다.

8. 파일 및 디렉토리 접근 권한 정정

액세스 권한을 정확하게 설정하려면 웹 서버가 실행되는 사용자와 그룹을 알아야 합니다.

가장 자주 CentOS의 경우 `apache` 또는 Ubuntu의 경우 `www-data`입니다. 일반적으로 사용자 이름은 그룹 이름과 같습니다. 그러나 다른 서버에서는 다를 수 있습니다.

다음 명령은 그것을 알아내는 데 도움이 될 것입니다.

 ps aux | egrep '(apache|httpd)'
Localhost에서 서버로 Magento 2 사이트를 전송하는 방법은 무엇입니까? | MageWorx Magento 블로그

결과적으로 첫 번째 열에 사용자 이름이 표시됩니다(그룹 이름은 같을 가능성이 높습니다. 그러나 확실하지 않은 경우 `groups apache` 명령을 사용합니다. 여기서 `apache`는 사용자 이름입니다. 확인 해봐).

그 후 첫 번째로 Magento 내부의 모든 파일과 디렉토리를 웹 서버 사용자에게 전송해야 합니다(예제에서는 `apache`입니다. `www-data` 사용자의 경우 `apache:apache`를 ` www-data:www-data` 및 기타 유사):

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

다음으로 변경 사항이 적용되었는지 여부를 확인합니다.

 ls -la /var/www/html

모든 파일과 디렉토리(`..`로 표시된 상위 파일 제외)에는 사용자와 `apache` 그룹이 있어야 합니다(`www-data`가 시스템에서 웹 서버 사용자인 경우 소유자):

Localhost에서 서버로 Magento 2 사이트를 전송하는 방법은 무엇입니까? | MageWorx Magento 블로그

이제 Magento 파일 및 디렉토리에 대한 액세스 권한을 정확하게 설정해야 합니다. 설명서에 따르면 다음 설정을 적극 권장합니다.

*모든 명령은 루트 Magento!에서 실행되어야 하며 일관되게 1 후에 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' 명령, 예: `sudo find ...`)를 사용하세요.

9. Magento 출시 전 표준 절차

이제 명령줄에서 Magento가 실행되는지 확인할 차례입니다. 먼저 액세스 권한이 있는 명령의 표준 출력을 테스트해 보겠습니다.

*이제 권한을 설정하면 파일, 캐시 파일, 정적 등을 생성하는 동일한 웹 서버 사용자가 Magento에 액세스할 수 있습니다. 이를 무시하면 Magento 실행이 중지되고 권한을 복원해야 합니다. 다시 한 번(이 지침의 이전 단계).

**정확한 작동을 위해서는 서버에서 올바른 php 인터프리터를 찾아야 합니다. 일반적으로 ` php` 별칭은 최신 버전을 나타냅니다. 그러나 예를 들어 `/usr/bin/php72`와 같이 전체 경로를 표시해야 하는 경우가 많습니다.

***여기에서 더 나아가 모든 Magento 명령은 서버(B)의 Magento 루트 디렉토리에서 실행됩니다.

 sudo -u apache php bin/magento list

이렇게 하면 명령줄에서 사용할 수 있는 명령 목록이 만들어집니다.

Localhost에서 서버로 Magento 2 사이트를 전송하는 방법은 무엇입니까? | MageWorx Magento 블로그

모두 성공적으로 진행되면 추가 명령을 진행할 수 있습니다.

*전송 전에 캐시와 생성된 파일이 있는 디렉토리를 지우지 않은 경우 다음 명령을 사용하여 이 작업을 수행하는 것이 좋습니다.

 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`는 러시아어 로케일에 사용됩니다.

축하합니다! 새 서버에서 제대로 작동하도록 localhost에서 Magento2 저장소를 성공적으로 전송했습니다. 이제 새 주소를 입력하여 브라우저에서 엽니다!

Localhost에서 서버로 Magento 2 사이트를 전송하는 방법은 무엇입니까? | MageWorx Magento 블로그

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: invalid user: … ` 명령이 표시되면 서버에 웹 서버 사용자를 잘못 지정했을 가능성이 큽니다.

해결책:

시스템의 서버 구성에 대한 해당 가이드를 참조하거나 `ps aux` 유틸리티를 사용하여 올바른 사용자를 결정하십시오.

문제 #4

문제:

새 서버에서 Magento를 시작할 때 PHP 오류가 있는 경우(일반적으로 일부 PHP 확장이 없음을 의미함)…

해결책:

이것은 누락된 확장을 설치하여 해결할 수 있습니다.

a) Monolog의 NormalizerFormatter를 사용하려면 `PHP의 json 확장이 필요합니다` ―

*php-json* 확장자가 없습니다.

b) `PHP 치명적인 오류: 잡히지 않은 오류: 'DOMDocument' 클래스를 찾을 수 없습니다...` ―

*php-xml* 확장자가 없습니다.

c) `PHP 치명적인 오류: 'IntlDateFormatter' 클래스가 …에서 찾을 수 없습니다.` ―

*php-intl* 확장자가 없습니다.

문제 #5

문제:

`composer update` 명령을 실행할 때 PHP 확장이 누락된 경우 다음 오류가 표시됩니다.

예를 들어,

`phpunit/phpunit 6.5.14에는 ext-mbstring이 필요합니다 * -> 요청한 PHP 확장 mbstring이 시스템에 없습니다.`

해결책:

이러한 오류를 처리하려면 작곡가가 참조하는 PHP 확장을 설치하기만 하면 됩니다. 예를 들어 `yum install php-mbstring`입니다.

Magento 2 버전에 필요한 확장의 전체 목록은 공식 문서에서 찾을 수 있습니다.

결론

당신 준비 다 됐어요! 이 기사에서는 Magento 2 사이트를 로컬 호스트에서 서버로 전송하는 단계를 따르기 쉽게 제시하기 위해 최선을 다했습니다.


여전히 질문이 있거나 의견을 공유하고 싶은 경우 아래의 의견 섹션을 자유롭게 사용하십시오. 모든 질문과 고민에 최선을 다해 답변해 드리겠습니다!