基于 Docker Compose 部署 Apache APISIX:全栈 API 网关实践

基于 Docker Compose 部署 Apache APISIX:全栈 API 网关实践

本文基于 APISIX 3.9.1 + Dashboard 3.0.1 + etcd 3.5.15 + Prometheus + Grafana 的生产级 Docker Compose 部署实践。


一、整体架构

本次部署采用 Docker Compose 编排五大组件,形成从配置管理到流量监控的完整闭环:

整体架构

组件 版本 作用 端口
APISIX 3.9.1-debian API 网关核心,路由转发、插件执行 9080/9443
Dashboard 3.0.1-alpine 可视化配置管理界面 9000
etcd 3.5.15 分布式配置存储,APISIX 的数据后端 2379
Prometheus v2.53.1 指标采集与存储 9090
Grafana 11.1.1 监控数据可视化 3000

所有组件运行在 Docker Bridge 网络 apisix 中,通过容器名互访,对外通过宿主机端口映射提供服务。


二、端口映射设计

采用 2xxxx 系列高位端口,避免与宿主机常用端口冲突:

端口映射

服务 功能 宿主机端口 容器端口
APISIX Admin API 29180 9180
APISIX HTTP 代理 29080 9080
APISIX Prometheus Metrics 29091 9091
APISIX HTTPS 代理 29443 9443
APISIX Control API 29092 9092
Dashboard 管理界面 29000 9000
etcd 客户端通信 22379 2379
Prometheus Web UI 29090 9090
Grafana 可视化面板 23000 3000

三、数据流分析

整个系统包含两条核心数据流:配置流监控流

配置与监控数据流

3.1 配置流

  1. Dashboardetcd:运维人员通过 Dashboard 创建路由、配置插件,数据写入 etcd
  2. etcdAPISIX:APISIX 通过 etcd watch 实时感知配置变更,无需重启即可生效

这种 etcd 驱动的配置模式是 APISIX 的核心设计优势 —— 配置热更新,零中断

3.2 监控流

  1. APISIXPrometheus:APISIX 内置 prometheus 插件,在 9091 端口暴露指标端点,Prometheus 以 5 秒间隔持续采集
  2. PrometheusGrafana:Grafana 以 Prometheus 作为数据源,通过预配置的 Dashboard 实现可视化

四、APISIX 核心配置

4.1 Admin API 双角色认证

APISIX 的 Admin API 定义了两个角色,各自持有独立 API Key:

Admin API 双角色认证

角色 权限 说明
admin 全量管理权限 可创建/修改/删除路由、插件、上游等所有资源
viewer 只读查看权限 仅可查看配置,不可修改
deployment:
  admin:
    allow_admin:
      - 0.0.0.0/0
    admin_key:
      - name: "admin"
        key: <admin-api-key>
        role: admin
      - name: "viewer"
        key: <viewer-api-key>
        role: viewer

生产环境中应将 allow_admin 限制为可信 IP 资段,而非 0.0.0.0/0

4.2 etcd 连接配置

deployment:
  etcd:
    host:
      - "http://etcd:2379"
    prefix: "/apisix"
    timeout: 30
  • host 使用 Docker 网络内的容器名 etcd,无需硬编码 IP
  • prefix: "/apisix" 是 APISIX 在 etcd 中的键前缀,与 Dashboard 配置一致
  • timeout: 30 秒,适应容器启动初期的网络延迟

4.3 Prometheus 插件配置

plugin_attr:
  prometheus:
    export_addr:
      ip: "0.0.0.0"
      port: 9091

指标端点绑定 0.0.0.0:9091,允许 Prometheus 从 Docker 网络内访问。指标路径为 /apisix/prometheus/metrics

4.4 Control API

apisix:
  enable_control: true
  control:
    ip: "0.0.0.0"
    port: 9092

Control API 用于 APISIX 自身健康检查与运行时信息查询,独立于 Admin API。


五、Dashboard 配置

5.1 访问控制

conf:
  allow_list:
    - 127.0.0.1
    - ::1
    - 0.0.0.0/0

allow_list 定义了 Dashboard Manager API 的 IP 白名单。当前配置允许所有访问,生产环境应收紧。

5.2 认证体系

Dashboard 认证体系

Dashboard 定义了两个登录账号:

用户名 角色 说明
admin 管理员 可管理所有配置
user 普通用户 受限操作权限
authentication:
  secret: <jwt-secret>
  expire_time: 3600
  users:
    - username: admin
      password: <admin-password>
    - username: user
      password: <user-password>

认证机制基于 JWT,Token 有效期 3600 秒(1 小时)。secret 字段强烈建议修改,默认值会在启动时被随机替换。

5.3 etcd 连接

conf:
  etcd:
    endpoints:
      - etcd:2379

与 APISIX 使用相同的 etcd 地址,确保配置读写一致性。

5.4 日志级别

conf:
  log:
    error_log:
      level: warn

日志级别设为 warn,平衡了信息量与性能开销,适合生产环境。


