Docker для внутренних сервисов: поднимаем GitLab, Nextcloud или Wiki без выделенного DevOps

Три года назад я бы сказал: Docker — это для больших команд с выделенным DevOps-инженером на 200 тысяч в месяц. Не для бухгалтерии на 15 человек. Не для юрфирмы на 12 рабочих мест. Ошибался. Сейчас мы разворачиваем корпоративные сервисы через Docker почти каждому клиенту среднего размера — и занимается этим обычный сисадмин после одного дня практики.

Почему не просто установить программу на сервер, как раньше

У нас есть клиент — производственная компания, 40 человек, Подмосковье. Три года назад попросили поднять Nextcloud для обмена файлами внутри команды и с подрядчиками. Поставили на Ubuntu 20.04, настроили Apache, PHP 7.4, MariaDB. Всё работало. Через год решили добавить GitLab для отдела разработки. Оказалось, что GitLab хочет другую версию PostgreSQL и конфликтует с настройками PHP под Nextcloud. Полдня разбирались, сломали и то, и другое. Восстанавливали из резервной копии трёхнедельной давности. Три недели данных потеряли — просто в мусор.

Вот именно от этого Docker и спасает. Каждый сервис живёт в своём изолированном контейнере со своими зависимостями. Nextcloud не знает, какая версия Python нужна GitLab. GitLab не знает, что Nextcloud хочет PHP 8.2. Они просто не пересекаются. Это не магия — изоляция на уровне ядра Linux через namespaces и cgroups. Детали нам знать необязательно. Достаточно знать, что работает и не конфликтует.

Есть и второй плюс, который я лично ценю больше всего. Переносимость. Переезжаете с одного сервера на другой — берёте docker-compose.yml, берёте папку с данными, переносите на новую машину и запускаете. Без переустановки PHP. Без настройки Apache с нуля. Без боли. Один раз настроил — повторяешь за пять минут. Для компаний, где сисадмин работает на полставки или вообще на аутсорсе, это бесценно.

Что нужно для старта: железо, операционная система и немного терпения

Начну с железа — здесь многие делают ошибку в обе стороны: берут слишком слабое или переплачивают. Для Nextcloud на 20 пользователей хватит 2 ядра CPU и 4 ГБ RAM. Для GitLab — минимум 4 ГБ RAM, лучше 8, иначе будет тормозить при каждом git push. Для Wiki (BookStack или Wiki.js) — 1–2 ГБ RAM за глаза. Хотите поднять всё сразу на одном сервере? Берите 8 ГБ RAM минимум. На рынке VPS такая конфигурация у Selectel или Timeweb обходится в 1500–2500 рублей в месяц. Можно поднять и на физическом сервере в офисе, если есть подходящее железо.

По операционной системе — рекомендую Ubuntu 22.04 LTS. Не потому что лучшая, а потому что на неё написано 90% документации и все примеры в интернете. Уже стоит Debian 12 — тоже отлично, Docker устанавливается так же. Windows Server 2019 и 2022 с Docker тоже работают, но есть нюансы: Linux-контейнеры на Windows гоняются через WSL2, производительность чуть хуже, некоторые образы ведут себя странно с правами на файлы. Если есть выбор — берите Linux. Без вариантов.

Ещё один момент. Белый IP. Хотите заходить в свои сервисы через интернет — нужен либо белый IP на сервере (VPS его даёт автоматически), либо домен с нужной DNS-записью, либо Cloudflare Tunnel. Последний вариант пробрасывает доступ без белого IP вообще. Для офисного сервера за NAT-провайдером Cloudflare Tunnel — почти единственный нормальный вариант без покупки статического адреса за 500–1000 рублей в месяц.

Устанавливаем Docker и Docker Compose: один раз и правильно

Установка Docker на Ubuntu — буквально четыре команды. Делать из этого квест не буду. Важный момент: устанавливать Docker нужно из официального репозитория Docker Inc., а не из стандартного репозитория Ubuntu. В Ubuntu 22.04 там лежит старая версия под именем docker.io — работает, но не поддерживает новый синтаксис Compose и часть современных возможностей. Добавляем официальный репозиторий через apt, устанавливаем docker-ce и сразу docker-compose-plugin. Это важно: Docker Compose v2 — плагин к Docker CLI, а не отдельная утилита. Команда теперь выглядит как docker compose (без дефиса), а не docker-compose.

После установки — одно действие, которое большинство забывает. Добавьте своего пользователя в группу docker командой usermod -aG docker $USER, потом перелогиньтесь. Иначе придётся каждый раз писать sudo перед каждой docker-командой. Мелочь, но нервы сохраняет. Проверяете результат командой docker run hello-world — если увидели приветственное сообщение, всё встало как надо.

