참고: 이것은 에지 전송 서비스 & 문서 작성에 대한 다소 고급 주제입니다. EDS & 문서 작성에 대한 소개를 보려면 먼저 이 내용을 확인하시기 바랍니다.

파일 기반 AEM Edge Delivery 구성의 배경 & 구성 서비스

Adobe가 처음 Edge Delivery Services(또는 내부적으로 알려진 Helix)를 출시했을 때 사이트 전체의 모든 주요 구성은 사이트 저장소에 체크인된 구성 파일을 사용하여 수행되었습니다. 새 구성을 배포하려면 main 리포지토리의 브랜치로 푸시하여 해당 구성을 사이트에 실시간으로 푸시했습니다. 이 방법의 단점은 특정 리포지토리를 사이트와 문서 리포지토리에 직접 연결해야 한다는 점입니다. 그러면 단일 코드 리포지토리로 여러 사이트 또는 단일 사이트의 여러 버전(콘텐츠 또는 구성 스테이징을 위한 dev/stg/prd 스타일 환경)을 구동할 수 없습니다.

이러한 문제와 기타 기술적인 문제로 인해 Adobe는 구성 서비스를 기반으로 하는 새로운 아키텍처 디자인으로 전환했습니다. 이 패러다임에서는 구성이 Adobe의 API 기반 구성 서비스에서 중앙 집중식으로 저장되고 버전이 관리되며, 이 서비스로 마이그레이션되면 Edge 전달 프로젝트의 파일은 더 이상 사이트에 영향을 미치지 않습니다.

구성 서비스로 이동하기 위한 전제 조건

https://www.aem.live/docs/config-service-setup#prerequisites 에서 설명한 대로 구성 서비스로 이동을 시작하기 전에 먼저 Adobe 사용자가 Github 조직의 관리자로 매핑되어 있는지 확인하여 구성 서비스에서 변경할 수 있는 권한이 있는지 확인해야 합니다. 일반적으로 거래하는 Adobe 기술 담당자가 이에 대해 안내해 드릴 수 있습니다.

엔드포인트 & 구성 서비스로의 이동으로 영향을 받는 구성 표면

이는 에지 전송 프로젝트의 다음 구성 표면에 영향을 줍니다:

• 콘텐츠 버스 매핑: 프로젝트가 DA(또는 AEM/Universal Editor 또는 Sharepoint와 같은 다른 위치)에 매핑되는 /fstab.yaml 의 구성이 이제 Config Service에 있습니다. 이것은 하나의 리포지토리로 여러 사이트를 구동할 수 있는 가장 중요한 부분입니다(이전에는 코드 리포지토리와 콘텐츠 리포지토리가 불가분의 관계에 있지 않다는 의미로 "리폴리스" 설정으로 알려졌음).

• 쿼리 인덱스: 모든 언어에 대한 인덱스 구성은 이전에 프로젝트에 다음과 같이 저장되어 있었습니다. /helix-query.yaml

• 사이트맵 구성: 이전에 /helix-sitemap.yaml 에서 만들었던 사이트맵 구성이 이제 구성 서비스에서 이루어집니다.

• 사이드킥 구성: 이전에는 git 프로젝트에 보관되어 있던 두 가지 유형의 사이드킥 설정이 이제 다른 곳에 있습니다.

  • DA 플러그인: 이전에는 DA 초기에 코드 리포지토리의 /tools/sidekick/config.json 파일에 DA 플러그인을 보관했습니다. 이는 날짜 선택기, AEM 태그 플러그인 등과 같은 다양한 DA UI 개선 사항과 같은 것들을 위한 것입니다. 이제 이 정보는 코드베이스가 아닌 DA 자체의 DA 구성에 있는 Library 시트에 보관됩니다.
  • 사이드킥 플러그인/구성: 빠른 편집 또는 AEM 실험을 위한 구성과 같은 기타 AEM Sidekick 구성은 이제 DA가 아닌 구성 서비스에서 바로 유지됩니다. EDS git 프로젝트의 Sidekick 구성은 더 이상 적용되지 않습니다.

• HTTP 헤더 구성: 이전에는 DA의 headers 시트에 보관되었지만 이제 구성 서비스로 푸시됩니다. 이는 특정 호스트에 access-control-allow-origin 헤더를 붙이는 것과 같은 CORS 구성을 위한 것입니다.

• Helix 미리 보기/게시 인증: 인증된 미리 보기/게시 액세스 제어를 위해 https://da.live/sheet#/[orgname]/[sitename]/.helix/config 에 data 시트가 있고, 여기에 사용자/프로필에 매핑되는 개별 Adobe 엔티티 ID에 대한 admin.role.author 또는 admin.role.publish 역할이 나열되는 시트 기반 인증 모델을 사용하고 있습니다. 이 기능은 이제 구성 서비스에서 폐기되었으며, 사용자는 이러한 미리 보기/게시 역할뿐만 아니라 액세스 요청에 대해서도 구성 서비스에서 직접 관리됩니다. 또한 이전에는 인증된 게시를 하려면 특정 조직의 사용자 로그인에 매핑되는 "[email protected]" 같은 읽을 수 없는 Adobe 프로필/사용자 ID를 사용해야 했습니다. 이제 구성 서비스에서 Helix는 알 수 없는 엔티티 ID 대신 이메일 주소를 사용할 수 있도록 하고, 사용자가 미리 보기/게시 문제가 발생할 때 "액세스 요청(" )을 하면 DA의 관리자 인터페이스 앱으로 표시되어 액세스 요청을 승인/거부할 수 있도록 합니다.

