部署前先弄清适用场景

Gemini CLI 属于面向终端的 AI 命令行工具，适合开发者在服务器、个人电脑或 CI 流程中完成代码解释、脚本生成、文档整理和日志分析等任务。相较于本机直接安装，采用 Docker 部署的优势在于环境隔离、迁移便利以及版本可控，尤其适用于多人共用机器、测试不同版本或希望快速清理运行环境的场景。

需要特别注意的是，Gemini CLI 本质上仍然依赖有效的模型服务凭据和网络访问条件。Docker 仅解决运行环境问题，既不会替你生成访问凭据，也无法绕开服务规则。部署前建议准备好 Docker Engine、可用的 Gemini API Key、一个用于持久化数据的目录，以及明确的镜像来源。

一、准备Docker运行环境

在 Linux 服务器上，可以先确认 Docker 是否可用，运行命令：docker version。如果能够同时看到客户端和服务端版本信息，说明基础环境已就绪。还可以执行：docker info，检查存储驱动、运行状态和当前用户权限。

在生产环境中，不建议直接在不受控的公共机器上保存 API Key。如果是团队服务器，建议创建单独的系统用户或使用受限目录来运行容器，避免密钥、历史记录和项目文件被无关进程读取。

二、选择并拉取镜像

镜像选择是 Docker 部署的第一道安全边界。优先使用项目官方说明中列出的镜像地址；如果打算使用第三方构建的镜像，应当仔细检查镜像说明、Dockerfile 来源、更新频率以及社区反馈，避免将密钥交给不可审计的运行环境。

拉取镜像的基本命令为：docker pull 镜像地址:版本标签。例如将镜像地址替换为你确认可信的 Gemini CLI 镜像：docker pull ghcr.io/example/gemini-cli:latest。不建议长期使用 latest 标签作为生产版本，因为它可能在你不知情的情况下发生变化。更稳妥的做法是固定版本，例如：docker pull ghcr.io/example/gemini-cli:1.2.0。

拉取完成后可查看镜像：docker images | grep gemini。如果发现镜像体积异常、标签与预期不符，或来源页面没有清晰的说明，应暂停部署并重新核对。

三、规划数据目录与配置目录

容器被删除后，其内部文件通常也会随之丢失。因此，凡是需要长期保留的内容都应挂载到宿主机目录，例如配置文件、会话记录、缓存以及工作区文件等。建议创建两个目录：/opt/gemini-cli/config 用于存放配置，/opt/gemini-cli/data 用于存放数据。

可执行命令：mkdir -p /opt/gemini-cli/config /opt/gemini-cli/data。随后根据运行用户调整权限，例如：chmod 700 /opt/gemini-cli/config。配置目录中可能保存密钥或令牌，因此权限不宜设置过宽。数据目录可按团队协作需要设置，但也应避免所有用户可写。

如果 Gemini CLI 支持配置文件，可将配置写入挂载目录，例如 /opt/gemini-cli/config/config.json。如果工具主要读取环境变量，则可通过 Docker 参数传入，但命令行历史可能留下痕迹，生产环境更推荐使用环境变量文件。

四、一键启动容器

基础启动命令可以写成：docker run -d --name gemini-cli --restart unless-stopped -v /opt/gemini-cli/config:/app/config -v /opt/gemini-cli/data:/app/data -e GEMINI_API_KEY=你的密钥 ghcr.io/example/gemini-cli:1.2.0。其中 --name 指定容器名称，--restart unless-stopped 表示服务异常退出后自动重启，-v 用于目录挂载，-e 用于传入环境变量。

如果只是交互式使用命令行工具，也可以不以后台方式运行，而是执行：docker run --rm -it -v /opt/gemini-cli/config:/app/config -v /opt/gemini-cli/data:/app/data -e GEMINI_API_KEY=你的密钥 ghcr.io/example/gemini-cli:1.2.0 gemini --help。这种方式适合临时测试，容器退出后自动清理，但挂载目录中的文件会保留下来。

五、端口映射怎么配置

并非所有 Gemini CLI 部署都需要进行端口映射。如果它只在终端内运行，不提供 Web 界面、本地 API 或回调服务，就不需要开放端口。只有当镜像说明中明确写明监听某个端口（例如 8080）时，才需要使用 -p 参数。

