Você está vendo a documentação do Apigee Edge.
Acesse a
documentação da Apigee X. informações
Em agosto e setembro de 2015, migraremos nossos roteadores de nuvem e balanceadores de carga do Apigee Edge para o NGINX (pronuncia-se "Mecanismo X"). O NGINX, um servidor da Web de código aberto, oferece desempenho ainda melhor e simultaneidade maior do que os nossos balanceadores de carga e roteadores atuais.
O que isso significa para nossos clientes de nuvem
Em resumo, essa mudança precisa ser transparente para você, e nenhuma ação da sua parte é necessária além da verificação de que seus sistemas estão funcionando conforme o esperado. Veja a seguir descrições das etapas que serão seguidas, além de respostas a algumas perguntas frequentes.
Etapa 1: atualização de software
Faremos upgrade de todos os roteadores para o novo roteador baseado em NGINX aproveitando nosso modelo de implantação em fases para ajudar a garantir que os serviços não sejam afetados como resultado dessa atividade.
Etapa 2: remover o nível do balanceador de carga em ambientes que não sejam de produção
Com o novo roteador NGINX gerenciando a funcionalidade de balanceamento de carga, vamos iniciar primeiro o processo de remoção do nível atual do balanceador de carga nos ambientes de não produção. Os balanceadores de carga de produção permanecerão intactos e inalterados durante essa etapa. Antes da remoção dos balanceadores de carga atuais, vamos adotar uma abordagem completa para garantir que o tráfego esteja funcionando conforme o esperado. Você não precisa fazer nada para concluir essa etapa. No entanto, informe quaisquer problemas à Apigee, e trabalharemos com você para resolver os problemas antes de prosseguir para a Etapa 3.
Etapa 3: remover o nível do balanceador de carga nos ambientes de produção
Após a conclusão da etapa 2, vamos determinar um conjunto de janelas de manutenção para remover o nível do balanceador de carga nos ambientes de produção usando a mesma abordagem mencionada na etapa 2 para garantir que o tráfego da API do ambiente de execução continue funcionando conforme o esperado.
Mudanças na funcionalidade do produto
Confira algumas mudanças na funcionalidade do produto com a migração para o NGINX.
Descontinuado
As seguintes propriedades não são mais compatíveis com ProxyEndpoints:
- allow.http10
- allow.http11
- allow.http.method.*
- allow.POST.without.content.length
- allow.PUT.without.content.length
Para contornar essa descontinuação, consulte este artigo da comunidade: https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html.
Perguntas frequentes
Veja a seguir as respostas para algumas perguntas frequentes sobre a migração do NGINX.
Durante a etapa 1, a resposta é "Não", já que não estamos trabalhando nos balanceadores de carga atuais, o que não muda diretamente os IPs que veiculam o tráfego. No entanto, dada a natureza do serviço de balanceamento de carga da Amazon Web Services (AWS), as regras de escalonamento normais são aplicadas, o que significa que os IPs podem mudar como parte da lógica de escalonamento (funcionalidade existente). É por isso que não recomendamos implementar as configurações de lista de permissões do norte com o pacote de produtos do Apigee Edge. Durante as etapas 2 e 3, há implicações na lista de permissões com a remoção do balanceador de carga e dos endereços IP associados. Por isso, trabalharemos juntos durante essas etapas para garantir uma transição tranquila, fornecendo um novo conjunto de endereços IP para permitir o acesso.
Nenhuma mudança é necessária, supondo que os servidores de origem sejam os servidores de endpoint de destino (servidores chamados do pacote de proxy). Essa alteração é no lado norte da Apigee ou no ponto de entrada na Apigee.
Não. As entradas CNAME existentes continuarão funcionando.
Se você estiver usando o SSL, a etapa inicial não afetará a configuração atual. No entanto, precisaremos trabalhar em conjunto com você para garantir que o SSL esteja configurado corretamente no novo roteador antes de prosseguir para as etapas 2 e 3.
As etapas 2 e 3 serão adiadas até que o suporte a SNI seja confirmado.
Não esperamos inatividade. As alterações serão implementadas usando nosso modelo de implantação padrão durante as janelas de lançamento atuais.