Tarefas de manutenção de pré-atualização

Antes de iniciar sua atualização, é importante seguir essas tarefas de manutenção para garantir que o sistema esteja pronto e possa ser revertido em caso de problemas:

• Garantir espaço suficiente em disco

• Fazer backup completo AEM

• Fazer backup das alterações em /etc

• Gerar o arquivo quickstart.properties

• Configurar a limpeza do workflow e do log de auditoria

• Instalar, configurar e executar as tarefas de pré-atualização

• Desativar Módulos de Logon Personalizados

• Remover Atualizações Do Diretório /install

• Interromper Instâncias de Espera Fria

• Desativar Trabalhos Programados Personalizados

• Executar Limpeza de Revisão Offline

• Executar coleta de lixo do armazenamento de dados

• Atualizar o esquema do banco de dados, se necessário

• Excluir usuários que possam prejudicar a atualização

• Girar arquivos de log

Garantir espaço suficiente em disco

Ao executar a atualização, além das atividades de atualização de conteúdo e código, será necessário executar a migração do repositório. A migração criará uma cópia do repositório no novo formato do Segment Tar. Como resultado, você precisará de espaço em disco suficiente para manter uma segunda versão, potencialmente maior, do repositório.

Fazer backup completo AEM

AEM deve ser feito o backup completo antes de iniciar a atualização. Certifique-se de fazer backup do repositório, da instalação do aplicativo, do armazenamento de dados e das instâncias do Mongo, se aplicável. Para obter mais informações sobre como fazer o backup e restaurar uma instância de AEM, consulte Backup e restauração.

Fazer backup das alterações em /etc

O processo de atualização faz um bom trabalho para manter e mesclar o conteúdo e as configurações existentes na /apps e /libs caminhos no repositório. Para alterações feitas no /etc , incluindo as configurações do Context Hub, geralmente é necessário reaplicar essas alterações após a atualização. Embora a atualização faça uma cópia de backup de qualquer alteração que não possa mesclar /var, recomendamos fazer backup dessas alterações manualmente antes de iniciar a atualização.

Gerar o arquivo quickstart.properties

Ao iniciar o AEM a partir do arquivo jar, um quickstart.properties o arquivo será gerado em crx-quickstart/conf. Se AEM tiver sido iniciado apenas com o script de início no passado, esse arquivo não estará presente e a atualização falhará. Verifique a existência desse arquivo e reinicie o AEM do arquivo jar se ele não estiver presente.

Configurar a limpeza do workflow e do log de auditoria

O WorkflowPurgeTask e com.day.cq.audit.impl.AuditLogMaintenanceTask tarefas exigem configurações OSGi separadas e não funcionarão sem elas. Se falharem durante a execução da tarefa de pré-atualização, as configurações ausentes serão o motivo mais provável. Portanto, adicione configurações OSGi para essas tarefas ou remova-as completamente da lista de tarefas de otimização de pré-atualização se não quiser executá-las. A documentação para configurar tarefas de limpeza de workflow pode ser encontrada em Administração de instâncias de fluxo de trabalho e a configuração da tarefa de manutenção de log de auditoria pode ser encontrada em Manutenção do registro de auditoria no AEM 6.

Para limpeza de workflow e log de auditoria no CQ 5.6, bem como limpeza de log de auditoria no AEM 6.0, consulte Eliminar fluxo de trabalho e nós de auditoria.

Instalar, configurar e executar as tarefas de pré-atualização

Devido ao nível de AEM de personalização permitido, os ambientes geralmente não seguem uma maneira uniforme de executar atualizações. Isso torna difícil a criação de um procedimento padronizado para atualizações.

Em versões anteriores, também era difícil para as atualizações de AEM que foram interrompidas ou que não puderam ser retomadas com segurança. Isso levou a situações em que o reinício do procedimento de atualização completo era necessário ou em que as atualizações defeituosas eram realizadas sem acionar nenhum aviso.

Para solucionar esses problemas, o Adobe adicionou vários aprimoramentos ao processo de atualização, tornando-o mais resiliente e fácil de usar. As tarefas de manutenção de pré-atualização que antes precisavam ser executadas manualmente estão sendo otimizadas e automatizadas. Além disso, relatórios pós-atualização foram adicionados para que o processo possa ser totalmente examinado, na esperança de que quaisquer problemas sejam encontrados com mais facilidade.

