O Adobe Cloud Manager facilita a criação de código e as implantações para o AEM as a Cloud Service. Podem ocorrer falhas durante as etapas no processo de criação, exigindo uma ação para resolvê-las. Este guia aborda as falhas comuns no na implantação e a melhor maneira de abordá-las.
A etapa de validação simplesmente garante que as configurações básicas do Cloud Manager sejam válidas. Falhas comuns de validação incluem:
A fase de Teste de compilação e unidade realiza uma compilação Maven (mvn clean package
) do projeto retirado da ramificação Git configurada do pipeline.
Os erros identificados nesta fase devem ser reproduzíveis na criação do projeto localmente, com as seguintes exceções:
pom.xml
. Observe que a inclusão de repositórios Maven não é incentivada, pois aumenta os tempos de compilação..sleep(..)
no código de teste.A varredura de código executa análise de código estático usando uma combinação de práticas recomendadas específicas para Java e AEM.
A varredura de código resulta em falha na build se houver vulnerabilidades críticas de segurança no código. Violações menores podem ser substituídas, mas é recomendável que sejam corrigidas. Observe que a verificação de código é imperfeita e pode resultar em falsos positivos.
Para resolver problemas de verificação de código, baixe o relatório em formato CSV fornecido pelo Cloud Manager por meio do Detalhes de download e revise quaisquer entradas.
Para obter mais detalhes, consulte Regras específicas do AEM nas documentações do Cloud Manager' regras personalizadas de varredura de código específico do AEM.
A imagem de build é responsável por combinar os artefatos de código criados na etapa de Teste de compilação e unidade com a versão do AEM, para formar um único artefato implantável.
Embora qualquer problema de compilação e criação de código seja encontrado durante o Teste de compilação e unidade, pode haver problemas estruturais ou de configuração identificados ao tentar combinar o artefato de compilação personalizado com a versão do AEM.
Quando várias configurações de OSGi são resolvidas por meio do modo de execução para o ambiente AEM de destino, a etapa Criar imagem falha com o erro:
[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
configuração definir como <cloudManagerTarget>none</cloudManagerTarget>
.Os scripts de repoinit definem o conteúdo básico, os usuários, as ACLs, etc. No AEM as a Cloud Service, os scripts de repoinit são aplicados durante a imagem de build, no entanto, no quickstart local do SDK do AEM, eles são aplicados quando a configuração de fábrica de repoinit do OSGi é ativada. Por causa disso, os scripts de Repoinit podem falhar silenciosamente (com o registro) na inicialização rápida local do SDK do AEM e, mas causar falha na etapa Criar imagem, interrompendo a implantação.
Os scripts de repoinit definem o conteúdo básico, os usuários, as ACLs, etc. No quickstart local do SDK do AEM, os scripts de repoinit são aplicados quando a configuração de fábrica OSGi de repoinit é ativada ou, em outras palavras, depois que o repositório está ativo e pode ter ocorrido alterações de conteúdo diretamente ou por meio de pacotes de conteúdo. No AEM as a Cloud Service, os scripts de repoinit são aplicados durante a criação de imagem em um repositório que pode não conter conteúdo do qual o script de repoinit dependa.
Esse problema afeta apenas ambientes não relacionados à produção que NÃO são atualizados automaticamente para a versão mais recente do AEM.
O AEM as a Cloud Service inclui automaticamente a versão mais recente dos Componentes principais em cada versão do AEM AEM, ou seja, depois que um ambiente do as a Cloud Service é atualizado automaticamente ou manualmente, ele recebe a versão mais recente dos Componentes principais implantada.
É possível para a etapa Criar imagem que falhará quando:
core
Projeto (pacote OSGi)Para evitar essa falha, sempre que uma Atualização do ambiente as a Cloud Service AEM estiver disponível, inclua a atualização como parte da próxima build/implantação e sempre verifique se as atualizações estão incluídas após incrementar a versão dos Componentes principais na base de código do aplicativo.
Sintomas:
A etapa Criar imagem falha com um relatório de ERRO que com.adobe.cq.wcm.core.components...
pacote(s) em intervalos de versões específicos não pôde ser importado pelo core
projeto.
[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] ------------------------------------------------------------------------
Causa: O pacote OSGi do aplicativo (definido na variável core
projeto) importa classes Java da dependência principal dos Componentes principais, em um nível de versão diferente do que é implantado no AEM as a Cloud Service.
Resolução:
Se as abordagens de solução de problemas acima não resolverem o problema, crie um caso de suporte de Adobe, via:
Adobe Admin Console > Guia Suporte > Criar caso
Se você for membro de várias organizações de Adobe, verifique se a organização de Adobe que tem pipeline com falha está selecionada no alternador de organizações de Adobe antes de criar o caso.
A etapa Implantar em é responsável por pegar o artefato de código gerado na Imagem de build, iniciar os novos serviços de Autor e Publicação do AEM usando-o e, após o sucesso, remover todos os serviços de Autor e Publicação do AEM antigos. Os pacotes e índices de conteúdo mutável também são instalados e atualizados nesta etapa.
Familiarize-se com Logs as a Cloud Service do AEM antes de depurar a etapa Implantar em. A variável aemerror
O registro contém informações sobre a inicialização e o encerramento de pods que podem ser pertinentes à implantação de problemas. Observe que o log disponível por meio do botão Baixar log na etapa Implantar em do Cloud Manager não é o aemerror
e não contém informações detalhadas relacionadas à inicialização dos aplicativos.
Os três principais motivos pelos quais a etapa Implantar em podem falhar:
O código em execução durante a inicialização do serviço AEM recém-implantado leva tanto tempo que o Cloud Manager atinge o tempo limite antes que a implantação possa ser concluída. Nesses casos, a implantação pode ser bem-sucedida, mesmo que o status do Cloud Manager relatou Falha.
aemerror
registra os serviços de Autor e Publicação do AEM no momento da falha (hora do registro em GMT), conforme mostrado pelo Cloud Manager, e procura mensagens de registro indicando quaisquer processos personalizados de execução de registro.A maioria das violações de código e configuração é capturada anteriormente na build. No entanto, é possível que o código ou a configuração personalizada seja incompatível com o AEM as a Cloud Service e não seja detectado até que seja executado no contêiner.
aemerror
registra os serviços de Autor e Publicação do AEM por volta do horário (registro em GMT) da falha, conforme mostrado pelo Cloud Manager.
/var
O é mutável e contém uma variedade de conteúdos transitórios e em tempo de execução. Incluindo /var
em pacotes de conteúdo (por exemplo, ui.content
) implantada por meio do Cloud Manager pode causar falha na etapa Implantar.
Esse problema é difícil de identificar, pois não resulta em falha na implantação inicial, somente em implantações subsequentes. Os sintomas perceptíveis incluem:
Para validar esse problema, é a causa do comportamento com falha:
Ao determinar que pelo menos um pacote de conteúdo faz parte da implantação, o grava em /var
.
Verifique se a fila de distribuição primária (em negrito) está bloqueada em:
AEM Author > Tools > Deployment > Distribution
Ao falhar na implantação subsequente, baixe os logs "Implantar em" do Cloud Manager usando o botão Baixar log:
… e verifique se há aproximadamente 60 minutos entre as instruções de registro:
2020-01-01T01:01:02+0000 Begin deployment in aem-program-x-env-y-dev [CorrelationId: 1234]
… e …
2020-01-01T02:04:10+0000 Failed deployment in aem-program-x-env-y-dev
Observe que esse log não conterá esses indicadores nas implantações iniciais que relatam como bem-sucedido, apenas em implantações subsequentes com falha.
/var
no AEM Publish. Isso resulta na falha da implantação do pacote de conteúdo no serviço de publicação do AEM./var
Os recursos não são necessários para remover recursos em /var
de pacotes de conteúdo implantados como parte do aplicativo./var
recursos são necessários, defina as estruturas de nó usando repoinit. Os scripts de repoinit podem ser direcionados para o AEM Author, AEM Publish ou ambos, por meio dos modos de execução OSGi./var
recursos são necessários apenas para o autor de AEM e não podem ser modelados razoavelmente usando repoinit, mova-os para um pacote de conteúdo distinto, que só é instalado no AEM Author por incorporação no all
pacote em uma pasta de modo de execução AEM Author (<target>/apps/example-packages/content/install.author</target>
).sling-distribution-importer
usuário do serviço conforme descrito neste ADOBE KB.Se as abordagens de solução de problemas acima não resolverem o problema, crie um caso de suporte de Adobe, via:
Adobe Admin Console > Guia Suporte > Criar caso
Se você for membro de várias organizações de Adobe, verifique se a organização de Adobe que tem pipeline com falha está selecionada no alternador de organizações de Adobe antes de criar o caso.