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

Что происходит:

  1. cmake --preset debug (Ninja, часто с ASan/UBSan в debug-пресете).

  2. CPM качает userver (ветка/тег из DownloadUserver.cmake).

  3. Собирается 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

./scripts/install-deps-native.sh

configure

make cmake-debug

build

make build-debug

run

./build-debug/service --config ... --config_vars ...

Docker оставляйте для CI/одинакового окружения у команды. Для локальной разработки userver спокойно живёт на хосте.


Автор: DaxRay. Если нашли неточность под вашей версией Ubuntu — issue/PR в этот репозиторий приветствуются.

Комментарии (7)


  1. j_larkin
    28.07.2026 16:13

    я сейчас прочитал манул о том, как компилить с помощью таргетов cmake? а зачем тег "высокогагруженные системы"?


  1. RaymanDaxter Автор
    28.07.2026 16:13

    Вы знаете про какую нагрузку идет же речь? когда говорят про высоконагруженные системы
    Спасибо, что прочитали статью


    1. RaymanDaxter Автор
      28.07.2026 16:13

      я про то что это про нагрузку на размер кода, а не вычислительную машину


      1. j_larkin
        28.07.2026 16:13

        Термин "высоконагруженные системы" в индустрии практически всегда означает системы, обслуживающие большое количество запросов, пользователей или операций в единицу времени. Это понятие связано с производительностью, масштабированием, отказоустойчивостью и архитектурой.

        Никто не использует этот термин в значении "большой размер кодовой базы". Для этого говорят "большие проекты", "масштабный проект" или "сложная кодовая база".

        CMake действительно полезен для больших проектов, где сотни таргетов и библиотек, но это никак автоматически не делает тему относящейся к высоконагруженным системам.
        Мой первый комментарий был скорее про низкий технический уровень. Минусы я не так часто ставлю, это не продуктивно. Но воспринимайте мои слова как конструктивную критику. Уровень статьи выглядит как "запустить компиляцию по таргету", т.е. уровень пикабу, а не хабра. Но это лишь моё мнение, а не истина в последней инстанции.


        1. RaymanDaxter Автор
          28.07.2026 16:13

          ну я решил начать писать свои статьи - и я эту проблему решал долго
          модератор не заблокировал статью поэтому для хабра она подходит
          тут есть очень простые статьи и много
          к примеру по opengl. поэтому в чем проблема не понимаю
          В книги от orely всоконагруженные системы говорится именно про сложноую логическую архитекутуру и размер кодовой базы
          немного про нагрузку на вычислительную машину


          1. Sazonov
            28.07.2026 16:13

            У вас статья про то, как просто скомпилировать проект на линуксе. Зачем для этого статья и причём тут userver?

            У userver неплохая документация. И если рядовой разработчик не справляется со сборкой (или даже установкой из готовых пакетов), то именно userver вам не нужен.

            Если вы не согласны - расскажите про ваш опыт использования userver в реальных проектах.

            P.S. я пока только начал изучать возможности userver и собираю его на маке, подтягивая все зависимости через vcpkg, без cpm. Мои фиксы для cmake еще пока сыроваты для публикации пуллреквеста, но я уже близок к тому чтобы полностью завезти userver через vcpkg. Но я не вижу никакого смысла оформлять очевидные инструкции по сборке в виде статьи на Хабре.


  1. RaymanDaxter Автор
    28.07.2026 16:13

    прочитайте внимательно статью
    по поводу userve а пишу сейчас продукт