Exemplo de Configurações de Recursos de Rede
Saiba mais sobre exemplos de como configurar recursos de rede para desenvolvimento de gateway de API.
Antes de usar o serviço API Gateway para criar gateways de API e implantar APIs neles como implantações de API:
- Você deve ter acesso a uma tenancy do Oracle Cloud Infrastructure. A tenancy deve estar inscrita em uma ou mais das regiões nas quais o serviço API Gateway está disponível (consulte Disponibilidade por Região).
-
Sua tenancy deve ter cota suficiente em recursos relacionados ao Gateway de API (consulte Limites do Serviço).
- Em sua tenancy, já deverá haver um compartimento para possuir os recursos de rede necessários. Se esse compartimento não existir ainda, você terá que criá-lo. Consulte Criar Compartimentos para Possuir os Recursos de Rede e os Recursos do Serviço API Gateway na Tenancy, se ainda não existirem.
- O compartimento que possui recursos de rede deve conter uma VCN, uma sub-rede regional pública ou privada e outros recursos (como um gateway de internet, uma tabela de roteamento, listas de segurança e/ou grupos de segurança de rede). Para garantir alta disponibilidade, os gateways de API só podem ser criados em sub-redes regionais (não sub-redes específicas do AD). Observe que um gateway de API deve atingir os back-ends definidos na especificação de implantação de API. Por exemplo, se o back-end estiver na internet pública, a VCN deverá ter um gateway de internet para permitir que o gateway de API roteie solicitações para o back-end.
-
A VCN deve ter um conjunto de opções de DHCP que inclua um resolvedor de DNS apropriado para mapear nomes de host definidos em uma especificação de implantação de API para endereços IP. Se esse conjunto de opções de DHCP já não existir na VCN, você terá que criá-lo. Selecione as opções de DHCP definidas para a sub-rede do gateway de API da seguinte forma:
- Se o nome do host for publicado publicamente na internet ou se o nome do host pertencer a uma instância na mesma VCN, selecione um conjunto de opções de DHCP que tenha Internet fornecida pela Oracle e Resolvedor de VCN como o Tipo de DNS. Este é o padrão se você não selecionar explicitamente um conjunto de opções de DHCP.
- Se o nome do host estiver em sua própria rede privada ou interna (por exemplo, conectado à VCN pelo FastConnect), selecione um conjunto de opções de DHCP que tenha Resolvedor Personalizado como o Tipo de DNS e tenha o URL de um servidor DNS adequado que possa resolver o nome do host para um endereço IP.
Observe que você pode alterar os detalhes do servidor DNS no conjunto de opções de DHCP especificado para a sub-rede de um gateway de API. O gateway de API será reconfigurado para usar os detalhes atualizados do servidor DNS em duas horas. Para obter mais informações sobre como resolver nomes de host para endereços IP, consulte DNS na Sua Rede Virtual na Nuvem e Opções de DHCP.
- Em sua tenancy, já deverá haver um compartimento para possuir recursos relacionados ao Gateway de API (gateways de API, implantações de API). Esse compartimento pode ser, mas não precisa ser, o mesmo compartimento que contém os recursos de rede. Consulte Criar Compartimentos para Possuir os Recursos de Rede e os Recursos do Serviço API Gateway na Tenancy, se ainda não existirem. Observe que os recursos relacionados ao Gateway de API podem residir no compartimento raiz. Porém, se você espera que várias equipes criem gateways de API, a prática recomendada é criar um compartimento separado para cada equipe.
-
Para criar gateways de API e implantar APIs neles, você deve pertencer a um dos seguintes:
- O grupo de Administradores da tenancy.
-
Um grupo ao qual as políticas concedem as permissões apropriadas para os recursos relacionados à rede e ao Gateway de API. Consulte Criar Políticas para Controlar o Acesso a Recursos Relacionados à Rede e ao Serviço API Gateway.
- As políticas devem ser definidas para fornecer aos gateways de API que você cria acesso a recursos adicionais, se necessário. Consulte Criar Políticas para Controlar o Acesso a Recursos Relacionados à Rede e ao Serviço API Gateway.
Este tópico fornece exemplos de como você pode configurar recursos de rede para gateways de API com uma função sem servidor como um backend:
- para um gateway de API pública em uma sub-rede pública (consulte Exemplo 1: Exemplo de Configuração de Recursos de Rede para um Gateway de API Pública em uma Sub-rede Pública com uma Função sem Servidor como um Backend de HTTP)
- para um gateway de API privada em uma sub-rede privada (consulte Exemplo 2: Configuração de Recursos de Rede para um Gateway de API Privada em uma Sub-rede Privada com uma Função sem Servidor como um Backend de HTTP)
Esses exemplos pressupõem que a função padrão helloworld tenha sido criada e implantada no OCI Functions com o nome helloworld-func e pertença ao aplicativo helloworld-app (consulte Criando, Implantando e Chamando uma Função Helloworld).
Os exemplos nesta seção mostram o uso de regras de segurança em listas de segurança para controlar o acesso. Se preferir grupos de segurança de rede em listas de segurança, você poderá especificar regras de segurança idênticas para grupos de segurança de rede.
Exemplo 1: Exemplo de Configuração de Recursos de Rede para um Gateway de API Pública em uma Sub-rede Pública com uma Função sem Servidor como um Backend de HTTP
Este exemplo pressupõe que você deseja que um gateway de API pública possa ser acessado diretamente pela internet, com uma função sem servidor, como um backend de HTTP.
Para alcançar esse exemplo de configuração, crie os seguintes recursos na sequência mostrada, com as propriedades mostradas na tabela Configuração de Exemplos de Recursos a seguir:
- Uma VCN chamada 'acme-vcn1'.
- Um gateway de internet chamado 'acme-internet-gateway'.
- Uma tabela de roteamento chamada 'acme-routetable-public'.
- Uma lista de segurança chamada 'acme-security-list-public', com uma regra de entrada que permite acesso público ao gateway de API e uma regra de saída que permite acesso ao OCI Functions.
- Uma sub-rede pública denominada 'acme-public-subnet'.
- Um gateway de API chamado 'acme-public-gateway', com uma implantação de API chamada 'acme-public-deployment'.
A emissão de um comando curl pela internet pública conforme a implantação da API retorna a resposta mostrada:
[user@machinename ~]$ curl -X GET https://lak...sjd.apigateway.us-phoenix-1.oci.customer-oci.com/marketing/hello
Hello, world!Exemplo de Configuração de Recursos de Rede
| Recurso | Exemplo |
|---|---|
| VCN |
Criado manualmente e definido da seguinte forma:
|
| Gateway de Internet |
Criado manualmente e definido da seguinte forma:
|
| Tabela de Roteamento |
Uma tabela de roteamento criada manualmente, nomeada e definida da seguinte forma:
|
| Opções de DHCP |
Criado automaticamente e definido da seguinte forma:
|
| Lista de Segurança |
Uma lista de segurança criada manualmente (além da lista de segurança padrão), nomeada e definida da seguinte forma:
|
| Sub-rede |
Uma sub-rede regional criada manualmente, nomeada e definida da seguinte forma:
|
| Gateway de API |
Um gateway de API pública criado e definido da seguinte forma:
|
| Implantação de API |
Uma implantação de API criada e definida da seguinte forma:
|
Exemplo 2: Configuração de Recursos de Rede para um Gateway de API Privada em uma Sub-rede Privada com uma Função sem Servidor como um Backend HTTP
Este exemplo pressupõe que você deseja que um gateway de API privada só possa ser acessado por meio de um bastion host (em vez de acessado diretamente da internet), com uma função sem servidor como um backend HTTP.
Para alcançar esse exemplo de configuração, crie os seguintes recursos na sequência mostrada, com as propriedades mostradas na tabela Configuração de Exemplos de Recursos a seguir:
- Uma VCN chamada acme-vcn2
- Um gateway de internet chamado acme-internet-gateway
- Um gateway de serviço chamado acme-service-gateway. (Neste exemplo, você só precisa criar um gateway de serviço porque o gateway de API só tem um back-end do OCI Functions. No entanto, se o gateway de API tiver um back end do OCI Functions e também um back end HTTP na internet pública, você poderá criar um gateway NAT em vez de acessar os dois back end.)
- Uma tabela de roteamento chamada acme-routetable-private
- Uma lista de segurança chamada acme-security-list-private, com uma regra de entrada que permite que o bastion host acesse o gateway de API e uma regra de saída que permite acesso ao OCI Functions.
- Uma sub-rede privada denominada acme-private-subnet
- Um gateway de API chamado acme-private-gateway, com uma implantação de API chamada acme-private-deployment
- Uma tabela de roteamento chamada acme-routetable-bastion
- Uma lista de segurança chamada de acme-security-list-bastion, com uma regra de entrada que permite acesso SSH público ao bastion host e uma regra de saída que permite que o bastion host acesse o gateway de API.
- Uma sub-rede pública denominada acme-bastion-public-subnet
- Uma instância de computação com um endereço IP público para atuar como bastion host, chamado de acme-bastion-instance
Partindo do princípio de que o SSH foi utilizado no bastion host, a emissão de um comando curl na implantação da API retorna a resposta mostrada:
[user@machinename ~]$ ssh opc@198.51.100.254
[opc@acme-bastion-instance ~]$ curl -X GET https://pwa...djt.apigateway.us-phoenix-1.oci.customer-oci.com/marketing-private/hello
Hello, world!Exemplo de Configuração de Recurso
| Recurso | Exemplo |
|---|---|
| VCN |
Criado manualmente e definido da seguinte forma:
|
| Gateway de Internet |
Criado manualmente e definido da seguinte forma:
|
| Gateway de Serviço |
Criado manualmente e definido da seguinte forma:
|
| Tabelas de Roteamento |
Duas tabelas de roteamento criadas manualmente, nomeadas e definidas da seguinte forma:
|
| Opções de DHCP |
Criado automaticamente e definido da seguinte forma:
|
| Lista de Segurança |
Duas listas de segurança criadas manualmente (além da lista de segurança padrão), nomeadas e definidas da seguinte forma:
|
| Sub-rede |
Duas sub-redes regionais criadas manualmente, nomeadas e definidas da seguinte forma:
|
| Gateway de API |
Um gateway de API privada criado e definido da seguinte forma:
|
| Implantação de API |
Uma implantação de API criada e definida da seguinte forma:
|
| Instância |
Uma instância de computação criada e definida da seguinte forma:
|