Разворачиваем Odoo 19 Community на своём VPS: Docker, PostgreSQL, nginx

Требования к железу: сайзинг из реальных внедрений

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы обслуживаем компании до 50 рабочих мест в Москве, держим свои серверы в дата-центре МТС и арендуем VPS у российских провайдеров. Odoo я разворачиваю клиентам не первый год, и эта статья — вторая в серии: в обзорной части я разбирал, кому вообще подходит Odoo Community и чем она отличается от Enterprise, а здесь — чистая практика развёртывания. Реальные команды, рабочие конфиги, сайзинг из моих проектов и грабли, которых нет в официальной документации.

Начнём с главного вопроса, который задаёт каждый клиент: «какой сервер брать?». Ошибиться тут дорого в обе стороны — недобор ресурсов даёт тормоза и злых менеджеров, перебор означает переплату каждый месяц. За несколько внедрений у меня сложилась вот такая таблица, от которой я отталкиваюсь при заказе VPS.

Пояснения к цифрам. На старте до десяти человек Odoo 19 уверенно живёт на двух ядрах и четырёх гигабайтах — этого хватает для приложения, отдельного контейнера PostgreSQL и системного запаса. Как только подключаются модули продаж, аналитика и растёт число одновременных сессий, я перехожу на четыре ядра и восемь гигабайт: это тот самый «комфортный» тариф, на котором отдел из 25–50 человек работает без задумчивости интерфейса в понедельник утром.

Почему диск считаем с запасом

Сорок гигабайт SSD — это минимум, и вот из чего он складывается. Сама Ubuntu и Docker-образы съедают несколько гигабайт. База PostgreSQL растёт по мере накопления сделок, писем и истории. Но главный пожиратель места — filestore: Odoo хранит вложения (сканы договоров, коммерческие предложения, картинки товаров) не в базе, а отдельными файлами на диске. Плюс бэкапы, которые я всегда держу локально хотя бы за несколько последних дней перед выгрузкой на внешнее хранилище. Отдел из 25 человек за год спокойно набирает 15–20 ГБ одних только вложений. Дешевле сразу взять SSD побольше, чем через полгода мучиться с расширением диска на живой системе.

Сколько это стоит и почему сервер в России

Ориентир по российским VPS на 2026 год — примерно 1500–3000 ₽ в месяц за конфигурацию под 25–50 пользователей. Это тот диапазон, в котором я беру машины у отечественных провайдеров, и на нём же считаю совокупную стоимость владения в финальном разделе.

Почему именно Россия, а не дешёвый европейский хостинг. Во-первых, 152-ФЗ: CRM с персональными данными клиентов (ФИО, телефоны, почта) по закону должна храниться на серверах в РФ, и объяснять это проверяющим потом дороже, чем сразу взять правильную площадку. Во-вторых, скорость отклика: когда сервер физически рядом с офисом, задержка до него — единицы миллисекунд, и интерфейс Odoo ощущается мгновенным. Европейский пинг в полтораста миллисекунд на каждый клик менеджеры замечают и жалуются.

Docker или пакетная установка: что выбираем и почему

Прежде чем открывать терминал, надо решить, каким способом ставить. Вариантов у Odoo по сути два, и у каждого своя область применения.

Пакетная установка из репозитория Odoo

Классический путь — подключить официальный репозиторий Odoo и поставить систему через apt как обычный сервис, а рядом развернуть PostgreSQL. Так вы получаете полный контроль над Python-окружением: можете доставлять свои и сторонние модули прямо в питоновские пути, отлаживать код, ставить конкретные версии зависимостей. Для команды, которая пишет собственные модули под клиента и живёт в этом коде, пакетная установка удобнее — среда прозрачна и вся под рукой.

Плата за это — хрупкость. Обновление версии, конфликт зависимостей Python, случайно обновившийся системный пакет — и вы разбираетесь, что именно сломалось в окружении. Перенос на другой сервер превращается в аккуратное воспроизведение всех зависимостей.

Официальный Docker-образ odoo:19

