Implantação do AEM as a Cloud Service deploying-to-aem-as-a-cloud-service

Introdução introduction

Os fundamentos do desenvolvimento de código são semelhantes no AEM as a Cloud Service em comparação às soluções locais do AEM e Managed Services. Desenvolvedores(as) criam o código e o testam localmente, e depois o enviam para ambientes remotos do AEM as a Cloud Service. O uso do Cloud Manager, que era uma ferramenta opcional de entrega de conteúdo do Managed Services, é obrigatório. Esta ferramenta de entrega é agora o único mecanismo para implantar código nos ambientes de desenvolvimento, preparo e produção do AEM as a Cloud Service. Para uma rápida validação e depuração de recursos antes da implantação desses ambientes mencionados, o código pode ser sincronizado de um ambiente local para um ambiente de desenvolvimento rápido.

A atualização da versão do AEM é sempre um evento de implantação separado do envio de código personalizado. Como alternativa, as versões de código personalizadas devem ser testadas em relação à versão do AEM que está em produção, pois é nela que ela é implantada. As atualizações de versão do AEM que ocorrem depois disso (que são frequentes e são aplicadas automaticamente) devem ser compatíveis com versões anteriores do código do cliente já implantado.

O restante deste documento descreve como os desenvolvedores adaptam suas práticas para trabalhar com atualizações de versão e de clientes da AEM as a Cloud Service.

Versões do cliente customer-releases

Codificar na versão correta do AEM coding-against-the-right-aem-version

Para soluções anteriores da AEM, a versão do AEM era alterada com pouca frequência e os clientes atualizavam as instâncias de produção para o início rápido mais recente, fazendo referência ao Jar da API. No entanto, os aplicativos do AEM as a Cloud Service são atualizados automaticamente para a versão mais recente com mais frequência, portanto, o código personalizado para versões internas deve ser criado baseado na versão mais recente do AEM.

Assim como nas versões existentes do AEM que não estão em nuvem, o desenvolvimento local e offline baseado em uma inicialização rápida específica é compatível e geralmente se espera que seja a ferramenta principal de depuração.

Para desenvolver um código personalizado para uma versão interna, a versão relevante do SDK do AEM as a Cloud Service deve ser baixada e instalada. Para obter informações adicionais sobre como usar as Ferramentas do AEM as a Cloud Service Dispatcher, consulte Dispatcher na nuvem.

O vídeo a seguir fornece uma visão geral de alto nível sobre como implantar código no AEM as a Cloud Service:

Implantação de pacotes de conteúdo por meio do Cloud Manager e do Gerenciador de pacotes deploying-content-packages-via-cloud-manager-and-package-manager

Implantações por meio do Cloud Manager deployments-via-cloud-manager

Clientes implantam código personalizado em ambientes na nuvem por meio do Cloud Manager. O Cloud Manager transforma pacotes de conteúdo montados localmente em um artefato em conformidade com o Modelo de recurso do Sling. Este modelo descreve um aplicativo no AEM as a Cloud Service quando executado em um ambiente de nuvem. Como resultado, ao examinar os pacotes do Gerenciador de pacotes em ambientes na nuvem, o nome incluirá “cp2fm” e os pacotes transformados terão todos os metadados removidos. Não é possível interagir com eles, o que significa que não podem ser baixados, replicados ou abertos. Para obter a documentação detalhada sobre o conversor, consulte sling-org-apache-sling-feature-cpconverter no GitHub.

Os pacotes de conteúdo para o AEM as a Cloud Service devem separar conteúdo imutável e mutável. O Cloud Manager instala somente o conteúdo mutável e gera uma mensagem como a seguinte:

Generated content-package <PACKAGE_ID> located in file <PATH> is of MIXED type

O resto desta seção descreverá a composição e as implicações dos pacotes imutáveis e mutáveis.

Pacotes de conteúdo imutáveis immutabe-content-packages

Todo conteúdo e código persistente no repositório imutável deve ser verificado no Git e implantado por meio do Cloud Manager. Em outras palavras, ao contrário das soluções atuais do AEM, o código nunca é implantado diretamente em uma instância em execução do AEM. Esse fluxo de trabalho garante que o código executado para determinada versão seja idêntico em qualquer ambiente da nuvem, o que elimina o risco de uma variação não intencional do código na produção. Como exemplo, a configuração do OSGI deve ser enviada para o controle de origem em vez de ser gerenciada no tempo de execução por meio do gerenciador de configuração do console da web do AEM.

