Vengala Vinay

Having 12+ Years of Experience in Software Development

Home » Zero-Downtime Deployments for Laravel Apps on AWS ECS with Blue/Green Strategy and Automated Rollbacks

Zero-Downtime Deployments for Laravel Apps on AWS ECS with Blue/Green Strategy and Automated Rollbacks

Understanding the Blue/Green Deployment Strategy

The Blue/Green deployment strategy is a cornerstone of achieving zero-downtime releases. It involves maintaining two identical production environments, referred to as “Blue” and “Green.” At any given time, one environment (e.g., Blue) is live and serving production traffic, while the other (Green) is idle. To deploy a new version, we provision the idle environment (Green) with the new application code. Once the Green environment is fully deployed, tested, and validated, traffic is switched from Blue to Green. The Blue environment is then kept as a rollback target or updated to the new version for the next deployment cycle.

AWS ECS and Load Balancer Integration

For this architecture, we’ll leverage Amazon Elastic Container Service (ECS) for container orchestration and an Application Load Balancer (ALB) to manage traffic routing. The ALB will be configured with target groups, where each target group points to a specific ECS service (representing either the Blue or Green environment). By manipulating the ALB’s listener rules, we can seamlessly switch traffic between these target groups.

Prerequisites and Setup

Before diving into the deployment script, ensure you have the following in place:

  • An existing AWS account with appropriate IAM permissions for ECS, ECR, ALB, and CloudFormation/Terraform.
  • Docker images for your Laravel application, pushed to an Amazon Elastic Container Registry (ECR) repository.
  • An existing ECS cluster.
  • An existing Application Load Balancer (ALB) with at least two target groups configured (e.g., my-app-blue-tg and my-app-green-tg). These target groups should point to the same ECS cluster and have identical health check configurations.
  • A listener on your ALB configured to forward traffic to one of these target groups (initially, let’s say my-app-blue-tg).
  • An ECS Task Definition for your Laravel application.

Automating Deployments with AWS CLI and Bash

We’ll create a bash script that orchestrates the deployment process. This script will dynamically determine the next environment to deploy to (Green if Blue is live, and vice-versa), update the ECS service for that environment, and then perform the traffic switch. For simplicity, we’ll assume a single listener rule on the ALB that needs to be updated. In more complex scenarios with multiple rules, you might need to manage rule priorities.

Identifying the Current Live Environment

The first step is to determine which target group is currently receiving traffic. We can achieve this by inspecting the ALB’s listener rules.

Example: Fetching ALB Listener Rules

#!/bin/bash

# --- Configuration ---
ALB_ARN="arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-laravel-alb/abcdef1234567890"
LISTENER_PORT="80"
BLUE_TG_ARN="arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-app-blue-tg/0123456789abcdef"
GREEN_TG_ARN="arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-app-green-tg/fedcba0987654321"
BLUE_SERVICE_NAME="my-laravel-app-blue"
GREEN_SERVICE_NAME="my-laravel-app-green"
ECS_CLUSTER_NAME="my-laravel-cluster"
TASK_DEFINITION_FAMILY="my-laravel-task-def"
NEW_IMAGE_TAG="latest" # Or a specific version tag

# --- Determine Current Environment ---
LISTENER_RULES=$(aws elbv2 describe-listener-rules --listener-arn $(aws elbv2 describe-listeners --load-balancer-arn $ALB_ARN --query "Listeners[?Port==\`$LISTENER_PORT\`].ListenerArn" --output text))

CURRENT_TG_ARN=$(echo "$LISTENER_RULES" | jq -r '.Rules[] | select(.IsDefault==false) | .Actions[] | select(.Type=="forward") | .ForwardConfig.TargetGroups[0].TargetGroupArn')

if [ "$CURRENT_TG_ARN" == "$BLUE_TG_ARN" ]; then
    echo "Blue environment is currently live."
    CURRENT_ENV="blue"
    TARGET_ENV="green"
    TARGET_TG_ARN=$GREEN_TG_ARN
    TARGET_SERVICE_NAME=$GREEN_SERVICE_NAME
    SOURCE_TG_ARN=$BLUE_TG_ARN
    SOURCE_SERVICE_NAME=$BLUE_SERVICE_NAME
elif [ "$CURRENT_TG_ARN" == "$GREEN_TG_ARN" ]; then
    echo "Green environment is currently live."
    CURRENT_ENV="green"
    TARGET_ENV="blue"
    TARGET_TG_ARN=$BLUE_TG_ARN
    TARGET_SERVICE_NAME=$BLUE_SERVICE_NAME
    SOURCE_TG_ARN=$GREEN_TG_ARN
    SOURCE_SERVICE_NAME=$GREEN_SERVICE_NAME
else
    echo "Error: Could not determine current live environment or unexpected target group."
    exit 1
fi

