Tarefas de Manutenção de Pré-Atualização pre-upgrade-maintenance-tasks

Antes de iniciar a atualização, é importante seguir estas tarefas de manutenção para garantir que o sistema esteja pronto e possa ser revertido caso ocorram 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, uma migração de repositório deve ser executada. A migração cria uma cópia do repositório no novo formato TAR de segmento. Como resultado, é necessário espaço em disco suficiente para manter uma segunda versão do repositório, possivelmente maior.

Fazer backup completo do AEM fully-back-up-aem

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

Fazer backup de alterações em /etc backup-changes-etc

O processo de atualização faz um bom trabalho de manutenção e mesclagem do conteúdo e das configurações existentes nos caminhos do /apps e do /libs no repositório. Para alterações feitas no caminho /etc, incluindo 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 todas as alterações que não podem ser mescladas no /var, a Adobe recomenda que você faça backup dessas alterações manualmente antes de iniciar a atualização.

Gerar o arquivo quickstart.properties generate-quickstart-properties

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

Configurar a limpeza do fluxo de trabalho e do log de auditoria configure-wf-audit-purging

As tarefas WorkflowPurgeTask e com.day.cq.audit.impl.AuditLogMaintenanceTask exigem configurações OSGi separadas e não podem funcionar sem elas. Se eles falharem durante a execução da tarefa de pré-atualização, a falta de configurações será 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 fluxo de trabalho pode ser encontrada em Administrando 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 de Log de Auditoria no AEM 6.

Para limpeza de fluxo de trabalho e log de auditoria no CQ 5.6 e limpeza de log de auditoria no AEM 6.0, consulte Limpar 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 personalização permitido pelo AEM, os ambientes geralmente não seguem uma maneira uniforme de executar atualizações. Assim, a criação de um procedimento padronizado para atualizações é um processo difícil.

Em versões anteriores, também era difícil para atualizações de AEM que eram interrompidas ou que não eram retomadas com segurança. Esse problema levou a situações em que era necessário reiniciar o procedimento de atualização completo ou em que atualizações com defeito eram realizadas sem disparar avisos.

Para resolver 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 pré-atualização que antes tinham de ser realizadas manualmente estão sendo otimizadas e automatizadas. Além disso, foram adicionados relatórios pós-atualização para que o processo possa ser totalmente analisado, na esperança de que quaisquer problemas sejam encontrados mais facilmente.

Atualmente, as tarefas de manutenção pré-atualização estão distribuídas por várias interfaces que são parcial ou totalmente 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 inspecionar seus resultados sob demanda.

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

Como configurar how-to-set-it-up

No AEM 6.3 e versões posteriores, as tarefas de otimização de manutenção de pré-atualização são incluídas no jar de início rápido.

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

O componente OSGI PreUpgradeTasksMBean vem pré-configurado com uma lista de tarefas de manutenção de pré-atualização que podem ser executadas todas de uma 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 de pré-atualização default-configuration-of-the-pre-upgrade-health-checks

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

A lista é editável. Você pode usar os botões mais (+) e menos (-) além das marcas para adicionar mais marcas personalizadas ou remover as padrão.

Métodos MBean

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

Você pode acessar os MBeans ao:

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

Desativar módulos de logon personalizados disable-custom-login-modules

A forma como os LoginModules personalizados são configurados para autenticação no nível do repositório mudou radicalmente no Apache Oak.

Nas versões do AEM que usavam a configuração do CRX2, ela era colocada no arquivo repository.xml, enquanto do AEM 6 em diante ela era feita no serviço Apache Felix JAAS Configuration Fatory, por meio do Console da Web.

Portanto, todas as configurações existentes precisarão ser desativadas e recriadas para o Apache Oak após a atualização.

Para desabilitar os módulos personalizados definidos na configuração JAAS de repository.xml, edite a configuração para usar o LoginModule padrão, como no exemplo a seguir:

<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 service packs, pacotes de recursos ou hotfixes que foram implantados por meio do diretório crx-quickstart/install no sistema de arquivos local. Isso impede a instalação inadvertida de hotfixes e service packs antigos sobre a nova versão do AEM após a conclusão da atualização.

Interromper Quaisquer Instâncias De Modo De Espera Por Frio stop-tarmk-coldstandby-instance

Se estiver usando a espera a frio do TarMK, interrompa todas as instâncias a frio da espera. Isso garante uma maneira eficiente de voltar a ficar online em caso de problemas na atualização. Depois que o upgrade for concluído com sucesso, as instâncias off-line deverão ser recriadas a partir das instâncias principais atualizadas.

Desabilitar Trabalhos Agendados Personalizados disable-custom-scheduled-jobs

Desative todos os trabalhos agendados OSGi incluídos no código do aplicativo.

Executar limpeza de revisão offline execute-offline-revision-cleanup

Se estiver usando TarMK, você deve executar a Limpeza de revisão offline antes da atualização. Isso torna a etapa de migração do repositório e as tarefas de atualização subsequentes muito mais rápidas e ajuda 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 Execução da 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 nas instâncias do CRX3, você deve executar a Coleta de lixo do armazenamento de dados para remover os blobs não referenciados no armazenamento de dados. Para obter instruções, consulte a documentação em Coleta de lixo do armazenamento de dados.

Fazer Upgrade do Esquema de Banco de Dados, Se Necessário upgrade-the-database-schema-if-needed

Normalmente, a pilha subjacente do Apache Oak que o AEM usa para persistência cuida do upgrade do esquema do banco de dados, se necessário.

No entanto, podem surgir casos em que o esquema não pode ser atualizado automaticamente. Esses casos são, em sua maioria, ambientes de alta segurança nos quais o banco de dados é executado sob um usuário com privilégios limitados. Se tal situação ocorrer, o AEM continuará a usar o esquema antigo.

Para evitar que esse cenário aconteça, atualize o esquema fazendo o seguinte:

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

Há casos excepcionais em que os usuários de serviço podem acabar sendo marcados incorretamente como usuários regulares em uma versão mais antiga do AEM.

Se tal situação ocorrer, a atualização falhará com uma mensagem como a seguinte:

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:

Girar arquivos de registro rotate-log-files

O Adobe recomenda arquivar seus arquivos de log atuais antes de iniciar a atualização. Isso facilita a monitoração e a varredura dos arquivos de registro durante e após a atualização para identificar e resolver quaisquer problemas que possam ocorrer.