Implementações Blue / Green com o CloudFront

Question

Estou procurando uma maneira de implantar o Blue / Green com o CloudFront .

Alguém tem uma boa solução para passar de uma distribuição do CloudFront para outra ou todos realmente apenas criam sua distribuição e nunca mais a tocam novamente?

Minha distribuição do CloudFront consiste em uma origem do S3 para conteúdo estático (javascript, etc.) ) e uma origem personalizada que aponta para um ELB da AWS.

Nenhuma alteração no CloudFront

Em circunstâncias normais, não fazemos alterações em nossa distribuição do CloudFront. Nós versionamos nosso conteúdo estático na origem do S3 alterando o nome dos arquivos de conteúdo estático no S3 e implementações contínuas em instâncias do EC2 sob o Elastic Load Balancer (ELB). No entanto, há momentos em que precisamos testar e fazer alterações na própria distribuição do CloudFront ou ter alterações significativas em nosso ambiente, de modo que precisamos apontar para um novo ELB em um novo ambiente.

Duas distribuições do CloudFront

A primeira opção que tentei foi ter duas Distribuições na Web do CloudFront. , um para o meu ambiente atual, ou A, e outro para o meu novo, ou B, ambiente. Eu tentei usar uma política de roteamento ponderada do Route53 Eu adicionei dois registros para o meu registro Route53 do www.domain.com, um apontando para o CloudFront Distribution A com um peso de 1 e o outro apontando para o CloudFront Distribution B com um peso de 0. O plano seria alterar os pesos quando eu quiser para mover da distribuição A para a distribuição B. No entanto, apenas uma distribuição do CloudFront por vez pode ter o www.domain.com Nomes de domínio alternativos (CNAMEs) registrados ou você recebe o seguinte erro:

com.amazonaws.services.cloudfront.model.CNAMEAlreadyExistsException: One or more of the CNAMEs you provided are already associated with a different resource. (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: ef84a5f0-44e7-11e5-9315-0ba167bb108a)

Uma distribuição do CloudFront

A segunda opção é manter uma distribuição da Web do CloudFront. Eu tenho S3 e origens personalizadas apontando para meus ambientes A e B e, em seguida, atualizo o Cache Comportamento do CloudFront. para apontar para a outra origem quando eu quiser passar de um ambiente para outro. Isso é extremamente confuso, pois essas atualizações demoram de 15 a 60 minutos, não há visibilidade do andamento da atualização e, dependendo da natureza da alteração, talvez seja necessário seguir um Invalidação do CloudFront para que você não esteja veiculando conteúdo em cache do ambiente antigo junto com novo conteúdo.

Obrigado pelo seu conselho!

    

Answer 1

Duas distribuições em cloudfront

Como o AWS permite a sobreposição entre CNAMEs alternativos com curingas na mesma conta da AWS, você pode alternar entre duas distribuições do cloudfront da seguinte maneira:

• Use www.domain.com como CNAME alternativo para distribuição Prod 1
• Use * .domain.com como CNAME alternativo para a distribuição Prod 2
• Aponte seu DNS CNAME DNS www.domain.com para distribuição 1 ou distribuição 2. (* .cloudfront.net).
• Remova o CNAME alternativo da distribuição da qual você não deseja mais veicular o conteúdo.

No entanto, os dois DNSs de distribuição diferentes (* .cloudfront.net) podem apontar para os mesmos nós de borda, o que significa que a maneira como seu conteúdo é veiculado é a correspondência do CNAME cloudfront.net com os nós Edge que o veiculam. para corresponder por hostname. Nesse caso, se as duas distribuições estiverem usando os mesmos nós de borda (pode ser verificado, por exemplo, com dig ), o corte não será limpo.

e.g. If both distributions share one or more edge nodes, distribution 1 with Alt CNAME www.domain.com will take precedence over distribution 2 with the more generic *.domain.com until the CNAME gets removed from the distribution 1 config in all edge nodes. So the version retrieved from one request may be different from the other during the transition period.

    

Answer 2

Um pouco atrasado no jogo aqui, mas para qualquer um que esteja procurando por isso. Eu acredito que isso pode ser feito usando lambda @ edge. Semelhante aos testes A / B. link . Você pode implementar uma função lambda acionada quando um usuário solicita uma URL. Opte por veicular o conteúdo azul / verde de diferentes origens ou prefixo de URL. Um valor de cookie determinará qual implantação será veiculada. Quando o primeiro pedido chegar (sem cookie), defina o cookie aleatoriamente com 95% de azul e 5% de verde.

    

Answer 3

Filmando no quadril, quanto tempo leva para mudar a origem dentro de uma distribuição de nuvem? 1) implantar novo código por trás ELB, aquecer 2) adicione ELB como uma nova origem para a sua distribuição frente nuvem ao remover o antigo origem 3) uma vez transição, derrubar antigo código por trás de idade ELB.

Para fugir dos atrasos associados com atualizações CloudFront ou atualizações de DNS, você poderia trocar o grupo autoscale atrás de seu ELB. 1) implantar novo código no novo ASG, aquecer 2) registrar o seu ELB existente com este novo ASG 3) de registrar o velho ASG do seu ELB 4) uma vez transição, derrubar velho ASG.

    

Answer 4

Eu também tenho pesquisado sobre esse assunto e tenho uma solução alternativa (veja abaixo).

Histórico:

O CloudFront exige que o CNAME na configuração de distribuição seja exclusivo em toda a sua conta. Portanto, controlar o azul / verde via DNS para diferentes distribuições não funcionará. Há um hack rolando que usaria curingas, mas isso não garante que os arquivos corretos sejam atendidos. Controlar azul / verde via DNS e CloudFront não é viável.

Além disso, a alteração de qualquer configuração no CloudFront (incluindo o CNAME) resulta em 15 a 60 minutos de espera enquanto as alterações são propagadas para os servidores de borda. Além disso, não é uma configuração ideal.

Solução:

Para o aplicativo de página única, essa configuração pode ajudar:

• URL do aplicativo: app.mydomain.com/app
• Estrutura S3:
  • app / (seu site ativo)
  • app2 / (seu site não é tão ativo)

Agora configure o CloudFront para usar seu bloco para veicular os arquivos. Neste ponto, tudo se resume a você configurações de cache. Como o CloudFront leva uma eternidade, defina o cabeçalho CacheControl em nossos objetos S3. Para index.html, usamos 5 minutos, tudo mais, 1 dia. Quando chegar a hora de trocar, troque os nomes dos diretórios do S3. Em cinco minutos, o aplicativo estará ativo para todos os efeitos.

Para aplicativos que já estão em execução, temos a versão de compilação incorporada no código e um arquivo json de configuração de compilação na raiz do aplicativo. Em seguida, o aplicativo solicitará ocasionalmente o arquivo json, verifique a versão, se estiver desatualizado, solicite uma atualização.

Limitações

Você não pode realizar testes de saturação muito bem. Suponho que é possível aumentar o TTL de index.html para algumas horas ou dias (dependendo da sua necessidade), o que ajudaria a garantir que os clientes obterão novas versões quando o cache local expirar.

    

Answer 5

Em esta postagem no blog , o autor implementa testes em b via Lambda @ Edge trabalhando fora do código na documentação da AWS (você pode ver seus exemplos aqui: link ).

Basicamente, o que você faz é criar uma única distribuição do Cloudfront apontando para duas origens diferentes. Então você pode usar o Lambda @ Edge para direcionar o tráfego para qualquer origem (via Cookies), e é claro que você pode implementar outras coisas através do Lambda como ponderar o tráfego ou lançá-lo, etc. Também é fácil adicionar outras origens e lógica .