Master
ThoughtWorks
菜单
关闭
  • 产品及服务
    • 概况
    • "客户体验、产品及设计业务线 "
    • 数据战略、工程及分析业务线
    • 数字化转型及运营业务线
    • 现代化企业、平台及云业务线
  • 合作伙伴
    • 概况
    • 汽车企业
    • 医疗企业
    • 公共服务机构
    • 清洁技术,能源与公用事业
    • 媒体和出版业
    • 零售业和电商
    • 金融和保险企业
    • 非盈利性组织
    • 旅游业和运输业
  • 洞见
    • 概况
    • 特色

      • 技术

        深入探索企业技术与卓越工程管理

      • 商业

        及时了解数字领导者的最新业务和行业见解

      • 文化

        分享职业发展心得,以及我们对社会公正和包容性的见解

    • 数字出版物和工具

      • 技术雷达

        对前沿技术提供意见和指引

      • 视野

        服务数字读者的出版物

      • 数字化流畅度模型

        可以将应对不确定性所需的数字能力进行优先级划分的模型

      • 解码器

        业务主管的A-Z技术指南

    • 所有洞见

      • 文章

        助力商业的专业洞见

      • 博客

        ThoughtWorks 全球员工的洞见及观点

      • 书籍

        浏览更多我们的书籍

      • 播客

        分析商业和技术最新趋势的精彩对话

  • 加入我们
    • 概况
    • 申请流程

      面试准备

    • 毕业生和变换职业者

      正确开启技术生涯

    • 搜索工作

      在您所在的区域寻找正在招聘的岗位

    • 保持联系

      订阅我们的月度新闻简报

  • 关于我们
    • 概况
    • 我们的宗旨
    • 奖项与荣誉
    • 多元与包容
    • 领导层
    • 合作伙伴
    • 辅助功能
    • 新闻
  • 联系我们
China | 中文
  • United States United States
    English
  • China China
    中文 | English
  • India India
    English
  • Canada Canada
    English
  • Singapore Singapore
    English
  • United Kingdom United Kingdom
    English
  • Australia Australia
    English
  • Germany Germany
    English | Deutsch
  • Brazil Brazil
    English | Português
  • Spain Spain
    English | Español
  • Global Global
    English
博客
选择主题
查看所有话题关闭
技术 
敏捷项目管理 云 持续交付 数据科学与工程 捍卫网络自由 演进式架构 体验设计 物联网 语言、工具与框架 遗留资产现代化 Machine Learning & Artificial Intelligence 微服务 平台 安全 软件测试 技术策略 
商业 
金融服务 全球医疗 创新 零售行业 转型 
招聘 
职业心得 多元与融合 社会改变 
博客

话题

选择主题
  • 技术
    技术
  • 技术 概观
  • 敏捷项目管理
  • 云
  • 持续交付
  • 数据科学与工程
  • 捍卫网络自由
  • 演进式架构
  • 体验设计
  • 物联网
  • 语言、工具与框架
  • 遗留资产现代化
  • Machine Learning & Artificial Intelligence
  • 微服务
  • 平台
  • 安全
  • 软件测试
  • 技术策略
  • 商业
    商业
  • 商业 概观
  • 金融服务
  • 全球医疗
  • 创新
  • 零售行业
  • 转型
  • 招聘
    招聘
  • 招聘 概观
  • 职业心得
  • 多元与融合
  • 社会改变
持续交付技术

EbDeployer - Automate your Deployments on AWS Elastic Beanstalk

Sudhindra Rao Sudhindra Rao

Published: Aug 28, 2014

Since the time Mingle was first released as a SaaS product, it has gone through a lot of changes. Most of those changes have been towards enabling Mingle to work in distributed environments on the cloud. In our journey, we learnt a lot about the cloud and how to build for it instead of fighting it. I will try to unfold our progress and showcase a tool - EbDeployer, which we built along the way (to enable continuous deployments on AWS).

Being on the cloud

Mingle has been on the cloud since December 2012. Since our first launch, we have been building more functionality and adapting it to fit the cloud. As explained in ‘how we moved to the cloud’ article, we built features along with cloud adaptability for Mingle in the last few months. Most of what we learnt helped us understand distributed computing - especially with AWS, better.

Using AWS specific tools

As we showed in the previous article, we used CloudFormation to build some of our services. Further to CloudFormation work, AWS has gone ahead and built a complete Web application stack infrastructure - they call it Elastic Beanstalk.

Elastic Beanstalk (EB) provides the following features:

  1. Complete stack management - Computing, Storage, Database, Load Balancer all connected together

  2. Stack lifecycle management - The application is deployed for the entire stack and only reports success when all the components are healthy

  3. Built-in monitoring and log retrieval

  4. Simple, configurable scaling and deployment

Elastic Beanstalk gives us everything in terms of managing the application lifecycle on AWS. We found that if we are able to build Mingle into self-contained application without the need of manual orchestration, EB would be of great benefit for us.

Migrating to Elastic Beanstalk

Given our better understanding of AWS infrastructure, we started by moving our simple web services to EB. These services were independent enough that they would not affect Mingle’s performance or availability. We picked Cycle Time Analytics(CTA) as one of the candidates to serve on EB. Since this service was small and independent, we were able to learn EB better when deploying it.

Pushing these services on to EB is straightforward enough. However, we had a few goals in mind, in addition to just deployment:

  1. Automated Deployments to allow for Continuous Delivery(CD)

  2. Zero Downtime for the user

  3. Rollback and no data loss

  4. One-click Seamless deployments

  5. Automatically running smoke tests - to ensure that the new deployments did not break anything.

