Infrastructure as Code(架构即代码)一直是衡量公有云是否支持良好运维能力的重要指标。作为云计算领先的AWS,通过服务CloudFormation来编排云环境中的基础设施资源。不过由于CloudFormation是使用YAML/JSON编写的声明式语言,不善于处理逻辑,编写繁琐且不利于调试排错,对于新上手的Devops工程师来说也有不小的学习曲线。三方开源的工具Terraform同样没有很好解决CloudFormation存在的这些问题。

AWS CDK的出现解决了目前CloudFormation存在的绝大部分问题,极大的提升基础设施编排代码的开发和维护效率。

AWS CDK是一种开源软件开发框架,开发者可以用自己使用熟悉的编程语言模拟和预置云应用程序资源,目前支持Typescript/Javascript、Python、Java和.Net。AWS CDK将云中资源抽象对象化,通过极其简单语法描述资源对象或设置其各种属性(重载CDK默认属性设置)来创建或更新云中资源。

例如,下面简单几行将创建一个新的名为Gameday的VPC网络,并且跨了两个可用区分别创建了公有子网和私有子网。

    this.vpc = new ec2.Vpc(this, 'Gameday', {
      cidr: '10.0.0.0/16',
      maxAzs: 2,
      subnetConfiguration: [ 
        { 
          cidrMask: 24, 
          name: 'Public', 
          subnetType: SubnetType.PUBLIC
        }, 
        { 
          cidrMask: 24, 
          name: 'Private', 
          subnetType: SubnetType.PRIVATE
        }
      ]
    });

我创建了两个示例项目使用了AWS CDK快速创建应用环境且部署应用,

  • Gameday 为一个ECS上运行的Web应用编排了完整的环境,包括VPC、RDS Aurora、NAT Gateway、安全组、ECS集群、ECS Task定义、ALB负载均衡。
  • Serverlss Domain Redirect 基于AWS搭建了无服务器架构的域名重定向服务。基于不同的配置参数,提供了基于 S3 + CloudFront + Route 53 或是 Lambda + API Gateway + Route 53 两种解决方案。

总体的来说,AWS CDK是一个非常值得采用的云中资源编排和管理方式,高效的管理了AWS上的资源。

由于CDK还在相对早期,成熟度还不是那么完美。我在使用中发现下面一些值得注意的问题。

  1. CDK程序最终还是创建了CloudFormation配置,提交到CloudFormation完成资源变更。核心的用户体验,需要依赖CloudFormation的能力。CloudFormation的创建或回退超时过长,时常影响资源部署体验。另外,清理资源的时候,遇到部分资源无法清理且缺少明确提示。比如Aurora集群。
  2. CDK类库缺少配置校验。这类错误只能通过CloudFormation部署后,才会被资源方发现并返回错误。导致整个创建的堆栈回退,调试大型的部署栈将花费比较长的时间。建议将整个部署拆分为多个小的堆栈,减小每次部署时间,方便调试。
  3. 文档还比较简陋。缺少较为深入的示例。增加了开发人员的学习曲线。
  4. 新版本向后兼容性不够好,时常新版本有break changes。在1.0GA之后发布的版本break changes相对减少,但仍然有出现。