• Robots.txt 구성: 이전에는 git 프로젝트의 /robots.txt 에 보관되었지만 이제는 Config Service에 구성됩니다.

• CDN 구성: 이전에는 DA의 .helix/config 시트에 보관되었지만 이제 Config Service로 푸시됩니다. 다음과 같은 값을 설정하는 데 사용됩니다:

  • cdn.prod.host
  • cdn.prod.type
  • cdn.prod.serviceId
  • cdn.prod.authToken

기존 파일 기반 엣지 전송 사이트를 구성 서비스로 이전하는 단계

파일 기반 Edge Delivery 설정을 구성 서비스로 자동 마이그레이션할 수 있는 migrate 명령이 AEM Admin(Helix) API에 있습니다. 하지만 몇 가지 주의 사항이 있으므로 이에 대해 알아두어야 할 사항이 있습니다.

먼저 파일 기반 구성을 사용하여 DA에서 생성된 기존 사이트가 있다고 가정해 보겠습니다(이러한 사이트가 몇 개 있는 것으로 알고 있습니다. 소수일 수도 있지만 이 블로그 게시물은 자신의 사용 사례에 맞게 단계를 다시 평가하고 싶을 것입니다).

단계:

1. 조직의 관리자 권한이 있는지 확인합니다: 위에서 언급했듯이 Adobe와 협력하여 Github 조직에 admin 주소가 있는지 확인합니다. https://tools.aem.live/tools/site-admin/index.html 으로 이동하여 이를 확인한 다음 로그인합니다. 올바르게 작동하면 다음에 대한 200 요청이 성공적으로 표시되어야 합니다. https://admin.hlx.page/config/[orgname]/sites.json

2. 인증 토큰을 받습니다: shift+ctrl+I 또는 shift+cmd+I를 눌러 개발자 도구를 팝업하고 위에서 언급한 sites.json 요청을 확인합니다. 네트워크 탭을 열고 헤더를 보면 x-auth-token 값이 표시됩니다. 이 값을 복사하면 다음 API 요청에 사용할 무기명 토큰이 AEM 구성 서비스와 상호 작용하는 데 사용해야 하므로 이 값을 복사합니다.

3. 사이트 사본을 만듭니다: 프로덕션 환경에서 실행하기 전에 이 프로세스를 테스트할 수 있도록 사이트(파일 기반 구성이 있는 사이트)에서 테스트 실행을 수행하는 것이 좋습니다. 새 EDS 리포지토리 & 사이트를 만들고 현재 사이트와 동일한 코드베이스로 채웁니다(아직 개발 리포지토리가 없는 경우). 또한 개발 콘텐츠 소스를 채우는 것이 가장 이상적이며, 이를 통해 완벽하게 무장하고 운영할 수 있는 샌드박스를 확보할 수 있습니다.

4. 마이그레이션 명령 드라이-런을 실행합니다: 다음 명령을 실행하면 파일 기반에서 구성 서비스로의 마이그레이션이 드라이 실행됩니다:
   
   curl --request GET --url 'https://admin.hlx.page/config/{my-org}/sites/{my-site}.json?migrate=true&validate=true' -H "Authorization: token $MY_AUTH_TOKEN_NOTED_ABOVE"
   
   작동하면 다음과 같은 유효성 검사 텍스트가 출력되어 마이그레이션이 작동하는지 여부를 알려줍니다. 제 경우에는 마이그레이션할 준비가 되지 않았고 수정해야 할 사항이 있다는 뜻입니다:
   
   "error": "validation failed.", "message": "/sidekick/plugins/0/environments/0 must be equal to one of the allowed values; /sidekick/plugins/2/environments/0 must be equal to one of the allowed values",
   
   또한 호출에서 400 불량 요청이 발생하면 HTTP 응답에 x-error 헤더를 사용하여 마이그레이션 드라이런 요청의 문제를 알려줄 수도 있습니다:

   

   이 경우 이 오류는 AEM Sidekick 플러그인 목록에서 /tools/sidekick/config.json 의 첫 번째 플러그인이 유효하지 않다는 것을 알려주는데, 이는 이러한 방식으로 플러그인을 구성하는 것이 Config Service에서 더 이상 지원되지 않기 때문입니다. 이 예제에서는 이 플러그인을 DA 플러그인용 DA 라이브러리 시트로 마이그레이션해야 합니다.

   

