TerraformMagentoCloud:将AWS Magento 2云Terraform基础架构作为代码。 对于任何系统Wo...

# Infrastructure as code for eCommerce Cloud Architecture on AWS (Multi Cloud AWS,GCP,Azure) This repository contains Magento 2 Cloud Terraform infrastructure as code for AWS Public Cloud. This infrastructure is the result of years of experience scaling Magento 1 and 2 in the cloud. It comes with the best cloud development practices baked in to save your time and money. Leveraging your own AWS Account dramatically reduces your monthly spend vs. paying an expensive managed hosting provider (PaaS, SaaS). This script is not limited to Magento deployments and can be used with any eCommerce/Web platform, eg. WordPress, WooCommerce, Drupal, Shopware 6, Shopify APP (Custum Private APP cloud), VueStorefront, Silyus, Oddo, ORO etc. It includes Magento in the name because it was designed for Magento at first. There are however projects using it to run Enterprise Java applications with auto scaling. If you have any questions feel free to send me an email – yegorshytikov@gmail.com # Important!!! Magento Software installation is out of the scope of this Project. This Repository just an example of the AWS infrastructure provisioning for Magento using Terraform. To Install Magento 2 on Centos 8 or AWS Linux 2 x86/ARM Linux use our another project: **Magento 2 Installation Automation (Centos 8.2, AWS linux with ARM support) GitHub repository:** [Magento installation Script] (https://github.com/Genaker/Magento-AWS-Linux-2-Instalation). Graviton 2 ARM instances are also supported. # Why Auoto Scaling Increasing the number of PHP-FPM processes beyond the number of physical processor cores does not improve the performance, rather is likely to degrade it, and can consume resources needlessly. Basic rule for the web is: CPU(physical) = (Concurrent HTTP REquest * http_req_duration) Be careful Intel CPUs are virtual and actual number of CPUs factor = 2; Graviton AWS ARM64 CPUS have factor 1 and are better for concurrent request processing. Intel CPUs have some advantages of 20-30% in some cases, however for magento (long heavy queries) physical cores are better. With higher trafic you need more CPUs. It is rule for uncached pages. With Varnish/FPC it is the same. However Varnish has response time ~ 1ms and a single instance CPU can return 1000 caches pages per sec. To avoid unpredictable results with the cache invalidation, misses, uncached checkouts, cart, AJAXs, API the BEST practices is to measure performance without FPC. FPC is a bonus. ## AWS Magento 2 Cloud Features: * True Horizontal Auto Scaling * Affordable (starting from ~300$ for us-west-2 region) * MySQL RDS scalable Managed by Amazon, multi az failover, vertical scaling without downtime * Compatible with RDS Aurora Cluster and Aurora Serverless * EFS - Fully managed elastic NFS for media and configuration storage * CloudFront CDN for static and media served from different origins S3 or Magento(EFS) as second origin * Automatically back up your code and databases (point-in-time snapshot) for easy restoration * 99.9% Uptime, availability across multiple zones * High security (Security groups, private infrastructure) * Elastic(Static) IP and used for internet access for all EC2 instances through NAT (Network Address Translation). * Bastion host to provide Secure Shell (SSH) access to the Magento web servers. * Appropriate security groups for each instance or function to restrict access to only necessary protocols and ports. * Private Public Subnets - NAT gateway, Bastion server * All servers and Database are hosted in private Network securely * System and Software Update Patches * DDoS Protection with AWS Shield * PCI compliant infrastructure * Redis cluster * Amazon Elasticsearch Service - Elasticsearch at scale with zero down time with built-in Kibana * Different Application Scaling Groups (ASG) * Application Load Balancer(ALB) with SSL/TSL termination, SSL certificates management * ALB Path-Based Routing, Host-Based Routing, Lambda functions as targets, HTTP header/method-based routing, Query string parameter-based routing * Scaled Varnish ASG * Dedicated Admin/Cron ASG * You can easily add new autoscaling groups for your needs (Per WebSite/for Checkout requests/for API), just copy paste code * Possibility to run the same infrastructure on Production/Staging/Dev environment, different projects * Automatic CI/CD (CodePipeline/CodeDeploy) deployments possible * AWS CodeDeploy In-place deployment, Blue/green deployment from Git or S3, Redeploy or Roll Back * Deploying from a Development Account to a Production Account * Amazon Simple Email Service (Amazon SES) - cloud-based email sending service. Price $0.10 for 1K emails * Amazon CloudWatch - load all the metrics (CPU, RAM, Network) in your account for search, graphing, and alarms. Metric data is kept for 15 months. * CloudWatch alarms that watche a single CloudWatch metric or the result of a math expression based on CloudWatch metrics and send SMS(Text) Notifications or Emails * Simple and Step Scaling Policies - choose scaling metrics that trigger horizontal scaling * Manual Scaling for Magento Auto Scaling Group (ASG) * AWS Command Line Interface (CLI) - tool to manage your AWS services. You can control multiple AWS services from the command line and automate them through scripts. * DynamoDb for logs, indexes, analytics * Lambda functions as targets for a load balancer * Elastic Container Registry (ECR) - fully-managed Docker container registry that makes it easy to store, manage, and deploy Docker container images! * You can use Amazon Elastic Container Service (ECS) instead of ASG with Service Auto Scaling to adjust running containers desired count automatically. * Awesome AWS documentation is Open Source and on GitHub  [Cloud Flat View](https://github.com/Genaker/TerraformMagentoCloud/blob/master/Magento2Cloud-Flat.png) # Our Infrastructure Infrastructure consists of multiple layers (autoscaling, alb, rds, security-group, vpc) where each layer is configured using one of the [Terraform AWS modules](https://github.com/terraform-aws-modules/) with arguments specified in `terraform.tfvars` in layers directory. Terraform uses this during the module installation step of `terraform init` to download the source code to a directory on local disk so that it can be used by other Terraform commands. The [https://registry.terraform.io/](public Terraform registry) provides infrastructure modules for many infrastructure resources. [Terragrunt](https://github.com/gruntwork-io/terragrunt) is used to work with Terraform configurations which allows you to orchestrate dependent layers, update arguments dynamically and keep configurations. Define Terraform code once, no matter how many environments you have ([DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)). # Magento 2 Multi Regional Infastructure Support We have a global scale-out model. All data updates (POST, DELETE request) are directed to the main data center region. All GET and CACHED requess (black lines) are directed regional data centers. Geographically distant web servers add latency and degrade the shopping experience. Such mistakes can prove costly, resulting in lost customers, missed revenue, and reputational damage. Route your traffic to your regional Magento Servers based on the user's location. When you use geolocation routing, you can localize your web store and present some or all of your websites in the language of your users. You can also use geolocation routing to restrict access to the websites to only the locations you have distribution rights. Another use case is balancing load across endpoints. Can you imagine your USA-based customers' frustration when your servers are located in Norway 🇳🇴 or Australia 🇦🇺? ## Pre-requirements - [Terraform 0.12 or newer](https://www.terraform.io/) - [Terragrunt 0.19 or newer](http