Planeje o upgrade para o Ansible Automation Platform 2.6

O lançamento do Red Hat Ansible Automation Platform 2.6 representa um marco crucial. Antes de iniciar o upgrade, há três informações importantes que você precisa saber para facilitar a transição:

• Esta é a última versão com instalador baseado em RPM. O Red Hat Ansible Automation Platform 2.6 com o método RPM está disponível apenas para o Red Hat Enterprise Linux (RHEL) 9. O instalador RPM será descontinuado após este lançamento. A solução Ansible Automation Platform 2.7 será compatível apenas com o método de instalação em containers, o operador do Red Hat OpenShift ou nossos serviços em nuvem. Portanto, agora é a hora de começar a transição.
• O Ansible Automation Platform 2.6 é um lançamento fundamental. Todos os caminhos de upgrade para versões futuras da plataforma devem passar pela versão 2.6. Não há como evitar.
• O RHEL 8 não é mais compatível. Se você ainda utiliza o RHEL 8, será necessário migrar para o RHEL 9 (ou RHEL 10) antes de fazer o upgrade para o Ansible Automation Platform 2.6.

Planeje seu upgrade

Ao planejar sua transição para o Ansible Automation Platform 2.6, duas considerações importantes devem moldar seu plano de upgrade:

Apenas uma coisa pode mudar por vez. Seja no sistema operacional subjacente, no método de instalação ou na versão do produto, o instalador lida com apenas uma alteração por execução. Isso significa que talvez você precise executá-lo várias vezes. Confira a documentação oficial para saber detalhes sobre como isso funciona.

Na maioria dos casos, você precisará instalar do zero.  Exceto em cenários específicos, como o upgrade da versão 2.5 para a 2.6 na mesma arquitetura ou determinadas implantações de operador do Red Hat OpenShift, você precisará implantar uma nova instância do Ansible Automation Platform 2.6 e depois migrar sua configuração para ela.

Isso levanta a seguinte questão: como transferir a configuração existente para a nova instância? A resposta começa com a compreensão de que a configuração do Ansible Automation Platform reside em um banco de dados PostgreSQL. A estratégia de upgrade trata de como você transfere esses dados.

Abordagens para o upgrade

Há dois caminhos para o Ansible Automation Platform 2.6: uma migração centrada no banco de dados ou uma migração centrada na API. A escolha certa depende do seu ambiente, dos seus requisitos e das concessões que você está disposto a fazer.

Uma abordagem centrada no banco de dados trata o Ansible Automation Platform como um sistema stateful em que os dados são a fonte da verdade. Uma abordagem centrada na API trata a plataforma como Configuration as Code (CaC), em que a fonte da verdade está nos arquivos de configuração. Consulte a tabela abaixo para avaliar as considerações técnicas de cada abordagem:

Migrações centradas no banco de dados

Migrações centradas no banco de dados são o caminho documentado e com suporte total que preserva e migra todo o seu banco de dados durante o processo de upgrade. O desafio? A "dança do upgrade". Talvez você esteja migrando do RHEL 8 para o RHEL 9, do RPM para o modelo em containers e do Ansible Automation Platform 2.4/2.5 para o 2.6. Cada uma dessas etapas é independente e requer a própria infraestrutura. 

Isso representa ter uma grande quantidade de ambientes intermediários para provisionar e gerenciar. Dependendo do ponto de partida, do objetivo final da migração e da escala do ambiente (e, portanto, do tamanho do banco de dados), essa tarefa pode demandar muito tempo.

Uma ressalva importante: se essa complexidade levar você a optar pelas ofertas de serviços gerenciados em nuvem do Ansible Automation Platform, saiba que o upload de um banco de dados para serviços gerenciados exigirá um ticket de suporte. Você pode encontrar esse processo documentado aqui. Para fazer isso por conta própria, você precisará usar a abordagem centrada em API.

Migração centrada em API

A Red Hat não oferece suporte formal a essa abordagem (embora os componentes individuais que permitem essa técnica de migração recebam suporte). Dito isso, ela pode ser significativamente mais rápida, especialmente para grandes ambientes. Como é uma migração única para a plataforma de destino, não há necessidade de instalações intermediárias.

Nesse método, você exportaria a configuração do Ansible Automation Platform usando chamadas de API para armazená-la localmente, como em arquivos de configuração ou em um banco de dados temporário. É possível modificar esses arquivos conforme necessário e restaurá-los em outra plataforma também por meio da API. Esse método também oferece um benefício adicional: ele introduz a Configuration as Code (CaC) ao seu fluxo de trabalho, oferecendo uma base para gerenciar a plataforma usando métodos de CaC futuramente.

Quais são os prós e os contras? Você perderá o histórico de tarefas (mitigado por um agregador de logs externo) e precisará lidar com os segredos com cuidado (mitigados por um gerenciador de segredos externo). Também pode ser necessário editar os arquivos de configuração exportados para formatá-los corretamente para importação, especialmente para o private automation hub e objetos do Event-Driven Ansible.

Uma observação sobre segredos

Os segredos de credencial e de notificação ficam armazenados no banco de dados de configuração e criptografados pela SECRET_KEY do banco de dados. Como são criptografados, seus valores não são exportados pela API. Portanto, para acessar os segredos da sua configuração, é necessário ter acesso root ao servidor do banco de dados. Como isso exporia seus segredos em texto simples, você precisará lidar com eles com extremo cuidado, como criptografá-los novamente em um Ansible vault. 