Odoo публикует официальный образ odoo:19 — это Community-редакция, собранная на базе Ubuntu 24.04 LTS. Базу данных при этом поднимают отдельным контейнером из образа postgres:16. Такой подход даёт то, ради чего Docker и придумали: одинаковую среду на сервере разработки, на тесте и в проде. Никаких «у меня работало» — образ один и тот же везде.

Обновление сводится к смене тега образа и перезапуску стека. Откат при неудачном апдейте — обратная смена тега: данные-то лежат в отдельных томах и никуда не деваются. Перенос на новый сервер — это копирование двух томов и одного compose-файла.

Дальше вся статья идёт по пути docker compose как основному сценарию — именно так мы сдаём Odoo клиентам под ключ.

Пошаговое развёртывание на Ubuntu 24.04

Переходим к практике. Дальше — ровно та последовательность, по которой работает моя команда: подготовка чистой Ubuntu, файл docker-compose.yml с разбором, конфиг odoo.conf и первый запуск с созданием базы.

Подготовка Ubuntu 24.04

Берём свежий VPS с Ubuntu 24.04 LTS. Первым делом — обновление и отдельный пользователь для работы вместо постоянного root. Затем настраиваем брандмауэр так, чтобы снаружи торчали только нужные порты: SSH, HTTP и HTTPS. Порты Odoo (8069 и 8072) наружу не открываем никогда — к ним обращается только nginx на том же хосте.

# обновляем систему и заводим рабочего пользователя
apt update && apt -y upgrade
adduser deploy
usermod -aG sudo deploy

# брандмауэр: наружу только SSH, HTTP и HTTPS
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable

# Docker Engine и плагин compose из официального репозитория Docker
apt -y install ca-certificates curl
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
  https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" \
  > /etc/apt/sources.list.d/docker.list
apt update
apt -y install docker-ce docker-ce-cli containerd.io docker-compose-plugin
usermod -aG docker deploy

После добавления пользователя в группу docker нужно перелогиниться, чтобы членство применилось. Проверяем, что всё встало: docker compose version должна показать версию плагина.

docker-compose.yml с разбором строк

Создаём рабочий каталог (я держу проект в /opt/odoo) и в нём — три подкаталога и два файла. Вот полный compose-файл, который мы кладём клиентам:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: postgres
      POSTGRES_USER: odoo
      POSTGRES_PASSWORD: сложный_пароль_БД
    volumes:
      - odoo-db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "odoo"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

  odoo:
    image: odoo:19
    depends_on:
      db:
        condition: service_healthy
    ports:
      - "127.0.0.1:8069:8069"
      - "127.0.0.1:8072:8072"
    environment:
      HOST: db
      USER: odoo
      PASSWORD: сложный_пароль_БД
    volumes:
      - odoo-web-data:/var/lib/odoo
      - ./config:/etc/odoo
      - ./addons:/mnt/extra-addons
    restart: unless-stopped

volumes:
  odoo-db-data:
  odoo-web-data:

Разберу по строкам, потому что здесь легко наступить на грабли.

• Сервис db на образе postgres:16. Переменные POSTGRES_USER и POSTGRES_PASSWORD задают учётку, под которой Odoo ходит в базу — они должны совпадать с USER и PASSWORD у сервиса odoo. Том odoo-db-data хранит собственно данные PostgreSQL — это то, что вы бэкапите и что переживает пересоздание контейнера.
• healthcheck на pg_isready. Без него Odoo при старте стека может ломануться в ещё не поднявшуюся базу и упасть. Связка depends_on с condition: service_healthy заставляет контейнер приложения дождаться, пока PostgreSQL реально готов принимать соединения, а не просто запущен.
• Порты только на localhost. Запись 127.0.0.1:8069:8069 публикует порт исключительно на петлевом интерфейсе — снаружи он недоступен, наружу смотрит только nginx. Порт 8072 — это gevent-воркер, который обслуживает живой чат, шину уведомлений и веб-сокеты; его тоже пробрасываем на localhost для nginx.
• Тома приложения. odoo-web-data — это тот самый filestore с вложениями, его теряют чаще всего. Каталог ./config отдаём под odoo.conf, а ./addons — под сторонние и свои модули.
• restart: unless-stopped. Стек сам поднимется после перезагрузки сервера или сбоя контейнера — без этого после ночного ребута VPS клиент утром встречает мёртвую CRM.

