Como implantar o Red Hat OpenShift Service on AWS

Muitas empresas escolhem o Red Hat OpenShift como a plataforma comum para desenvolver e executar todas as aplicações. Dessa forma, evitam um ambiente heterogêneo que pode criar muita complexidade. Elas criam e executam novas aplicações nativas em nuvem no Red Hat OpenShift, além de migrar as aplicações legadas para a plataforma.

Uma das principais vantagens de usar o OpenShift é que os desenvolvedores só precisam aprender a usar interface, sem ter que se preocupar com os detalhes subjacentes da plataforma. Isso pode resultar em aumentos significativos na produtividade.

Red Hat OpenShift Service on AWS (ROSA)

Alguns dos clientes que decidem adotar o OpenShift querem ainda mais simplicidade. Eles preferem não se preocupar em fornecer nem gerenciar a infraestrutura para os clusters. Eles querem que suas equipes sejam produtivas desde o primeiro dia e se concentrem apenas no desenvolvimento de aplicações. Uma opção é o Red Hat OpenShift Service on AWS (ROSA).

O ROSA é totalmente hospedado na nuvem pública da Amazon Web Services (AWS). Ele é mantido em conjunto pela Red Hat e AWS, o que significa que o control plane e os nós de computação são totalmente gerenciados por uma equipe de engenheiros de confiabilidade de sites (SREs) da Red Hat com suporte conjunto da Red Hat e da Amazon. Isso inclui instalação, gerenciamento, manutenção e upgrades em todos os nós.

Opções de implantação do ROSA

Há duas maneiras principais de implantar o ROSA: em um cluster público ou em um cluster privado. Em ambos os casos, recomendamos implantá-lo em várias zonas de disponibilidade para fins de resiliência e alta disponibilidade. 

Os clusters públicos são usados principalmente para cargas de trabalho sem requisitos rigorosos de segurança. O cluster será implantado em uma nuvem privada virtual (VPC) dentro de uma sub-rede privada (que conterá os nós de control plane, os nós de infraestrutura e os nós de trabalho onde as aplicações são executadas). No entanto, ela ainda poderá ser acessada pela Internet. Por isso, é necessária uma sub-rede pública além da VPC. 

Os balanceadores de carga da AWS (balanceadores de carga elásticos e de rede) implantados nessa sub-rede pública permitem que a equipe de SRE e os usuários que acessam as aplicações (ou seja, o tráfego de entrada para o cluster) se conectem. No caso dos usuários, um balanceador de carga redirecionará o tráfego para o serviço de roteador em execução nos nós de infraestrutura e, a partir daí, ele será encaminhado para a aplicação desejada em execução em um dos nós de trabalho. A equipe de SRE usará uma conta da AWS dedicada para se conectar aos nós de controle e infraestrutura por meio de diferentes balanceadores de carga. 

Figura 1. Cluster público do ROSA

Para cargas de trabalho de produção com necessidades de segurança mais rigorosas, recomendamos implantar um cluster do PrivateLink. Nesse caso, a VPC na qual o cluster reside tem apenas uma sub-rede privada, o que significa que não pode ser acessada pela Internet pública. 

A equipe de SRE usa uma conta da AWS dedicada que se conecta a um balanceador de carga da AWS por meio de um endpoint AWS PrivateLink. O balanceador de carga redireciona o tráfego para os nós de controle ou de infraestrutura conforme necessário. Depois que o AWS PrivateLink é criado, o cliente precisa aprovar o acesso da conta da AWS da equipe de SRE. Os usuários se conectam a um balanceador de carga da AWS, que os redireciona para o serviço de roteador nos nós de infraestrutura. Depois, eles são direcionados para o nó de trabalho no qual a aplicação que desejam acessar está em execução.

Em implementações de cluster do PrivateLink, é comum que os clientes queiram redirecionar o tráfego de saída do cluster para a infraestrutura on-premise deles ou para outras VPCs na nuvem da AWS. Para fazer isso, eles podem usar um AWS Transit Gateway ou AWS Direct Connect para que não seja necessário implantar uma sub-rede pública na VPC em que o cluster reside. Mesmo que precisem direcionar o tráfego de saída para a Internet, eles podem se conectar (por meio do AWS Transit Gateway) a uma VPC que tenha uma sub-rede pública com um AWS NAT Gateway e um AWS Internet Gateway.

Figura 2. Cluster privado do ROSA com PrivateLink

Nas implementações pública e do PrivateLink, o cluster pode interagir com outros serviços da AWS usando endpoints de VPC da AWS para se comunicar com a VPC em que o cluster está com os serviços desejados.

Como se conectar ao cluster

A maneira recomendada para a equipe de SRE fazer login nos clusters do ROSA e realizar tarefas administrativas é usar o AWS Security Token Service (STS). É fundamental adotar o conceito de menor privilégio, limitando os papéis atribuídos apenas aos necessários para concluir uma tarefa. O token é temporário e de uso único. Portanto, se uma tarefa semelhante precisar ser realizada novamente após a expiração, será necessário solicitar um novo token.

O uso do STS também inclui a conexão do cluster do ROSA a outros serviços da AWS, como o EC2 (por exemplo, se novos servidores precisarem ser iniciados para o cluster) ou o EBS (quando o armazenamento persistente é necessário).

Resumo

Adotar metodologias de DevOps e modernizar a maneira como as aplicações são implantadas usando uma plataforma Kubernetes empresarial como o OpenShift são opções viáveis para todos os tipos de clientes. Eles podem optar por hospedá-la on-premise e gerenciá-la por conta própria. Se preferirem, o ROSA também é uma opção. O grande número de serviços da AWS que podem interagir com os clusters do ROSA ajuda os clientes a aproveitar ao máximo a plataforma.

Mais informações

• Implementação do Red Hat OpenShift Service on AWS