AEM as a Cloud Service에 배포 deploying-to-aem-as-a-cloud-service

소개 introduction

코드 개발의 기본 사항은 AEM On Premise 및 Managed Services 솔루션과 비교할 경우 AEM as a Cloud Service의 기본 사항과 유사합니다. 개발자는 코드를 작성하고 로컬에서 테스트한 다음, AEM as a Cloud Service의 원격 환경에 푸시합니다. Managed Services용 선택적 콘텐츠 게재 도구였던 Cloud Manager가 필요합니다. 이 게재 도구는 코드를 AEM as a Cloud Service 개발, 스테이징 및 프로덕션 환경에 배포하기 위한 유일한 메커니즘입니다. 앞서 언급한 환경을 배포하기 전에 빠른 기능 검증 및 디버깅을 위해 코드를 로컬 환경에서 신속한 개발 환경으로 동기화할 수 있습니다.

AEM 버전 업데이트는 항상 사용자 정의 코드 푸시와는 별도의 배포 이벤트입니다. 또는 사용자 지정 코드 릴리스는 프로덕션에 있는 AEM 버전에 대해 테스트해야 하는데, 이는 배포된 버전이기 때문입니다. 그 이후에 발생하는 AEM 버전 업데이트(빈번하며 자동으로 적용됨)는 이미 배포된 고객 코드와 역으로 호환되도록 설계되었습니다.

이 문서의 나머지 부분에서는 개발자가 AEM as a Cloud Service의 버전 업데이트 및 고객 업데이트 모두에서 작동하도록 사례를 조정하는 방법을 설명합니다.

고객 릴리스 customer-releases

올바른 AEM 버전에 대한 코딩 coding-against-the-right-aem-version

이전 AEM 솔루션의 경우, AEM 버전이 드물게 변경되고 고객이 API Jar를 참조하여 프로덕션 인스턴스를 최신 빠른 시작으로 업데이트했습니다. 단, AEM as a Cloud Service의 애플리케이션은 최신 버전의 AEM으로 더 자주 자동으로 업데이트되므로 내부 릴리스에 대한 사용자 정의 코드는 최신 AEM 버전에 대해 빌드해야 합니다.

기존 비 클라우드 AEM 버전과 마찬가지로 특정 빠른 시작을 기반으로 하는 로컬 오프라인 개발이 지원되며 일반적으로 디버깅을 위한 기본 도구가 될 수 있습니다.

내부 릴리스용 사용자 정의 코드를 개발하려면 관련 버전의 AEM as a Cloud Service SDK를 다운로드하고 설치해야 합니다. AEM as a Cloud Service Dispatcher 도구 사용에 대한 자세한 내용은 클라우드의 Dispatcher를 참조하십시오.

다음 비디오는 AEM as a Cloud Service에 코드를 배포하는 방법에 대한 높은 수준의 개요를 제공합니다.

Cloud Manager 및 패키지 관리자를 통해 컨텐츠 패키지 배포 deploying-content-packages-via-cloud-manager-and-package-manager

Cloud Manager을 통한 배포 deployments-via-cloud-manager

고객은 Cloud Manager를 통해 클라우드 환경에 사용자 정의 코드를 배포합니다. Cloud Manager은 로컬로 어셈블된 콘텐츠 패키지를 슬링 기능 모델에 따라 아티팩트로 변환합니다. 이 모델은 클라우드 환경에서 실행할 때 AEM as a Cloud Service에서 애플리케이션을 설명합니다. 따라서 클라우드 환경의 패키지 관리자에서 패키지를 찾을 때 이름에는 “cp2fm”이 포함되며 변환된 패키지에서 모든 메타데이터가 제거됩니다. 상호 작용할 수 없다는 것은 다운로드, 복제 또는 열 수 없다는 의미입니다. 변환기에 대한 자세한 문서는 GitHub의 sling-org-apache-sling-feature-cpconverter를 참조하십시오.