Um switch permite alterações no aplicativo devido ao padrão de implantação, de modo que não podem depender de alterações no repositório mutável, exceto para usuários de serviço, suas ACLs, tipos de nó e alterações na definição de índice.

Para clientes com bases de código já existentes, é muito importante realizar o exercício de reestruturação de repositório descrito na documentação do AEM para garantir que o conteúdo anteriormente contido em /etc seja movido para o local correto.

Algumas restrições adicionais se aplicam a esses pacotes de código, por exemplo, os ganchos de instalação não são suportados.

Configuração OSGI osgi-configuration

Como mencionado acima, a configuração do OSGI deve ser confirmada pelo controle de origem em vez do console da web. As técnicas para fazer isso incluem:

Leia mais sobre a configuração do OSGI em Configuração do OSGi para o AEM as a Cloud Service.

Conteúdo mutável mutable-content

Às vezes, é útil preparar alterações de conteúdo no controle do código-fonte para que o Cloud Manager as implante sempre que um ambiente for atualizado. Por exemplo, é razoável propagar determinadas estruturas de pastas raiz. Para ativar componentes de políticas atualizados pela implantação do aplicativo, alinhe as alterações nos modelos editáveis.

O Cloud Manager implanta conteúdo no repositório mutável usando duas estratégias: pacotes de conteúdo mutável e instruções repoinit.

Pacotes de conteúdo mutáveis mutable-content-packages

Conteúdos como hierarquias de caminho de pasta, usuários de serviço e controles de acesso (ACLs) normalmente são confirmados em um projeto do AEM baseado no arquétipo Maven. As técnicas incluem exportar do AEM ou gravar diretamente como XML. Durante o processo de criação e implantação, o Cloud Manager compacta o pacote de conteúdo mutável resultante. O conteúdo mutável é instalado em três momentos diferentes durante a fase de implantação no pipeline:

Antes da inicialização da nova versão do aplicativo:

Durante a inicialização da nova versão do aplicativo, mas antes da mudança:

Após a mudança para a nova versão do aplicativo:

É possível limitar a instalação de conteúdo mutável para criar ou publicar incorporando pacotes em uma pasta install.author ou install.publish sob /apps. A reestruturação para refletir essa separação foi feita no AEM 6.5 e os detalhes sobre a reestruturação de projeto recomendada podem ser encontrados na documentação do AEM 6.5.

Além disso, não há um mecanismo para reverter as alterações mutáveis no pacote de conteúdo após elas serem aplicadas. Se clientes detectarem um problema, poderão optar por corrigi-lo na próxima versão do código ou, como último recurso, restaurar o sistema inteiro para um determinado estado antes da implantação.

Todos os pacotes de terceiros incluídos devem ser validados como compatíveis com o AEM as a Cloud Service; caso contrário, a inclusão resultará em uma falha de implantação.

Como mencionado acima, os clientes com bases de código existentes estão em conformidade com o exercício de reestruturação de repositório necessário para as alterações de repositório do 6.5 descritas na documentação do AEM 6.5.

Repoinit repoinit

Para os seguintes casos, é preferível usar a abordagem de codificação manual de instruções de criação de conteúdo explícito repoinit nas configurações de fábrica OSGI:

O repoinit é recomendado nesses casos de uso de modificação de conteúdo compatíveis devido aos seguintes benefícios:

Quando o Cloud Manager implanta o aplicativo, ele executa essas instruções, independentemente da instalação de qualquer pacote de conteúdo.

Para criar repoinit instruções:

Mais detalhes sobre repoinit podem ser encontrados na documentação do Sling

Pacotes “avulsos” do Gerenciador de pacotes para pacotes de conteúdo mutável package-manager-oneoffs-for-mutable-content-packages

Há casos de uso em que um pacote de conteúdo deve ser instalado como uma instalação “única”. Por exemplo, importação de conteúdo específico da produção para o preparo a fim de depurar um problema de produção. Para esses cenários, o Gerenciador de pacotes pode ser usado em ambientes do AEM as a Cloud Service.

