What You'll Miss On AWS
& How To Find It Again
@M1ke
Mike Lehan
S3: Simple Storage Service
EC2: Elastic Compute Cloud
RDS: Relational Database Service
EBS: Elastic Block Store
EFS: Elastic File System
ELB: Elastic Load Balancer
First, Acronyms!
Cheap file storage
Servers!
No more my.cnf!
Hard disks!
Networked HDD
You'll see!
| What you'll miss | How we solve it | |
|---|---|---|
| 1 | Your server actually being there | Launch servers in multiple availability zones |
| 2 | Domain mapping to an IP | Load balancing with a Route 53 alias |
| 3 | Users having consistent sessions | Enable sticky sessions |
| 4 | Making server config changes | Auto scaling groups & automated machine imaging |
| 5 | Using the file system | Elastic File System |
| 6 | SSH access to your server | Elastic IP and Lambda functions |
| 7 | Files uploading quickly | Multi-stage deployments |
| 8 | Sub 1s PHP execution times | Zend Opcache |
| 9 | Cron! | Scheduled Lambda functions |
tl;dr
Is this really the best way of doing things?
You'll miss: your server actually being available
eu-west-1 (Dublin) or eu-west-2 (London)
- Launch servers in multiple availability zones
- If using RDS, choose the "Multi AZ" option
- Use an "auto scaling group" to guarantee servers in a specified number of AZs
- No need to worry about S3, EFS or Lambda - synced across AZs automatically
You'll miss: domains mapping to IPs
- You don't need to worry about its AZ
- It can target a group of instances
- Even checks if an instance can receive HTTP connections
- Called a "balancer" but really just directs traffic randomly
- Because you obviously all use TLS, you'll need to give the Load Balancer your private key
You'll miss: users having consistent sessions
Sticky sessions!
You'll miss: making server config changes on the fly
Behold the "master" instance!
Be lazy; use Lambda!
- Check for AMIs in our account with a specific "tag"
- If there are more than 1, delete all but the newest - helps keep our S3 costs down and our account tidy
- Get the current launch configuration of our autoscaling group - we can assume this works
- Replace the variables in the data for the AMI ID and snapshot ID
- Create a new launch configuration
- Apply the launch configuration to the autoscaling group
Next, hacks and magic!
Autoscaling lets us make scheduled actions
It also lets us choose how it terminates instances
In summary
- Edit your master server
- Switch off your master server
- Make an image of it
- Create a launch configuration with that image
- Set your autoscaling group to use the new launch configuration
- Cycle out your old instances
- ?
- Profit
You'll miss: using the file system
How are there are no memes about file systems?
This bit
Connect from any AZ
Works as a network mount
EFS is also "limitless"
The "E" stands for exabyte:
1,000,000,000,000,000,000 bytes
You'll miss: SSH access to your server
Elastic IP
.ssh/config
You'll miss: files uploading quickly
EFS slow down means your app files might end up inconsistent
If your app can't tolerate this you need to use atomic deployments
- Deploy your application to a writable directory on whichever server you have an elastic IP attached to
- Trigger a process on the server to copy your files to a named release folder (e.g. timestamp) on EFS
- Repoint a symlink to which your web server config points as the application root
Many deployment programs that use a remote agent (e.g. capistrano) already use this technique. We rolled our own in bash
You'll miss: PHP scripts executing in less than a second
Seriously, can we not have cool logos for PHP mods?
/etc/php/7.(0|1)/mods-available/opcache.ini
Easy right?
github.com/rlerdorf/opcache-status
You'll miss: crontab for scheduling jobs
Why did I commit to this meme thing?
Logging is fun...
Sounds like you'll miss a lot...
What do you gain?
- Ability to offer "always up" web services to your company or clients without building your own data centre(s)
- A growing standard for how distributed applications behave
- Stupidly cheap storage on S3 and processing on Lambda
- Bulletproof backups
- Multiple options for data sovereignty
AWS might appear hard, but it's easier than finding a relevant meme for each item in a list of infrastructure problems!
Liked this talk?
Let me know!
@m1ke on Twitter
github.com/m1ke
Enjoy the rest of PHPNW17
Please leave feedback
https://joind.in/talk/0e908
