Adobe AEM Cloud Manager를 사용하면 코드를 쉽게 작성하고 as a Cloud Service으로 배포할 수 있습니다. 빌드 프로세스의 단계 중에 오류가 발생하여 이를 해결하기 위한 작업이 필요할 수 있습니다. 이 안내서에서는 배포의 일반적인 오류를 이해하고 이러한 오류에 가장 잘 접근하는 방법을 안내합니다.
유효성 검사 단계에서는 기본 Cloud Manager 구성이 유효한지 확인하기만 하면 됩니다. 일반적인 유효성 검사 실패는 다음과 같습니다.
빌드 및 단위 테스트 단계에서는 Maven 빌드(mvn clean package
파이프라인에 구성된 Git 분기에서 체크 아웃된 프로젝트.
이 단계에서 식별된 오류는 다음 예외를 제외하고 로컬에서 프로젝트를 빌드하여 다시 생산할 수 있어야 합니다.
pom.xml
. Maven 리포지토리를 포함하는 것은 작성 시간을 늘리기 때문에 권장되지 않습니다..sleep(..)
를 입력합니다.코드 스캔은 Java와 AEM 관련 모범 사례를 혼합하여 정적 코드 분석을 수행합니다.
코드에 심각한 보안 취약점이 존재하는 경우 코드 스캔으로 인해 빌드 오류가 발생합니다. 더 적은 위반은 재정의할 수 있지만 수정되는 것이 좋습니다. 코드 스캔이 불완전하여 다음을 초래할 수 있습니다. 긍정 오류.
코드 스캔 문제를 해결하려면 다음을 통해 Cloud Manager에서 제공하는 CSV 형식의 보고서를 다운로드하십시오. 다운로드 세부 정보 단추를 누르고 모든 항목을 검토합니다.
자세한 내용은 AEM 관련 규칙을 참조하십시오. Cloud Manager 설명서 를 참조하십시오. 사용자 지정 AEM 관련 코드 검색 규칙.
빌드 이미지는 빌드 및 단위 테스트 단계에서 생성된 빌드된 코드 아티팩트를 AEM 릴리스와 결합하여 하나의 배포 가능한 아티팩트를 형성합니다.
빌드 및 단위 테스트 중에 코드 빌드 및 컴파일 문제가 발견되지만 사용자 지정 빌드 아티팩트를 AEM 릴리스와 결합하려고 할 때 구성 또는 구조적 문제가 확인될 수 있습니다.
여러 OSGi 구성이 대상 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>
.Repoinit 스크립트는 기준 컨텐츠, 사용자, ACL 등을 정의합니다. AEMas a Cloud Service 에서 repoinit 스크립트는 빌드 이미지 중에 적용되지만 AEM SDK의 로컬 빠른 시작에서는 OSGi repoinit 팩토리 구성이 활성화될 때 적용됩니다. 이러한 이유로 Repoinit 스크립트는 AEM SDK의 로컬 빠른 시작에서(로깅과 함께) 조용히 실패하지만 이미지 작성 단계가 실패하여 배포가 중지될 수 있습니다.
Repoinit 스크립트는 기준 컨텐츠, 사용자, ACL 등을 정의합니다. AEM SDK의 로컬 빠른 시작에서 repoinit 스크립트는 repoinit OSGi 팩토리 구성이 활성화될 때 또는 다시 말해 저장소가 활성화된 후에 적용되며 콘텐츠 패키지를 통해 또는 직접 콘텐츠를 변경할 수 있습니다. AEMas a Cloud Service 에서 repoinit 스크립트는 repoinit 스크립트가 의존하는 콘텐츠를 포함하지 않을 수 있는 저장소에 대해 이미지 작성 중에 적용됩니다.
이 문제는 최신 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
project)는 AEM에 as a Cloud Service으로 배포된 것과 다른 버전 수준에서 핵심 구성 요소 핵심 종속성의 Java 클래스를 가져옵니다.
해결 방법:
위의 문제 해결 방법으로 문제가 해결되지 않으면 다음을 통해 Adobe 지원 사례를 만드십시오.
Adobe Admin Console > 지원 탭 > 사례 만들기
여러 Adobe 조직의 멤버인 경우 사례를 생성하기 전에 Adobe 조직 전환기에서 실패한 파이프라인이 있는 Adobe 조직이 선택되었는지 확인하십시오.
배포처 단계는 빌드 이미지에서 생성된 코드 아티팩트를 가져오고, 이를 사용하여 새 AEM Author 및 Publish 서비스를 시작하며, 성공 시 이전 AEM Author 및 Publish 서비스를 제거합니다. 이 단계에서도 변경 가능한 콘텐츠 패키지 및 색인이 설치되고 업데이트됩니다.
다음 내용에 대해 숙지하십시오. AEM as a Cloud Service 로그 배포 대상 단계를 디버깅하기 전에. 다음 aemerror
로그에는 문제에 배포와 관련이 있을 수 있는 pod의 시작 및 종료에 대한 정보가 포함되어 있습니다. Cloud Manager의 배포 대상 단계에서 로그 다운로드 버튼을 통해 사용할 수 있는 로그는 이 아닙니다. aemerror
에는 애플리케이션 시작과 관련된 자세한 정보가 포함되어 있지 않습니다.
배포 대상 단계가 실패할 수 있는 세 가지 주요 이유는 다음과 같습니다.
새로 배포된 AEM 서비스를 시작하는 동안 실행되는 코드는 시간이 너무 오래 걸려 Cloud Manager가 시간 초과되어 배포를 완료할 수 있습니다. 이러한 경우 Cloud Manager 상태가 실패로 보고되었더라도 배포가 결국 성공할 수 있습니다.
aemerror
Cloud Manager에 표시된 대로 실패 시간(GMT로 로그 시간) 경에 AEM 작성자 및 게시 서비스에 대한 로그를 찾고, 실행 중인 사용자 정의 로그를 나타내는 로그 메시지를 찾습니다.대부분의 코드 및 구성 위반은 빌드의 앞부분에서 발견되지만, 사용자 지정 코드 또는 구성이 AEM as a Cloud Service과 호환되지 않을 수 있으며 컨테이너에서 실행될 때까지 감지되지 않습니다.
aemerror
AEM Author 및 Publish 서비스에 대한 로그는 Cloud Manager에 표시된 대로 오류가 발생한 시간(GMT로 로그 시간)에 해당합니다.
/var
은 다양한 임시 런타임 콘텐츠를 포함하여 변경할 수 있습니다. 포함 /var
콘텐츠 패키지에서(예: ui.content
) Cloud Manager를 통해 배포하면 배포 단계가 실패할 수 있습니다.
이 문제는 초기 배포에 실패하지 않고 후속 배포에만 실패하므로 식별하기가 어렵습니다. 눈에 띄는 증상은 다음과 같습니다.
이 문제의 유효성을 검사하려면 실패 동작의 원인을 확인하십시오.
배포의 일부인 하나 이상의 콘텐츠 패키지가 /var
.
기본(굵게) 배포 큐가 다음 위치에서 차단되었는지 확인:
AEM 작성자 > 도구 > 배포 > 배포
후속 배포가 실패하면 로그 다운로드 버튼을 사용하여 Cloud Manager의 "배포 대상" 로그를 다운로드합니다.
… 그리고 log 문 사이에 약 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 Publish 서비스로 배포하지 못합니다./var
리소스는 필요하지 않습니다. /var
애플리케이션의 일부로 배포되는 콘텐츠 패키지에서/var
리소스가 필요합니다. 다음을 사용하여 노드 구조를 정의합니다. repoinit. Repoinit 스크립트는 OSGi 실행 모드를 통해 AEM Author, AEM Publish 또는 둘 다에 타깃팅할 수 있습니다./var
리소스는 AEM 작성자에게만 필요하며 를 사용하여 합리적으로 모델링할 수 없습니다. repoinit, 개별 컨텐츠 패키지로 이동합니다. 이 패키지는 AEM 작성자에만 설치됩니다. 포함 다음에서 all
AEM 작성자 실행 모드 폴더의 패키지(<target>/apps/example-packages/content/install.author</target>
).sling-distribution-importer
이에 설명된 서비스 사용자 ADOBE KB.위의 문제 해결 방법으로 문제가 해결되지 않으면 다음을 통해 Adobe 지원 사례를 만드십시오.
Adobe Admin Console > 지원 탭 > 사례 만들기
여러 Adobe 조직의 멤버인 경우 사례를 생성하기 전에 Adobe 조직 전환기에서 실패한 파이프라인이 있는 Adobe 조직이 선택되었는지 확인하십시오.