Docker Для Агентов И Ботов (Container Sandboxing)

1. Обзор концепции и системная проблема

Запуск автономных агентов, скраперов, ботов и скриптов генерации кода непосредственно в операционной системе сервера (например, прямым вызовом python agent.py или node bot.js) создает критические угрозы:

• Катастрофические ошибки и инъекции: модель, получив инструмент выполнения shell-команд, может случайно удалить рабочий каталог проекта, изменить права доступа на /etc/shadow или слить системные переменные окружения хоста.
• Конфликты зависимостей («Dependency Hell»): один бот требует Node.js 18 и Python 3.10, другой — Node.js 22 и системные библиотеки Chromium для Playwright. Попытка развернуть их на одном хосте ломает системные пакеты.
• Исчерпание памяти (Fork Bombs): бесконечный автономный цикл может создать тысячи параллельных процессов, вызвав Kernel Panic или полное зависание сервера.

Docker для агентов и ботов обеспечивает детерминированную контейнеризацию и надежную изоляцию (Sandboxing). Используя встроенные примитивы ядра Linux, контейнер создает легковесную эфемерную капсулу, где агент получает все необходимые утилиты, но не может повлиять на хостовую систему или соседние сервисы.

2. Архитектурная таксономия и ментальная модель

Архитектура безопасной изоляции агента опирается на три уровня контроля ядра Linux:

┌─────────────────────────────────────────────────────────────┐
│                 DOCKER AGENT SANDBOX ARCHITECTURE           │
├─────────────────────────────────────────────────────────────┤
│ 1. Process Isolation (Linux Namespaces):                    │
│    • PID (Агент видит только собственные процессы)          │
│    • NET (Изолированный сетевой стек, veth pairs)           │
│    • MNT (Собственная корневая файловая система rootfs)     │
├─────────────────────────────────────────────────────────────┤
│ 2. Resource Enclosure (Control Groups - cgroups v2):        │
│    • Memory limit (например, max 1.5GB RAM)                  │
│    • CPU quota (например, max 1 core)                        │
│    • PIDs limit (защита от бесконечного форка процессов)     │
├─────────────────────────────────────────────────────────────┤
│ 3. Security Hardening Layer:                                │
│    • Unprivileged User (`USER nonroot` вместо UID 0)       │
│    • Read-Only Root Filesystem (`--read-only`)              │
│    • Dropped Linux Capabilities (`--cap-drop=ALL`)          │
├─────────────────────────────────────────────────────────────┤
│ 4. Host Integration: Named Volumes & Health Checks          │
└─────────────────────────────────────────────────────────────┘

1. Пространства имен (Linux Namespaces):
   • Обеспечивают виртуализацию процессов, сети и файловой системы. Агент внутри контейнера видит себя как отдельную ОС и не имеет доступа к процессам хоста.
2. Контрольные группы (cgroups v2):
   • Жесткие аппаратные квоты: лимиты RAM, CPU и количества потоков. Если скрипт агента начинает утекать память, Linux OOM-killer убивает только контейнер, не затрагивая основные службы сервера.
3. Эфемерные одноразовые контейнеры (Throwaway Sandboxes):
   • Запуск с флагом --rm. После выполнения кода контейнер самоуничтожается вместе со всеми временными изменениями.
4. Политики перезапуска (Restart Policies):
   • Для долгоживущих ботов директива restart: unless-stopped в docker-compose.yml гарантирует мгновенное поднятие сервиса после перезагрузки VPS.

3. Технический пайплайн и внутренняя механика

Жизненный цикл безопасного выполнения непроверенного кода в агентской песочнице:

1. Формирование задачи и создание конфигурации: ШИ-агент генерирует скрипт (например, Python-код для парсинга финансовых данных).
2. Подготовка изолированного тома: Хостовая система создает временную папку /tmp/sandbox-run-981, записывает туда скрипт и выставляет права непривилегированного пользователя UID 1000.
3. Запуск защищенного одноразового контейнера: Оркестратор инициирует команду с полным сбросом привилегий:

   docker run --rm \
     --network none \
     --memory 512m \
     --cpus 1.0 \
     --pids-limit 64 \
     --read-only \
     --tmpfs /tmp:rw,noexec,nosuid,size=64m \
     --user 1000:1000 \
     -v /tmp/sandbox-run-981:/app:ro \
     python:3.12-slim python /app/script.py
   

4. Изолированное выполнение: Скрипт выполняется:
   • Сеть полностью отключена (--network none), что исключает утечку данных в облако злоумышленника.
   • Файловая система доступна только для чтения (--read-only).
   • Запись разрешена только в крошечный временный диск в RAM (/tmp).
5. Чтение вывода и очистка: Потоки STDOUT и STDERR передаются обратно в агентское ядро, после чего временный каталог удаляется за долю секунды.

4. Практические инженерные сценарии в продакшене

01. Отказоустойчивый продакшен-стек Telegram-бота

Развертывание бота с помощью docker-compose.yml:

services:
  bot:
    build: .
    restart: unless-stopped
    environment:
      - BOT_TOKEN=${BOT_TOKEN}
      - DATABASE_URL=postgres://user:pass@db:5432/botdb
    depends_on:
      db:
        condition: service_healthy
    deploy:
      resources:
        limits:
          memory: 512M

  db:
    image: postgres:17-alpine
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d botdb"]
      interval: 10s

volumes:
  pgdata:

• Бот автоматически перезапускается в случае непредвиденных сбоев памяти, а данные базы хранятся в персистентном томе pgdata.

02. Изолированный запуск браузерного агента Playwright

Автоматизированное тестирование и парсинг сложных SPA:

• Агент поднимает контейнер с установленным headless Chromium.
• Зависшие вкладки браузера или тяжелые анимации используют только выделенную виртуальную память контейнера, не нагружая рабочую станцию.

03. Пакетное выполнение непроверенных пользовательских скриптов

Платформа онлайн-тестирования кода:

• Каждый пользовательский тест запускается в собственном контейнере с жестким таймаутом в 5 секунд, что исключает зависание сервера из-за бесконечных циклов while(true).

5. Подводные камни, типовые ошибки и безопасность

• Потеря данных из-за отсутствия томов (Volume Absence): Если развернуть контейнер базы данных без монтирования персистентного тома (volumes: - db_data:/var/lib/postgresql/data), при первом же обновлении образа или команды docker compose down вся клиентская база данных будет стерта навсегда.
• Работа под умолчанию под пользователем Root: Если в Dockerfile не указана инструкция USER appuser, процессы внутри контейнера выполняются с правами суперпользователя (UID 0). В случае уязвимости ядра (Container Escape) злоумышленник мгновенно получает полный root на хостовом сервере.
• Переполнение диска неиспользуемыми образами: Регулярные билды агентских образов оставляют гигабайты «осиротевших» слоев. Настройте еженедельную команду очистки: docker system prune -af --volumes.
• Игнорирование .dockerignore: Если не создать файл .dockerignore, папки node_modules, .git и файлы локальных секретов .env будут скопированы внутрь публичного образа контейнера во время сборки.