六、插件生态

Dashboard 配置中声明了完整的插件列表,涵盖六大核心类别:

核心插件分类

类别 代表插件 典型场景
认证鉴权 jwt-auth, basic-auth, key-auth, openid-connect, cas-auth API 身份验证、OAuth2 集成
限流熔断 limit-conn, limit-count, limit-req, api-breaker 流量控制、过载保护
可观测性 prometheus, skywalking, zipkin, opentelemetry 指标采集、分布式追踪
流量管控 traffic-split, proxy-mirror, proxy-rewrite, cors, gzip A/B 测试、灰度发布、跨域处理
安全防护 ip-restriction, uri-blocker, csrf, consumer-restriction IP 黑白名单、URL 过滤
日志记录 http-logger, kafka-logger, clickhouse-logger, syslog 请求日志收集、审计追踪

插件通过 etcd 配置动态加载,无需重启 APISIX 即可生效。


七、监控体系

7.1 Prometheus 采集配置

监控数据流水线

global:
  scrape_interval: 1s
  external_labels:
    stack: "apisix"

scrape_configs:
  - job_name: "prometheus"
    scrape_interval: 5s
    static_configs:
      - targets: ["localhost:9090"]
  - job_name: "apisix"
    scrape_interval: 5s
    metrics_path: "/apisix/prometheus/metrics"
    static_configs:
      - targets: ["apisix:9091"]

关键配置:

  • 全局默认采集间隔 1 秒,Prometheus 自身和 APISIX 各 5 秒
  • APISIX job 的 metrics_path 指定 /apisix/prometheus/metrics(APISIX 插件默认路径)
  • targets 使用 Docker 容器名 apisix,与 docker-compose 网络一致
  • external_labels.stack: "apisix" 为所有指标添加栈标签,便于多环境区分

7.2 Grafana 自动配置

Grafana 通过 provisioning 机制实现了 开箱即用

数据源自动配置:

datasources:
  - access: 'proxy'
    editable: true
    is_default: true
    name: 'apisix'
    org_id: 1
    type: 'prometheus'
    url: 'http://prometheus:9090'
    version: 1

数据源指向 Docker 内网的 Prometheus,Grafana 启动后即可直接查询 APISIX 指标。

Dashboard 自动加载:

providers:
  - name: 'default'
    orgId: 1
    folder: ''
    type: file
    options:
      path: /var/lib/grafana/dashboards

预置了 apisix-grafana-dashboard.json,启动后自动呈现 APISIX 专用监控面板,无需手动配置。

7.3 Grafana 安全配置

[security]
allow_embedding = true
content_security_policy = true

[auth.anonymous]
enabled = true
  • allow_embedding = true:允许 Dashboard 将 Grafana 面板嵌入 iframe
  • auth.anonymous.enabled = true:匿名访问,适合内部监控场景
  • CSP 中允许了内网 IP 段的 frame-src,支持 Dashboard 嵌入 Grafana 面板

八、etcd 配置要点

# etcd docker-compose 环境变量
ETCD_ENABLE_V2: "true"
ALLOW_NONE_AUTHENTICATION: "yes"
ETCD_ADVERTISE_CLIENT_URLS: "http://etcd:2379"
ETCD_LISTEN_CLIENT_URLS: "http://0.0.0.0:2379"

关键配置:

  • ETCD_ENABLE_V2: "true":APISIX 依赖 etcd V2 API,必须启用
  • ALLOW_NONE_AUTHENTICATION: "yes":无认证模式,适合内网部署;生产环境应启用认证
  • advertise URL 使用容器名:确保 Docker 网络内客户端能正确发现 etcd
# etcd.conf.yml 关键参数
heartbeat-interval: 100
election-timeout: 1000
auto-compaction-mode: periodic
auto-compaction-retention: "1"
  • auto-compaction-mode: periodic + retention: "1":每小时自动压缩历史数据,防止 etcd 数据无限膨胀
  • strict-reconfig-check: false:放宽重新配置检查,简化单节点部署

九、部署流程

部署流程

步骤 1:配置文件准备

根据实际环境修改以下关键配置:

  • apisix_conf/config.yaml:Admin API Key、etcd 地址
  • dashboard_conf/config.yaml:登录密码、JWT Secret、allow_list
  • prometheus_conf/prometheus.yml:采集目标地址
  • grafana_conf/config/grafana.ini:CSP 域名白名单

步骤 2:启动服务

docker-compose up -d

验证所有容器状态:

docker-compose ps

步骤 3:访问 Dashboard

浏览器打开 http://<宿主机IP>:29000,使用 admin 账号登录。

步骤 4:配置路由与插件

在 Dashboard 中创建 Route、Upstream,并绑定所需插件(如限流、认证、日志等)。

步骤 5:监控可视化

浏览器打开 http://<宿主机IP>:23000,查看预配置的 APISIX 监控面板。


十、生产环境加固建议

