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

从零开始使用FireRedASR-AED-L：Git代码管理与Docker化部署指南

news 2026/4/2 0:31:11

从零开始使用FireRedASR-AED-L：Git代码管理与Docker化部署指南

如果你已经对语音识别技术有所了解，并且正在寻找一个能快速上手、效果不错的开源方案，那么FireRedASR-AED-L可能是一个值得尝试的选择。它集成了自动语音识别（ASR）和音频事件检测（AED）的能力，还提供了一个直观的Web界面，方便我们进行交互和测试。

不过，直接从源码开始部署，可能会遇到环境依赖、配置复杂等问题。今天，我们就来聊聊如何把这件事变得简单、标准化。核心思路是：用Git管理代码版本，用Docker封装运行环境，最后构建成镜像，实现一键部署。这样，无论是在你自己的开发机上测试，还是部署到服务器，都能保证环境一致，省去很多麻烦。

这篇文章，我会带你走一遍完整的流程：从GitHub上拉取示例代码，到编写Dockerfile构建专属镜像，再到将镜像推送到私有仓库，形成一个可复用的部署包。整个过程就像搭积木，一步步来，清晰明了。

1. 前期准备：环境与工具检查

在开始动手之前，我们需要确保手头有趁手的工具。别担心，这些都是开发者的“标配”，检查一下就好。

1.1 基础环境确认

首先，你需要一台Linux服务器或者你自己的Linux/Mac开发机。Windows用户可以通过WSL2获得完整的Linux体验，这对后续的Docker操作非常友好。

打开终端，检查一下系统版本和基础工具：

# 查看系统信息（示例为Ubuntu） lsb_release -a # 检查Git是否安装 git --version # 检查Docker是否安装 docker --version docker-compose --version # 如果使用Compose的话

如果git或docker命令未找到，就需要先安装它们。以Ubuntu系统为例，安装命令如下：

# 更新软件包列表 sudo apt-get update # 安装Git sudo apt-get install git -y # 安装Docker Engine sudo apt-get install docker.io -y sudo systemctl start docker sudo systemctl enable docker # 将当前用户加入docker组，避免每次使用sudo sudo usermod -aG docker $USER # 执行后需要退出终端重新登录生效

1.2 获取项目代码与镜像

FireRedASR-AED-L的官方仓库提供了模型和示例。我们首先需要把代码拿到本地。

# 创建一个项目目录并进入 mkdir -p ~/projects/firered_asr cd ~/projects/firered_asr # 克隆官方示例代码仓库（这里假设仓库地址为示例，请替换为实际地址） git clone https://github.com/username/firered-asr-aed-examples.git cd firered-asr-aed-examples

代码拉取下来后，你可以看到项目的结构，通常包含模型文件、配置文件、测试脚本等。同时，我们需要获取其WebUI的Docker镜像。假设镜像已经发布在公共仓库：

# 拉取FireRedASR-AED-L的WebUI镜像 docker pull registry.example.com/firered-asr-aed-webui:latest

到这里，我们的“原材料”就准备好了：一份是源码，一份是封装好的Web应用环境。

2. 理解部署逻辑：从代码到容器

在动手写Dockerfile之前，我们先花两分钟理清思路。我们要做的，不是从零编译整个项目，而是基于官方提供的WebUI运行时镜像，将我们的定制代码和配置“叠加”上去。

你可以这样理解：官方的WebUI镜像是一个已经装好所有系统依赖、Python环境、基础框架的“纯净系统”。我们的代码是放在这个系统里运行的“应用程序”。Dockerfile的作用，就是创建一个自动化脚本，告诉Docker如何把这个“应用程序”安装到“纯净系统”里，并做好设置。

这样做的好处很明显：

环境一致：杜绝了“在我机器上能跑”的问题。
部署极简：最终只需一条docker run命令。
易于维护：更新代码后，重新构建镜像即可，服务器端无需复杂操作。

我们的工作流将分为三步：

编写Dockerfile，定义构建步骤。
使用docker build命令构建出我们自己的镜像。
将构建好的镜像推送到私有仓库，供部署服务器拉取。

3. 编写Dockerfile：构建定制镜像

现在，进入核心环节。我们在示例代码的根目录下创建一个名为Dockerfile的文件（没有后缀名）。

# 使用官方WebUI镜像作为基础镜像 FROM registry.example.com/firered-asr-aed-webui:latest # 设置工作目录 WORKDIR /app # 将当前目录下的所有代码文件复制到容器的/app目录下 # 注意：确保本地有requirements.txt等必要文件 COPY . /app/ # 安装额外的Python依赖（如果有的话） # 如果官方镜像已包含全部依赖，此步骤可省略或用于安装你的特定工具包 RUN pip install --no-cache-dir -r requirements.txt # 暴露WebUI服务的端口（通常为7860或5000，请根据实际镜像调整） EXPOSE 7860 # 设置容器启动时执行的命令 # 这里假设启动命令是启动一个Python Web服务，具体命令需根据项目来定 CMD ["python", "app.py"]

这个Dockerfile非常简洁，做了以下几件事：

