Publicação

Nesta parte da jornada, você aprenderá a planejar e executar a migração assim que o código e o conteúdo estiverem prontos para serem transferidos para o AEM as a Cloud Service. Além disso, você aprenderá quais são as práticas recomendadas e as limitações conhecidas ao executar a migração.

A história até agora

Nas fases anteriores da jornada:

  • Você aprendeu como começar a migrar para o AEM as a Cloud Service na Introdução página.
  • Determinado se sua implantação está pronta para ser movida para a nuvem lendo o Fase de preparação
  • Familiarizou-se com as ferramentas e o processo pelos quais é possível preparar seu código e sua nuvem de conteúdo com o Fase de implementação.

Objetivo

Este documento ajuda você a entender como executar a migração para o AEM as a Cloud Service depois de conhecer as etapas anteriores da jornada. Você aprenderá a executar a migração de produção inicial e as práticas recomendadas a serem seguidas ao migrar para o AEM as a Cloud Service.

Migração de produção inicial

Antes de executar a migração de produção, siga as etapas de ajuste e prova de migração descritas na seção Estratégia e cronograma de migração de conteúdo seção do Fase de implementação.

  • Inicie a migração da produção com base na experiência adquirida durante a migração do estágio de AEM as a Cloud Service executada em clones:

    • Autor-Autor
    • Publish-Publish

  • Valide o conteúdo assimilado nos níveis de criação e publicação as a Cloud Service do AEM.

  • Instrua a equipe de criação de conteúdo a evitar mover o conteúdo na origem e no destino até que a assimilação seja concluída

  • O novo conteúdo pode ser adicionado, editado ou excluído, mas evite movê-lo. Isso se aplica tanto à origem quanto ao destino.

  • Registre o tempo decorrido para que a extração e a assimilação completas tenham uma estimativa dos cronogramas de migração complementar futuros.

  • Criar um planejador de migração para autor e publicação.

Complementos incrementais

Após a migração inicial da produção, você deve realizar atualizações complementares incrementais para garantir que seu conteúdo seja atualizado na instância da nuvem. Por causa disso, recomenda-se seguir estas práticas recomendadas:

  • Colete dados sobre a quantidade de conteúdo. Por exemplo: por uma semana, duas semanas ou um mês.
  • Certifique-se de planejar as atualizações complementares de forma a evitar mais de 48 horas de extração e assimilação de conteúdo. Isso é recomendado para que as atualizações complementares de conteúdo se encaixem em um intervalo de tempo de fim de semana.
  • Planeje o número de atualizações necessárias e use essas estimativas para planejar a data de ativação.

Identificar os cronogramas de congelamento de código e conteúdo para a migração

Como mencionado anteriormente, será necessário agendar um código e um período de congelamento do conteúdo. Use as seguintes perguntas para ajudá-lo a planejar o período de congelamento:

  • Por quanto tempo preciso congelar as atividades de criação de conteúdo?
  • Por quanto tempo devo solicitar que minha equipe de entrega pare de adicionar novos recursos?

Para responder à primeira pergunta, considere o tempo necessário para executar execuções de avaliação em ambientes não relacionados à produção. Para responder à segunda pergunta, você precisa de uma colaboração estreita entre a equipe que está adicionando novos recursos e a equipe que está refatorando o código. O objetivo é garantir que todo o código adicionado à implantação existente também seja adicionado, testado e implantado na ramificação dos serviços em nuvem. Geralmente, significa que a quantidade de congelamento do código é menor.

Além disso, você precisa planejar um congelamento de conteúdo quando a atualização final do conteúdo for agendada.

Práticas recomendadas

Ao planejar ou executar a migração, você deve considerar as seguintes diretrizes:

  • Migrar de Autor para Autor e Publicar para Publicação
  • Solicite um clone de produção que possa ser usado para:
    • Capturar estatísticas do repositório
    • Prova de atividades de migração
    • Preparar o plano de migração
    • Identificar requisitos de congelamento de conteúdo
    • Identificar quaisquer necessidades de upsizing na produção ao fazer a migração da produção

Práticas recomendadas da ferramenta Transferência de conteúdo

Ao entrar em funcionamento, certifique-se de executar a migração de conteúdo na produção em vez de em um clone. Uma boa abordagem é usar AZCopy para a migração inicial e, em seguida, executar extrações complementares com frequência (mesmo diariamente) para extrair partes menores e evitar qualquer carga de longo prazo no AEM de origem.

Ao executar a migração de produção, você deve evitar a execução da ferramenta Transferência de conteúdo a partir de um clone, pois:

  • Se um cliente solicitar que as versões de conteúdo sejam migradas durante as migrações complementares, a execução da ferramenta Transferência de conteúdo de um clone não migrará as versões. Mesmo que o clone seja recriado frequentemente a partir de um autor ativo, cada vez que um clone é criado, os pontos de verificação usados pela ferramenta Transferência de conteúdo para calcular os deltas são redefinidos.
  • Como um clone não pode ser atualizado como um todo, o pacote de Consulta ACL deve ser usado para empacotar e instalar o conteúdo que está sendo adicionado ou editado de produção para clone. O problema dessa abordagem é que qualquer conteúdo excluído na instância de origem nunca chegará ao clone, a menos que seja excluído manualmente da origem e do clone. Isso introduz a possibilidade de que o conteúdo excluído na produção não seja excluído no clone e no AEM as a Cloud Service.

