OpenCloudOS 9 小型服务器 Docker 部署实战：PostgreSQL+PostGIS、Redis、Nginx 安全加固与一键脚本

一、前言

1. Docker 的优势

对于中小型项目的服务端部署，Docker 容器化技术已经成为事实标准。与传统"直接在操作系统上安装软件"的方式相比，Docker 在以下几个维度具备显著优势。
环境一致性。 传统安装方式下，开发环境与生产环境的软件版本、配置文件路径、依赖库版本经常存在细微差异，这些差异往往是"在我电脑上能跑"这种问题的根源。Docker 通过镜像机制将运行环境整体打包，开发阶段测试通过的镜像，部署到生产环境后行为完全一致。你不需要关心目标服务器上是否安装了特定版本的 libpq 或者 glibc，因为镜像内部已经包含了所有依赖。

部署效率。 以 PostgreSQL 为例，传统安装需要配置软件源、安装主程序、初始化数据库集群、修改配置文件、创建用户和数据库，整个过程涉及十多个步骤。使用 Docker，一条 docker run 命令即可完成所有工作。当你需要在一台新服务器上重建整套环境时，Docker Compose 配置文件就是完整的部署文档，几分钟之内就能拉起所有服务。

隔离性。 容器之间通过 namespace 和 cgroup 实现进程、网络、文件系统的隔离。PostgreSQL 的端口冲突、Redis 的配置文件覆盖、Nginx 的共享库污染等问题在容器化架构下自然消失。每个服务运行在独立的容器中，升级、回滚、重启某一个服务不会影响其他服务。

版本管理。 当你需要从 PostgreSQL 15 升级到 16，或者从 Redis 6 切换到 7，传统方式下这是一个需要谨慎操作的过程——备份、卸载、安装新版本、迁移数据。在 Docker 中，只需要修改镜像标签，数据通过 volume 挂载保持不变，回滚时也只需切回旧标签。

资源控制。 Docker 允许为每个容器设置 CPU 和内存的上限。在一台资源有限的服务器上，你可以精确控制每个服务最多占用多少内存，防止单个服务（比如 PostgreSQL 执行了复杂查询）耗尽系统资源导致其他服务不可用。这在 2核4GB 这种入门级云主机上尤为重要。

当然，Docker 并非银弹。容器化会引入一定的资源开销（Docker 守护进程通常占用 100-300MB 内存），对于内存极其紧张的场景需要权衡。JDK 应用容器化后，JVM 对容器内存的感知、GC 策略的配置都比原生部署更复杂。这也是为什么在实际生产中，我们采用"混合部署"策略：数据库、缓存、反向代理等无状态或数据可外挂的服务用 Docker 管理，JDK 应用原生运行在宿主机上。

2. 本博客要点

本文基于一台 2核4GB内存 的 OpenCloudOS 9 云主机，完整记录从零开始部署 PostgreSQL 16 + PostGIS 3.5、Redis 7、Nginx 的全过程，并附带一份可直接使用的一键部署脚本。

博客覆盖以下核心内容：

• 安装选型决策：在资源受限的服务器上，为什么选择"JDK 原生 + 其余 Docker 化"的混合部署方案，而非全部原生安装或全部容器化。
• Docker 服务部署：PostgreSQL + PostGIS、Redis、Nginx 三个服务的容器化配置细节，包括内存参数调优、数据持久化、网络隔离。
• 安全加固策略：非标准端口映射、强密码自动生成、fail2ban 防暴力破解、PostgreSQL 认证延迟、Redis 危险命令禁用、Nginx 请求速率限制。
• 自动化脚本：所有配置集成到一个 bash 脚本中，root 用户直接运行即可完成全部部署。

在命令行工具中输入以下命令查看CPU信息：

cat /proc/cpuinfo

再来看一下内存配置，命令如下：

cat /proc/meminfo

二、需要安装的类型

1. Docker 本身

为什么需要 Docker

