启鑫的黑板报

标签： Docker

  • Docker 磁盘爆满实录：我以为镜像删干净了，结果系统还是报 No Space

    执行了 docker rmi，为什么磁盘空间还是 100% 占用？记录了一次服务器磁盘爆满的排查过程，深度解析 Docker 分层存储与构建缓存，并分享真正有效的深度清理命令。

    在日常开发和运维中，我习惯于用一个简单的命令来清理 Docker 镜像：

    docker rmi <IMAGE_ID>

    删除不再使用的镜像，释放磁盘空间，逻辑看似完美。直到有一天，我的服务器直接弹出令人绝望的红字：

    No space left on device

    我删光了所有能删的镜像，为什么磁盘还是满的？

    1. 现象：镜像删了，空间没回？

    当我意识到磁盘报警时，第一反应是检查 Docker 的占用情况：

    docker images  # 查看镜像列表
df -h          # 查看系统磁盘状况

    诡异的现象出现了：

    • docker images 列表里只剩下几个业务镜像，加起来不到 2GB。
    • 但 /var/lib/docker 目录依然占用了 40GB+。

    这时候我才意识到：看到的“镜像”，并不代表 Docker 占用的全部空间。

    2. 分析原因：为什么 docker rmi 会失效？

    理解这个问题，必须看清 Docker 的底层存储机制。Docker 镜像并非一个独立的文件，而是像乐高积木一样层层堆叠的（Layer-based Filesystem）。

    2.1 镜像层（Layers）的“幽灵”

    当你用 docker rmi 删除一个镜像时，Docker 只会尝试删除该镜像特有的层。如果某些层被其他镜像引用，或者是构建过程中的中间层，它们就会留在磁盘上，变成无法通过 rmi 直接删除的“幽灵空间”。

    2.2 虚悬镜像（Dangling Images）

    在多次执行 docker build 后，旧的镜像会失去标签（Tag），变成 <none>:<none>。这些镜像往往不会出现在你常规的清理视线里，但依然实打实地占据空间。

    2.3 构建缓存（Build Cache）

    这是最隐形的“空间杀手”。特别是开启了 BuildKit 后，Docker 会产生大量的构建缓存。这些缓存完全不会显示在 docker images 列表中，却是磁盘爆满的元凶之一。

    3. 真正救命的命令：docker image prune

    当我发现手动删除（rmi）无能为力后，我使用了 Docker 官方提供的“深度清理”命令：

    docker image prune -a

    这条命令到底做了什么？

    1. 所有未被容器使用的镜像（即使它有 Tag）。
    2. 所有虚悬镜像（Dangling Images）。
    3. 所有孤立的镜像层。

    ⚠️ 安全提示： 只要你的业务容器正在运行，它所依赖的镜像就是安全的，不会被 prune 误删。但对于已经停止（Exited）的容器，其对应的镜像可能会被判定为“未使用”而被清理。

    执行后，我的服务器磁盘占用瞬间从 100% 降到了 15%。

    4. 进阶技巧：如何精准定位与排查？

    在盲目清理之前，我建议先用以下命令定位 Docker 的真实磁盘占用：

    docker system df

    输出会清晰地展示四类数据的占用分布：

    • Images: 镜像
    • Containers: 容器（包括日志和可写层）
    • Local Volumes: 本地卷
    • Build Cache: 构建缓存

    如果 image prune 仍不足以释放空间，可以使用终极命令：

    # 清理一切：停止的容器、未使用的网络、未使用的镜像和卷