5. 위에서 언급한 대로 유효성 검사 문제를 수정합니다: 발생하는 모든 문제를 검토하여 수정한 다음 유효성 검사 요청을 다시 실행해야 합니다.
   
   프로젝트에서 사이드킥 플러그인으로 정의된 기존 플러그인을 가져와서 DA에 넣습니다. 이와 같은 사이드킥 플러그인 문제의 경우 DA 플러그인은 시트의 "라이브러리" 탭의 https://da.live/config#/[orgname]/[sitename]/ 에서 대신 구성됩니다.

   

   또는 이와 같은 다른 문제도 있습니다:

   

   이는 헤더에 더 이상 지원되지 않는 불법 속성이 있었음을 나타냅니다(또는 지원되지 않는데도 아무 것도 깨뜨리지 않아서 실수로 남겨둔 것일 수도 있습니다).
   
   이러한 문제가 처리되면 마이그레이션을 실행할 준비가 된 것입니다.

6. 깨끗한 & 유효성이 검사된 구성을 구성 서비스로 푸시/마이그레이션합니다: 구성을 푸시하려면 다음 명령을 사용합니다:
   
   curl --request POST --url 'https://admin.hlx.page/config/{my-org}/sites/{my-site}.json?migrate=true' -H "Authorization: token $MY_AUTH_TOKEN_NOTED_ABOVE"
   
   기본적으로 위와 동일한 명령이지만 GET 대신 POST 를 사용합니다. 그러면 구성 서비스로 마이그레이션됩니다.

7. 유효성 검사: 마이그레이션 후 즉시 확인해야 할 몇 가지 사항이 있습니다.

   1. 인덱스 유효성 검사: https://tools.aem.live/tools/index-admin/index.html 로 이동하여 인덱스가 제대로 가져왔는지 확인합니다.
   2. 사이트맵 유효성 검사: https://tools.aem.live/tools/sitemap-admin/index.html 으로 이동하여 모든 사이트맵이 제대로 전달되었는지 확인합니다.
   3. 사용자를 확인합니다: https://tools.aem.live/tools/user-admin/index.html?org={orgname}&site={sitename} 으로 이동하여 미리보기/게시 사용자가 표시되는지 확인합니다.
   4. DA에서 사용자 확인: https://da.live/apps/aem-permissions#/{orgname}/{sitename} 으로 이동하면 DA에 노출되는 미리보기/게시 권한의 사용자 친화적인 목록을 볼 수 있습니다. 또한 이제 다음을 수행할 수 있습니다.
   5. 미리 보기/게시 유효성을 확인합니다: 미리보기/게시 권한이 있는 사용자로 로그인한 경우 미리보기/게시 기능이 제대로 작동하는지 확인합니다. 미리 보기 또는 게시 액세스 권한이 없는 사용자를 확보하고 적절하게 잠궜는지 확인합니다.
   6. 사이트에 필요하다고 생각되는 기타 기타 유효성 검사.

8. 번인: QA & 번인: 팀과 함께 번인하고, 발생하는 다른 미리보기/게시 문제를 수정하고, 새 구성을 최소 일주일 동안 번인하여 발생할 수 있는 다른 문제를 해결합니다.

9. 구성 파일을 정리합니다: 번인이 완료되면 더 이상 저장소 내 구성이 필요하지 않게 되며, 하나씩 삭제할 수 있습니다. 누군가 어떤 이유로든 취소할 수 없는 잘못된 API 요청을 할 경우를 대비하여 버전 관리를 위해 현재 구성의 깨끗한 복사본을 git에 보관해 두는 것이 좋습니다.

구성 서비스의 CI/CD 의미에 대한 참고 사항

CI/CD에 대한 참고 사항: 이제 API 기반 구성 서비스의 고유한 유연성을 갖게 되었으므로 이제 더 이상 git 기반 CI/CD가 효과가 없다는 단점도 있습니다.

다행히도 구성 변경 사항과 누가 어떤 변경을 했는지 추적할 수 있는 버전 관리자와 같은 도구가 있습니다:

나쁜 소식은 이렇게 하면 Edge Delivery에서 우리 모두가 알고 있고 절대적으로 좋아하는 기본 제공 풀-리퀘스트 중심의 CI/CD 프레임워크가 사라진다는 것입니다. 따라서 주니어 엔지니어가 변경 사항을 제안해야 하는 상황이 발생하면 구성 변경이 롤포워드해도 안전하다는 것을 입증하는 풀 리퀘스트를 제공하기가 훨씬 더 까다로워집니다.

API에 대한 권한 부여가 현재 로그인한 사용자를 기준으로 이루어지기 때문에 영구 키 집합을 CI/CD 파이프라인에 통합하려는 시도가 약간 까다로워집니다. 약간의 손질이 필요할 뿐, 할 수 있다고 확신합니다.

따라서 (이 글을 쓰는 시점에서) 조직의 규모와 구성에 맞게 편안하게 사용할 수 있는 자체 CI/CD 프로세스를 구축해야 합니다.

도움이 되셨기를 바라며, 문제가 있으시면 언제든지 문의해 주세요!

저자 소개

들으신 내용이 마음에 드시나요? 어떤 것이 적합한지 궁금한 점이 있으신가요? 상담하고 싶어요! 문의하기

더 읽어볼 만한 기사