AEM as a Cloud Service용 컨텐츠 패키지는 변경할 수 없는 컨텐츠와 변경할 수 있는 컨텐츠를 구분해야 합니다. Cloud Manager은 변경 가능한 콘텐츠만 설치하고 다음과 같은 메시지를 출력합니다.

Generated content-package <PACKAGE_ID> located in file <PATH> is of MIXED type

이 섹션의 나머지 부분에서는 변경 불가능한 패키지 및 변경 가능한 패키지의 컴포지션 및 의미에 대해 설명합니다.

변경할 수 없는 콘텐츠 패키지 immutabe-content-packages

변경 불가능한 저장소에서 지속되는 모든 콘텐츠는 Git에 체크인하고 Cloud Manager를 통해 배포해야 합니다. 즉, 현재 AEM 솔루션과 달리 코드는 실행 중인 AEM 인스턴스에 직접 배포하지 않습니다. 이 워크플로는 클라우드 환경의 특정 릴리스에 대해 실행 중인 코드가 동일하므로 프로덕션에서 의도하지 않게 코드 변형이 발생할 위험이 제거됩니다. 예를 들어 OSGI 구성은 런타임 시 AEM 웹 콘솔의 구성 관리자를 통해 관리하는 대신 소스 제어에 커밋해야 합니다.

스위치는 배포 패턴으로 인한 응용 프로그램 변경을 활성화하므로 서비스 사용자, 해당 ACL, 노드 유형 및 색인 정의 변경을 제외한 변경 가능한 저장소의 변경 사항에 따라 달라질 수 없습니다.

고객이 기존 코드 베이스를 보유하고 있는 경우 AEM 설명서에 설명된 저장소 재구성 연습을 살펴보면서 /etc 아래의 이전 콘텐츠가 올바른 위치로 이동했는지 확인해야 합니다.

이러한 코드 패키지에는 몇 가지 추가 제한 사항이 적용됩니다. 예를 들어 설치 후크는 지원되지 않습니다.

OSGI 구성 osgi-configuration

앞서 언급한 바와 같이 OSGI 구성은 웹 콘솔을 통해서가 아니라 소스 제어에 커밋해야 합니다. 이에 필요한 기술에는 다음이 포함됩니다.

AEM as a Cloud Service용 OSGi 구성에서 OSGI 구성에 대해 자세히 살펴봅니다.

변경 가능한 콘텐츠 mutable-content

경우에 따라 환경이 업데이트될 때마다 Cloud Manager이 배포하도록 소스 제어에서 콘텐츠 변경 사항을 준비하는 것이 유용합니다. 예를 들어 특정 루트 폴더 구조를 시드하는 것이 좋습니다. 응용 프로그램 배포가 업데이트하는 정책 구성 요소를 활성화하려면 편집 가능한 템플릿의 변경 사항을 정렬합니다.

Cloud Manager은 변경 가능한 콘텐츠 패키지 및 repoinit 문의 두 가지 전략을 사용하여 변경 가능한 저장소에 콘텐츠를 배포합니다.

변경 가능한 콘텐츠 패키지 mutable-content-packages

일반적으로 폴더 경로 계층, 서비스 사용자와 액세스 제어(ACL) 등 콘텐츠는 Maven Archetype 기반 AEM 프로젝트에 커밋합니다. 기법에는 AEM에서 내보내기 또는 직접 XML로 작성하기가 포함됩니다. 빌드 및 배포 프로세스 도중 Cloud Manager는 최종 변경 가능한 콘텐츠 패키지를 패키지화합니다. 파이프라인의 배포 단계에서 변경 가능한 콘텐츠를 세 가지 다른 시간대에 설치합니다.

새 애플리케이션 버전 시작에 앞서:

새 애플리케이션 버전 시작 도중(단, 전환에 앞서):

새 애플리케이션 버전으로 전환하고 나서:

