Kasm Workspaces в Docker Compose: готовый файл

MAATRIX

Держать «одноразовый» браузер для проверки подозрительных ссылок, давать подрядчику доступ к рабочему столу без VPN и логина в основную систему, гонять headless-Chrome для парсинга в изолированном контейнере — все эти задачи решает Kasm Workspaces. Это открытый плейформа для контейнеризированных рабочих столов и приложений, которые открываются прямо в браузере через HTML5-стрим, без установки клиентов и без классического VNC/RDP с его задержками и проблемами с буфером обмена. Ниже — рабочий docker-compose.yml, разбор параметров и типичные грабли при развёртывании на своём VPS.

Что такое Kasm Workspaces и зачем он нужен

Kasm — это не просто «Docker + noVNC». Внутри у него своя система оркестрации контейнеров (Kasm Agent), сервис аутентификации, менеджер образов и прокси-сервис для стриминга рабочего стола по протоколу KasmVNC (доработанный VNC с аппаратным ускорением кодирования и WebRTC-подобной передачей кадров). Из коробки доступны готовые образы: Chrome, Firefox, Ubuntu-desktop с XFCE, Kali Linux, LibreOffice, Tor Browser и десятки других — каждый запускается как изолированный контейнер и уничтожается после сессии (если включён режим ephemeral).

Типичные сценарии использования:

• Изолированный браузинг — открывать фишинговые ссылки, тестировать вредоносные сайты, работать с чувствительными данными в контейнере, который не имеет доступа к остальной инфраструктуре.
• Удалённый доступ для команды — выдавать сотрудникам или фрилансерам рабочий стол с нужным набором софта, не открывая RDP наружу и не выдавая VPN-конфиги.
• CI/тестирование UI — headless и headful браузеры для Selenium/Playwright с готовым веб-интерфейсом для отладки.
• Замена терминального сервера — вместо Windows RDS или классического Guacamole+VNC, если устраивает Linux-десктоп.

В отличие от Apache Guacamole, который просто проксирует существующие RDP/VNC/SSH-сессии, Kasm сам создаёт и управляет контейнерами с рабочими столами — то есть это законченная платформа, а не только шлюз.

Требования к серверу

Kasm — тяжеловесная штука: помимо основного стека (Postgres, Redis, Nginx, API-сервер) он поднимает отдельные контейнеры под каждую пользовательскую сессию. Минимальные требования для теста на 1–3 пользователей:

Каждая активная сессия с браузером съедает ориентировочно 1–2 ГБ RAM и половину-целое ядро CPU в пике (кодирование видеопотока рабочего стола — не бесплатная операция). Точные цифры зависят от нагрузки на сам браузер внутри сессии (видео, тяжёлые SPA), поэтому закладывайте запас и мониторьте docker stats в первую неделю. Под такую нагрузку разумнее брать сервер с выделенными ядрами, а не «плавающими» vCPU — на дешёвых тарифах с overselling кодирование видео начинает подтормаживать первым.

Официальный установщик Kasm (bash <(curl ...)) ставит всё нативно через systemd и свой Docker Compose под капотом, но для управляемого, версионируемого развёртывания удобнее собрать compose-файл вручную — так вы контролируете сети, тома и порты, и можете держать конфиг в git.

Готовый docker-compose.yml

Ниже — упрощённая, но рабочая схема на основе официального core-стека Kasm (версия 1.16.x на конец августа 2026). Полная установка через официальный скрипт разворачивает больше сервисов (share, guac, api, proxy отдельными контейнерами), но для одного сервера с умеренной нагрузкой этого стека достаточно, если вы используете All-in-One установщик как базу, а не собираете с нуля — ручная пересборка всех микросервисов Kasm через compose трудоёмка и плохо документирована апстримом.

Рекомендуемый путь — гибридный: ставим ядро официальным installer'ом (он сам генерирует compose-файлы в /opt/kasm/current/), но управляем жизненным циклом и добавляем свои volume/сети через override-файл:

