Implantações azuis / verdes com CloudFront

Estou procurando uma maneira de fazer implantações Blue / Green com CloudFront .

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

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

Nenhuma alteração no CloudFront

Sob circunstâncias normais, não fazemos nenhuma alteração em nossa distribuição do CloudFront. Versão nosso conteúdo estático na origem do S3, alterando o nome dos arquivos de conteúdo estático no S3 e fazendo implantações contínuas para instâncias do EC2 no 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 suficientemente significativas em nosso ambiente que precisamos apontar para um novo ELB em um novo ambiente.

Duas distribuições CloudFront

A primeira opção que tentei foi ter duas distribuições Web CloudFront separadas , uma para o meu ambiente atual, ou A, e outra para o meu novo ambiente, ou B. Tentei usar uma política de roteamento ponderada do Route53 em que adicionei dois registros para o meu registro www.domain.com Route53, um apontando para a Distribuição A do CloudFront com peso 1 e o outro apontando para a Distribuição B do CloudFront com peso 0. O valor O plano seria alterar os pesos quando eu quiser passar da distribuição A para a distribuição B. No entanto, apenas uma distribuição do CloudFront por vez pode ter os Nomes de Domínio Alternativo (CNAMEs) www.domain.com 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)

Distribuição One CloudFront

A segunda opção é manter uma distribuição na web do CloudFront. Tenho S3 e origens personalizadas apontando para meus ambientes A e B e, em seguida, atualizo o Comportamento de cache do CloudFront para apontar para a outra origem quando quero passar de um ambiente para outro. Isso é extremamente confuso, pois essas atualizações levam de 15 a 60 minutos, não há visibilidade do andamento da atualização e, dependendo da natureza da sua alteração, talvez você precise acompanhar isso com uma Invalidação do CloudFront para não exibir o conteúdo em cache do ambiente antigo junto com o novo conteúdo.

Obrigada pelo Conselho!

Duas distribuições Cloudfront

Como a AWS permite sobreposição entre CNAMEs alternativos com curinga na mesma conta da AWS, você pode alternar entre duas distribuições de frente para a nuvem 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 www.domain.com para a 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 é correspondendo o CNAME do cloudfront.net aos nós de Borda que o servem e depois correspondendo por nome de anfitrião. Nesse caso, se ambas as suas distribuições estiverem usando os mesmos nós de aresta (pode ser verificado, por exemplo, com dig), o corte não será limpo.

Por exemplo, se as duas distribuições compartilharem um ou mais nós de borda, a distribuição 1 com Alt CNAME www.domínio.com terá precedência sobre a distribuição 2 com o * .domain.com mais genérico até que o CNAME seja removido da configuração da distribuição 1 em todos os nós de borda . Portanto, a versão recuperada de uma solicitação pode ser diferente da outra durante o período de transição.

Um pouco tarde no jogo aqui, mas para quem procura isso. Eu acredito que isso pode ser feito usando lambda @ edge. Semelhante aos testes A / B. https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html . Você pode implementar uma função lambda acionada quando um usuário solicita um URL. Escolha servir o conteúdo azul / verde de diferentes origens ou prefixo de URL. Um valor de cookie determinará qual implantação será veiculada. Quando a primeira solicitação chegar (sem cookie), defina o cookie aleatoriamente dizendo 95% azul 5% verde.

Filmando a partir do quadril, quanto tempo leva para mudar a origem dentro de uma distribuição na frente da nuvem? 1) implante um novo código atrás do ELB, aqueça-o 2) adicione esse ELB como uma nova origem à sua distribuição de frente para a nuvem enquanto remove a antiga origem 3) depois da transição, destrua o código antigo por trás do antigo ELB.

Para evitar os atrasos associados às atualizações do CloudFront ou DNS, você pode trocar o grupo de dimensionamento automático por trás do seu ELB. 1) implante um novo código no novo ASG, aqueça-o 2) registre seu ELB existente com este novo ASG 3) cancele o registro do ASG antigo do seu ELB 4) uma vez eliminado, remova o ASG antigo.

Eu também tenho pesquisado esse tópico e tenho uma solução alternativa (veja abaixo).

Fundo:

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á. Existe um truque que usaria curingas, mas isso não garante que os arquivos corretos sejam veiculados. Controlar azul / verde via DNS e CloudFront não é viável.

Além disso, alterar qualquer configuração no CloudFront (incluindo 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.

Gambiarra:

Para aplicativos de página única, esta configuração pode executar o truque:

• 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 bucket para servir os arquivos. Neste ponto, tudo se resume às 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, todo o resto, 1 dia. Quando chegar a hora de trocar, troque os nomes de diretório S3. Dentro de 5 minutos, o aplicativo estará disponível para todos os efeitos.

Para aplicativos que já estão em execução, temos a versão de compilação incorporada ao código e um arquivo json de configuração de compilação na raiz do aplicativo. Ocasionalmente, o aplicativo solicita o arquivo json, verifica a versão, se estiver desatualizada, solicita uma atualização.

Limitações

Você não pode executar testes de imersão muito bem. Suponho que seja possível aumentar o TTL do index.html para algumas horas ou dias (dependendo da sua necessidade), o que ajudaria a garantir que os clientes obtenham novas versões à medida que o cache local expira.

Em deste blog postar os implementos autor ab testando via Lambda @ Borda trabalhando fora do código na documentação AWS (você pode ver seus exemplos aqui: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda- examples.html ).

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