docker system prune -a --volumes

  • 企业内网Docker加速方案：基于 Docker Registry 搭建私有镜像缓存代理

    在企业内网环境下，受限于出口带宽与合规性，Docker 镜像拉取缓慢甚至超时已成为研发痛点。利用 Docker Registry 的 Pull-through Cache（拉取透传缓存） 模式，构建一套“一次拉取、全速复用”的内网镜像加速系统。为企业提供低成本、高效率的镜像分发方案。

    一、 部署指南

    1. 编写配置文件

    在服务器创建目录（如 /opt/docker-proxy），并创建 docker-compose.yaml：

    services:
  registry:
    image: registry:3
    container_name: registry
    ports:
      - "5000:5000"
    restart: always
    environment:
      REGISTRY_PROXY_REMOTEURL: https://registry-1.docker.io
    volumes:
      - ./data:/var/lib/registry

    2. 启动服务

    docker-compose up -d

    二、 客户端配置

    配置好加速器后，内网的终端设备（开发者电脑、测试服务器等）可以通过以下两种方式享受加速。

    方式 A：无侵入式拉取（推荐用于脚本）

    直接在镜像名前加上内网代理服务器的 IP 和端口：

    # 格式：docker pull <代理IP>:5000/<镜像名>
docker pull 192.168.1.100:5000/library/nginx:latest

    注意：对于 Docker Hub 的官方镜像，必须加上 library/ 前缀。

    方式 B：透明加速（推荐用于开发环境）

    修改 Docker 守护进程配置文件 /etc/docker/daemon.json，添加 registry-mirrors：

    {
  "registry-mirrors": ["http://192.168.1.100:5000"],
  "insecure-registries": ["192.168.1.100:5000"]
}

    由于我们默认使用的是 HTTP 协议，需要同时在 insecure-registries 中放行。

  • 使用 Docker 一键部署本地 WordPress 开发环境

    下面是一份适合完全新手的 WordPress 本地安装教程（使用 Docker Desktop + docker compose）

    1. 为什么选择 Docker 部署 WordPress？

    对于初学者来说，Docker 就像是一个“虚拟打包盒”。它将 WordPress 运行所需的所有组件（数据库、PHP、Web服务器等）打包在隔离的环境中运行，完全不干扰你的电脑主机系统。

    主要优势对比：传统环境 vs. Docker 容器

    特性传统安装 Docker 容器化部署
    环境配置需手动安装和配置 PHP、MySQL、Nginx/Apache，易出现版本冲突和依赖错误。仅需一个配置文件 (docker-compose.yml)，环境自动搭建，保证一次成功。
    系统侵入安装组件会修改操作系统配置，可能与其他软件冲突。环境完全隔离，零侵入主机系统，不产生任何“数字垃圾”。
    可移植性难以将环境从一台电脑迁移到另一台，或从本地迁移到云服务器。极高的可移植性。只需复制项目文件夹，即可在任何支持 Docker 的机器上一键还原。
    启动/停止需要分别启动和关闭 Web 服务、数据库服务等多个进程。使用 docker compose up -d 和 down 命令，一键管理所有服务。

    简而言之，Docker 是现代本地开发的首选方案。它帮你彻底告别环境配置的噩梦，让你将所有精力集中在 WordPress 本身，实现真正的即开即用。

    2. 安装 Docker Desktop 与创建独立项目目录

    2.1 安装 Docker Desktop (核心工具)

    访问 Docker 官方网站下载并安装适用于您操作系统的版本：

    https://www.docker.com/products/docker-desktop/

    安装完成后，请打开 Docker Desktop 应用程序，并确保左下角的状态显示为 Running（正在运行）。

    2.2 创建项目工作目录

    在您喜欢的位置（如桌面或文档文件夹），创建一个新的空文件夹，作为您的 WordPress 项目目录。所有配置文件和数据都将保存在这里。

    wordpress-docker

    3. 核心配置：编写 docker-compose.yml 文件

    进入 wordpress-docker 文件夹，新建一个名为 docker-compose.yml 的文件。

    把下面内容完整粘贴进去：

    services:

  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress
      MYSQL_ROOT_PASSWORD: qixinlee.com
    volumes:
      - ./mysql:/var/lib/mysql
    networks:
      - wordpress_network

  wordpress:
    image: wordpress:latest
    restart: always
    ports:
      - "80:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - ./web:/var/www/html
      - ./logs:/var/log/apache2  
    networks:
      - wordpress_network

  phpmyadmin:
    image: phpmyadmin:latest
    restart: always
    ports:
      - "8080:80"
    environment:
      PMA_HOST: db
    networks:
      - wordpress_network

