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