Docker для агентів та ботів (Container Sandboxing)(Контейнеризація та ізоляція автономних систем у Docker)

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 будуть скопійовані всередину публічного образу контейнера під час збірки.