Você está lendo a documentação do Apigee Edge.
Acesse a documentação da
Apigee X. info
Durante agosto e setembro de 2015, vamos migrar nossos roteadores de nuvem e balanceadores de carga do Apigee Edge para o NGINX (pronunciado "Engine X"). O NGINX, um servidor da Web de código aberto, oferece desempenho ainda melhor e maior simultaneidade do que os balanceadores de carga e roteadores atuais.
O que isso significa para nossos clientes de nuvem
Essa mudança deve ser transparente para você e não exige nenhuma ação da sua parte, além da verificação de que seus sistemas estão funcionando conforme o esperado. A seguir, há descrições das etapas que vamos seguir, além de respostas para algumas perguntas frequentes.
Etapa 1: atualização de software
Vamos fazer upgrade de todos os roteadores para o novo roteador baseado em NGINX usando nosso modelo de implantação em fases para 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 processando a funcionalidade de balanceamento de carga, vamos começar o processo de remoção do nível de balanceador de carga atual nos seus ambientes de não produção. Os balanceadores de carga de produção vão permanecer intactos e inalterados durante essa etapa. Antes da remoção dos balanceadores de carga atuais, vamos adotar uma abordagem exaustiva para garantir que o tráfego esteja funcionando conforme o esperado. Você não precisa fazer nada para concluir esta etapa. No entanto, você precisa informar qualquer problema à Apigee, e vamos trabalhar com você para resolver os problemas antes de prosseguir com a etapa 3.
Etapa 3: remover o nível do balanceador de carga em 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 de tempo de execução continue funcionando como esperado.
Mudanças na funcionalidade do produto
Confira algumas mudanças na funcionalidade do produto com a mudança 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 o seguinte artigo da comunidade: As propriedades do método de permissão HTTP do endpoint de proxy não estão funcionando.
Perguntas frequentes
Confira abaixo respostas para algumas perguntas frequentes sobre a migração do NGINX.
Na etapa 1, a resposta é "Não", porque não estamos mexendo nos balanceadores de carga existentes, que não vão mudar diretamente nenhum dos IPs que atendem ao tráfego. No entanto, devido à natureza do serviço de balanceamento de carga da Amazon Web Services (AWS), as regras de escalonamento normais se aplicam, o que significa que os IPs podem mudar como parte da lógica de escalonamento (funcionalidade atual). Por isso, não recomendamos implementar configurações de inclusão na lista de permissões de saída com o pacote de produtos do Apigee Edge. Durante as etapas 2 e 3, há implicações de lista de permissões com a remoção do balanceador de carga e dos endereços IP associados. Por isso, vamos trabalhar em estreita colaboração com você 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 mudança está no lado norte da Apigee ou no ponto de entrada da Apigee.
Não. As entradas CNAME atuais vão continuar funcionando conforme o esperado.
Se você estiver usando SSL, a etapa inicial não vai afetar a configuração SSL atual. No entanto, vamos precisar coordenar com você para garantir que o SSL seja configurado corretamente no novo roteador antes de prosseguir com as etapas 2 e 3.
As etapas 2 e 3 serão adiadas até que o suporte ao SNI seja confirmado.
Não esperamos inatividade. As mudanças serão implementadas usando nosso modelo de implantação padrão durante as janelas de lançamento atuais.