First, make sure you have an EC2 instance profile that can be used for your Beanstalk environment. If you’re wondering what that is or how to create an EC2 instance profile, please refer to Chapter 5, Determining Security Requirements and Controls. The sample application simply displays Hello World on a web page, so you do not need to provide any specific permission to the instance role assigned to your instance profile. Now, after your instance profile has been defined, you can proceed to create your Beanstalk environment and deploy your application. Carry on with this next step:
$ eb create –instance_profile aws-elasticbeanstalk-sample-role
This command instructs Beanstalk to do the following:
- Create the necessary resources to support your application.
- Deploy your application once those resources are in place.
Beanstalk will again ask you a couple of questions to clarify what sort of infrastructure you want to create. You will provide additional information such as the following:
- The name for your Beanstalk environment, so that you can look it up later on (for instance, in the AWS Management Console)
- A DNS CNAME that Beanstalk will use to create the necessary DNS records with Amazon Route53 so that your web application can be reached
- The type of ELB load balancer that you would like to use (Application Load Balancer or Network Load Balancer)
Beanstalk will then create all the relevant resources on your behalf: the ELB load balancer, the EC2 instance, the Auto Scaling group (the mechanism for scaling your infrastructure), and security groups (virtual firewalls to protect your resources and control the traffic that can reach them). Once the environment creation is complete, Beanstalk will install and configure the engine runtime you specified and deploy your application on top of it.
And that’s it! From this point on, your application is up and running. As you can see, it’s pretty straightforward and doesn’t require any prior knowledge of AWS besides a high-level understanding and the ability to look up the AWS IAM documentation to create an EC2 instance profile. You could even have a simpler experience if you use the AWS Management Console (you then don’t need to worry about the EC2 instance profile) to do everything we just did via the command line.
When you need to make further developments and iterate over multiple versions of your application, Beanstalk offers multiple options to release updates for your application. These options are discussed in detail here:
- All-at-once deployment: This option consists of replacing your existing application with the new version on all the currently deployed EC2 instances.
- Rolling deployment: With this second option, Beanstalk does a rolling update by progressively deploying your new version on a subset of your environment, updating a batch of EC2 instances at a time. With this option, the old and new releases of your application co-exist for the time the rolling update takes, so a portion of the incoming requests will still be served by your existing application. Before updating a batch of EC2 instances with the new release of your application, Beanstalk will detach them from the load balancer. You can enable connection draining before this happens to avoid breaking in-flight transactions. After deploying the new release on a batch of EC2 instances, if the release passes health checks successfully within the allocated time, Beanstalk carries on with the next batch of instances. In the case of health check failures or timeouts, and unless you specified ignoring health checks, Beanstalk will declare the deployment as failed and stop rolling out the new application. This may have the undesired effect of leaving your environment partly running the new release of your application and partly still running the old release. It is then up to you to carry out a new deployment to fix this situation in whichever way you see fit, for instance, by re-deploying the old release.
- Rolling deployment with an additional batch: As you’ve just seen, during a rolling deployment, some instances are taken offline to proceed with the new release’s deployment, which means that your workload stops operating at full capacity. This might be an issue depending on the incoming traffic hitting it at that moment in time. This is why Beanstalk made a third option available, namely, Rolling deployment with an additional batch. This option lets you spin up a batch of fresh instances before taking any of your existing instances offline for updating. Once the deployment is completed, Beanstalk will tear down the extra capacity.
- Immutable deployment: With this option, Beanstalk adds brand-new EC2 instances in a separate Auto Scaling group where it deploys the new release of your application. Your old release, including all its infrastructure resources, is left intact until your new release successfully passes health checks. Only then does Beanstalk stop the old release and tear down all its infrastructure resources (such as EC2 instances and their Auto Scaling group). If the health checks fail, then the old release of your application and all of its infrastructure remain in place as if nothing happened, and the freshly created resources supporting the new release are terminated.
- Traffic-splitting deployment: Beanstalk provides yet a fifth deployment option, namely, Traffic-splitting deployment, which, similar to immutable deployment, launches a set of new instances wherein you can deploy the new release. Once the new release is deployed, only a portion of the incoming traffic is diverted to these new instances for the evaluation period that you specify. If, at the end of the evaluation period, the new instances remain healthy, Beanstalk will send all traffic to them and terminate the old instances. If they’re unhealthy, all traffic moves back to the old instances and the new instances are terminated. This deployment option lets you avoid any traffic interruption.
If you don’t explicitly specify a deployment strategy, Beanstalk defaults to an all-at-once strategy. However, if you deploy your application via the CLI, as we just did, Beanstalk defaults to a rolling update strategy.
