Neste documento, descrevemos como instalar e configurar a Apigee a partir da linha de comando com peering de VPC. Essas etapas se aplicam aos modelos de preços de assinatura e pagamento por uso para organizações pagas
com ou sem a residência de dados ativada.
Resumo das etapas
As etapas de provisionamento são as seguintes:
Etapa 1: definir as variáveis de ambiente:
configure o gcloud e defina as variáveis de ambiente.
A Google Cloud CLI gerencia a autenticação, a configuração local,
o fluxo de trabalho do desenvolvedor e as interações com as APIs do Google Cloud.
Etapa 2: ativar APIs: a Apigee requer a ativação de várias
APIs do Google Cloud.
Etapa 4: configurar a rede de serviços: a rede de serviços
automatiza a configuração de conectividade particular (usando peering de rede VPC) entre sua rede
e a Apigee.
Etapa 5: criar uma organização: uma organização da Apigee
(às vezes chamada de organização) é o contêiner de nível superior da Apigee. Ela inclui todos os
ambientes e grupos de ambientes, usuários, proxies de API e recursos relacionados.
Etapa 6: criar uma instância de ambiente de execução: uma instância ou ambiente de execução
é o local em que seu projeto e os serviços relacionados são armazenados. Ela fornece o endpoint voltado ao usuário
para seus serviços.
Etapa 7: criar um ambiente: um proxy de API precisa ser
implantado em um ambiente e adicionado a um grupo de ambientes antes que as APIs expostas
fiquem acessíveis pela rede.
Configure gcloud e defina variáveis de ambiente para uso em etapas posteriores:
Verifique se você cumpre os requisitos de configuração listados em Antes de começar.
É preciso ter o SDK do Cloud instalado. Se você precisar instalá-lo, consulte Como instalar o SDK Cloud.
Inicialize o SDK Cloud, conforme descrito em Como inicializar a gcloud CLI ou garanta que o projeto do Google Cloud criado em Pré-requisitos é o projeto padrão para gcloud.
Defina as variáveis de ambiente a seguir no terminal de comando.
Selecione a guia que corresponde ao tipo de organização de que você precisa: Sem residência de dados ou com Residência de dados:
AUTH define o cabeçalho Authentication com um token do portador.
Você usará esse cabeçalho ao chamar as APIs Apigee. O token expira após um certo tempo. Quando isso acontecer, basta gerar o token novamente usando o mesmo comando. Saiba mais na página de referência do comando print-access-token.
PROJECT_ID é o ID do projeto do Cloud que você criou como parte dos Pré-requisitos.
PROJECT_NUMBER é o número do projeto do Cloud que você criou como parte dos Pré-requisitos.
RUNTIME_LOCATION é o local físico em que a instância da Apigee que você criará está localizada. Para conferir uma lista de locais disponíveis para o ambiente de execução, consulte Locais da Apigee.
ANALYTICS_REGION é o local físico em que os dados de análise da Apigee são armazenados. Para ver uma lista de regiões disponíveis do Apigee API Analytics, consulte Locais da Apigee.
RUNTIME_LOCATION e RUNTIME_LOCATION podem ser a mesma região, mas não precisam ser os mesmos.
BILLING_TYPE é o tipo de faturamento da organização criada. Os valores válidos são:
AUTH define o cabeçalho Authentication com um token do portador.
Você usará esse cabeçalho ao chamar as APIs Apigee. O token expira após um certo tempo. Quando isso acontecer, basta gerar o token novamente usando o mesmo comando. Saiba mais na página de referência do comando print-access-token.
PROJECT_ID é o ID do projeto do Cloud que você criou como parte dos Pré-requisitos.
PROJECT_NUMBER é o número do projeto do Cloud que você criou como parte dos Pré-requisitos.
RUNTIME_LOCATION é o local físico em que a instância da Apigee que você criará está localizada. Para conferir uma lista de locais disponíveis para o ambiente de execução, consulte Locais da Apigee.
O local do ambiente de execução precisa estar no local do plano de controle.
CONTROL_PLANE_LOCATION é o local físico em que os dados do plano de controle da Apigee serão armazenados.
Para ver uma lista de locais disponíveis do plano de controle, consulte Locais da Apigee.
CONSUMER_DATA_REGION é uma sub-região da região do plano de controle. Você precisa especificar CONTROL_PLANE_LOCATION e CONSUMER_DATA_REGION.
Para ver uma lista de regiões de dados do consumidor disponíveis, consulte Locais da Apigee.
BILLING_TYPE é o tipo de faturamento da organização criada. Os valores válidos são:
(Opcional) Verifique seu trabalho incluindo os valores que você acabou de definir. Quando quiser
usar uma variável nos comandos, coloque o cifrão
($) antes do nome dela.
As respostas aos comandos echo precisam ser semelhantes a estas:
YOUR_TOKEN
my-cloud-project
1234567890
us-west1
us
us-west1
SUBSCRIPTION
Etapa 2: ativar as APIs
Permissões exigidas para a tarefa
É possível conceder ao provisionador da Apigee um papel predefinido que inclua as permissões necessárias para realizar essa tarefa ou conceder permissões mais refinadas a fim de fornecer o privilégio mínimo necessário. Consulte Papéis predefinidos e Permissões de ativação de API.
A Apigee requer a ativação de várias APIs do Google Cloud. Ative as APIs executando o seguinte comando services enable:
Verifique se o agente foi criado com sucesso. A resposta precisa mostrar o nome do
agente no seguinte formato:
service-PROJECT_NUMBER@gcp-sa-apigee.iam.gserviceaccount.com.
por exemplo:
Service identity created: service-1234567890@gcp-sa-apigee.iam.gserviceaccount.com
Etapa 4: configurar a rede de serviços
Nesta etapa, você aloca um par de intervalos de endereços IP (um intervalo CIDR /22 e /28) para a Apigee e
executa o peering de VPC entre sua rede e a rede da Apigee. Cada instância da Apigee
requer um intervalo CIDR não sobreposto de /22 e /28. O endereço do ambiente de execução da Apigee
recebe endereços IP desse intervalo CIDR. Como resultado, é
importante que o intervalo seja reservado para a Apigee e não usado por outros
aplicativos na rede VPC do cliente. Para mais informações e considerações importantes, consulte Noções básicas sobre intervalos de peering.
Observe que você está criando um intervalo de IP de rede suficiente para uma instância da Apigee. Se você planeja
criar outras instâncias da Apigee, repita essa etapa para cada uma. Os intervalos
não podem ser compartilhados entre instâncias. Consulte também
Como expandir a Apigee para várias regiões.
Permissões exigidas para a tarefa
É possível conceder ao provisionador da Apigee um papel predefinido que inclua as permissões necessárias para realizar essa tarefa ou conceder permissões mais refinadas a fim de fornecer o privilégio mínimo necessário. Consulte Papéis predefinidos
e Permissões de rede de serviços.
RANGE_NAME é o nome do intervalo de endereços IP que você está criando.
Você dá o nome que quiser a ele. Por exemplo: google-svcs
NETWORK_NAME é o nome do recurso de rede em que os endereços precisam ser reservados.
O Google cria uma rede padrão (chamada default) para cada novo projeto, para que você possa usar isso. No entanto, o Google não recomenda usar a rede padrão para qualquer finalidade que não seja teste.
Crie um intervalo de IP de rede com um comprimento CIDR de /22:
Em que --addresses permite especificar um intervalo de endereços. Por exemplo, para alocar o bloco CIDR 192.168.0.0/22, especifique 192.168.0.0 como endereço e 22 como tamanho de prefixo. Consulte também Como criar uma alocação de IP.
Se você não fornecer o parâmetro --addresses, a gcloud selecionará um intervalo de endereços disponível.
Em caso de sucesso, gcloud responderá com o seguinte:
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/addresses/google-svcs].
Depois que você criar um intervalo de endereços IP, os endereços serão associados ao
projeto até que você os libere.
Verifique se o intervalo de IPs da rede foi criado com um comprimento CIDR de /22:
Crie um intervalo de IP de rede com um comprimento CIDR de /28. Esse intervalo é obrigatório e é usado pela Apigee para solução de problemas e não pode ser personalizado ou alterado.
Em que --addresses permite especificar um intervalo de endereços. Por exemplo, para alocar o bloco CIDR 192.168.0.0/28, especifique 192.168.0.0 como endereço e 28 como tamanho de prefixo. Consulte também Como criar uma alocação de IP.
Se você não fornecer o parâmetro --addresses, a gcloud selecionará um intervalo de endereços disponível.
Verifique se o intervalo de IPs da rede foi criado com um comprimento CIDR de /28:
A Apigee cria uma conexão entre sua VPC e os serviços do Google. Especificamente,
a Apigee conecta seu projeto à API Service Networking usando o peering de VPC. A Apigee também associa os endereços IP ao seu projeto.
Após alguns minutos, verifique se o peering de VPC foi bem-sucedido:
gcloud services vpc-peerings list \
--network=$NETWORK_NAME \
--service=servicenetworking.googleapis.com \
--project=$PROJECT_ID
Etapa 5: criar uma organização
Permissões exigidas para a tarefa
É possível conceder ao provisionador da Apigee um papel predefinido que inclui as permissões necessárias para concluir essa tarefa ou conceder permissões mais refinadas para fornecer o privilégio mínimo necessário. Veja estes tópicos:
Antes de criar uma organização, crie um keyring e uma chave de criptografia de banco de dados de ambiente de execução (consulte a etapa 1) e, se estiver usando a residência de dados, os keyrings e as chaves de criptografia do plano de controle (consulte a etapa 2). Essas chaves do Cloud KMS criptografam dados que são armazenados e replicados nos locais do plano de controle e do ambiente de execução. A Apigee usa essas entidades para criptografar dados de aplicativos, como KVMs, cache e chaves secretas do cliente, que são armazenados no banco de dados. Para mais informações, consulte Sobre as chaves de criptografia da Apigee.
Crie um keyring e uma chave de criptografia do banco de dados do ambiente de execução.
Defina uma variável de ambiente para o local do keyring e da chave de criptografia do banco de dados do ambiente de execução. Isso ajuda a garantir a consistência quando na criação e
facilita o acompanhamento na documentação.
O valor é o local físico em que o keyring e a chave de criptografia do banco de dados são armazenados.
Região única
Configurações de região única, em que você tem apenas uma instância
em uma região: escolha entre os locais
regionais do KMS.
Exemplo:
RUNTIMEDBKEY_LOCATION="us-west1"
O valor pode ser o mesmo que $RUNTIME_LOCATION (também uma região), mas
não precisa ser. No entanto, isso poderá resultar em uma melhoria no desempenho.
Se você tiver uma configuração multirregional nos EUA, recomendamos usar
us como seu local, se possível. Do contrário, use nam4.
Defina variáveis de ambiente para keyrings e nomes de chaves de bancos de dados.
O nome do keyring precisa ser exclusivo para sua organização. Se você criar uma
segunda ou uma região subsequente, o nome não poderá ser igual ao de outros
keyrings.
(Opcional) Verifique seu trabalho incluindo os valores que você acabou de definir. Quando quiser usar uma
variável nos comandos, lembre-se de colocar o cifrão
($) antes do nome da variável.
Esse comando vincula a chave ao agente de serviços da Apigee.
Após a conclusão dessa solicitação, gcloud responde com algo semelhante
ao seguinte:
Updated IAM policy for key [runtime].
bindings:
- members:
- serviceAccount:service-1234567890@gcp-sa-apigee.iam.gserviceaccount.com
role: roles/cloudkms.cryptoKeyEncrypterDecrypter
etag: BwWqgEuCuwk=
version: 1
Se você receber um erro como este:
INVALID_ARGUMENT: Role roles/cloudkms.cryptokms.cryptoKeyEncrypterDecrypter is not supported for this resource.
Verifique se você usou o número do projeto e não o nome do projeto
no endereço de e-mail da conta de serviço.
Se você estiver usando a residência de dados, crie um keyring e uma chave de criptografia de plano de controle. Se você não estiver usando a residência de dados, avance para a etapa 3.
Siga as etapas a seguir para criar um keyring e uma chave de criptografia de plano de controle.
Defina uma variável de ambiente para o local do keyring e da chave de criptografia do banco de dados do plano de controle:
CONTROL_PLANE_LOCATION é o local físico em que os dados do plano de controle da Apigee serão armazenados.
Para ver uma lista de locais disponíveis do plano de controle, consulte Locais da Apigee.
CONSUMER_DATA_REGION é uma sub-região da região do plano de controle. Você precisa especificar CONTROL_PLANE_LOCATION e CONSUMER_DATA_REGION.
Para ver uma lista de regiões de dados do consumidor disponíveis, consulte Locais da Apigee.
Defina variáveis de ambiente para os nomes de chaves e keyrings do banco de dados do plano de controle.
O nome do keyring precisa ser exclusivo para sua organização.
runtimeDatabaseEncryptionKeyName: o ID da chave de criptografia do
aplicativo que você criou na etapa anterior. Lembre-se de que o ID é estruturado
como um caminho de arquivo. Por exemplo: projects/my-project/locations/us-west1/keyRings/my-key-ring/cryptoKeys/my-key
-d define o payload de dados para a solicitação. Esse payload precisa incluir os seguintes dados:
name: identifica a nova organização. Ele precisa ter o mesmo
nome do ID do projeto.
runtimeType: Defina esse valor como CLOUD.
billingType: especifica o tipo de faturamento da organização criado.
controlPlaneEncryptionKeyName: é o ID da chave do plano de controle.
apiConsumerDataLocation: também é preciso especificar uma sub-região para uso de recursos internos. Consulte Regiões de residência de dados para conferir os valores aceitos.
apiConsumerDataEncryptionKeyName: é o ID da chave da região de dados do consumidor.
runtimeDatabaseEncryptionKeyName: o ID da chave de criptografia do
aplicativo que você criou na etapa anterior. O ID é estruturado como um caminho de arquivo. Por exemplo: projects/my-project/locations/us-west1/keyRings/my-key-ring/cryptoKeys/my-key
Depois que você executar esse comando, a Apigee iniciará uma operação de longa duração, que pode levar alguns minutos para ser concluída.
Se você receber um erro, verifique se colocou os valores das variáveis entre
aspas no payload de dados. Coloque a variável $PROJECT_ID entre aspas duplas e
simples, conforme mostrado no exemplo a seguir:
"'"$PROJECT_ID"'"
Se você usar strings simples (não variáveis de ambiente) como valores de solicitação, coloque-as
entre aspas duplas dentro da
string de payload entre aspas simples, como no exemplo abaixo:
'{ "name":"my-gcp-project", ... }'
Aguarde alguns minutos.
Para verificar o status da solicitação de criação, envie uma solicitação GET para a
API List organizations da Apigee, como no exemplo abaixo:
Se você vir essa resposta, a criação da organização ainda não foi concluída:
{
"error": {
"code": 403,
"message": "Permission denied on resource \"organizations/apigee-docs-m\" (or it may not exist)",
"status": "PERMISSION_DENIED"
}
}
Se a Apigee tiver criado uma nova organização, você receberá uma resposta
semelhante a esta:
Etapa 6: criar uma instância de ambiente de execução
Permissões exigidas para a tarefa
É possível conceder ao provisionador da Apigee um papel predefinido que inclua as permissões necessárias para realizar essa tarefa ou conceder permissões mais refinadas a fim de fornecer o privilégio mínimo necessário. Consulte Papéis predefinidos e Permissões de instância do ambiente de execução.
Uma instância de ambiente de execução é onde seu projeto da Apigee e os serviços relacionados são armazenados. Ela fornece o endpoint voltado ao usuário para seus serviços. Para criar uma nova instância de ambiente de execução:
Verifique se a Apigee terminou de criar sua organização. Você enviou uma solicitação para criar uma nova organização em Criar uma organização da Apigee, mas é preciso verificar se ela está concluída antes de continuar.
Se a organização existir e você tiver as permissões adequadas para visualizá-la, a Apigee responderá
com detalhes sobre ela. Se a Apigee responder com um erro, aguarde alguns minutos e envie a solicitação novamente.
Assim como na tarefa anterior, em que foi criada uma chave de criptografia para o banco de dados, agora você precisa criar uma chave do Cloud KMS usada para criptografar dados do lado do servidor.
Para começar, defina as seguintes variáveis de ambiente:
INSTANCE_NAME: o nome da sua nova instância. Por exemplo, my-runtime-instance. O nome precisa começar com uma letra minúscula, ter até 32 caracteres e incluir apenas letras minúsculas, números e hífens. Ele não pode começar nem terminar com um hífen e precisa ter pelo menos dois caracteres.
RUNTIME_LOCATION é o lugar físico em que o cluster está hospedado.
Os valores válidos são qualquer local permitido pelo Compute Engine. Consulte regiões e zonas disponíveis. O exemplo usa us-west1.
DISK_KEY_RING_NAME é o nome do keyring de criptografia do disco.
DISK_KEY_NAME é o nome da chave de criptografia do disco.
consumerAcceptList (opcional) especifica uma lista de IDs de projetos do Google Cloud que podem se conectar de maneira particular ao anexo de serviço da VPC da Apigee. O anexo de serviço é uma entidade usada com o Private Service Connect do Google Cloud para permitir que os produtores de serviços (neste caso, a Apigee) exponham serviços aos consumidores (neste caso, um ou mais projetos do Cloud que pertencem a você).
Por padrão, usamos o projeto do Cloud que já está associado à sua organização da Apigee. Por exemplo: "consumerAcceptList": ["project1", "project2", "project3"]
Também é possível definir e alterar a lista de projetos aceitos na interface da instância. Para mais detalhes, consulte Como gerenciar instâncias.
Essa solicitação pode levar até 20 minutos para ser concluída porque a Apigee precisa criar e
iniciar um novo cluster do Kubernetes, instalar os recursos da Apigee nesse cluster e configurar
o balanceamento de carga.
Para ver o status da solicitação de criação da instância de ambiente de execução, execute o comando
a seguir. Quando o estado for ACTIVE, avance para a próxima etapa.
Sem residência de dados
curl -i -X GET -H "Authorization: Bearer $AUTH" \
"https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances/$INSTANCE_NAME"
Residência dos dados
curl -i -X GET -H "Authorization: Bearer $AUTH" \
"https://$CONTROL_PLANE_LOCATION-apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances/$INSTANCE_NAME"
Etapa 7: criar um ambiente
Permissões exigidas para a tarefa
É possível conceder ao provisionador da Apigee um papel predefinido que inclui as permissões necessárias para concluir essa tarefa ou conceder permissões mais refinadas para fornecer o privilégio mínimo necessário. Veja estes tópicos:
Para criar um ambiente e anexá-lo ao ambiente de execução na linha
de comando:
Defina as variáveis de ambiente a serem usadas nesta seção: As variáveis específicas de ambiente que você cria dependem de se você está criando um ambiente para uma assinatura ou um pagamento por utilização.
org.
Assinatura
Para um ambiente de assinatura, crie estas variáveis:
ENVIRONMENT_NAME é um nome de string. Por exemplo: test
ENVIRONMENT_TYPE é o tipo desse ambiente e só é aplicável a usuários de Pay-as-you-go, que precisam especificar um destes valores: BASE, INTERMEDIATE ou COMPREHENSIVE. Outros usuários precisam omitir o tipo de ambiente.
ENV_GROUP_NAME é um nome de string. Por exemplo: test-group
ENV_GROUP_HOSTNAME é um nome de host de domínio válido. Por exemplo: foo.example.com
Crie um novo ambiente com os Ambientes API Os comandos específicos que você usa
dependerão da criação de um ambiente para uma organização de assinatura ou
de pagamento por uso.
Assinatura
Para um novo ambiente de assinatura, use o seguinte
comando:
Nesta etapa, você vai configurar a comunicação dos aplicativos clientes com a Apigee. O tráfego do cliente para a Apigee
também é chamado de tráfego "norte". As opções de configuração na direção norte são as seguintes.
Acesse a opção de configuração que quer usar e execute as etapas para essa opção:
Tipo de acesso
Descrição do processo de configuração e implantação
Use um grupo de instâncias gerenciadas (MIG, na sigla em inglês) para enviar
tráfego de API de um serviço de back-end do balanceador de carga global para a Apigee. Com essa configuração, a Apigee só pode se
conectar à VPC com peering. Essa configuração permite enviar solicitações de proxy da API Apigee de qualquer
máquina ativada para rede.
Permita apenas o acesso interno aos proxies da API de qualquer um dos seus projetos do Google Cloud usando o
Private Service Connect (PSC).
O PSC permite uma conexão particular entre um produtor de serviços (Apigee) e um consumidor de serviço (o projeto VPC com peering e/ou um ou mais projetos do Cloud que você controla). Com esse método, as solicitações passam por um endpoint de serviço ou um balanceador de carga regional interno para um único ponto de anexo, chamado de anexo de serviço.
Essa configuração permite que os clientes internos enviem
solicitações de proxy da API da Apigee de qualquer máquina ativada para rede.
Use o Private Service Connect (PSC) para ativar a conexão particular entre
um produtor de serviços (Apigee) e um consumidor de serviço (o projeto VPC com peering e/ou
um ou mais projetos do Cloud que você controla). Com esse método, as solicitações são transmitidas por um balanceador de carga externo global ou regional para um único ponto de anexo, chamado anexo de serviço.
Essa configuração permite enviar
solicitações de proxy de API da Apigee de qualquer
máquina ativada para rede.
Cada uma destas abordagens de roteamento é apresentada nas instruções abaixo.
Roteamento interno (VPC)
Para encaminhar o tráfego de clientes internos para a Apigee, escolha usar o encerramento do TLS ou não:
Opções de TLS: você tem duas opções se quiser fazer chamadas de proxy de API de clientes internos com o TLS ativado:
(Opção 1) Configurar um balanceador de carga interno (ILB):
Criar um grupo gerenciado de instâncias (MIG, na sigla em inglês) no projeto. Para criar o MIG, siga as etapas 8a, 8b e 8c na guia Roteamento externo (MIG).
(Opção 2) Usar o nome de domínio totalmente qualificado interno padrão e o IP do balanceador de carga
interno da instância da Apigee. Este caso é recomendado apenas para testes e não para um ambiente de produção. Nesse caso, os certificados autoassinados criados pela Apigee são usados com o balanceador de carga interno da Apigee, e não é possível alterá-los. Consulte Como chamar um proxy de API com acesso somente interno.
Opção não TLS: se você não precisar ativar o término de TLS, poderá chamar proxies de API
em que o cliente desativar a TLS. Por exemplo, usando a opção -k com
cURL, é possível desativar o TLS. Consulte Como chamar um proxy de API com acesso somente interno.
Roteamento externo (MIG)
Nesta seção, descrevemos como configurar o roteamento para permitir o acesso externo
a proxies de API usando um grupo gerenciado de instâncias (MIG, na sigla em inglês) para enviar o tráfego de API de um serviço de back-end de balanceador de carga global para a Apigee. É necessário fazer
isso para enviar uma solicitação de um cliente externo à instância de ambiente de execução da
Apigee.
Permissões exigidas para a tarefa
É possível conceder ao provisionador da Apigee um papel predefinido que inclui as permissões necessárias para concluir essa tarefa
ou conceder permissões mais refinadas para fornecer o privilégio mínimo necessário.
Consulte Papéis predefinidos e Permissões de roteamento de acesso.
Nas instruções desta seção, usamos variáveis de ambiente para fazer referência às strings usadas
várias vezes. Recomendamos que você defina essas variáveis antes de continuar:
MIG_NAME=apigee-mig-MIG_NAME # You can choose a different name if you like
VPC_NAME=default # If you are using a shared VPC, use the shared VPC nameVPC_SUBNET=default # Private Google Access must be enabled for this subnetREGION=RUNTIME_REGION # The same region as your Apigee runtime instanceAPIGEE_ENDPOINT=APIGEE_INSTANCE_IP # See the tip below for details on getting this IP address value
Você usará essas variáveis várias vezes durante os processos restantes. Se você quiser configurar várias regiões, crie variáveis com valores específicos para cada região.
Etapa 8c: criar um grupo gerenciado de instâncias
Nesta etapa, você cria e configura um grupo gerenciado de instâncias (MIG, na sigla em inglês). Em uma etapa posterior,
você adicionará o MIG a um serviço de back-end conectado a um balanceador de carga global. Um MIG é
necessário para enviar o tráfego da API do serviço de back-end do balanceador de carga global para a Apigee.
Como você vê neste comando, as máquinas são do tipo e2-medium. Elas executam o Debian 12 e têm 20 GB de disco. O script startup-script.sh configura o MIG para rotear o tráfego de entrada do balanceador de
carga para a instância da Apigee.
Etapa 8d: criar um certificado SSL e uma chave para o balanceador de carga
Você só precisa criar as credenciais uma vez, esteja
instalando em uma ou várias regiões. Em um futuro passo, você vai associar essas credenciais
ao proxy HTTPS de destino do balanceador de carga.
É possível criar as credenciais com:
Seu próprio certificado de uma autoridade certificadora
Defina DOMAIN_HOSTNAME como um nome de host de domínio válido que você registrou. Em uma etapa futura, você vai receber o endereço IP do balanceador de carga e atualizar o registro A para apontar para esse endereço. Por exemplo, um nome de host de domínio
pode ter esta aparência: foo.example.com.
Use essa verificação de integridade para garantir a execução do serviço de back-end. Para
configurar verificações de integridade mais avançadas em relação a um proxy específico, consulte
Como executar verificações de integridade.
Etapa 8f: conseguir um endereço IP reservado e criar regras de firewall
Atribua um endereço IP ao balanceador de carga e crie regras que permitam
que o balanceador de carga acesse o MIG. Essa etapa só precisa ser feita uma vez, seja na instalação em uma ou várias regiões.
Etapa importante: acesse o site, o host DNS ou o ISP em que seus registros DNS são gerenciados e verifique se
o registro DNS de seu domínio está resolvido para o endereço IP do balanceador de carga do Google
Cloud. Esse endereço é o valor do IP retornado na última etapa. Saiba mais em
Atualizar os registros DNS A e AAAA para apontar para o endereço IP do balanceador de carga.
Crie uma regra de firewall que permita que o balanceador de carga acesse o MIG usando o
comando a seguir:
gcloud compute firewall-rules create FIREWALL_RULE_NAME \
--description "Allow incoming from GLB on TCP port 443 to Apigee Proxy" \
--project $PROJECT_ID --network $VPC_NAME --allow=tcp:443 \
--source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gke-apigee-proxy
Os intervalos de endereços IP 130.211.0.0/22 e 35.191.0.0/16 são os intervalos de endereços IP de origem do Google Load Balancing. Essa regra de firewall permite que o Google Cloud Load Balancing
faça solicitações de verificação de integridade ao MIG.
Nesta seção, explicamos como permitir apenas o acesso interno aos proxies de API de qualquer projeto do Google Cloud usando o Private Service Connect (PSC).
Você tem duas opções para configurar o acesso interno com o PSC:
Endpoint de serviço: as solicitações são transmitidas por um endpoint de serviço para um único ponto de anexo, chamado anexo de serviço.
Balanceador de carga regional interno: as solicitações passam por um balanceador de carga HTTP(S) regional interno. Consulte também Balanceamento de carga global vs. regional.
Selecione a guia abaixo para a configuração que você escolheu e siga as etapas:
Endpoint de serviço
Permissões exigidas para a tarefa
É possível conceder ao provisionador da Apigee um papel predefinido que inclui as permissões necessárias para concluir essa tarefa ou conceder permissões mais refinadas para fornecer o privilégio mínimo necessário.
Consulte Papéis predefinidos e Permissões de roteamento de acesso.
Criação de um endpoint de serviço do PSC para o anexo de serviço
Consiga o anexo de serviço da instância criada anteriormente:
Sem residência de dados
curl -i -X GET -H "Authorization: Bearer $AUTH" \
"https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"
Residência dos dados
curl -i -X GET -H "Authorization: Bearer $AUTH" \
"https://$CONTROL_PLANE_LOCATION-apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"
No exemplo de saída a seguir, o valor serviceAttachment é mostrado em negrito:
Crie um endpoint de serviço do PSC que aponte para o anexo de serviço que você recebeu do corpo de resposta da instância na etapa anterior, conforme explicado em Criar um endpoint do Private Service Connect.
É possível conceder ao provisionador da Apigee um papel predefinido que inclui as permissões necessárias para concluir essa tarefa
ou conceder permissões mais refinadas para fornecer o privilégio mínimo necessário.
Consulte Papéis predefinidos
e Permissões de roteamento de acesso.
Etapa 8a: configurar as variáveis de ambiente
Nas instruções desta seção, usamos variáveis de ambiente para fazer referência às strings usadas
várias vezes. Verifique se você definiu as variáveis em Definir variáveis de ambiente.
Além disso, defina as variáveis de ambiente a seguir:
NEG_NAME: um nome para o grupo de endpoints de rede.
TARGET_SERVICE: o anexo de serviço ao qual você quer se conectar. Por exemplo: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
NETWORK_NAME (opcional): nome da rede em que o NEG foi criado. Se você omitir esse parâmetro, a rede do projeto default será usada.
SUBNET_NAME: nome da sub-rede usada para conectividade particular com o produtor.
O tamanho da sub-rede pode ser pequeno: o NEC PSC só precisa de um IP da sub-rede.
Para a Apigee, apenas um NEG de PSC é necessário por região. A sub-rede pode ser compartilhada e usada por VMs ou outras entidades.
Se uma sub-rede não for especificada, os endpoints de rede poderão pertencer a qualquer sub-rede da região em que o grupo de endpoints de rede for criado.
BACKEND_SERVICE_NAME pelo nome do serviço de back-end.
Para criar um balanceador de carga HTTPS, você precisa ter um recurso de certificado SSL para usar no proxy de destino HTTPS.
Use este comando para criar um recurso de certificado SSL autogerenciado. Para criar um certificado SSL autogerenciado, você precisa de um arquivo de chave privada local e de um arquivo de certificado local. Se você precisar criar esses arquivos, consulte a etapa 1 de usar certificados SSL autogerenciados.
DEFAULT_BACKEND_SERVICE_NAME: o nome do serviço de back-end padrão do balanceador de carga.
O padrão é usado quando nenhuma regra de host corresponde ao nome do host solicitado.
Use o recurso de certificado SSL para criar um proxy de destino HTTPS.
Nesta seção, descrevemos como configurar o roteamento externo usando o Private Service Connect (PSC, na sigla em inglês) para
permitir a comunicação entre a Apigee e as VPCs que você controla. É necessário fazer isso para poder enviar uma solicitação de um cliente externo à instância de ambiente de execução da Apigee.
Permissões exigidas para a tarefa
É possível conceder ao provisionador da Apigee um papel predefinido que inclui as permissões necessárias para concluir essa tarefa
ou conceder permissões mais refinadas para fornecer o privilégio mínimo necessário.
Consulte Papéis predefinidos e Permissões de roteamento de acesso.
Etapa 8b: criar um NEG e configurar o balanceador de carga
É possível criar um balanceador de carga regional ou global.
NEG_NAME: um nome para o grupo de endpoints da rede.
TARGET_SERVICE: o anexo de serviço ao qual você quer se conectar. Use o valor do anexo do serviço retornado pelo comando anterior. Por exemplo:
projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
NETWORK_NAME: (opcional) nome da rede em que o NEG foi criado. Se você omitir
esse parâmetro, a rede do projeto default será usada.
SUBNET_NAME: nome da sub-rede usada para conectividade particular com o produtor.
O tamanho da sub-rede pode ser pequeno: o NEC PSC só precisa de um IP da sub-rede.
Para a Apigee, apenas um NEG de PSC é necessário por região. A sub-rede pode ser compartilhada e usada por VMs ou
outras entidades.
Se uma sub-rede não for especificada, os endpoints de rede poderão pertencer a qualquer sub-rede da região em que o grupo de endpoints de rede for criado.
$PROJECT_ID é o projeto do Cloud que já está associado à organização da Apigee ou um projeto do Cloud incluído no consumerAcceptlist quando a instância de ambiente de execução da Apigee foi criada.
Se você ainda não fez isso, crie uma variável de ambiente para manter o ID do projeto, porque ela é usada na maioria dos comandos a seguir.
Reserve um endereço IPv4 externo global para o balanceador de carga.
DEFAULT_BACKEND_SERVICE_NAME: o nome do serviço de back-end padrão do balanceador de carga.
O padrão é usado quando nenhuma regra de host corresponde ao nome do host solicitado.
Crie o proxy de destino HTTPS.
Para criar um balanceador de carga HTTPS, você precisa ter um recurso de certificado SSL para usar no proxy de destino HTTPS. É possível criar um recurso de certificado SSL usando um certificado SSL gerenciado pelo Google ou um certificado SSL autogerenciado. O uso de certificados gerenciados pelo Google é recomendado porque o Google Cloud recebe, gerencia e renova esses certificados automaticamente.
DOMAIN: o nome de domínio do balanceador de carga.
Use este comando para criar um recurso de certificado SSL autogerenciado. Para criar um
certificado SSL autogerenciado, você precisa de um arquivo de chave privada local e de um arquivo de certificado
local. Se você precisar criar esses arquivos, consulte a etapa 1 de usar certificados SSL autogerenciados.
TARGET_SERVICE: o nome do anexo de serviço com que você quer se conectar.
Por exemplo: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
DEFAULT_BACKEND_SERVICE_NAME: o nome do serviço de back-end padrão do balanceador de carga.
O padrão é usado quando nenhuma regra de host corresponde ao nome do host solicitado.
Crie o proxy de destino HTTPS.
Para criar um balanceador de carga HTTPS, você precisa ter um recurso de certificado SSL
para usar no proxy de destino HTTPS.
Use este comando para criar um recurso de certificado SSL autogerenciado. Para criar um
certificado SSL autogerenciado, você precisa de um arquivo de chave privada local e de um arquivo de certificado
local. Se você precisar criar esses arquivos, consulte a etapa 1 de usar certificados SSL autogerenciados.
A criação e a implantação de proxies precisam de um conjunto mínimo de permissões. Se você tiver o papel de administrador da organização da Apigee, conclua esta tarefa. Para saber mais sobre outros papéis que podem ser implantados, consulte Papéis da Apigee.
Faça o download do proxy de amostra pelo GitHub. O destino do proxy é o serviço httpbin.org, que é um serviço público de solicitação e resposta usado com frequência.
Faça upload do pacote do proxy de API no ambiente de execução usando a API apis da Apigee:
Se você receber um erro como CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure, verifique se
o certificado SSL criado foi provisionado.
Use este comando para verificar o status de provisionamento. Quando o certificado é provisionado, o status é ACTIVE.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-07-18 UTC."],[],[]]