DevOps Lab: CI/CD Deployment to AWS ECS

In this DevOps lab scenario, Jules, the software developer, is tasked with creating a professional website for a product of the reporter's choice. The final website should be accessible at https://yourdomain.com and display the name of the product.

The application development phase involves Jules writing the application code which will eventually be stored in a GitHub repository. The application must have a professional homepage, multiple sections, responsive design, and a working application. The application code should be version-controlled and stored in GitHub.

Next, a production-style AWS infrastructure is created. This includes a VPC with subnets in the us-east-1 region, both public and private. The architecture supports internet access through an Internet Gateway, application load balancing, and ECS. Private workloads have appropriate outbound connectivity. The necessary AWS resources are created, such as VPC subnets, route tables, internet gateway, NAT gateway, security groups, ECR repository, ECS cluster, ECS task definition, ECS service, target group, and application load balancer.

Continuous Integration (CI) is set up using GitHub Actions. The CI pipeline is triggered whenever there is a change in the application code. It performs various tasks, including source code checkout, dependency installation, application testing, SonarQube code-quality analysis, Docker image build, Trivy vulnerability scanning, AWS authentication, and pushing the Docker image to Amazon ECR. The CI process ensures that the application is safe and ready for deployment.

Continuous Deployment (CD) begins once a validated container image exists in ECR. Jenkins is used for CD, and the approved application is safely released to the environment. The Jenkins deployment uses the specific image produced by CI. The deployment process involves creating a new ECS task definition revision, updating the ECS service, performing a rolling deployment, and checking the health of the tasks. The target group must report that all tasks are healthy.

Finally, an Internet-facing Application Load Balancer (ALB) is configured with subnets in the public and private sections of the VPC. The ALB routes traffic from customers to the ECS service running in the private subnets. The ALB is associated with a custom domain, and an SSL/TLS certificate is configured for HTTPS. The final traffic flow is https://yourdomain.com, which directs users to the ALB, which then forwards the request to the ECS service running the application. The browser should display a valid HTTPS connection and show the product name.

The lab is considered successful when the CI GitHub push triggers the GitHub Actions pipeline, SonarQube analysis passes, Docker image builds, Trivy scans the image, and the versioned image reaches ECR. Jenkins then deploys the ECR image, creating a new ECS task definition revision. ECS performs a rolling deployment, and once the tasks are healthy, the old tasks are terminated.

The target group reports that all tasks are healthy, and users can access the website at https://yourdomain.com, seeing the product name displayed properly. The key takeaway for students is understanding the difference between CI (code testing and scanning) and CD (deploying the container image to ECS, running the application, and configuring HTTPS).