As implantações multinuvem vieram para ficar. De acordo com o relatório State of Application Strategy in 2022 da F5, 77% das empresas operam aplicativos em várias nuvens. A adoção de arquiteturas híbridas e multinuvem desbloqueia benefícios importantes, como maior eficiência, menor risco de interrupções e prevenção de dependência de fornecedores. Mas essas arquiteturas complexas também apresentam desafios únicos.
Os líderes de software e TI pesquisados pela F5 nomearam estes como seus principais desafios multinuvem:
Gerenciar APIs para microsserviços em ambientes multinuvem é especialmente complexo. Sem uma estratégia de API holística, as APIs proliferam em ambientes de nuvem pública, locais e de ponta mais rápido do que as equipes de operações de plataforma conseguem protegê-las e gerenciá-las. Chamamos esse problema de proliferação de APIs e, em um post anterior, explicamos por que isso é uma ameaça tão significativa.
Você precisa de uma estratégia de API multinuvem para poder implementar uma abordagem cuidadosa para unificar seus microsserviços — agora distribuídos em várias nuvens — para garantir conectividade de ponta a ponta . Dois dos cenários comuns para implantações multinuvem e híbridas são:
No tutorial a seguir, mostramos passo a passo como usar o API Connectivity Manager , parte do F5 NGINX Management Suite , no segundo cenário: implantando os mesmos serviços em vários ambientes para alta disponibilidade. Isso elimina um único ponto de falha em seu ambiente de produção híbrido ou multinuvem: se uma instância de gateway falhar, outra instância de gateway assume e seus clientes não sofrem interrupções, mesmo que uma nuvem fique inativa.
O API Connectivity Manager é uma solução nativa da nuvem e independente de tempo de execução para implantar, gerenciar e proteger APIs. Em um único painel, você pode gerenciar todas as suas operações de API para gateways de API e portais de desenvolvedores do NGINX Plus implantados em ambientes de nuvem pública, locais e de ponta. Isso dá às suas equipes de operações de plataforma visibilidade total do tráfego de API e facilita a aplicação de políticas consistentes de governança e segurança para cada ambiente.
Conforme mencionado na introdução, neste tutorial estamos configurando o API Connectivity Manager para alta disponibilidade de serviços executados em vários ambientes de implantação. Especificamente, estamos implantando o NGINX Plus como um gateway de API que roteia o tráfego para dois serviços, Serviço A e Serviço B , que estão sendo executados em duas nuvens públicas, Google Cloud Platform (GCP) e Amazon Web Services (AWS). (A configuração se aplica igualmente a qualquer combinação de ambientes de implantação, incluindo Microsoft Azure e data centers locais.)
A Figura 1 descreve a topologia usada no tutorial.
Siga as etapas nestas seções para concluir o tutorial:
Selecione os ambientes que compõem sua infraestrutura multinuvem ou híbrida. Para o tutorial, escolhemos AWS e GCP e estamos instalando uma instância NGINX Plus em cada nuvem. Em cada ambiente, execute estas etapas em cada host do plano de dados que atuará como um gateway de API:
Adicione as seguintes diretivas no contexto principal (nível superior) em /etc/nginx/nginx.conf :
load_module módulos/ngx_http_js_module.so;load_module módulos/ngx_stream_js_module.so;
Reinicie o NGINX Plus, por exemplo, executando este comando:
$ nginx -s recarregar
Você pode criar vários espaços de trabalho de infraestrutura (até 10 no momento da redação deste artigo) no API Connectivity Manager. Com Workspaces segregados, você pode aplicar políticas e requisitos de autenticação/autorização específicos para diferentes linhas de negócios, equipes de desenvolvedores, parceiros externos, nuvens e assim por diante.
Trabalhando na GUI do API Connectivity Manager, crie um novo Workspace:
Clique no botão + Criar para criar um novo espaço de trabalho, conforme mostrado na Figura 2.
No painel Criar Espaço de Trabalho que é aberto, preencha o campo Nome ( demonstração na Figura 3). Opcionalmente, preencha o campo Descrição e os campos na seção Informações de contato do espaço de trabalho . O administrador de infraestrutura (sua equipe de operações de plataforma, por exemplo) pode usar as informações de contato para fornecer atualizações sobre status ou problemas aos usuários do Workspace.
No API Connectivity Manager, um ambiente é um agrupamento lógico de recursos dedicados (como gateways de API ou portais de desenvolvedores de API). Você pode criar vários ambientes por área de trabalho (até 25 no momento da redação deste artigo); eles geralmente correspondem a diferentes estágios de desenvolvimento e implantação do aplicativo, como codificação, teste e produção, mas podem atender a qualquer propósito que você desejar.
Dentro de um ambiente, um cluster de gateway de API é um agrupamento lógico de instâncias do NGINX Plus que atuam como gateways de API. Um único ambiente pode ter vários clusters de API Gateway que compartilham o mesmo nome de host (por exemplo, api.nginx.com , como neste tutorial). As instâncias do NGINX Plus em um cluster do API Gateway podem estar localizadas em mais de um tipo de infraestrutura, por exemplo, em várias nuvens.
Há duas maneiras de configurar um ambiente no API Connectivity Manager para alta disponibilidade ativa de gateways de API:
O principal motivo para implantar vários clusters do API Gateway é poder aplicar um conjunto diferente de políticas de segurança a cada cluster.
Em Implantar instâncias do NGINX Plus como gateways de API , implantamos duas instâncias do NGINX Plus – uma na AWS e a outra no GCP. O tutorial usa as mesmas instâncias para ilustrar ambos os tipos de ambiente (com um único cluster de API Gateway ou com vários clusters de API Gateway); se você quiser implantar ambos os tipos de ambiente em um único espaço de trabalho, precisará criar instâncias adicionais do NGINX Plus para o segundo ambiente.
Para um ambiente com um cluster de gateway de API, as mesmas políticas de segurança se aplicam a todas as instâncias de gateway de API do NGINX Plus, conforme mostrado na Figura 4.
Navegue até seu Workspace e clique no botão Criar Ambiente , conforme mostrado na Figura 5.
No painel Criar ambiente que é aberto, preencha o campo Nome ( prod na Figura 6) e, opcionalmente, o campo Descrição , e selecione o Tipo de ambiente (aqui estamos escolhendo Prod ).
Clique no botão Criar .
O painel Ambiente criado é aberto para exibir o comando que você precisa executar em cada instância do NGINX Plus para atribuí-la ao Cluster do API Gateway. Para sua conveniência, mostramos os comandos na Etapa 7 abaixo.
Repita em cada instância do NGINX Plus:
ssh
para conectar e efetuar login na instância.Se o agente NGINX já estiver em execução, pare-o:
$ systemctl parar nginx-agent
Execute o comando de sua escolha ( curl
ou wget
) para baixar e instalar o pacote do agente NGINX:
Se você não habilitou o mTLS em Instalar e configurar o API Connectivity Manager , adicione:
‑k
para o comando curl
--no-check-certificate
para o comando wget
<NMS_FQDN>
, substitua o endereço IP ou o nome de domínio totalmente qualificado do seu servidor NGINX Management Suite.<nome_do_cluster>
, substitua o nome do API Gateway Cluster (api-cluster
neste tutorial).$ enrolar [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <nome_do_cluster> && sudo systemctl iniciar nginx-agent
ou
$ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <nome_do_cluster> && sudo systemctl iniciar nginx-agent
As instâncias do NGINX Plus agora aparecem na seção Instâncias da janela Cluster para api-cluster , conforme mostrado na Figura 7.
Para um ambiente com vários clusters de gateway de API, diferentes políticas de segurança podem ser aplicadas a diferentes instâncias de gateway de API do NGINX Plus, conforme mostrado na Figura 8.
Navegue até seu Workspace e clique no botão Criar Ambiente , conforme mostrado na Figura 9.
No painel Criar ambiente que é aberto, preencha o campo Nome ( prod na Figura 10) e, opcionalmente, o campo Descrição , e selecione o Tipo de ambiente (aqui estamos escolhendo Prod ).
Clique no botão Criar .
O painel Ambiente criado é aberto para exibir o comando que você precisa executar em cada instância do NGINX Plus para atribuí-la ao Cluster do API Gateway. Para sua conveniência, mostramos os comandos na Etapa 10 abaixo.
Volte para a guia Ambiente e clique no botão + Adicionar no canto superior direito da seção Clusters do API Gateway , conforme mostrado na Figura 11.
No painel Criar cluster do API Gateway , preencha o campo Nome com o nome do segundo cluster ( gcp-cluster na Figura 12) e o campo Nome do host com o mesmo nome de host do primeiro cluster ( api.nginx.com ).
Os dois clusters do API Gateway agora aparecem nos clusters do API Gateway para o ambiente de produção , conforme mostrado na Figura 13.
Repita em cada instância do NGINX Plus:
ssh
para conectar e efetuar login na instância.Se o agente NGINX já estiver em execução, pare-o:
$ systemctl parar nginx-agent
Execute o comando de sua escolha ( curl
ou wget
) para baixar e instalar o pacote do agente NGINX:
Se você não habilitou o mTLS em Instalar e configurar o API Connectivity Manager , adicione:
‑k
para o comando curl
--no-check-certificate
para o comando wget
<NMS_FQDN>
, substitua o endereço IP ou o nome de domínio totalmente qualificado do seu servidor NGINX Management Suite.<nome_do_cluster>
, substitua o nome do cluster de gateway de API apropriado (neste tutorial, aws-cluster-aplicativo
para a instância implantada na AWS e cluster gcp
para a instância implantada no GCP).$ enrolar [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <nome_do_cluster> && sudo systemctl iniciar nginx-agent
ou
$ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <nome_do_cluster> && sudo systemctl iniciar nginx-agent
A instância apropriada do NGINX Plus agora aparece na seção Instâncias das janelas Cluster para aws‑cluster (Figura 14) e gcp‑cluster (Figura 15).
Agora você pode adicionar políticas globais que se aplicam a todas as instâncias do NGINX Plus em um cluster do API Gateway. Por exemplo, para proteger o acesso do cliente às suas APIs, você pode aplicar a política OpenID Connect Relying Party ou TLS Inbound . Para proteger a conexão entre um gateway de API e o serviço de backend que expõe a API, aplique a política de backend TLS . Para obter mais informações sobre políticas de TLS, consulte a documentação do API Connectivity Manager .
Navegue até a guia Cluster do API Gateway onde você deseja aplicar uma política ( api-cluster na Figura 16). Clique no botão Gerenciar que fica acima do canto direito da tabela Políticas .
Clique em Políticas globais na coluna de navegação à esquerda e, em seguida, no ícone … na coluna mais à direita da linha da política ( TLS Backend na Figura 17). Selecione + Adicionar política no menu suspenso.
Gerenciar arquiteturas híbridas e multinuvem não é uma tarefa fácil. São ambientes complexos com aplicações que mudam rapidamente e que muitas vezes são difíceis de observar e proteger.
Com as ferramentas certas, no entanto, você pode evitar a dependência de fornecedores e, ao mesmo tempo, manter a agilidade e a flexibilidade necessárias para entregar novos recursos ao mercado com mais rapidez. Como uma ferramenta nativa da nuvem, o API Connectivity Manager da NGINX oferece a escalabilidade, a visibilidade, a governança e a segurança necessárias para gerenciar APIs em ambientes híbridos e de várias nuvens.
Inicie uma avaliação gratuita de 30 dias do NGINX Management Suite , que inclui acesso ao API Connectivity Manager , ao NGINX Plus como um gateway de API e ao NGINX App Protect para proteger suas APIs.
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."