/apps 아래의 install.author 또는 install.publish 폴더에 패키지를 임베드하여 변경 가능한 콘텐츠 설치를 작성자 또는 게시로 제한할 수 있습니다. 이러한 분리를 반영하기 위한 재구성은 AEM 6.5에서 수행되었으며 권장 프로젝트 재구성에 대한 자세한 내용은 AEM 6.5 설명서를 참조하십시오.

또한 변경 가능한 콘텐츠 패키지 변경 사항이 적용된 후 해당 변경 사항을 롤백하는 메커니즘이 없습니다. 고객이 문제를 감지하는 경우 다음 코드 릴리스에서 문제를 해결하거나 마지막 수단으로 전체 시스템을 배포하기 전 시점으로 복원하도록 선택할 수 있습니다.

포함된 모든 서드파티 패키지는 AEM as a Cloud Service 호환되는지 확인해야 합니다. 그렇지 않으면 포함되면 배포가 실패합니다.

위에서 언급했듯이 기존 코드 베이스를 사용하는 고객은 AEM 6.5 설명서에 설명된 6.5 저장소 변경 사항에 필요한 저장소 재구성 연습을 따릅니다.

Repoinit repoinit

다음과 같은 경우 OSGI 팩토리 구성에서 명시적 콘텐츠 생성 repoinit 문을 수동으로 코딩하는 것이 좋습니다.

다음과 같은 이점으로 인해 지원되는 이 콘텐츠 수정 사용 사례에 대해 Repoinit가 권장됩니다.

Cloud Manager가 애플리케이션을 배포하는 경우 콘텐츠 패키지 설치와 별도로 해당 명령문을 실행합니다.

repoinit 문을 만들려면:

repoinit에 대한 자세한 내용은 Sling 설명서에서 확인할 수 있습니다.

변경 가능한 콘텐츠 패키지를 위한 패키지 관리자 “단일” package-manager-oneoffs-for-mutable-content-packages

콘텐츠 패키지를 “일회성” 설치로 설치해야 하는 사용 사례가 있습니다. 예를 들면 프로덕션 문제를 디버깅하기 위해 프로덕션에서 스테이징으로 특정 콘텐츠를 가져오기 등이 있습니다. 해당 시나리오의 경우, 패키지 관리자를 AEM as a Cloud Service의 환경으로 사용할 수 있습니다.

패키지 관리자는 런타임 개념이므로 변경할 수 없는 저장소에 콘텐츠 또는 코드를 설치할 수 없으며 이러한 콘텐츠 패키지는 변경할 수 있는 콘텐츠(주로 /content 또는 /conf)로 구성됩니다. 콘텐츠 패키지에 혼합된 콘텐츠(변경 가능한 콘텐츠와 변경 불가능한 콘텐츠 모두)가 포함된 경우, 변경 가능한 콘텐츠만 설치합니다.

모든 컨텐츠 패키지 Cloud Manager 설치(변경 가능 및 변경 불가능)는 AEM 패키지 관리자 사용자 인터페이스에 동결된 것으로 표시됩니다. 이러한 패키지는 재설치, 다시 빌드 또는 다운로드할 수 없으며 Cloud Manager에서 설치를 수행했음을 나타내는 “cp2fm” 접미사로 나열됩니다.

서드파티 패키지 포함 including-third-party

일반적으로 고객은 Adobe의 번역 파트너와 같은 소프트웨어 공급업체 등 서드파티 소스에서 사전 설치된 패키지를 포함합니다. 원격 저장소에서 해당 패키지를 호스팅하고 pom.xml에서 참조하는 것이 좋습니다. 이 방법은 암호로 보호된 Maven 저장소의 설명에 따라 암호 보호가 설정된 공용 저장소와 개인 저장소의 경우에도 가능합니다.

패키지를 원격 저장소에 저장할 수 없는 경우, 고객은 프로젝트의 일부로 SCM에 커밋하는 로컬 파일 시스템 기반의 Maven 저장소에 배치할 수 있습니다. 무엇에 의존하든 그것을 참조합니다. 저장소는 아래 그림과 같이 프로젝트 pom에서 선언됩니다.

