O Adobe Cloud Manager facilita a criação do código e as implantações em AEM as a Cloud Service. Falhas podem ocorrer durante as etapas do processo de compilação, exigindo ação para resolvê-las. Este guia aborda a compreensão de falhas comuns na implantação e como abordá-las da melhor maneira.
A etapa de validação simplesmente garante a validade das configurações básicas do Cloud Manager. As falhas comuns de validação incluem:
A fase Criar e Testar unidade executa uma compilação Maven (mvn clean package
) do projeto com check-out da ramificação Git configurada do pipeline.
Os erros identificados nesta fase devem ser reproduzidos na construção local do projeto, com as seguintes exceções:
pom.xml
. Observe que, a inclusão de repositórios Maven não é incentivada, pois aumenta os tempos de criação..sleep(..)
no código de teste.A verificação de código executa a análise de código estático usando uma combinação de práticas recomendadas específicas de Java e AEM.
A verificação de código resulta em uma falha de criação se houver uma vulnerabilidade de segurança crítica no código. É possível substituir menos violações, mas é recomendável corrigi-las. Observe que a digitalização de código é imperfeita e pode resultar em falsos positivos.
Para resolver problemas de digitalização de código, baixe o relatório em formato CSV fornecido pelo Cloud Manager por meio da Detalhes de download e revise quaisquer entradas.
Para obter mais detalhes, consulte AEM regras específicas, consulte as documentações do Cloud Manager" regras de varredura de código AEM específicas personalizadas.
A imagem de build é responsável por combinar os artefatos de código criados na etapa Criar e testar a unidade com a versão do AEM, para formar um único artefato implantável.
Embora todos os problemas de compilação e criação de código sejam encontrados durante o teste de compilação e unidade, pode haver problemas de configuração ou estruturais identificados ao tentar combinar o artefato de compilação personalizado com a versão de AEM.
Quando várias configurações de OSGi são resolvidas via runmode para o ambiente de 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 defina como <cloudManagerTarget>none</cloudManagerTarget>
.Os scripts de redirecionamento definem o conteúdo da linha de base, os usuários, as ACLs, etc. Em AEM as a Cloud Service, os scripts de realocação são aplicados durante a Criação de imagem, no entanto, na inicialização rápida local AEM SDK, eles são aplicados quando a configuração de fábrica de reponteiro OSGi é ativada. Por causa disso, os scripts Repoinit podem falhar silenciosamente (com registro) AEM inicialização rápida local do SDK, mas fazem com que a etapa Criar imagem falhe, interrompendo a implantação.
Os scripts de redirecionamento definem o conteúdo da linha de base, os usuários, as ACLs, etc. Em AEM inicialização rápida local do SDK, os scripts de redirecionamento são aplicados quando a configuração de fábrica OSGi de redirecionamento é ativada, ou em outras palavras, depois que o repositório está ativo e pode ter incorrido em alterações de conteúdo diretamente ou por meio de pacotes de conteúdo. Em AEM as a Cloud Service, os scripts de reponteiro são aplicados durante a criação de imagem em relação a um repositório que pode não conter conteúdo do qual o script de reponteiro depende.
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.
AEM as a Cloud Service inclui automaticamente a versão mais recente dos Componentes principais em cada versão de AEM, o que significa que, depois que um ambiente as a Cloud Service é atualizado automaticamente ou manualmente, a versão mais recente dos Componentes principais foi implantada nele.
É possível que a etapa Criar imagem falhe 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 garanta que as atualizações sejam 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 ERROR que
com.adobe.cq.wcm.core.components...
os pacotes em intervalos de versão específicos não puderam ser importados 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 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 Adobe, por meio de:
Adobe Admin Console > Guia Suporte > Criar caso
Se você for membro de várias Orgs do Adobe, verifique se o pipeline Adobe com falha está selecionado no alternador de Orgs do Adobe antes de criar o caso.
A etapa Implantar em é responsável por obter o artefato de código gerado na Criar imagem, iniciar novos serviços de Autor e Publicação do AEM usando e, após o sucesso, remover qualquer serviço antigo de Autor e Publicação do AEM. Pacotes e índices de conteúdo variável também são instalados e atualizados nesta etapa.
Familiarize-se com AEM registros as a Cloud Service antes de depurar a etapa Implantar em . O aemerror
o log contém informações sobre a inicialização e o desligamento de pods que podem ser pertinentes para a implantação para problemas. Observe que o log disponível por meio do botão Download Log na etapa Implantar no Cloud Manager não é o aemerror
e não contém informações detalhadas sobre a inicialização de seus aplicativos.
Os três principais motivos pelos quais a etapa Implantar em pode falhar:
O código em execução durante a inicialização do serviço de AEM recém-implantado demora tanto que o Cloud Manager expire antes que a implantação possa ser concluída. Nesses casos, a implantação poderá eventualmente ter êxito, mesmo se o status do Cloud Manager for relatado como Failed.
aemerror
Registros para os serviços de Autor e Publicação do AEM na hora da falha (tempo de log em GMT), conforme mostrado pelo Cloud Manager, e procure mensagens de log indicando quaisquer processos de log personalizados em execução.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 personalizados sejam incompatíveis com o AEM as a Cloud Service e não sejam detectados até que seja executado no container.
aemerror
Registros para os serviços de Autor e Publicação do AEM ao longo do tempo (tempo de log em GMT) da falha, conforme mostrado pelo Cloud Manager.
/var
O é mutável que contém uma variedade de conteúdo temporário em tempo de execução. Incluindo /var
em pacotes de conteúdo (por exemplo, ui.content
) implantado 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 notáveis incluem:
Para validar esse problema, é a causa do comportamento com falha:
Determinar que pelo menos um pacote de conteúdo que faz parte da implantação grava em /var
.
Verifique se a fila de distribuição primária (em negrito) está bloqueada em:
Autor do AEM > Ferramentas > Implantação > Distribuição
Ao falhar na implantação subsequente, baixe os registros "Implantar em" do Cloud Manager usando o botão Baixar log:
… e verifique se há aproximadamente 60 minutos entre as declarações de log:
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-sucedidas, em vez de somente nas implantações subsequentes com falha.
/var
na publicação do AEM. 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 de /var
de pacotes de conteúdo que são implantados como parte de seu aplicativo./var
os recursos são necessários, defina as estruturas do nó usando repoinit. Os scripts de realocação podem ser direcionados para Autor do AEM, Publicação do AEM ou ambos, por meio de modos de execução OSGi./var
os recursos são necessários apenas AEM autor e não podem ser razoavelmente modelados usando repoinit, mova-os para um pacote de conteúdo discreto, que é instalado somente no AEM Author por incorporação no all
pacote em uma pasta do modo de execução do AEM Author (<target>/apps/example-packages/content/install.author</target>
).sling-distribution-importer
usuário de 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 Adobe, por meio de:
Adobe Admin Console > Guia Suporte > Criar caso
Se você for membro de várias Orgs do Adobe, verifique se o pipeline Adobe com falha está selecionado no alternador de Orgs do Adobe antes de criar o caso.