No entanto, se você usar um gerenciador de segredos externo, como o HashiCorp Vault, isso não será um problema, pois esses segredos não residem no Ansible Automation Platform. Caso haja poucos segredos para gerenciar, pode ser igualmente simples preenchê-los na nova plataforma.

Considerações sobre ambos os métodos

Independentemente do caminho escolhido, lembre-se do seguinte: as integrações externas e os tokens de API provavelmente exigirão atenção. 

O Red Hat Ansible Automation Platform 2.5 introduziu o automation gateway, um front-end unificado que conecta o automation controller, o Ansible automation hub e o Event-Driven Ansible controller em uma única interface. Isso mudou muitos endpoints de API para novos caminhos. Embora a compatibilidade com versões anteriores desses pontos de extremidade de integração tenha sido mantida na versão 2.6, será necessário atualizá-los para versões futuras. Além disso, será necessário regenerar e redistribuir a maioria dos tokens emitidos pela plataforma, provisionar servidores adicionais e atualizar os balanceadores de carga para o novo serviço de gateway.

Bancos de dados gerenciados externamente

Para clientes com bancos de dados gerenciados externamente, há considerações adicionais.  Primeiro, o Red Hat Ansible Automation Platform 2.4 usa Postgres 13. O sistema realiza o upgrade para Postgres 15 na versão 2.5 e PostgreSQL 15 na versão 2.6. O Red Hat Ansible Automation Platform 2.6 também oferece suporte para bancos de dados PostgreSQL 16 e 17 fornecidos pelo cliente. Esse procedimento de upgrade do banco de dados é uma consideração importante na migração e na "dança da atualização"; ele é fundamental para explicar por que os clientes não podem reutilizar o banco de dados existente sem passar por esse processo.  Especificamente para o Red Hat Ansible Automation Platform 2.5+, é necessário habilitar os componentes internacionais para Unicode (ICU) em bancos de dados fornecidos pelo cliente. Esse recurso está disponível, mas não vem habilitado por padrão na maioria dos principais provedores de banco de dados, como EDB, Amazon Web Services Relational Database Service (AWS RDS) e Azure SQL Database. Essa compatibilidade de banco de dados é o motivo pelo qual não é possível apenas atualizar o esquema em um banco de dados existente.

Compatibilidade com playbooks

Ao fazer o upgrade do Red Hat Ansible Automation Platform, a versão do ansible-core enviada no execution environment padrão também é atualizada. A boa notícia é que você sempre pode executar ambientes de execução mais antigos em versões mais recentes da plataforma para manter a compatibilidade com versões anteriores. No entanto, o upgrade é altamente recomendável para aproveitar as novas funcionalidades e correções de segurança.

Ao fazer o upgrade dos ambientes de execução, você atualiza para uma nova versão do ansible-core, o que pode trazer algumas mudanças. Veja o que esperar:

Migração do Red Hat Ansible Automation Platform 2.4 para 2.6 (migração do ansible-core 2.15 para 2.16)

Este é um upgrade secundário. A alteração mais notável é que o sistema agora trata alguns avisos em instruções condicionais como erros. Além disso, o impacto é mínimo.

Migração para o ansible-core 2.18 (ambiente de execução opcional no Red Hat Ansible Automation Platform 2.6) Esse upgrade é um ambiente de execução com suporte opcional para o Red Hat Ansible Automation Platform 2.6 e traz muito mais mudanças. Especificamente:

• As versões Python 2.7 e 3.6 em nós de destino não são mais compatíveis. Isso significa que não é mais possível direcionar hosts do RHEL 6 com esse ambiente de execução. Os hosts do RHEL 7 precisarão do Python 3.8 (disponível via Red Hat Software Collections) para automação com o Red Hat Ansible Automation Platform.
• O Python 3.11 agora é a versão do Python incluída no seu ambiente de execução. É necessário atualizar as bibliotecas Python personalizadas e de terceiros para versões compatíveis com 3.11.
• A limpeza das "dead batteries" do Python está em andamento. PEP 594: este processo remove bibliotecas obsoletas, inseguras e sem manutenção da biblioteca padrão ao longo das próximas versões do Python. Os avisos de descontinuação começam com o Python 3.11. Algumas bibliotecas são removidas na versão 3.12 e a remoção em massa ocorre na versão 3.13.

Para a grande maioria dos clientes, essa não é uma preocupação imediata, mas vale a pena prestar atenção aos avisos de descontinuação agora para se preparar.

Para ver todos os detalhes sobre as versões compatíveis do ansible-core, consulte a Política de suporte oficial da Red Hat.

A transição para o Ansible Automation Platform 2.6 é mais do que apenas uma atualização de versão: é uma medida estratégica que prepara o terreno para a próxima geração de automação. Ao escolher o caminho de migração que melhor se adapta à sua infraestrutura hoje, você pode manter sua automação resiliente, focada na segurança e pronta para o que vier.

Recursos adicionais

• Artigo: Automatize upgrades do Ansible Automation Platform 2.6 com Python, AsyncIO e operações em massa
• Notas de lançamento e documentação do Ansible Automation Platform.
• Novidades do Ansible Automation Platform