配置项 当前值 建议值 原因
Admin API allow_admin 0.0.0.0/0 限制为可信 IP 资段 防止未授权访问
Dashboard allow_list 0.0.0.0/0 限制为运维网段 防止未授权访问
etcd 认证 无认证 启用密码认证 防止配置数据泄露
Dashboard JWT Secret 默认值 自定义强密码 防止 Token 伪造
Admin API Key 硬编码值 自定义强随机字符串 防止 API 被滥用
Grafana 匿名访问 enabled 按需关闭 仅允许认证用户查看监控
CSP frame-src 内网 IP 按需收紧 防止 XSS 嵌入攻击

十一、实践总结

要点 说明 核心收益
Docker Compose 编排 五组件一键部署 简化运维,环境一致性
高位端口映射 2xxxx 系列端口 避免端口冲突
etcd V2 API 必须启用 APISIX 依赖 V2 读写配置
Admin 双角色 admin + viewer 权限分离,安全可控
Prometheus 5s 采集 高频指标收集 实时感知流量异常
Grafana 开箱即用 预配置数据源 + Dashboard 零配置即可可视化
CSP 嵌入允许 Dashboard 嵌入 Grafana 统一运维入口
etcd 自动压缩 periodic 1h 防止数据膨胀
插件动态加载 etcd 驱动热更新 配置即时生效,零重启
全栈可观测性 Metrics + Tracing + Logging 全方位洞察网关状态

阅读更多

Ghost 邮箱订阅功能在中国大陆的困境:Mailgun 注册受阻实录

Ghost 邮箱订阅功能在中国大陆的困境:Mailgun 注册受阻实录

本文记录了 Ghost 博客邮箱订阅功能因 Mailgun 在中国大陆无法注册而被迫关闭的完整过程,包括注册尝试、工单沟通及最终应对方案。 一、背景:Ghost 与 Mailgun Ghost 博客平台内置了邮箱订阅(Newsletter)功能,读者可以通过输入邮箱地址订阅博客更新,Ghost 会自动将新文章以邮件形式推送给订阅者。这一功能的邮件发送能力依赖于第三方邮件服务——Mailgun。 Ghost 官方推荐使用 Mailgun 作为邮件传输层,配置方式如下: 配置项 说明 示例值 mail.from 发件人地址 newsletter@yourdomain.com mail.transport 传输协议 SMTP mail.options.host SMTP 主机 smtp.mailgun.org mail.options.port

By 菱角
Kubernetes 全栈监控体系:kube-prometheus-stack + 7 大 Exporter 生产实践

Kubernetes 全栈监控体系:kube-prometheus-stack + 7 大 Exporter 生产实践

本文基于 kube-prometheus-stack Helm Chart 在 Kubernetes 上构建完整监控体系的实战,覆盖 Prometheus、Grafana、Alertmanager 及 7 个专用 Exporter 的部署与配置。 一、监控体系全景架构 整套监控以 kube-prometheus-stack 为核心,通过 ServiceMonitor CRD 自动发现并采集 7 大数据源,配合 Alertmanager 分级告警与 Grafana 可视化: 组件 版本 作用 Prometheus v2.45.0 指标采集与存储,10 天数据保留 Alertmanager v0.25.0 告警路由与邮件推送,2 副本 HA

By 菱角
在 Kubernetes 上部署 Apache Flink:生产实战指南

在 Kubernetes 上部署 Apache Flink:生产实战指南

本文基于 Flink 1.15.2 + Kubernetes 的生产环境部署实践。 一、架构概览 Flink 在 Kubernetes 上采用经典的 JobManager + TaskManager 主从架构,JobManager 负责作业调度与协调,TaskManager 承载实际的计算任务。 资源分配一览 组件 作用 副本数 Task Slots 内存配置 JobManager 作业调度、Checkpoint 管理、协调 1 — 8G TaskManager 执行计算任务 3 80/Pod 48G 总计 — 4 240 — 二、Namespace 隔离 为 Flink 创建独立 Namespace,

By 菱角
Kubernetes 环境下的 PostgreSQL 部署

Kubernetes 环境下的 PostgreSQL 部署

基于官方 postgres 镜像的生产级部署与备份实践 前言 PostgreSQL 作为最强大的开源关系型数据库之一,在企业级应用中扮演着重要角色。将 PostgreSQL 部署在 Kubernetes 环境中,不仅能享受容器化带来的便利,还能利用 Kubernetes 的弹性伸缩和自愈能力。 今天,我将分享一套完整的 PostgreSQL K8s 部署方案,包括 StatefulSet 部署、用户权限管理、以及自动备份策略。 为什么选择 Kubernetes 部署 PostgreSQL? 优势 说明 高可用 Kubernetes 自动重启故障 Pod,保证服务持续运行 弹性伸缩 根据负载动态调整资源配额 版本管理 通过镜像版本轻松实现数据库升级 资源隔离 独立的 Namespace 和资源配额 存储管理 HostPath 或持久卷灵活配置 整体架构一览 先来看一张部署架构图:

By 菱角