v4 signing) • Ansible (VPC modules not production ready) • Cloud formation (JSON, 56k limit) • Chef provisioning (not production ready) • BASH scripts and Chef
10.100.0.0/27 | 10.100.10.0/27 | 10.100.20.0/27 PUB b | 10.100.0.32/27 | 10.100.10.32/27 | 10.100.20.32/27 ——————————————————————————————————- PRIV a | 10.100.1.0/27 | 10.100.11.0/27 | 10.100.21.0/27 PRIV b | 10.100.1.32/27 | 10.100.11.32/27 | 10.100.21.32/27 ——————————————————————————————————- PERSIST a | 10.100.2.0/27 | 10.100.12.0/27 | 10.100.22.0/27 PERSIST b | 10.100.2.32/27 | 10.100.12.32/27 | 10.100.22.32/27 VPC: 10.100.0.0/16 18 subnets: • Room for 30 instances in each subnet, with 21 more stacks, 7 more tiers and 6 more subnets (AZ’s) in each tier/stack available for expansion. • Network ACLs used to keep traffic within stacks, ie control IPs not ports • Security groups used to control ports, not IPs • Easier to maintain
Chef 2 bash scripts are used to create a stack: • create-varnish-autoscale.sh • create-drupal-autoscale.sh (also create-ha-nat-autoscale.sh to create the NAT infrastructure) • AWS CLI commands to create RDS instance, load balancers, elasticache clusters (instead of local memcache) launch configurations and autoscaling groups • Tags and userdata hook into Chef • S3 used for keys, website and DB content • Instances are assigned an IAM role to enable them to access S3 resources and for possible future stuff (instances cannot be given roles after creation) Stack Creation
• Roles, Environments defined Varnish cookbook: • Installs and configures varnish • Cron+BASH+AWS CLI to monitor backends and update config Drupal cookbook: • Master & slave recipes • Website content and config is downloaded from S3 and modified according to Chef attributes • DB user is created, DB is populated from S3 • lsyncd is used to replicate content to slave(s) • S3 used for master public key • Slave uses Cron+BASH+AWS CLI to monitor for changes • Cron+BASH+AWS CLI used to monitor for slave and varnish instances Chef roles
but they need to know about each other. • Drupal master and slave need to have the same config and content • Drupal needs to know about the Varnish server(s) • Varnish needs to know about the Drupal server(s) • Any instance can be blown away and replaced at any time • Autoscaling: there can potentially be 1,2,3,10 or 100 of any instance Cattle, not pets (but how do they commoonicate?)
to mean specific things by different people / products • Vanish / Drupal master / Drupal slave = ROLE • Live / Staging = ENV • Blue / Green = STACK In Blue/Green, both stacks should be identical (apart from version) BUT staging has different requirements! • Locked down access • Robots.txt - do not index! Used a bolt-on recipe to make changes for staging - needs to be removed from runlist when switching to live.