Automatic1111 Docker一键部署：镜像拉取、端口映射与数据目录配置

部署前需要了解什么

Automatic1111 是常见的 Stable Diffusion WebUI 实现，适合本地搭建 AI绘画工具，用于文生图、图生图、模型切换、插件扩展和参数调试。相比手动安装 Python、依赖库和运行环境，Docker部署的优势是环境隔离、迁移方便、回滚简单，尤其适合需要在多台机器上复用同一套配置的用户。

在开始前，需要确认三件事：第一，主机已经安装 Docker，并能正常运行容器；第二，如果使用显卡计算，需要安装匹配的显卡驱动和容器运行组件；第三，磁盘空间要足够，基础镜像、模型文件、输出图片和扩展插件会持续占用容量，建议至少预留 50GB，长期使用可准备更大的数据盘。

选择镜像与版本思路

部署 Automatic1111 时，镜像选择很关键。常见做法是使用社区维护的 WebUI 镜像，镜像中通常已包含运行依赖、启动脚本和常用优化参数。选择镜像时，不要只看“最新”，还要查看更新频率、说明文档、是否支持 GPU、默认数据目录位置以及是否提供版本标签。

更稳妥的方式是使用明确版本标签，例如 automatic1111-webui:版本号，而不是长期使用 latest。latest 虽然方便，但每次拉取都可能发生变化，插件兼容性、依赖版本、启动参数都可能受到影响。生产或长期创作环境建议固定版本，验证无误后再升级。

拉取镜像的基本步骤

在终端中先确认 Docker 可用，可执行 docker version 查看服务状态。随后拉取镜像，例如使用 docker pull 镜像名称:版本号。不同镜像仓库的名称略有差异，应以镜像维护方说明为准。拉取速度取决于网络环境和镜像大小，首次下载通常较慢。

如果拉取失败，优先检查镜像名称是否拼写正确、版本标签是否存在、Docker 服务是否启动，以及本机磁盘空间是否不足。不要随意下载来源不明的镜像，AI绘画工具通常会访问本地模型和生成文件，镜像可信度会直接影响数据安全。

端口映射如何配置

Automatic1111 默认 Web 服务常见端口为 7860。Docker 中的服务运行在容器内部，如果希望从浏览器访问，需要将容器端口映射到主机端口。典型形式是 -p 7860:7860，前一个 7860 表示主机端口，后一个 7860 表示容器端口。

如果主机 7860 已被占用，可以改成 -p 17860:7860，然后在浏览器访问 http://主机地址:17860。多实例部署时尤其要注意端口不要重复，例如一个实例用 7860，另一个实例用 7861 或 17860。端口开放范围应尽量控制在可信网络内，不建议直接暴露到公共环境；如需多人访问，应增加访问控制、反向袋里认证或仅允许内网访问。

数据目录为什么必须挂载

Docker 容器默认是临时运行环境，如果不挂载目录，容器删除后模型、插件、输出图片和配置可能一并丢失。因此部署时一定要把关键目录映射到主机。常见需要持久化的目录包括 models、outputs、extensions、embeddings、config 或整个 webui 数据目录。

以常见思路为例，可以在主机创建 /data/automatic1111 作为总目录，再在其中建立 models、outputs、extensions 等子目录。启动容器时使用 -v /data/automatic1111:/容器内数据路径 进行挂载。具体容器内路径要参考镜像说明，有的镜像使用 /stable-diffusion-webui，有的使用 /app，路径不一致会导致模型无法识别。

推荐的启动命令结构

一个典型启动命令通常包含容器名称、端口映射、目录挂载、GPU 参数和启动选项。例如：docker run -d --name automatic1111 -p 7860:7860 -v /data/automatic1111:/data --gpus all 镜像名称:版本号。这里 -d 表示后台运行，--name 便于后续管理，-p 用于端口映射，-v 用于数据持久化，--gpus all 表示允许容器使用显卡资源。