在 2核4GB 的服务器上，Docker 本身的资源开销是第一个需要评估的问题。Docker 守护进程（dockerd）加上 containerd 运行时，通常占用 100-300MB 内存。在 4GB 总量中，这个开销占比约 5%-8%，是可以接受的代价。
OpenCloudOS 9 基于 RHEL 9 内核，对 Docker 的兼容性良好。安装过程使用 dnf 包管理器，配置阿里云镜像源加速国内下载。

安装步骤

安装 Docker CE（社区版）和 Docker Compose 插件：

# 安装 dnf 插件并添加 Docker 仓库
dnf install -y dnf-plugins-core
dnf config-manager –add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
# 安装 Docker 引擎和 Compose 插件
dnf install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
# 启动并设置开机自启
systemctl start docker
systemctl enable docker
# 验证安装
docker –version
docker compose version

如果需要独立的 docker-compose 命令（部分旧版工具兼容），还可以额外安装二进制文件：

curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)–$(uname -m)" \\
-o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

开机自启机制

Docker 服务通过 systemctl enable docker 注册为系统服务。服务器重启后，systemd 自动拉起 Docker 守护进程，Docker 守护进程再检测到所有设置了 restart: always 策略的容器并逐一启动。这条链路保证了容器服务的自动恢复，无需额外配置 crontab 或其他监控手段。

2. PostgreSQL + PostGIS

镜像选择

使用官方维护的 postgis/postgis 镜像，版本选择 postgis/postgis:16-3.5。这个镜像基于 Debian，预装了 PostgreSQL 16 和 PostGIS 3.5 扩展，稳定性经过社区广泛验证。相比自行在基础 PostgreSQL 镜像上编译安装 PostGIS，官方镜像省去了编译环节的复杂度和潜在的依赖冲突。

值得注意的是，不建议使用 Alpine 基础的 PostgreSQL 镜像来运行 PostGIS。Alpine 使用 musl libc 而非 glibc，部分 PostGIS 的第三方扩展可能存在兼容性问题。Debian 基础镜像虽然体积稍大（约 400MB），但在兼容性上更有保障。

内存参数调优

2核4GB 的配置下，PostgreSQL 的内存参数需要谨慎设置。核心参数如下：

其中 work_mem 的设置需要特别说明。每个连接在执行排序、哈希连接等操作时都会分配 work_mem 大小的内存。如果设置为 16MB、200 个连接同时执行复杂查询，理论上可能占用 3.2GB，远超物理内存。设置为 4MB 后，极端情况的上限控制在 800MB，在 4GB 总量下更安全。对于确实需要大排序的个别查询，可以在会话级别临时调高。

共享内存配置

这是 Docker 中运行 PostgreSQL 最容易踩的坑。Docker 容器默认的 /dev/shm（共享内存）只有 64MB，而 PostgreSQL 的 shared_buffers 设为 1GB 后，共享内存不足会导致启动失败或严重性能下降。

解决方案是在 Docker Compose 中显式设置 shm_size：

services:
postgres:
image: postgis/postgis:16–3.5
shm_size: 2g # 必须大于 shared_buffers 的值
# …

数据持久化

PostgreSQL 的数据文件通过 volume 挂载到宿主机独立目录 /data/pgdata，而非 Docker 的默认存储位置。这样做有三个好处：

• 数据安全：即使执行 docker compose down -v（删除容器和 volume），宿主机上的数据目录不受影响。
• 备份方便：可以直接对 /data/pgdata 目录进行文件级备份或 rsync 同步。
• 重建透明：容器删除后重新创建，挂载同一目录即可恢复全部数据。

目录权限设置为 chmod 700，owner 设为 999:999（PostgreSQL 官方镜像的容器内用户 UID）。这个权限配置确保只有 PostgreSQL 进程能读写数据文件，即使是 root 用户也不能直接读取数据库文件内容。

完整的 Docker Compose 配置

