用 Docker 搭一套公司内部知识库，配置文件直接拿去用

发布人：慈云数据-客服中心发布时间：21小时前阅读量：3

Docker 企业知识库搭建｜附配置文件

在企业内部，知识库往往承担着非常重要的角色：制度文档、项目资料、研发规范、运维手册、故障复盘、接口说明、培训材料、常见问题等内容，都需要一个统一、可检索、可权限控制的平台来沉淀。如果没有知识库，团队成员会频繁在聊天记录、个人文档、网盘目录中寻找资料，不仅效率低，而且容易出现知识断层。

本文将介绍如何使用 Docker 快速搭建一套企业级知识库系统。方案采用 Wiki.js + PostgreSQL + Nginx，具备部署简单、维护方便、权限灵活、支持 Markdown、支持搜索、支持多用户协作等特点。文章中会附带完整的 docker-compose.yml、Nginx 配置、环境变量配置、备份脚本以及常见运维建议，适合中小型企业、研发团队、运维团队、项目组作为内部知识库使用。

一、为什么选择 Docker 搭建企业知识库？

传统方式部署知识库系统，通常需要手动安装运行环境、数据库、反向代理、依赖库等组件。不同服务器环境差异较大，后续迁移也比较麻烦。而使用 Docker 之后，可以把应用及依赖封装在容器中，通过配置文件统一管理，具备以下优势：

1. 部署简单

只需要提前安装 Docker 和 Docker Compose，然后准备好配置文件，执行一条命令即可启动整套知识库服务。

docker compose up -d

2. 环境一致

无论是在测试服务器、生产服务器，还是迁移到新的云主机，只要 Docker 版本兼容，部署结果基本一致，减少“在我电脑上没问题”的环境差异。

3. 便于维护和升级

知识库应用、数据库、反向代理都可以通过容器管理。升级版本时，只需修改镜像版本号并重新拉取镜像即可。

4. 数据持久化清晰

通过 Docker Volume 或宿主机目录挂载，可以明确区分应用容器和数据文件，方便备份、恢复、迁移。

5. 适合企业内部标准化

企业可以将知识库部署流程固化成配置文件，后续分公司、项目组、测试环境都可以复用同一套部署方案。

二、方案选型说明

本文使用的技术组合如下：

组件	说明
Wiki.js	开源知识库系统，支持 Markdown、权限管理、搜索、页面版本等
PostgreSQL	Wiki.js 官方推荐数据库之一，稳定可靠
Nginx	反向代理，支持域名访问、HTTPS、静态代理
Docker Compose	统一编排多个容器
Ubuntu / CentOS / Debian	推荐的 Linux 服务器系统

为什么选择 Wiki.js？

Wiki.js 是一款现代化的开源知识库系统，相比传统 Wiki 系统，它的界面更加友好，配置更加灵活。它支持：

Markdown 编辑；
页面树结构管理；
用户与角色权限控制；
本地账号、LDAP、OAuth、SAML 等认证方式；
页面历史版本；
多语言；
搜索功能；
Git 存储同步；
主题配置；
API 扩展。

对于企业内部知识库而言，Wiki.js 既轻量，又足够强大。

三、服务器准备

本文假设服务器环境如下：

操作系统：Ubuntu 22.04 LTS
服务器 IP：192.168.10.20
知识库域名：wiki.example.com
部署目录：/opt/wiki

如果你使用的是 CentOS、Debian 或其他 Linux 发行版，整体思路基本一致，只是安装 Docker 的命令略有区别。

1. 创建部署目录

sudo mkdir -p /opt/wiki
sudo mkdir -p /opt/wiki/data/postgres
sudo mkdir -p /opt/wiki/nginx/conf.d
sudo mkdir -p /opt/wiki/nginx/certs
sudo mkdir -p /opt/wiki/backup
cd /opt/wiki

建议将所有与知识库相关的配置、数据、备份统一放在 /opt/wiki 目录下，后续维护更清晰。

四、安装 Docker 和 Docker Compose

如果服务器已经安装 Docker，可以跳过本节。

1. 安装基础依赖

