Elastic Beanstalk
Last updated
Last updated
AWS comprises over one hundred services, each of which exposes an area of functionality. While the variety of services offers flexibility for how you want to manage your AWS infrastructure, it can be challenging to figure out which services to use and how to provision them.
Developer need not be burden with managing all the components like ELB, ASG, EC2/ECS/EKS and other application infrastructure so as to deploy their application. With Elastic Beanstalk, one can just upload your application code and Beanstalk will manage capacity provisioning, scaling, health monitoring etc as per configuration provided in the template. This takes away the burden of infrastructure management from developers.
One can develop applications in variety of languages like Go, Java, .NET, Node.js, PHP, Python, and Ruby and deploy them in Beanstalk.
Elastic Beanstalk is free in itself and one needs to only pay for the underlying infrastructure being used.
Elastic Beanstalk under the hood uses CloudFormation to deploy resources.
Application version
a specific, labeled iteration of deployable code for a web application. An application version points to an Amazon Simple Storage Service (Amazon S3) object that contains the deployable code, such as a Java WAR file. An application version is part of an application. Applications can have many versions and each application version is unique.
Environments
It is a collection of AWS resources running an application version. Each environment runs only one application version at a time, however, you can run the same application version or different application versions in many environments simultaneously.
Enivronment tier
When you launch an Elastic Beanstalk environment, you first choose an environment tier. The environment tier designates the type of application that the environment runs, and determines what resources Elastic Beanstalk provisions to support it.
Tiers include web server environment tier, worker environment tier.
Platform
A platform is a combination of an operating system, programming language runtime, web server, application server, and Elastic Beanstalk components. You design and target your web application to a platform. Elastic Beanstalk provides a variety of platforms on which you can build your applications.
Single instance mode, typically for development environment.
High availability mode, typically for production environment.
All at once
No
Yes
Rolling update
No
No
Rolling update with additional batches
Yes
No
Immutable
Yes
No
Traffic splitting, (canary testing)
Yes
No
Blue Green (not direct option)
Yes
No
Refer here for more info.
A CLI tools which enables a user to work with elastic bean stalk via command line.
Commands for EB CLI can be found here.
Upto 1000 application versins can be stored in an account.
Once the limit is reached, the Beanstalk wont be able to deploy application unless the older versions are deleted.
To phase out older versions of application, one can use the lifecycle mechanism.
Based on time deletion
Based on space deletion (when there are too many versions)
.ebextensions directory located in root directory helps user to configure parameters like environment variables etc.
All files within the directory must be either follow YAML or Json file format and must end with extension .config.
Clone an environment with exact same configuration, which is useful for deploying a test environment.
All resources are preserved as the source.
After creating an environment in Elastic Beanstalk, one cannot change the type of load balancer. Though configuration of existing load balancer can be changed, one cannot change type of existing load balancer from application load balancer to say another type such as network load balancer.
Cloning will not work here, as clone also will create existing type of load balancer in the cloned environment.
So one must create a separate environment with all same configuration except along with desired type of load balancer. Once done deploy your application and shift the traffic by doing a DNS update or CNAME swap.
Typically Database lifecycle is tied to Beanstalk environment and would be deleted once environment is deleted.
In order to avoid deletion, one should provision RDS separately and use connection string to connect the application from with Beanstalk environment to the RDS.
However to migrate the existing RDS within the current Beanstalk environment to the new environment is as follows,
Create a snapshot of RDS database.
Enable delete protection on the instance from RDS console.
Create new Beanstalk environment without RDS and point the application to the existing RDS.
Now do a CNAME swap or route 53 update and test the connection.
Terminate the current Beanstalk environment, however the RDS wont be deleted as delete protection is enabled for it.
This will fail the Beanstalk deletion.
Go to CloudFormation service and delete the Beanstalk stack manually.
