스토어프런트 시작

이 가이드에서는 새로운 PWA Kit 스토어프런트를 시작하고 공식 퍼블릭 웹 주소에서 액세스할 수 있도록 하는 방법을 설명합니다. 두 가지 옵션을 사용하여 트래픽을 시작하고 PWA Kit 스토어프런트로 라우팅할 수 있습니다.

  1. CloudFlare나 Akamai 같은 타사 CDN을 사용합니다.
  2. Managed Runtime에서 제공하는 CDN을 사용합니다.

이 가이드에서는 다음과 같은 속성의 예제 스토어프런트를 사용합니다.

  • 프로덕션 URL: https://www.example.com
  • 프로젝트 ID: example
  • 환경: staging 및 production

이 가이드에 “Mobify”라는 단어가 몇 번 등장합니다. Mobify는 PWA Kit 및 Managed Runtime의 원천 기술을 개발한 회사의 이름입니다. 2020년에 Salesforce는 Mobify의 모든 기술과 함께 Mobify를 인수했습니다.

Mobify에서 Salesforce로의 브랜드 변경이 여전히 진행 중입니다. Mobify 브랜드 이름은 여전히 스토어프런트 호스팅에 사용되는 mobify-storefront.com 도메인과 Managed Runtime API에서 사용되는 cloud.mobify.com 도메인에 나타납니다. 새로운 Salesforce 도메인이 이러한 Mobify 도메인을 대신하게 되지만 Mobify 도메인도 계속 지원합니다.

Managed Runtime은 PWA Kit 스토어프런트의 전면에 타사 CDN을 사용하도록 지원합니다. 먼저 기본 설정으로 환경을 배포합니다. 다음으로, {{project}}-{{environment}}.mobify-storefront.com 스토어프런트를 타사 CDN의 오리진으로 추가합니다. CDN이 요청 방법, 경로(쿼리 문자열 포함), 헤더 및 본문을 전달하도록 구성되어 있는지 확인합니다. 또한 CDN이 HTTP 캐싱 헤더를 따르도록 설정되어 있는지 확인합니다.

HTTP 요청을 반영하는 핸들러를 추가하여 CDN이 올바르게 구성되었는지 확인할 수 있습니다.

또한 httpbin.org/anything을 사용하여 프록시를 추가함으로써 프록시로 전달되는 헤더가 올바르게 전송되었는지 확인할 수도 있습니다.

준비, 스테이징 환경 시작 및 프로덕션 환경 시작의 세 단계로 "라이브"하는 방법에 대해 다룹니다.

이 가이드에서는 Runtime Admin 웹 애플리케이션과 Managed Runtime API에 액세스하여 관리 작업을 수행할 수 있다고 가정합니다. 이러한 도구에 액세스하려면 Commerce Cloud 관리자에게 연락하여 Account Manager에서 Managed Runtime User 또는 Managed Runtime Admin 역할 중 하나를 계정에 추가하도록 요청하십시오.

Managed Runtime API에 요청을 하려면 HTTP 요청 Authorization 헤더에 값이 Bearer {{api_key}}인 API 키를 포함해야 합니다. 제공된 모든 샘플 요청에서 {{api_key}}를 실제 API 키로 바꾸어야 한다는 것을 잊지 마십시오.

API 키를 찾으려면 Runtime Admin에 로그인하여 Account Settings(계정 설정) 페이지로 이동하십시오.

중요: 스크립트가 사용자 대신 작업을 수행할 수 있도록 하므로 API 키를 암호처럼 취급하십시오.

언제든지 이러한 단계를 완료할 수 있지만 PWA Kit를 사용하기 시작할 때 이 단계를 시작하는 것이 좋습니다.

Managed Runtime API 또는 Runtime Admin 웹 애플리케이션을 사용하여 staging이라는 환경(타겟이라고도 함)을 만들어 스토어프런트 시작 방법을 연습합니다.

다음은 Managed Runtime API의 target 엔드포인트를 사용하여 환경을 만드는 샘플 요청입니다. 요청의 example을 실제 프로젝트 ID 문자열로 바꾸고 {{api_key}}를 실제 API 키로 바꿉니다.

Runtime Admin을 사용하여 환경을 만드는 방법에 대한 지침은 Managed Runtime 관리 가이드를 참조하십시오.

스토어프런트 코드가 B2C Commerce 인스턴스에 액세스할 수 있어야 하므로 API가 공개적으로 제공되어야 합니다.

www.example.com이 현재 B2C Commerce 인스턴스로 확인된다고 가정합니다. 시작 후에는 www.example.com이 mobify-storefront.com 도메인으로 확인됩니다. 스토어프런트 코드에는 B2C Commerce 인스턴스와 연결된 API를 확인할 방법이 필요합니다. api.example.com에서 API를 사용할 수 있도록 설정하고, API를 사용하도록 환경의 프록시 설정을 업데이트할 수 있습니다. 자세한 내용은 요청 프록싱에 대한 가이드를 참조하십시오.

