1. 项目概述为什么今天还要亲手部署 HarborHarbor 不是“又一个容器镜像仓库”它是企业级容器治理体系里那根看不见却压不弯的脊梁。我第一次在某金融类客户现场看到他们用三台虚拟机硬扛 Docker Hub 镜像拉取失败时的告警风暴就意识到当业务容器化率超过60%当 CI/CD 流水线每小时构建200个镜像当安全团队开始要求所有镜像必须通过 CVE 扫描、签名验证、策略拦截——Docker Registry 原生方案连日志格式都写不全更别说权限分级、审计留痕、多租户隔离这些刚需。Harbor 就是在这个临界点上被真正“用起来”的。它解决的从来不是“能不能存镜像”而是“敢不敢让开发往生产环境推镜像”。关键词Harbor部署及使用背后藏着三重现实压力一是合规审计要求镜像来源可追溯、操作可回放二是运维团队需要统一入口管理私有镜像、第三方基础镜像、扫描结果和策略配置三是安全团队必须在镜像进入 K8s 集群前完成漏洞阻断、签名校验、SBOM 生成。这不是 DevOps 工具链里的可选项而是容器平台上线前的准入红线。适合谁来读这篇如果你正面临以下任一场景这篇就是为你写的刚接手公司容器平台建设领导说“下周要上线镜像仓库”但你只在本地跑过docker run registry:2已经用着 Harbor但每次升级都卡在数据库迁移或证书续签不敢动生产安全同事发来《镜像安全基线检查表》里面17条要求你一条条对发现 Harbor 默认配置只满足其中5条想把 Harbor 接入现有 LDAP/AD但文档里写的ldap_url和你域控实际返回的 DN 格式总对不上。我带过的三个真实项目某车企智能座舱平台、某省级政务云容器底座、某跨境电商订单中台全部从零部署 Harbor踩过所有典型坑PostgreSQL 连接池耗尽导致 UI 卡死、Clair 扫描器因镜像层过大超时退出、Harbor 与 Kubernetes Ingress TLS 终止冲突引发推送 400 错误……这些不会出现在官方 Quick Start 里但会真实消耗你三天排查时间。接下来的内容就是我把这三年部署、调优、排障经验按真实工作流拆解成可直接抄作业的步骤。2. 整体架构设计与选型逻辑为什么不是简单 docker-compose upHarbor 的部署绝不是“下载离线包、改两行配置、执行 install.sh”就完事。它的架构设计本质是对企业容器治理复杂度的显性化拆解。官方提供三种部署方式Docker Compose单机/测试、Helm ChartK8s 生产、OVAVMware 快速POC。但真实生产环境里90% 的故障根源都来自对架构分层理解偏差——比如把数据库和 Redis 部署在同一台机器上结果扫描任务一启动PostgreSQL 内存吃满整个 Harbor UI 变成“正在加载…”或者把所有组件打包容器里却没给harbor-core分配足够 CPU导致策略引擎响应延迟超 3 秒CI 流水线频繁超时失败。我们最终采用分离式 Helm 部署核心逻辑是让每个组件承担单一职责并能独立伸缩。具体拆解如下2.1 组件职责与资源边界组件核心职责关键资源约束为什么必须分离harbor-database存储项目、用户、策略、扫描报告等结构化数据内存 ≥ 4GB磁盘 IOPS ≥ 3000PostgreSQL 是 Harbor 的状态中心扫描结果、策略日志、审计记录全依赖其事务一致性。共用宿主机会被其他组件 IO 打爆harbor-redis缓存会话、扫描任务队列、临时文件元数据内存 ≥ 2GB禁用持久化Redis 若启用 RDB/AOF在高并发扫描时会产生大量磁盘写拖慢整个集群。分离后可配置为纯内存模式harbor-core权限校验、策略执行、Webhook 触发、API 网关CPU ≥ 2核内存 ≥ 3GB所有 API 请求必经此组件策略引擎如阻止含高危漏洞镜像推送在此执行。CPU 不足会导致策略判断超时降级为“仅告警”harbor-registry镜像存储、分层上传、Manifest 管理磁盘 ≥ 500GBSSD网络带宽 ≥ 1Gbps镜像层文件读写是 IO 密集型操作。与数据库共用磁盘会导致 PostgreSQL WAL 日志写入延迟引发连接超时harbor-trivyCVE 漏洞扫描、配置审计、许可证检测CPU ≥ 4核内存 ≥ 8GBTrivy 扫描单个 2GB 镜像需 3~5 分钟期间占用大量 CPU 和内存。若与 core 共享资源会导致 API 响应停滞提示很多团队用docker-compose.yaml部署时把所有服务写在一个文件里看似方便实则埋下隐患。我见过最典型的案例是某公司用 8C16G 服务器部署 all-in-one Harbor运行三个月后harbor-core进程 RSS 内存涨到 12GBOOM Killer 杀掉进程所有未完成的扫描任务丢失安全团队无法出具当月漏洞报告。2.2 外部依赖选型依据Harbor 官方支持 PostgreSQL、MySQL、Redis 作为外部依赖但生产环境必须做取舍数据库选 PostgreSQL 而非 MySQLHarbor 的审计日志表audit_log和扫描报告表scan_report包含大量 JSONB 字段如漏洞详情、策略匹配规则。PostgreSQL 的 JSONB 索引查询性能比 MySQL 的 JSON 函数快 3~5 倍。实测对比查询“过去24小时所有被阻断的镜像推送”操作PostgreSQL 耗时 120msMySQL 耗时 850ms。更重要的是Harbor 的数据库迁移脚本如 v2.5 → v2.6默认按 PostgreSQL 语法编写MySQL 版本需手动修改 DDL极易出错。缓存选 Redis 6.2 而非 MemcachedHarbor 的会话管理session和扫描队列job_queue强依赖 Redis 的 Pub/Sub 和 Sorted Set 功能。Memcached 不支持消息广播无法实现“扫描完成自动触发 Webhook”。Redis 6.2 新增的 ACL 权限控制可为harbor-core和harbor-jobservice分配不同密码避免密钥泄露风险。对象存储选 S3 兼容服务而非本地文件系统官方文档说“支持 filesystem”但生产环境必须用 S3。原因有三一是本地存储无法跨节点共享HA 部署时harbor-registry实例切换会导致镜像层丢失二是 S3 的版本控制功能可恢复误删镜像三是 S3 的生命周期策略能自动清理 90 天前的扫描缓存Trivy 下载的 CVE 数据库节省 40% 存储空间。我们实测过用 MinIO 替代本地存储后镜像推送成功率从 92.3% 提升至 99.98%。2.3 网络与证书设计原则Harbor 的 HTTPS 不是“加个证书就完事”它涉及四层信任链客户端到 Harbor ProxyNginx浏览器/CLI 访问https://harbor.example.com需有效 TLS 证书建议 Lets Encrypt WildcardProxy 到 Harbor Core/Registry内部通信走 HTTP但必须配置--insecure-registry或自签名 CARegistry 到对象存储S3 访问需 IAM Role 或 Access Key且必须启用 TLSTrivy 扫描器到 CVE 数据源Trivy 默认从 GitHub 下载数据库需确保出向网络可达或配置内网镜像源。注意很多团队在 K8s 中用 Ingress 暴露 Harbor却忽略ingress-nginx的proxy-buffer-size默认值4k太小导致推送大镜像500MB时 Manifest 解析失败报错400 Bad Request。正确做法是在 Ingress annotation 中显式设置nginx.ingress.kubernetes.io/proxy-buffer-size: 128k。3. 核心细节解析与实操要点配置文件里每一行都在解决什么问题Harbor 的harbor.ymlHelm 对应values.yaml不是参数列表而是一份容器治理策略的声明式契约。下面逐项拆解关键配置项背后的业务含义和实操陷阱。3.1 认证与权限体系配置auth_mode: ldap_auth ldap_url: ldaps://ad.example.com:636 ldap_search_dn: CNharbor-reader,CNUsers,DCexample,DCcom ldap_search_password: xxx ldap_base_dn: DCexample,DCcom ldap_filter: (objectClassuser) ldap_uid: sAMAccountName ldap_scope: 2这段配置表面是“连 AD”实则定义了三重治理边界身份同步粒度ldap_filter: (objectClassuser)表示只同步 AD 中的用户对象不包括计算机、组织单元。若误写成(objectClass*)Harbor 会尝试同步所有 AD 对象导致数据库插入失败字段长度超限用户名映射逻辑ldap_uid: sAMAccountName决定了用户登录名是zhangsan还是zhangsanexample.com。某次客户要求“AD 用户必须用邮箱登录”我们改成mail属性结果发现部分用户mail字段为空导致登录 500 错误。最终方案是保留sAMAccountName为主键通过ldap_group_attribute_name同步邮箱到用户资料页搜索范围控制ldap_scope: 2表示子树搜索subtree若设为0base objectHarbor 只查根节点永远找不到用户。实操心得LDAP 配置必须配合./prepare --with-notary --with-clair重新生成配置。很多人改完harbor.yml直接docker-compose up -d结果发现 UI 里用户列表为空——因为prepare脚本会生成common/config/core/env文件其中AUTH_MODE等变量未更新。正确流程是改配置 → 运行 prepare → 重启服务。3.2 镜像扫描与安全策略配置trivy: ignore_unfixed: false skip_update: false insecure: false github_token: severity: UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL scanners: - vuln - config - secretTrivy 配置直接影响安全基线达标率ignore_unfixed: false是否忽略无修复方案的漏洞。设为true会隐藏所有“暂无补丁”的 CVE但审计要求“所有已知漏洞必须记录”所以必须falseskip_update: false是否跳过 CVE 数据库更新。生产环境必须false否则扫描结果基于旧数据库漏报率超 40%。但要注意Trivy 每次启动会自动下载数据库约 300MB若网络不稳定会导致扫描任务卡住。解决方案是提前在 Harbor 节点执行trivy image --download-db-only并挂载本地目录到容器/home/scanner/.cache/trivy/dbscanners列表vuln扫漏洞config扫 Dockerfile 和 Kubernetes YAML 配置风险如特权容器、root 用户运行secret扫镜像层中的密钥文件.env、id_rsa。某次客户安全检查发现secret扫描未启用导致一个含 AWS Access Key 的测试镜像流入预发环境。3.3 存储与性能调优参数storage_service: ca_bundle: /path/to/ca-bundle.crt s3: region: us-east-1 bucket: harbor-prod-images accesskey: xxx secretkey: xxx regionendpoint: https://minio.example.com encrypt: false secure: true v4auth: true chunksize: 5242880 rootdirectory: /dockerS3 配置的chunksize分块上传大小是性能关键参数默认值52428805MB适合千兆网络但在万兆网络或内网直连 MinIO 场景下调大到5242880050MB可提升大镜像2GB推送速度 3.2 倍encrypt: false表示不启用 S3 服务端加密SSE因为 Harbor 已对镜像层做了 SHA256 校验且企业通常要求密钥由 KMS 统一管理而非 S3 自建ca_bundle必须指向 Harbor 节点信任的 CA 证书链否则连接私有 MinIO 时会报x509: certificate signed by unknown authority。注意rootdirectory: /docker不是路径而是 S3 的 prefix。所有镜像层文件将存储在s3://harbor-prod-images/docker/下。若误写为/harbor/docker会导致 Harbor 无法列出镜像UI 显示“no repositories”。3.4 高可用与灾备配置# 在 values.yaml 中启用 HA externalDatabase: host: postgres-ha.example.com port: 5432 username: harbor password: xxx coreDatabase: registry notaryServerDatabase: notary_server notarySignerDatabase: notary_signer externalRedis: host: redis-ha.example.com port: 6379 password: xxx registryDBIndex: 1 jobserviceDBIndex: 2 chartmuseumDBIndex: 3 trivyDBIndex: 4HA 配置的核心是数据库连接池隔离coreDatabase、notaryServerDatabase、notarySignerDatabase必须指向不同 PostgreSQL 数据库schema 级别隔离而非同一库的不同表。因为 Notary内容信任服务的数据库事务模型与 Core 完全不同混用会导致锁表Redis 的DBIndex分配必须严格对应组件jobserviceDBIndex: 2表示harbor-jobservice只操作 Redis DB 2这样即使harbor-core因 Bug 清空 DB 0扫描队列也不会丢失。4. 实操过程与核心环节实现从零部署到策略落地的完整流水线以下是以 Kubernetes 为底座的 Helm 部署全流程所有命令均来自某省级政务云容器平台真实实施记录。环境假设K8s 集群已就绪v1.24kubectl已配置helm已安装cert-manager已部署。4.1 前置准备证书、存储、网络第一步申请 Wildcard TLS 证书Harbor 域名必须为*.harbor.example.com因为后续要支持notary.harbor.example.com内容签名和chartmuseum.harbor.example.comHelm Chart 仓库。使用 cert-manager 创建 Certificate# cert.yaml apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: harbor-wildcard namespace: harbor spec: secretName: harbor-tls issuerRef: name: letsencrypt-prod kind: ClusterIssuer dnsNames: - *.harbor.example.com - harbor.example.com提示secretName: harbor-tls将生成名为harbor-tls的 SecretHelm 会自动挂载到harbor-core容器的/etc/tls目录。若 Secret 名称不匹配Harbor 启动时报错failed to load TLS certificate。第二步创建 S3 兼容存储桶我们使用 MinIO 作为对象存储后端。创建桶并配置策略# 登录 MinIO 控制台创建桶 harbor-prod-images # 设置桶策略只允许 Harbor 服务账号访问 mc policy set readwrite harbor/minio/harbor-prod-images \ --policy{Version:2012-10-17,Statement:[{Effect:Allow,Principal:{AWS:[arn:aws:iam::123456789012:user/harbor-sa]},Action:[s3:GetObject,s3:PutObject,s3:DeleteObject],Resource:[arn:aws:s3:::harbor-prod-images/*]}]}第三步部署外部 PostgreSQL 和 Redis使用 Bitnami Helm Chart 部署高可用实例# PostgreSQL启用 pgBouncer 连接池 helm install postgresql bitnami/postgresql \ --set global.postgresql.auth.postgresPasswordxxx \ --set primary.fullnameOverridepostgresql-ha \ --set architecturereplication \ --set pgBouncer.enabledtrue \ --set pgBouncer.resources.limits.memory2Gi # Redis禁用持久化纯内存模式 helm install redis bitnami/redis \ --set global.redis.passwordxxx \ --set master.persistence.enabledfalse \ --set replica.persistence.enabledfalse \ --set usePasswordtrue注意pgBouncer是必须的。Harbor 的harbor-core默认最大连接数 100但一个扫描任务可能占用 5~8 个连接10 个并发扫描就会耗尽连接池导致 UI 报错too many clients already。pgBouncer 将连接池统一管理实测将并发能力提升至 200。4.2 Helm 部署 Harbor参数详解与避坑第四步下载并定制 Harbor Helm Chart从 goharbor/harbor-helm 下载 v1.13.0当前最新稳定版wget https://github.com/goharbor/harbor-helm/archive/refs/tags/v1.13.0.tar.gz tar -xzf v1.13.0.tar.gz cd harbor-helm-1.13.0编辑values.yaml重点修改以下区块# 1. 外部依赖 externalDatabase: host: postgresql-ha-postgresql.default.svc.cluster.local port: 5432 username: postgres password: xxx coreDatabase: registry notaryServerDatabase: notary_server notarySignerDatabase: notary_signer externalRedis: host: redis-master.default.svc.cluster.local port: 6379 password: xxx registryDBIndex: 1 jobserviceDBIndex: 2 chartmuseumDBIndex: 3 trivyDBIndex: 4 # 2. 存储配置 persistence: enabled: true resourcePolicy: keep imageChartStorage: disableredirect: false type: s3 s3: region: us-east-1 bucket: harbor-prod-images accesskey: xxx secretkey: xxx regionendpoint: https://minio.example.com secure: true v4auth: true chunksize: 52428800 # 50MB 分块提升大镜像推送速度 # 3. TLS 与域名 hostname: harbor.example.com harborAdminPassword: Harbor12345 protocol: https tls: enabled: true secretName: harbor-tls # 必须与 cert-manager 生成的 Secret 名称一致 notarySecretName: notary-tls # Notary 独立证书 # 4. 扫描器配置 trivy: enabled: true ignoreUnfixed: false skipUpdate: false insecure: false severity: CRITICAL,HIGH,MEDIUM scanners: - vuln - config第五步执行部署与验证# 创建命名空间 kubectl create ns harbor # 安装 Harbor helm install harbor . \ --namespace harbor \ --values values.yaml \ --set expose.ingress.hosts.coreharbor.example.com \ --set expose.ingress.hosts.notarynotary.harbor.example.com \ --set expose.ingress.hosts.chartmuseumchartmuseum.harbor.example.com # 查看 Pod 状态 kubectl get pods -n harbor # 应看到harbor-core-xxx, harbor-registry-xxx, harbor-trivy-xxx 等全部 Running第六步首次登录与基础策略配置访问https://harbor.example.com用admin/Harbor12345登录。立即执行三件事创建项目点击“项目” → “新建项目”名称prod-apps勾选“公开”供 CI 流水线匿名拉取配置机器人账号点击“机器人账号” → “新建机器人”名称ci-pipeline权限设为prod-apps的pull/push复制 Token 供 Jenkins 使用启用全局策略点击“管理员” → “配置管理” → “系统设置”开启“镜像扫描”、“内容信任”、“漏洞阻断”。实操心得不要跳过“机器人账号”这步直接用 admin Token 会让 CI 流水线暴露超级管理员凭证。某次客户 Jenkins 配置被泄露攻击者用 admin Token 删除了所有项目。机器人账号可随时禁用且权限最小化。4.3 策略落地从“能用”到“管用”的关键配置部署完成只是起点真正体现 Harbor 价值的是策略配置。以下是某车企项目落地的四大核心策略4.3.1 镜像漏洞阻断策略目标所有推送至prod-apps项目的镜像若含CRITICAL或HIGH漏洞自动拒绝。配置路径项目prod-apps→ “配置” → “漏洞阻断” → 启用设置严重等级为CRITICAL,HIGH。原理当harbor-registry收到镜像推送请求会触发harbor-trivy扫描。扫描完成后harbor-core根据策略判断若报告中存在CRITICAL漏洞则返回403 Forbidden并附带漏洞详情 JSON。CI 流水线捕获该错误停止部署。注意CRITICAL,HIGH是平衡安全与效率的选择。若设为MEDIUM会导致 70% 的构建失败大量基础镜像含中危漏洞反而降低安全水位。我们通过“白名单机制”解决在harbor-core的config.yml中添加vulnerability: ignore: - cve: CVE-2021-44228 # Log4j2 白名单待基础镜像升级后移除 package: log4j-core4.3.2 内容信任Notary策略目标所有生产环境镜像必须签名未签名镜像禁止拉取。配置路径项目prod-apps→ “配置” → “内容信任” → 启用。实操步骤开发者本地安装notaryCLI初始化仓库notary -s https://notary.harbor.example.com init prod-apps/library/nginx签名镜像notary -s https://notary.harbor.example.com add -r prod-apps/library/nginx v1.21.0推送时自动签名docker push harbor.example.com/prod-apps/library/nginx:v1.21.0。效果当 K8s 集群拉取镜像时containerd配置notary插件会校验签名有效性。若签名失效或缺失拉取失败报错signature verification failed。4.3.3 镜像生命周期策略目标自动清理 90 天未拉取的镜像释放存储空间。配置路径项目prod-apps→ “配置” → “镜像生命周期” → 新建策略。参数设置规则名称auto-cleanup-90days触发条件Last pulled before 90 days动作Delete tags and manifests执行频率Daily at 02:00。原理harbor-jobservice每天扫描project_repository表找出last_pull_time now() - 90 days的镜像调用harbor-registryAPI 删除。删除前会发送 Webhook 到 Slack 通知运维组。4.3.4 审计日志对接 SIEM目标所有用户操作登录、推送、删除实时同步到企业 SIEM 平台。配置路径管理员 → “配置管理” → “系统设置” → “审计日志” → 启用设置Endpoint为 SIEM 的 Syslog 地址。关键配置Endpoint:tcp://siem.example.com:514Format:jsonLevel:info记录所有操作或warn仅记录删除、权限变更等高危操作。效果SIEM 收到日志示例{ event_type: PULL, user: dev-zhangsan, repo: prod-apps/frontend, tag: v2.3.1, ip: 10.10.20.15, time: 2023-10-05T08:22:15Z }安全团队可基于此生成“高频拉取行为分析”、“异常时段操作告警”等报表。5. 常见问题与排查技巧实录那些官方文档不会告诉你的真相Harbor 部署后的问题80% 出现在“看似正常”的边缘场景。以下是我在三个项目中整理的高频问题速查表附带独家排查技巧。5.1 镜像推送失败400 Bad Request现象docker push harbor.example.com/prod-apps/app:v1.0报错400 Bad Request日志显示failed to parse manifest。根本原因Ingress Nginx 的proxy-buffer-size过小无法承载大镜像的 Manifest JSON4KB。排查步骤查看harbor-registryPod 日志kubectl logs -n harbor deploy/harbor-registry | grep parse manifest若出现http: proxy error: context canceled基本确定是缓冲区问题检查 Ingress 配置kubectl get ingress harbor-ingress -n harbor -o yaml | grep proxy-buffer-size。解决方案在 Ingress annotation 中添加nginx.ingress.kubernetes.io/proxy-buffer-size: 128k nginx.ingress.kubernetes.io/proxy-buffers: 8 128k提示不要改nginx.conf全局配置Ingress annotation 会覆盖全局设置且便于版本管理。5.2 扫描任务卡住Trivy 一直 Pending现象UI 显示“扫描中…”但 30 分钟无进展harbor-jobservice日志出现failed to get scan job status。根本原因Trivy 数据库下载失败或 Redis 连接池耗尽。排查步骤进入harbor-trivyPodkubectl exec -it -n harbor deploy/harbor-trivy -- sh手动触发扫描trivy image --format json --output /tmp/report.json nginx:alpine若报错failed to download vulnerability DB检查网络连通性curl -I https://github.com/aquasecurity/trivy-db/releases/download/v1-2023091512/trivy.db.tgz若网络正常检查 Redis 连接redis-cli -h redis-master.default.svc.cluster.local -p 6379 -a xxx ping。解决方案网络问题配置 Trivy 内网镜像源在values.yaml中添加trivy: downloadDbOnly: true dbRepository: https://mirror.example.com/trivy-dbRedis 问题增加jobserviceDBIndex的连接池大小在harbor-core的config.yml中jobservice: redis_pool: max_idle: 100 max_active: 2005.3 LDAP 同步失败用户列表为空现象登录 Harbor 后“用户管理”页面无任何用户但harbor-core日志显示ldap search success。根本原因ldap_filter过滤条件过严或ldap_base_dn范围太小。排查步骤在 Harbor 服务器上用ldapsearch模拟查询ldapsearch -x -H ldaps://ad.example.com:636 \ -D CNharbor-reader,CNUsers,DCexample,DCcom \ -w xxx \ -b DCexample,DCcom \ (sAMAccountNamezhangsan)若返回No such object说明ldap_base_dn不包含该用户若返回Insufficient access rights说明ldap_search_dn权限不足。解决方案扩大ldap_base_dn从DCexample,DCcom改为DCcom需 AD 管理员授权降低ldap_filter严格度从(objectClassuser)改为((objectClassuser)(sAMAccountName*))确保匹配所有用户。5.4 UI 加载缓慢Dashboard 卡在“Loading…”现象打开https://harbor.example.comUI 卡在加载状态Network 面板显示api/v2.0/projects请求超时。根本原因PostgreSQL 连接池耗尽harbor-core无法获取数据库连接。排查步骤查看harbor-core日志kubectl logs -n harbor deploy/harbor-core | grep failed to acquire database connection登录 PostgreSQL查看连接数SELECT count(*) FROM pg_stat_activity;若连接数 100确认是否启用了 pgBouncer。解决方案启用 pgBouncer见 4.1 节调整harbor-core连接池参数在values.yaml中core: extraEnv: - name: DATABASE_MAX_IDLE_CONNS value: 50 - name: DATABASE_MAX_OPEN_CONNS value: 1005.5 安全基线不达标CVE 扫描漏报现象安全团队用第三方工具扫描同一镜像发现 12 个CRITICAL漏洞Harbor Trivy 只报告 3 个。根本原因Trivy 数据库版本过旧或扫描器未启用config扫描器。排查步骤进入harbor-trivyPod查看数据库版本trivy --version检查values.yaml中trivy.scanners是否包含config手动更新数据库trivy image --download-db-only。解决方案强制每日更新在harbor-jobservice的 CronJob 中添加schedule: 0 3 * * * # 每天 03:00 jobTemplate: spec: template: spec: containers: - name: update-db image: aquasec/trivy:0.45.0 args: [--download-db-only]启用config扫描trivy配置中 scanners
