& 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!

tl;dr

Is this really the best way of doing things?

You'll miss: your server actually being available

1. Launch servers in multiple availability zones
2. If using RDS, choose the "Multi AZ" option
3. Use an "auto scaling group" to guarantee servers in a specified number of AZs
4. No need to worry about S3, EFS or Lambda - synced across AZs automatically

You'll miss: domains mapping to IPs

1. You don't need to worry about its AZ
2. It can target a group of instances
3. Even checks if an instance can receive HTTP connections
4. Called a "balancer" but really just directs traffic randomly
5. 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!

1. Check for AMIs in our account with a specific "tag"
2. If there are more than 1, delete all but the newest - helps keep our S3 costs down and our account tidy
3. Get the current launch configuration of our autoscaling group - we can assume this works
4. Replace the variables in the data for the AMI ID and snapshot ID
5. Create a new launch configuration
6. 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

1. Edit your master server
2. Switch off your master server
3. Make an image of it
4. Create a launch configuration with that image
5. Set your autoscaling group to use the new launch configuration
6. Cycle out your old instances
7. ?
8. 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

1. Deploy your application to a writable directory on whichever server you have an elastic IP attached to
2. Trigger a process on the server to copy your files to a named release folder (e.g. timestamp) on EFS
3. 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?

1. Ability to offer "always up" web services to your company or clients without building your own data centre(s)
2. A growing standard for how distributed applications behave
3. Stupidly cheap storage on S3 and processing on Lambda
4. Bulletproof backups
5. 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