Otimização da carga na origem do AEM ao executar a migração de conteúdo

Lembre-se, a carga na fonte AEM é maior durante a fase de extração. Você deve estar ciente de que:

  • A Ferramenta de transferência de conteúdo é um processo Java externo que usa um Heap JVM de 4 GB
  • A versão que não é do AzCopy baixa binários, armazena em um espaço temporário no autor AEM de origem, consumindo E/S de disco e faz upload no contêiner do Azure que consome largura de banda de rede
  • AzCopy transfere blobs diretamente do armazenamento de blobs para o contêiner do Azure, o que salva a E/S de disco e a largura de banda da rede. A versão do AzCopy ainda usa o disco e a largura de banda da rede para extrair e carregar os dados do armazenamento de segmentos no container do Azure
  • O processo da ferramenta Transferência de conteúdo é mais leve nos recursos do sistema durante a fase de assimilação, pois apenas transmite logs de assimilação e não há muita carga na instância de origem no que diz respeito à E/S de disco ou à largura de banda da rede.

Limitações conhecidas

Leve em consideração que toda a assimilação falhará se qualquer uma das seguintes limitações for encontrada como parte do conjunto de migração extraído:

  • Um Nó JCR que tem um nome com mais de 150 caracteres
  • Um Nó JCR com mais de 16 MB
  • Qualquer usuário/grupo com rep:AuthorizableID sendo assimilado que já está presente no AEM as a Cloud Service
  • Se qualquer ativo extraído e assimilado for movido para um caminho diferente na origem ou no destino antes da próxima iteração da migração.

Integridade do ativo

Em comparação à seção acima da assimilação não falha devido às seguintes preocupações com ativos. No entanto, é altamente recomendável que você siga as etapas apropriadas nestes cenários:

  • Qualquer ativo que tenha a representação original ausente
  • Qualquer pasta que tenha um ausente jcr:content nó.

Ambos os itens acima são identificados e relatados na variável Analisador de práticas recomendadas relatório.

Lista de verificação de ativação

Revise esta lista de atividades para garantir que você execute uma migração tranquila e bem-sucedida.

  • Execute um pipeline de produção completo com testes funcionais e de interface do usuário para garantir uma sempre atual Experiência do produto AEM. Consulte os seguintes recursos.
  • Migre o conteúdo para produção e verifique se um subconjunto relevante está disponível no ambiente de preparo para testes.
    • As práticas recomendadas de DevOps para AEM implicam que o código passa do desenvolvimento para o ambiente de produção, enquanto o conteúdo passa dos ambientes de produção.
  • Programar um período de congelamento do código e do conteúdo.
  • Faça a complementação do conteúdo final.
  • Validar configurações do dispatcher.
    • Usar um validador de dispatcher local que facilite a configuração, validação e simulação do dispatcher localmente
    • Analise cuidadosamente a configuração do host virtual.
      • A solução mais fácil (e padrão) é incluir ServerAlias * em seu arquivo de host virtual no /dispatcher/src/conf.d/available_vhostsfolder.
        • Isso permitirá que os aliases de host usados pelos testes funcionais do produto, invalidação do cache do dispatcher e clones funcionem.
      • No entanto, se ServerAlias * não é aceitável, pelo menos, o seguinte: ServerAlias as entradas devem ser permitidas além dos domínios personalizados:
        • localhost
        • *.local
        • publish*.adobeaemcloud.net
        • publish*.adobeaemcloud.com
  • Configure CDN, SSL e DNS.
    • Se você estiver usando seu próprio CDN, insira um tíquete de suporte para configurar o roteamento apropriado.
    • Se você não estiver usando um CDN adicional, gerencie o SSL e o DNS de acordo com a seguinte documentação:
    • Lembre-se de validar o TTL definido para seu registro DNS.
      • O TTL é o tempo que um registro DNS permanece em um cache antes de solicitar uma atualização ao servidor.
      • Se você tiver um TTL muito alto, as atualizações do seu registro DNS levarão mais tempo para se propagar.
  • Execute testes de desempenho e segurança que atendam aos requisitos e objetivos de sua empresa.
  • Transfira e verifique se a ativação real é realizada sem nenhuma nova implantação ou atualização de conteúdo.
  • Criar perfis de notificação de usuário Admin Console. Consulte Perfis de notificação

Você sempre pode consultar a lista caso precise recalibrar suas tarefas ao executar a migração.

O que vem a seguir

Depois de entender como executar a migração para o AEM as a Cloud Service, você pode verificar o Pós-ativação página para manter sua instância em execução sem problemas.

Nesta página