使用 ECS Exec 直通 ECS 容器会话(适用于 Fargate 和 EC2)

基于 EC2 的 ECS 服务,要看看容器内的状态,一直以来都是先 SSM(Simple System Manager) 或 SSH 进到 EC2 实例,然后再 docker exec -it <container-id> sh, 查看容器的控制台日志则用 docker logs <container-id> [--follow]. 但是对使用 Farget 的 ECS 服务就无能为力了,因为找不到 SSM 或 SSH 的主体, 只能通过程序日志来大概了解容器内发生的事了。

Amazon 在 2021-03-15 推出了一个新的特性 ECS Exec 允许我们直接连接 Fargate 或 EC2 中的容器会话,见 Amazon ECS now allows you to run commands in a container running on Amazon EC2 or AWS Fargate. ECS Exec 支持 Container Agent 版本为 1.50.2 及以上的 ECS Optimized AMI 系列,和 Fargate Platform Version 1.4.0(Linux) 或 1.0.0(Windows) 及以上。

ECS Exec 的实现原理是以往在 EC2 实例上启动的 SSM Agent,也在容器内部启动一份,然后命令 aws ecs execute-command 直指容器本身。参考本人写过的一篇 AWS Session Manager 管理 EC2 实例,连接过程中唯一的不同就是容器中也运行了一个 SSM Agent, 所以这个容器也就无所谓是在 EC2 实例还是在 Fargate 中。

阅读全文 >>

为 S3 中的 CSV 文件创建带 Partition 的 Athena 表

CSV 文件是纯文本的,对人阅读和编辑来说是最友好的描述表格数据的格式。虽然当前处理大数据时会用到 JSON, avro, parquet 等数据格式,但是在处理平面数据时 CSV 仍然被广泛使用。

S3 Select 能支持 CSV, JSON 和 parquet 格式数据的直接查询。在 AWS s3 控制台选择一个 CSV 文件,从右上的 Object actions 下拉选项上选择 Query with S3 Select 就能直接查询该文件的内容,而无须下载后打开文件。

如 S3 Select 查询语句

SELECT * from s3object WHERE Name='Tom' LIMIT 5

如果 CSV 带 Header 的话,请勾选上 Exclude the first line of CSV data。当然 S3 Select 查看任意的文本文件也行,只是把它当成一个不规则的 CSV 文件来对待。

S3 Select 只能针对单个 S3 文件查询,如果要对一组 CSV 文件同时进行查询的话就要用到 Athena。把相同 Schema 的一系列 CSV 文件放到 S3 的某一个目录中,我们可为它们创建一个  Athena 表,然后查询该 Athena 表就会从对应 S3 目录中扫描所有的 CSV 文件。 阅读全文 >>

构建 AWS AMI 镜像(EC2 Image Builder + Terraform)

使用到 AWS 的 EC2 服务时,选择一个基础镜像后,要定制的话需要在 userdata 中写上一堆脚本。如果不想每次重复 userdata,或者要更快速的初始化一个虚拟机,就应该定制自己的 AMI,特别是在 Batch, ECS, EKS 选择的基础镜像还不方便使用 userdata。

定制一个 AMI, 我们可以用 aws create-image 命令,或是 HashiCorp 提供的 Packer(它不仅支持 AWS, 还能为 阿里云,Azure, Google 云,vmware, docker, Vagrant 等定制镜像)。而我们这里将要介绍的仍然是 HashiCorp 公司的 Terraform 并结合 AWS 的 EC2 Image Builder 服务来构建 AMI 镜像。

EC2 Image Builder 是 2019 年 12 月 1 日推出来的服务,见 Introducing EC2 Image Builder

构建一个镜像的基本过程是选择一个基础镜像来启动一个实例,然后在该实例中做一系列的操作,再保存操作后的状态为自己的镜像。这和用 Dockerfile 定制自己的 Docker 镜像是类似的。 阅读全文 >>

AWS Windows EC2 实例的 userdata 应用笔记

因为平常主要是使用 EC2 的 Linux 实例,所以之前写过的一篇关于 UserData 的日志 创建 AWS EC2 实例时 userdata 的一些知识 默认就是讲的有关 Linux 实例的 UserData。本文补充上 Windows 的 EC2 实例 UserData 的基本使用,参考自 AWS 官方文档 Run commands on your Windows instance at launch

Windows 的 UserData 被谁执行,依据所选择 AMI 的不同有以下三种方式

  1. EC2Launch v2: 最新方式,只是被当前预览版的 AMI 所支持,它支持 YAML 配置的脚本
  2. EC2Launch: 当前方式,Windows Server 2016 及更新版
  3. EC2Cofnig: 旧有方式, Windows Sever 2012 R2 及旧版本

阅读全文 >>

配置 AWS Lambda Python Logging

通常在 Python 应用中简单的配置使用内置的 logging 是这样的

假如文件名为 test.py, 用 python test.py 执行后输出

2022-01-25 21:02:47,231 - INFO - test(<module>:6) - hello world

在 Lambda 中的现象

可是这同样的代码放到 AWS Lambda Python 代码中却不灵验了,logging.info() 将得不到任何输出。 阅读全文 >>

学习使用 AWS API Gateway V2

关于 AWS API Gateway V1, 写过一篇笔记 Lambda + API Gateway 创建需 API Key 验证的 API。 AWS 又推出了 API Gateway V2(服务管理/理解层面), 它同样可以用来作 HTTP-PROXY 调用 REST API, WebSocket; AWS-PROXY 调用 Lambda, 还能直接调用 AWS 的其他服务,如 StepFunction, SQS 等。