postgres:
image: postgis/postgis:16–3.5
container_name: postgres
restart: always
shm_size: 2g
deploy:
resources:
limits:
memory: 2g
environment:
POSTGRES_PASSWORD: ${PG_PASSWORD}
POSTGRES_DB: ${PG_DB}
POSTGRES_USER: ${PG_USER}
PGDATA: /var/lib/postgresql/data
volumes:
– /data/pgdata:/var/lib/postgresql/data
– /data/docker/pg_hba.conf:/var/lib/postgresql/data/pg_hba.conf:ro
– /data/docker/postgresql–custom.conf:/etc/postgresql–custom.conf:ro
ports:
– "15432:5432"
command: >
postgres
-c shared_buffers=1GB
-c effective_cache_size=2GB
-c maintenance_work_mem=256MB
-c wal_buffers=16MB
-c work_mem=4MB
-c max_connections=200
-c config_file=/etc/postgresql-custom.conf
healthcheck:
test: ["CMD-SHELL", "pg_isready -U ${PG_USER} -d ${PG_DB}"]
interval: 10s
timeout: 5s
retries: 5
networks:
– backend

PostGIS 扩展初始化

PostGIS 扩展不会随容器启动自动创建到目标数据库中，需要手动执行一条 SQL：

docker exec -it postgres psql -U myuser -d myapp -p 15432 \\
-c 'CREATE EXTENSION IF NOT EXISTS postgis;'

这条命令可以写入部署脚本中自动执行，也可以在应用首次启动时由 ORM 框架自动创建。

3. Redis

镜像选择

使用 redis:7-alpine 镜像。Redis 是典型的内存型服务，Alpine 基础镜像的极小体积（约 40MB）和低内存开销非常适合。Redis 不存在 glibc 兼容性问题，Alpine 在这里是最佳选择。

内存控制

Redis 在 2核4GB 服务器上应严格控制内存使用。通过两个层面实现：

容器层面，Docker Compose 设置内存硬上限为 256MB：

deploy:
resources:
limits:
memory: 256m

Redis 层面，通过 maxmemory 参数设置实际使用的上限为 192MB（留出约 25% 的缓冲空间给容器自身开销）：

redis-server –maxmemory 192mb –maxmemory-policy allkeys-lru

allkeys-lru 淘汰策略在内存达到上限时，优先淘汰最近最少使用的 key，适合缓存场景。如果你的 Redis 同时存储了持久化数据和缓存数据，应根据业务逻辑选择 volatile-lru（只淘汰设置了过期时间的 key）或其他策略。

持久化策略

开启 AOF（Append Only File）持久化：

redis-server –appendonly yes

AOF 记录每一次写操作，Redis 重启时通过回放这些操作恢复数据。相比 RDB 快照方式，AOF 在数据安全性上更有保障，最多只丢失 1 秒的数据。数据文件通过 volume 挂载到 /data/docker/redis 目录。

完整配置

redis:
image: redis:7–alpine
container_name: redis
restart: always
deploy:
resources:
limits:
memory: 256m
command: >
redis-server /usr/local/etc/redis/redis-custom.conf
volumes:
– /data/docker/redis:/data
– /data/docker/redis/redis–custom.conf:/usr/local/etc/redis/redis–custom.conf:ro
ports:
– "16379:6379"
healthcheck:
test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD}", "ping"]
interval: 10s
timeout: 3s
retries: 5
networks:
– backend

Redis 的配置通过外部文件 redis-custom.conf 挂载，而非直接写在 command 参数中。这样做的优势是：修改 Redis 配置后只需重启容器，不需要修改 Docker Compose 文件本身。

4. Nginx

镜像选择

使用 nginx:alpine 镜像，内存占用极低（约 20-50MB），在 4GB 服务器上几乎可以忽略不计。

核心功能

在这套架构中，Nginx 承担两个角色：

反向代理。将外部请求转发到宿主机上原生运行的 Java 应用。例如，通过 8086 端口反向代理到 JDK 应用的 8080 端口：

