In a serie of blog articles I’ll take a closer look at the available CI/CD development tools, serverless architecture and orchestration services (like Elastic Beanstalk and Cloudformation) in AWS. In my previous blog article “AWS and DevOps – Elastic Beanstalk: Application Lifecycle” you can read more about what Elastic Beanstalk is and the Application Lifecycle. In this blog article I’ll go into more detail about the platform configuration in Elastic Beanstalk.
When building an application in Elastic beanstalk, the platform configuration is where you define your infrastructure and software stack to be used for the given language environment. You can select the configuration presets: Low cost (free tier), high availability and custom. When selecting high availability you automatically will have more EC2 instances, a loadbalancer and an auto scaling group that will be monitored by Elastic BeanStalk. This all can be configured in detail. Health monitoring goes beyond just monitoring the EC2 instances. The actual HTTP data is being monitored, or rather the status codes as they’re going to and returning from your application. This is part of the enhanced health monitoring in Elastic BeanStalk, and relies on a set of rules determining the health of your environment. Optionally you can ignore any 4xx HTTP errors in Elastic BeanStalk by configure ‘ignore 4xx Errors’
Elastic beanstalk will use different resources and services within AWS to deploy and manage the environment. The list is too long to describe them all. But to give an idea of the most commonly used services/resources here’s a small list.
EC2 is a virtual computing environment, that enables customers to use Web service interfaces to launch instances with a variety of operation systems, load them with your custom applications manage your network access permissions, and run your image using as many or few systems as you need.
Elastic Load Balancer
The load balancer distributes traffic among your environment’s instances. Elastic Beanstalk supports these load balancer types:
- Classic Load Balancer – The Elastic Load Balancing previous-generation load balancer. Routes HTTP, HTTPS, or TCP request traffic to different ports on environment instances.
- Application Load Balancer – An application layer load balancer. Routes HTTP or HTTPS request traffic to different ports on environment instances based on the request path.
- Network Load Balancer – A network layer load balancer. Routes TCP request traffic to different ports on environment instances. Supports both active and passive health checks.
By default, Elastic Beanstalk creates an Application Load Balancer for your environment when you enable load balancing with the Elastic Beanstalk console or the EB CLI. It configures the load balancer to listen for HTTP traffic on port 80 and forward this traffic to instances on the same port.
Auto Scaling monitors your application/resources and automatically adjusts the capacity to maintain a steady and predictable performance of your environment. When you decide to create a high available environment for your application, auto scaling is one of the services that will be configured.
S3 is an object storage service that offers availability, durability and performance. Elastic beanstalk will use S3 to store your source code, logs and other artifacts that are created for your application.
Cloudwatch is a monitoring and management service that provides you with data to monitor your applications. Cloudwatch can respond to system-wide performance changes. Elastic beanstalk automatically configures cloudwatch alarms that monitor the EC2 instances and are triggered when the load is too high or too low. When an alarm is triggered, your auto scaling group scales up or down in response.
The provisioning of the platform is handled by CloudFormation. This is another service of AWS that provides a common language (Json or YAML) to describe and provision all the AWS resources in your cloud environment. It basically is infrastructure as Code. I’ll cover this in another blog.
After your environment is deployed by EB the application has a CNAME (URL) that routes the traffic to your application. Route53 is the DNS service in AWS and takes care of your zones. A domain name in Elastic beanstalk looks like this: subdomain.region.elasticbeanstalk.com.
Within your application in Elastic beanstalk, you can specify how to deploy your application by selecting the deployment policy. Every time you deploy a new version of your application to the platform, Elastic Beanstalk will deploy this by the policy you enforced on your application. We can broadly define two ways of deployment, with downtime (all at once) and without downtime (rolling deployment and immutable deployment).
All at Once
By default this policy is used when you select an environment that doesn’t include autoscaling. All at once deployment means downtime because all instances are updated simultaneously.
With rolling deployment your environment is split into batches and Elastic Beanstalk will deploy the new version of the application to one batch at a time. During the deployment some instances will serve the old application while instances in the completed batch will serve requests from the new version. This means your capacity is being reduced during the deployment.
Rolling deployment with an additional batch
To maintain full capacity during deployments you can launch a new batch of instances before taking any instances out of service. This deployment is known as Rolling deployment with an additional batch.
Immutable deployments can prevent issues caused by partially completed rolling deployments. This is accomplished by launching a new set of instances running this new version of the application in a seperate Auto Scaling Group, alongside the ‘old’ instances. If the new instances don’t pass the health checks they will be terminated by Elastic Beanstalk (rollback). Within the configuration of your application in Elastic Beanstalk you have the option to ignore health checks. This can be helpfull when you want to force an update regardless of the health status of the instances. Also, you can allow instances to pass health checks with lower status, such as warning. By default, Elastic Beanstalk will terminate your new instances if any health check will fail.
Blue/green deployments in Elastic Beanstalk can not be compared to one of the deployment policies described above. With a blue/green deployment in Elastic Beanstalk you have full control of the deployment as with the deployment policies you let Elastic Beanstalk do the deployment of the application. By performing a blue/green deployment, you deploy the new version to a separate environment, and then swap CNAMEs of the two environments to redirect traffic to the new version instantly.
A blue/green deployment requires the following manual steps:
- Clone current environment
- Deploy new application to the new environment
- Test new application
- Swap environment URLs from the AWS console
A blue/green deployment can also be helpful if you want to do a platform upgrade. The swap URL option becomes available when your deploy two environments in Elastic beanstalk for the same application language.They turn green in your console after deploying and the swap URL option will handle the configuration in Route53. Because it’s an alias CNAME ,which points to an resource in AWS (ARN) you don’t have any caching issues on external resolvers.
Blue/green deployments require that your environment runs independently of your production database, if your application uses one. If your production database is part of your environment you have to be aware that the data will not be transferred over to your second environment, and will be lost if you terminate the original environment.
Aside from deploying your application you also have to deal with configuration changes in your environment. When you modify configuration settings in the environment, Elastic beanstalk will propagate this to all affected resources. Many configuration changes can be applied to running instances without downtime, because you’re running a high available infrastructure or because Elastic Beanstalk doesn’t have to replace the running instances. In some situations it will replace running instances. For example, when you decide to change the security of your EC2 instance (you want to deploy your ssh private key for example, which is stored in AWS), this results in a deployment of a new instance. The running instance will be terminated and replaced by a new instance with your new ssh key.
Rolling updates occur when you change settings that require new Amazon EC2 instances to be provisioned for your environment (in the example of deploying new ssh keys). To prevent downtime during these processes, Elastic beanstalk applies these configuration changes in batches, keeping a minimum number of instances running and serving the traffic at all times.
Elastic beanstalk waits after it finished the batch before continuing with the next batch. This can be affected by changing the update type. There are three update types available:
Rolling based on health
Wait until the current batch is healthy before placing the instances in service and starting the next batch.
Rolling based on time
Wait an amount of time before moving on to the next batch.
Updates are applied to a new fresh group of instances. This can be compared to the immutable deployment.
Vincent Lamers, Linux-consultant @ AT Computing