不同镜像对启动参数的支持不同。有些镜像允许通过环境变量指定 COMMANDLINE_ARGS，例如开启 listen、xformers、api、低显存模式等。参数不要盲目堆叠，低显存设备可优先尝试 --medvram 或 --lowvram；需要局域网访问时才开启监听地址；需要程序调用时再开启 API。

使用 Docker Compose 管理更方便

如果准备长期使用，建议采用 Docker Compose 管理。它能把镜像、端口、挂载目录、环境变量、重启策略写入配置文件，后续启动只需执行 docker compose up -d，停止可执行 docker compose down。相比一长串命令，Compose 更适合团队共享和故障排查。

配置时建议加入 restart: unless-stopped，避免主机重启后服务未恢复。目录挂载建议使用绝对路径，不要使用容易混淆的相对路径。升级前复制一份 Compose 配置，并记录当前镜像标签，方便出现兼容问题时快速回到旧版本。

模型文件放在哪里

部署完成后，需要把 checkpoint、VAE、LoRA、ControlNet 模型等文件放入对应目录。一般 checkpoint 放在 models/Stable-diffusion，VAE 放在 models/VAE，LoRA 放在 models/Lora，ControlNet 放在 extensions 或 models/controlnet 相关目录，具体取决于插件和镜像结构。

放入新模型后，如果页面未显示，可在 WebUI 中刷新模型列表，或重启容器。模型文件较大，复制过程中不要中断；下载来源应尽量选择可信渠道，避免把未知文件放入生产环境。长期使用时建议按模型类型、版本、用途建立清晰命名，减少后期管理成本。

启动后的验证流程

容器启动后，先执行 docker ps 查看状态，确认容器处于 Up。再使用 docker logs 容器名 查看启动日志，重点关注是否成功加载依赖、是否检测到显卡、Web 服务是否监听在 0.0.0.0:7860 或指定地址。随后打开浏览器访问 http://localhost:7860 或服务器地址加端口。

第一次启动可能需要初始化依赖和扫描模型，等待时间较长属于正常现象。如果页面能打开，可先用较低分辨率、较少采样步数生成一张测试图，确认流程正常后再逐步增加参数。不要一开始就使用超大分辨率和批量生成，容易占满显存或内存。

常见问题与处理办法

页面打不开：检查容器是否运行、端口是否映射正确、防火墙规则是否允许访问、启动参数是否只监听本地。端口冲突：更换主机端口，例如 17860:7860。模型不显示：确认挂载路径与镜像内部路径一致，文件扩展名是否正确，并刷新模型列表。

显卡不可用：检查主机驱动、Docker 对 GPU 的支持组件、启动时是否加入 --gpus all。生成时报显存不足：降低分辨率、减少批量数量、启用低显存参数，或更换更轻量模型。插件报错：先禁用最近新增插件，确认 WebUI 主版本与插件版本是否匹配。

升级、回滚与备份建议

升级前至少备份三类内容：配置文件、插件目录、模型索引或自定义参数。镜像升级建议先拉取新标签，再用同一份数据目录启动测试容器，确认插件、模型和常用工作流都正常后，再替换正式容器。不要在重要任务进行中直接升级。

如果升级后异常，回滚思路是停止新容器，使用旧镜像标签重新启动，并挂载原数据目录。这里再次体现固定版本标签的重要性：只有记录了旧版本，才能快速恢复。对于高频创作环境，可定期打包配置目录，但模型文件体积较大，可单独保存清单，不必每次完整复制。

安全边界与实用建议

Automatic1111 更适合在本机或可信网络中使用。开启远程访问时，应避免无认证暴露；如需多人共用，建议增加账号校验、访问白名单或网关层保护。不要把包含个人素材、客户素材、未授权模型的数据目录随意共享，也不要运行来源不明的脚本和插件。

日常使用中，建议把模型、输出、插件和配置分区管理；为常用参数建立预设；定期清理 outputs 目录；保留一套稳定镜像作为主力环境，另建测试容器尝试新插件。这样既能享受 Docker部署的便利，也能降低环境损坏、版本冲突和数据丢失的风险。