Adobe Cloud Manager를 사용하면 AEM as a Cloud Service에 대한 코드 작성 및 배포를 용이하게 할 수 있습니다. 빌드 프로세스의 단계 중에 오류가 발생할 수 있으므로 이를 해결하기 위한 작업이 필요합니다. 이 안내서에서는 배포의 일반적인 오류를 이해하고 이를 가장 잘 활용하는 방법을 안내합니다.
유효성 검사 단계에서는 기본 Cloud Manager 구성이 유효한지 간단히 확인할 수 있습니다. 일반적인 유효성 검사 오류는 다음과 같습니다.
빌드 및 단위 테스트 단계에서는 Maven 빌드(mvn clean package
)를 사용하십시오.
이 단계에서 식별된 오류는 다음 예외를 제외하고 로컬에서 프로젝트를 다시 생성할 수 있어야 합니다.
pom.xml
. Maven 리포지토리를 포함하면 빌드 시간이 늘어나기 때문에 해당 리포지토리를 포함할 수 없습니다..sleep(..)
를 입력합니다.코드 스캔에서는 Java와 AEM 관련 우수 사례를 혼합하여 정적 코드 분석을 수행합니다.
코드 스캔은 코드에 위험 보안 취약점이 있는 경우 빌드 오류를 발생합니다. 작은 위반은 재정의할 수 있지만, 이를 수정하는 것이 좋습니다. 코드 스캔은 불완전하며 결과를 초래할 수 있습니다 긍정 오류.
코드 스캔 문제를 해결하려면 다운로드 세부 정보 단추를 누르고 항목을 검토합니다.
자세한 내용은 AEM 특정 규칙 을 참조하십시오. Cloud Manager 설명서 사용자 지정 AEM 특정 코드 스캔 규칙.
빌드 이미지는 빌드 및 단위 테스트 단계에서 만든 빌드 코드 아티팩트를 AEM 릴리스와 결합하여 단일 배포 가능한 아티팩트를 형성해야 합니다.
빌드 및 단위 테스트 중에 코드 작성 및 컴파일 문제가 발견되지만 사용자 지정 빌드 아티팩트를 AEM 릴리스와 결합하려고 할 때 식별되는 구성 또는 구조적 문제가 있을 수 있습니다.
여러 OSGi 구성이 target AEM 환경에 대한 런타임 모드를 통해 확인되면 이미지 작성 단계가 오류로 인해 실패합니다.
[ERROR] Unable to convert content-package [/tmp/packages/enduser.all-1.0-SNAPSHOT.zip]:
Configuration 'com.example.ExampleComponent' already defined in Feature Model 'com.example.groupId:example.all:slingosgifeature:xxxxx:X.X',
set the 'mergeConfigurations' flag to 'true' if you want to merge multiple configurations with same PID
filevault-package-maven-plugin
구성 설정 <cloudManagerTarget>none</cloudManagerTarget>
.보고서 스크립트는 기본 컨텐츠, 사용자, ACL 등을 정의합니다. AEM as a Cloud Service에서는 포인트 스크립트가 이미지 작성 중에 적용되지만 AEM SDK의 로컬 빠른 시작에서는 OSGi 보고서 팩토리 구성이 활성화될 때 적용됩니다. 이로 인해 Repointet 스크립트는 AEM SDK의 로컬 빠른 시작에서 조용히 실패할 수 있지만 Build Image 단계가 실패하여 배포를 중단합니다.
보고서 스크립트는 기본 컨텐츠, 사용자, ACL 등을 정의합니다. AEM SDK의 로컬 빠른 시작에서 포인트 스크립트는 Repointeit OSGi 공장 구성이 활성화될 때 또는 다시 말해 저장소가 활성 상태가 되고 콘텐츠 패키지를 통해 직접 또는 콘텐츠 패키지를 통해 콘텐츠 변경이 발생할 수 있는 경우에 적용됩니다. AEM as a Cloud Service에서 포인트 스크립트는 이미지 작성 중에 포인터 스크립트가 종속되는 컨텐츠를 포함하지 않을 수 있는 저장소에 적용됩니다.
이 문제는 최신 AEM 릴리스로 자동 업데이트하지 않는 비프로덕션 환경에만 영향을 줍니다.
AEM as a Cloud Service은 모든 AEM 릴리스에 최신 핵심 구성 요소 버전을 자동으로 포함합니다. 즉, AEM as a Cloud Service 환경이 자동 또는 수동으로 업데이트되면에 최신 버전의 핵심 구성 요소가 배포됩니다.
다음 경우에 이미지 작성 단계가 실패할 수 있습니다.
core
(OSGi 번들) 프로젝트이 실패를 방지하기 위해 AEM as a Cloud Service 환경의 업데이트를 사용할 수 있을 때마다 다음 빌드/배포의 일부로 업데이트를 포함시키고, 애플리케이션 코드 베이스에서 코어 구성 요소 버전을 증분 후에 항상 업데이트가 포함되도록 하십시오.
증상:
다음 오류 보고와 함께 이미지 작성 단계가 실패합니다.
com.adobe.cq.wcm.core.components...
특정 버전 범위의 패키지를 가져올 수 없습니다 core
프로젝트.
[ERROR] Bundle com.example.core:0.0.3-SNAPSHOT is importing package(s) Package com.adobe.cq.wcm.core.components.models;version=[12.13,13) in start level 20 but no bundle is exporting these for that start level in the required version range.
[ERROR] Analyser detected errors on feature 'com.adobe.granite:aem-ethos-app-image:slingosgifeature:aem-runtime-application-publish-dev:1.0.0-SNAPSHOT'. See log output for error messages.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
원인: 응용 프로그램의 OSGi 번들( core
프로젝트)는 AEM as a Cloud Service에 배포되는 것과 다른 버전 수준에서 코어 구성 요소 핵심 종속성에서 Java 클래스를 가져옵니다.
해결:
위의 문제 해결 방법으로 문제가 해결되지 않으면 다음을 통해 Adobe 지원 사례를 만드십시오.
Adobe Admin Console > 지원 탭 > 사례 만들기
여러 Adobe 조직의 멤버인 경우 케이스를 만들기 전에 Adobe 조직 전환기에서 실패한 파이프라인이 있는 Adobe 조직이 선택되었는지 확인하십시오.
배포 대상 단계는 이미지 작성에서 생성된 코드 아티팩트를 가져와서 이를 사용하여 새 AEM 작성자 및 게시 서비스를 시작하고, 성공하면 이전 AEM 작성자 및 게시 서비스를 제거합니다. 가변 컨텐츠 패키지 및 인덱스가 이 단계에서도 설치 및 업데이트됩니다.
숙지하십시오 AEM as a Cloud Service 로그 배포 대상 단계를 디버깅하기 전에 다음 aemerror
로그에는 문제에 대한 배포와 관련이 있을 수 있는 pod의 시작 및 종료에 대한 정보가 포함되어 있습니다. Cloud Manager의 배포 대상 단계에서 다운로드 로그 버튼을 통해 사용할 수 있는 로그는 그렇지 않습니다 aemerror
응용 프로그램 시작과 관련된 자세한 정보는 로그 및 포함하지 않습니다.
배포 대상 단계가 실패하는 3가지 주요 이유:
새로 배포된 AEM 서비스를 시작하는 동안 실행되는 코드가 너무 오래 걸려서 배포가 완료되기 전에 Cloud Manager 시간이 초과됩니다. 이러한 경우 Cloud Manager 상태가 실패 라고 보고해도 결국 배포가 성공할 수 있습니다.
aemerror
Cloud Manager에 표시된 실패 시간(GMT에 로그인 시간)에 AEM 작성자 및 게시 서비스에 대한 로그를 찾고 사용자 지정 로그 실행 프로세스를 나타내는 로그 메시지를 찾습니다.대부분의 코드 및 구성 위반은 빌드 초기에 발견되지만 사용자 지정 코드 또는 구성이 AEM as a Cloud Service과 호환되지 않고 컨테이너에서 실행될 때까지 검색되지 않을 수 있습니다.
aemerror
Cloud Manager에서 보듯이 실패의 시간(GMT에 로그 시간)에 AEM 작성자 및 게시 서비스에 대한 로그입니다.
/var
는 다양한 임시 런타임 컨텐츠를 포함하는 변경할 수 있습니다. 포함 /var
컨텐츠 패키지 내(예: ui.content
) Cloud Manager를 통해 배포되면 배포 단계가 실패할 수 있습니다.
이 문제는 초기 배포에 오류가 발생하지 않고 후속 배포에만 실패하므로 식별하기 어렵습니다. 눈에 띄는 증상은 다음과 같습니다.
이 문제의 원인을 확인하려면:
배포의 일부인 하나 이상의 컨텐츠 패키지가 /var
.
기본(볼드) 배포 큐가 다음 위치에서 차단되었는지 확인합니다.
AEM 작성자 > 도구 > 배포 > 배포
후속 배포가 실패하면 다운로드 로그 단추를 사용하여 Cloud Manager의 "배포 대상" 로그를 다운로드하십시오.
… 및 로그 문 사이에 약 60분이 있는지 확인합니다.
2020-01-01T01:01:02+0000 Begin deployment in aem-program-x-env-y-dev [CorrelationId: 1234]
… 및 …
2020-01-01T02:04:10+0000 Failed deployment in aem-program-x-env-y-dev
이 로그에는 후속 배포가 실패한 경우에만 성공적이라고 보고하는 초기 배포에 이러한 지표가 포함되지 않습니다.
/var
AEM 게시에서 참조할 수 있습니다. 따라서 AEM 게시 서비스에 컨텐츠 패키지를 배포하지 못합니다./var
리소스를 제거할 필요가 없습니다. /var
애플리케이션의 일부로 배포되는 컨텐츠 패키지에서/var
리소스가 필요하며, 점. 리디렉션 스크립트는 OSGi 실행 모드를 통해 AEM 작성자, AEM 게시 또는 둘 다에 타깃팅될 수 있습니다./var
리소스는 AEM 작성자에만 필요하며 점로 이동하여 작성자 AEM 작성자에만 설치된 개별 컨텐츠 패키지로 이동합니다 포함 다음 위치에서 all
aem 작성자 런타임 모드 폴더의 패키지(<target>/apps/example-packages/content/install.author</target>
).sling-distribution-importer
서비스 사용자 참조 Adobe KB.위의 문제 해결 방법으로 문제가 해결되지 않으면 다음을 통해 Adobe 지원 사례를 만드십시오.
Adobe Admin Console > 지원 탭 > 사례 만들기
여러 Adobe 조직의 멤버인 경우 케이스를 만들기 전에 Adobe 조직 전환기에서 실패한 파이프라인이 있는 Adobe 조직이 선택되었는지 확인하십시오.