FROM：指定基础镜像，这是我们能力的来源。
WORKDIR：设置容器内的工作路径，后续命令都在此路径下执行。
COPY：将我们本地的代码全部拷贝到容器内。
RUN：在构建镜像时执行命令，这里用于安装依赖。
EXPOSE：声明容器运行时监听的端口，方便映射。
CMD：指定容器启动后默认执行的命令。

重要提示：CMD中的启动命令需要根据firered-asr-aed-examples项目实际的启动方式来确定。你需要查看项目文档或代码，找到启动Web服务的正确命令。可能是python app.py，也可能是uvicorn main:app --host 0.0.0.0 --port 7860等。

4. 构建与测试：生成你的镜像

Dockerfile写好之后，就可以用它来构建镜像了。在包含Dockerfile的目录下执行：

# 构建镜像，-t参数用于给镜像打标签 # 格式：docker build -t [仓库地址/]镜像名:标签 . # 最后的点“.”表示当前目录是构建上下文 docker build -t my-firered-asr-webui:v1.0 . # 查看本地镜像列表，确认构建成功 docker images | grep my-firered-asr

构建过程可能会花费几分钟，Docker会逐层执行Dockerfile中的指令。成功后，我们就有了一个名为my-firered-asr-webui:v1.0的本地镜像。

接下来，在本地运行这个镜像，测试一切是否正常：

# 运行容器 # -p 参数将本地的8080端口映射到容器的7860端口 # -d 参数让容器在后台运行 docker run -d -p 8080:7860 --name asr-test my-firered-asr-webui:v1.0 # 查看容器运行状态 docker ps # 查看容器日志，检查是否有错误 docker logs asr-test

如果日志显示服务启动成功，没有报错，你就可以打开浏览器，访问http://localhost:8080（如果你的服务器没有桌面环境，则是http://<服务器IP>:8080），应该就能看到FireRedASR-AED-L的Web界面了。

测试完成后，记得停止并移除测试容器：

docker stop asr-test docker rm asr-test

5. 推送到私有仓库：实现部署标准化

本地测试通过，意味着我们的镜像已经“打包”好了。接下来，为了能在其他服务器上部署，我们需要把它上传到一个镜像仓库。这里以搭建私有Docker Registry为例。

5.1 搭建或使用私有仓库

如果你公司内部有Harbor、GitLab Container Registry等，可以直接使用。这里简单演示如何在另一台服务器上启动一个最简易的私有仓库：

# 在作为仓库的服务器上执行 docker run -d \ -p 5000:5000 \ --name registry \ --restart=always \ -v /data/registry:/var/lib/registry \ registry:2

这样，一个私有仓库就在http://<仓库服务器IP>:5000运行了。

5.2 推送镜像到仓库

回到我们构建镜像的机器，需要先给本地镜像打上符合私有仓库地址的标签，然后推送。

# 1. 给本地镜像打上新的标签，指向私有仓库 docker tag my-firered-asr-webui:v1.0 <仓库服务器IP>:5000/firered-asr/webui:v1.0 # 2. 如果私有仓库是http且不安全（默认需要https），需要修改Docker守护进程配置或添加不安全仓库 # 编辑 /etc/docker/daemon.json (如果不存在则创建) # 添加： { "insecure-registries":["<仓库服务器IP>:5000"] } # 然后重启docker： sudo systemctl restart docker # 3. 推送镜像到私有仓库 docker push <仓库服务器IP>:5000/firered-asr/webui:v1.0

推送成功后，你可以在任何能访问该私有仓库的机器上，拉取并运行这个镜像了。

5.3 在部署服务器上拉取运行

在最终要部署的服务器上，操作变得极其简单：

# 1. 拉取镜像（同样需要配置insecure-registries） docker pull <仓库服务器IP>:5000/firered-asr/webui:v1.0 # 2. 运行容器 docker run -d \ -p 7860:7860 \ --name firered-asr-production \ --restart=unless-stopped \ <仓库服务器IP>:5000/firered-asr/webui:v1.0

--restart=unless-stopped参数可以让容器在异常退出时自动重启，增强稳定性。

6. 进阶：结合Git与CI/CD流程

到目前为止，我们已经实现了手动构建和部署。要让这个过程自动化，我们可以将其集成到CI/CD（持续集成/持续部署）流水线中。思路是：当Git仓库的代码发生更新（比如推送到main分支），自动触发镜像构建、测试、并推送到私有仓库，甚至自动部署到服务器。

这里给出一个GitLab CI/CD的.gitlab-ci.yml配置文件示例，你可以把它放在项目根目录：

stages: - build - deploy variables: IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA # 使用提交哈希作为标签 build-image: stage: build image: docker:latest services: - docker:dind script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY - docker build -t $IMAGE_TAG . - docker push $IMAGE_TAG only: - main # 仅在main分支推送时触发 deploy-to-server: stage: deploy image: alpine:latest script: - apk add --no-cache openssh-client - eval $(ssh-agent -s) - echo "$DEPLOY_SERVER_SSH_KEY" | ssh-add - - ssh -o StrictHostKeyChecking=no user@your-deploy-server " docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY && docker pull $IMAGE_TAG && docker stop firered-asr-production || true && docker rm firered-asr-production || true && docker run -d -p 7860:7860 --name firered-asr-production --restart=unless-stopped $IMAGE_TAG " only: - main dependencies: - build-image

这个配置做了两件事：