As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Migre suas cargas de trabalho de contêiner do Azure Red Hat OpenShift (ARO) para Serviço Red Hat OpenShift na AWS (ROSA)
Naveen Ramasamy, Srikanth Rangavajhala e Gireesh Sreekantan, Amazon Web Services
Resumo
Esse padrão fornece step-by-step instruções para migrar cargas de trabalho 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. Esse padrão ajuda a garantir uma transição suave enquanto otimiza os Nuvem AWS serviços, a segurança e a eficiência de custos. Ele abrange dois métodos para migrar suas cargas de trabalho para clusters ROSA: CI/CD e o Migration Toolkit for Containers (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 do seu aplicativo e pode garantir uma configuração consistente por meio de um pipeline, recomendamos que você use o CI/CD método. 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 um único Conta da AWS. Ele oferece total compatibilidade com outros Serviços da AWS e fornece suporte colaborativo tanto da Red Hat 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 Nuvem AWS serviços e fornece integração perfeita com AWS ofertas como serviços de banco de dados, soluções de armazenamento e serviços de segurança.
Pré-requisitos e limitações
Pré-requisitos
Um ativo Conta da AWS.
Permissões configuradas para Serviços da AWS isso que o ROSA usa para fornecer funcionalidade. 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 ROSA, consulte o guia de orientação AWS prescritiva sobre estratégias de implementação do ROSA.
Conectividade de rede estabelecida a partir da rede local AWS por meio de 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 clientcliente OpenShift CLIoc(), cliente ROSA e binário Git.
Pré-requisitos adicionais para o método: CI/CD
Acesso ao servidor Jenkins local com permissões para criar um novo pipeline, adicionar estágios, adicionar OpenShift clusters 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 todos 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 AWS PrivateLinke. PrivateLinkpermite que as equipes de engenharia de confiabilidade de sites (SRE) da Red Hat gerenciem o cluster usando uma sub-rede privada conectada ao PrivateLink endpoint do cluster em uma VPC existente.
A escolha da PrivateLink opção 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 OpenShift documentação da Red Hat
Importante
Você pode criar um PrivateLink cluster somente no momento da instalação. Você não pode alterar um cluster para usar PrivateLink após a instalação.
O diagrama a seguir ilustra a PrivateLink arquitetura de um cluster ROSA usado Direct Connect para se conectar aos ambientes locais e ARO.
AWS permissões para ROSA
Para obter AWS permissões 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 funções e políticas predefinidas com privilégios mínimos para conceder ao ROSA permissões mínimas para operar no e oferece suporte à instalação Conta da AWS, ao plano de controle e à funcionalidade de computação do ROSA.
Reimplantação do pipeline de CI/CD
CI/CD pipeline redeployment is the recommended method for users who have a mature CI/CDoleoduto. Ao escolher essa opção, você pode usar qualquer estratégia de DevOps implantação para transferir gradualmente a carga do aplicativo para implantações no ROSA.
nota
Esse padrão pressupõe um caso de uso comum em que você tem um pipeline Git, JFrog Artifactory e Jenkins locais. Essa abordagem exige que você estabeleça conectividade de rede da sua rede local AWS até Direct Connect a outra e que configure o cluster ROSA antes de seguir as instruções na seção Epics. 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
AWS DataSyncé um serviço on-line de transferência e descoberta de dados que ajuda você a mover arquivos ou dados de objetos para, de e entre serviços AWS de armazenamento.
AWS Direct Connectconecta sua rede interna a um Direct Connect local por meio de um cabo de fibra óptica Ethernet padrão. Com essa conexão, você pode criar interfaces virtuais diretamente para o público, Serviços da AWS ignorando os provedores de serviços de Internet em seu caminho de rede.
AWS PrivateLinkajuda você a criar conexões unidirecionais e privadas de suas nuvens privadas virtuais (VPCs) para serviços fora da VPC.
Serviço Red Hat OpenShift na AWS (ROSA) é um serviço gerenciado que ajuda OpenShift os usuários da Red Hat a criar, escalar e gerenciar aplicativos em contêineres. AWS
AWS Security Token Service (AWS STS) ajuda você a solicitar credenciais temporárias com privilégios limitados para os 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 cargas de trabalho de conformidade de segurança, configure um cluster ROSA Multi-AZ que use. PrivateLink Para obter mais informações, consulte a documentação do ROSA.
nota
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 OpenShift documentação da Red Hat
. 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 for OpenShift Container Platform para entender e monitorar melhor os custos de nuvens e containers. Para obter mais informações, consulte ROSA Workshop
. Monitore e audite os serviços e aplicativos da infraestrutura do cluster ROSA usando Serviços da AWS. Para obter mais informações, consulte ROSA Workshop
.
Épicos
| Tarefa | Description | Habilidades necessárias |
|---|---|---|
Adicione o novo cluster do ROSA ao Jenkins. |
| Administrador da AWS, administrador de sistemas da AWS, AWS DevOps |
Adicione o cliente |
| Administrador da AWS, administrador de sistemas da AWS, AWS DevOps |
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, AWS DevOps |
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, AWS DevOps |
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, AWS DevOps, 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, AWS DevOps, administrador de sistemas da AWS |
Verificar a implantação. | Use o comando oc ou o console do ROSA | Administrador da AWS, AWS DevOps, administrador de sistemas da AWS |
Copie dados para o cluster de destino. | Para cargas de trabalho com estado, copie os dados do cluster de origem para o cluster de destino usando 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 documentação do AWS DataSync. | Administrador da AWS, AWS DevOps, administrador de sistemas da AWS |
Testar seu aplicativo |
| Administrador da AWS, AWS DevOps, 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 | Description | Habilidades necessárias |
|---|---|---|
Instale o operador do MTC. | Instale o operador MTC nos clusters ARO e ROSA:
| Administrador da AWS, AWS DevOps, 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, AWS DevOps, 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, AWS DevOps, 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, AWS DevOps, 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, AWS DevOps, 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, AWS DevOps, 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 aplicativos que dependem de nomes DNS estáticos IPs ou específicos. |
Acesso a serviços externos | Se seu aplicativo 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. |
Site-to-Site VPN ou Direct Connect configuração | Se houver Direct Connect conexões existentes Site-to-Site VPN ou entre sua rede local 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
AWSreferências
O que é 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 estratégias de implementação (AWS orientação prescritiva)
Serviço Red Hat OpenShift na AWS Agora GA
(postagem AWS no blog)
OpenShift Documentação da Red Hat
Mais informações
Escolhendo entre as opções de MTC e reimplantação de CI/CD dutos
A migração de aplicativos de um OpenShift cluster para outro exige uma análise cuidadosa. Idealmente, você desejaria uma transição suave usando um CI/CD pipeline para reimplantar o aplicativo e lidar com a migração de dados de volume persistentes. 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 CI/CD pipeline é a abordagem recomendada se seu aplicativo puder ser reimplantado 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 DevOps estratégia.
Desvantagens:
É preciso mais esforço para testar a funcionalidade da sua aplicação.
Se seu aplicativo contiver dados persistentes, ele precisará de etapas adicionais para copiar os dados usando 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 DevOps equipe precisa de treinamento para usar a ferramenta MTC e realizar migrações.