O Gerenciador de Pacotes é um conceito de tempo de execução; não é possível instalar conteúdo ou código no repositório imutável, e esses pacotes de conteúdo consistem em conteúdo mutável (principalmente /content ou /conf). Se o pacote de conteúdo incluir conteúdo misto (conteúdo mutável e imutável), somente o conteúdo mutável será instalado.

Qualquer instalação de pacote de conteúdo do Cloud Manager (mutável e imutável) aparece congelada na interface do usuário do Gerenciador de pacotes do AEM. Esses pacotes não podem ser reinstalados, recriados ou mesmo baixados e estão listados com um sufixo “cp2fm”, indicando que o Cloud Manager executou a instalação.

Incluindo pacotes de terceiros including-third-party

É comum que os clientes incluam pacotes pré-criados de origem de terceiros, como fornecedores de software, por exemplo, os parceiros de tradução da Adobe. A recomendação é hospedar esses pacotes em um repositório remoto e referenciá-los no pom.xml. Esse método é possível para repositórios públicos e também para repositórios privados com proteção por senha, conforme descrito em repositórios maven protegidos por senha.

Se não for possível armazenar o pacote em um repositório remoto, os clientes podem colocá-lo em um repositório Maven local, baseado no sistema de arquivos, que é confirmado no SCM como parte do projeto. O que depender dele é referência. O repositório é declarado no pom do projeto, conforme ilustrado abaixo:

<repository>
    <id>project.local</id>
    <name>project</name>
    <url>file:${maven.multiModuleProjectDirectory}/repository</url>
</repository>

Todos os pacotes de terceiros incluídos devem seguir as diretrizes de codificação e embalagem do AEM as a Cloud Service descritas neste artigo, caso contrário, sua inclusão resultará em uma falha de implantação.

O seguinte trecho do Maven POM.xml mostra como os pacotes de terceiros podem ser incorporados ao pacote “Container” do projeto, normalmente denominado “todos”, por meio da configuração do plug-in filevault-package-maven-plugin do Maven.

...
<plugin>
  <groupId>org.apache.jackrabbit</groupId>
  <artifactId>filevault-package-maven-plugin</artifactId>
  <extensions>true</extensions>
  <configuration>
      ...
      <embeddeds>

          ...

          <!-- Include any other extra packages  -->
          <embedded>
              <groupId>com.vendor.x</groupId>
              <artifactId>vendor.plug-in.all</artifactId>
              <type>zip</type>
              <target>/apps/vendor-packages/container/install</target>
          </embedded>
      <embeddeds>
  </configuration>
</plugin>
...

Como funcionam as implantações contínuas how-rolling-deployments-work

Assim como as atualizações do AEM, as versões do cliente são implantadas usando uma estratégia de implantação contínua para eliminar o tempo de inatividade do cluster do autor nas circunstâncias certas. A sequência geral de eventos é descrita abaixo, onde os nós com as versões antiga e nova do código do cliente estão executando a mesma versão de código do AEM.

Índices indexes

Os índices novos ou modificados geram uma etapa extra de indexação ou reindexação antes que a nova versão possa receber tráfego. Detalhes sobre o gerenciamento de índice no AEM as a Cloud Service podem ser encontrados em Pesquisa e indexação de conteúdo. É possível verificar o status de indexação das páginas de criação no Cloud Manager e receber uma notificação quando a nova versão estiver pronta para receber tráfego.

No momento, o AEM as a Cloud Service não funciona com ferramentas de gerenciamento de índice, como a ferramenta ACS Commons Ensure Oak Index.

Replicação replication

O mecanismo de publicação é compatível com versões anteriores das APIs Java™ de Replicação do AEM.

Para desenvolver e testar a replicação usando o quickstart do AEM pronto para nuvem, use recursos de replicação clássicos com uma configuração de Autor/Publicação. Se o ponto de entrada da interface no AEM Author for removido da nuvem, os usuários irão para o http://localhost:4502/etc/replication para configuração.

Código compatível com versões anteriores para implantações móveis backwards-compatible-code-for-rolling-deployments