Atualmente, as tarefas de manutenção pré-atualização são distribuídas por várias interfaces que são parcial ou completamente executadas manualmente. A otimização de manutenção de pré-atualização introduzida no AEM 6.3 permite uma maneira unificada de acionar essas tarefas e poder inspecionar seus resultados sob demanda.

Todas as tarefas incluídas na etapa de otimização pré-atualização são compatíveis com todas as versões a partir AEM 6.0.

Como configurá-lo

No AEM 6.3 e posterior, as tarefas de otimização de manutenção de pré-atualização são incluídas no jar de início rápido. Se estiver atualizando de uma versão mais antiga do AEM 6, elas serão disponibilizadas por meio de pacotes separados que você pode baixar no Gerenciador de pacotes.

Você pode encontrar os pacotes nesses locais:

• Para atualização do AEM 6.0

• Para atualização do AEM 6.1

• Para atualização do AEM 6.2

Como usá-lo

O PreUpgradeTasksMBean O componente OSGI vem pré-configurado com uma lista de tarefas de manutenção de pré-atualização que podem ser executadas de uma só vez. Você pode configurar as tarefas seguindo o procedimento abaixo:

1. Vá para o Console da Web navegando até https://serveraddress:serverport/system/console/configMgr

2. Pesquisar por "preupgradetask", em seguida, clique no primeiro componente correspondente. O nome completo do componente é com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl

3. Modifique a lista de tarefas de manutenção que precisam ser executadas conforme mostrado abaixo:

   

A lista de tarefas difere dependendo do modo de execução que está sendo usado para iniciar a instância. Abaixo está uma descrição do modo de execução para o qual cada tarefa de manutenção foi projetada.

Configuração padrão das verificações de integridade pré-atualização

O PreUpgradeTasksMBeanImpl O componente OSGI vem pré-configurado com uma lista de tags de verificação de integridade de pré-atualização a serem executadas quando o runAllPreUpgradeHealthChecks é chamado:

• sistema - a etiqueta utilizada pelos controlos sanitários de manutenção dos granitos

• pré-atualização - esta é uma tag personalizada que pode ser adicionada a todas as verificações de integridade que você pode definir para executar antes de uma atualização

A lista é editável. Você pode usar o sinal de mais (+) e menos (-) além das tags, para adicionar mais tags personalizadas ou remover as tags padrão.

Métodos do MBean

A funcionalidade do bean gerenciado pode ser acessada usando o Console JMX.

Você pode acessar os MBeans usando:

1. Ir para o Console JMX em https://serveraddress:serverport/system/console/jmx

2. Procurar por PreUpgradeTasks e clique no resultado

3. Selecione qualquer método no Operações e selecione Invocar na janela a seguir.

Abaixo está uma lista de todos os métodos disponíveis que a variável PreUpgradeTasksMBeanImpl expõe:

Desativar Módulos de Logon Personalizados

A maneira como personalizar LoginModules são configurados para autenticação no nível do repositório e foram alterados fundamentalmente no Apache Oak.

Em AEM versões que usaram a configuração do CRX2 foram colocadas na repository.xml , enquanto a partir de AEM 6, é feito no serviço Apache Felix JAAS Configuration Fatory via Web Console.

Portanto, qualquer configuração existente terá que ser desativada e recriada para o Apache Oak após a atualização.

Para desativar os módulos personalizados definidos na configuração JAAS de repository.xml, é necessário modificar a configuração para usar o padrão LoginModule, como neste exemplo:

<Security >
             ....
          <!--
                 Use LoginModule authenticating against repository itself
                 -->
                 <LoginModule class = "com.day.crx.core.CRXLoginModule" >
                     <param name = "anonymousId" value = "anonymous" />
                     <param name = "adminId" value ="admin" />
                     <param name = "disableNTLMAuth" value = "true" />
                     <param name = "tokenExpiration" value = "43200000" />
                     <!-- param name="trust_credentials_attribute" value="d5b9167e95dad6e7d3b5d6fa8df48af8"/
                -->
                 </LoginModule >
         </ Security>