networks:
  wordpress_network:

    保存文件即可。

    4. 执行部署：启动容器并验证服务状态

    这是最关键的一步，我们将通过终端命令启动 WordPress 环境。

    4.1 打开终端并导航到项目目录

    首先，根据您的操作系统，打开相应的终端工具：

    系统终端工具
    WindowsPowerShell / CMD
    Mac / LinuxTerminal

    如何确定路径？

    您需要告诉终端工具您的项目文件夹 wordpress-docker 位于电脑的哪个位置。

    1. 找到项目位置： 找到您在 步骤 2 中创建的 wordpress-docker 文件夹。
    2. 复制完整路径：
    • Windows 用户： 在文件管理器中，点击地址栏并复制完整的路径（例如 C:\Users\YourName\Desktop\wordpress-docker）。
    • Mac / Linux 用户： 右键点击文件夹，选择“获取信息”或“属性”，然后复制路径。

    执行导航（cd 命令）：

    使用 cd (Change Directory) 命令进入该文件夹。请将下面的示例路径替换为您自己电脑上的实际路径（YourName 也要替换）。

    • 如果您的文件夹在 Windows 桌面：
    cd C:\Users\YourName\Desktop\wordpress-docker
    • 如果您的文件夹在 Mac/Linux 桌面：
    cd /Users/YourName/Desktop/wordpress-docker

    成功进入文件夹后，您就可以进行下一步的启动操作了。

    4.2 执行启动命令

    运行以下命令来启动所有服务。-d 参数表示在后台（分离模式）运行容器：

    docker compose up -d

    提示： 第一次运行会自动下载 WordPress、MySQL 和 phpMyAdmin 的镜像文件——请耐心等待下载和创建过程完成。

    4.3 验证服务状态

    启动完成后，运行以下命令检查容器状态：

    docker compose ps

    如果看到以下三个服务都显示为 running，则表示部署成功：

    服务状态
    dbrunning
    wordpressrunning
    phpmyadminrunning

    5. 首次访问：通过浏览器完成 WordPress 首次安装

    浏览器访问：

    http://localhost

    第一次访问会进入 WordPress 安装向导：

    1. 选择语言
    2. 输入站点名称、管理员账号密码
    3. 完成安装并进入后台

    之后，你就能正常管理网站、安装主题、安装插件、写文章了。

    6. 数据库管理：通过 phpMyAdmin 图形界面管理数据库

    phpMyAdmin 是一个流行的、基于 Web 的 MySQL 数据库管理工具。如果你需要手动检查 WordPress 的数据表结构、备份数据，或进行高级的数据库操作，可以使用这个工具。

    浏览器访问：

    http://localhost:8080

    登录时，请使用您在 docker-compose.yml 文件中为 db 服务配置的凭证：

    字段值
    用户名wordpress
    密码wordpress

    7. 容器操作：停止、重启与日志查看

    动作命令
    停止所有服务docker compose down
    重启所有服务docker compose restart
    查看日志docker compose logs -f

    停止不会删除数据，因为数据库文件和网站文件都保存在你本地文件夹里。

    现在你成功拥有了本地 WordPress 环境

    以后开发或者测试主题、插件，都只需要：

    docker compose up -d

    就能一键启动 WordPress

  • Docker 部署 FossFLOW轻松绘制3D云架构与网络拓扑图

    什么是 FossFLOW

    FossFLOW 是一个专注于架构可视化的轻量级前端工具，旨在简化复杂系统图的绘制过程。它采用独特的 等距视角，将网络、云架构、系统拓扑等内容以 3D 立体效果清晰呈现，让抽象结构一目了然。

    主要特点与优势

    • 3D 等距视图：带来更具透视感的展示方式，帮助快速识别组件之间的关系。
    • 纯前端应用：无需部署后端，直接在浏览器中使用，轻便高效。
    • 专为架构设计打造：内置丰富的云计算、网络设备组件，专注支持云架构、网络拓扑、数据流图等场景。
    • 易于使用: 直观的界面和拖放功能使得用户可以快速上手并创建专业的架构图。

    应用场景

    FossFLOW 的设计使其非常适合以下场景：

    • 云架构设计: 无论是 AWS、Azure 还是 Google Cloud，FossFLOW 可以帮助架构师和工程师可视化云资源、服务和它们之间的关系，从而更好地规划和管理云部署。
    • 网络拓扑: 绘制服务器、路由器、交换机、防火墙等网络设备的连接图，清晰展示数据流路径和网络结构。
    • 系统设计: 用于描绘软件系统的组件、模块及其交互，帮助开发团队理解系统的高层结构。

    使用 Docker 部署 FossFLOW

    FossFLOW 是前端应用，部署过程非常简单。借助 Docker可以在几分钟内启动并使用。

    1. 克隆代码仓库

    打开终端，执行以下命令：

    git clone https://github.com/stan-smith/FossFLOW
