因为平常主要是使用 EC2 的 Linux 实例，所以之前写过的一篇关于 UserData 的日志 创建 AWS EC2 实例时 userdata 的一些知识 默认就是讲的有关 Linux 实例的 UserData。本文补充上 Windows 的 EC2 实例 UserData 的基本使用，参考自 AWS 官方文档 Run commands on your Windows instance at launch。
Windows 的 UserData 被谁执行，依据所选择 AMI 的不同有以下三种方式
通常在 Python 应用中简单的配置使用内置的 logging 是这样的
|
1 2 3 4 5 6 |
import logging logging_format = '%(asctime)s - %(levelname)s - %(module)s(%(funcName)s:%(lineno)d) - %(message)s' logging.basicConfig(level=logging.INFO, format=logging_format) logging.info('hello world') |
假如文件名为 test.py, 用 python test.py 执行后输出
2022-01-25 21:02:47,231 - INFO - test(<module>:6) - hello world
可是这同样的代码放到 AWS Lambda Python 代码中却不灵验了，logging.info() 将得不到任何输出。 阅读全文 >>
关于 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 阅读全文 >>
本人在 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 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 在 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(Docker + Python + Terraform), 但是觉得太长了，于是只取了前半部份。仍然要在开头部分强调一下本文件打算要实现什么
目标明确，我们直冲到代码的目录结构来，项目目录为 api-gateway-demo, Github 上的链接为 api-gateway-demo. 后面详叙还会把其中每一个文件的内部给列出来 阅读全文 >>
AWS 提供的 NoSQL 数据库有 DynamoDB, DocumentDB(即 MongoDB), 和 Keyspaces(即 Cassandra)。还有一个神秘的早已消失于 AWS 控制台之外的 SimpleDB，它只能通过 API 才能使用。因为 AWS 有意要把它藏起来，不愿被新用户看到它，希望用 DynamoDB 替代它，关于用 aws cli 如何体验 AWS SimpleDB 可见本文后面部分。
DynamoDB 所设计的读写容量参数的概念，AWS 为其标榜是为保证一致性与明确的性能表现，实际上不如说是一个赚钱的计量单位，为了钱反而是把一个简单的事情弄复杂了。当需要全局索引时，必须为全局索引设定读写容量，连索引的钱也不放过。本文只为体验对 DynamoDB 的常用操作，不管吞吐量的问题，所以不用关心读写容量的问题。
DynamoDB 后端用 SSD 存储，不像 Elasticache 是把数据放在内存当，对了 Elasticache 也是 AWS 提供了 NoSQL 服务。DynamoDB 每条记录(Item) 的大小限制为 400K. 阅读全文 >>
我们在初始一个 AWS EC2 实例时，可以通过 user data 让 EC2 第一次启动后做些事情，可以放置 shell script 或 cloud-init 指令。在控制台设置 user data 可用明文文本，由 awscli 创建时可使用一个文件，或者通过 API 用 base64 编码的内容。
下面是 user data 被执行时需知晓的一些知识
#! 开始，俗称 Shebang, 如 #!/bin/bashroot 身份执行，所以不要用 sudo, 当然创建的目录或文件的 owner 也是 root，需要 ec2-user 用户访问的话需要 chmod 修改文件权限，或者直接用 chown ec2-user:ec2-user -R abc 修改文件的所有者()apt install -y xzy, 带个 -y 标记/var/lib/cloud/instances/<instance-id>/user-data.txt 文件中，因此也可以从这里验证 user data 是否设置正确。或者在 EC2 实例上访问 http://169.254.169.254/latest/user-data 也能看到 user data 的内容。并且在 EC2 实例初始化后不被删除，所以以此实例为基础来创建一个新的 AMI 需把它删除了/var/log/cloud-init-output.log, 它会捕获 cloud-init 控制台的输出内容 DynamoDB Stream 的实质就是一个依附于表的流，对表的增删改像关系型数据的触发器一样，以日志形式按顺记录到该流中。我们可以用 API 去读取其中的记录，或用来触发一个 Lambda。DynamoDB Stream 非常类似于 Kinesis 的 Stream, 它们都是有 Shard 的概念，但是 DynamoDB Stream 的 Shard 数目是不太确定的。而且还能用 KCL(Kinesis Client Library) 来操作 DynamoDB Stream。
DynamoDB Stream 和 Kinesis Stream 有几个通用的 API 操作，像 list_streams(), describe_stream(), get_shard_iterator() 和 get_records() 函数。同时呢，在设置 Lambda 的触发器时，选择 DynamoDB Stream 与 Kinesis Stream 时可配置的参数几乎是一样的，有 Batch size, Batch window, Starting position 以及重试策略。而且也是一个 Shard 只能同时启动一个 Lambda 实例，由于 DynamoDB Stream 的 Shard 数目不太确定，所以它能同时启动几个 Lambda 实例也不确定的。
另外， 一个 DynamoDB Stream 只能最多被两个 Consumer 消费，而可用来消费 Kinesis Stream 的 Consumer 数目是不受限的。DynamoDB Stream 中的记录保存时间为 24 小时， Kinesis Stream 中记录保存时间也是可配置的。我们创建一个 DynamoDB 表时还能启用 Amazon Kinesis data stream details, 即把对 DynamoDB 的操作记录直接发送到 Kinesis Stream 中去，这样就能操作熟悉的 Kinesis Stream，Shard 数目可设定，坏处就是 Kinesis Stream 较费钱。 阅读全文 >>