Elastic Beanstalk Flashcards
price
is free, but you pay for the underlying resources
3 architecture models
- single instance deployment: good for dev
- LB + ASG : for production or pre-prod web app
- ASG only: non-web apps in production
BeanStalk has three components.
- an application
- an application version, so every time you upload new code, you’ll get an application version,
- and environment name, so you’re going to deploy your code to DEV, TEST, and PROD.
And you’re free to name your environments just the way you want, and have as many environments as you wish. You’re going to deploy applications to your environments, and basically will be able to promote
these application versions to the next environments.
rollback
there is a rollback feature to previous app versions
Beanstalk workflow
you create an application, and you create an environment or multiple environments, and then, you’re going to upload a version and you’re going to give it an alias, so, just a name that you want.
And then, this alias, you will release it to environments.
deployment options for updates
- all at once - deploy in one go
- rolling: update a few instances at a time (bucket)
- rolling with additional batches
- immutable: spins up new ASG and then swaps
deployment strategy All at once
the fastest but the application has a downtime
for quick iterations in dev environment
deployment strategy Rolling
say, we have 4 instances. We define bucket size as 2. So two instances will receive update deployments, and while these 2 updates are being deployed, they will not be available. The application will still be running on the other 2, not-updated instances. So app is running below capacity. When the first two have been updated and are running with the new version, the other tow will receive update deployments.
Application is running both versions simultaneously. No additional costs
deployment strategy Rolling with additional batches
say, we have 4 instances running with version 1. We add two more instances (bucket size) with the new version. Then we start update deployment on 2 instances with the old version. So these two are not available, but we have 2 running with old version and 2 extra running with new version.
When the update on 2 instances is finished, we start update on the last 2 instances with the old version. In the end, we have 6 instances with the new version instead of initial 4, and we terminate 2 of them.
deployment strategy Rolling with additional batches
Evaluation
- app is running at capacity
- running 2 versions at the same time
- small additional cost
- longer deployment
- good for prod
deployment strategy immutable
new instances are deployed in a completely new ASG. When the new version is deployed on them, they are added to the ASG where instances are running with the old version. These old instances are then terminated.
deployment strategy immutable
Evaluation
zero downtime
the longest deployment
high costs for double capacity
quick rollback in case of failures
good for prod
blue/green deployment
is not a direct feature of AWS. Required manual intervention
- create a new environment and deploy v2 there
- it can be validated independently and rolled back
- Route 53 can be set up with weighted policies to redirect a little bit of traffic to the stage environment
- using beanstalk swap URLs when done with testing
BeanStalk can store at most how many versions
1000
if you don’t remove old - you wont be able to deploy anymore
to phase out old versions - use a lifecycle policy
lifecycle policy to remove old versions
- can be based on age - how old the version is
or - how many total versions exist
you can still choose to retain the removed version in S3
all the parameters that we set in the UI, can also be configured
in files inside folder .ebextensions in the root of your source code, with .config as file extension
It must be in the YAML or JSON formats.
you have the ability to add resources, using the EB extensions, such as RDS, ElastiCache, DynamoDB
anything that is managed by the EB extensions
gets deleted if the environment goes away. So that means that if you create for example, an ElastiCache as part of your Elastic Beanstalk environment, and then you delete your Elastic Beanstalk environment,
then your ElastiCache will go away as well.
if we wanted to connect, for example, to an external RDS database, maybe Postgresql RDS database,
then we will need to set up environment variables
with an EB extension
option_settings:
# see: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html#command-options-general-elasticbeanstalkapplicationenvironment
aws:elasticbeanstalk:application:environment:
DB_URL: “jdbc:postgresql://rds-url-here.com/db”
DB_USER: username
under the hood, Beanstalk relies on
CloudFormation = is used to provision other AWS services so we have our infrastructure as code.
using the CloudFormation resources in your .ebextensions folder
you can provision an ElastiCache, an S3 bucket, an DynamoDB table, whatever you want
with EB extensions and CloudFormation, you can configure anything you want in your AWS.
if you go in AWS Management Console to CloudFormation, you will see the resources that we reserved when we created our elastic beanstalk environment
Cloning
you can clone an existing environment into a new environment and it will have the exact same configuration.
helpful if you already have a production version of your application and you want to deploy a test version with the exact same settings.
All the resources and the configuration of the original environment are preserved so that includes the load balancer type and the configuration, the RDS database type, although if you have an RDS database, the data is not going to be preserved, but the configuration of your RDS database will,
Migration
after you create a Beanstalk environment you cannot change the Elastic Load Balancer type, only its configuration. So if you want it to somehow upgrade
from a Classic Load Balancer to an Application Load Balancer you will need to perform a migration
Migration steps
- create a new environment with the same configuration except the Load Balancer. (we can’t use the clone feature because the clone feature would copy the exact same Load Balancer type and configuration. So you have to recreate manually the same configuration)
- then we will deploy our application onto the new environment with the new load balancer
- shift the traffic from the old environment to the new environment. (CNAME swap or Route 53)
Decoupling RDS
RDS can be provisioned with your Beanstalk application, which is great if you want to do development and test.
But if you are doing a production deployment, this is not great because the database lifecycle is going to be tied to the Beanstalk environment lifecycle. So the best way to do it in prod is to separate the RDS Database from your Beanstalk environment and reference it using a connection string for example using an environment variable.