mkdir -p /opt/kasm-src && cd /opt/kasm-src
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.16.1.7c58c8.tar.gz
tar -xf kasm_release_1.16.1.7c58c8.tar.gz
cd kasm_release
sudo bash install.sh --swap-size 4096

Проверьте актуальный номер релиза на странице загрузок Kasm перед установкой — версии выходят часто, и точный билд у вас на момент чтения статьи может отличаться.

Если же вам нужен именно самостоятельный docker-compose.yml для облегчённого сценария (например, только для проброса одного-двух образов рабочих столов внутрь уже существующей инфраструктуры), вот минимальный рабочий вариант на базе отдельного Kasm-агента и registry с образами:

version: "3.8"

services:
  kasm_db:
    image: postgres:15-alpine
    container_name: kasm_db
    restart: unless-stopped
    environment:
      POSTGRES_DB: kasm
      POSTGRES_USER: kasmapp
      POSTGRES_PASSWORD: ${KASM_DB_PASSWORD}
    volumes:
      - kasm_db_data:/var/lib/postgresql/data
    networks:
      - kasm_net

  kasm_redis:
    image: redis:7-alpine
    container_name: kasm_redis
    restart: unless-stopped
    command: redis-server --requirepass ${KASM_REDIS_PASSWORD}
    volumes:
      - kasm_redis_data:/data
    networks:
      - kasm_net

  kasm_api:
    image: kasmweb/api:1.16.1
    container_name: kasm_api
    restart: unless-stopped
    depends_on:
      - kasm_db
      - kasm_redis
    environment:
      DB_HOST: kasm_db
      DB_PASS: ${KASM_DB_PASSWORD}
      REDIS_HOST: kasm_redis
      REDIS_PASS: ${KASM_REDIS_PASSWORD}
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - kasm_certs:/opt/kasm/current/certs
    networks:
      - kasm_net

  kasm_proxy:
    image: kasmweb/nginx:1.16.1
    container_name: kasm_proxy
    restart: unless-stopped
    depends_on:
      - kasm_api
    ports:
      - "443:443"
    volumes:
      - kasm_certs:/etc/nginx/certs
    networks:
      - kasm_net

  kasm_agent:
    image: kasmweb/agent:1.16.1
    container_name: kasm_agent
    restart: unless-stopped
    depends_on:
      - kasm_api
    environment:
      DB_HOST: kasm_db
      DB_PASS: ${KASM_DB_PASSWORD}
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - kasm_agent_profiles:/profiles
    networks:
      - kasm_net

networks:
  kasm_net:
    driver: bridge

volumes:
  kasm_db_data:
  kasm_redis_data:
  kasm_certs:
  kasm_agent_profiles:

Важная оговорка: официальный стек Kasm внутри сложнее (есть ещё компоненты share, RDP-gateway, guac-сервис для проброса внешних RDP/VNC), и версии образов, теги и переменные окружения меняются от релиза к релизу. Схема выше показывает архитектурный принцип (API + БД + Redis + прокси + агент, управляющий Docker-сокетом), но для продакшна используйте официальный installer — он генерирует полный compose-набор под конкретную версию, синхронизированный с миграциями БД.

Переменные окружения и .env

Создайте .env рядом с compose-файлом:

KASM_DB_PASSWORD=сгенерируйте_длинный_пароль
KASM_REDIS_PASSWORD=ещё_один_длинный_пароль
KASM_ADMIN_EMAIL=admin@ваш-домен.ru

Пароли генерируйте через openssl rand -base64 32, не вписывайте вручную. .env-файл обязательно добавьте в .gitignore, если конфиг лежит в git — это база данных с учётками пользователей и их сессиями, утечка пароля от неё критична.

Первый запуск и настройка