cd FossFLOW

    这会将 FossFLOW 的代码下载到本地机器，并进入项目根目录。

    2. 运行容器

    docker compose up -d

    3. 打开浏览器访问：

    http://localhost:3000

    看到 FossFLOW 的界面，现在可以开始拖拽组件、连接节点、构建专属的 3D 架构图了！

  • Web 部署新选择：Docker 还是 Podman

    容器化已成为现代 Web 网站部署的核心策略。无论是 Docker 还是 Podman，都能将你的网站及其所有依赖打包成一个独立、可移植的单元，从而极大地简化部署流程。作为开发者，你需要了解它们在架构和使用上的差异，因为这些差异会直接影响你的部署效率、系统安全性，甚至是未来的可扩展性。容器仅仅是一种工具，而非最终目的。

    Docker

    Docker 作为容器技术的先行者，凭借其强大的生态系统和丰富的工具链，已成为 Web 应用部署的事实标准。

    优点：

    • 海量镜像资源，开发部署高效： Docker Hub 上拥有庞大的官方和社区镜像库，涵盖了 Nginx、Node.js、MySQL 等各类服务。这意味着你无需从头配置，就能快速拉取所需环境，大幅缩短开发和部署周期。
    • Docker Compose 简化多服务部署： 现代 Web 应用常由多个服务构成（如 Web 服务器、数据库、缓存）。docker-compose.yml 文件允许你通过一份声明式配置，一次性定义并启动所有相关服务，实现“一键部署”，极大地简化了开发、测试和生产环境的管理。
    • 与云原生编排工具无缝集成： 如果你的网站未来需要扩展到集群环境以应对高并发（例如使用 Kubernetes 或 Docker Swarm），Docker 能提供良好的兼容性。这为你的大规模部署奠定了坚实的基础，确保平滑过渡。
    • 跨平台一致性，提升团队协作效率： 无论团队成员使用 Windows、macOS 还是 Linux，Docker Desktop 都能提供统一的容器开发和运行体验，有效减少“在我机器上能跑”的问题，确保开发与生产环境的高度一致。

    适用场景：

    • 容器技术初学者，希望快速入门并能找到大量学习资料和社区支持。
    • 需要同时管理多个相互依赖的服务，例如 WordPress + MySQL。
    • 计划将 Web 应用部署到大型云平台或 Kubernetes 集群。
    • 团队成员操作系统多样，需要统一的开发环境以提高协作效率。

    Podman

    Podman 是容器领域的一颗新星，以其独特的无守护进程架构和卓越的安全性在 Linux 环境中脱颖而出。

    优点：

    • 无守护进程，支持无 Root 运行，安全性更高： 这是 Podman 的核心优势。它没有常驻后台的守护进程，并且支持“无根容器”（rootless containers）。这意味着你可以以普通用户身份运行容器，即使容器被攻陷，攻击者也难以获得宿主机的 Root 权限，显著降低了安全风险。
    • 与 Systemd 原生集成，简化服务管理： 在 Linux 服务器上，你可以将容器直接注册为 systemd 服务，享受系统级的自启动、守护和监控功能。这让 Web 服务的长期管理变得异常简单和可靠，特别适合在 VPS 或物理服务器上部署。
    • 资源占用低，提升边缘设备性能： 由于 Podman 没有常驻守护进程，它仅在执行命令时才消耗资源。这使得它在资源有限的服务器（如小型 VPS 或边缘设备）上更为高效，能有效节省内存和 CPU，提升系统整体性能。
    • 支持 Pod 架构，与 Kubernetes 理念一致： Podman 能够管理“Pod”（一组共享网络和存储的容器），这与 Kubernetes 的设计理念完全一致。你可以将 Web 服务和数据库打包进一个 Pod，简化它们之间的通信和数据共享，同时也为未来迁移到 Kubernetes 做了技术储备。

    适用场景：

    • 对安全性有极高要求，希望容器能够在无 Root 权限下运行。
    • 主要在 Linux 服务器上进行部署，并希望容器能与系统服务 (systemd) 紧密集成。
    • 资源受限的环境，追求极致的性能和效率。
    • 希望提前熟悉 Kubernetes 的 Pod 概念，为未来的云原生转型做准备。

    实际使用中的关键差异

    除了核心特性，实际部署中还有一些细节差异值得开发者注意：

    • 1. 命令行兼容性并非百分百： 尽管 Podman 的命令与 Docker 大致相似，但在一些高级用法、网络配置或特定参数上仍存在细微差别。习惯 Docker 的用户可能需要短暂的适应期。
    • 2. 镜像构建方式： Docker 主要使用 docker build 命令和 Dockerfile 来构建镜像。Podman 虽然也支持 podman build，但它更推崇与 Buildah 工具集成。Buildah 提供了更底层的控制和更多样的构建方式（甚至无需 Dockerfile），这对于需要高度定制化构建流程的开发者来说非常有用。
    • 3. 存储卷与权限处理： 在 Linux 系统下，Docker 和 Podman 在处理容器存储卷的默认权限和 SELinux 安全上下文时可能有所不同。特别是在 Podman 的无根容器模式下，存储卷的权限配置需要开发者更加细致地处理，以避免潜在的文件访问问题。

    特性对比

    特性/维度DockerPodman
    架构有守护进程（dockerd）无守护进程，命令直接调用容器引擎
    无 Root 运行需要 Root (或 sudo)支持 rootless 模式
    多容器编排Docker Compose / Swarm支持 Pod，但 Compose 支持较弱
    与 Systemd 集成需额外配置或借助外部工具原生支持 systemd 生成服务文件
    镜像构建docker build (基于 Dockerfile)podman build + Buildah (更灵活)
    资源占用较高 (后台常驻 dockerd)更低 (按需启动，无守护)
    安全性中等 (需注意权限)高 (支持无 Root 容器，强权限隔离)

    Docker 和 Podman 并非相互对立，它们代表了两种不同的容器设计理念：

    • Docker = 生态成熟 + 上手快 + 支持云原生全流程。
    • Podman = 安全优先 + 系统集成强 + 更贴近 Linux 哲学。

  • 使用 Docker 部署 Greenbone Community Edition（GCE）：打造你的本地漏洞扫描平台

    一、GCE 简介

    Greenbone Community Edition（GCE） 是由 Greenbone Networks 维护的开源安全漏洞扫描解决方案，基于知名的 OpenVAS（Open Vulnerability Assessment System） 项目构建。它包括：

    • GSA（Greenbone Security Assistant）：图形化 Web 管理界面；
    • GVMD：扫描调度与管理守护进程；
    • OpenVAS Scanner：扫描引擎；
    • Greenbone Community Feed：开源漏洞数据库（每日更新）；
    • GVM-Tools：命令行工具，支持远程自动化控制。

    GCE 是企业级 Greenbone GSM 产品的免费替代方案，非常适合中小企业、个人研究人员、DevSecOps 团队部署。

    二、安装Docker

    $ curl -fsSL https://get.docker.com -o get-docker.sh