<repository>
    <id>project.local</id>
    <name>project</name>
    <url>file:${maven.multiModuleProjectDirectory}/repository</url>
</repository>

포함된 모든 서드파티 패키지는 이 문서에 설명된 AEM as a Cloud Service 코딩 및 패키징 지침을 준수해야 합니다. 그렇지 않으면 포함에 따라 배포가 실패합니다.

다음 Maven POM.xml 조각은 서드파티 패키지가 filevault-package-maven-plugin Maven 플러그인 구성을 사용하여 프로젝트의 “컨테이너”(일반적으로 “모두”​라고 함) 패키지에 임베드할 수 있는 방식을 보여 줍니다.

...
<plugin>
  <groupId>org.apache.jackrabbit</groupId>
  <artifactId>filevault-package-maven-plugin</artifactId>
  <extensions>true</extensions>
  <configuration>
      ...
      <embeddeds>

          ...

          <!-- Include any other extra packages  -->
          <embedded>
              <groupId>com.vendor.x</groupId>
              <artifactId>vendor.plug-in.all</artifactId>
              <type>zip</type>
              <target>/apps/vendor-packages/container/install</target>
          </embedded>
      <embeddeds>
  </configuration>
</plugin>
...

롤링 배포 작동 방법 how-rolling-deployments-work

AEM 업데이트와 마찬가지로 적절한 상황에서 작성 클러스터 중단 시간을 없애려면 롤링 배치 전략을 사용하여 고객 릴리스를 배포합니다. 일반적인 이벤트 순서는 아래에 설명되어 있습니다. 여기서 고객 코드의 이전 버전 및 새 버전의 노드는 동일한 버전의 AEM 코드를 실행 중입니다.

색인 indexes

신규 또는 수정된 색인으로 인해 새 버전이 트래픽을 처리하기 전에 인덱싱 단계 또는 리인덱싱 단계가 추가될 수 있습니다. AEM as a Cloud Service의 인덱스 관리에 대한 자세한 내용은 콘텐츠 검색 및 색인화에서 확인할 수 있습니다. Cloud Manager 빌드 페이지에서 인덱싱 상태를 확인할 수 있으며, 새 버전이 트래픽을 가져올 수 있게 되면 알림을 받게 됩니다.

현재 AEM as a Cloud Service는 ACS Commons Ensure Oak 인덱스 도구 등의 색인 관리 도구와 구동하지 않습니다.

복제 replication

게시 메커니즘은 AEM 복제 Java™ API와 역으로 호환됩니다.

Cloud ready AEM 빠른 시작을 사용하여 복제를 개발하고 테스트하려면 작성자/게시 설정과 함께 클래식 복제 기능을 사용하십시오. 클라우드에 대한 AEM 작성자의 사용자 인터페이스 진입점이 제거된 경우, 사용자는 구성을 위해 http://localhost:4502/etc/replication으로 이동합니다.

이전 버전과 호환되는 롤링 배포 코드 backwards-compatible-code-for-rolling-deployments

위에서 자세히 설명했듯이 AEM as a Cloud Service의 롤링 배포 전략은 이전 버전과 새 버전이 모두 동시에 작동함을 의미합니다. 따라서 코드 변경 내용이 아직 작동 중인 이전 AEM 버전과 역으로 호환되지 않으므로 주의하십시오.

또한 변형 가능한 콘텐츠가 제거되어 롤백이 있는 경우, 새 릴리스에서 변경 가능한 새 콘텐츠 구조를 적용하면서 이전 릴리스의 호환성을 테스트해야 합니다.

서비스 사용자 및 ACL 변경 사항 service-users-and-acl-changes