После docker compose up -d (или после официального installer'а) веб-интерфейс поднимается на https://<IP-сервера>:443 (или на порту, который вы прокинули). Самоподписанный сертификат при первом входе браузер пометит как небезопасный — это ожидаемо, если вы ещё не привязали домен.

Логин администратора по умолчанию — admin@kasm.local, пароль генерируется установщиком и печатается в конце вывода install.sh (сохраните его сразу, повторно нигде не показывается). Первым делом:

1. Смените пароль администратора в Admin → Users.
2. Загрузите или включите нужные Workspace-образы в Admin → Images (Chrome, Firefox, Ubuntu Desktop и т.д. — некоторые тянутся из Docker Hub при первом запуске сессии, это может занять пару минут).
3. Настройте группы пользователей и лимиты сессий в Admin → Groups, чтобы один пользователь не мог заспавнить десять параллельных десктопов и не съел всю RAM.
4. Привяжите нормальный домен и SSL — через встроенный Let's Encrypt-модуль Kasm (Admin → Certificates) или через свой Traefik/Nginx Proxy Manager перед Kasm, если Kasm уже часть более крупной инфраструктуры на сервере.

Изоляция сессий и сеть

По умолчанию Kasm поднимает контейнер сессии в отдельной Docker-сети без прямого доступа к другим контейнерам хоста — это и есть основа «изоляции». Но есть нюансы, о которых часто забывают:

• Docker-сокет у агента — контейнер kasm_agent монтирует /var/run/docker.sock, то есть управляет всем Docker на хосте. Это нормальная архитектура Kasm (агенту нужно создавать/убивать контейнеры сессий), но компрометация агента = компрометация хоста. Держите административный доступ под жёстким контролем и не открывайте порт агента наружу.
• Egress-трафик сессий не фильтруется по умолчанию — браузер в контейнере имеет обычный выход в интернет. Для полной изоляции (например, анализ малвари) добавьте отдельную bridge-сеть с ограничением через iptables/nftables или заведите отдельный VPS под такие сессии.
• Постоянство профиля — при включённых persistent profiles данные браузера (куки, история, расширения) сохраняются между сессиями в volume. Для одноразовых «чистых» сессий выключите это в настройках образа (Persistent Profile Path — оставить пустым).

Для контроля исходящего трафика с сервера в целом пригодится настройка UFW — открывайте наружу только 443/tcp (веб-интерфейс) и закрывайте всё остальное, включая случайные порты, которые Docker может пробросить по умолчанию.

Производительность и масштабирование

Основной потребитель ресурсов — кодирование видеопотока рабочего стола (KasmVNC encoder) внутри каждого контейнера сессии. Несколько практических рекомендаций:

• Ограничивайте FPS и разрешение стрима в настройках образа (Admin → Images → <образ> → Advanced) — 24 FPS вместо 60 заметно снижает нагрузку на CPU без ощутимой потери удобства для большинства офисных задач.
• Для десятков одновременных пользователей логично разносить компоненты: kasm_db/kasm_redis/kasm_api на одном сервере, а агентов (которые реально спавнят сессии) — на отдельных нодах-воркерах. Kasm поддерживает multi-agent конфигурацию из коробки через Admin → Agents.
• Мониторьте память отдельно от CPU: браузерные сессии текут по RAM при долгой работе с тяжёлыми SPA сильнее, чем по CPU в простое — держите разумный timeout на неактивные сессии (Idle Session Time Limit в настройках образа), чтобы зависшие вкладки не копились месяцами.
• Диск растёт за счёт логов и, если включены, persistent-профилей — настройте ротацию логов Docker (log-opts с max-size/max-file в /etc/docker/daemon.json), иначе за пару месяцев /var/lib/docker может неожиданно распухнуть.

Если предполагается больше 15–20 параллельных сессий, закладывайте выделенный сервер, а не VPS общего назначения — колебания соседей по хосту бьют по плавности видеопотока.

Частые вопросы