上篇 AWS ECS 使用 EC2 Capacity Provider (EC2 Auto Scaling) 学习了如何在 ECS 中使用 Capacity Provider + EC2 Auto Scaling 来部署一个简单的 Web 应用，以及了解 ECS 如何管理 EC2 的 Auto Scaling Group.

ECS Capacity Providers 是于 2019 年 12 月发布的，随同的功能支持了 Fargate, Fargate Spot, 和 EC2 AutoScaling. 而 Managed Instances 在 2025-09-30 才加入的新特性，见 Announcing Amazon ECS Managed Instances.

在近六年之间, AWS 大概也理解到了 Capacity Provider + EC2 Auto Scaling 的复杂性，虽说可由 ECS 来管理 EC2 的 ASG, 但毕竟有个 ASG 在那里。 ECS 与 EC2 ASG 之间联接由 CloudWatch Metrics, Alarms, EC2 ASG 的 Dynamic scaling policies 和 Lifecycle hooks 的一整套机制协作。 经常还不得不在 EC2 ASG 与 ECS 两个界面之间来回找问题。而 Managed Instances 的出现则将 EC2 实例的管理完全透明化了，在 EC2 端压根就不存在 一个相应的 ASG, 更不需要 CloudWatch Alarms 之类的关联组件。

Managed Instances 与 EC2 Auto Scaling 之间就好比 Serverless 与 非 Serverless 的区别，用 Managed Instances 之后你只管控制好 ECS Desired Count(ECS AutoScaling), 其余的都由 Managed Instances 来管理，在界面上只需要关注 ECS Infrastructure 中的 Container Instances. 由 Managed Instances 管理的 EC2 实例，你即使用有管理员权限都无法关闭它，只能全权由 Managed Instances 来控制。试图关闭这样的 EC2 实例时报错

在我 X 中 AWS 上不同应用的部署策略 中提到过在 AWS 部署服务(特别是 Web 服务时)， 基于采用过以下演进的方式

1. EC2(AutoScaling) + 直接 EC2 中部署本地应用, 靠 userdata 完成应用部署 2 EC2(AutoScaling) + ECS(AutoScaling), 运行容器，Replica 模式，有两个层次的 AutoScaling 要单独控制，比较麻烦
2. ECS + EC2(AutoScaling), 运行容器，Daemon 模式。由 EC2 来驱动部署 ECS Task
3. ECS(AutoScaling) + Fargate, 运行容器。这是最简单的，但硬件资源受限, 想要强大的 CPU, 没门
4. ECS(AutoScaling) + Capacity Provider(EC2) + EC2(Managed AutoScaling), 运行容器。由 ECS Task 发起 EC2 实例需求
5. ECS(AutoScaling) + Capacity Provider(Fargate)，运行容器，Serverless 就是简单，同样硬件资源受限
6. EKS，开启 Auto mode，一切变得简单，像是 Capacity Provider(EC2). 但会涉及到复杂的 EKS 配置管理，集群内网络，如 ELB,
   基于服务的 WAF, IAM Role. 但基本是一次的工作，建立了健壮的 EKS, 以后部署任何应用都变得很轻松。

对于 #2 和 #3, 如果选择 Network 模式为 vpc 的话，即每个容器都会有自己的 IP 地址，并且 Target Group 中注册的是 IP 地址，这时候 AutoScaling 在缩减实例时就要靠 AutoScaling 的 Lifecycle Hook 来处理对相应 ECS Task 的通知，因为 EC2 的 AutoScaling 只知在开始关闭实例停止向相应实例 转发请求. 如果 Network 模式为默认的 Bridge 则没问题，因为请求是过通 NAT 方式(如 32768:80) 由 EC2 实例转发到其中的容器。

本文主要专注在 Docker 内的应用进程如何与外部发过来的 Linux 信号进行响应。具体应用在当运行为一个 ECS 的 Docker 容器时，对 ECS 的 AutoScaling 以及部署时如何让应用能正确收到相应的信号。关于 Linux 的 Signal 请参考 Wikipedia 的 Signal(IPC).

其实相关的话题在以前三篇中都有涉及

1. 如何向 Docker 容器传递参数
2. AWS Batch 是如何向 Docker 容器传递参数
3. Dockerfile 中命令的两种书写方式的区别

