Updating ElasticBeanstalk

EBS Deployment Policies

Elastic Beanstalk supports several options for processing deployments:

  • All at once
  • Rolling
  • Rolling with additional batch
  • Immutable

All at Once Deployment Policy

  • Deploys the new version to all instances simultaneously
  • All of your instances are out of service while the deployment takes place
  • You will experience an outage while the deployment is taking place - not ideal for mission-critical production systems
  • If the update fails, you need to roll back the changes by re-deploying the original version to all your instances
  • Use this in test or dev environment unless business is prepared to have some down time.

Rolling Deployment Policy

  • Deploys the new version in batches
  • Each batch of instances is taken out of service while the deployment takes place
  • Your environment capacity will be reduced by the number of instances in a batch while the deployment takes place
  • Not ideal for performance sensitive systems
  • If the update fails, you need to perform an additional rolling update to roll back the changes
  • If you have 10 environments and have batches of 2, 2 of the environments will go down at a time

Rolling with Additional Batch Policy

  • Launches an additional batch of instances
  • Deploys the new version in batches
  • Maintains full capacity during the deployment process
  • If the update fails, you need to perform an additional rolling update to roll back the changes
  • EXAM QUESTION: If you can't have downtime and need full capacity, use ROLLING WITH ADDITIONAL BATCH POLICIES
    • if you can have downtime, choose all at once or rolling deployment if you can have some instances that are out of service

Immutable Deployment Policy

  • Deploys the new version to a fresh group of instances in their own new autoscaling group
  • When the new instances pass their health checks, they are moved to your existing auto scaling group
    • Old instances are terminated
  • Maintains full capacity during the deployment process
  • The impact of a failed update is far less, and the rollback process requires only terminating the new auto scaling group
  • Preferred option for Mission Critical Production Systems

Lab Notes

  • You can only choose all at once or immutable if you only have 1 EC2 instance.
  • If you had 2 behind and elastic load balancer, you'd have more options
  • Most important thing for exam is the four policies and which scenarios to use them.

Updating Elastic Beanstalk Exam Tips

  • Remember the 4 different deployment approaches:
    • All at once
      • Service interruiption while you update the entire environment at once
      • To roll back, perform a further all at once upgrade
    • Rolling
      • Reduced capacity during deployment
      • To roll back, perform a further rolling update
    • Rolling with Additional Batch
      • Maintains full capacity
      • To roll back, perform a further rolling update
    • Immutable
      • Perferred option for mission critical production systems
      • Maintains full capacity
      • To roll back, just delete the new instances and auto scaling group

Updating Extras

You can use Elastic Beanstalk Console or the CLI to update your environment's platform version. Depending on the platform version you'd like to update to, Elastic Beanstalk recommends one of two methods for performing platform updates.

Method 1 - Update your Environment's Platform Version

This is the recommended method when you're updating to the latest platform version, without a change in runtime, web server, or application server versions, and without a change in the major platform version. This is the most common and routine platform update. This would be updating from version 7.1 to 7.2.

Method 2 - Perform a Blue/Green Deployment

This is the recommended method when you're udpating to a different runtime, web server, or application server versions, or to a different major platform version. This is a good approach when you want to take advantage of new runtime capabilities or the latest Elastic Beanstalk functionality. This would be updating from version 7 to version 8.

Updating Extras Continued

Because AWS Elastic Beanstalk performs an in-place update when you update your application versions, your application can become unavailable to users for a short period of time. You can avoid this downtime by performing a blue/green deployment, where you deploy the new version to a separate environment, and then swap CNAMES of the two envirnoments to redirect traffic to the new version instantly.

Blue/Green deployments require that your environment runs independently of your production database, if your application uses one. If your environment has an Amazon RDS DB instance attached to it, the data will not transfer over to your second environment, and will be lost if you terminate the original environment.

Updating your EB Environment's Platform Version

Changing instance type of Elastic Beanstalk Environment

The Elastic Beanstalk console and EB CLI set configuration options wh en you create an environment. You can also set configuration options in saved configurations and configuration files. If the same option is set in multiple places, the value used is determed by order of precedence.

Configuration option settings can be compsoed in text format and saved prior to environment creation, applied during environmentt creation, and added modified or removed after environment creation.

During environment creation, configuration options are applied from multiple sources with the following precedence, from highest to lowest:

  • Settings applied directly to the environment
    • Settings specified during a create environment or update environment operation on the Elastic Beanstalk API by any client, including the AWS Management Console, EB CLI, AWS CLI, and SDKs. The AWS Management Console and EB CLI also apply recommended values for some options that apply at this level unless overridden
  • Saved Configurations
    • Settings for any options that are not applied directly to the environment are loaded from a saved configuration, if specified.
  • Configuration files (.ebextensions)
    • Settings for any options that are not applied directly to the environment, and also not specified in a saved configuration, are loaded from configuration files in the .ebextensions folder at the root of the application source bundle.
    • Configuration files are executed in alphabetical order. For example, .ebextensions/01run.config is executed before .ebextensions/02do.config
  • Default Values
    • If a configuration option has a default value, it only applies when the option is not set at any of the above levels.

If the same configuration option is defined in more than one location, the setting with the highest precedence is applied. When a setting is applied from a saved configuration or settings applied directly to the environment, the setting is stored as part of the environment's configuration. These settings can be removed with the AWS CLI or with the EB CLI.

Settings in configuration files are not applied directly to the environment and cannot be removed without modifying the configuration files and deploying a new application version. * If a setting applied with one of the other methods is removed, the same setting will be loaded from configuration files in the source bundle.

Managing Elastic Beanstalk EC2 Instances