当前位置：首页 > news >正文

StructBERT模型Docker化部署进阶：使用Docker Compose编排WebUI与数据库

news 2026/3/27 9:28:47

StructBERT模型Docker化部署进阶：使用Docker Compose编排WebUI与数据库

你是不是已经成功把StructBERT模型塞进了Docker容器，能跑起来做个简单的相似度计算了？但回头看看，是不是总觉得少了点什么——Web界面交互不方便，计算结果没地方存，每次重启数据就没了，这离一个能用的应用还差得远。

别急，今天咱们就来解决这个问题。单打独斗的容器虽然灵活，但真要用起来，还得靠“团队协作”。这篇文章，我就带你用Docker Compose这个编排工具，把StructBERT的推理服务、一个好看的WebUI、还有负责存数据的数据库（比如用Redis缓存热点，用MySQL存历史记录）给拧成一股绳，打包成一个完整、可一键启动的应用。

这么做的最大好处就是，无论是你自己在电脑上开发调试，还是给测试同学一个稳定环境，甚至是最后往服务器上部署，用的都是同一套配置，彻底告别“在我机器上好好的”这种魔咒。咱们就从零开始，一步步把docker-compose.yml这个“乐高说明书”给写出来。

1. 项目准备与环境梳理

在动手写配置之前，咱们先得把“乐高积木”都找齐，想清楚它们怎么拼。一个完整的StructBERT应用，通常需要这几个核心部件：

模型服务（Model Service）：这是核心，就是咱们之前Docker化的那个StructBERT模型，它提供一个API，比如/predict，接收文本对，返回相似度分数。
Web前端（Web UI）：总不能用curl命令来调接口吧？我们需要一个网页，让用户能方便地输入文本、查看结果。这个前端会通过HTTP请求调用后面的模型服务。
缓存服务（Cache）：比如Redis。想象一下，很多用户反复查询一些热门短语的相似度，每次都让模型算一遍太浪费。可以把结果临时存到Redis里，下次同样请求直接返回，速度飞快。
数据库服务（Database）：比如MySQL。我们需要把用户查询的历史记录、结果持久化保存下来，方便以后查看、分析或审计。

它们之间的关系，简单画个图就是这样：用户 -> Web UI -> (可选：Redis缓存) -> 模型服务 -> MySQL数据库。WebUI和模型服务是主动干活的应用，Redis和MySQL是被动提供支持的服务。

接下来，给我们的项目安个家。在你的工作目录下，新建一个文件夹，比如叫structbert-compose-demo，然后进去。

mkdir structbert-compose-demo && cd structbert-compose-demo

在这个文件夹里，我们最终会有一个docker-compose.yml文件，以及各个服务相关的配置文件、代码目录。现在，确保你的系统已经安装了Docker和Docker Compose。检查命令如下：

docker --version docker-compose --version

如果都能正确显示版本号，那咱们的基础环境就妥了。

2. 编写核心：docker-compose.yml配置文件

docker-compose.yml是今天的主角，它用YAML语法定义了所有服务、网络和卷。咱们一个一个服务来构建。

2.1 定义模型推理服务

首先，是最关键的模型服务。假设我们已经有一个构建好的StructBERT Docker镜像，名字叫my-structbert:latest。这个服务需要暴露一个端口给WebUI调用。

version: '3.8' services: model-service: image: my-structbert:latest # 替换成你的实际镜像名 container_name: structbert_model restart: unless-stopped ports: - "8000:8000" # 假设模型服务内部运行在8000端口 volumes: - ./model_cache:/app/model_cache # 挂载卷，避免每次下载模型 environment: - MODEL_NAME=structbert - CACHE_ENABLED=true - CACHE_HOST=redis networks: - app-network healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8000/health"] interval: 30s timeout: 10s retries: 3

这里有几个关键点：

image: 指定使用的镜像。如果你还没构建，可以指向一个基础镜像并在build上下文构建，但今天我们聚焦编排。
ports: 将容器内的8000端口映射到宿主机的8000端口。
volumes: 把本地的./model_cache目录挂载到容器的/app/model_cache，这样模型文件就保存在本地了，重启容器也不会丢。
environment: 设置环境变量。这里告诉模型服务，缓存功能已开启，并且缓存的主机名是redis（Compose会自动将其解析为Redis服务的IP）。
networks: 让这个服务加入一个自定义的网络app-network，这样服务间可以通过服务名直接通信。
healthcheck: 健康检查配置，让Compose知道这个服务什么时候才算真正“就绪”。