但是  API Gateway V2 把 V1 中的 API Key 验证功能去掉了,这有点为了赚钱耍无赖了,先前是 API Key 验证不过时不会调用 Lambda, 现在可用 Lambda 来验证 API 调用,也就是不管 API Key 对与不对,都会去调用 Lambda 从而实现从你的帐户上扣钱的功能。

在 V1 中创建整套服务的过程基本是  Resource -> Method -> Integration -> Stage。而在 V2 中的过程是 Integration -> Route -> Stage, 把 Resource 和 Method  合而为一,比如 Route Key 写成 GET /users.

下面照旧以 Terraform 的方式来叙述使用 API Gateway V2 如何实现 HTTP 代理,调用 Lambda, 及使用 AWS 服务(以 SQS 为例),或与 VPC 内部的服务集成。首先是一个基本的框架,含 API 本身和 Stage 阅读全文 >>

Terraform 的变量使用及赋值规则

本人在 AWS 上建立基础架构的时候倾向于用 Terraform, 而不是 AWS 自家的 CloudFormation。倒不是因为 Terraform 支持多种类型的 Provider,而是它能模块化,不同项目共享 AWS 资源时也更方便。而使用 CloudFormation 的话,一不小心就会写出一个超大的 YAML 文件来,要使用共同的 AWS 资源时,谁来创建是个不小的问题。CloudFormation 稍值得称道的地方也就是有一个可视化的  Stack,但把  Terraform 执行的 state 存到 S3 也不差。使用 Terraform 还有一个最享受的地方就是它的官方文档组织的非常清晰。

出品 Terraform 的公司 HashiCorp 秉持着 Infrastructure as Code,近日在忙着 IPO, 估值在 $13B, Ticker 将为 HCP(该链接直接可用时便以上市),介时也值得关注一下。扯远了,回到日常使用 Terraform 的变量上来。

本文直接参考自 Terraform 官网的 Input Variables。不管英文好不好都应该读原文去理解 Terraform 变量的详细使用方法。这里主要是了解各种输入变量的方式,以及验证一下当同时用多种方式输入重复的变量时,以谁为最终的结果。 阅读全文 >>

AWS Assume IAM role 的使用

AWS 要授权给他人访问指定资源有哪几种方式呢?

  1. 创建一个 AWS 帐号让别人用,那是 AWS 干的事
  2. 在自己帐号下创建一个用户,把 Access Key ID 和 Secret Access Key 告诉别人。可为该用户限定权限,但任何获得那两个 Key 的人都能使用该用户。
  3. 创建一个 IAM Role, 并指定谁(帐号或 Role) 能以该 Role 的身份来访问。被 Assume 的 Role 可限定权限和会话有效期。

用 Assume Role 的方式具有更高的安全可控性,还不用维护 Access Key ID 和 Secret Access Key。比如在构建和部署时通常是有一个特定的 Account, 然后 Assume 到别的 IAM Role 去操作资源。

本文将详细介绍在帐号 A 创建一个 IAM Role(标注为 R) 并分配一些权限,然后允许另一个帐号 B 以 IAM Role - R 的身份来访问帐号 A 下的资源。IAM Role 将用 awscli 来创建,Assume Role 的过程用 awscli 和 boto3 Python 代码两种方式来演示。 阅读全文 >>

构建 AWS Lambda Python Docker 镜像

AWS 的 Lambda 在 2020-12-01 开始支持用 Docker 镜像存放代码,见 New for AWS Lambda - Container Image Support。AWS Lambda 最初的对发布包的限制是 50M, 解压后(因为执行前需要解压缩)不能超过 250M,对于压缩比小于 1/5 的包来说,要突破 50M 部署包的限制就要用 2018-11-29 推出的层(layer), 即把 Lambda 的依赖可以组织为层,每个 Lambda 可引用最多 5 个层,但最终 Lambda 加上层所解压后的大小仍然有 250 M 的限制。

对于使用了大量依赖的 Lambda,比如 Python 中用了 Pandas 之类的数学分析包,250M 的大小是不够的,所以才有了 Docker 镜像化的 Lambda, 镜像的大小限制一下蹦到 10G,要构建出一个 10G Lambda 用的 Linux 镜像, 那绝对是个巨兽,至少目前是超越我的想像力,除非往里面塞入大量的业务数据。关于 Lambda 有哪些限制,请参阅 Lambda quotas

介绍完 Lambda 引入 Docker 镜像的背景后,本文接下来只关注如何构建一个 Python Lambda 镜像,对于如何部署 Docker 化的 Lambda, 不在本文的范围之内。主要的参考文档为 AWS Lambda 官方的 Deploy Python Lambda functions with container images. 阅读全文 >>

Lambda + API Gateway 创建需 API Key 验证的 API

希望在标题上尽量包含更多的信息,原本命题为: Lambda + API Gateway 创建需 API Key 验证的 API(Docker + Python + Terraform), 但是觉得太长了,于是只取了前半部份。仍然要在开头部分强调一下本文件打算要实现什么

  1. 在 AWS  用 Lambda  和  API Gateway 创建 API
  2. 创建的 API 是 public 的,需要用 x-api-key 来验证
  3. Lambda 的实现代码打包在了一个 Docker 镜像中
  4. 整个 AWS 的基础架构(包括 ECR, Lambda, API Gateway 及权限等)是由 Terraform 脚本创建管理的

目标明确,我们直冲到代码的目录结构来,项目目录为 api-gateway-demo, Github 上的链接为 api-gateway-demo. 后面详叙还会把其中每一个文件的内部给列出来 阅读全文 >>