Conforme detalhado acima, a estratégia de implantação contínua da AEM as a Cloud Service implica que as versões antiga e nova operam ao mesmo tempo. Portanto, tenha cuidado com alterações de código que não sejam compatíveis com a versão antiga do AEM que ainda esteja operacional.

Além disso, a versão antiga deve ser testada quanto à compatibilidade com qualquer nova estrutura de conteúdo mutável aplicada pela nova versão em caso de reversão, já que o conteúdo mutável não é removido.

Usuários de serviço e alterações de ACL service-users-and-acl-changes

A alteração de usuários de serviço, ou ACLs que acessam conteúdo ou código, leva a erros nas versões mais antigas do AEM, resultando no acesso a esse conteúdo ou código com usuários de serviço desatualizados. Para lidar com esse comportamento, é recomendado fazer alterações distribuídas em pelo menos duas versões, com a primeira versão funcionando como uma ponte antes da limpeza da versão subsequente.

Alterações de índice index-changes

Se forem feitas alterações nos índices, é importante que a versão antiga continue a usar seus índices até que seja encerrada, enquanto a nova versão usa seu próprio conjunto modificado de índices. O desenvolvedor segue as técnicas de gerenciamento de índice descritas em Pesquisa e indexação de conteúdo.

Codificação conservadora para reversões conservative-coding-for-rollbacks

Se uma falha for relatada ou detectada após a implantação, pode ser necessário reverter para a versão antiga. Certifique-se de que o novo código seja compatível com quaisquer novas estruturas criadas pela nova versão, uma vez que essas estruturas (qualquer conteúdo mutável) não serão revertidas. Se o código antigo não for compatível, as correções precisarão ser aplicadas nas versões subsequentes do cliente.

Ambientes de desenvolvimento rápido (RDE) rde

Os Ambientes de desenvolvimento rápido (ou RDEs) permitem que os desenvolvedores implantem e revisem as alterações rapidamente. Isso minimiza o tempo necessário para testar recursos que já comprovadamente funcionam em um ambiente de desenvolvimento local.

Diferentemente dos ambientes de desenvolvimento comuns, que implantam código por meio do pipeline do Cloud Manager, os desenvolvedores usam ferramentas de linha de comando para sincronizar o código de um ambiente de desenvolvimento local com o RDE. Depois que as alterações forem testadas com sucesso em um RDE, implante-as em um ambiente de desenvolvimento na nuvem normal por meio do pipeline do Cloud Manager, que coloca o código pelos portais de qualidade apropriados.

Modos de execução runmodes

Nas soluções existentes do AEM, os clientes têm a opção de executar instâncias com modos de execução arbitrários e aplicar a configuração do OSGI ou instalar pacotes OSGI nessas instâncias específicas. Os modos de execução definidos normalmente incluem o serviço (autor e publicação) e o ambiente (RDE, desenvolvimento, preparo, produção).

O AEM as a Cloud Service, por outro lado, é mais opinativo sobre quais modos de execução estão disponíveis e como os pacotes OSGI e a configuração OSGI podem ser mapeados para eles:

O AEM as a Cloud Service não permite o uso de modos de execução para instalar conteúdo em ambientes ou serviços específicos. Se um ambiente de desenvolvimento precisar ser semeado com dados ou HTML que não estejam nos ambientes de preparo ou produção, o Gerenciador de pacotes poderá ser usado.

As configurações compatíveis do modo de execução são:

A configuração OSGI que tem mais modos de execução correspondentes é usada.

Ao desenvolver localmente, um parâmetro de inicialização do modo de execução, -r, é usado para especificar a configuração OSGI do modo de execução.

$ java -jar aem-sdk-quickstart-xxxx.x.xxx.xxxx-xxxx.jar -r publish,dev

Configuração de tarefas de manutenção no controle de origem maintenance-tasks-configuration-in-source-control

As configurações da Tarefa de manutenção precisam ser mantidas no controle de origem já que a tela Ferramentas > Operações não estará disponível nos ambientes na nuvem. Esse benefício garante que as alterações sejam intencionalmente mantidas, em vez de reativamente aplicadas e esquecidas. Consulte Tarefas de manutenção no AEM as a Cloud Service para obter mais informações.