Elastic Beanstalk

What is Elastic Beanstalk?

• Elastic Beanstalk is a managed service for deploying the application. It relies on CloudFormation. 
• There is no additional charge for Elastic Beanstalk.
• It handles capacity, load balancing, scaling, monitoring
• Can store at most 1000 app versions
  • Use lifecycle policy to phase out older versions.
    • It is based in time or space.
    • Cannot delete used versions.
• You can clone an environment with Beanstalk Cloning (data is not preserved)
• Setup HTTPS: Load SSL certification to Load Balancer
  • Can be done from console or code (ebextentions)
• Ability to use Custom Platform (Advanced)
  • Define from scratch the OS and the scripts that Beanstalk run.
  • To create it you need to use the Packer software (create AMIs)
• The database will be deleted in case we delete the environment. Perhaps you want to create the database outside beanstalk.
  • For dev/test use Beanstalk to create the database. For production use a separate database.

Source Bundle

• ZIP or WAR file (you can include multiple WAR files inside your ZIP file)
• Not exceed 512 MB
• Not include a parent folder or top-level directory (subdirectories are fine)
• Optional: For a worker application that processes periodic background tasks, the source bundle must also include a cron.yaml file.

 

Environments

• Two types of environments.
  • Web Server: listen and process HTTP
  • Worker environment: Background process apps
• If the Beanstalk application performs operations or workflows that take a long time to complete, you can offload those tasks to a dedicated worker environment.

Change load balancer after the creation

You need to perform migration

• 1. Create new environment, with same configuration, but with another LB
  2. Deploy application in new environment
  3. Shift traffic from old to new

Deployment Modes

• Single Instance – Great for dev
• HA with Load Balancer – Great for prod
• Deployment Options for Updates
  • All at once
    • Fastest but with downtime
  • Rolling
    • Few instances at a time (bucket or batch)
    • You set the bucket size (for example 2 out of 4 instances).
    • First 2 out of 4 will be updated, and when healthy the rest will be updated.
    • There is a point in time where both versions are running. 
    • No additional costs
  • Rolling with additional batches
    • Same with rolling, but spins up new instances 
    • Deploy new instances for example 2 extra, 6 in total.
    • After deploying the new instances, perform a normal rolling update to the old. It keeps the existing instances.
    • Good for production 
    • Small additional cost
  • Immutable
    • Spin up new instances in new ASG, deploy there and swap all the instances when healthy
    • Longest deployment and higher additional cost
    • Spin up new ASG with the new version in parallel with the old. Easy rollbacks.
    • In the end merge the two ASGs and terminate the old version applications.
  • Canary testing – Traffic Splitting

 

Extensions

• Placed in .ebextensions/ folder in the root folder of your app
• YAML / JSON format
• .config extensions (for example .ebextensions/xray-daemon.config)
• You can use CloudFormation in this folder 

BeanStalk with Docker

• For Single Docker Container it does not user ECS, but docker launched on EC2
• Multi Docker Container creates ECS Cluster, EC2 instances run by ECS, LB, Task definitions