Infrastructure as Code - Load Balanced AutoScaling Clustered Magento 2 EE with DevOps CI and CD
This case study started in December, 2015. Magento 2 was just being launched and this customer already had Magento 1.x EE! The revised AWS infrastructure was done parallel with live data syncing to ensure minimal down time.
Schogini’s Magento and AWS certified team have done the entire infrastructure using a collection of version-able Bash Shell scripts. This made the architecture safe and repeatable.
Magento 2 EE Enterprise Edition with pre-existing Magento 1 EE with an in-house Magento development team. Schogini’s team members joined customers dev team seamlessly to collaborate with their DevOps culture.
Magento 1 EE (M1EE) to Magento 2 EE (M2EE) Upgrade and Data Migration
Custom Magento 2 Module Development to Handle Gift Cards
Varnish front-end caching clusters
AWS Elasticache (Redis backend and block caching)
Aurora RDS with Read Replica Database
AWS Cloudfront CDN for media and static content delivery
AWS Elastic Load balancer with Custom Health Check
AWS Autoscaling for the frontend clusters
AWS Route53 based Maintenance and DR (Disaster Recovery) system
Development, Staging/Testing and Production Automated CI/CD Pipeline
M2EE maintaining atomicity of sessions/user cart contents across frontend EC2 clusters
Frontend Varnish cache purging across all clusters to force push changes made by the shop admin
Very low maintenance period
Automated Backup and Rollback system with auto-detection of shop defects
The network setup containing VPC, Security Groups, Elastic IPs, Placement Groups etc. created using AWS CLI scripts
Custom AMI was created with the final M2EE code and made it as the source for the Launch Configuration.
Dedicated EC2 admin instance created with no Varnish and no Load Balancer to exclusive IP restricted access to security
Each frontend autoscaling cluster instance traffic came from the Load Balancer
Custom Health Check flag was created to communicate health of the shop to the Route53 to fail over to maintenance mode
Push to production script to automate going live process created
CloudFront CDN with the Admin server’s media and static folder as the origin defined
Custom command line module was created to auto generate thumbnails to reduce CDN miss latency
In this Magento AWS architecture, one S3 bucket has been designated for backup and rollback. The cluster generated static files (if any) were being copied to the admin server folder for CDN propagation. Local Git repository maintained the code and infrastructure versions.
Full-page cache across the auto-scaled clusters posed inconsistencies during updates. This had to be fixed after repeated trials by Schogini’s custom scripts to force Varnish purging.
Sree - Founder/MD/Chief Cloud & DevOps Architect
Sree is an evangelist and thought leader in the Continuous Delivery and DevOps space. In addition to being a Cloud Architect, he also imparts training in AWS, Docker and other DevOps related technologies. Sree's core speciality is in building scripted, version-able, repeatable, auto-scaling, load-balanced and self-healing infrastructures. Sree also works in server-less architectures using AWS Lambda service and Internet of Things (IOT). Sree is also an Amazon Certified AWS Cloud Architect with 15+ years of server experience.
Know more about the author.