For some time I fear to face AWS Elastic Beanstalk cause it is indeed a pretty complicated service but today, I finally have the courage to start getting to know it.
AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS.
You can simply upload your code and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring. At the same time, you retain full control over the AWS resources powering your application and can access the underlying resources at any time.
You would be surprised for how many services that AWS EB runs for you in the background, here is the list
1. EC2
2. Security Group ( S.G )
3. Load Balancer
4. Load Balancer S.G
5. Auto Scaling Group
6. S3 Bucket
7. CloudWatch Alarms
8. CloudFormation Stack
9. Domain name
Deployment update options and how they work
1. All at once.
Deploy the new version to all instances simultaneously. All instances in your environment are out of service for a short time while the deployment occurs.
2. Rolling.
You choose the % of total existing instances ( batch ) to be updated. For example, 50 % of a total of 4 instances will have 2 instances in a batch. Updates are installed to batch first, after passing health check, update the remaining instances. During batch update, instances in batch are detached from ELB causing the capacity of your application to drop down.
3. Rolling with additional batch.
To solve the capacity drop down issue, provision additional instances and perform update. 50 % of a total of 4 instances will provision 2 extra instances with updates installed first, causing a total of 6 instances and serving both new and old contents at the same time. After the 2 new instances pass health check, updates are applied to 2 of the existing instances. After the 2 old instances pass health check, the last 2 old instances are terminated.
4. Immutable.
Build first then destroy. With total of 4 instances, when updating, a new updated instance will be provision first with a temperately A.S.G. After health check pass, it will extend to a total of 4 updated instances. After health check pass, temperately A.S.G is deleted and the original A.S.G’s value is change from 4 to 8. At the moment, new and old contents are serving at the same time. Then, out-dated instances are started to terminate, one at a time, till the 4 updated instances are remained.
Enough talking, let’s start the walk through.
Give your application a name, upload a php testing zip file where it prints out the local server IP.
<?php
echo “My IP is : “ . $_SERVER[‘SERVER_ADDR’] . “\n”;
echo “ I am version 4”;
?>
This is the place where you can configure your infrastructure to run your application.
In the walk through, I modified necessary settings so that I can try out application updating later on.
Here is the place where you configure how you want to update your application. If you did not choose more than 2 instances in the Capacity option, you will only see All at once and Immutable.
Click Create app at the bottom right corner and you will see the creation begins.
A finish view of Elastic Beanstalk.
You can find your Elastic Beanstalk connection address on the top of page or in the Recent Events list. Verify that EB works. We can see that traffics are indeed routed to 2 instances and codes are working.
To update your application, click on Upload and Deploy where you can upload your new code and choose the way how to update it.
I tried out all 4 different types of updating options but don’t have screen shoots for them cause it would be too many images. Try them out and at the same time, monitor/check out EB’s Health, Events, Monitoring, EC2, Targets under Load Balancing Target Groups and Auto Scaling Groups during updating. It helps a lot to understand how EB updates works at the background!
To delete EB, simply click Terminate Environment
After the deletion is completed, you will find that the S3 bucket created by EB is not delete and you cannot delete it manually either. That’s cause EB applies a bucket policy to the bucket to prevent accidental deletion. Simply delete the policy of the bucket from Permissions section then you are good to delete the bucket.