콘텐츠 또는 코드에 액세스하는 서비스 사용자 또는 ACL을 변경하면 이전 AEM 버전에서 오류가 발생하여 오래된 서비스 사용자가 해당 콘텐츠 또는 코드에 액세스할 수 있습니다. 이 비헤이비어를 해결하려면 후속 릴리스에서 정리하기 전에 링크 역할을 하는 첫 번째 릴리스로 변경 사항이 최소 두 개의 릴리스에 분산되어야 합니다.

색인 변경 index-changes

색인을 변경한 경우 이전 버전은 종료될 때까지 해당 색인을 계속 사용하는 반면 새 버전은 수정된 자체 색인 세트를 사용하는 것이 중요합니다. 개발자는 콘텐츠 검색 및 색인화에 설명된 색인 관리 기법을 따릅니다.

롤백에 대한 보존적 코딩 conservative-coding-for-rollbacks

배포 후 오류를 보고하거나 감지하는 경우, 이전 버전으로 롤백해야 합니다. 새 구조(변경 가능한 콘텐츠)는 롤백되지 않으므로 새 코드가 새 버전에서 생성된 새 구조와 호환되는지 확인하도록 합니다. 이전 코드가 호환되지 않는 경우, 후속 고객 릴리스에 수정 사항이 적용되어야 합니다.

신속한 개발 환경 (RDE) rde

신속한 개발 환경(또는 RDE)을 통해 개발자는 변경 사항을 신속하게 배포하고 검토할 수 있습니다. 이를 통해 이미 로컬 개발 환경에서 작동하는 것으로 입증된 기능을 테스트하는 데 필요한 시간을 최소화할 수 있습니다.

Cloud Manager 파이프라인을 사용하여 코드를 배포하는 일반 개발 환경과 달리 개발자는 명령줄 도구를 사용하여 로컬 개발 환경에서 RDE로 코드를 동기화합니다. 변경 사항이 RDE에서 성공적으로 테스트된 후에 Cloud Manager 파이프라인을 통해 일반 클라우드 개발 환경에 이를 배포합니다. 이때 파이프라인에서 코드가 적절한 품질 게이트를 통과합니다.

실행 모드 runmodes

기존 AEM 솔루션에서는 고객이 임의 실행 모드로 인스턴스를 실행하고 OSGI 구성을 적용하거나 해당 특정 인스턴스에 OSGI 번들을 설치할 수 있습니다. 일반적으로 정의된 실행 모드에는 서비스(작성자 및 게시) 및 환경(RDE, 개발, 스테이지, 프로덕션)이 포함됩니다.

반면에 AEM as a Cloud Service는 사용 가능한 실행 모드와 OSGI 번들 및 OSGI 구성을 매핑할 수 있는 방법에 있어 보다 독창적입니다.

AEM as a Cloud Service에서는 실행 모드를 사용하여 특정 환경 또는 서비스에 대한 콘텐츠를 설치할 수 없습니다. 스테이징 또는 프로덕션 환경에 없는 데이터 또는 HTML로 개발 환경을 시드해야 하는 경우, 패키지 관리자를 사용할 수 있습니다.

지원되는 실행 모드 구성은 다음과 같습니다.

가장 일치하는 실행 모드가 있는 OSGI 구성을 사용합니다.

로컬에서 개발할 때 실행 모드 시작 매개변수 -r를 사용하여 실행 모드 OSGI 구성을 지정합니다.

$ java -jar aem-sdk-quickstart-xxxx.x.xxx.xxxx-xxxx.jar -r publish,dev

소스 제어에서 유지 관리 작업 구성 maintenance-tasks-configuration-in-source-control

도구 > 작업 화면은 클라우드 환경에서 사용할 수 없으므로 소스 제어에서 유지 관리 작업 구성을 지속해야 합니다. 변경 사항이 반응적으로 적용되고 잊혀지기 보다는 의도적으로 지속될 수 있다는 이점이 있습니다. 자세한 내용은 AEM as a Cloud Service의 유지 관리 작업을 참조하십시오.