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

от автора

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 bashset -euo pipefailSUDO=(sudo)[[ "$(id -u)" -eq 0 ]] && SUDO=()"${SUDO[@]}" apt-get update -qqPKGS=(  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 servicemake cmake-debugmake 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-releasemake 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 в этот репозиторий приветствуются.

ссылка на оригинал статьи https://habr.com/ru/articles/1064074/