odoo.conf: боевой конфиг

В каталог config кладём файл odoo.conf. Вот минимально-боевой набор параметров — подробный тюнинг воркеров и памяти разберу отдельным разделом ниже:

[options]
; master-пароль менеджера баз данных — сменить и спрятать!
admin_passwd = очень_длинный_мастер_пароль
db_host = db
db_port = 5432
db_user = odoo
db_password = сложный_пароль_БД
; в проде показываем только свою базу и запрещаем менеджер БД
db_filter = ^ваша_база$
list_db = False
; мы за реверс-прокси nginx — доверяем заголовкам X-Forwarded-*
proxy_mode = True
; воркеры и лимиты памяти (подробности — в разделе тюнинга)
workers = 5
max_cron_threads = 1
limit_memory_soft = 2147483648
limit_memory_hard = 2684354560
limit_time_cpu = 600
limit_time_real = 1200

Четыре параметра здесь критичны для безопасности и стабильности, и на них спотыкаются постоянно.

• admin_passwd — это НЕ пароль администратора Odoo. Это мастер-пароль менеджера баз данных: тот, кто его знает, может через веб-интерфейс создать, удалить, скачать или восстановить любую базу на сервере. Дефолтное значение admin — открытая дверь. Меняем на длинную случайную строку и кладём в сейф паролей.
• list_db = False. Выключает выпадающий список баз и страницу менеджера БД на боевом сайте. Без этого любой посетитель видит имена ваших баз и форму управления ими.
• db_filter. Регулярка, ограничивающая, какие базы обслуживает этот сервер. На одну боевую базу ставим строгий якорь ^имя$, чтобы Odoo не пытался угадывать базу по домену.
• proxy_mode = True. Говорит Odoo доверять заголовкам, которые проставляет nginx (реальный IP клиента, протокол https). Без него в письмах и ссылках будут кривые адреса, а Odoo будет считать соединение незашифрованным.

Первый запуск, база и русский язык

Поднимаем стек командой docker compose up -d из каталога проекта. Пока list_db ещё не мешает первичной инициализации, заходим на сервер через nginx (его настроим следующим разделом) и создаём базу: система спросит мастер-пароль (тот самый admin_passwd), имя базы, почту и пароль администратора. Сразу на этом экране можно выбрать язык и страну — ставим русский и Россию, тогда справочники и форматы подтянутся корректно.

После создания базы заходим под администратором и ставим первый прикладной модуль: раздел «Приложения», находим CRM, устанавливаем. Если русский не подхватился на старте — идём в «Настройки» → «Языки» (Settings → Languages), загружаем русский и назначаем его пользователям. После этого возвращаемся в odoo.conf, убеждаемся, что list_db = False и db_filter прописаны, и перезапускаем контейнер приложения. Всё, боевая база создана и заперта от посторонних.

nginx как reverse proxy и HTTPS

Odoo напрямую наружу не выставляют: перед ним ставят nginx, который терминирует TLS, отдаёт статику быстрее и защищает приложение. Здесь же кроется грабля, которая портит жизнь чаще всего, — веб-сокеты.

Два upstream: обычный трафик и веб-сокеты

Идея простая: основной поток запросов nginx проксирует на порт 8069, а всё, что идёт по пути /websocket, — на отдельный порт 8072, где живёт gevent-воркер. Именно этот воркер держит живой чат, всплывающие уведомления и шину обмена сообщениями. Вот боевой server-блок:

upstream odoo {
    server 127.0.0.1:8069;
}
upstream odoochat {
    server 127.0.0.1:8072;
}