推荐先将服务绑定到本机地址：-p 127.0.0.1:8080:8080。完整示例如下：docker run -d --name gemini-cli -p 127.0.0.1:8080:8080 -v /opt/gemini-cli/config:/app/config -v /opt/gemini-cli/data:/app/data -e GEMINI_API_KEY=你的密钥 --restart unless-stopped ghcr.io/example/gemini-cli:1.2.0。这样一来，外部主机将无法直接访问该端口，非常适合本机调试。

如果确实需要局域网内其他设备访问，可改为：-p 8080:8080，但必须配合访问控制、强口令或上游网关限制。切记不要将未鉴权的 AI 工具服务直接暴露到公网，否则可能造成密钥泄露、额度消耗和数据外传风险。

六、使用环境变量文件管理密钥

为了避免密钥出现在终端历史中，可以创建环境变量文件：/opt/gemini-cli/config/.env，内容示例如下：GEMINI_API_KEY=你的密钥。然后使用命令：docker run -d --name gemini-cli --env-file /opt/gemini-cli/config/.env -v /opt/gemini-cli/config:/app/config -v /opt/gemini-cli/data:/app/data ghcr.io/example/gemini-cli:1.2.0。

这个文件应设置严格的权限：chmod 600 /opt/gemini-cli/config/.env。如果团队内有多人维护，建议使用专门的密钥管理方案，并定期轮换 Key。切勿将 .env 文件提交到代码仓库，也不要在截图、日志或工单中直接展示完整密钥。

七、验证运行状态

容器启动后，先查看运行状态：docker ps。如果没有看到容器，执行：docker ps -a 检查是否已退出。查看日志可使用：docker logs -f gemini-cli。常见的正常信息包括初始化完成、配置加载成功、等待输入或监听端口成功。

若需要进入容器内部进行排查，可执行：docker exec -it gemini-cli sh；部分镜像使用 bash：docker exec -it gemini-cli bash。进入后可检查配置目录是否成功挂载、命令是否存在、版本号是否符合预期。

八、升级与回滚建议

升级前请先备份配置和数据目录：tar -czf gemini-cli-backup.tar.gz /opt/gemini-cli/config /opt/gemini-cli/data。然后拉取新镜像，停止旧容器：docker stop gemini-cli，删除旧容器：docker rm gemini-cli，再用原参数启动新版本。

回滚的关键在于固定旧版本标签。只要旧镜像仍在本机或镜像仓库可用，就可以使用同样的挂载目录重新启动旧版本。若新版本对数据结构做了升级，回滚前应确认兼容性，必要时恢复升级前的备份。

九、常见问题排查

第一，提示找不到密钥。请检查环境变量名是否与工具要求一致，常见写法可能是 GEMINI_API_KEY 或项目自定义名称，应以镜像文档为准。使用 docker exec 进入容器后，可通过 env 命令确认变量是否成功传入。

第二，端口无法访问。先确认工具是否真的启动了服务，再检查容器端口与宿主机端口是否一致。可用 docker port gemini-cli 查看映射关系，用 docker logs 确认监听地址。如果服务只监听 127.0.0.1 且在容器内部，外部映射可能不可用，应按照工具参数改为监听 0.0.0.0。

第三，挂载目录没有写入文件。这通常与路径写错、容器内运行用户无权限有关。请检查 -v 左右两侧的路径是否正确，宿主机目录是否存在，必要时调整目录属主或权限。

第四，请求失败或响应慢。先确认密钥有效、服务配额正常、机器网络可达，再查看 CLI 日志中的错误码。不要反复高频重试，以避免触发服务限制。

十、安全边界与实用建议

Gemini CLI 适合处理代码片段、公开资料、个人知识库和内部辅助任务，但建议不要直接输入高度敏感的客户资料、未脱敏的业务数据或核心凭据。确需用于企业流程时，应当建立数据分级、日志清理、访问审计以及密钥轮换制度。

在镜像层面，要坚持使用可信来源、固定版本并定期更新。在容器层面，要限制端口暴露，尽量采用只读配置、最小权限运行和独立数据目录。在使用层面，要把提示词、输出结果和自动化脚本纳入审核流程，避免将 AI 生成内容未经确认就用于生产变更。

一个稳定的 Docker 部署并不复杂：可信镜像、固定版本、密钥隔离、目录持久化、端口最小开放，再配合日志观察和备份回滚，就能让 Gemini CLI 在个人开发和团队场景中更加可靠地运行。