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 минут именно через логи.