Docker для userver удобен, но не обязателен. Ниже — рабочий путь: системные пакеты + CMake/Ninja + сборка сервиса из официального шаблона нативно.
Статья по мотивам реального подъёма сервиса на Ubuntu (без make docker-*).
Зачем без Docker
быстрее итерации по коду (нет обёртки контейнера);
проще отладка в IDE / sanitizers;
понятнее, какие библиотеки реально нужны.
Минус: первая сборка долгая — CMake тянет userver через CPM и компилирует сотни файлов.
Что понадобится
Ubuntu (проверялось на свежих релизах; список пакетов близок к deps для 24.04)
g++/cmake/ninja/git~несколько GB места под
build-*и_deps
1. Создать сервис из шаблона
Официальный способ — скрипт userver-create-service из репозитория userver (или готовый шаблон service). В итоге должна получиться структура roughly:
service/ CMakeLists.txt CMakePresets.json Makefile configs/ src/ tests/
В Makefile есть цели cmake-debug, build-debug, start-debug и опционально docker-*. Мы используем только native.
2. Поставить зависимости (один раз)
Для hello/core-сервиса не нужны postgres/mongo/kafka/grpc. Достаточно toolchain + Boost + OpenSSL + yaml-cpp + fmt + libev и т.п.
Пример скрипта scripts/install-deps-native.sh:
#!/usr/bin/env bash set -euo pipefail SUDO=(sudo) [[ "$(id -u)" -eq 0 ]] && SUDO=() "${SUDO[@]}" apt-get update -qq PKGS=( build-essential ccache cmake ninja-build git gdb pkgconf libboost-context-dev libboost-coroutine-dev libboost-filesystem-dev libboost-iostreams-dev libboost-locale-dev libboost-program-options-dev libboost-stacktrace-dev libboost-dev libssl-dev libyaml-cpp-dev libyaml-cpp0.8 libfmt-dev libjemalloc-dev libnghttp2-dev zlib1g-dev libcurl4-openssl-dev libev-dev libcrypto++-dev libc-ares-dev libbenchmark-dev libgtest-dev libgmock-dev libpugixml-dev libre2-dev liblz4-dev python3-dev python3-venv python3-yaml python3-jinja2 python3-voluptuous clang-format ) "${SUDO[@]}" DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends "${PKGS[@]}"
На новых Ubuntu unversioned пакеты Boost (libboost-context-dev и т.д.) сами резолвятся в актуальную версию (например 1.90).
3. Собрать только core (чтобы не тащить всё)
В CMakeLists.txt шаблона до download_userver / find_package(userver) можно выключить тяжёлые фичи:
set(USERVER_FEATURE_POSTGRESQL OFF CACHE BOOL "" FORCE) set(USERVER_FEATURE_REDIS OFF CACHE BOOL "" FORCE) set(USERVER_FEATURE_MONGODB OFF CACHE BOOL "" FORCE) set(USERVER_FEATURE_GRPC OFF CACHE BOOL "" FORCE) set(USERVER_FEATURE_CLICKHOUSE OFF CACHE BOOL "" FORCE) set(USERVER_FEATURE_RABBITMQ OFF CACHE BOOL "" FORCE) set(USERVER_FEATURE_MYSQL OFF CACHE BOOL "" FORCE) set(USERVER_FEATURE_ROCKS OFF CACHE BOOL "" FORCE) set(USERVER_FEATURE_KAFKA OFF CACHE BOOL "" FORCE) set(USERVER_FEATURE_ODBC OFF CACHE BOOL "" FORCE) set(USERVER_FEATURE_YDB OFF CACHE BOOL "" FORCE) set(USERVER_FEATURE_SQLITE OFF CACHE BOOL "" FORCE)
Сервису с userver::core этого хватает. Меньше зависимостей — меньше шансов упасть на configure.
4. Configure + build
cd service make cmake-debug make build-debug
Что происходит:
cmake --preset debug(Ninja, часто с ASan/UBSan в debug-пресете).CPM качает userver (ветка/тег из
DownloadUserver.cmake).Собирается
userver-core+ вашservice— первая сборка может занять много минут (~тысячи translation units).
Повторные сборки после правок своего кода заметно быстрее, особенно с ccache.
Release без санитайзеров (быстрее на каждый день)
make cmake-release make build-release
Debug с USERVER_SANITIZE компилируется медленнее — для ежедневной работы удобнее release или свой preset без ASan.
5. Запуск
Конфиги: configs/static_config.yaml + configs/config_vars.yaml (порт, логи, потоки).
./build-debug/service \ --config configs/static_config.yaml \ --config_vars configs/config_vars.yaml
Проверка:
curl -sS 'http://127.0.0.1:8080/ping' curl -sS 'http://127.0.0.1:8080/hello?name=userver'
Если 8080 занят — смени server-port в config_vars (например на 8090).
Через testsuite:
make start-debug
Типичные грабли
Conda в PATH / LD_LIBRARY_PATH
Если в окружении активен Miniconda, линкер/рантайм может подхватить чужие libcurl / libssl / libyaml-cpp и получить warning про conflicting RPATHs или странные падения.
Перед сборкой:
export PATH="$(echo "$PATH" | tr ':' '\n' | grep -v miniconda | paste -sd:)" unset LD_LIBRARY_PATH CONDA_PREFIX CONDA_DEFAULT_ENV
Порт уже занят
userver в debug с ASan при Address already in use может грохнуться шумно. Сначала ss -tlnp | grep 8080, потом другой порт или освободи процесс.
«Обязательно через Docker?»
Нет. make docker-* в шаблоне — обёртка над теми же cmake/build. Нативная цепочка полностью валидна.
Итог
Шаг |
Команда |
|---|---|
deps |
|
configure |
|
build |
|
run |
|
Docker оставляйте для CI/одинакового окружения у команды. Для локальной разработки userver спокойно живёт на хосте.
Автор: DaxRay. Если нашли неточность под вашей версией Ubuntu — issue/PR в этот репозиторий приветствуются.
Комментарии (7)