不同 Dockerfile 的 ENTRYPOINT 或 CMD 会影响到 Docker 内进程的启动方式，额外参数的接收方式，以及信号的传递。本篇只关注在信号这一议题。 先学习本地的 Docker 容器内与对 docker stop 或 docker kill 发出的信号的响应，进而讲述运行在 ECS 的容器与 ASG，部署行为的信号响应。

本文初衷是要专注在 Docker 内的应用进程如何与外部发过来的 Linux 信号进行响应。具体应用在当运行为一个 ECS 的 Docker 容器时，对 ECS 的 AutoScaling 以及部署时如何让应用能正确收到相应的信号。可是一提及这一话题，思维就产生了极大的发散，很想好好捋一捋进程与 Linux 信号之间关系和相关的概念。 关于 Linux 的 Signal 请参考 Wikipedia 的 Signal(IPC).

本文以渐进的方式，从信号的简介，本地 C, Bash, Java 程序与信号，然后将在下一篇学习本地 Docker 容器内进程与信号的处理，ECS 的容器与 ASG，部署行为的信号响应。

前篇 MacOS/Linux C++ GDB 远程调试基础 演示了如在 macOS 开发调试远程 Linux 下的 C++ 程序， 本篇将结合 C 语言静态库与动态库的生成和使用 练习如何调试含动态库，静态库的 C++ 程序, 并了解如何指定符号文件。

示例源码

本文将用以下的目录结构, 分别验证主程序与动态库，静态库的源代码断点调试，以及把源文件放在不同目录中是否有特别之处。

1├── dynamic        # 动态库
2│   └── add.cpp
3├── static         # 静态库
4│   └── sub.cpp
5└── main.cpp       # 主程序

有那么一个古老的项目，编译用的是 g++, 目标平台的是 Linux x86_64， 构建工具是 make. 本地开发环境是 macOS, 硬件为 Arm64 的苹果芯片 M4， IDE 尝试用 CLion, 如果喜欢的话，也可以选择 VSCode.

想要单步调试的目的就是想让代码跑起来，然后逐步理解代码执行的逻辑。所以不想对现有项目构建过程进行改造，如换成 CMake, 使用 LLVM 编译之类的。 只想使用远程 Linux 机器, 仍然使用原来的 make 命令编译，然后在 Linux 下启动程序，由 Clion 连到的 Linux 上进程， 关联源代码进行调试。

因为编译用的 g++, 所以采用 gdbserver 和 gdb 进行远程调用，llvm 相应的解决方案是 lldb-server + lldb. 下面是关键的步骤

. 本地 Clion 中编辑代码 . 代码传到远程 Linux 机器 . 远程 Linux 机器上编译，编译的二进制代码要保留符号信息 . 在 Linux 机器上的符号文件要下载给 Clion . 在远程用 gdbserver 指定端口启动程序 . 本地 Clion 配置用 GDB 连接到远程 Linux 机器上的 gdbserver . 在 Clion 中断点单步调试

上面是基本的操作，当我们用某个客户端工具(比配置运行 Clion 的 Remote GDB Server) 就自动完成以上的某些操作，如自动双向同步源代码与二进制/符号文件, 自动驱动远程端的的编译，启动 gdbserver. 远程 Linux 还能进一步使用 Docker 容器替代。但是在苹果芯片的 macOS 中启动 x86_64 的容器中运行的 gdbserver 在 macOS 中用 gdb 是连不上的。

Bash 环境

多数时候我们用的是 Bash, 比如个人的 Linux 不愿去定制，远程服务器的由不得你去定制，所以就从 Bash 说起。

默认键绑定 emacs, 操作是 ctrl-x, ctrl-e

在默认的 Bash  环境下，只要在命令行中按下 ctrl-x, ctrl-e 就会把当前命令的内容调入到环境变量  $EDITOR 指示的编辑器(默认为 emacs)去编辑，编辑后保存退出就会立即执行。

如果未安装 Emacs 编辑器，在按下 ctrl-x, ctrl-e 会得到如下提示

[vagrant@localhost ~]$
-bash: emacs: command not found

如果希望使用 vi 来编辑当前命令，就需要设置 EDITOR 环境变量，比如在 .bashrc 中加入

export EDITOR=vi

那么在命令行中按下 ctrl-x, ctrl-e 使用打开  vi 来编辑当前命令。

注：Emacs 要用 ctrl-x, ctrl-c, 再回答 y, 命令保存到临时文中; 而 vi 的相应操作是 :wq, 至少这个操作上 vi 要简洁些。 Read More