Você está lendo a documentação do Apigee Edge.
Acesse a
documentação da Apigee X. info
Durante agosto e setembro de 2015, migramos nossos balanceadores de carga e roteadores de nuvem do Apigee Edge para o NGINX (pronunciado "Engine X"). O NGINX, um servidor da Web de código aberto, oferece um desempenho ainda melhor e maior simultaneidade do que nossos 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, descrevemos as etapas que vamos seguir e respondemos a algumas perguntas frequentes.
Etapa 1: atualização de software
Vamos fazer o upgrade de todos os roteadores para o novo roteador baseado em NGINX, aproveitando nosso modelo de implantação em fases para garantir que os serviços não sejam afetados por essa atividade.
Etapa 2: remover a camada 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 da camada do balanceador de carga atual nos seus ambientes que não sejam de 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. Nenhuma ação é necessária da sua parte para concluir essa etapa. No entanto, informe qualquer problema à Apigee. Vamos trabalhar com você para resolver os problemas antes de prosseguir com a etapa 3.
Etapa 3: remover a camada 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 a camada do balanceador de carga em ambientes de produção usando a mesma abordagem mencionada na etapa 2 para garantir que o tráfego da API de execução continue funcionando conforme o esperado.
Mudanças na funcionalidade do produto
Confira algumas mudanças na funcionalidade do produto com a mudança para o NGINX.
Descontinuado
As propriedades a seguir 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: Proxy Endpoint HTTP allow method properties not working (em inglês).
Perguntas frequentes
A seguir, respondemos a algumas perguntas frequentes sobre a migração do NGINX.
Durante a etapa 1, a resposta é "Não", porque não estamos tocando nos balanceadores de carga atuais, que não vão mudar diretamente nenhum dos IPs que atendem ao tráfego. No entanto, dada a 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 que não recomendamos a implementação de configurações de 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. Como resultado, vamos coordenar de perto 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 de saída da Apigee ou no ponto de entrada da Apigee.
Não. As entradas de 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 de perto com você para garantir que o SSL esteja configurado corretamente no novo roteador antes de prosseguir com as etapas 2 e 3.
As etapas 2 e 3 serão atrasadas até que o suporte a SNI seja confirmado.
Não esperamos nenhum tempo de inatividade. As mudanças serão implementadas usando nosso modelo de implantação padrão durante as janelas de lançamento atuais.