$ sudo sh get-docker.sh

    三、部署Greenbone Community Edition（GCE）

    1. 保存 docker-compose.yml 文件
    2. 运行以下命令启动服务：
    docker compose up -d
    1. 容器启动后，访问 Web 管理界面：
    http://<服务器IP>:9392
登录默认管理员账户/密码：admin

    首次启动可能需要等待几分钟，用于加载漏洞数据库、初始化服务。

    name: greenbone-community-edition

services:
  vulnerability-tests:
    image: registry.community.greenbone.net/community/vulnerability-tests
    environment:
      FEED_RELEASE: "24.10"
    volumes:
      - vt_data_vol:/mnt

  notus-data:
    image: registry.community.greenbone.net/community/notus-data
    volumes:
      - notus_data_vol:/mnt

  scap-data:
    image: registry.community.greenbone.net/community/scap-data
    volumes:
      - scap_data_vol:/mnt

  cert-bund-data:
    image: registry.community.greenbone.net/community/cert-bund-data
    volumes:
      - cert_data_vol:/mnt

  dfn-cert-data:
    image: registry.community.greenbone.net/community/dfn-cert-data
    volumes:
      - cert_data_vol:/mnt
    depends_on:
      - cert-bund-data

  data-objects:
    image: registry.community.greenbone.net/community/data-objects
    environment:
      FEED_RELEASE: "24.10"
    volumes:
      - data_objects_vol:/mnt

  report-formats:
    image: registry.community.greenbone.net/community/report-formats
    environment:
      FEED_RELEASE: "24.10"
    volumes:
      - data_objects_vol:/mnt
    depends_on:
      - data-objects

  gpg-data:
    image: registry.community.greenbone.net/community/gpg-data
    volumes:
      - gpg_data_vol:/mnt

  redis-server:
    image: registry.community.greenbone.net/community/redis-server
    restart: on-failure
    volumes:
      - redis_socket_vol:/run/redis/

  pg-gvm:
    image: registry.community.greenbone.net/community/pg-gvm:stable
    restart: on-failure
    volumes:
      - psql_data_vol:/var/lib/postgresql
      - psql_socket_vol:/var/run/postgresql

  gvmd:
    image: registry.community.greenbone.net/community/gvmd:stable
    restart: on-failure
    volumes:
      - gvmd_data_vol:/var/lib/gvm
      - scap_data_vol:/var/lib/gvm/scap-data/
      - cert_data_vol:/var/lib/gvm/cert-data
      - data_objects_vol:/var/lib/gvm/data-objects/gvmd
      - vt_data_vol:/var/lib/openvas/plugins
      - psql_data_vol:/var/lib/postgresql
      - gvmd_socket_vol:/run/gvmd
      - ospd_openvas_socket_vol:/run/ospd
      - psql_socket_vol:/var/run/postgresql
    depends_on:
      pg-gvm:
        condition: service_started
      scap-data:
        condition: service_completed_successfully
      cert-bund-data:
        condition: service_completed_successfully
      dfn-cert-data:
        condition: service_completed_successfully
      data-objects:
        condition: service_completed_successfully
      report-formats:
        condition: service_completed_successfully

  gsa:
    image: registry.community.greenbone.net/community/gsa:stable
    restart: on-failure
    ports:
      - 9392:80
    volumes:
      - gvmd_socket_vol:/run/gvmd
    depends_on:
      - gvmd
  # Sets log level of openvas to the set LOG_LEVEL within the env
  # and changes log output to /var/log/openvas instead /var/log/gvm
  # to reduce likelyhood of unwanted log interferences
  configure-openvas:
    image: registry.community.greenbone.net/community/openvas-scanner:stable
    volumes:
      - openvas_data_vol:/mnt
      - openvas_log_data_vol:/var/log/openvas
    command:
      - /bin/sh
      - -c
      - |
        printf "table_driven_lsc = yes\nopenvasd_server = http://openvasd:80\n" > /mnt/openvas.conf
        sed "s/127/128/" /etc/openvas/openvas_log.conf | sed 's/gvm/openvas/' > /mnt/openvas_log.conf
        chmod 644 /mnt/openvas.conf
        chmod 644 /mnt/openvas_log.conf
        touch /var/log/openvas/openvas.log
        chmod 666 /var/log/openvas/openvas.log

  # shows logs of openvas
  openvas:
    image: registry.community.greenbone.net/community/openvas-scanner:stable
    restart: on-failure
    volumes:
      - openvas_data_vol:/etc/openvas
      - openvas_log_data_vol:/var/log/openvas
    command:
      - /bin/sh
      - -c
      - |
        cat /etc/openvas/openvas.conf
        tail -f /var/log/openvas/openvas.log
    depends_on:
      configure-openvas:
        condition: service_completed_successfully

  openvasd:
    image: registry.community.greenbone.net/community/openvas-scanner:stable
    restart: on-failure
    environment:
      # `service_notus` is set to disable everything but notus,
      # if you want to utilize openvasd directly, remove `OPENVASD_MODE`
      OPENVASD_MODE: service_notus
      GNUPGHOME: /etc/openvas/gnupg
      LISTENING: 0.0.0.0:80
    volumes:
      - openvas_data_vol:/etc/openvas
      - openvas_log_data_vol:/var/log/openvas
      - gpg_data_vol:/etc/openvas/gnupg
      - notus_data_vol:/var/lib/notus
    # enable port forwarding when you want to use the http api from your host machine
    # ports:
    #   - 127.0.0.1:3000:80
    depends_on:
      vulnerability-tests:
        condition: service_completed_successfully
      configure-openvas:
        condition: service_completed_successfully
      gpg-data:
        condition: service_completed_successfully
    networks:
      default:
        aliases:
          - openvasd

  ospd-openvas:
    image: registry.community.greenbone.net/community/ospd-openvas:stable
    restart: on-failure
    hostname: ospd-openvas.local
    cap_add:
      - NET_ADMIN # for capturing packages in promiscuous mode
      - NET_RAW # for raw sockets e.g. used for the boreas alive detection
    security_opt:
      - seccomp=unconfined
      - apparmor=unconfined
    command:
      [
        "ospd-openvas",
        "-f",
        "--config",
        "/etc/gvm/ospd-openvas.conf",
        "--notus-feed-dir",
        "/var/lib/notus/advisories",
        "-m",
        "666",
      ]
    volumes:
      - gpg_data_vol:/etc/openvas/gnupg
      - vt_data_vol:/var/lib/openvas/plugins
      - notus_data_vol:/var/lib/notus
      - ospd_openvas_socket_vol:/run/ospd
      - redis_socket_vol:/run/redis/
      - openvas_data_vol:/etc/openvas/
      - openvas_log_data_vol:/var/log/openvas
    depends_on:
      redis-server:
        condition: service_started
      gpg-data:
        condition: service_completed_successfully
      vulnerability-tests:
        condition: service_completed_successfully
      configure-openvas:
        condition: service_completed_successfully

  gvm-tools:
    image: registry.community.greenbone.net/community/gvm-tools
    volumes:
      - gvmd_socket_vol:/run/gvmd
      - ospd_openvas_socket_vol:/run/ospd
    depends_on:
      - gvmd
      - ospd-openvas

volumes:
  gpg_data_vol:
  scap_data_vol:
  cert_data_vol:
  data_objects_vol:
  gvmd_data_vol:
  psql_data_vol:
  vt_data_vol:
  notus_data_vol:
  psql_socket_vol:
  gvmd_socket_vol:
  ospd_openvas_socket_vol:
  redis_socket_vol:
  openvas_data_vol:
  openvas_log_data_vol: