本文主要是介绍AWS 专题学习 P8 (ECS、EKS、Lambda、CloudFront、DynamoDB),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
文章目录
- 什么是 Docker?
- 操作系统上的 Docker
- Docker 镜像存储
- Docker vs. Virtual Machines
- Docker 入门
- AWS 中的 Docker Containers Management
- Amazon ECS
- EC2 Launch Type
- Fargate Launch Type
- ECS 的 IAM Roles
- Load Balancer Integrations
- Data Volumes (EFS)
- ECS Service Auto Scaling
- EC2 Launch Type – Auto Scaling EC2 实例
- Amazon ECR
- Amazon EKS 概述
- Amazon EKS - Diagram
- Amazon EKS – 节点类型
- Amazon EKS – 数据卷
- AWS App Runner
- Serverless 概述
- 什么是无服务?
- AWS 中的无服务
- 为什么选择 AWS Lambda
- AWS Lambda 的优点
- AWS Lambda 语言支持
- AWS Lambda 集成
- AWS Lambda 定价:示例
- AWS Lambda 的限制(per region)
- Customization At The Edge
- CloudFront Functions vs. Lambda[@Edge ](/Edge )
- CloudFront Functions
- Lambda[@Edge ](/Edge )
- 总结
- CloudFront Functions
- Lambda[@Edge ](/Edge )
- 默认的 Lambda
- VPC 中的 Lambda
- 带有 RDS 代理的 Lambda
- Amazon DynamoDB
- DynamoDB - 基础知识
- DynamoDB – 表示例
- DynamoDB – 读/写容量模式
- DynamoDB 加速器 (DAX)
- DynamoDB 加速器 (DAX) vs. ElastiCache
- DynamoDB – 流处理
- DynamoDB 流
- Kinesis Data Streams(较新)
- DynamoDB Global Tables
- DynamoDB – 生存时间 (TTL)
- DynamoDB – 用于灾难恢复的备份
- DynamoDB – 与 Amazon S3 集成
什么是 Docker?
- Docker 是一个用于部署应用程序的软件开发平台
- Docker 容器可以在任何操作系统上运行,应用程序运行在容器中
- 应用程序运行过程相同,无论它们在何处运行 —> 行为可预测
- 无兼容性问题,更易于维护和部署
- 减少工作量
- 使用案例:微服务架构、将应用程序从本地直接迁移到 AWS 云,…
操作系统上的 Docker
Docker 镜像存储
- Docker 镜像存储在 Docker Repositories
- Docker Hub (https://hub.docker.com)
- 公共存储库
- 查找多种技术或操作系统的基础映像(例如 Ubuntu、MySQL…)
- Amazon ECR(Amazon Elastic Container Registry)
- 私有存储库
- 公共存储库(Amazon ECR Public Gallery: https://gallery.ecr.aws)
Docker vs. Virtual Machines
- Docker 趋近于一种虚拟化技术,但并不完全是
- 区别:与主机共享资源 => 一台服务器上有许多容器
Docker 入门
AWS 中的 Docker Containers Management
- Amazon 弹性容器服务 (Amazon ECS)
- Amazon 自己的容器平台
- Amazon Elastic Kubernetes 服务 (Amazon EKS)
- Amazon 托管的 Kubernetes(开源)
- AWS Fargate
- Amazon 自己的无服务容器平台
- 可与 ECS 和 EKS 配合使用
- Amazon ECR:
- 存储容器的镜像
Amazon ECS
EC2 Launch Type
- ECS = 弹性容器服务
- 在 AWS 上启动 Docker 容器 = 在 ECS 集群上启动 ECS Tasks
- EC2 启动类型:用户必须配置和维护基础设施(EC2 实例)
- 每个 EC2 实例必须运行 ECS Agent 才能在 ECS 集群中注册
- AWS 负责启动/停止容器
Fargate Launch Type
- 在 AWS 上启动 Docker 容器
- 用户无需配置基础设施(无需管理 EC2 实例)
- 一切都是无服务的!
- 用户只需创建任务定义
- AWS 只是根据用户需要的 CPU/RAM 为用户运行 ECS Tasks
- 如果要扩展,只需增加 Task 数量即可。 简单 —— 不会有更多的 EC2 实例
ECS 的 IAM Roles
- EC2 实例配置文件(仅限 EC2 启动类型):
- 由 ECS Agent 使用
- 对 ECS 服务进行 API 调用
- 将容器日志发送到 CloudWatch Logs
- 从 ECR 拉取 Docker 镜像
- 引用 Secrets Manager 或 SSM 参数存储中的敏感数据
- ECS Task Role:
- 允许每个任务具有特定的角色
- 对不同 ECS 服务使用不同的角色
- Task Role 是在 Task Definition 中定义
Load Balancer Integrations
- 应用程序负载均衡器(ALB):支持并适用于大多数用例
- 网络负载均衡器(NLB):建议仅用于高吞吐量/高性能用例,或将其与 AWS Private Link 配对
- 弹性负载均衡器(ELB):支持但不推荐(无高级功能 - 如 Fargate)
Data Volumes (EFS)
- 将 EFS 文件系统挂载到 ECS Tasks 上
- 适用于 EC2 和 Fargate 启动类型
- 在任何 AZ 中运行的任务将共享 EFS 文件系统中的相同数据
- Fargate + EFS = Serverless
- 使用案例:EFS 作为多可用区共享存储,实现容器的持久化
- 注意:
- Amazon S3 无法作为文件系统安装
- Amazon S3 无法作为文件系统安装
ECS Service Auto Scaling
- 自动增加/减少所需的 ECS Tasks 数量
- ECS 实现自动扩展的方式是使用 AWS Application Auto Scaling 服务
- ECS 服务平均 CPU 利用率
- ECS 服务 RAM 上的 平均内存利用率规模
- 每个目标的 ALB 请求计数 (来自 ALB 的指标)
- 目标跟踪(Target Tracking): 根据特定 CloudWatch 指标的目标值进行扩展
- 步进扩展(Step Scaling): 根据指定的 CloudWatch 警报进行扩展
- 计划扩展(Scheduled Scaling): 根据指定日期/时间进行扩展(可预测的变化)
- ECS Service Auto Scaling(任务级别)≠ EC2 Auto Scaling(EC2 实例级别)
- Fargate Auto Scaling 更容易设置(因为无服务)
EC2 Launch Type – Auto Scaling EC2 实例
- 通过添加底层 EC2 实例来适应 ECS 服务扩展
- Auto Scaling Group (ASG)
- 根据CPU 利用率扩展用户的 ASG
- 随着时间的推移添加 EC2 实例
- ECS Cluster Capacity Provider
- 用于自动配置和扩展 ECS Tasks的基础设施
- 通常与 ASG 配合使用
- 当用户缺少容量(CPU、RAM…)时添加 EC2 实例
ECS Scaling - Service CPU 使用示例
Event Bridge 调用的 ECS Tasks
Event Bridge Schedule 调用的 ECS Tasks
ECS – SQS 队列示例
Amazon ECR
- ECR = Elastic Container Registry
- 在 AWS 上存储和管理 Docker 映像
- 私有和公共存储库(Amazon ECR 公共库 https://gallery.ecr.aws)
- 与 ECS 完全集成,由 Amazon S3 支持
- 访问通过 IAM 控制(权限错误 => 策略)
- 支持镜像漏洞扫描、版本控制、镜像标签、镜像生命周期…
Amazon EKS 概述
- Amazon EKS = Amazon Elastic Kubernetes Service
- 这是在 AWS 上启动托管 Kubernetes 集群的一种方法
- Kubernetes 是一个开源系统,用于自动部署、扩展和管理容器化(通常是 Docker)应用程序
- EKS 是 ECS 的一种替代方案,目标类似但 API 不同
- EKS 支持 EC2(如果要部署工作节点),也支持 Fargate(如果要部署无服务器容器)。
- 使用案例:如果用户的公司已在本地或其他云中使用 Kubernetes,并且希望使用 Kubernetes 迁移到 AWS
- Kubernetes 与云无关(可以在任何云中使用 – Azure、GCP…)
- 对于多个区域,需要在每个区域部署一个 EKS 集群
- 使用 CloudWatch Container Insights 收集日志和指标
Amazon EKS - Diagram
Amazon EKS – 节点类型
- 受托管节点组
- 为用户创建和管理节点(EC2 实例)
- 节点是EKS 管理的ASG 的一部分
- 支持按需实例或 Spot 实例
- 自我管理节点
- 由用户创建并注册到 EKS 集群并由 ASG 管理的节点
- 用户可以使用预构建的 AMI - Amazon EKS 优化的 AMI
- 支持按需实例或 Spot 实例
- AWS Fargate
- 无需维护; 没有管理节点
Amazon EKS – 数据卷
- 需要在 EKS 集群上指定 StorageClass 清单
- 利用 Container Storage Interface (CSI) 兼容的驱动程序
- 支持…
- Amazon EBS
- Amazon EFS(与 Fargate 配合使用)
- Amazon FSx for Lustre
- 适用于 NetApp ONTAP 的 Amazon FSx
AWS App Runner
- 完全托管的服务,可以轻松大规模部署 Web 应用程序和 API
- 无需基础架构经验
- 从源代码或容器映像开始
- 自动构建和部署 Web 应用程序
- 自动扩展、高可用性、负载均衡器、加密
- VPC 访问支持
- 连接到数据库、缓存和消息队列服务
- 使用案例:Web 应用程序、API、微服务、快速生产部署
Serverless 概述
什么是无服务?
- 无服务是一种新范式,开发人员无需再管理服务器…
- 只部署xx代码、xx功能!
- 最初,无服务 == FaaS(函数即服务)
- 无服务由 AWS Lambda 开创,但现在还包括任何托管内容:“数据库、消息传递、存储等”。
AWS 中的无服务
- AWS Lambda
- DynamoDB
- AWS Cognito
- AWS API Gateway
- Amazon S3
- AWS SNS & SQS
- AWS Kinesis Data Firehose
- Aurora Serverless
- Step Functions
- Fargate
|
为什么选择 AWS Lambda
- Amazon EC2
- 云中的虚拟服务器
- 受 RAM 和 CPU 限制
- 连续运行
- 扩展意味着需要人工干预去添加/删除服务器
- Amazon Lambda
- 虚拟功能——无需管理服务器!
- 受时间限制 - 执行时间短
- 按需运行
- 缩放是自动的!
AWS Lambda 的优点
- 轻松定价:
- 按请求和计算时间付费
- 提供免费的使用额度,包括1,000,000个AWS Lambda请求和400,000 GB的计算时间
- 与整个 AWS 服务套件集成
- 与多种编程语言集成
- 通过AWS CloudWatch 轻松监控
- 轻松为函数获取更多资源(高达 10GB RAM!)
- 增加 RAM 也能提高CPU和网络性能
AWS Lambda 语言支持
- Node.js (JavaScript)
- Python
- Java(兼容 Java 8)
- C#(.NET 核心)
- Go 语言
- C# / Powershell
- 红宝石
- 自定义运行时 API(社区支持,例如 Rust)
- Lambda 容器映像
- 容器映像必须实现Lambda Runtime API
- ECS / Fargate 是运行任意 Docker 镜像的首选
AWS Lambda 集成
Main ones
示例:无服务缩略图创建
示例:无服务 CRON 作业
AWS Lambda 定价:示例
- 用户可以在此处找到总体定价信息:
https://aws.amazon.com/lambda/pricing/ - 按调用量付费:
- 前 1,000,000 个请求免费
- 此后每 100 万个请求 0.20 美元(每个请求 0.0000002 美元)
- 按持续时间付费:(以 1 毫秒为增量)
- 每月免费 400,000 GB-秒 的计算时间
- exp: 400,000 秒(如果函数为 1GB RAM)
- exp: 3,200,000 秒(如果函数为 128 MB RAM)
- 此后 600,000 GB 秒 1.00 美元
- 每月免费 400,000 GB-秒 的计算时间
- 运行 AWS Lambda 通常非常便宜,因此非常受欢迎
AWS Lambda 的限制(per region)
- 执行:
- 内存分配:128 MB ~ 10GB(1 MB 增量)
- 最长执行时间:900 秒(15 分钟)
- 环境变量 (4 KB)
- “功能容器”中的磁盘容量(/tmp):512 MB 至 10GB
- 并发执行:1000(可以增加)
- 部署:
- Lambda 函数部署大小(压缩的.zip):50 MB
- 未压缩部署的大小(代码+依赖项):250 MB
- 可以使用/tmp目录在启动时加载其他文件
- 环境变量的大小:4 KB
Customization At The Edge
- 许多现代应用程序在边缘执行某种形式的逻辑
- 边缘功能:
- 用户编写并附加到 CloudFront 分配的代码
- 靠近用户运行以最大限度地减少延迟
- CloudFront 提供两种类型:CloudFront Functions 和 Lambda@Edge
- 用户无需管理全球部署的任何服务器
- 使用案例:定制CDN 内容
- 仅按使用量付费
- 完全无服务
CloudFront Functions vs. Lambda@Edge
用例:
- 网站安全和隐私
- 边缘的动态 Web 应用程序
- 搜索引擎优化(SEO)
- 智能路由跨源和数据中心
- 边缘机器人缓解
- 实时图像转换
- A/B 测试
- 用户身份验证和授权
- 用户优先级
- 用户跟踪和分析
CloudFront Functions
- 用 JavaScript 编写的轻量级函数
- 适用于大规模、延迟敏感的 CDN 定制
- 亚毫秒级启动时间,每秒数百万个请求
- 用于更改查看器请求和响应:
- 查看者请求:CloudFront 收到查看者的请求后
- 查看器响应:在 CloudFront 将响应转发给查看器之前
- CloudFront 的本机功能(完全在 CloudFront 内管理代码)
Lambda@Edge
- 用 NodeJS 或 Python 编写的 Lambda 函数
- 可扩展到每秒 1000 个请求
- 用于更改 CloudFront 请求和响应:
- 查看者请求:CloudFront 收到查看者的请求后
- 源请求:在 CloudFront 将请求转发到源之前
- 源响应:CloudFront 收到来自源的响应后
- 查看器响应:在 CloudFront 将响应转发给查看器之前
- 在一个 AWS 区域 (us-east-1) 中编写用户的函数,然后 CloudFront 复制到其位置
总结
CloudFront Functions
- 缓存键规范化
- 转换请求属性(标头、cookie、查询字符串、URL)以创建最佳缓存键
- Header 操作
- 在请求或响应中插入/修改/删除 HTTP 标头
- URL 重写或重定向
- 请求身份验证和授权
- 创建并验证用户生成的令牌(例如 JWT)以允许/拒绝请求
- 创建并验证用户生成的令牌(例如 JWT)以允许/拒绝请求
Lambda@Edge
- 较长的执行时间(几毫秒)
- 可调节CPU或内存
- 用户的代码依赖于第三个库(例如,用于访问其他 AWS 服务的 AWS SDK)
- 网络访问以使用外部服务进行处理
- 文件系统访问或对 HTTP 请求正文的访问
默认的 Lambda
- 默认情况下,用户的 Lambda 函数在用户自己的 VPC 外部(在 AWS 拥有的 VPC 中)启动
- 因此,它无法访问用户的VPC 中的资源(RDS、ElastiCache、内部ELB…)
VPC 中的 Lambda
- 用户必须定义 VPC ID、子网和安全组
- Lambda 将在用户的子网中创建 ENI(弹性网络接口)
带有 RDS 代理的 Lambda
- 如果 Lambda 函数直接访问用户的数据库,它们可能会在高负载下打开太多连接
- RDS 代理
- 通过池化和共享数据库连接来提高可扩展性
- 通过减少 66% 的故障转移时间并保留连接来提高可用性
- 通过在 Secrets Manager 中强制执行 IAM 身份验证和存储凭证来提高安全性
- Lambda 函数必须部署在用户的 VPC 中,因为 RDS Proxy 永远无法公开访问
Amazon DynamoDB
- 完全托管、高度可用,可跨多个可用区进行复制
- NoSQL 数据库,具有事务支持
- 可扩展到海量工作负载、分布式数据库
- 每秒数百万个请求、数万亿行、数百TB 存储
- 快速且一致的性能(个位数毫秒)
- 与 IAM 集成以实现安全、授权和管理
- 低成本和自动扩展功能
- 无需维护或修补,始终可用
- 标准和不频繁访问 (IA) 表类
DynamoDB - 基础知识
- DynamoDB 由表组成
- 每个表都有一个主键(必须在创建时决定)
- 每个表可以有无限数量的项目(= 行)
- 每个项目都有属性(可以随着时间的推移添加 - 可以为空)
- 项目的最大大小为 400KB
- 支持的数据类型有:
- 标量类型 – 字符串、数字、二进制、布尔值、空值
- 文档类型 – 列表、地图
- 集合类型 – 字符串集合、数字集合、二进制集合
- 因此,在 DynamoDB 中,用户可以快速发展架构
DynamoDB – 表示例
DynamoDB – 读/写容量模式
- 控制管理表容量的方式(读/写吞吐量)
- 配置模式(默认)
- 用户指定每秒读/写的数量
- 用户需要提前规划容量
- 支付预配置的读取容量单位 (RCU) 和写入容量单位 (WCU) 费用
- 可以为 RCU 和 WCU 添加自动缩放模式
- 点播模式
- 读/写会根据用户的工作负载自动扩展/缩减
- 无需进行容量规划
- 按使用量付费,价格更高 ($$$)
- 非常适合不可预测的工作负载、陡峭的突然峰值
DynamoDB 加速器 (DAX)
- DynamoDB 的完全托管、高可用性、无缝内存缓存
- 通过缓存帮助解决读取拥塞
- 缓存数据的微秒级延迟
- 不需要修改应用程序逻辑(与现有的DynamoDB API 兼容)
- 5 分钟 TTL 缓存(默认)
DynamoDB 加速器 (DAX) vs. ElastiCache
DynamoDB – 流处理
- 表中项目级修改(创建/更新/删除)的有序流
- 用例:
- 实时响应变化(向用户发送欢迎电子邮件)
- 实时使用情况分析
- 插入衍生表
- 实施跨区域复制
- 对 DynamoDB 表的更改调用 AWS Lambda
DynamoDB 流
- 24 小时保留期
- 消费者数量有限
- 使用 AWS Lambda 触发器或 DynamoDB Stream Kinesis 适配器进行处理
Kinesis Data Streams(较新)
- 保留 1 年
- 消费者数量多
- 使用 AWS Lambda、Kinesis Data Analytics、Kineis Data Firehose、AWS Glue Streaming ETL 进行处理…
DynamoDB 流
DynamoDB Global Tables
- 使 DynamoDB 表可在多个区域中以低延迟进行访问
- 主动-主动复制
- 应用程序可以读取和写入任何区域的表
- 必须启用 DynamoDB Streams 作为先决条件
DynamoDB – 生存时间 (TTL)
- 在过期时间戳后自动删除项目
- 使用案例:通过仅保留当前项目来减少存储的数据、遵守监管义务、Web 会话处理…
DynamoDB – 用于灾难恢复的备份
- 使用时间点恢复 (PITR) 进行连续备份
- 可选择在过去 35 天内启用
- 时间点恢复到备份窗口内的任何时间
- 恢复过程创建一个新表
- 按需备份
- 完整备份可长期保留,直至明确删除
- 不影响性能或延迟
- 可以在AWS Backup 中进行配置和管理(支持跨区域复制)
- 恢复过程创建一个新表
DynamoDB – 与 Amazon S3 集成
- 导出到S3(必须启用PITR)
- 适用于过去 35 天内的任何时间点
- 不影响表的读取容量
- 在DynamoDB 之上执行数据分析
- 保留快照以供审核
- 在导入回 DynamoDB 之前对 S3 数据进行 ETL
- 以DynamoDB JSON 或ION 格式导出
- 导入到 S3
- 导入 CSV、DynamoDB JSON 或 ION 格式
- 不消耗任何写入容量
- 创建一个新表
- 导入错误记录在CloudWatch Logs 中
示例:构建无服务 API
这篇关于AWS 专题学习 P8 (ECS、EKS、Lambda、CloudFront、DynamoDB)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!