Salesforce가 도메인용 TLS 인증서를 발급하도록 허용하려면 CNAME 레코드를 생성해야 합니다. Salesforce 고객 지원에 연락하여 스토어프런트에 대한 CNAME 레코드를 만드는 데 필요한 세부 정보를 제공해 줄 것을 요청합니다.

세부 정보를 받은 후 24시간 내에 CNAME 레코드를 생성합니다. CNAME 레코드는 다음과 같습니다.

항상 먼저 스테이징 환경에서 시작 프로세스를 테스트합니다.

staging.example.com에서 스토어프런트를 시작하는 중이며, Managed Runtime의 프로젝트 ID가 example이고 번들이 staging라는 환경에 배포된다고 가정해보겠습니다.

staging.example.com의 TTL을 1분으로 단축합니다. TTL을 단축하면 DNS 컷오버 프로세스가 빨라지고, 문제가 발생할 경우 신속하게 롤백할 수 있습니다.

TTL은 dig 명령을 사용하여 확인할 수 있습니다.

호스트 staging.example.com에서 트래픽을 수신하도록 환경을 구성합니다.

Managed Runtime API를 사용하여 환경의 ssr_external_domain 설정과 ssr_external_hostname 설정을 업데이트합니다.

중요: 이 단계가 완료된 후에는 해당 mobify-storefront.com 도메인에서 환경에 더 이상 액세스할 수 없습니다.

DNS 스푸핑을 통해 요청을 하는 cURL 명령을 사용하여 새 설정이 적용되는지 확인합니다.

Salesforce 지원 부서에서는 명명 규칙 {{project}}-{{environment}}-cdn.mobify-storefront.com에 따라 안정적인 도메인을 제공합니다. 여기서 {{project}}는 프로젝트 ID이고 {{environment}}는 환경 ID입니다.

staging.example.com의 DNS CNAME 레코드를 example-staging-cdn.mobify-storefront.com으로 업데이트합니다. 웹 브라우저를 열고 staging.example.com으로 이동합니다.

축하합니다. 테스트 출시를 완료했습니다! 🥳

시작할 준비가 되면 production 환경과 도메인을 사용하여 테스트 시작과 동일한 단계를 수행하십시오.

여기서부터는 Customer Success 그룹이 사이트 트래픽을 모니터링하여 성공적으로 시작되었는지 확인합니다. 여기서 목표는 시작하는 동안 모든 것이 예상대로 작동되도록 하는 것입니다.

시작 후 Signature Success Plan을 보유한 고객은 사전 예방적인 사이트 모니터링을 받게 됩니다. 이렇게 개선된 모니터링 서비스를 이용하려면 환경을 프로덕션 환경으로 표시해야 합니다. 자세한 내용은 Managed Runtime 개요에서 환경에 대한 섹션을 참조하십시오.

  • ssr_external_domain 타겟 설정은 타겟이 트래픽을 수신하는 호스트를 제어합니다. 요청의 HTTP Host 헤더가 이 값과 일치하지 않으면 요청이 실패합니다.
  • 현재 Salesforce는 example.com(www 하위 도메인이 없음)과 같이 베어 도메인을 사용하는 스토어프런트 URL을 지원하지 않습니다. 베어 도메인을 사용하려면 요청을 베어 도메인에서 CNAME로 리디렉션하도록 서버를 설정해야 합니다.

사용되는 도메인에 따라 사이트의 동작을 변경하는 조건부 로직을 추가해야 할 경우, 로컬 개발 서버에서 맞춤형 도메인을 사용할 수 있을 때 이 로직을 테스트하는 편이 더 쉽습니다. 이 같은 로직은 왜 추가해야 하는 것일까요? 도메인에 따라 서로 다른 SLAS 클라이언트 ID를 조회해야 할 경우를 예로 들 수 있습니다.

맞춤형 도메인을 사용하여 로컬 개발 서버를 실행하려면:

  1. 맞춤형 도메인을 127.0.0.1(로컬 호스트)로 확인하도록 로컬 컴퓨터의 DNS를 수정합니다.
  2. ssr.js를 편집합니다.
  3. runtime.createHandler로 전달되는 options에서 포트를 80으로 설정합니다.
  4. EXTERNAL_DOMAIN_NAME=www.example.com npm start를 실행하여 example.com의 값을 맞춤형 도메인으로 바꿉니다. 포트 80에서 서버를 실행하려면 관리 권한이 필요할 수 있습니다.

이제 브라우저에서 맞춤형 도메인으로 전달되는 요청이 확인되고 로컬 개발 서버로 라우팅됩니다.

그럼 재미있게 디버깅하세요!