当我们直接使用 Tomcat 时，访问日志的配置在 $TOMCAT_HOME/conf/server.xml 中<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
产生的日志文件在 $TOMCAT_HOME/logs 目录中，生成以日期戳进行区分的滚动日志文件，如 localhost_access_log.2022-10-25.txt 等
prefix="localhost_access_log" suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
而在我们使用 Spring Boot Web 时, 默认的嵌入式 Web 应用服务器是 Tomcat，我们可以在 Spring 属性文件中配置是否启用 Tomcat 访问日志(默认不启用)。属性文件中的配置针对的是如何输出访问日志到文件，而我们有时候需要输出访问日志到控制台而不非文件，比如 AWS 上的 ECS 应用，控制台的输出可直接发送到 CloudWatch，这样便于分析日志。
在 Spring Web 中可以用 Interceptor 或 Filter 来记录访问日志，但在请求出错时无法准确显示出响应时间和状态码，毕竟 Tomcat 的访问日志在代码的外层，进出 Controller 方法的输入输出信息也就掌握的更清楚。
本文的任务是探索输出 Spring Boot Web 嵌入式 Tomcat 的访问日志到控制台。有两种方式 Read More
使用到 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 镜像是类似的。 Read More- 因为平常主要是使用 EC2 的 Linux 实例，所以之前写过的一篇关于 UserData 的日志 创建 AWS EC2 实例时 userdata 的一些知识 默认就是讲的有关 Linux 实例的 UserData。本文补充上 Windows 的 EC2 实例 UserData 的基本使用，参考自 AWS 官方文档 Run commands on your Windows instance at launch。
Windows 的 UserData 被谁执行，依据所选择 AMI 的不同有以下三种方式- EC2Launch v2: 最新方式，只是被当前预览版的 AMI 所支持，它支持 YAML 配置的脚本
- EC2Launch: 当前方式，Windows Server 2016 及更新版
- EC2Cofnig: 旧有方式， Windows Sever 2012 R2 及旧版本
- 通常在 Python 应用中简单的配置使用内置的 logging 是这样的
1import logging 2 3logging_format = '%(asctime)s - %(levelname)s - %(module)s(%(funcName)s:%(lineno)d) - %(message)s' 4logging.basicConfig(level=logging.INFO, format=logging_format) 5 6logging.info('hello world')
假如文件名为 test.py, 用 python test.py 执行后输出2022-01-25 21:02:47,231 - INFO - test(<module>:6) - hello world
在 Lambda 中的现象
可是这同样的代码放到 AWS Lambda Python 代码中却不灵验了，logging.info()将得不到任何输出。 Read More 
本人在 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 变量的详细使用方法。这里主要是了解各种输入变量的方式，以及验证一下当同时用多种方式输入重复的变量时，以谁为最终的结果。 Read More
- 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. Read More - 我们在初始一个 AWS EC2 实例时，可以通过 user data 让 EC2 第一次启动后做些事情，可以放置 shell script 或 cloud-init 指令。在控制台设置 user data 可用明文文本，由 awscli 创建时可使用一个文件，或者通过 API 用 base64 编码的内容。
下面是 user data 被执行时需知晓的一些知识- 是脚本时必须以
#!开始，俗称 Shebang, 如#!/bin/bash - user data是以
root身份执行，所以不要用sudo, 当然创建的目录或文件的 owner 也是root，需要ec2-user用户访问的话需要chmod修改文件权限，或者直接用chown ec2-user:ec2-user -R abc修改文件的所有者() - 脚本不能交互，有交互时必须想办法跳过用户输入，如
apt install -y xzy, 带个-y标记 - 如果脚本中需访问 AWS 资源，权限由 Instance Profile 所指定的 IAM role 决定
- user data 中的脚本会被存储在
/var/lib/cloud/instances/<instance-id>/user-data.txt文件中，因此也可以从这里验证 user data 是否设置正确。或者在 EC2 实例上访问 http://169.254.169.254/latest/user-data 也能看到 user data 的内容。并且在 EC2 实例初始化后不被删除，所以以此实例为基础来创建一个新的 AMI 需把它删除了 - user data 的大小限制为 16 KB, 指 base64 编码前的大小
- cloud-init 的输出日志在
/var/log/cloud-init-output.log, 它会捕获 cloud-init 控制台的输出内容
Read More - 是脚本时必须以
- The most common way to manage a remote machine is SSH (Unix/Linux, Mac) or PowerShell/RDP (Windows), which requires the remote machine to open the corresponding access port and firewall, credentials or SSH Key. When selecting an EC2 instance on AWS console, we can click the "Connect" button, which provides three connection options:
- EC2 Instance Connect: Requires EC2 to be configured with SSH Key, sshd is started, ssh inbound port allowed by Security Group,
ec2-instance-connectinstalled(sudo yum install ec2-instance-connect) - Session Manager: This is what we are going to talk about next. sshd is not required(SSH key is not needed of cause). Security Group only requires outbound port 443.
- SSH client: Client SSH to EC2 instance, start sshd, allow inbound ssh port 22 by Security Group, use SSH Key or username and password in AMI, or configure to login with domain account after joining the domain.
AWS Session Manager provides access to EC2 instances through a browser or AWS CLI, and even machines or virtual machines in the local datacenter (requires advanced-instances tier support) , and no longer depends on SSH.Session Manager Overview
Session Manager determines who can or cannot be accessed by the IAM access policy. It can be forwarded through the local port, the operation log in the session can be recorded as an audit, and can configure to send a message to Amazon EventBridge or SQS when session open or closed. The session log encrypted by a KMS key. Read More - EC2 Instance Connect: Requires EC2 to be configured with SSH Key, sshd is started, ssh inbound port allowed by Security Group,
- 管理一个远程机器最常规的做法是 SSH(Unix/Linux, Mac) 或 PowerShell/RDP(Windows)，这就要求远端机器要开通相应的访问端口及打开防火墙，配置好登陆用的用户名密码或 SSH Key。当选择一个 EC2 实例的时候，可以点击 "Connect" 按，它提供有三种连接选择：
- EC2 Instance Connect: 要求 EC2 配置了 SSH Key, 启动了 sshd 并开启了 ssh 的 Security Group，还要在实例上安装了
ec2-instance-connect(如安装命令 sudo yum install ec2-instance-connect) - Session Manager: 这就是我们本文要讲述的，sshd 不用启动，Security Group 只要求能往连接外部的 443 端口，SSH Key 不需要
- SSH client: 客户端 SSH 到 EC2 实例，需要打开 sshd 其 22 号端口接受连接的 Security Group，用 SSH Key 或 AMI 中的用户名和密码，或配置加入了域后使用域帐号验证登陆
AWS 的 Session Manager 提供了通过浏览器或 AWS CLI 来访问 EC2 实例，甚至是本地机房的机器或虚拟机(需 advanced-instances tier 的支持)，不再依赖于 SSH。 Read More - EC2 Instance Connect: 要求 EC2 配置了 SSH Key, 启动了 sshd 并开启了 ssh 的 Security Group，还要在实例上安装了
前面从无到有或是分别以 Docker Desktop, Minikube, kind 来搭建过 Kubernetes 集群。而如今各大云服务提供商基本都推出了各自的 Kubernetes 服务，例如：- Google GKE - Google Kubernetes Engine
- Amazon EKS - Amazon Elastic Kubernetes Service
- Microsoft AKS - Azure Kubernetes Service
- IBM Cloud Kubernetes Service
- Alibaba Cloud Container Service
所以对 Kubernetes 的进一步学习过程中何不一跃而直上云霄，直接尝试 AWS 的 EKS 如何搭建。EKS 是在 2018 年 6 月份正式推出，见 Amazon Elastic Container Service for Kubernetes Now Generally Available。EKS 在 AWS 上是与 ECS 并列的服务，它们的功能也比较类似，都是伸缩性的容器服务，ECS 配置管理更分散，EKS 本身就是一个集群管理工具。它们也有些共同的东西，如 Auto Scaling Groups, Launch Templates。
现在用 Terraform 脚本来演示一下如何创建一个 EKS 集群，并启动三个 EC2 Worker 节点(EKS 也支持 Fargate Worker 节点)，并部署一个应用。Terraform 脚本将会列出完成该任务的基本要素，也将会看看背后发生了什么。 Read More