Tarefas de manutenção de pré-atualização pre-upgrade-maintenance-tasks

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 ensure-sufficient-disk-space

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 fully-back-up-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 backup-changes-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 generate-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 configure-wf-audit-purging

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 install-configure-run-pre-upgrade-tasks

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 how-to-set-it-up

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:

Como usá-lo how-to-use-it

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:

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 default-configuration-of-the-pre-upgrade-health-checks

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:

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:

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

Desativar Módulos de Logon Personalizados disable-custom-login-modules

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 remove-updates-install-directory

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 stop-tarmk-coldstandby-instance

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 disable-custom-scheduled-jobs

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

Executar Limpeza de Revisão Offline execute-offline-revision-cleanup

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 execute-datastore-garbage-collection

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.

Excluir usuários que possam prejudicar a atualização delete-users-that-might-hinder-the-upgrade

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:

Para contornar esse problema, faça o seguinte:

Atualizar o esquema do banco de dados, se necessário upgrade-the-database-schema-if-needed

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:

Girar arquivos de log rotate-log-files

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.