Теперь про docker-compose.yml — это главный файл, с которым будете работать постоянно. По сути текстовый файл в формате YAML: какие контейнеры запускать, какие порты открывать, куда монтировать данные с хоста, какие переменные окружения передавать. Выглядит страшно поначалу. На деле — просто структурированный список настроек. Берёте готовый пример из официальной документации нужного сервиса, меняете пароли и пути к данным — и запускаете. Для большинства популярных сервисов официальные compose-файлы уже есть на Docker Hub или в документации проекта.

Nextcloud: корпоративное облако за один вечер

Nextcloud — самый популярный сервис, который мы разворачиваем клиентам через Docker. Свой Dropbox, только данные у вас, а не где-то на серверах американской компании. Синхронизация файлов, общий доступ по ссылке, календари, контакты, видеозвонки через Nextcloud Talk. У нас есть клиент — медклиника на 25 человек. Через Nextcloud шарят шаблоны документов, расписания и сканы выписок. Раньше всё это расходилось через WhatsApp-группу. Стало намного цивилизованнее — и безопаснее.

Compose-файл для Nextcloud в базовом варианте — три контейнера: сам Nextcloud, база данных MariaDB и Redis для кэширования сессий. Плюс отдельный nginx-proxy, если нужен SSL. Данные Nextcloud монтируются в папку на хосте — обычно что-то вроде /opt/nextcloud/data. Важно понимать: файлы хранятся не внутри контейнера, а на хосте. Контейнер можно удалить и пересоздать — данные никуда не денутся.

Главная засада при первом запуске Nextcloud — права доступа на файлы. Nextcloud внутри контейнера работает от пользователя www-data с UID 33. Папка на хосте принадлежит root — получите ошибку прав при первом старте. Решается командой chown -R 33:33 /opt/nextcloud/data перед запуском. Звучит как магия, но это нужно просто один раз записать и запомнить. Половина вопросов на форумах про «Nextcloud не запускается» — именно про это.

GitLab или Gitea: хранилище кода для тех, у кого есть разработчики

Есть хоть один разработчик в компании — нужен git-репозиторий. GitHub бесплатен для открытых проектов, но для приватного корпоративного кода придётся либо платить (от 4 долларов в месяц на человека в Team-тарифе, это около 370 рублей по текущему курсу), либо поднимать своё. GitLab Community Edition — бесплатный, с CI/CD пайплайнами, issue tracker, merge requests и своей Wiki из коробки. Полноценная замена GitHub Enterprise, только у вас на сервере. Звучит здорово.

Но есть нюанс. GitLab — тяжёлый. Очень. Минимум от разработчиков — 4 ядра и 4 ГБ RAM только для GitLab. При 2 ГБ RAM запустится, но будет тормозить и периодически падать с OOM-ошибкой. Был у нас клиент — небольшая веб-студия, 6 разработчиков. Попробовали GitLab на VPS за 800 рублей в месяц с 2 ГБ RAM. Результат предсказуемый. Переехали на Gitea. Это лёгкая альтернатива, написанная на Go: потребляет 100–300 МБ RAM, запускается за секунды. Полноценного встроенного CI/CD как в GitLab нет, но для хранения кода, code review и базового трекера задач — вполне.

Критерий выбора простой. Больше 10 разработчиков, нужен полноценный CI/CD из коробки — берите GitLab на сервере от 8 ГБ RAM. Команда маленькая, важна скорость и дешевизна — Gitea. Compose-файл для Gitea — буквально 20 строк. У GitLab чуть сложнее: там нужно настроить SSH на нестандартный порт, иначе он конфликтует со стандартным SSH хоста и вы потеряете доступ к серверу. Один раз сам на это попался — теперь предупреждаю всех.

Wiki для внутренней базы знаний: BookStack, Wiki.js или DokuWiki

База знаний внутри компании — одна из тех вещей, которые «надо бы сделать», но откладываются годами. Регламенты в Word-файлах на расшаренном диске. Инструкции в голове у конкретного сотрудника. Ответы на одни и те же вопросы по десять раз в день. Знакомо? У нас есть клиент — небольшая юрфирма, три партнёра и восемь юристов. Шаблоны договоров, регламенты, инструкции по системам — всё лежало в папках с непонятными названиями. Потратили один день на развёртывание BookStack и перенос документов. Через месяц один из партнёров написал, что это лучшее, что они сделали за год.

По выбору движка. DokuWiki — самый простой: работает без базы данных вообще, файлы хранятся как обычный текст. Для небольших команд и несложных задач — идеально. Но выглядит олдскульно и плохо масштабируется на большие объёмы. Wiki.js — современный, красивый, поддерживает и markdown, и WYSIWYG-редактор, умеет авторизацию через Active Directory и Google OAuth. Сложнее в первоначальной настройке. BookStack — золотая середина. Структура «Полка — Книга — Глава — Страница» интуитивно понятна любому, кто хоть раз открывал оглавление. Авторизация через LDAP есть. Compose-файл на 30 строк, запускается с первого раза.

