Как поднять userver без Docker на Ubuntu

Docker для userver ^[1] удобен, но не обязателен. Ниже — рабочий путь: системные пакеты + CMake/Ninja + сборка сервиса из официального шаблона нативно.

Статья по мотивам реального подъёма сервиса на Ubuntu (без make docker-*).

Зачем без Docker

• быстрее итерации по коду (нет обёртки контейнера);

• проще отладка в IDE / sanitizers;

• понятнее, какие библиотеки реально нужны.

Минус: первая сборка долгая — CMake тянет userver через CPM и компилирует сотни файлов.

Что понадобится

• Ubuntu (проверялось на свежих релизах; список пакетов близок к deps для 24.04 ^[2])

• 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. Нативная цепочка полностью валидна.

Итог

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

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