2.2 添加Redis缓存服务

接下来是Redis，我们直接用官方镜像，配置很简单。

redis: image: redis:7-alpine container_name: structbert_redis restart: unless-stopped ports: - "6379:6379" volumes: - redis_data:/data command: redis-server --appendonly yes networks: - app-network

image: 使用轻量级的redis:7-alpine镜像。
volumes: 这里使用了命名卷redis_data，Docker会管理这个卷的存储位置，比绑定挂载（./xxx）更适用于数据库数据，生命周期独立于容器。
command: 启动命令，--appendonly yes开启持久化，确保数据安全。
同样，它加入了app-network。

2.3 添加MySQL数据库服务

然后是MySQL，同样使用官方镜像，需要配置root密码和初始化数据库。

mysql: image: mysql:8 container_name: structbert_mysql restart: unless-stopped ports: - "3306:3306" environment: MYSQL_ROOT_PASSWORD: your_strong_password_here # 务必修改！ MYSQL_DATABASE: structbert_db MYSQL_USER: app_user MYSQL_PASSWORD: app_user_password volumes: - mysql_data:/var/lib/mysql - ./init.sql:/docker-entrypoint-initdb.d/init.sql # 初始化脚本 networks: - app-network healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-uapp_user", "-papp_user_password"] interval: 30s timeout: 10s retries: 3

environment: 设置数据库环境变量，包括root密码、创建的数据库名、应用用户名和密码。生产环境务必使用强密码，并通过env_file或Docker Secret管理，不要硬编码。
volumes:mysql_data是命名卷，存数据。./init.sql是绑定挂载，用于在容器首次启动时执行SQL脚本，创建表结构。你需要在项目根目录创建这个init.sql文件。
healthcheck: 使用mysqladmin ping命令检查数据库是否可连接。

一个简单的init.sql示例，用于创建记录查询历史的表：

-- init.sql USE structbert_db; CREATE TABLE IF NOT EXISTS similarity_queries ( id INT AUTO_INCREMENT PRIMARY KEY, text1 TEXT NOT NULL, text2 TEXT NOT NULL, score FLOAT NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

2.4 构建WebUI服务

WebUI服务稍微特殊点，通常我们需要自己编写前端代码并构建镜像。这里假设我们有一个简单的Python Flask或FastAPI应用作为前端，它调用模型服务API。

首先，在项目根目录创建webui/目录，里面放你的前端应用代码（如app.py,requirements.txt,templates/等）。然后，在webui/目录下创建Dockerfile。

webui/Dockerfile示例：

FROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD ["python", "app.py"]

webui/app.py 简化示例：

from flask import Flask, request, render_template, jsonify import requests import json app = Flask(__name__) MODEL_SERVICE_URL = "http://model-service:8000" # 关键！使用服务名 @app.route('/') def index(): return render_template('index.html') @app.route('/api/predict', methods=['POST']) def predict(): data = request.json try: # 调用模型服务 resp = requests.post(f"{MODEL_SERVICE_URL}/predict", json=data, timeout=30) result = resp.json() # 这里可以添加调用Redis、MySQL的逻辑 return jsonify(result) except Exception as e: return jsonify({"error": str(e)}), 500 if __name__ == '__main__': app.run(host='0.0.0.0', port=5000)

注意，在Flask应用里，我们通过http://model-service:8000来访问模型服务。model-service就是在docker-compose.yml中定义的服务名，Docker Compose的网络DNS会自动解析。

现在，在docker-compose.yml中添加WebUI服务：

webui: build: ./webui # 指定构建上下文 container_name: structbert_webui restart: unless-stopped ports: - "5000:5000" # 将WebUI暴露给宿主机 environment: - MODEL_SERVICE_URL=http://model-service:8000 - REDIS_HOST=redis - MYSQL_HOST=mysql depends_on: - model-service - redis - mysql networks: - app-network

build: ./webui: 告诉Compose基于./webui目录下的Dockerfile构建镜像。
depends_on: 声明依赖关系，确保model-service,redis,mysql先启动，再启动webui。但注意，它只控制启动顺序，不保证依赖服务已“就绪”，所以结合healthcheck更可靠。
ports: 将容器内的5000端口映射到宿主机的5000端口，这样你就能通过浏览器访问http://localhost:5000了。

2.5 配置网络与数据卷

最后，在文件末尾定义我们一直在用的网络和卷。

networks: app-network: driver: bridge volumes: redis_data: mysql_data:

networks: 定义了一个名为app-network的桥接网络，所有服务都在这个网络内，可以互相通过服务名访问。
volumes: 声明了两个命名卷redis_data和mysql_data，用于持久化存储数据。

好了，把上面所有服务的配置片段组合起来，就是一个完整的docker-compose.yml文件了。它定义了四个服务，一个网络，两个持久化卷。

3. 一键启动与日常操作

配置文件写好了，操作就变得极其简单。在项目根目录（即docker-compose.yml所在目录）下，打开终端。

启动所有服务：

docker-compose up -d

-d参数表示在后台运行。第一次运行会拉取镜像（如redis, mysql）、构建镜像（webui），然后启动所有容器。你会看到一串精彩的日志输出。

查看服务状态：

docker-compose ps

这个命令会列出所有服务容器的状态、端口映射等信息。

查看某个服务的日志（比如看模型服务启动是否正常）：

docker-compose logs -f model-service

-f可以持续跟踪日志输出，调试时非常有用。

停止所有服务：

docker-compose down

这个命令会停止并移除所有容器、网络（默认网络），但不会删除命名卷（redis_data,mysql_data），所以你的数据是安全的。

如果想彻底清理（包括数据卷，谨慎使用！）：

docker-compose down -v

在服务运行后，进入某个容器的Shell（比如检查MySQL数据）：

docker-compose exec mysql bash

现在，打开你的浏览器，访问http://localhost:5000，应该就能看到StructBERT相似度计算的Web界面了。输入两段文本，点击计算，请求会经过WebUI -> (Redis) -> 模型服务 -> MySQL，最终把结果呈现给你并保存下来。

4. 进阶配置与优化建议

基础的编排跑通了，咱们再看看怎么让它更健壮、更贴近生产环境。

1. 使用环境变量文件：把敏感信息（如数据库密码）从docker-compose.yml中移出，放到.env文件里，然后在Compose文件中引用。.env文件：

MYSQL_ROOT_PASSWORD=your_very_strong_password MYSQL_PASSWORD=another_strong_password

docker-compose.yml中修改：

environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} MYSQL_PASSWORD: ${MYSQL_PASSWORD}