Мой личный выбор для клиентов без технических команд — BookStack. Видел, как его начинают использовать люди, которые вообще не понимают, что такое wiki. Разбирались за 20 минут без обучения. Wiki.js рекомендую, если команда технически грамотная и важен первоклассный markdown. DokuWiki — когда сервер слабый или нет желания возиться с базой данных.

Бэкапы, обновления и мониторинг: то, о чём обычно вспоминают после падения

Поднять Docker-сервис и оставить без присмотра — плохая идея. Не потому что нестабильный. Потому что контейнеры надо обновлять, данные надо бэкапить, иногда что-то идёт не так и надо быстро разобраться. Начнём с бэкапов. Данные всех сервисов хранятся в папках на хосте — в bind mount volumes. Если монтировали в /opt/nextcloud, /opt/gitea, /opt/bookstack — бэкап это просто копирование этих папок. Rsync на удалённый сервер, tar-архив на отдельный диск. Если уже есть Veeam Agent for Linux — прекрасно работает и с этим сценарием, папки с данными контейнеров копируются как обычные файлы.

Обновления образов. Время от времени выходят новые версии Nextcloud, GitLab, BookStack. Обновление в Docker выглядит так: docker compose down, docker compose pull — скачиваем свежие образы с Docker Hub, docker compose up -d — запускаем с новыми. Всё. Никакой возни с пакетами, зависимостями и конфигурационными файлами. Раньше обновление Nextcloud вручную у меня занимало час и заканчивалось нервным перекуром. Сейчас — пять минут. Одно правило: перед обновлением делайте бэкап базы командой docker compose exec db mysqldump -u root -pВАШ_ПАРОЛЬ nextcloud > backup.sql. На случай если что-то пойдёт не так.

И последнее — мониторинг. Рекомендую Uptime Kuma. Docker-контейнер, лёгкий, с красивым веб-интерфейсом. Пингует ваши сервисы каждые 60 секунд, отправляет уведомления в Telegram, если что-то упало. Настраивается за 15 минут. Стоит ноль рублей. Один раз поставил клиенту — он узнал что Nextcloud упал раньше, чем кто-то из пользователей успел написать «ничего не работает». Приятное ощущение. И одна просьба: не запускайте docker system prune без понимания что эта команда делает. Она удаляет неиспользуемые образы и тома — если что-то назвали не так, можно удалить нужное.

Частые вопросы

Нужен ли Linux, или Docker работает на Windows Server?
Docker работает и на Windows Server 2019/2022, но с оговорками. Linux-контейнеры на Windows запускаются через WSL2 — это дополнительный слой, который немного снижает производительность и иногда создаёт проблемы с правами доступа к файлам. Для продуктивной среды с несколькими сервисами рекомендую Linux: Ubuntu 22.04 LTS или Debian 12. Если в офисе только Windows-серверы и Linux-навыков нет совсем — Docker Desktop на Windows Server тоже вариант, но готовьтесь к нюансам с путями и правами.

Как настроить HTTPS, если нет белого IP?
Три варианта. Первый — Cloudflare Tunnel (бесплатно): устанавливаете агент cloudflared на сервер, создаёте туннель в панели Cloudflare, получаете адрес вида yourapp.your-domain.com с автоматическим SSL. Белый IP не нужен вообще. Второй — купить статический IP у провайдера (500-1500 рублей в месяц) и использовать Let's Encrypt через контейнер Certbot или traefik с автоматическим получением сертификата. Третий — самоподписанный сертификат для доступа только внутри офисной сети. Для большинства небольших компаний Cloudflare Tunnel — оптимальный выбор.

Сколько сервисов можно запустить на одном сервере?
Зависит от RAM. Ориентируйтесь так: Nextcloud с MariaDB и Redis — около 500 МБ RAM в покое. Gitea — 150-300 МБ. BookStack — 200-300 МБ. GitLab Community Edition — 2-4 ГБ. Uptime Kuma — 100 МБ. На сервере с 8 ГБ RAM реально держать Nextcloud, Gitea, BookStack и Uptime Kuma с запасом. GitLab лучше на отдельном сервере или хотя бы 8 ГБ RAM только под него. По CPU большинство сервисов почти ничего не потребляют в покое — нагрузка возникает только в момент запроса.

Что делать, если контейнер упал и не поднимается?
Первым делом — docker compose logs имя_сервиса. Там почти всегда написано что именно пошло не так: нет прав на папку, неверный пароль базы данных, занят порт. Если контейнер даже не стартует — запустите docker compose up без флага -d, то есть в интерактивном режиме: вывод ошибок пойдёт прямо в терминал. Чуть реже нужно зайти внутрь контейнера командой docker compose exec имя_сервиса bash и посмотреть что там происходит изнутри. В 90% случаев проблема решается за 10-15 минут именно через логи.