Elastic Beanstalk service automates the building of a middleware servers (e.g. httpd servers, nginx servers,…etc) and then deploys your app into it. I.e. it is perfect for setting up a vanilla httpd server, or Rails server,…etc. This is ideal if you have a relatively simple application you want to deploy, that doesn’t require a lot of middleware configurations.
AnnouncementI have released my new course on Udemy, Kubernetes By Example. Sign up now to get free lifetime access!
Elastic Beanstalk basically does the following:
- deploys – install middleware and deploys apps into it.
- manages – e.g. OS patching, configuring firewalld, ..etc.
- auto scale up/down – add/removes instance to manage demand.
Elastic Beanstalk can install middleware in order to deploy the following types of applications:
- docker containers
some of the middleware that Elastic Beanstalk can install+configure are:
- httpd server
- nginx server
- passenger server
- apache tomcat
- Microsoft IIS
Elastic Beanstalk achieves its job by making use of:
- Simple Notication Service SNS
All you need to tell the Elastic Beanstalk service is:
- what middleware you want
- what type of app you have, e.g. ruby app
- what instance size you want, e.g. t2.micro
you can also configure it to deploy applications from git repos.
Elastic Beanstalk tool comes with it’s own cli called eb. This CLI can be used to build dev/test/prod environments based on your dev/test/prod git branches. In fact this is the preferred way using beanstalk.
It’s easy to deploy software updates, e.g. just do a git pull.
As an alternative to storing the code in git, you can store it in S3, e.g. in the form of a targz file.
To start using Beanstalk, you first have to create a new “Application”:
You just have to specify the type of middleware (ruby. php, etc.) that you want to deploy.
It will then get started by building a ‘default’ environment. You can choose to build multiple environments (dev/test/prod) inside your beanstalk based application.
There are 2 types of environments you can create inside your beanstalk ‘application’ resource:
If you want an environment that directly handles web requests (e.g. http or https), then you pick web server. However if you want an environment that runs background jobs, then you choose worker environment. Worker environment also links well with SQS, i.e. it polls the queue to processes queue jobs.
You can create multiple ‘production’ webserver+worker environments and then link them to create a single multi-tiered environment.
When creating a new web server environment, you will be prompted for the following:
- middleware type, e.g. PHP, Tomcat, Docker, …etc.
- Environment type, here you have the option to set up environment as a single instance, or autoscaling+loadbalancing
- You then get the option to upload your code, either by specifying an s3 based url to a zip file, or upload a zip file from your local desktop
- you get a checkbox, to specify whether you want an RDS instance to be created as part of your environment
- Instance specific details:
- instance type, e.g. t2.medium
- EC2 key pair, in order to ssh into your EC2 instance.
- Application healthckeck url – what url to ping to check for health
- Which VPC to create the environment in, along with ticking which subnets to build the ELB and EC2 instances in.
Each web server environment comes with it’s own unique url. You can use this to view your Elastic Beanstalk environment’s homepage, which is the php apache’s home page, if you selected apache.
You can then add a user friendly url name to point to your environment’s ELB. The ELB should be listed in the dropdown list when your creating a route 53, alias based entry.
https://aws.amazon.com/elasticbeanstalk/ (watch the video)