server {
    listen 80;
    server_name crm.example.ru;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name crm.example.ru;

    ssl_certificate     /etc/letsencrypt/live/crm.example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/crm.example.ru/privkey.pem;

    # сжатие текстовых ответов
    gzip on;
    gzip_types text/css text/plain application/javascript application/json image/svg+xml;

    # запас под вложения: сканы, КП, картинки товаров
    client_max_body_size 100m;

    proxy_read_timeout 720s;
    proxy_connect_timeout 720s;
    proxy_send_timeout 720s;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # ЖИВОЙ ЧАТ И УВЕДОМЛЕНИЯ: путь /websocket на порт 8072
    location /websocket {
        proxy_pass http://odoochat;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # весь остальной трафик — на порт 8069
    location / {
        proxy_pass http://odoo;
        proxy_redirect off;
    }

    location ~* /web/static/ {
        proxy_cache_valid 200 90m;
        proxy_buffering on;
        expires 864000;
        proxy_pass http://odoo;
    }
}

HTTPS через certbot с плагином nginx

Сертификат Let's Encrypt выпускаем плагином nginx — он сам правит конфиг и, что важнее, корректно продлевается потом:

apt -y install certbot python3-certbot-nginx
certbot --nginx -d crm.example.ru

Про gzip и client_max_body_size отдельно. Сжатие ощутимо ускоряет загрузку интерфейса Odoo — он отдаёт много CSS и JavaScript. А client_max_body_size обязан быть не меньше вашего реального максимального вложения: без него nginx завернёт большой файл ошибкой 413 ещё до того, как запрос дойдёт до Odoo, и менеджер не сможет прикрепить к сделке тяжёлый скан.

Тюнинг под нагрузку: воркеры, память, PostgreSQL

Свежепоставленный Odoo из коробки работает в один поток — для боевого отдела это неприемлемо. Разберём, как настроить многопроцессный режим и подтюнить базу.

Воркеры: почему workers=0 нельзя в прод

По умолчанию Odoo запускается с workers = 0 — это однопроцессный, многопоточный режим, задуманный для разработки. В нём нет отдельного gevent-воркера, а значит, толком не работают веб-сокеты и живые уведомления, и вся нагрузка ложится на один процесс: два менеджера, открывшие тяжёлый отчёт одновременно, уже чувствуют тормоза. В прод такой режим ставить нельзя.

Боевой режим — многопроцессный, число рабочих воркеров считается по формуле:

workers = (число vCPU * 2) + 1

Для машины на два ядра это 5 воркеров, на четыре — 9. Плюс отдельно задаём max_cron_threads — воркер под плановые задачи (рассылки, напоминания, автоматизации); обычно хватает одного. Итого на двухъядерном VPS: workers = 5, max_cron_threads = 1.

Лимиты памяти на воркер

Каждый воркер надо ограничить по памяти, иначе один разросшийся процесс съест RAM и уронит сервер. Odoo сам перезапускает воркер, когда тот переходит мягкий лимит после обработки текущего запроса, и убивает жёстко — при превышении верхней границы. Мои рабочие значения для старта на четырёх гигабайтах:

limit_memory_soft = 2147483648   ; ~2 ГБ — мягкий лимит на воркер
limit_memory_hard = 2684354560   ; ~2.5 ГБ — жёсткий лимит на воркер
limit_time_cpu = 600             ; предел процессорного времени на запрос, сек
limit_time_real = 1200           ; предел реального времени на запрос, сек

Здравый смысл при подборе числа воркеров: считайте, сколько памяти они суммарно могут занять по мягкому лимиту, и оставляйте запас под PostgreSQL и систему. На восьмигигабайтной машине с четырьмя ядрами девять воркеров по два гигабайта в пике — это уже впритык, поэтому на таких конфигурациях я либо снижаю мягкий лимит, либо не гонюсь за максимальным числом воркеров, а балансирую под реальную нагрузку.

PostgreSQL: конкретные значения для VPS на 8 ГБ

База из коробки настроена консервативно и не использует память сервера. Основные параметры правим в postgresql.conf (в нашем стеке — через переменные окружения контейнера db или монтированием конфига). Для машины на 8 ГБ мои рабочие значения:

shared_buffers = 2GB              ; ~25% от RAM
effective_cache_size = 4GB        ; оценка доступного кэша ОС, ~50% RAM
work_mem = 32MB                   ; память на операцию сортировки/хэша
maintenance_work_mem = 256MB      ; под VACUUM и построение индексов
log_min_duration_statement = 500  ; логировать запросы дольше 500 мс

shared_buffers — главный рычаг: около четверти оперативной памяти отдаём под буфер базы, это заметно ускоряет работу с горячими данными. work_mem задаём аккуратно: он выделяется на каждую операцию сортировки, поэтому большие значения при множестве параллельных запросов быстро суммируются в проблему — 32 мегабайта на старте безопасны.

Базовая настройка CRM: 60 минут до передачи клиенту

Система развёрнута и защищена — остаётся сделать из голого Odoo рабочий инструмент отдела продаж. У меня на это уходит примерно час, и вот из чего он складывается.

Команды продаж и воронки

Первым делом заводим команды продаж под реальную структуру отдела: если у клиента есть направления (например, розница и опт или разные продуктовые линейки), каждое получает свою команду с руководителем и набором менеджеров. Команда в Odoo — это и разграничение видимости сделок, и отдельная воронка со своей аналитикой. Не сваливайте всех в одну кучу: разделение с первого дня избавляет от мучительной ретроспективной чистки потом.

Стадии под реальный процесс

Дефолтные стадии воронки Odoo («Новый», «Квалификация», «Предложение», «Выиграно») — это заготовка, а не готовое решение. Сажусь с руководителем отдела и вытаскиваю его реальный процесс: как лид проходит от первого касания до оплаты, какие этапы действительно есть. Переименовываю и достраиваю стадии под этот процесс. Правило простое: стадия должна отражать факт, который можно проверить («выставлен счёт»), а не настроение менеджера («клиент думает»). Тогда воронка показывает правду, а не фантазии.

Входящая почта sales@ и автосоздание лидов

Мощная штука, которую часто пропускают: почтовый алиас команды. Настраиваем так, чтобы письма на адрес вида sales@example.ru автоматически превращались в лиды в нужной воронке. Клиент написал на общий ящик продаж — в CRM тут же появился лид с текстом письма, а ответы менеджера уходят из карточки и подшиваются в переписку. Ничего не теряется в личных почтах сотрудников. Для работы нужен настроенный входящий почтовый сервер в Odoo и проброшенный на алиас ящик.

Пользователи и права

Заводим менеджеров и раздаём права по принципу минимальной достаточности. В Odoo для продаж три ключевых уровня:

• Salesperson (менеджер) — видит и ведёт свои сделки в рамках своей команды. Базовый уровень для рядового продавца.
• Sales Manager (руководитель) — видит сделки всех команд, управляет воронками и стадиями, имеет доступ к сводной аналитике. Даём руководителям направлений.
• Administrator — полный доступ к настройкам системы. Оставляем строго за собой и одним доверенным человеком на стороне клиента; рядовым сотрудникам этот уровень не выдаём никогда.

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

Отключаем лишнее

После установки CRM Odoo активно предлагает подключить смежные приложения и показывает рекомендации. Пока клиенту нужна именно CRM — лишние модули не ставим и убираем навязчивые подсказки: чем меньше в интерфейсе кнопок, ведущих не туда, тем быстрее менеджеры осваиваются. Расширять функциональность (склад, счета, подписки) будем осознанно, когда клиент дозреет, а не потому, что система предложила.

Чек-лист приёмки перед эксплуатацией

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

1. list_db выключен. Открываем в браузере страницу менеджера баз — она должна быть недоступна, а не показывать форму со списком баз. Если список виден, значит list_db = False не применился, вернитесь к odoo.conf и перезапустите контейнер.
2. Мастер-пароль сменён и лежит в сейфе. Значение admin_passwd — не admin и не что-то угадываемое, а длинная случайная строка, сохранённая в вашем менеджере паролей. Напомню: этот пароль позволяет удалить и скачать любую базу.
3. HTTPS с автопродлением. Сертификат валиден, и — обязательно — принудительный тест продления certbot renew --dry-run проходит без ошибок. Именно эта проверка отлавливает грабли с certbot заранее.
4. Бэкап снят и восстановлен. Делаем полный бэкап (дамп базы плюс архив filestore), разворачиваем его на тестовой базе и заходим внутрь. Бэкап, из которого ни разу не восстанавливались, бэкапом не считается — это просто файл, о котором вы думаете, что он вас спасёт.
5. Живые уведомления работают. Открываем CRM двумя пользователями, одним назначаем задачу другому — уведомление должно прилететь без обновления страницы. Не прилетело — чиним блок /websocket в nginx.
6. Отклик под нагрузкой. Просим 10 сотрудников одновременно поработать в системе (или гоняем лёгкий нагрузочный тест) и смотрим, что интерфейс держит отклик в разумных пределах, а воркеры не упираются в лимиты памяти. Это выявляет недобор ресурсов до того, как его выявят пользователи.

Сколько стоит и сколько занимает

Финальный вопрос, который волнует любого руководителя: во сколько всё это обойдётся по деньгам и времени. Отвечаю честно, из практики.

Хронометраж внедрения

Разложу по этапам, как это выглядит в реальном проекте:

• Развёртывание — один вечер. Подготовка сервера, docker compose, nginx, TLS, создание базы и установка CRM по этой инструкции занимают несколько часов. К концу вечера у вас работающая, защищённая CRM на своём домене.
• Настройка процессов — 2–3 дня. Команды, воронки, стадии под реальный процесс, права, почтовые алиасы, перенос текущих клиентов. Это не про технику, а про то, чтобы система отражала то, как компания действительно продаёт.
• Обучение — около недели. Показать менеджерам, где что лежит, приучить вести сделки в системе, а не в голове и в блокноте. Неделя мягкого сопровождения — и отдел работает в CRM как в привычном инструменте.

TCO против облачной CRM

Прикинем совокупную стоимость владения за год на отдел в 20 человек. Облачные CRM берут абонентскую плату за каждого пользователя ежемесячно, и на два десятка сотрудников это выливается в весьма ощутимую сумму в год — причём растущую с каждым новым человеком и с каждым повышением тарифа.

Self-hosted Odoo Community — это лицензия LGPLv3 без платы за пользователей и без лимита на их число. Ваши прямые расходы — только VPS: те самые 1500–3000 ₽ в месяц, то есть порядка 20–36 тысяч рублей в год за сервер целиком, независимо от того, 20 на нём человек или 50. Плюс разовые работы по внедрению. На горизонте года, а тем более двух-трёх, разница с помесячной оплатой за каждого пользователя становится кратной, и чем больше отдел, тем сильнее перевес в сторону своего сервера.

Что остаётся на стороне клиента

Честно о плате за независимость: при самостоятельной установке на клиенте остаётся эксплуатация. Это обновления версий, регулярные бэкапы и проверка их восстановлением, мониторинг свободного места и нагрузки, продление сертификатов, реакция на инциденты. Ничего запредельного, но это работа, которую кто-то должен делать — либо ваш системный администратор, либо подрядчик.

Если разворачивать и сопровождать Odoo самостоятельно некогда или некому — это ровно наша работа. В ITfresh мы разворачиваем Odoo 19 на вашем VPS под ключ: сервер, Docker, PostgreSQL, nginx с правильным websocket, тюнинг под нагрузку, настройка CRM под ваш процесс, чек-лист приёмки и передача. А дальше берём на абонентское сопровождение: обновления, бэкапы, мониторинг. Собственные серверы в дата-центре МТС, 15+ лет опыта с юрлицами до 50 рабочих мест. Пишите в Telegram @ITfresh_Boss или звоните +7 903 729-62-41 — развернём и настроим.