server {
listen 8086;
server_name localhost;

location / {
proxy_pass http://host.docker.internal:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}

host.docker.internal 是 Docker 提供的特殊 DNS 名称，指向宿主机的网关地址。通过它，Nginx 容器可以访问宿主机上运行的 JDK 应用。

静态资源服务。直接托管前端静态文件、API 文档等。Nginx 处理静态文件的性能远高于 Java 应用服务器，将其卸载到 Nginx 可以显著降低 JDK 应用的负载。

配置文件管理

Nginx 的配置文件通过 volume 以只读方式挂载：

volumes:
– /data/docker/nginx/conf.d:/etc/nginx/conf.d:ro
– /data/docker/nginx/html:/usr/share/nginx/html:ro

在 conf.d 目录下，每个 .conf 文件定义一个 server 块。Nginx 会自动加载该目录下的所有配置文件，这意味着你可以随时添加新的站点或反向代理配置，而不需要修改 Docker Compose 文件。唯一需要注意的是，新增监听端口时，需要在 Docker Compose 的 ports 段中声明端口映射，否则容器的网络层不会放行该端口。

安全加固配置

server {
listen 80;
server_name localhost;

# 隐藏 Nginx 版本号，防止攻击者利用已知版本漏洞
server_tokens off;

# 每个 IP 限制 30 请求/秒，防 CC 攻击
limit_req_zone $binary_remote_addr zone=ddos:10m rate=30r/s;

location / {
limit_req zone=ddos burst=50 nodelay;
root /usr/share/nginx/html;
index index.html index.htm;
}

client_max_body_size 10m;
}

三、安全策略

1. 关闭默认端口

为什么需要修改默认端口

互联网上存在大量的自动化扫描工具，它们 7×24 小时不间断地扫描公网 IP 的常用端口。以下数据来自公开的蜜罐统计：

如果你的服务使用默认端口并暴露在公网上，即使密码足够强，大量的暴力破解尝试也会消耗服务器资源、产生海量日志，甚至在某些极端情况下（比如密码恰好出现在了某个泄露的字典中）被攻破。

将对外映射的端口改为非标准值，能自动屏蔽 99% 的自动化扫描。扫描工具通常只探测已知的默认端口列表，改为 15432 和 16379 后，扫描器根本不会尝试连接这些端口。

端口映射策略

在 Docker Compose 中，端口映射的格式为 宿主机端口:容器内端口。容器内端口保持默认值（PostgreSQL 5432、Redis 6379），只修改宿主机侧的映射端口：

Nginx 的 80/443 端口保留默认值，是因为它们是 HTTP/HTTPS 的标准端口。如果改为非标准端口，用户每次访问都需要在 URL 中手动输入端口号（如 http://example.com:8080），严重影响使用体验。

修改后的 Docker Compose 端口配置：

# PostgreSQL
ports:
– "15432:5432" # 外部用 15432 连接，容器内仍是 5432

# Redis
ports:
– "16379:6379" # 外部用 16379 连接，容器内仍是 6379

# Nginx
ports:
– "80:80" # 保持标准端口
– "443:443"

容器之间通过 Docker 内部的 backend 桥接网络通信时，仍然使用默认端口（5432、6379），互不影响。宿主机上的 JDK 应用连接数据库时，使用映射后的端口（15432、16379）通过 localhost 访问。

连接命令示例

修改端口后，连接命令也需要相应调整：

# 连接 PostgreSQL
docker exec -it postgres psql -U myuser -d myapp -p 15432

# 连接 Redis
redis-cli -h localhost -p 16379 -a YourPassword

更彻底的安全方案：不暴露端口

如果 Redis 仅用于本机 JDK 应用的缓存，根本不需要对外暴露端口。在 Docker Compose 中删除 ports 配置，Redis 只能被同 backend 网络下的容器和宿主机访问，公网完全不可达。这比改端口更安全，因为不存在任何外部入口。

同样，如果 PostgreSQL 只供本机应用使用，安全组中可以关闭 15432 的公网入站规则，只允许内网 IP 或本机访问。

2. 安装 fail2ban

fail2ban 是什么

fail2ban 是一个入侵防御工具，它监控系统日志文件，当检测到某个 IP 在指定时间窗口内的失败登录次数超过阈值时，自动通过防火墙规则（iptables/nftables）将该 IP 封禁一段时间。

简单来说，fail2ban 的工作流程是：

攻击者尝试连接 → 连接失败被记录到日志 → fail2ban 分析日志
→ 发现同一 IP 失败次数超过阈值 → 调用防火墙封禁该 IP → 封禁到期后自动解封

是否必须安装

客观评价，fail2ban 不是必须安装的，但它是低成本高收益的安全加固手段。

不装 fail2ban 也安全的条件：

如果你已经做好了以下全部措施，安全级别已经足够：

• 使用 16 位以上的随机强密码（大小写字母 + 数字 + 特殊字符混合）
• 对外端口已改为非标准值（15432/16379）
• 云主机安全组只允许特定 IP 访问数据库端口
• 数据库不对外开放，仅供本机或内网访问

安装 fail2ban 的增量价值：

对于数据库需要对外开放的场景（比如远程开发、多服务器协作），安装 fail2ban 是值得的。10-30MB 的内存代价换来暴力破解的主动防御，性价比很高。如果数据库只供本机使用且安全组已关闭对应端口的公网访问，fail2ban 的作用就不大了。

安装与配置

# 安装
dnf install -y fail2ban
systemctl enable fail2ban
systemctl start fail2ban

配置文件 /etc/fail2ban/jail.local，针对不同服务设置不同的防护策略：

[DEFAULT]
bantime = 3600
findtime = 300
maxretry = 5
ignoreip = 127.0.0.1/8

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
maxretry = 3
bantime = 86400

[postgres-docker]
enabled = true
port = 15432
logpath = /var/log/fail2ban-postgres.log
maxretry = 5
findtime = 300
bantime = 3600

[redis-docker]
enabled = true
port = 16379
logpath = /var/log/fail2ban-redis.log
maxretry = 5
findtime = 300
bantime = 3600

各项参数的含义：

• bantime：封禁时长（秒），3600 秒 = 1 小时
• findtime：检测时间窗口（秒），300 秒 = 5 分钟
• maxretry：时间窗口内允许的最大失败次数
• ignoreip：白名单 IP，永远不被封禁

SSH 服务的防护更严格：3 次失败即封禁 24 小时。因为 SSH 是攻击者最常扫描和爆破的服务，必须设置更低的阈值。

验证 fail2ban 运行状态

# 查看所有 jail 的状态
fail2ban-client status

# 查看 SSH jail 的详细信息
fail2ban-client status sshd

# 手动解封某个 IP
fail2ban-client set sshd unbanip 1.2.3.4

与 PostgreSQL 配合使用

fail2ban 要检测 PostgreSQL 的暴力破解，需要 PostgreSQL 将失败的连接尝试记录到日志中。在 PostgreSQL 的配置中开启以下参数：

log_connections = on
log_disconnections = on
log_line_prefix = '%t [%p]: [%d] %u '

日志格式中包含用户名和时间戳，fail2ban 的 filter 规则可以从日志中提取失败连接的 IP 地址。

与 Redis 配合使用

Redis 本身的认证失败不会产生详细的日志输出，fail2ban 对 Redis 的防护更多依赖端口层面的连接失败检测。当攻击者使用错误的密码或无密码尝试连接 Redis 时，连接层面的异常行为会被 fail2ban 的端口监控捕获。

3. 其他安全加固措施

PostgreSQL 认证延迟

PostgreSQL 16 支持 auth_delay 扩展，每次认证失败后强制延迟指定毫秒数：

auth_delay.milliseconds = 3000

这个设置的效果是：每次密码输入错误后，服务器故意等待 3 秒才返回错误信息。对于暴力破解工具来说，这意味着原本每秒可以尝试 100 次的速率被降低到每 3 秒 1 次，破解成本提高了数百倍。

Redis 危险命令禁用

Redis 提供了一些极其危险的命令（如 FLUSHALL、CONFIG），一旦被攻击者利用，可以瞬间清空所有数据或读取服务器配置。通过 rename-command 将这些命令禁用或重命名：

# 完全禁用
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
rename-command SHUTDOWN ""

# 重命名（只有知道新名字的人才能使用）
rename-command KEYS "ADMIN_KEYS"
rename-command EVAL "ADMIN_EVAL"

禁用后，即使攻击者获得了 Redis 的访问权限，也无法执行这些高危操作。

密码策略

强密码是安全的基石。在部署脚本中，密码留空时会自动生成 32 位随机强密码：

openssl rand -base64 32 | tr -dc 'A-Za-z0-9!@#$%^&*()_+-=' | head -c 32

生成的密码包含大小写字母、数字和特殊字符的组合。脚本还会进行密码强度检查，如果手动指定的密码长度不足 16 位或未包含大小写字母和数字的组合，会发出警告。

密码通过 .env 文件传递给 Docker Compose，文件权限设为 chmod 600，仅 root 用户可读。

四、总结

架构回顾

本文在 2核4GB 的 OpenCloudOS 9 云主机上，采用 “JDK 原生 + 数据库/缓存/反向代理 Docker 化” 的混合部署架构，部署了以下服务栈：

各服务的总内存占用控制在 2.4-2.9GB，在 4GB 总量下留有 1.1-1.6GB 的余量，可以应对业务峰值。

安全防线总结

安全不是单一手段能解决的，而是多层防御的叠加效果：

每一层单独来看都可能被绕过，但八层叠加后，攻击者需要同时突破所有防线才能造成实际损害，成本极高。

运维常用命令

# 查看所有容器状态
cd /data/docker && docker compose ps

# 查看日志
cd /data/docker && docker compose logs -f

# 只看某个服务的日志
cd /data/docker && docker compose logs -f postgres

# 重启某个服务（修改配置后）
cd /data/docker && docker compose up -d postgres

# 进入 PostgreSQL
docker exec -it postgres psql -U myuser -d myapp -p 15432

# 创建 PostGIS 扩展
docker exec -it postgres psql -U myuser -d myapp -p 15432 \\
-c 'CREATE EXTENSION IF NOT EXISTS postgis;'

# 查看 fail2ban 封禁状态
fail2ban-client status

# 查看服务器资源占用
docker stats

JDK 应用连接配置

宿主机上原生运行的 Java 应用，通过 localhost 和映射后的端口连接 Docker 中的服务：

# PostgreSQL
spring.datasource.url=jdbc:postgresql://localhost:15432/myapp
spring.datasource.username=myuser
spring.datasource.password=生成的强密码

# Redis
spring.redis.host=localhost
spring.redis.port=16379
spring.redis.password=生成的强密码

通过 systemd 管理 Java 应用服务时，设置 After=docker.service 确保 Docker 服务先启动，避免应用启动时数据库尚未就绪。

扩展新端口的操作流程

当需要通过 Nginx 暴露新的业务端口时（如 8086），操作流程如下：

整个过程不需要停止其他服务，PostgreSQL 和 Redis 保持正常运行不受影响。

一键部署脚本

本文涉及的所有配置（Docker 安装、服务部署、安全加固、fail2ban 配置）已集成到一个 bash 脚本中。脚本特点：

• 自动检测并安装 Docker（如未安装）
• 密码留空时自动生成 32 位随机强密码
• 内置密码强度检查
• 自动安装配置 fail2ban
• PostgreSQL/Redis/Nginx 全量安全加固
• 自动创建数据目录并设置正确权限
• 生成 .env 文件并限制为 chmod 600
• 部署完成后输出连接信息和常用命令

以 root 用户直接运行即可完成全部部署，适合在生产环境中快速搭建标准化的服务栈。