echo "Deploying to the $TARGET_ENV environment."

Note: This script uses jq for JSON parsing. Ensure it’s installed on your system.

Updating the ECS Service

Once we know which environment to deploy to, we need to update its corresponding ECS service with the new Docker image. This involves creating a new revision of the task definition with the updated image tag and then updating the ECS service to use this new revision.

Example: Updating ECS Service with New Image

# --- Update Task Definition ---
echo "Creating new task definition revision..."
NEW_TASK_DEF_ARN=$(aws ecs register-task-definition \
    --family $TASK_DEFINITION_FAMILY \
    --cli-input-json "$(aws ecs describe-task-definition --task-definition $TASK_DEFINITION_FAMILY --query 'taskDefinition' --output json | jq --arg NEW_IMAGE "$NEW_IMAGE_TAG" '.containerDefinitions[0].image = "123456789012.dkr.ecr.us-east-1.amazonaws.com/my-laravel-app:'$NEW_IMAGE_TAG'"')")

NEW_TASK_DEF_REVISION=$(echo "$NEW_TASK_DEF_ARN" | jq -r '.taskDefinition.revision')
echo "New task definition revision created: $TASK_DEFINITION_FAMILY:$NEW_TASK_DEF_REVISION"

# --- Update ECS Service ---
echo "Updating ECS service '$TARGET_SERVICE_NAME' to use new task definition revision..."
aws ecs update-service \
    --cluster $ECS_CLUSTER_NAME \
    --service $TARGET_SERVICE_NAME \
    --task-definition "$TASK_DEFINITION_FAMILY:$NEW_TASK_DEF_REVISION" \
    --force-new-deployment

echo "ECS service update initiated for $TARGET_SERVICE_NAME."

# --- Wait for Service to Stabilize (Crucial for Rollout) ---
echo "Waiting for service '$TARGET_SERVICE_NAME' to stabilize..."
aws ecs wait services-stable \
    --cluster $ECS_CLUSTER_NAME \
    --services $TARGET_SERVICE_NAME

echo "Service '$TARGET_SERVICE_NAME' has stabilized with the new deployment."

The aws ecs wait services-stable command is critical. It polls ECS until the service’s tasks have reached a stable state, meaning they are running and passing their health checks (as defined in the ECS service and potentially the ALB target group). This ensures the new version is healthy before we switch traffic.

Performing the Traffic Switch

With the target environment updated and stabilized, we can now switch traffic. This involves modifying the ALB listener rule to point to the new target group. We’ll also need to update the default rule if it’s the one being used for routing.

Example: Switching ALB Listener Rules

# --- Get Listener Rule ARN ---
# Assuming a single non-default rule for simplicity. Adjust if you have multiple.
RULE_ARN=$(aws elbv2 describe-listener-rules --listener-arn $(aws elbv2 describe-listeners --load-balancer-arn $ALB_ARN --query "Listeners[?Port==\`$LISTENER_PORT\`].ListenerArn" --output text) --query "Rules[?IsDefault==false].RuleArn" --output text)

if [ -z "$RULE_ARN" ]; then
    echo "Error: Could not find a non-default listener rule for port $LISTENER_PORT."
    exit 1
fi

echo "Found listener rule ARN: $RULE_ARN"

# --- Update Listener Rule to point to the new Target Group ---
echo "Switching traffic to target group: $TARGET_TG_ARN"
aws elbv2 modify-listener \
    --listener-arn $(aws elbv2 describe-listeners --load-balancer-arn $ALB_ARN --query "Listeners[?Port==\`$LISTENER_PORT\`].ListenerArn" --output text) \
    --default-actions TargetGroupArn=$TARGET_TG_ARN,Type=forward

echo "Traffic switch complete. The $TARGET_ENV environment is now live."

# --- Optional: Update the old live environment's target group to be idle ---
# This is more complex and depends on your setup. For a simple blue/green,
# you might just leave it running and update it on the *next* deployment.
# If you want to immediately de-provision or stop it, you'd need more logic here.
echo "The previous live environment ($SOURCE_SERVICE_NAME) is now idle and can be used for rollback or the next deployment."

The modify-listener command directly updates the listener’s default action. If your routing is more complex (e.g., path-based routing), you would use aws elbv2 modify-rule to update specific rules.

Implementing Automated Rollbacks

Rollbacks are as crucial as deployments. In a Blue/Green strategy, rolling back is as simple as reversing the traffic switch. If the new deployment (now Green) causes issues, we simply point the ALB listener back to the old environment (Blue).

Rollback Procedure

To implement an automated rollback, you would typically trigger it based on health check failures or an explicit command. The core of the rollback is switching the ALB listener back to the previously live target group.

Example: Rollback Script Snippet

# --- Rollback Logic (to be integrated into a separate script or triggered by monitoring) ---

# Assume we know the SOURCE_TG_ARN from the previous deployment script's output
# or by re-inspecting the ALB listener rules.

