AWS Infrastructure Code (E)

Infrastructure as Code

Outline

  • Challenge manually configured: probably because of human error resulting in lack of reliability, the environment can not be completely reproduced, and the need for additional documentation
  • Infrastructure as a code, software development for creating reusable, maintainable, testable and scalable technologies, practices and tools infrastructure, rather than drop the infrastructure is defined as a bundled hardware components.
  • Infrastructure-code benefits:
    • reliability
    • Reproducibility - repeatability, reusability
    • Maintainability
    • consistency
    • Parallelization
    • Documentation of

AWS Infrastructure Code (E)

Automation environment

  • Whenever possible, all resources should automatically execute pre-terminated and configuration operations by eliminating manual processes and improve the stability and consistency of the system, and the efficiency of the organization
  • Use of resources releasable
    • The use of dynamic configuration attributes of cloud computing, servers and other components considered as a temporary resource
  • Automatically deploy the same configuration of new resources
    • Termination of unused resources
    • Automatically switch to the new IP address
    • Test the new resource update, and then replace the old with the updated resource Resources

AWS Infrastructure Code (E)

AWS Lambda

Outline

  • You do not need any configuration and management of servers and applications will be able to run the code.
  • Simply upload codes, Lambda process will run automatically and transversely expanded as needed
  • Lambda is fully managed computing service in response to an event intervals or event-free operation status code
  • Lambda code language support
    • Python
    • Java
    • Node.js (JavaScript)
    • C#
    • Go
  • Lambda can support:
    • server
    • Capacity requirements
    • deploy
    • Extension and fault tolerance
    • Operating system and language update
    • Indicators and Logging
  • Lambda can be achieved:
    • Use your own code or even a native library
    • Code running in parallel
    • Create a back-end, event handlers and data processing system
    • Always having to pay for idle resources
  • Lambda extended use
    • Extended event-triggered Lambda, Lambda function automatically initiate the use of API calls to other AWS services
    • Examples of extended-based containers, such as Docker, ECS, etc.
    • By function to achieve a more intelligent extensions, such as is found by analyzing performance data, not just events
    • Because Lambda be automatically extended, it can be used to replace some of the functions Lambda EC2

AWS Infrastructure Code (E)

Use AWS Lambda decoupling infrastructure

  • Lambda because of its high availability, limited occupancy costs is an ideal solution for processing data
  • Lambda can use a simple service to replace the traditional micro server, further decoupling of infrastructure
  • 当用实例即可处理的简单功能和应用程序,而又不想为高可用和扩展烦恼,建议使用Lambda
  • 以下事件可以触发 Lambda

AWS Infrastructure Code (E)

Lambda使用方法

  • 以.zip 格式上传代码,
  • 用计划函数指定运行频率
  • 用驱动型函数指定事件源
  • 指定所需的计算资源 - 23个级别,从128M最低CPU到1.5GB最高CPU,可以调整计算级别
  • 指定超时时限
  • 指定所需要访问资源的VPC
  • 启动函数 (100ms - 5 min 运行时间,最长为15min)
  • Lambda代码存储在S3中,并且静态加密
  • Lambda仅支持无状态函数
  • 每个 Lambda 函数都会在自己的 /tmp 目录中接收到 500MB 的非永久性磁盘空间。
  • Lambda 支持代码版本控制
  • 免费套餐包括 每月100万个免费请求及40w内存GB-秒的计算时间
  • 可以借助CodePipeline 和 CodeDeploy 自动执行无服务应用程序的发布过程,也可以使用CloudFormation进行打包加载
  • Lambda@Edge
    • 响应CloudFront的请求,在全球运行代码
  • 超出并发默认限制
    • 同步调用的 AWS Lambda 函数会返回一条限制错误信息(429 错误代码)。
    • 异步调用的 Lambda 函数可以承受一定范围内的流量突增大约 15 到 30 分钟,之后再进来的事件将会以限制为理由遭到拒绝。
    • 如果调用的 Lambda 函数是用于响应 Amazon S3 事件,则被 AWS Lambda 拒绝的事件可能被 S3 保留 24 小时并在此期间反复重试

Lambda的应用场景

  • 将Lambda作为Web服务器

AWS Infrastructure Code (E)

  • 用Lambda可以执行 轮询/侦听、排队、处理、自动扩展、冗余和负载均衡来替代传统的复杂的数据处理方案

