Nautobot四种部署方式：从Docker Compose到Kubernetes Helm实战指南

1. 项目概述为什么一个网络自动化平台需要“四种姿势”Nautobot 是由 Network to CodeNtC团队主导开发的开源网络源事实Source of Truth, SoT与网络自动化平台它不是简单的 CMDB 或拓扑发现工具而是为现代云原生网络工程师量身打造的“数据中枢编排引擎”。我从 2021 年起在三家不同规模的运营商和金融客户现场落地 Nautobot最深的体会是部署方式从来不是技术选型题而是组织成熟度、运维习惯、基础设施现状和未来演进路径的综合映射。你不会因为 Kubernetes 很火就强行把核心网管系统塞进 K8s也不会因为 Docker Compose 简单就让生产环境裸跑在单机上——这就像给外科医生配手术刀得看他是做微创腹腔镜还是开胸搭桥。标题里说的“四种姿势”指的就是Docker Compose 单机开发/测试模式、Docker Compose 生产级多容器编排模式、Kubernetes 原生集群部署Helm Chart 驱动、Kubernetes 手动 YAML 清单部署。这四者不是并列关系而是存在明确的演进阶梯从本地验证逻辑 → 小团队快速上线 → 中大型组织标准化交付 → 超大规模或强定制化场景深度管控。我见过太多团队卡在第二步——用docker-compose up -d启动后一切正常但一加 Redis 持久化、一配 LDAP 认证、一连外部 Git 仓库就出现ps no configuration file provided: not found或restart always导致服务反复崩溃根本原因是没吃透 Compose 的生命周期管理机制我也见过另一些团队跳过前两步直接 Helm install结果因未理解values.yaml中postgresql.primary.persistence.enabled和redis.master.persistence.enabled的联动关系导致升级后整个状态数据库丢失回滚都找不到快照。这四种方式的核心差异不在命令行长短而在于责任边界划分Docker Compose 把所有依赖PostgreSQL、Redis、RabbitMQ、Nginx打包成一个“黑盒应用”你负责定义它怎么启动、怎么重启、怎么挂载卷Kubernetes 则把每个组件拆成独立的“公民”PostgreSQL 是 StatefulSetRedis 是 DeploymentNautobot Web 是 HorizontalPodAutoscaler 管理的 Pod你不再“启动应用”而是“声明期望状态”K8s 控制面负责持续调谐。Helm 的作用就是把这种声明式配置封装成可复用、可参数化的软件包Chart就像给乐高积木配好说明书和分装盒。所以当你搜索 “ubuntu 22.04 安装 kubernetes” 或 “helm 安装 harbor bitnami” 时本质上是在寻找如何把别人验证过的“状态声明模板”安全地嫁接到自己的基础设施上。适合谁来读如果你是刚接触网络自动化的工程师正被 “docker compose 是干什么的” 困扰本文会告诉你 Compose 文件里volumes不只是存数据更是隔离配置与代码的关键契约如果你是已用上 Ansible 自动化设备配置、正考虑引入 SoT 的网络架构师你会看到 Kubernetes 部署如何与现有 CI/CD 流水线无缝集成如果你是 SRE 团队负责人正评估是否将 Nautobot 纳入统一 K8s 集群管理本文会实测 Helm Chart 在启用 TLS 终止、Ingress 路由、多租户 RBAC 时的真实行为。不讲虚的只讲我在客户现场改了 37 次docker-compose.yml、写了 14 版values.yaml、重装过 5 次 K8s 集群后沉淀下来的硬核经验。2. 四种部署方式的设计逻辑与适用场景深度拆解2.1 Docker Compose 单机开发/测试模式为什么它不是“玩具”而是设计验证的黄金标准很多人把docker-compose.yml当作临时测试脚本这是巨大误解。Nautobot 官方 GitHub 仓库中development/目录下的 Compose 文件其实是整个平台架构的“最小可行契约”Minimum Viable Contract。它强制约束了四个核心依赖的版本兼容性PostgreSQL 14、Redis 7、RabbitMQ 3.11、Python 3.11。我曾在一个金融客户项目中发现他们自建的 PostgreSQL 12 集群无法支撑 Nautobot 1.6 的dcim.device模型迁移报错column last_updated does not exist根源就是跳过了 Compose 开发环境验证直接在生产库上执行迁移。Compose 的价值在于它用 20 行 YAML 定义了一个可重现、可审计、可丢弃的完整运行时上下文。这个模式的核心设计逻辑是“进程隔离 配置即代码”。docker-compose.yml中的services不是服务列表而是进程拓扑图nautobot进程依赖nautobot-worker进程处理异步任务nautobot-worker又依赖redis进程作为消息队列nautobot进程自身通过environment注入NAUTOBOT_DATABASE_URLpostgresql://nautobot:nautobotpostgres:5432/nautobot这串 URL 不是魔法字符串而是对postgres服务名、端口、数据库名、用户名密码的精确寻址。当你说docker compose ps报no configuration file provided90% 的情况是你在错误目录执行了命令或者.env文件缺失——.env文件才是真正的配置中心它把敏感信息如NAUTOBOT_SECRET_KEY和环境变量如NAUTOBOT_ALLOWED_HOSTS从 YAML 中剥离实现配置与代码分离。这也是为什么windows docker compose用户常遇到路径问题Windows 默认使用\作为路径分隔符而 Compose 的volumes映射要求/必须写成./config:/opt/nautobot/nautobot/configuration.py而非.\config:\opt\nautobot\nautobot\configuration.py。适用场景非常明确个人开发者本地功能验证、小团队两周内快速搭建 PoCProof of Concept、CI/CD 流水线中的单元测试环境。它不适合生产但它是所有生产部署的“数字孪生体”。我坚持要求所有新成员入职第一周必须在自己笔记本上用 WSL2Ubuntu 22.04完整走一遍git clone https://github.com/nautobot/nautobot cd nautobot docker compose up -d然后手动修改configuration.py添加一个自定义字段再触发一次docker compose restart nautobot。这个过程不是为了学 Docker而是建立对 Nautobot 运行时契约的肌肉记忆。2.2 Docker Compose 生产级多容器编排模式如何让单机部署扛住真实业务流量当 PoC 获得认可你需要把 Nautobot 推向生产。这时docker-compose.yml不再是开发脚本而是一份生产就绪的基础设施即代码IaC声明。关键转变在于从“能跑起来”到“跑得稳、看得清、扩得动”。官方提供的production/目录 Compose 文件正是为此设计。它引入了三个核心增强反向代理层Nginx、持久化存储策略、健康检查与重启策略。先说 Nginx。很多新手直接暴露 Nautobot 的 8000 端口这是严重安全隐患。生产级 Compose 必须包含nginx服务它通过volumes挂载自签名或 Lets Encrypt 证书并在nginx.conf中配置proxy_pass http://nautobot:8000;同时设置proxy_set_header X-Forwarded-For $remote_addr;。这样做的意义远超 HTTPS 加密它让 Nautobot 应用层无需处理 SSL 终止专注业务逻辑它允许你在 Nginx 层做请求限速limit_req、IP 黑白名单geomap、静态资源缓存location ~* \.(js|css|png|jpg)$极大降低后端压力。我曾在一个省级广电客户项目中仅通过 Nginx 配置limit_req zoneapi burst10 nodelay;就将恶意扫描 API 的请求拦截率提升至 99.2%而 Nautobot Worker 的 CPU 使用率下降 40%。再说持久化。docker compose restart always看似可靠但若宿主机断电未刷盘的数据会丢失。生产级 Compose 必须显式定义volumespostgres_data:/var/lib/postgresql/data、redis_data:/data、nautobot_media:/opt/nautobot/media。这里有个极易被忽略的细节postgres_data卷的权限。PostgreSQL 容器以 UID 999 运行若宿主机目录/var/lib/postgresql/data的属主不是 999容器启动会失败并报initdb: error: could not change permissions of directory /var/lib/postgresql/data: Permission denied。解决方案不是chmod 777绝对禁止而是用docker volume create --driver local --opt ouid999,gid999 --opt typetmpfs --opt devicetmpfs postgres_data创建带 UID/GID 的卷或在宿主机上chown -R 999:999 /path/to/postgres_data。最后是健康检查。healthcheck指令不是可选项而是生产系统的生命线。nautobot服务的健康检查应为healthcheck: test: [CMD, curl, -f, http://localhost:8000/api/status/] interval: 30s timeout: 10s retries: 3 start_period: 40s这个配置告诉 Docker每 30 秒用 curl 检查/api/status/接口是否返回 HTTP 200超时 10 秒连续 3 次失败则标记为 unhealthystart_period: 40s是给 Django 应用冷启动留出缓冲时间。配合restart: on-failure:3就能实现故障自动恢复。我在线上环境实测过当模拟kill -9杀死 Nautobot 进程后平均 22 秒内服务自动恢复用户无感知。2.3 Kubernetes 原生集群部署Helm Chart 驱动为什么 Helm 是企业级交付的“瑞士军刀”当你管理的网络设备超过 5000 台或需要与 Argo CD、Flux 等 GitOps 工具集成时Docker Compose 的“单机思维”必然触顶。Kubernetes 成为必选项但直接手写数百行 YAML 是灾难。Helm 的价值就是把 Kubernetes 的复杂性封装成“一键安装”的确定性体验。Nautobot 官方 Helm Chartnautobot/nautobot不是简单打包而是遵循 CNCF 最佳实践的企业级应用交付框架。Chart 的核心设计逻辑是“分层抽象 参数化注入”。整个 Chart 分为三层charts/子 Chart如postgresql、redis、rabbitmqtemplates/主模板生成 Nautobot 的 Deployment、Service、Ingress、Secretvalues.yaml配置文件用户唯一需要修改的入口。这种结构意味着你可以用--set postgresql.enabledfalse关闭内置 PostgreSQL改用企业已有的 RDS 实例可以用--set redis.existingSecretprod-redis-secret复用现有 Redis 凭据更关键的是values.yaml中的ingress配置块直接决定了 Nautobot 如何暴露给外部——ingress.enabledtrue且ingress.classNamenginx就会生成标准 Ingress 资源由集群内的 Nginx Ingress Controller 处理若设为ingress.classNameistio则生成 Istio VirtualService实现服务网格集成。Helm 的真正威力在升级与回滚。helm upgrade nautobot nautobot/nautobot --version 1.6.0 -f my-values.yaml不是覆盖安装而是执行“声明式差异计算”Helm 比较新旧values.yaml只更新实际变更的字段如replicaCount从 2 改为 3其他配置保持不动。这避免了传统脚本升级时“全量覆盖导致配置丢失”的风险。我经历过一次惨痛教训某次升级因未备份values.yaml误将nautobot.extraEnv中的NAUTOBOT_GIT_TOKEN覆盖为空导致所有 Git 集成插件失效。Helm 的helm history nautobot和helm rollback nautobot 1让我在 3 分钟内完成回滚而不用翻查 Git 历史。适用场景聚焦于中大型组织标准化交付、多环境dev/staging/prod一致性管理、与企业现有 K8s 生态如 Harbor 镜像仓库、Prometheus 监控深度集成。当你搜索 “helm 部署 harbor 通过 ingress 但无法访问”本质是 Ingress Controller 未正确配置 TLS 或 Service 名称不匹配这恰恰说明 Helm Chart 的强大——它把问题暴露在配置层而非黑盒内部。2.4 Kubernetes 手动 YAML 清单部署什么情况下你需要亲手拧每一颗螺丝Helm Chart 再强大也无法覆盖所有边缘场景。手动 YAML 部署不是“原始人做法”而是终极控制权的体现。典型场景有三类安全合规强要求如禁用 Helm Tiller、超大规模定制如多集群联邦部署、遗留系统深度集成如对接 Oracle 数据库。手动部署的本质是把 Helm Chart 的templates/目录“展开”成纯 YAML并进行精细化调整。例如Helm Chart 默认的nautobot-deployment.yaml可能只定义了基础资源限制resources: requests: memory: 512Mi cpu: 250m limits: memory: 1Gi cpu: 500m但在一个承载 20000 台设备的金融核心网环境中我将其改为resources: requests: memory: 4Gi cpu: 1000m limits: memory: 8Gi cpu: 2000m # 关键增强添加 QoS 类别 qosClass: Burstable # 更关键的是亲和性调度 affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app.kubernetes.io/name operator: In values: - nautobot topologyKey: topology.kubernetes.io/zone这段配置强制 Nautobot Pod 分散在不同可用区zone避免单点故障qosClass: Burstable确保内存突发时有弹性空间。这些细节 Helm Chart 不会默认开启因为它们高度依赖你的基础设施拓扑。另一个典型场景是 TLS 终止位置。Helm Chart 默认在 Ingress 层终止 TLS但某些金融客户要求应用层Nautobot Pod 内部也启用 HTTPS以满足等保三级“通信传输加密”要求。这时你需要手动修改nautobot-deployment.yaml在容器args中加入--https-redirect并在volumeMounts中挂载私钥证书同时在service中开放 443 端口。整个过程涉及 7 个 YAML 文件的协同修改任何一处疏漏都会导致服务不可用。我建议只有在 SRE 团队具备 K8s 深度调试能力时才采用此模式否则宁可选择 Helm。3. 核心实操环节详解从零开始逐个击破每种部署的“致命细节”3.1 Docker Compose 单机开发模式绕不开的 5 个“第一次”第一次环境准备与基础依赖安装Ubuntu 22.04 / Windows WSL2在 Ubuntu 22.04 上ubuntu安装docker compose的标准流程是# 1. 更新系统并安装必要工具 sudo apt update sudo apt install -y curl gnupg lsb-release # 2. 添加 Docker 官方 GPG 密钥关键避免 apt-key 警告 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # 3. 添加稳定版仓库 echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 4. 安装 Docker Engine 和 Compose Plugin注意不是旧版 docker-compose sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 5. 验证安装 docker compose version # 输出应为 v2.x.x非 v1.x.x提示docker composev2是 Docker CLI 的原生插件而docker-composev1是独立二进制。新版 Compose Plugin 支持docker compose ls、docker compose logs --tail100等高级功能且与 Docker Desktop 深度集成。Windows 用户务必使用 WSL2Docker Desktop for Windows 的 Hyper-V 模式对网络设备模拟支持极差。第二次克隆代码与首次启动解决no configuration file providedgit clone https://github.com/nautobot/nautobot.git cd nautobot # 创建 .env 文件这是救命稻草 cat .env EOF NAUTOBOT_VERSION1.6.0 NAUTOBOT_SECRET_KEYyour-super-secret-key-change-this-in-production NAUTOBOT_ALLOWED_HOSTSlocalhost,127.0.0.1 NAUTOBOT_DATABASE_URLpostgresql://nautobot:nautobotpostgres:5432/nautobot NAUTOBOT_REDIS_URLredis://redis:6379/0 NAUTOBOT_RABBITMQ_URLamqp://guest:guestrabbitmq:5672// EOF # 启动注意必须在 nautobot/ 目录下执行 docker compose -f development/docker-compose.yml up -d # 查看日志确认无报错 docker compose -f development/docker-compose.yml logs -f nautobot注意docker compose ps报no configuration file provided的根本原因是当前目录下没有docker-compose.yml或docker-compose.yaml。-f参数指定文件路径是强制要求不能省略。另外NAUTOBOT_SECRET_KEY必须是 50 位以上随机字符串用openssl rand -hex 32生成。第三次自定义配置与模型扩展configuration.py的正确打开方式Nautobot 的灵魂在于configuration.py。在development/模式下它位于nautobot/nautobot/configuration.py。不要直接编辑此文件正确做法是# 1. 创建自定义配置目录 mkdir -p ./custom-config # 2. 编写 custom-config/configuration.py cat ./custom-config/configuration.py EOF # -*- coding: utf-8 -*- from nautobot.core.settings import * # noqa: F403 # 继承默认配置 ALLOWED_HOSTS [localhost, 127.0.0.1] SECRET_KEY os.environ.get(NAUTOBOT_SECRET_KEY, ) # 添加自定义字段 CUSTOM_FIELDS { dcim.device: { device_owner: { type: text, label: 设备负责人, description: 该设备的最终责任人, } } } # 启用 Git 集成关键 GIT_SYNC_ENABLED True GIT_SYNC_INTERVAL 300 # 5分钟同步一次 EOF # 3. 修改 docker-compose.yml挂载自定义配置 # 在 nautobot 服务的 volumes 下添加 # - ./custom-config:/opt/nautobot/nautobot/configuration.py:ro # 4. 重启服务 docker compose -f development/docker-compose.yml restart nautobot实操心得CUSTOM_FIELDS的键名dcim.device必须与 Django App 名完全一致大小写敏感。GIT_SYNC_ENABLEDTrue后Nautobot 会自动拉取 Git 仓库中的jobs/目录这是实现自动化任务的基础。第四次数据初始化与初始用户创建invoke命令的隐藏技巧Nautobot 启动后是空库需初始化超级用户# 进入 nautobot 容器 docker compose -f development/docker-compose.yml exec nautobot bash # 在容器内执行 nautobot-server createsuperuser # 按提示输入用户名、邮箱、密码 # 退出容器 exit注意nautobot-server是 Django 的管理命令封装createsuperuser会连接 PostgreSQL 创建用户。若报django.db.utils.OperationalError: FATAL: database nautobot does not exist说明 PostgreSQL 容器未就绪等待 30 秒后重试。更稳妥的方式是docker compose -f development/docker-compose.yml exec nautobot nautobot-server migrate先执行数据库迁移。第五次验证 API 与前端访问curl和浏览器的双重校验# 1. 用 curl 验证 API curl -X GET http://localhost:8000/api/dcim/sites/ \ -H Authorization: Token your-api-token-here \ -H Accept: application/json # 2. 获取 API Token需先登录 Web UI # 3. 浏览器访问 http://localhost:8000用 superuser 登录 # 4. 检查右上角用户头像 → API Tokens → 创建新 Token提示API Token 是 Bearer Token格式为Token token-string。Web UI 登录后可在http://localhost:8000/admin/users/token/页面管理 Token。切勿在生产环境使用DEBUGTrue这会导致敏感信息泄露。3.2 Docker Compose 生产级模式解决restart always失效的 3 个根因根因一PostgreSQL 数据卷权限错误Permission denied当docker compose up -d后postgres容器反复重启docker compose logs postgres显示initdb: error: could not change permissions of directory这是经典权限问题。解决方案# 1. 停止并删除旧卷谨慎确保有备份 docker compose -f production/docker-compose.yml down -v # 2. 创建新卷并设置 UID/GID docker volume create --driver local \ --opt typetmpfs \ --opt devicetmpfs \ --opt ouid999,gid999 \ postgres_data # 3. 或在宿主机创建目录并授权 sudo mkdir -p /opt/nautobot/postgres-data sudo chown -R 999:999 /opt/nautobot/postgres-data # 4. 修改 docker-compose.yml 中 volumes 路径指向该目录根因二Nginx 配置错误导致 502 Bad Gatewaydocker compose ps显示nginxhealthy 但nautobotunhealthycurl http://localhost返回 502检查nginx日志docker compose -f production/docker-compose.yml logs nginx | tail -20 # 常见错误connect() failed (111: Connection refused) while connecting to upstream # 原因nginx.conf 中 proxy_pass 地址错误应为 http://nautobot:8000而非 http://localhost:8000正确nginx.conf片段upstream nautobot_backend { server nautobot:8000; } server { listen 80; server_name localhost; location / { proxy_pass http://nautobot_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }根因三健康检查超时healthcheck配置不当docker compose ps显示nautobot状态为(unhealthy)但docker compose logs nautobot无错误。这是因为健康检查curl超时。解决方案# 在 production/docker-compose.yml 的 nautobot 服务下 healthcheck: test: [CMD, curl, -f, -s, http://localhost:8000/api/status/] interval: 45s # 延长间隔避免过于频繁 timeout: 15s # 延长超时给 Django 更多响应时间 retries: 5 # 增加重试次数 start_period: 60s # 延长启动期适应慢速磁盘3.3 Kubernetes Helm 部署从helm install到ingress可访问的完整链路步骤一环境准备与 Helm 初始化ubuntu 22.04 安装kubernetes在 Ubuntu 22.04 上推荐使用 MicroK8s轻量、易管理# 1. 安装 MicroK8s sudo snap install microk8s --classic # 2. 启用必要插件 microk8s enable dns dashboard storage ingress registry # 3. 配置 kubectl 别名 sudo snap alias microk8s.kubectl kubectl # 4. 验证集群状态 kubectl get nodes -o wide # 5. 添加 Helm 仓库 helm repo add nautobot https://nautobot.github.io/helm-charts/ helm repo update步骤二定制values.yaml并安装解决helm 部署harbor 通过ingress 但无法访问创建my-nautobot-values.yaml# 启用 Ingress ingress: enabled: true className: nginx # 必须与 microk8s enable ingress 创建的 IngressClass 名称一致 hosts: - host: nautobot.local paths: - path: / pathType: Prefix tls: - secretName: nautobot-tls hosts: - nautobot.local # 使用外部 PostgreSQL企业级要求 postgresql: enabled: false # 外部数据库配置 externalDatabase: host: your-rds-endpoint.amazonaws.com port: 5432 database: nautobot user: nautobot password: your-password # 启用 TLS 终止Ingress 层 tls: enabled: true secretName: nautobot-tls生成 TLS Secret# 1. 创建自签名证书生产环境请用 Lets Encrypt openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout tls.key -out tls.crt -subj /CNnautobot.local # 2. 创建 Secret kubectl create secret tls nautobot-tls --key tls.key --cert tls.crt # 3. 安装 helm install nautobot nautobot/nautobot \ --version 1.6.0 \ -f my-nautobot-values.yaml \ --namespace nautobot \ --create-namespace步骤三验证 Ingress 可访问性排查无法访问的 4 个检查点检查 Ingress 资源状态kubectl get ingress -n nautobot # 输出应显示 ADDRESS 字段如 192.168.1.100若为空说明 Ingress Controller 未就绪检查 Ingress Controller Podkubectl get pods -n kube-system | grep nginx # 确保 nginx-ingress-microk8s-controller-xxx 处于 Running 状态检查 Service 是否关联正确kubectl get svc -n nautobot # 确认 nautobot-web Service 的 CLUSTER-IP 可访问且 Endpoints 有 IP kubectl get endpoints nautobot-web -n nautobot检查 DNS 解析# 在集群内测试 kubectl run -it --rm --imagecurlimages/curl curl-test -- sh # 在容器内执行 curl -k https://nautobot.local/api/status/ # 若成功说明 Ingress 工作正常若失败检查 /etc/hosts 是否添加 192.168.1.100 nautobot.local3.4 Kubernetes 手动 YAML 部署编写第一个nautobot-deployment.yaml模板构建从 Helm Chart 反向生成Helm Chart 的templates/deployment.yaml是最佳学习材料。用helm show manifest导出helm show manifest nautobot/nautobot --version 1.6.0 -f my-values.yaml nautobot-manual.yaml提取核心 Deployment 片段精简为apiVersion: apps/v1 kind: Deployment metadata: name: nautobot-web namespace: nautobot labels: app.kubernetes.io/name: nautobot spec: replicas: 2 selector: matchLabels: app.kubernetes.io/name: nautobot template: metadata: labels: app.kubernetes.io/name: nautobot spec: containers: - name: nautobot image: nautobot/nautobot:v1.6.0 ports: - containerPort: 8000 name: http envFrom: - configMapRef: name: nautobot-config - secretRef: name: nautobot-secrets resources: requests: memory: 4Gi cpu: 1000m limits: memory: 8Gi cpu: 2000m livenessProbe: httpGet: path: /api/status/ port: 8000 initialDelaySeconds: 60 periodSeconds: 30 readinessProbe: httpGet: path: /api/status/ port: 8000 initialDelaySeconds: 10 periodSeconds: 10 # 关键ServiceAccount 用于访问 Kubernetes APIGit Sync 需要 serviceAccountName: nautobot-sa --- # 创建对应的 ConfigMap 和 Secret apiVersion: v1 kind: ConfigMap metadata: name: nautobot-config namespace: nautobot data: NAUTOBOT_ALLOWED_HOSTS: nautobot.local NAUTOBOT_DATABASE_URL: postgresql://nautobot:nautobotpostgres.nautobot.svc.cluster.local:5432/nautobot --- apiVersion: v1 kind: Secret metadata: name: nautobot-secrets namespace: nautobot type: Opaque stringData: NAUTOBOT_SECRET_KEY: your-50-char-secret-key NAUTOBOT_DATABASE_PASSWORD: your-db-password注意postgres.nautobot.svc.cluster.local是 Kubernetes 内部 DNS 名称格式为service-name.namespace.svc.cluster.local。手动部署必须精确匹配此格式否则连接失败。4. 常见问题与独家排查技巧实录4.1 Docker Compose 问题速查表问题现象根本原因排查命令解决方案docker compose ps报no configuration file provided: not found当前目录无docker-compose.yml或未用-f指定路径ls -la查看当前目录文件确保在nautobot/目录执行或显式指定-f development/docker-compose.ymlpostgres容器反复重启日志Permission denied宿主机数据目录 UID/GID 不匹配 PostgreSQL 容器UID 999ls -ld /path/to/postgres_datasudo chown -R 999:999 /path/to/postgres_data或用docker volume create --opt ouid999,gid999nautobot容器启动后立即退出无日志configuration.py语法错误或NAUTOBOT_SECRET_KEY为空docker compose logs nautobot检查.env文件确保NAUTOBOT_SECRET_KEY非空用python -m py_compile custom-config/configuration.py验证语法curl http://localhost返回502 Bad GatewayNginxproxy_pass地址错误或nautobot服务未就绪docker compose logs nginx检查nginx.confproxy_pass必须为http://nautobot:8000服务名非localhostdocker compose restart always无效