sudo apt update
sudo apt install -y ca-certificates curl gnupg lsb-release

2. 安装 Docker

curl -fsSL https://get.docker.com | sudo bash

3. 设置开机自启

sudo systemctl enable docker
sudo systemctl start docker

4. 查看 Docker 版本

docker version
docker compose version

如果能够正常输出版本信息，说明 Docker 环境已安装完成。

五、目录结构规划

最终目录结构建议如下：

/opt/wiki
├── docker-compose.yml
├── .env
├── nginx
│   ├── conf.d
│   │   └── wiki.conf
│   └── certs
│       ├── wiki.example.com.pem
│       └── wiki.example.com.key
├── data
│   └── postgres
└── backup
    ├── backup-wiki.sh
    └── restore-wiki.sh

说明：

docker-compose.yml：核心服务编排文件；
.env：环境变量配置文件，存放数据库账号、密码、域名等；
nginx/conf.d/wiki.conf：Nginx 反向代理配置；
nginx/certs：HTTPS 证书目录；
data/postgres：数据库持久化目录；
backup：备份与恢复脚本目录。

六、编写环境变量配置文件

在 /opt/wiki 目录下创建 .env 文件：

cd /opt/wiki
vim .env

写入以下内容：

# 项目名称
COMPOSE_PROJECT_NAME=enterprise-wiki

# Wiki.js 访问配置
WIKI_DOMAIN=wiki.example.com
WIKI_PORT=3000

# PostgreSQL 数据库配置
POSTGRES_DB=wikijs
POSTGRES_USER=wikijs
POSTGRES_PASSWORD=ChangeThisStrongPassword_2025

# PostgreSQL 容器内部端口
POSTGRES_PORT=5432

# 时区
TZ=Asia/Shanghai

请务必修改 POSTGRES_PASSWORD，不要在生产环境使用示例密码。建议使用长度不少于 16 位，包含大小写字母、数字和特殊字符的强密码。

七、编写 Docker Compose 配置文件

在 /opt/wiki/docker-compose.yml 中写入以下配置：

version: "3.9"

services:
  postgres:
    image: postgres:15-alpine
    container_name: wikijs-postgres
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      TZ: ${TZ}
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    networks:
      - wiki-net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5

  wikijs:
    image: ghcr.io/requarks/wiki:2
    container_name: wikijs-app
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      DB_TYPE: postgres
      DB_HOST: postgres
      DB_PORT: ${POSTGRES_PORT}
      DB_USER: ${POSTGRES_USER}
      DB_PASS: ${POSTGRES_PASSWORD}
      DB_NAME: ${POSTGRES_DB}
      TZ: ${TZ}
    ports:
      - "127.0.0.1:${WIKI_PORT}:3000"
    networks:
      - wiki-net

  nginx:
    image: nginx:1.25-alpine
    container_name: wikijs-nginx
    restart: unless-stopped
    depends_on:
      - wikijs
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./nginx/certs:/etc/nginx/certs:ro
    networks:
      - wiki-net

networks:
  wiki-net:
    driver: bridge

配置说明

这里将 Wiki.js 的服务端口绑定到宿主机本地地址：

ports:
  - "127.0.0.1:${WIKI_PORT}:3000"

这样外部无法直接通过 服务器IP:3000 访问 Wiki.js，只能通过 Nginx 反向代理访问，安全性更好。

PostgreSQL 没有对宿主机暴露端口，只允许 Docker 网络内部访问，减少数据库被扫描和攻击的风险。

八、配置 Nginx 反向代理

在 /opt/wiki/nginx/conf.d/wiki.conf 中写入以下配置。

如果暂时没有 HTTPS 证书，可以先使用 HTTP 配置；如果已有证书，则直接使用 HTTPS 配置。

方案一：HTTP 配置

