Docker dla agentów i botów (konteneryzacja w piaskownicy)

1. Przegląd koncepcji i problem systemowy

Uruchamianie autonomicznych agentów, scraperów, botów oraz skryptów generujących kod bezpośrednio w systemie operacyjnym serwera (np. poprzez wywołanie python agent.py lub node bot.js) stwarza krytyczne zagrożenia:

• Katastrofalne błędy i iniekcje: Model, dysponujący narzędziem do wykonywania komend shellowych, może przypadkowo usunąć katalog roboczy projektu, zmienić uprawnienia dostępu do /etc/shadow lub wycieknąć zmienne środowiskowe hosta.
• Konflikty zależności („Dependency Hell”): Jeden bot wymaga Node.js 18 i Pythona 3.10, inny – Node.js 22 oraz bibliotek systemowych Chromium dla Playwright. Próba wdrożenia ich na jednym hoście łamie pakiety systemowe.
• Wyczerpanie pamięci (Fork Bombs): Nieskończona pętla autonomiczna może utworzyć tysiące równoległych procesów, powodując Kernel Panic lub całkowite zawieszenie serwera.

Docker dla agentów i botów zapewnia deterministyczną konteneryzację oraz niezawolną izolację (Sandboxing). Wykorzystując wbudowane prymitywy jądra Linux, kontener tworzy lekką, efemeryczną kapsułę, w której agent otrzymuje wszystkie niezbędne narzędzia, ale nie ma możliwości wpływu na system hosta ani sąsiednie usługi.

2. Taksonomia architektoniczna i model mentalny

Architektura bezpiecznej izolacji agenta opiera się na trzech poziomach kontroli jądra Linux:

┌─────────────────────────────────────────────────────────────┐
│                 ARCHITEKTURA PIASKOWNICY AGENTA DOCKER      │
├─────────────────────────────────────────────────────────────┤
│ 1. Izolacja procesów (Przestrzenie nazw Linux):             │
│    • PID (Agent widzi tylko własne procesy)                 │
│    • NET (Izolowany stos sieciowy, pary veth)               │
│    • MNT (Własny system plików rootfs)                      │
├─────────────────────────────────────────────────────────────┤
│ 2. Ograniczanie zasobów (Grupy kontrolne - cgroups v2):     │
│    • Limit pamięci (np. maks. 1,5 GB RAM)                   │
│    • Kwota CPU (np. maks. 1 rdzeń)                          │
│    • Limit PIDs (ochrona przed nieskończonym forkowaniem    │
│      procesów)                                              │
├─────────────────────────────────────────────────────────────┤
│ 3. Warstwa utwardzenia bezpieczeństwa:                       │
│    • Użytkownik nieuprzywilejowany (`USER nonroot` zamiast  │
│      UID 0)                                                 │
│    • System plików root w trybie tylko do odczytu           │
│      (`--read-only`)                                        │
│    • Usunięte uprawnienia Linux (`--cap-drop=ALL`)          │
├─────────────────────────────────────────────────────────────┤
│ 4. Integracja z hostem: Nazwane wolumeny i kontrole stanu   │
└─────────────────────────────────────────────────────────────┘

1. Przestrzenie nazw (Linux Namespaces):
   • Zapewniają wirtualizację procesów, sieci i systemu plików. Agent wewnątrz kontenera postrzega siebie jako osobny OS i nie ma dostępu do procesów hosta.
2. Grupy kontrolne (cgroups v2):
   • Sztywne kwoty sprzętowe: limity RAM, CPU oraz liczby wątków. Jeśli skrypt agenta zacznie przeciekać pamięcią, mechanizm OOM-killer w Linuksie zabije wyłącznie kontener, nie naruszając głównych usług serwera.
3. Efemeryczne jednorazowe kontenery (Throwaway Sandboxes):
   • Uruchomienie z flagą --rm. Po wykonaniu kodu kontener samoczynnie niszczy się wraz ze wszystkimi tymczasowymi zmianami.
4. Polityki restartu (Restart Policies):
   • Dla długowiecznych botów dyrektywa restart: unless-stopped w pliku docker-compose.yml gwarantuje natychmiastowe podniesienie usługi po restarcie VPS.

3. Pipeline techniczny i mechanika wewnętrzna

Cykl życia bezpiecznego wykonania niezweryfikowanego kodu w piaskownicy agenta:

1. Formułowanie zadania i tworzenie konfiguracji: Agent AI generuje skrypt (np. kod Pythona do parsowania danych finansowych).
2. Przygotowanie izolowanego wolumenu: System hosta tworzy tymczasowy folder /tmp/sandbox-run-981, zapisuje tam skrypt i ustawia uprawnienia nieuprzywilejowanego użytkownika UID 1000.
3. Uruchomienie chronionego jednorazowego kontenera: Orkiestrator inicjuje polecenie z pełnym resetem uprawnień:

   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. Izolowane wykonanie: Skrypt jest uruchamiany:
   • Sieć jest całkowicie wyłączona (--network none), co uniemożliwia wyciek danych do chmury atakującego.
   • System plików jest dostępny tylko do odczytu (--read-only).
   • Zapis jest dozwolony wyłącznie na miniaturowy dysk tymczasowy w RAM (/tmp).
5. Odczyt wyjścia i czyszczenie: Strumienie STDOUT oraz STDERR są przekazywane z powrotem do rdzenia agenta, po czym katalog tymczasowy jest usuwany w ułamku sekundy.

4. Praktyczne scenariusze inżynierskie w produkcji

01. Odporny na awarie stack produkcyjny bota Telegram

Wdrożenie bota za pomocą 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:

• Bot automatycznie restartuje się w przypadku nieprzewidzianych błędów pamięci, a dane bazy przechowywane są w trwałym wolumenie pgdata.

02. Izolowane uruchomienie agenta przeglądarkowego Playwright

Automatyzacja testów i parsowanie złożonych SPA:

• Agent uruchamia kontener z zainstalowanym headless Chromium.
• Zawieszone karty przeglądarki lub ciężkie animacje zużywają jedynie przydzieloną pamięć wirtualną kontenera, nie obciążając stacji roboczej.

03. Masowe wykonanie niezweryfikowanych skryptów użytkownika

Platforma online do testowania kodu:

• Każdy test użytkownika uruchamiany jest we własnym kontenerze z sztywnym timeoutem wynoszącym 5 sekund, co uniemożliwia zawieszenie serwera przez nieskończone pętle while(true).

5. Pułapki, typowe błędy i bezpieczeństwo

• Utrata danych przez brak wolumenów (Volume Absence): Jeśli wdrożysz kontener bazy danych bez montowania trwałego wolumenu (volumes: - db_data:/var/lib/postgresql/data), przy pierwszej aktualizacji obrazu lub wydaniu polecenia docker compose down cała baza danych klienta zostanie trwale usunięta.
• Domyślne działanie pod użytkownikiem Root: Jeśli w pliku Dockerfile nie wskazano instrukcji USER appuser, procesy wewnątrz kontenera działają z uprawnieniami superużytkownika (UID 0). W przypadku podatności jądra (Container Escape) atakujący natychmiast uzyskuje pełne prawa root na serwerze hosta.
• Przepełnienie dysku nieużywanymi obrazami: Regularne buildy obrazów agentów pozostawiają gigabajty „sierocych” warstw. Skonfiguruj cotygodniowe polecenie czyszczenia: docker system prune -af --volumes.
• Ignorowanie .dockerignore: Jeśli nie utworzysz pliku .dockerignore, foldery node_modules, .git oraz lokalne pliki z sekretami .env zostaną skopiowane do publicznego obrazu kontenera podczas budowania.