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.
Decoupling RDS steps
- create a snapshot of our RDS Database as a safeguard in case things go wrong, so we have a backup or data
- go to the RDS console and protect the RDS Database from deletion. This will prevent it from being deleted no matter what
- we create a new Elastic Beanstalk environment, this time without RDS. And we point our application to the already existing RDS Database, for example, using an environment variable. So now we have the new environment pointing to the same database.
- perform a CNAME swap, so a blue/green deployment or route 53 DNS updates and we confirm it’s working.
So now we have shifted all the traffic from the old version to the new version then we terminate the old environment. And because we have enabled RDS deletion protection then RDS will stay.
- Because it’s the CloudFormation stack, behind our Elastic Beanstalk environment - it will be in the Delete Failed state, but not deleted. And so we need to just go in CloudFormation and delete that CloudFormation stack manually.
run our application as a single Docker container
either provide
- Dockerfile: E Beanstalk will build and run the Docker container
or
- Dockerrun.aws.json (v1): Describe where already built Docker image is
if you use a single container mode for Docker, it does not use ECS behind the scenes, it just uses Docker on EC2.
multi Docker container
helps you run multiple containers per EC2 instance in Elastic Beanstalk.
It will create for you:
- ECS cluster
- EC2 instances configured to use this cluster
- LoadBalancer in high availability mode
- task definitons and execution
Requires Dockerrun.aws.json (v2) at the root of the source code. It is used to generate ECS task definition
Docker images must be pre-built and stored for ex., on Docker Hub
HTTPS on Beanstalk
- Beanstalk with HTTPS
2. Beanstalk redirect HTTP to HTTPS
Beanstalk with HTTPS
Load SSL certificate onto Load Balancer (from EB console or from ebextensions/securelistener-alb.config)
The certificate can be provisioned via ACM or CLI
Configure security group to allow incoming port 443
Beanstalk redirect HTTP to HTTPS
configure your instances or your load balancer to redirect HTTP to HTTPS
web server versus a worker environment
if you’re performing tasks that are very long to complete, you want to offload these tasks to a dedicated environment called a worker environment,
this is to decouple your application into two tiers
For this you can define these periodic tasks into a cron.yaml
you have your web tier which is corresponding to your load balancer and your auto scaling group
and then you would send the messages to an SQS Queue, and your worker tier will be reading from the SQS Queue, and performing these long tasks for you,
custom platform (advanced)
allow you to define from scratch the operating system, the additional software, the scripts that Beanstalk runs on these platforms,
the only use case for a custom platform is if you have an application language that is both incompatible with Beanstalk and also does not use Docker,
To create your own custom platform (advanced)
define your own AMI using a platform.yaml file, and then you need to use the Packer software, which is an open source tool to create AMI, to build that platform,
I am creating an application and would like for it to be running with minimal cost in a development environment. I should run it in
Single Instance Mode
I would like to customize the runtime of Elastic Beanstalk and include some of my company wide security software. I should
provide a custom platform
I would like to update my development environment as soon as a new version is available. Because my Elastic Beanstalk environment is internal and only used by me, I don’t mind downtime. Which deployment options is the best fit?
All at once
I would like to update my Elastic Beanstalk application so that we are able to roll back very quickly in case of issues with the new application version. Which deployment mode is the best fit?
immutable
to roll back quickly, this deployment mode terminates the temporary ASG that has the new version, while the current one is untouched and already running at capacity
I want to update my Elastic Beanstalk application gradually without incurring new costs on update. My application has been over provisioned and can temporarily decrease in size for the number of serving instances, but I still want to serve my users without downtime. I do not want to incur extra costs over updates. Which deployment mode is the best fit?
Rolling
We would like to update our EB application with minimal added cost, while maintaining the full capacity to serve our current users in production. Which deployment is the best fit?
Rolling with additional batches
I would like to create an ElastiCache with my Elastic Beanstalk environment. I should
create an elasticcache.config file in .ebextensions folder at the root of the code zip file and provide the configuration
My deployments on Elastic Beanstalk have been painfully slow, and after looking at the logs, I realize this is due to the fact that my dependencies are resolved on each EC2 machine at deployment time. How can I speed up my deployment with the minimal impact?
resolve dependencies beforehand and package them into zip file uploaded to Elastic Beanstalk
You would like your Elastic Beanstalk environment to expose an HTTPS endpoint instead of an HTTP endpoint in order to get in-flight encryption between your clients and your web servers. What must be done to setup HTTPS on Beanstalk?
create an .ebextensions/elb.config file to configure LB
How can you remove older versions that are not used by Elastic Beanstalk so that new versions can be created for your applications?
Use Lifecycle policy
You are looking to perform a set of repetitive and scheduled tasks asynchronously. Which Elastic Beanstalk environment should you setup?
set up a worker environment and cron.yaml
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features-managing-env-tiers.html
You have created a test environment in Elastic Beanstalk and as part of that environment, you have created an RDS database. How can you make sure the database can be explored after the environment is destroyed?
make a snapshot of the database before it is deleted