Remover Atualizações Do Diretório /install

Remova todos os service packs, pacotes de recursos ou hotfixes que foram implantados por meio do crx-quickstart/install no sistema de arquivos local. Isso impedirá a instalação inadvertida de hotfixes e service packs antigos além da nova versão do AEM após a conclusão da atualização.

Interromper Instâncias de Espera Fria

Se estiver usando o modo de espera frio TarMK, pare as instâncias de espera frias. Isso garantirá uma maneira eficiente de retornar online em caso de problemas na atualização. Após a conclusão bem-sucedida da atualização, as instâncias de standby frio precisarão ser recriadas a partir das instâncias primárias atualizadas.

Desativar Trabalhos Programados Personalizados

Desative quaisquer trabalhos agendados OSGi incluídos no código do seu aplicativo.

Executar Limpeza de Revisão Offline

Se estiver usando o TarMK, você deve executar a Limpeza de Revisão Offline antes de atualizar. Isso fará com que a etapa de migração do repositório e as tarefas subsequentes de atualização sejam executadas muito mais rapidamente e ajudará a garantir que a Limpeza de Revisão Online possa ser executada com êxito após a conclusão da atualização. Para obter informações sobre como executar a Limpeza de Revisão Offline, consulte Executando limpeza de revisão offline.

Executar coleta de lixo do armazenamento de dados

Depois de executar a limpeza de revisão em instâncias do CRX3, você deve executar a Coleta de lixo do armazenamento de dados para remover blobs não referenciados no armazenamento de dados. Para obter instruções, consulte a documentação em Coleta de lixo do armazenamento de dados.

Atualizar o esquema do banco de dados, se necessário

Geralmente, a pilha subjacente do Apache Oak AEM usa para persistência cuidará da atualização do schema do banco de dados, se necessário.

No entanto, podem ocorrer casos em que o schema não pode ser atualizado automaticamente. Esses são ambientes de alta segurança, em que o banco de dados está sendo executado sob um usuário com privilégios muito limitados. Se isso acontecer, AEM continuará usando o schema antigo.

Para evitar que isso aconteça, é necessário atualizar o schema seguindo o procedimento abaixo:

1. Desligue a instância de AEM que precisa ser atualizada.

2. Atualize o schema do banco de dados. Consulte a documentação do tipo de banco de dados para ver quais ferramentas você precisa usar para conseguir isso.

   Para obter mais informações sobre como o Oak lida com atualizações de esquema, consulte esta página no site do Apache.

3. Continue com o AEM de atualização.

Excluir usuários que possam prejudicar a atualização

Há casos excepcionais em que os usuários do serviço podem acabar sendo marcados incorretamente como usuários regulares em versões AEM mais antigas.

Se isso acontecer, a atualização falhará com uma mensagem como esta:

ERROR [Apache Sling Repository Startup Thread] com.adobe.granite.repository.impl.SlingRepositoryManager Exception in a SlingRepositoryInitializer, SlingRepository service registration aborted
java.lang.RuntimeException: Unable to create service user [communities-utility-reader]:java.lang.RuntimeException: Existing user communities-utility-reader is not a service user.

Para contornar esse problema, faça o seguinte:

1. Desanexar a instância do tráfego de produção

2. Crie um backup dos usuários que causam o problema. Você pode fazer isso por meio do Gerenciador de pacotes. Para obter mais informações, consulte Como trabalhar com pacotes.

3. Exclua os usuários que estão causando o problema. Abaixo está uma lista de usuários que podem estar incluídos nesta categoria:

   1. dynamic-media-replication
   2. communities-ugc-writer
   3. communities-utility-reader
   4. communities-user-admin
   5. oauthservice
   6. sling-scripting

Girar arquivos de log

Recomendamos o arquivamento dos arquivos de log atuais antes de iniciar a atualização. Isso facilitará o monitoramento e a verificação dos arquivos de log durante e após a atualização para identificar e resolver qualquer problema que possa ocorrer.

Recursos do Business.Adobe.com

Ecommerce Integrations Style System Customer Communications Mobile Forms Version History Digital Rights Management