​Building EBDeployer

Pengchao Wang started building what we now call EbDeployer - a tool for automated Continuous Delivery on AWS Elastic Beanstalk. EbDeployer automates blue-green deployments for EB. EbDeployer was built with the above goals in mind. Since it has been built, we have been able to deploy multiple times a day, with automated deployments through our CD pipelines.

Blue-Green Deployments

EbDeployer is based on the ideas from Blue-Green Deployments by Martin Fowler.

Here is a brief explanation of what it means to have blue-green deployments in your infrastructure:

While working on some form of Continuous Delivery,  the problem of keeping the application up and running, while simultaneously updating it with new features, is common. Blue-green deployments allow you to have a clone of the production environment, so you can deploy to the clone, verify the functionality and switch it with the production environment.  This way, new features are available to the users without any perceived downtime. The diagram below illustrates how it would work with a rack of servers.

Blue Green Deployment Vanilla

Although the basic idea seems simple, without proper tools, such deployments could be a challenge. Some of the human aspects involved in maintaining this system and doing it accurately make it error prone.

A few reasons why blue-green deployments are hard to maintain:

  1. High cost of duplicate infrastructure

  2. Maintenance of the duplicate infrastructure

  3. Ensuring environments and data are in sync

  4. Dead cost of the inactive infrastructure when it does not serve users

  5. Human involvement in putting pieces together and running tests that make it error prone

EB addresses, these hard to maintain issues by design, as follows:

  1. EB is available on the cloud - no sunk costs in maintaining your own infrastructure

  2. EB automatically scales the environment based on load - thus reducing cost when the load on them is reduced

  3. EB manages the entire development stack

  4. EB is built on top of CloudFormation - thus providing protection around eventual consistency issues and more reliable state of the system

  5. Inactive environments are tuned to use minimum resources based on load - hence saves on cost

EbDeployer - why we built it

EbDeployer brings harmony by automating blue-green deployments for EB.

EbDeployer leverages the low friction in EB to allow for maintaining and deploying to blue-green environment stacks. EbDeployer provisions environments using the EB API and builds active and inactive environments. Once these are built, the following deployments always happen on the inactive environment. They are verified through smoke tests and then switched with the active environment - thus achieving hassle free blue-green deployments.

EbDeployer manages to perform all these actions without any burden on the developer.  A simple configuration file is all it takes to setup your environment components. Some of these components can be pre-built if that is preferred. These components can be stacked and connected the way your application needs them.

A sample configuration looks as follows: 

application: eb-deployer-simple-java

common:
  region: us-west-1
  smoke_test: >
    Timeout.timeout(600) do
      until `curl http://#{host_name}`.include?('Hello, World')
        sleep 5
      end
    end


  option_settings:
    - namespace: aws:autoscaling:launchconfiguration
      option_name: InstanceType
      value: m1.small

# You can define environment here. Each environment can overriden any common settings
environments:
  dev:
    strategy: inplace-update
  prod:
    option_settings:
      - namespace: aws:autoscaling:asg
        option_name: MinSize
        value: "2"

    inactive_settings:
      - namespace: aws:autoscaling:asg
        option_name: 'MinSize'
        value: "1"

More examples of detailed configuration can be found on EbDeployer website.

EbDeployer also provides a standard template, thus making it really easy to use and deploy to AWS. A typical blue-green environment built with EbDeployer looks as shown in the picture below.

Blue Green with EB
Once you specify the details in the configuration, EbDeployer can deploy the environment for you. By default, EbDeployer creates an active environment on the first deploy. On the subsequent deploy, it will create a clone environment with updated code and switch it with the active one.

Smoke testing and deployment strategies

Once active/inactive environments have been set up, the blue-green environments are ready.
Smoke Tests
Subsequent deploys will continue to deploy to the inactive one and switch over once it passes the set of smoke tests. Yes, EbDeployer allows you to run smoke tests along with your deployment.
Active Inactive Blue Green

You can choose different blue-green strategies depending on your use case. For example, in a development or testing stack, we would like to destroy the inactive one to save on cost/hassle. So after testing the deployment, you can choose to terminate the old one.

EbDeployer also allows you to choose the deployment style - phoenix mode or inplace update.

  • If there are no changes to configuration of the stack, inplace updates are faster

  • Phoenix mode can be useful if you want to ensure a clean environment without any stale state whatsoever

​Delivering EbDeployer

Pengchao Wang(WPC) and I presented on how EB becomes better with EbDeployer at the aws re:invent 2013 (Our talk starts at 27m 45s). Feel free to browse the presentation below and use EbDeployer for your cloud app.

Since its initial build, we have moved a number of our applications, including the core Mingle application to EB. We have been doing daily, as well as automated deployments, to all our environments in blue-green fashion.

A few new features have been added and the community is finding it useful. EbDeployer has now been forked a number of times and has also inspired others to build similar tools - like cf-deployer.

More documentation and open sourced code can be found on our EbDeployer website. 

Check out other related posts on the topic of Continuous Delivery on the Cloud:  

1. Implementing Blue Green Deployments with AWS
 
2. Continuous Deployment of a Static Website to AWS with Snap CI
 
3. Deploying to AWS using Elastic Beanstalk "
Master
政策声明 | 现代奴役声明 | 辅助功能
Connect with us
×

WeChat

QR code to ThoughtWorks China WeChat subscription account
© 2021 ThoughtWorks, Inc.