# For rollback, we need to switch back to the SOURCE_TG_ARN
echo "Initiating rollback to the previous environment (Target Group: $SOURCE_TG_ARN)..."

aws elbv2 modify-listener \
    --listener-arn $(aws elbv2 describe-listeners --load-balancer-arn $ALB_ARN --query "Listeners[?Port==\`$LISTENER_PORT\`].ListenerArn" --output text) \
    --default-actions TargetGroupArn=$SOURCE_TG_ARN,Type=forward

echo "Rollback complete. Traffic is now directed to the previous stable environment."

# After rollback, you might want to investigate the failed deployment (TARGET_ENV)
# and potentially scale down its ECS service or mark it for debugging.

The rollback mechanism relies on the fact that the previous environment (now idle) is still running and in a known good state. If the rollback itself fails, it indicates a more fundamental infrastructure issue.

Considerations for Laravel Applications

When deploying Laravel applications, several factors need careful consideration:

Database Migrations

Database schema changes are a common source of deployment friction. With Blue/Green, you have a few options:

  • Run Migrations on the New Environment: Execute php artisan migrate on the newly deployed Green environment before switching traffic. This requires careful coordination to ensure the Blue environment doesn’t perform migrations simultaneously.
  • Zero-Downtime Migrations: Use tools like robmorgan/phinx or implement a phased migration strategy (e.g., adding new columns, deploying code that uses them, then removing old columns in a subsequent deployment). Laravel’s built-in migration system doesn’t inherently support zero-downtime for schema changes that involve dropping or altering existing columns without careful planning.
  • Separate Migration Deployments: Treat database migrations as a separate deployment step that happens before the application code deployment. This can add complexity but offers more control.

Caching

Ensure your caching strategy (e.g., Redis, Memcached) is robust. If you’re using a shared cache, be mindful of potential inconsistencies between the Blue and Green environments during the transition. Consider cache invalidation strategies or, in some cases, a temporary cache flush during the switch.

Environment Variables

Manage environment variables carefully. AWS Systems Manager Parameter Store or AWS Secrets Manager are excellent choices for storing sensitive configuration. Ensure both Blue and Green environments can access the correct variables, especially during the transition phase.

Session Management

If your application relies on file-based sessions, you’ll encounter issues during traffic switching as users might be directed to an environment with a different session store. Configure Laravel to use a shared session driver like Redis or a database-backed session store.

Orchestration Tools and CI/CD Integration

While the bash script provides a foundational understanding, integrating this into a CI/CD pipeline is essential for true automation. Tools like Jenkins, GitLab CI, GitHub Actions, or AWS CodePipeline can be configured to:

  • Build and push Docker images to ECR upon code commits.
  • Trigger the deployment script after successful image builds.
  • Perform automated smoke tests or integration tests against the newly deployed environment (e.g., hitting a specific health check endpoint on the Green environment before switching traffic).
  • Initiate rollbacks based on test failures or monitoring alerts.

Example: GitHub Actions Workflow Snippet

name: Laravel Blue/Green Deploy

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Build and Push Docker Image
        env:
          ECR_REGISTRY: 123456789012.dkr.ecr.us-east-1.amazonaws.com
          ECR_REPOSITORY: my-laravel-app
          IMAGE_TAG: ${{ github.sha }}
        run: |
          aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin $ECR_REGISTRY
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG

      - name: Run Blue/Green Deployment Script
        env:
          ALB_ARN: "arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-laravel-alb/abcdef1234567890"
          BLUE_TG_ARN: "arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-app-blue-tg/0123456789abcdef"
          GREEN_TG_ARN: "arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-app-green-tg/fedcba0987654321"
          BLUE_SERVICE_NAME: "my-laravel-app-blue"
          GREEN_SERVICE_NAME: "my-laravel-app-green"
          ECS_CLUSTER_NAME: "my-laravel-cluster"
          TASK_DEFINITION_FAMILY: "my-laravel-task-def"
          NEW_IMAGE_TAG: ${{ github.sha }} # Use commit SHA as image tag
        run: |
          # Download or include your deployment script here
          # For example, if you have a deploy.sh file in your repo:
          chmod +x deploy.sh
          ./deploy.sh

This GitHub Actions workflow demonstrates how to automate the build, push, and deployment steps. The actual deploy.sh script would contain the AWS CLI commands detailed earlier.

Conclusion

Implementing zero-downtime deployments with a Blue/Green strategy on AWS ECS requires careful orchestration of container services, load balancers, and deployment scripts. By automating the process of updating environments, switching traffic, and enabling quick rollbacks, you can significantly improve the reliability and availability of your Laravel applications. Remember to thoroughly test your deployment and rollback procedures in a staging environment before applying them to production.

Recent Posts

Top Categories

Our Products

Our Services