# 进程守护程序任务定义
进程守护程序任务定义是您的进程守护程序的蓝图。Amazon ECS 托管进程守护程序使用专用的进程守护程序任务定义资源，这与标准的 Amazon ECS 任务定义不同。您可以注册进程守护程序任务定义来指定进程守护程序的容器映像、资源要求和配置。
## 创建进程守护程序任务定义
您可以使用 AWS 管理控制台 或 AWS CLI 创建进程守护程序任务定义。
### 使用 AWS 管理控制台
1. 打开 Amazon ECS 控制台。在左侧导航窗格中，选择**进程守护程序任务定义**。
1. 选择**创建新的进程守护程序任务定义**。
1. 对于**进程守护程序任务定义系列**，输入一个唯一的名称。名称最多可以包含 255 个字母数字字符、连字符和下划线。
1. （可选）对于**任务角色**，选择一个 IAM 角色来向在容器中运行的应用程序授予权限。如果您的容器不调用 AWS API，请将此选项留空。
1. （可选）对于**任务执行角色**，选择 `ecsTaskExecutionRole`。Amazon ECS 需要此角色才能提取容器映像和发布日志。
1. （可选）对于**任务大小**，请指定要为进程守护程序保留的 CPU 和内存。例如，`0.25 vCPU` 和 `512 MB` 内存。
1. 配置您的容器详细信息：
+ **容器名称** - 输入容器的名称。名称最多可以包含 255 个字母数字字符、连字符和下划线。
+ **必备容器** - 选择**是**。每个进程守护程序任务定义都至少需要一个必备容器。如果必备容器出现故障，Amazon ECS 将停止整个任务。
+ **映像 URI** - 输入 Docker 映像 URI。您可以浏览 Amazon ECR 映像或使用来自 Docker Hub 或其他注册表的公有映像。
1. （可选）根据需要配置资源分配、运行状况检查、环境变量、日志收集和标签。
1. 查看您的配置，然后选择**创建**。
### 使用 AWS CLI
通过创建 JSON 文件并使用 `register-daemon-task-definition` 命令来注册进程守护程序任务定义。
以下是示例 JSON 文件：
```
{
"family": "my-daemon-task",
"containerDefinitions": [
{
"name": "daemon-container",
"image": "public.ecr.aws/docker/library/busybox:latest",
"essential": true,
"command": ["sh", "-c", "while true; do echo 'Daemon running'; sleep 30; done"],
"memoryReservation": 512
}
]
}
```
运行以下命令注册进程守护程序任务定义：
```
aws ecs register-daemon-task-definition --cli-input-json file://daemon-taskdef.json
```
## 进程守护程序任务定义参数
注册进程守护程序任务定义时，您可以使用以下参数。
**必填参数**
+ `family` - 任务定义的系列名称。它将同一个进程守护程序任务定义的多个修订版分组在一起。
+ `containerDefinitions` - 描述进程守护程序任务中容器的 `DaemonContainerDefinition` 对象数组。
**可选参数**
+ `cpu` - 以字符串形式表示的任务级 CPU 单元（例如，`"256"`）。
+ `memory` - 以字符串形式表示的任务级内存（以 MiB 为单位）（例如 `"512"`）。
+ `taskRoleArn` - 为您的进程守护程序任务中的容器授予权限的 IAM 角色的 ARN。
+ `executionRoleArn` - Amazon ECS 容器代理用于代表您进行 AWS API 调用（例如，从 Amazon ECR 提取映像）的 IAM 角色的 ARN。
+ `volumes` – `DaemonVolume` 对象的数组。进程守护程序卷仅支持具有 `host` 和 `sourcePath` 的绑定挂载。进程守护程序任务定义不支持 Amazon EBS、Amazon EFS、FSx for Windows File Server、Docker 卷或临时存储。
+ `tags` - 用于标记进程守护程序任务定义的键值对数组。
+ `pidMode`：控制进程守护程序的 PID 命名空间模式。
+ `ipcMode`：控制进程守护程序的 IPC 命名空间模式。
## 网络模式
进程守护程序使用 Amazon ECS 自动设置的特殊 `daemon_bridge` 网络模式。您不能在进程守护程序任务定义中指定网络模式。实例上的所有进程守护程序共享一个网络命名空间，并且可以通过静态进程守护程序桥接 IP 地址（IPv4 为 `169.254.172.2` 或 IPv6 为 `fd00:ec2::172:2`）进行本地访问。应用程序任务（非进程守护程序）可以在此地址与进程守护程序通信，无需进行额外的网络配置。
由于进程守护程序在与应用程序任务不同的网络命名空间中运行，因此非进程守护程序任务无需担心与进程守护程序的端口冲突。然而，由于所有进程守护程序任务共享同一个命名空间，因此同一实例中的进程守护程序不能绑定到相同的端口。部署多个进程守护程序时，请确保每个进程守护程序使用唯一的端口。
## 特权功能
在 Amazon ECS 托管实例上，进程守护程序支持用于系统级操作的特权 Linux 功能。安全代理、网络监控工具和可观测性代理通常需要内核级别的访问权限才能正常运行。
您可以通过两种方式授予功能：
**完全特权模式**向容器授予所有 Linux 功能。当您的代理需要广泛的系统访问权限时，请使用此选项：
```
{
"containerDefinitions": [{
"name": "security-daemon",
"image": "my-security-agent:latest",
"privileged": true
}]
}
```
**单个功能**仅根据最低权限原则授予您的进程守护程序需要的权限。使用 `linuxParameters.capabilities` 字段添加各项功能，如 `SYS_ADMIN`、`NET_ADMIN`、`SYS_PTRACE`、`BPF` 和 `PERFMON`：
```
{
"containerDefinitions": [{
"name": "monitoring-daemon",
"image": "my-monitoring-agent:latest",
"linuxParameters": {
"capabilities": {
"add": ["NET_ADMIN", "SYS_PTRACE"]
}
}
}]
}
```
## PID 和 IPC 命名空间共享
在 Amazon ECS 托管实例上，进程守护程序支持 PID 和 IPC 命名空间共享，从而支持需要查看应用程序任务进程或 IPC 资源的用例，例如安全代理、监控工具和可观测性守护程序。
`pidMode`
类型：字符串
必需：否
有效值：`none` \| `shared`
默认值：`none`
进程守护程序的 PID 命名空间模式。如果指定 `none` 或未提供任何值，则进程守护程序将使用自己的 PID 命名空间运行，与其他任务实现隔离。如果指定 `shared`，则进程守护程序将加入主机 PID 命名空间，以便使用 `pidMode: "host"` 的非进程守护程序或使用 `pidMode: "shared"` 的其他进程守护程序可以访问该命名空间。
`ipcMode`
类型：字符串
必需：否
有效值：`none` \| `shared`
默认值：`none`
进程守护程序的 IPC 命名空间模式。如果指定 `none` 或未提供任何值，则进程守护程序将使用自己的 IPC 命名空间运行，与其他任务实现隔离。如果指定 `shared`，则进程守护程序将加入主机 IPC 命名空间，以便使用 `ipcMode: "host"` 的非进程守护程序或使用 `ipcMode: "shared"` 的其他进程守护程序可以访问该命名空间。
以下示例显示了同时启用 PID 与 IPC 命名空间共享的进程守护程序任务定义：
```
{
"family": "my-monitoring-daemon",
"pidMode": "shared",
"ipcMode": "shared",
"containerDefinitions": [
{
"name": "monitoring-agent",
"image": "public.ecr.aws/my-company/monitoring-agent:latest",
"essential": true
}
]
}
```
要与 `pidMode` 设置为 `shared` 的进程守护程序共享 PID 命名空间，非进程守护程序任务必须在其任务定义中指定 `pidMode: "host"`。这样任务的容器就可以查看进程守护程序的进程，并支持诸如进程监控和信号传递之类的用例。
要与 `ipcMode` 设置为 `shared` 的进程守护程序共享 IPC 命名空间，非进程守护程序任务必须在其任务定义中指定 `ipcMode: "host"`。这样任务的容器就可以访问进程守护程序的 IPC 资源，例如共享内存段和消息队列。
## 卷
托管进程守护程序支持使用具有 `sourcePath` 规范的主机卷进行绑定挂载。这允许进程守护程序容器挂载主机目录，以访问底层 Amazon EC2 实例上的日志、指标和系统信息。日志收集代理、指标导出器和安全扫描程序通常会利用此功能来获取主机层面的数据信息。
进程守护程序任务定义支持具有 `sourcePath` 的主机卷规范。进程守护程序卷在底层容器实例的生命周期内持续存在。
**注意**
进程守护程序任务定义不支持 Amazon EBS 卷、Amazon EFS 卷、FSx for Windows File Server 卷、Docker 卷或临时存储。
**注意**
进程守护程序不支持彼此之间的卷共享。每个进程守护程序都使用自己的独立卷配置运行。
以下示例展示了一个带有绑定挂载的日志收集进程守护程序：
```
{
"containerDefinitions": [{
"name": "log-collector",
"image": "fluent/fluentd:latest",
"mountPoints": [{
"sourceVolume": "var-log",
"containerPath": "/var/log"
}]
}],
"volumes": [{
"name": "var-log",
"host": {
"sourcePath": "/var/log"
}
}]
}
```
## 支持的容器参数
进程守护程序容器定义支持以下参数：
+ `image`（必填）- 容器映像 URI
+ `name`（必填）- 容器名称
+ `cpu` - 为容器保留的 CPU 单位
+ `memory`/`memoryReservation` - 硬内存和软内存限制
+ `essential` - 容器是否必备（默认值：true）
+ `command`/`entryPoint` - 覆盖容器命令或入口点
+ `environment` / `environmentFiles` / `secrets` - 环境配置
+ `privileged` - 在特权模式下运行容器
+ `user` - 以其身份运行容器的用户
+ `workingDirectory` - 容器内的工作目录
+ `readonlyRootFilesystem` - 将容器的根文件系统挂载为只读
+ `mountPoints` - 卷挂载点（仅将装载与主机和 sourcePath 绑定）
+ `logConfiguration` - 日志记录配置（支持 awslogs、splunk、awsfirelens）
+ `healthCheck` - 容器运行状况检查配置
+ `dependsOn` - 容器启动依赖项
+ `ulimits` - 资源限制
+ `systemControls` - 内核参数
+ `linuxParameters.capabilities` - 可添加或删除的 Linux 功能
+ `linuxParameters.initProcessEnabled` - 在容器中运行 init 进程
+ `repositoryCredentials` - 私有注册表的凭证
+ `restartPolicy` - 容器重启策略