启动时，Compose会自动读取同目录下的.env文件。记得把.env加入.gitignore。

2. 资源限制：避免某个容器吃光所有资源。

services: model-service: deploy: resources: limits: cpus: '2.0' memory: 4G reservations: cpus: '0.5' memory: 1G

（注意：deploy部分通常用于Docker Swarm，在单机Compose中，更简单的资源限制可以使用cpus,mem_limit等旧参数，或使用runtime配置。对于新版本，建议查看对应Docker Compose版本的文档。）

3. 服务依赖与健康检查：我们之前用了depends_on和healthcheck。更高级的用法是让webui等待model-service健康检查通过再启动，这可以通过脚本或dockerize等工具在启动命令中实现，这里不展开。

4. 多环境配置：可以创建多个Compose文件，如docker-compose.yml（基础配置）、docker-compose.override.yml（开发环境）、docker-compose.prod.yml（生产环境）。通过-f指定文件组合。

# 开发环境 docker-compose up -d # 生产环境（假设生产配置在prod.yml） docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d

5. 总结

走完这一趟，你应该能感受到Docker Compose的魅力了。它把多个分散的容器，通过一个配置文件有机地组织起来，定义了它们之间的关系、依赖和资源。对于咱们这个StructBERT应用来说，从模型服务、Web界面到缓存和数据库，现在都是一个整体。

部署和迁移变得无比简单。只要把整个项目文件夹（包含docker-compose.yml、webui/代码、初始化脚本）拷贝到任何安装了Docker Compose的机器上，一句docker-compose up -d，整个应用就活过来了。这极大地简化了开发、测试和生产环境的一致性管理。

当然，今天演示的是一个相对完整的示例。真实项目中，你可能还需要考虑日志收集、监控、更复杂的网络拓扑、安全加固等。但万变不离其宗，理解了服务定义、网络和卷这几个核心概念，你就能用Docker Compose这把瑞士军刀，应对各种容器编排的挑战了。下次当你再遇到需要多个服务配合的项目时，不妨先想想，能不能用Compose把它们“框”起来。