AWS Infrastructure Code (E)

  • 其他案例

AWS Infrastructure Code (E)

AWS Infrastructure Code (E)

AWS Infrastructure Code (E)

AWS Infrastructure Code (E)

AWS Infrastructure Code (E)

AWS CloudFormation

概述

  • 自动建模和设置AWS资源,降低管理从成本
  • 支持快速启动新的测试环境,可靠复制环境
  • 便捷的预配置机制,适用于众多 AWS 资源。它支持许多不同类型的应用程序的基础设施需求,
  • 三大组件
    • 模板- 用JSON/YAML格式文件描述创建的资源,将其视为源代码进行保存和管理
    • 引擎 - 利用AWS组件将模板解释为AWS资源堆栈
    • 堆栈 - AWS CloudFormation创建资源的集合,可在AWS管理控制台中跟踪和审查
  • 每个账户默认只能创建200个堆栈,可申请扩展

模板

模板即是代码

  • 在模板中完整定义应用程序堆栈(应用程序所需要的所有资源)
  • 定义模板运行时的参数(EC2大小、密钥对等)
  • 模板的编辑方法
    • 直接用JSON/YAML文本编辑
    • 第三方VisualOps.io 模板编辑器
    • AWS CloudFormation Designer通过拖拽资源和编辑属性而生成JSON模板
  • CloudFormation 模板组织
    • 模板可以在不同区域被重复使用以实现部署的一致性
    • 应基于所有权和应用程序生命周期将资源分配到不同的 CloudFormation 模板中
    • 不建议在一个模板内构建应用程序的所有环境,至少将网络资源、安全资源和应用程序资源分开到不同的模板中
    • 即便是对于相同类型的资源,也应该避免不同的应用程序共享同一个模板
    • 共享模板,某些特定环境部分常亮依旧不会工作,需要用输入参数等变量进行定义,如EC2秘钥对,安全组名称,子网ID,EBS快照ID等

AWS Infrastructure Code (E)

CloudFormation 模板剖析

AWS Infrastructure Code (E)

  • Description:
    • 描述模板的文本字符串
    • 不能使用参数或者函数
  • Metadata
    • 提供关于模板其他详细信息的JSON对象
    • CloudFormation 的一些功能需要检索的设置或配置信息
    • 可以在模板或资源级别指定,例如
      • AWS::CloudFormation::Init - 为cfn-init帮助程序脚本定义配置任务
      • AWS::CloudFormation::Interface - 在控制台中显示输入参数时,定义的参数分组和排序
      • AWS::CloudFormation::Desinger - 描述资源在 CloudFormation Designer 是如何布局的
  • Resource
    • 要在堆栈中启动的服务及其设置
    • 必须对每个资源进行单独声明
    • 可以指定同种类型的多个资源,但需要用逗号分隔开
    • 资源声明中需要包含资源属性
  • DependsOn
    • 指定只有在创建另一个资源后才能创建特定资源
    • 例如AutoScaling,EC2,ELB,弹性IP等需要关联公有IP地址并处于一个VPC时,需要依赖于VPC网关连接
    • 等待条件 AWS::CloudFormation::WaitCondition
      • 可暂停创建堆栈并等待,直到收到信号后方继续
    • 创建策略 CreationPolicy
      • 为不同操作设置执行策略,如等待特定时间或特定数量的信号等
  • Parameters
    • 可在运行是传入模板的变量值
    • 允许在启动模板时自定义堆栈
    • 可为每个参数指定允许值和默认值
    • 每模板最多60个参数
  • Mapping
    • 指定条件参数值的密钥及其关联值
    • 基于特定条件来自定义资源属性
  • Condition
    • 控制在堆栈创立或更新期间是创建特定资源还是为特定属性分配值
    • 通过定义资源或属性定义的语句,比较两个值是否相等等前提下进行有条件的创建资源
    • 比如利用同一模板完成对测试和生产环境进行不同Size的资源部署
  • Outputs
    • 查看堆栈的属性时返回的值
    • 声明要从 CloudFormation 控制台查看的输出值,或者是响应调用时返回的输出值
    • 每模板最多60个

