Migração das suas workloads de contêiner do Azure Red Hat OpenShift (ARO) para o Serviço Red Hat OpenShift na AWS (ROSA)
Naveen Ramasamy, Srikanth Rangavajhala e Gireesh Sreekantan, Amazon Web Services
Resumo
Este padrão fornece instruções passo a passo para migrar workloads de contêiner do Azure Red Hat OpenShift (ARO) para Serviço Red Hat OpenShift na AWS(ROSA)
A migração de workloads de contêineres do ARO, de outras nuvens ou de on-premises para o ROSA envolve a transferência de aplicações, configurações e dados de uma plataforma para outra. Este padrão ajuda a garantir uma transição suave e, ao mesmo tempo, otimiza os serviços da Nuvem AWS, a segurança e a eficiência de custos. Ele abrange dois métodos para migrar suas workloads para clusters ROSA: CI/CD e kit de ferramentas de migração para contêineres (MTC).
Este padrão abrange os dois métodos. O método que você escolhe depende da complexidade e da certeza do seu processo de migração. Se você tem controle total sobre o estado da sua aplicação e pode garantir uma configuração consistente por meio de um pipeline, recomendamos que você use o método de CI/CD. No entanto, se o estado da sua aplicação envolver incertezas, mudanças imprevistas ou um ecossistema complexo, recomendamos que você use o MTC como um caminho confiável e controlado para migrar sua aplicação e seus dados para um novo cluster. Para uma comparação detalhada dos dois métodos, consulte a seção Informações adicionais.
Benefícios da migração para o ROSA:
O ROSA se integra perfeitamente à AWS como um serviço nativo. É facilmente acessível por meio do Console de gerenciamento da AWS e cobrado por meio de uma única Conta da AWS. Ele oferece total compatibilidade com outros Serviços da AWS e fornece suporte colaborativo tanto da AWS quanto da Red Hat.
O ROSA oferece suporte a implantações híbridas e multinuvem Ele permite que as aplicações sejam executadas de forma consistente em data centers on-premises e em vários ambientes de nuvem.
O ROSA se beneficia do foco em segurança da Red Hat e fornece recursos como controle de acesso baseado em funções (RBAC), digitalização de imagens e avaliações de vulnerabilidade para garantir um ambiente de contêiner seguro.
O ROSA foi projetado para escalar aplicações com facilidade e fornecer opções de alta disponibilidade. Ele permite que as aplicações cresçam conforme necessário, mantendo a confiabilidade.
O ROSA automatiza e simplifica a implantação de um cluster do Kubernetes em comparação com os métodos manuais de configuração e gerenciamento. Isso acelera o processo de desenvolvimento e implantação.
O ROSA se beneficia dos serviços da Nuvem AWS e fornece integração perfeita com ofertas da AWS como serviços de banco de dados, soluções de armazenamento e serviços de segurança.
Pré-requisitos e limitações
Pré-requisitos
Uma Conta da AWS ativa.
Permissões configuradas para Serviços da AWS, nas quais o ROSA depende para fornecer funcionalidades. Para obter mais informações, consulte Prerequisites na documentação do ROSA.
ROSA habilitado no console do ROSA
. Para obter instruções, consulte a documentação do ROSA. O cluster do ROSA instalado e configurado. Para obter mais informações, consulte Get started with ROSA na documentação do ROSA. Para entender os diferentes métodos para configurar um cluster do ROSA, consulte as Recomendações da AWS Estratégias de implementação do ROSA.
Conectividade de rede estabelecida a partir da rede on-premises para a AWS por meio do AWS Direct Connect (preferencial) ou AWS Virtual Private Network (Site-to-Site VPN).
Uma instância do Amazon Elastic Compute Cloud (Amazon EC2) ou outro servidor virtual para instalar ferramentas como
aws client, cliente OpenShift CLI (oc), cliente ROSA e binário Git.
Pré-requisitos adicionais para o método de CI/CD:
Acesso ao servidor Jenkins on-premises com permissões para criar um novo pipeline, adicionar estágios, adicionar clusters do OpenShift e realizar compilações.
Acesso ao repositório Git onde o código-fonte da aplicação é mantido, com permissões para criar uma nova ramificação Git e realizar confirmações na nova ramificação.
Pré-requisitos adicionais para o método MTC:
Um bucket do Amazon Simple Storage Service (Amazon S3) que será usado como repositório de replicação.
Acesso administrativo ao cluster ARO de origem. Isso é necessário para configurar a conexão MTC.
Limitações
Alguns Serviços da AWS não estão disponíveis em todas as Regiões da AWS. Para conferir a disponibilidade de uma região, consulte Serviços da AWS by Region
. Para endpoints específicos, consulte a página Cotas e endpoints de serviços e clique no link correspondente ao serviço desejado.
Arquitetura
O ROSA fornece três padrões de implantação de rede: público, privado e AWS PrivateLink. O PrivateLink permite que as equipes de engenharia de confiabilidade de sites (SRE) da Red Hat gerenciem o cluster usando uma sub-rede privada conectada ao endpoint PrivateLink do cluster em uma VPC existente.
A escolha da opção PrivateLink fornece a configuração mais segura. Por esse motivo, nós o recomendamos para workloads confidenciais ou requisitos rígidos de conformidade. Para obter informações sobre as opções de implantação de redes públicas e privadas, consulte a documentação do Red Hat OpenShift
Importante
Você pode criar um cluster PrivateLink somente no momento da instalação. Você não pode alterar um cluster para usar o PrivateLink após a instalação.
O diagrama a seguir ilustra a arquitetura do PrivateLink para um cluster do ROSA que usa o Direct Connect para se conectar aos ambientes on-premises e ARO.
Permissões da AWS para o ROSA
Para obter permissões da AWS para o ROSA, recomendamos que você use AWS Security Token Service (AWS STS) com tokens dinâmicos de curta duração. Esse método usa perfis e políticas predefinidas com privilégios mínimos para conceder ao ROSA permissões mínimas para operar no Conta da AWS e oferece suporte à instalação, ao ambiente de gerenciamento e à funcionalidade de computação do ROSA.
Reimplantação do pipeline de CI/CD
A reimplantação do pipeline de CI/CD é o método recomendado para usuários que têm um pipeline de CI/CD maduro. Ao escolher essa opção, você pode usar qualquer estratégia de implantação de DevOps para transferir gradualmente a carga da aplicação para implantações no ROSA.
nota
Este padrão pressupõe um caso de uso comum em que você tem um pipeline Git, JFrog Artifactory e Jenkins on-premises. Essa abordagem exige que você estabeleça conectividade de rede da sua rede on-premises para a AWS por meio do Direct Connect, e que configure o cluster do ROSA antes de seguir as instruções na seção Épicos. Consulte a seção Pré-requisitos para obter detalhes.
O diagrama a seguir mostra o fluxo de trabalho para esse método.
Método MTC
Você pode usar o kit de ferramentas de migração para contêineres (MTC)
O diagrama a seguir mostra o fluxo de trabalho para esse método.
Ferramentas
Serviços da AWS
O AWS DataSync é um serviço on-line de transferência e descoberta de dados que ajuda você a mover arquivos ou dados de objetos de, para e entre os serviços de armazenamento da AWS.
O AWS Direct Connect estabelece uma conexão entre sua rede interna e um ponto do Direct Connect usando um cabo de fibra óptica Ethernet padrão. Com essa conexão, é possível criar interfaces virtuais diretamente para Serviços da AWS públicos, sem depender dos provedores de internet.
O AWS PrivateLink ajuda a criar conexões unidirecionais e privadas de suas nuvens privadas virtuais (VPCs) para serviços em outras VPCs.
O Serviço Red Hat OpenShift na AWS (ROSA) é um serviço gerenciado que ajuda os usuários do Red Hat OpenShift a criar, escalar e gerenciar aplicações em contêineres na AWS.
AWS Security Token Service (AWS STS) O () permite solicitar credenciais temporárias de privilégio limitado para usuários.
Outras ferramentas
O kit de ferramentas de migração para contêineres (MTC)
fornece um console e uma API para migrar aplicações em contêineres do ARO para o ROSA.
Práticas recomendadas
Para resiliência e se você tiver workloads de conformidade de segurança, configure um cluster do ROSA Multi-AZ que use o PrivateLink. Para obter mais informações, consulte a documentação do ROSA.
nota
O PrivateLink não pode ser configurado após a instalação.
O bucket do S3 que você usa para o repositório de replicação não deve ser público. Use as políticas do bucket do S3 apropriadas para restringir o acesso.
Se você escolher o método MTC, use a opção de migração Stage para reduzir a janela de tempo de inatividade durante a substituição.
Revise suas cotas de serviço antes e depois de provisionar o cluster do ROSA. Se necessário, solicite um aumento de cota de acordo com suas necessidades. Para obter mais informações, consulte a documentação do Service Quotas.
Revise as diretrizes de segurança do ROSA e implemente as práticas recomendadas de segurança.
Recomendamos que você remova o administrador de cluster padrão após a instalação. Para obter mais informações, consulte a documentação do Red Hat OpenShift
. Use o escalonamento automático do pool de máquinas para reduzir os nós de processamento não utilizados no cluster do ROSA e otimizar os custos. Para obter mais informações, consulte ROSA Workshop
. Use o serviço Red Hat Cost Management para o OpenShift Container Platform para entender e monitorar melhor os custos de nuvens e contêineres. Para obter mais informações, consulte ROSA Workshop
. Monitore e audite os serviços e aplicações da infraestrutura do cluster do ROSA usando Serviços da AWS. Para obter mais informações, consulte ROSA Workshop
.
Épicos
| Tarefa | Descrição | Habilidades necessárias |
|---|---|---|
Adicione o novo cluster do ROSA ao Jenkins. |
| Administrador da AWS, administrador de sistemas da AWS, profissional de DevOps da AWS |
Adicione o cliente |
| Administrador da AWS, administrador de sistemas da AWS, profissional de DevOps da AWS |
Crie uma nova ramificação do Git. | Crie uma nova ramificação no seu repositório Git para | AWS DevOps |
Marque as imagens do ROSA. | Em seu estágio de construção, use uma marcação diferente para identificar as imagens que são criadas a partir do pipeline ROSA. | Administrador da AWS, administrador de sistemas da AWS, profissional de DevOps da AWS |
Crie um pipeline. | Crie um novo pipeline do Jenkins que seja semelhante ao seu pipeline existente. Para esse pipeline, use a ramificação | Administrador da AWS, administrador de sistemas da AWS, profissional de DevOps da AWS |
Adicione um estágio de implantação do ROSA. | No novo pipeline, adicione um estágio para implantação no cluster do ROSA e faça referência ao cluster do ROSA que você adicionou à configuração global do Jenkins. | Administrador da AWS, profissional de DevOps da AWS, administrador de sistemas da AWS |
Inicie uma nova compilação. | No Jenkins, selecione seu pipeline e escolha Build now, ou inicie uma nova compilação confirmando uma alteração na ramificação | Administrador da AWS, profissional de DevOps da AWS, administrador de sistemas da AWS |
Verificar a implantação. | Use o comando oc ou o console do ROSA | Administrador da AWS, profissional de DevOps da AWS, administrador de sistemas da AWS |
Copie dados para o cluster de destino. | Para workloads com estado, copie os dados do cluster de origem para o cluster de destino usando o AWS DataSync ou usando utilitários de código aberto, como rsync, ou você pode usar o método MTC. Para obter mais informações, consulte a a documentação do AWS DataSync. | Administrador da AWS, profissional de DevOps da AWS, administrador de sistemas da AWS |
Testar seu aplicativo |
| Administrador da AWS, profissional de DevOps da AWS, administrador de sistemas da AWS |
Substituir. | Se o teste for bem-sucedido, use a política apropriada do Amazon Route 53 para mover o tráfego da aplicação hospedada no ARO para a aplicação hospedada no ROSA. Quando você concluir essa etapa, a workload da sua aplicação fará a transição completa para o cluster do ROSA. | Administrador da AWS, administrador de sistemas da AWS |
| Tarefa | Descrição | Habilidades necessárias |
|---|---|---|
Instale o operador do MTC. | Instale o operador MTC nos clusters ARO e ROSA:
| Administrador da AWS, profissional de DevOps da AWS, administrador de sistemas da AWS |
Configure o tráfego de rede para o repositório de replicação. | Se você estiver usando um servidor proxy, configure-o para permitir o tráfego de rede entre o repositório de replicação e os clusters. O repositório de replicação é um objeto de armazenamento intermediário que o MTC usa para migrar dados. Os clusters de origem e de destino devem ter acesso de rede ao repositório de replicação durante a migração. | Administrador da AWS, profissional de DevOps da AWS, administrador de sistemas da AWS |
Adicione o cluster de origem ao MTC. | No console web MTC, adicione o cluster de origem ARO. | Administrador da AWS, profissional de DevOps da AWS, administrador de sistemas da AWS |
Adicione o Amazon S3 como seu repositório de replicação. | No console web da MTC, adicione o bucket do Amazon S3 (consulte Pré-requisitos) como repositório de replicação. | Administrador da AWS, profissional de DevOps da AWS, administrador de sistemas da AWS |
Criar um plano de migração. | No console web do MTC, crie um plano de migração e especifique o tipo de transferência de dados como Cópia. Isso instruirá a MTC a copiar os dados do cluster de origem (ARO) para o bucket do S3 e do bucket para o cluster de destino (ROSA). | Administrador da AWS, profissional de DevOps da AWS, administrador de sistemas da AWS |
Execute o plano de migração. | Execute o plano de migração usando a opção Stage ou Cutover:
| Administrador da AWS, profissional de DevOps da AWS, administrador de sistemas da AWS |
Solução de problemas
| Problema | Solução |
|---|---|
Problemas de conectividade | Ao migrar suas workloads de contêiner do ARO para o ROSA, você pode encontrar problemas de conectividade que devem ser resolvidos para garantir uma migração bem-sucedida. Para resolver esses problemas de conectividade (listados nesta tabela) durante a migração, um planejamento meticuloso, a coordenação com suas equipes de rede e segurança e testes completos são essenciais. A implementação de uma estratégia de migração gradual e a verificação da conectividade em cada etapa ajudarão a minimizar possíveis interrupções e garantir uma transição suave do ARO para o ROSA. |
Diferenças de configuração de rede | ARO e ROSA podem ter variações em suas configurações de rede, como configurações de rede virtual (VNet), sub-redes e políticas de rede. Para uma comunicação adequada entre os serviços, certifique-se de que as configurações de rede estejam alinhadas entre as duas plataformas. |
Grupo de segurança e regras de firewall | O ROSA e o ARO podem ter configurações de firewall e grupo de segurança padrão diferentes. Certifique-se de ajustar e atualizar essas regras para permitir que o tráfego necessário mantenha a conectividade entre contêineres e serviços durante a migração. |
Alterações no endereço IP e no DNS | Quando você migra workloads, os endereços IP e os nomes DNS podem mudar. Reconfigure aplicações que dependem de IPs estáticos ou nomes DNS específicos. |
Acesso a serviços externos | Se sua aplicação depender de serviços externos, como bancos de dados ou APIs, talvez seja necessário atualizar suas configurações de conexão para garantir que eles possam se comunicar com os novos serviços do ROSA. |
Configuração do Azure Private Link | Se você usa o Azure Private Link ou serviços de endpoint privados no ARO, precisará configurar a funcionalidade equivalente no ROSA para garantir a conectividade privada entre os recursos. |
Configuração da Site-to-Site VPN ou Direct Connect | Se houver conexões existentes por Site-to-Site VPN ou Direct Connect entre sua rede on-premises e o ARO, você precisará estabelecer conexões semelhantes com o ROSA para comunicação ininterrupta com seus recursos locais. |
Configurações de entrada e do balanceador de carga | As configurações para controladores de entrada e balanceadores de carga podem ser diferentes entre ARO e ROSA. Redefina essas configurações para manter o acesso externo aos seus serviços. |
Tratamento de certificados e TLS | Se suas aplicações usarem certificados SSL ou TLS, verifique se os certificados são válidos e configurados corretamente no ROSA. |
Acessos do registro de contêiner | Se seus contêineres estiverem hospedados em um registro de contêiner externo, configure a autenticação adequada e as permissões de acesso para o ROSA. |
Monitorar e registrar em log | Atualize as configurações de monitoramento e registro em log para refletir a nova infraestrutura no ROSA para que você possa continuar monitorando a integridade e a performance de seus contêineres de forma eficaz. |
Recursos relacionados
AWS References da
O que é o Serviço Red Hat OpenShift na AWS? (Documentação do ROSA)
Get started with ROSA (documentação do ROSA)
Serviço Red Hat OpenShift na AWS implementation strategies (Recomendações da AWS)
Serviço Red Hat OpenShift na AWS Now GA
(publicação no Blog da AWS)
Documentação do Red Hat OpenShift
Mais informações
Escolher entre as opções de reimplantação de pipeline de MTC e de CI/CD
A migração de aplicações de um cluster do OpenShift para outro exige uma análise cuidadosa. Idealmente, você desejaria uma transição suave usando um pipeline de CI/CD para reimplantar a aplicação e lidar com a migração de dados de volume persistente. No entanto, na prática, uma aplicação em execução em um cluster é suscetível a mudanças imprevistas ao longo do tempo. Essas alterações podem fazer com que a aplicação se desvie gradualmente de seu estado original de implantação. A MTC oferece uma solução para cenários em que o conteúdo exato de um namespace é incerto e uma migração perfeita de todos os componentes da aplicação para um novo cluster é importante.
Fazer a escolha certa exige avaliar seu cenário específico e pesar os benefícios de cada abordagem. Ao fazer isso, você pode garantir uma migração bem-sucedida e perfeita, alinhada às suas necessidades e prioridades. Aqui estão as diretrizes adicionais para a escolha entre as duas opções.
Reimplantação do pipeline de CI/CD
O método de pipeline de CI/CD é a abordagem recomendada se sua aplicação puder ser reimplantada com confiança usando um pipeline. Isso garante que a migração seja controlada, previsível e alinhada às suas práticas de implantação existentes. Ao escolher esse método, você pode usar estratégias de implantação azul/verde ou de implantação canário para transferir gradualmente a carga para implantações no ROSA. Para esse cenário, esse padrão pressupõe que o Jenkins esteja orquestrando implantações de aplicações a partir do ambiente on-premises.
Vantagens:
Você não precisa de acesso administrativo ao cluster ARO de origem nem precisa implantar nenhum operador no cluster de origem ou de destino.
Essa abordagem ajuda você a mudar o tráfego gradualmente usando uma estratégia de DevOps.
Desvantagens:
É preciso mais esforço para testar a funcionalidade da sua aplicação.
Se sua aplicação contiver dados persistentes, ele precisará de etapas adicionais para copiar os dados usando o AWS DataSync ou outras ferramentas.
Migração MTC
No mundo real, as aplicações em execução podem passar por mudanças imprevistas que fazem com que eles se afastem da implantação inicial. Escolha a opção MTC quando não tiver certeza sobre o estado atual da sua aplicação no cluster de origem. Por exemplo, se seu ecossistema de aplicações abrange vários componentes, configurações e volumes de armazenamento de dados, recomendamos que você escolha o MTC para garantir uma migração completa que abranja a aplicação e todo o seu ambiente.
Vantagens:
O MTC fornece backup e restauração completos da workload.
Ele copiará os dados persistentes da origem para o destino durante a migração da workload.
Ele não requer acessos ao repositório de código-fonte.
Desvantagens:
Você precisa de privilégios administrativos para instalar o operador MTC nos clusters de origem e destino.
A equipe de DevOps precisa de treinamento para usar a ferramenta MTC e realizar migrações.