RaymanDaxter Автор
28.07.2026 16:13Вы знаете про какую нагрузку идет же речь? когда говорят про высоконагруженные системы
Спасибо, что прочитали статью
RaymanDaxter Автор
28.07.2026 16:13я про то что это про нагрузку на размер кода, а не вычислительную машину

j_larkin
28.07.2026 16:13Термин "высоконагруженные системы" в индустрии практически всегда означает системы, обслуживающие большое количество запросов, пользователей или операций в единицу времени. Это понятие связано с производительностью, масштабированием, отказоустойчивостью и архитектурой.
Никто не использует этот термин в значении "большой размер кодовой базы". Для этого говорят "большие проекты", "масштабный проект" или "сложная кодовая база".
CMake действительно полезен для больших проектов, где сотни таргетов и библиотек, но это никак автоматически не делает тему относящейся к высоконагруженным системам.
Мой первый комментарий был скорее про низкий технический уровень. Минусы я не так часто ставлю, это не продуктивно. Но воспринимайте мои слова как конструктивную критику. Уровень статьи выглядит как "запустить компиляцию по таргету", т.е. уровень пикабу, а не хабра. Но это лишь моё мнение, а не истина в последней инстанции.
RaymanDaxter Автор
28.07.2026 16:13ну я решил начать писать свои статьи - и я эту проблему решал долго
модератор не заблокировал статью поэтому для хабра она подходит
тут есть очень простые статьи и много
к примеру по opengl. поэтому в чем проблема не понимаю
В книги от orely всоконагруженные системы говорится именно про сложноую логическую архитекутуру и размер кодовой базы
немного про нагрузку на вычислительную машину
Sazonov
28.07.2026 16:13У вас статья про то, как просто скомпилировать проект на линуксе. Зачем для этого статья и причём тут userver?
У userver неплохая документация. И если рядовой разработчик не справляется со сборкой (или даже установкой из готовых пакетов), то именно userver вам не нужен.
Если вы не согласны - расскажите про ваш опыт использования userver в реальных проектах.
P.S. я пока только начал изучать возможности userver и собираю его на маке, подтягивая все зависимости через vcpkg, без cpm. Мои фиксы для cmake еще пока сыроваты для публикации пуллреквеста, но я уже близок к тому чтобы полностью завезти userver через vcpkg. Но я не вижу никакого смысла оформлять очевидные инструкции по сборке в виде статьи на Хабре.

RaymanDaxter Автор
28.07.2026 16:13прочитайте внимательно статью
по поводу userve а пишу сейчас продукт
j_larkin
я сейчас прочитал манул о том, как компилить с помощью таргетов cmake? а зачем тег "высокогагруженные системы"?