server {
    listen 80;
    server_name wiki.example.com;

    client_max_body_size 100m;

    location / {
        proxy_pass http://wikijs:3000;
        proxy_http_version 1.1;

        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;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

这种方式部署简单，但不建议生产环境长期使用。企业内部如果有统一证书，也应尽量启用 HTTPS。

方案二：HTTPS 配置

如果你的证书文件位于：

/opt/wiki/nginx/certs/wiki.example.com.pem
/opt/wiki/nginx/certs/wiki.example.com.key

则可以使用以下配置：

server {
    listen 80;
    server_name wiki.example.com;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name wiki.example.com;

    client_max_body_size 100m;

    ssl_certificate /etc/nginx/certs/wiki.example.com.pem;
    ssl_certificate_key /etc/nginx/certs/wiki.example.com.key;

    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    add_header X-Frame-Options SAMEORIGIN always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-XSS-Protection "1; mode=block" always;

    location / {
        proxy_pass http://wikijs:3000;
        proxy_http_version 1.1;

        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 https;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

如果使用的是 Let’s Encrypt，可以把证书同步到该目录，也可以将宿主机上的 /etc/letsencrypt 挂载到 Nginx 容器中。企业内网环境则可以使用公司统一 CA 签发的证书。

九、启动知识库服务

进入部署目录：

cd /opt/wiki

拉取镜像：

docker compose pull

启动服务：

docker compose up -d

查看容器状态：

docker compose ps

正常情况下可以看到三个容器：

wikijs-postgres
wikijs-app
wikijs-nginx

查看日志：

docker compose logs -f wikijs

如果没有明显报错，就可以访问：

https://wiki.example.com

首次访问时，Wiki.js 会进入初始化页面，需要创建管理员账号、设置站点名称、语言等基本信息。

十、初始化 Wiki.js

首次打开知识库地址后，按照页面提示完成初始化。

建议设置如下：

配置项	建议
Site Title	企业知识库 / 公司知识中心
Admin Email	使用企业管理员邮箱
Admin Password	设置强密码
Language	简体中文
Public Access	内部知识库建议关闭匿名访问
Editor	推荐 Markdown

初始化完成后，可以进入管理后台继续配置。

十一、企业知识库栏目规划建议

知识库工具只是基础，真正决定知识库价值的是内容结构。建议从一开始就规划清晰的栏目。

例如：

企业知识库
├── 公司制度
│   ├── 人事制度
│   ├── 财务制度
│   └── 行政制度
├── 研发中心
│   ├── 开发规范
│   ├── Git 使用规范
│   ├── 接口文档
│   ├── 数据库规范
│   └── 发布流程
├── 运维中心
│   ├── 服务器管理
│   ├── Docker 运维
│   ├── Kubernetes 运维
│   ├── 监控告警
│   └── 故障复盘
├── 产品中心
│   ├── 产品需求
│   ├── 原型说明
│   └── 版本规划
├── 项目资料
│   ├── 项目 A
│   ├── 项目 B
│   └── 项目 C
└── 常见问题
    ├── 新人入职
    ├── 账号权限
    └── 办公软件

建议每个栏目设置对应负责人，避免知识库变成“无人维护的文档仓库”。

十二、权限管理建议

企业知识库通常不能完全公开，需要根据部门、角色进行权限隔离。Wiki.js 支持用户组和权限策略，可以按实际情况配置。

常见权限模型如下：

用户组	权限
管理员	全站管理、用户管理、权限配置
编辑组	创建、编辑、移动、删除页面
普通员工	查看内部公开页面
研发组	查看和编辑研发相关文档
运维组	查看和编辑运维相关文档
外部协作方	仅访问指定项目文档

建议遵循最小权限原则：用户只拥有完成工作所需的权限，不要默认给所有人编辑权限。

如果企业已有 LDAP、AD、OAuth、CAS 或统一身份认证平台，建议将 Wiki.js 接入统一认证，减少账号管理成本。

十三、数据库备份配置

企业知识库中的数据非常重要，必须做好备份。下面提供一个 PostgreSQL 备份脚本。

创建文件：

vim /opt/wiki/backup/backup-wiki.sh

写入：

#!/bin/bash

set -e

BACKUP_DIR="/opt/wiki/backup"
DATE=$(date +"%Y%m%d_%H%M%S")
CONTAINER_NAME="wikijs-postgres"
DB_NAME="wikijs"
DB_USER="wikijs"

mkdir -p ${BACKUP_DIR}

echo "开始备份 Wiki.js 数据库..."

docker exec ${CONTAINER_NAME} pg_dump -U ${DB_USER} ${DB_NAME} > ${BACKUP_DIR}/wikijs_${DATE}.sql

gzip ${BACKUP_DIR}/wikijs_${DATE}.sql

echo "备份完成：${BACKUP_DIR}/wikijs_${DATE}.sql.gz"

echo "清理 30 天前的备份文件..."
find ${BACKUP_DIR} -name "wikijs_*.sql.gz" -mtime +30 -delete

echo "备份任务结束。"

赋予执行权限：

chmod +x /opt/wiki/backup/backup-wiki.sh

手动执行测试：

/opt/wiki/backup/backup-wiki.sh

如果在 /opt/wiki/backup 目录下生成了 .sql.gz 文件，说明备份成功。

十四、配置定时备份

使用 crontab 配置每天凌晨 2 点自动备份：

crontab -e

加入：

0 2 * * * /opt/wiki/backup/backup-wiki.sh >> /opt/wiki/backup/backup.log 2>&1

建议将备份文件同步到远程对象存储或其他服务器，例如：

阿里云 OSS；
腾讯云 COS；
AWS S3；
MinIO；
NAS；
异地备份服务器。

只把备份放在同一台服务器上并不安全。一旦服务器磁盘损坏或误删，备份也可能丢失。

十五、数据库恢复脚本

创建恢复脚本：

vim /opt/wiki/backup/restore-wiki.sh

写入：

#!/bin/bash

set -e

if [ -z "$1" ]; then
  echo "用法：$0 /opt/wiki/backup/wikijs_xxxxx.sql.gz"
  exit 1
fi

BACKUP_FILE=$1
CONTAINER_NAME="wikijs-postgres"
DB_NAME="wikijs"
DB_USER="wikijs"

if [ ! -f "${BACKUP_FILE}" ]; then
  echo "备份文件不存在：${BACKUP_FILE}"
  exit 1
fi

echo "即将恢复数据库：${BACKUP_FILE}"
echo "请确认已经停止 Wiki.js 应用容器，避免写入冲突。"
read -p "继续恢复？输入 yes 确认：" CONFIRM

if [ "${CONFIRM}" != "yes" ]; then
  echo "已取消。"
  exit 0
fi

echo "停止 Wiki.js 应用..."
docker stop wikijs-app

echo "解压并恢复数据库..."
gunzip -c ${BACKUP_FILE} | docker exec -i ${CONTAINER_NAME} psql -U ${DB_USER} -d ${DB_NAME}

echo "启动 Wiki.js 应用..."
docker start wikijs-app

echo "恢复完成。"

赋予执行权限：

chmod +x /opt/wiki/backup/restore-wiki.sh

恢复示例：

/opt/wiki/backup/restore-wiki.sh /opt/wiki/backup/wikijs_20250101_020000.sql.gz

注意：恢复数据库前请确认备份文件来源可靠，并尽量先在测试环境验证。

十六、升级 Wiki.js

升级前先备份数据库：

/opt/wiki/backup/backup-wiki.sh

然后拉取新镜像并重启：

cd /opt/wiki
docker compose pull
docker compose up -d

查看日志确认是否正常：

docker compose logs -f wikijs

如果希望固定版本，避免每次拉取最新镜像造成不可控变更，可以将：

image: ghcr.io/requarks/wiki:2

改成具体版本，例如：

image: ghcr.io/requarks/wiki:2.5

生产环境建议固定版本，并在测试环境验证后再升级。

十七、安全加固建议

为了让企业知识库更适合生产使用，建议进行以下安全加固。

1. 使用 HTTPS

即使是企业内网，也建议启用 HTTPS，避免账号密码和敏感文档明文传输。

2. 关闭匿名访问

如果知识库中包含内部资料、项目设计、服务器信息、接口文档等内容，应关闭公开访问。

3. 配置强密码策略

管理员账号必须使用强密码，并定期更换。可以接入企业统一认证系统，避免账号散落。

4. 限制服务器访问

如果知识库仅供公司内网使用，可以通过防火墙或安全组限制访问来源，例如只允许办公网段访问 80 和 443 端口。

5. 数据库不暴露端口

本文配置中 PostgreSQL 没有映射到宿主机端口，这是比较安全的做法。除非有明确需求，否则不要暴露数据库端口。

6. 定期备份和恢复演练

备份不是目的，能够恢复才是目的。建议每季度至少进行一次恢复演练，确保备份文件可用。

7. 控制文档中的敏感信息

知识库不应直接保存明文密码、云平台密钥、数据库连接密码等敏感信息。如果确实需要记录，应使用专门的密码管理工具。

十八、常见问题排查

1. 页面无法访问

先查看容器是否正常：

docker compose ps

再查看 Nginx 日志：

docker logs wikijs-nginx

以及 Wiki.js 日志：

docker logs wikijs-app

确认域名是否解析到服务器 IP：

ping wiki.example.com

2. 数据库连接失败

检查 PostgreSQL 容器状态：

docker logs wikijs-postgres

确认 .env 中的数据库账号、密码、数据库名与 docker-compose.yml 中引用一致。

如果修改过数据库密码，但数据目录已经初始化，PostgreSQL 不会自动更新旧数据库的密码，需要手动修改数据库用户密码或重新初始化数据目录。

3. 上传附件失败

检查 Nginx 配置中的上传限制：

client_max_body_size 100m;

如果企业需要上传较大的文件，可以调整为：

client_max_body_size 500m;

修改后重启服务：

docker compose restart nginx

4. HTTPS 证书不生效

检查证书文件是否存在：

ls -l /opt/wiki/nginx/certs

检查 Nginx 配置中的证书路径是否与容器内路径一致：

ssl_certificate /etc/nginx/certs/wiki.example.com.pem;
ssl_certificate_key /etc/nginx/certs/wiki.example.com.key;

查看 Nginx 配置是否加载成功：

docker exec -it wikijs-nginx nginx -t

十九、完整配置文件汇总

1. `.env`

COMPOSE_PROJECT_NAME=enterprise-wiki

WIKI_DOMAIN=wiki.example.com
WIKI_PORT=3000

POSTGRES_DB=wikijs
POSTGRES_USER=wikijs
POSTGRES_PASSWORD=ChangeThisStrongPassword_2025
POSTGRES_PORT=5432

TZ=Asia/Shanghai

2. `docker-compose.yml`

version: "3.9"

services:
  postgres:
    image: postgres:15-alpine
    container_name: wikijs-postgres
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      TZ: ${TZ}
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    networks:
      - wiki-net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5

  wikijs:
    image: ghcr.io/requarks/wiki:2
    container_name: wikijs-app
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      DB_TYPE: postgres
      DB_HOST: postgres
      DB_PORT: ${POSTGRES_PORT}
      DB_USER: ${POSTGRES_USER}
      DB_PASS: ${POSTGRES_PASSWORD}
      DB_NAME: ${POSTGRES_DB}
      TZ: ${TZ}
    ports:
      - "127.0.0.1:${WIKI_PORT}:3000"
    networks:
      - wiki-net

  nginx:
    image: nginx:1.25-alpine
    container_name: wikijs-nginx
    restart: unless-stopped
    depends_on:
      - wikijs
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./nginx/certs:/etc/nginx/certs:ro
    networks:
      - wiki-net

networks:
  wiki-net:
    driver: bridge

3. `nginx/conf.d/wiki.conf`

server {
    listen 80;
    server_name wiki.example.com;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name wiki.example.com;

    client_max_body_size 100m;

    ssl_certificate /etc/nginx/certs/wiki.example.com.pem;
    ssl_certificate_key /etc/nginx/certs/wiki.example.com.key;

    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    add_header X-Frame-Options SAMEORIGIN always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-XSS-Protection "1; mode=block" always;

    location / {
        proxy_pass http://wikijs:3000;
        proxy_http_version 1.1;

        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 https;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}