CODEWITHSUNDEEP
amazon-web-servicesgithubamazon-ec2load-balancingamazon-elb
Matthew Housser
Matthew Housser

Reputation: 1012

Deploying to EC2 instances behind a load balancer; PHPStorm + GitHub

I know this has been partially answered in a bunch of places, but the answers are so.. all over the map, dated and not well explained. I'm looking the best practice as of February 2016.

The setup:

A PHP-based RESTful application service that lives in an EC2 instance. The EC2 instance uses S3 for uploaded user data (image files), and RDS MySql for its DB (these two points aren't particularly important.)

We develop in PHPStorm, and our source control is GitHub. When we deploy, we just use PHPStorm's built-in SFTP deployment to upload files directly to the EC2 instance (we have one instance for our Staging environment, and another for our Production environment). I deploy to Staging very often. Could be 20 times a day. I just click on a file in PHPStorm and say 'deploy to Staging', which does the SFTP transfer. Or, I might just click on the entire project and click 'deploy to Staging' - certain folders and files are excluded from the upload, which is part of PHPStorm's deployment configuration.

Recently, I put our EC2 instance behind a Load Balancer. I did this so that I can take advantage of Amazon's free SSL offering via the Certificate Manager, which does not support individual EC2 instances.

So, right now, there's a Load Balancer with only a single EC2 instance behind it. I maintain an Elastic IP pointing to the EC2 instance so that I can access it directly (see my current deployment method above).

Question:

I have not yet had the guts to create additional (clone) EC2 instances behind my Load Balancer, because I'm not sure how I should be deploying to them. A few ideas came to mind, but they're all pretty hacky.

Given the scenario above, what is currently the smoothest and best way to A) quickly deploy a codebase to a set of EC2 instances behind a Load Balancer, and B) actually 'clone' my current EC2 instance to create additional instances.

I haven't been able to really paint a clear picture of the above in my head yet, despite the fact that I've gone over a few (highly technical) suggestions.

Thanks!

Upvotes: 1

Views: 1143

Answers (1)

Matt Houser
Matt Houser

Reputation: 36073

You need to treat your EC2 instance as 100% dispensable. Meaning, that it can be terminated at any time and you should not care. A replacement EC2 instance would start and take over the work.

There are 3 ways to accomplish this:

Method 1: Each deployment creates a new AMI image.

When you deploy you app, you deploy it to a worker EC2 instance whose sole purpose is for "setup" of your app. Once the new version is deployed, you create a fresh AMI image from the EC2 instance and update your Auto Scaling launch configuration with the new AMI image. The old EC2 instances are terminated and replaced with the new code.

New EC2 instances have the recent code already on them so they're ready to be added to the load balancer.

Method 2: Each deployment is done to off-instance storage (like Amazon S3).

The EC2 instances will download the recent code from Amazon S3 and install it on boot.

So to put the new code in action, you terminate the old instances and new ones are launched to replace them which start using the new code.

This could be done in a rolling-update fashion, or as a blue/green deployment.

Method 3: Similar to method 2, but this time the instances have some smarts and can be signaled to download and install the code.

This way, you don't need to terminate instances: the existing instances are told to update from S3 and they do so on their own.

Some tools that may help include:

  • Chef
  • Ansible
  • CloudFormation

Update:

Methods 2 & 3 both start with a "basic" AMI which is configured to pull the webpage assets from S3. This AMI is not changed from version-to-version of your website.

For example, the AMI can have Apache and PHP already installed and on boot it pulls the .php website assets from S3 and puts them in /var/www/html.

CloudFormation works well for this. In addition, for method 3, you can use cfn-hup to wait for update signals. When signaled, it'll pull updated assets from S3.

Another possibility is using Elastic Beanstalk which could be used to manage all of this for you.

Update:

To have your AMI image pull from Git, try the following:

  1. Setup an EC2 instance with everything installed that you need to have installed for your web app
  2. Install Git and setup a local repo ready to Git pull.
  3. Shutdown and create an AMI of your instance.

When you deploy, you do the following:

  1. Git push to GitHub
  2. Launch a new EC2 instance, based on your AMI image.

As part of the User Data (specified during the EC2 instance launch), specify something like the following:

#!/bin/sh
cd /git/app
git pull
; copy files from repo to web folder
composer install

When done like this, that user data acts as a script which will run on first boot.

Upvotes: 2

Related Questions