自定义资源管理

  • 为了处理不受 CloudFormation 直接支持的资源和功能,可以在创建堆栈是加入自己的逻辑
  • 支持WaitCondition,确保应用程序或管理系统等外部资源收到完成信号前,阻止其他资源创建
  • 如配置第三方订阅,将身份认证秘钥返回给需要的EC2实例
  • 使用Lambda将新的VPC与其他VPC建立对等关系
  • 使用模板创建堆栈时,若有任一资源创建失败,所以已经创建的资源都会被回滚和删除
  • 可以通过提交原始模板的修改版本来创建更改集以更新堆栈和资源
  • 默认情况下,删除堆栈会删除所有资源,但可以通过设置删除策略来保留某些资源
  • 当任一资源删除失败,剩余未删除资源都将被暂时保留,直到成功删除整个堆栈

AWS Elastic Beanstalk

概述

  • 适用于Web应用程序和Worker process 环境的 一项自动部署和扩展服务, 是最快速最简单的方式
  • 开发人员只需上传应用程序,Elastic Beanstalk 将自动处理容量预配置、负载均衡、Auto Scaling 和应用程序运行状况监控的部署细节
  • 支持 Docker
  • 支持多种语言,包括 PHP、Java、Python、Ruby、Node.js、.Net、Go等直接上传运行
  • 在Apache、Nginx、Passenger 和 IIS服务器上部署
  • Beanstalk创建的环境是独立的
  • Beanstalk 是一个包括环境、版本和环境配置的逻辑组合,概念上与文件夹类似
  • 可以自动部署和处理负载均衡、运行状况监控、自动扩展、应用程序平台管理、代码部署等
  • 大多数现有的应用程序容器或平台即服务解决方案在减少所需的编程量的同时,会大大降低开发人员的灵活性和控制。使用 AWS Elastic Beanstalk,开发人员可保留对支持其应用程序的 AWS 资源的完全控制。如果开发人员决定要管理基础设施的某些(或全部)元素,可使用 Elastic Beanstalk 的管理功能无缝操作。
  • 可以轻松为每一个应用程序版本创建一个独立的运行环境,由于是一次运行的,所以完成会就会自动删除
  • 可以运行Docker环境

特性

  • 可以内置CloudWatch监控指标对基础架构进行监控和管理,并且通过SNS发布通知
  • 开发人员可以完全控制支持其应用程序的AWS资源
  • 选择最合适的EC2实例类型
  • 选择合适的存储和数据库
  • 启用对EC2实例的登录访问
  • 通过ELB启用HTTPS来增强安全性
  • 调整应用服务器设置并传递变量
  • 调整Auto Scaling设置
  • 默认情况下应用程序是公开的,可以使配置VPC、设置安全组和nACL设置为私有。
  • 底层平台建议设置每周两个小时的维护时段进行新平台版本的发布和更新

使用场景

  • 非常适用于蓝绿部署的场景
  • 在全规模生产和最小规模预生产切换
  • 使用两个ELB保持预热状态
  • 出现错误时可以实现快速回滚
  • 实际上 CloudFormation 也可以实现蓝绿部署

AWS OpsWorks

概述

  • 利用Chef 和 Puppt 实现的配置管理服务,帮助配置和操作各种形态和规模的应用程序
  • 可以定义应用程序的整体架构和规范,包括软件包安装、软件配置、资源等
  • 利用OpsWorks 生命周期工具可以简化应用程序管理、减少部署周期数
  • 支持对Linux和Windows服务器的管理
  • 支持DevOps持续集成

管理

  • 有组织的方式对堆栈、层和应用程序进行建模和可视化
  • 堆栈
    • AWS将应用程序所需要的包括EC2,EBS,ELB等资源组称为堆栈
    • OpsWorks 采用简单和灵活地方式来创建、配置、管理和监视堆栈及应用程序
    • AWS可以使用OpsWorks 和 IAM来管理用户权限,且两者不排斥可以共同工作。
  • 层 Layer
    • 可以将整个应用程序分为多层来定义堆栈元素,每层服务于特定目的
    • 每层通过Chef任务列表来处理任务可以通过修改默认配置或添加任务来自定义或扩展图层
    • 用户可以完全控制安装哪些软件包,部署哪些应用程序,如何配置他们。
  • 应用程序
    • OpsWorks可以运行生命周期事件,每个应用程序可以在合适的事件自动运行一组指定的任务

AWS Infrastructure Code (E)

