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:
Configurar a limpeza do fluxo de trabalho e do log de auditoria
Instalar, Configurar e Executar as Tarefas de Pré-Atualização
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.
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.
O processo de atualização faz um bom trabalho ao manter e mesclar o conteúdo e as configurações existentes no /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 ser mesclada no /var
, o Adobe recomenda que você faça o backup dessas alterações manualmente antes de iniciar a atualização.
Ao iniciar o AEM a partir do arquivo jar, uma variável quickstart.properties
o arquivo é 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.
A variável WorkflowPurgeTask
e com.day.cq.audit.impl.AuditLogMaintenanceTask
As tarefas do 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 as tarefas de limpeza de fluxo de trabalho 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 podem ser encontradas em Manutenção do registro 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.
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.
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.
A variável PreUpgradeTasksMBean
O componente OSGI 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:
Acesse o Console da Web navegando até https://serveraddress:serverport/system/console/configMgr
Pesquisar por "tarefas de pré-atualização", em seguida, clique no primeiro componente correspondente. O nome completo do componente é com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl
Modifique a lista de tarefas de manutenção que devem 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.
Tarefa | Modo de execução | Notas |
TarIndexMergeTask |
crx2 | |
DataStoreGarbageCollectionTask |
crx2 | Executa a marcação e a varredura. Para armazenamentos de dados compartilhados, remova esta etapa e execute preparar instâncias manualmente ou corretamente antes da execução. |
ConsistencyCheckTask |
crx2 | |
WorkflowPurgeTask |
crx2/crx3 | É necessário configurar o OSGi de configuração de limpeza de fluxo de trabalho do Adobe Granite antes de executar. |
GenerateBundlesListFileTask |
crx2/crx3 | |
RevisionCleanupTask |
crx3 | Para instâncias TarMK no AEM 6.0 para 6.2, execute manualmente a Limpeza de revisão offline. |
com.day.cq.audit.impl.AuditLogMaintenanceTask |
crx3 | É necessário definir a configuração OSGi do Agendador de limpeza de log de auditoria antes de executar. |
A variável DataStoreGarbageCollectionTask
chama uma operação de Coleta de Lixo do Datastore com a fase de marcação e varredura, se usada. Para implantações que usam um armazenamento de dados compartilhado, reconfigure-o corretamente ou prepare a instância para evitar a exclusão de itens referenciados por outra instância. Esse processo pode exigir a execução da fase de marcação manualmente em todas as instâncias antes de acionar essa tarefa de pré-atualização.
A variável PreUpgradeTasksMBeanImpl
O componente OSGI vem pré-configurado com uma lista de tags de verificação de integridade de pré-atualização para serem executadas quando o runAllPreUpgradeHealthChecks
o método é chamado:
sistema - a tag usada pelas verificações de integridade de manutenção do granite
pré-atualização - 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 padrão.
Métodos MBean
A funcionalidade do bean gerenciado pode ser acessada usando o Console JMX.
Você pode acessar os MBeans ao:
Indo para o console JMX em https://serveraddress:serverport/system/console/jmx
Pesquisar por TarefasDePré-Atualização e clique no resultado
Selecione qualquer método no Operações e selecione Chamar na janela a seguir.
Abaixo está uma lista de todos os métodos disponíveis que o PreUpgradeTasksMBeanImpl
expõe:
Nome do método | Tipo | Descrição |
getAvailablePreUpgradeTasksNames() |
INFO | Exibe a lista de nomes de tarefas de manutenção de pré-atualização disponíveis. |
getAvailablePreUpgradeHealthChecksTagNames() |
INFO | Exibe a lista dos nomes das tags de verificação de integridade pré-atualização. |
runAllPreUpgradeTasks() |
AÇÃO | Executa todas as tarefas de manutenção de pré-atualização da lista. |
runPreUpgradeTask(preUpgradeTaskName) |
AÇÃO | Executa a tarefa de manutenção de pré-atualização com o nome fornecido como o parâmetro. |
isRunAllPreUpgradeTaskRunning() |
ACTION_INFO | Verifica se runAllPreUpgradeTasksmaintenance tarefa em execução. |
getAnyPreUpgradeTaskRunning() |
ACTION_INFO | Verifica se alguma tarefa de manutenção de pré-atualização está em execução e retorna uma matriz contendo os nomes das tarefas em execução no momento. |
getPreUpgradeTaskLastRunTime(preUpgradeTaskName) |
AÇÃO | Exibe o tempo de execução exato da tarefa de manutenção de pré-atualização com o nome fornecido como parâmetro. |
getPreUpgradeTaskLastRunState(preUpgradeTaskName) |
AÇÃO | Exibe o último estado de execução da tarefa de manutenção de pré-atualização com o nome fornecido como o parâmetro. |
runAllPreUpgradeHealthChecks(shutDownOnSuccess) |
AÇÃO | Executa todas as verificações de integridade anteriores à atualização e salva seu status em um arquivo chamado O arquivo de propriedades é usado como uma pré-condição para qualquer atualização futura |
detectUsageOfUnavailableAPI(aemVersion) |
AÇÃO | Lista todos os pacotes importados que não são mais satisfeitos quando atualização para a versão do AEM especificada. A versão do AEM de destino deve ser fornecido como parâmetro. |
Os métodos MBean podem ser chamados por meio de:
Esta etapa só é necessária se você estiver atualizando de uma versão AEM 5. Ele pode ser ignorado totalmente para atualizações de versões mais antigas do AEM 6.
A forma como o LoginModules
estão configurados para autenticação no nível do repositório e foram alterados basicamente no Apache Oak.
Em versões do AEM que usavam a configuração CRX2, ela era colocada no estado repository.xml
arquivo, enquanto a partir do AEM 6 ele é feito no serviço Apache Felix JAAS Configuration Fatory através 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 desativar os módulos personalizados definidos na configuração JAAS de repository.xml
, você deverá editar a configuração para usar o padrão LoginModule
, 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>
Para obter mais informações, consulte Autenticação com o módulo de logon externo.
Para obter um exemplo de LoginModule
no AEM 6, consulte Configuração do LDAP com AEM 6.
Remova os pacotes somente do diretório crx-quickstart/install DEPOIS de desligar a instância AEM. Esta etapa é uma das últimas antes de iniciar o procedimento de atualização no local.
Remova service packs, pacotes de recursos ou hotfixes que foram implantados por meio do 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.
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.
Desative todos os trabalhos agendados OSGi incluídos no código do aplicativo.
Esta etapa só é necessária para instalações TarMK
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 de limpeza de revisão offline.
Esta etapa só é necessária para instâncias que executam o crx3
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 todos 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.
Normalmente, a pilha subjacente do Apache Oak que o AEM usa para persistência cuida da atualização 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:
Desligue a instância do AEM que deve ser atualizada.
Atualize o esquema do banco de dados. Consulte a documentação do tipo de banco de dados para ver quais ferramentas são necessárias para obter o resultado.
Para obter mais informações sobre como o Oak lida com atualizações de esquema, consulte esta página no site do Apache.
Continue atualizando o AEM.
Essa tarefa de manutenção pré-atualização só será necessária se:
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:
Desanexar a instância do tráfego de produção
Crie um backup de um ou mais usuários que causam o problema. Você pode fazer essa tarefa por meio do Gerenciador de pacotes. Para obter mais informações, consulte Como trabalhar com pacotes.
Exclua um ou mais usuários que estão causando o problema. Veja abaixo uma lista de usuários que podem se enquadrar nesta categoria:
dynamic-media-replication
communities-ugc-writer
communities-utility-reader
communities-user-admin
oauthservice
sling-scripting
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.