 |
Embora os contêineres tenham revolucionado como as equipes de desenvolvimento empacotam e implantam aplicativos, essas equipes tiveram que monitorar cuidadosamente os lançamentos e criar ferramentas personalizadas para mitigar os riscos de implantação, o que diminui a velocidade do envio. Em escala, as equipes de desenvolvimento gastam ciclos valiosos construindo e mantendo ferramentas de implantação indiferenciadas em vez de inovar para seus negócios.
A partir de hoje, você pode usar a capacidade de implantação azul/verde embutida em Serviço de contêineres elásticos da Amazon (Amazon ECS) Para tornar suas implantações de aplicativos mais seguras e consistentes. Esse novo recurso elimina a necessidade de criar ferramentas de implantação personalizadas, fornecendo a confiança para enviar atualizações de software program com mais frequência com a capacidade de reversão.
Veja como você pode ativar a capacidade de implantação azul/verde embutida no Amazon ECS console.
Você cria um novo ambiente de aplicativo “verde” enquanto o ambiente “azul” existente continua a servir o tráfego ao vivo. Depois de monitorar e testar bem o ambiente verde, você direciona o tráfego ao vivo de azul para verde. Com esse recurso, o Amazon ECS agora fornece funcionalidade interna que torna as implantações de aplicativos em contêiner mais seguras e confiáveis.
Abaixo está um diagrama que ilustra como a implantação azul/verde funciona mudando o tráfego de aplicativos do ambiente azul para o ambiente verde. Você pode aprender mais no Amazon ECS Blue/Inexperienced Service implantações Fluxo de trabalho página.
A Amazon ECS orquestra todo esse fluxo de trabalho enquanto fornece ganchos de eventos para validar novas versões usando o tráfego sintético antes de rotear o tráfego de produção. Você pode validar novas versões de software program em ambientes de produção antes de expô-los a usuários finais e reverter quase instantes se surgirem problemas. Como essa funcionalidade é construída diretamente no Amazon ECS, você pode adicionar essas salvaguardas simplesmente atualizando sua configuração sem criar nenhuma ferramenta personalizada.
Começando
Deixe -me orientá -lo em uma demonstração que mostra como configurar e usar implantações azuis/verdes para um serviço ECS. Antes disso, existem algumas etapas de configuração que eu preciso concluir, incluindo a configuração AWS Id and Entry Administration (Iam) papéis, que você pode encontrar no Recursos necessários para implantações Amazon ECS Blue/Inexperienced Página de documentação.
Para esta demonstração, quero implantar uma nova versão do meu aplicativo usando a estratégia azul/verde para minimizar o risco. Primeiro, preciso configurar meu serviço ECS para usar implantações azuis/verdes. Eu posso fazer isso através do console do ECS, Interface da linha de comando da AWS (AWS CLI), ou usando infraestrutura como código.
Usando o console do Amazon ECS, crio um novo serviço e o configuro como de costume:
Na seção de opções de implantação, eu escolho ECS Como o Tipo de controlador de implantaçãoentão Azul/verde Como o Estratégia de implantação. Bake Time é o momento após o tráfego de produção mudar para verde, quando estiver disponível instantâneo para o azul. Quando o tempo de bolos expira, as tarefas azuis são removidas.
Também estamos introduzindo ganchos de ciclo de vida da implantação. Estes são mecanismos orientados a eventos que você pode usar para aumentar o fluxo de trabalho de implantação. Eu posso selecionar qual AWS Lambda Função Eu gostaria de usar como um gancho de ciclo de vida de implantação. A função Lambda pode executar a lógica de negócios necessária, mas deve retornar um standing de gancho.
A Amazon ECS suporta os seguintes ganchos do ciclo de vida durante as implantações azuis/verdes. Você pode aprender mais sobre cada estágio no Estágios do ciclo de vida da implantação página.
- Pré -escala
- Pós -escala
- Mudança de tráfego de produção
- Teste de troca de tráfego
- Mudança de tráfego pós -produção
- Pós -teste de trânsito de tráfego
Para o meu aplicativo, quero testar quando a mudança de tráfego de teste estiver concluída e o serviço verde lida com todo o tráfego de teste. Como não há tráfego do usuário closing, uma reversão nesta fase não terá impacto nos usuários. Isso faz Pós -teste de trânsito de tráfego Adequado para o meu caso de uso, pois posso testá -lo primeiro com minha função Lambda.
O contexto de troca por um momento, vamos nos concentrar na função Lambda que eu uso para validar a implantação antes de permitir que ela prossiga. Na minha função Lambda como um gancho de ciclo de vida de implantação, posso executar qualquer lógica de negócios, como testes sintéticos, chamando outra API ou consultando métricas.
Dentro da função lambda, devo devolver um hookStatus. UM hookStatus pode ser SUCCEEDEDque moverá o processo para a próxima etapa. Se o standing for FAILEDele volta à implantação azul. Se for IN_PROGRESSentão o Amazon ECS experimenta a função Lambda em 30 segundos.
No exemplo a seguir, configurei minha validação com uma função Lambda que executa o add de arquivo como parte de um conjunto de testes para o meu aplicativo.
import json
import urllib3
import logging
import base64
import os
# Configure logging
logger = logging.getLogger()
logger.setLevel(logging.DEBUG)
# Initialize HTTP shopper
http = urllib3.PoolManager()
def lambda_handler(occasion, context):
"""
Validation hook that exams the inexperienced atmosphere with file add
"""
logger.data(f"Occasion: {json.dumps(occasion)}")
logger.data(f"Context: {context}")
attempt:
# In an actual situation, you'll assemble the check endpoint URL
test_endpoint = os.getenv("APP_URL")
# Create a check file for add
test_file_content = "It is a check file for deployment validation"
test_file_data = test_file_content.encode('utf-8')
# Put together multipart kind information for file add
fields = {
'file': ('check.txt', test_file_data, 'textual content/plain'),
'description': 'Deployment validation check file'
}
# Ship POST request with file add to /course of endpoint
response = http.request(
'POST',
test_endpoint,
fields=fields,
timeout=30
)
logger.data(f"POST /course of response standing: {response.standing}")
# Test if response has OK standing code (200-299 vary)
if 200 <= response.standing < 300:
logger.data("File add check handed - acquired OK standing code")
return {
"hookStatus": "SUCCEEDED"
}
else:
logger.error(f"File add check failed - standing code: {response.standing}")
return {
"hookStatus": "FAILED"
}
besides Exception as error:
logger.error(f"File add check failed: {str(error)}")
return {
"hookStatus": "FAILED"
}Quando a implantação atinge o estágio do ciclo de vida associado ao gancho, o Amazon ECS invoca automaticamente minha função Lambda com o contexto de implantação. Minha função de validação pode executar testes abrangentes contra a revisão verde – escolhendo a saúde do aplicativo, executando testes de integração ou validando métricas de desempenho. A função então sinaliza de volta à ECS se deve prosseguir ou abortar a implantação.
Como escolhi a estratégia de implantação azul/verde, também preciso configurar os balanceadores de carga e/ou o Amazon ECS Service Join. No Balanceamento de carga Seção, eu seleciono meu Balanceador de carga de aplicação.
No Ouvinte Seção, eu uso um ouvinte existente na porta 80 e selecione dois Grupos -alvo.
Feliz com essa configuração, crio o serviço e espero o ECS para fornecer meu novo serviço.
Testando implantações azuis/verdes
Agora, é hora de testar minhas implantações azuis/verdes. Para este teste, o Amazon ECS acionará minha função Lambda após a conclusão da mudança de tráfego de teste. Minha função lambda retornará FAILED Nesse caso, como executa o add de arquivo no meu aplicativo, mas meu aplicativo não possui esse recurso.
Eu atualizo meu serviço e verifiquei Forçar a nova implantaçãoconhecer a capacidade de implantação azul/verde reverterá se detectar uma falha. Selecionei esta opção porque não modifiquei a definição da tarefa, mas ainda preciso acionar uma nova implantação.
Nesta fase, tenho ambientes azuis e verdes em execução, com a revisão verde lidando com todo o tráfego de teste. Enquanto isso, com base em Amazon CloudWatch Logs da minha função Lambda, também vejo que os ganchos do ciclo de vida da implantação funcionam conforme o esperado e emitem a seguinte carga útil:
(INFO) 2025-07-10T13:15:39.018Z 67d9b03e-12da-4fab-920d-9887d264308e Occasion:
{
"executionDetails": {
"testTrafficWeights": {},
"productionTrafficWeights": {},
"serviceArn": "arn:aws:ecs:us-west-2:123:service/EcsBlueGreenCluster/nginxBGservice",
"targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123:service-revision/EcsBlueGreenCluster/nginxBGservice/9386398427419951854"
},
"executionId": "a635edb5-a66b-4f44-bf3f-fcee4b3641a5",
"lifecycleStage": "POST_TEST_TRAFFIC_SHIFT",
"resourceArn": "arn:aws:ecs:us-west-2:123:service-deployment/EcsBlueGreenCluster/nginxBGservice/TFX5sH9q9XDboDTOv0rIt"
}Como esperado, minha função AWS Lambda retorna FAILED como hookStatus Porque não conseguiu executar o teste.
(ERROR) 2025-07-10T13:18:43.392Z 67d9b03e-12da-4fab-920d-9887d264308e File add check failed: HTTPConnectionPool(host="xyz.us-west-2.elb.amazonaws.com", port=80): Max retries exceeded with url: / (Brought on by ConnectTimeoutError(, 'Connection to xyz.us-west-2.elb.amazonaws.com timed out. (join timeout=30)')) Como a validação não foi concluída com sucesso, o Amazon ECS tenta reverter a versão azul, que é a versão anterior de implantação de trabalho. Eu posso monitorar esse processo por meio de eventos do ECS no Eventos Seção, que fornece visibilidade detalhada para o progresso da implantação.
O Amazon ECS revira com sucesso a implantação para a versão de trabalho anterior. A reversão acontece quase instantaneamente porque a revisão azul permanece em execução e pronta para receber o tráfego de produção. Não há impacto no usuário closing durante esse processo, pois o tráfego de produção nunca mudou para a nova versão do aplicativo-o ECS simplesmente reverteu o tráfego de teste para a versão estável authentic. Isso elimina o tempo de inatividade típico de implantação associado às implantações tradicionais de rolagem.
Eu também posso ver o standing de reversão no Última implantação seção.
Ao longo dos meus testes, observei que a estratégia de implantação azul/verde fornece comportamento consistente e previsível. Além disso, os ganchos do ciclo de vida da implantação fornecem mais flexibilidade para controlar o comportamento da implantação. Cada revisão de serviço mantém configuração imutável, incluindo definição de tarefa, configurações de balanceador de carga e configuração de conexão de serviço. Isso significa que as reversão restauram exatamente o mesmo ambiente que estava em execução anteriormente.
Coisas adicionais para saber
Aqui estão algumas coisas a serem observadas:
- Preço – O recurso de implantação azul/verde está incluído no Amazon ECS sem custo adicional. Você paga apenas pelos recursos de computação usados durante o processo de implantação.
- Disponibilidade – Essa capacidade está disponível em todas as regiões comerciais da AWS.
Comece a implantações azuis/verdes, atualizando sua configuração de serviço Amazon ECS no Amazon ECS Console.
Feliz implantação!
– Donnie