监控

  • OpsWorks可以将所有资源的指标发送给CloudWatch,以便可视化和设置警报
  • 支持各种自定义指标

AWS EC2 Run Command

概述

  • 提供简单的方法自动执行常见的管理任务,包括
    • Linux Shell
    • Windows PowerShell
    • 安装软件或补丁
    • 可以跨多个实例执行命令
    • 使结果具有可见性
  • AWS 上还支持包括Chef、Puppt、Ansible 和 Salt等其他第三方自动化解决方案

Amazon API Gateway

概述

  • 可以在AWS上创建API,作为后端服务访问数据、业务逻辑或功能的接口
  • 完全托管并接受处理高达数万并发API调用时涉及的所有任务
  • 可以处理以下工作负载
    • Lambda
    • 使用AWS Step Function状态机调用EC2,ECS, Beanstalk, Web应用程序
    • 可以与其他AWS服务集成,如Kinesis
  • 支持创建HTTP/REST API 和 WebSocket API
    • HTTP/REST API 是一组资源和方法,或者是终端节点。HTTP/REST API 可以部署到不同阶段,并可克隆到新版本。
    • WebSocket API 可以在互连客户端之间维持永久连接,以启用实时消息通信。
  • 可以托管和使用不同版本和阶段的API
  • 创建API秘钥并分配给开发人员
  • 利用签名v4授予API访问权限
  • 限制并监控请求以保护后端系统
  • 与AWS Lambda高度集成
  • 如果使用JavaScript/AJAX来跨域访问资源,必须在API Gateway上启用CORS功能已确定可以调用非本站点资源

好处

  • 计量
    • 计量和限制第三方开放人员访问API的计划
  • 安全
    • 支持多种授权访问工具
    • 保护系统免受DDOS***
  • 弹性
    • 默认提供托管缓存以存储API响应
    • 通过Amazon CloudFront降低延迟
    • 一种低成本的无服务方案,可以自动弹性伸缩
  • 操作监控
    • 通过指标监控面板,监控服务调用情况
    • 包括调用次数、延迟数据和错误率
    • 收集错误日志、访问日志和调试日志
  • 生命周期管理
  • 专为开发人员设计
    • 适用于iOS,Android和Java的新一×××发工具包
    • 支持OpenAPI规范(Swagger)
  • 实时双向通信
    • 维持用户间永久连接,支持消息传输
    • 请求/响应数据转换

      API管理台配置

  • 资源
    • 资源是一种类型化对象,属于您的 API 的域。
    • 每个资源可能都关联了一个数据模型,或与其他资源相关,并且可以响应不同的方法。
    • 您也可以将资源定义为变量来拦截对多个子资源的请求。
    • 资源策略
      • 资源策略是一种 JSON 策略文档,您可以将其附加到某个 API 来控制指定的主体(通常是 IAM 用户或角色)是否可以调用该 API。
      • 您可以使用资源策略让来自其他 AWS 账户的用户安全访问您的 API,或者只允许从指定的源 IP 地址范围或 CIDR 块调用该 API
      • Resource strategies can be used with Amazon API Gateway in the REST API.
  • method
    • REST API in each resource may support one or more standard HTTP methods.
    • You will define each verb resources should be supported (GET, POST, PUT, PATCH, DELETE, HEAD and OPTIONS) and its implementation.
  • stage
    • Stage similar to the label, define the deployment of the access path. For example, you can define the development stage, you can also set a custom domain name directly to the stage, so you need to use a different path parameters.
      • The life cycle
        • With Amazon API Gateway, each REST API can have multiple stages.
      • stage
        • Used to divide the development life cycle API, for example, after you build the API and deploy it to the development stage, or when you are ready for production, you can deploy it to the production stage.
      • Stage variable
        • Stage variable-definable configuration values ​​associated with a particular stage of key / value pairs. These values ​​are similar to environment variables can be used to configure your API.
    • Use plan
      • Use plan can help you plan statement for third-party developers, will soon restrict access to particular API, define the limits and request quotas and restrictions associated with the API key.
      • You can also extract data on a per-use API key, API usage to analyze and generate billing documents.

Select the right solution

In fact it is the convenience and controllability to find a balance

AWS Infrastructure Code (E)

Guess you like

Origin blog.51cto.com/wzlinux/2423331