Outline для команды: что нужно кроме VPS для входа и хранения вложений

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

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

Карта: что на самом деле входит в «установку Outline»

Официальный пример конфигурации Outline (.env.sample в репозитории проекта) удобен тем, что показывает состав системы без маркетинга. В нём есть параметры PostgreSQL, параметры Redis, настройки файлового хранилища, параметры провайдеров входа и настройки SMTP. Это не перечень «желательных дополнений», а перечень того, о чём приложение будет спрашивать при старте и в работе.

Разложим это по ролям:

• Приложение Outline — сам веб-сервис, который принимает запросы пользователей.
• PostgreSQL — хранит структурированные данные: документы, коллекции, пользователей, права.
• Redis — вспомогательное хранилище, к которому приложение обращается наряду с базой.
• Провайдер входа — внешняя система, которая подтверждает, что человек тот, за кого себя выдаёт.
• Хранилище файлов — место для вложений и изображений: локальный диск или S3-совместимый сервис.
• SMTP — канал для транзакционных писем и входа по почте.

Теперь отметим, что из этого списка действительно приезжает вместе с арендой сервера. Приезжает вычислительная машина: процессор, память, диск, root-доступ. В публичном предложении VPS MAATRIX это NVMe, AMD EPYC и root-доступ. База и Redis вы разворачиваете сами на этом же сервере (или выносите отдельно), а вот провайдер входа, почтовый канал и, при выборе S3, объектное хранилище — это зависимости другого рода. Их придётся либо завести у третьих сторон, либо поднять самостоятельно, и тогда они сами потребуют ресурсов и внимания. Аренда сервера не включает их автоматически.

Про ресурсы самого приложения, памяти и запас под базу мы отдельно писали в материале «Сколько RAM нужно для Outline». Здесь же тема другая: не сколько нужно железа, а что нужно кроме него.

Вход: выбираем способ и ищем владельца

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

В конфигурации присутствуют параметры провайдеров, среди них OIDC. Это универсальный протокол для внешней аутентификации: Outline выступает клиентом, а подтверждение личности выполняет отдельная система. Практическое следствие важнее технического: у этой системы есть владелец, и это почти никогда не тот, кто арендует VPS.

Три разных мира, три разных владельца

Условно варианты выглядят так.

Таблица не ранжирует варианты, она показывает, с кем придётся договариваться. Если ваша команда уже живёт внутри каталога с единым входом, OIDC почти наверняка проще: владельцем станет человек, который и так управляет учётными записями. Он решает, кто в принципе получит доступ, и увольнение сотрудника уйдёт в Outline через ту же дверь, что и во все остальные системы. Это рассуждение, а не обещание продукта: насколько быстро завершится уже открытая сессия после отключения учётной записи, зависит от конкретной настройки, и безусловного мгновенного отзыва всех сессий обещать не стоит.

Отдельно про редакцию. Набор способов входа в разных редакциях и сборках продукта может отличаться, а пример конфигурации из основной ветки репозитория не служит гарантией того, что конкретная функция доступна в той версии, которую вы поставите. Поэтому, если вам нужен определённый протокол, например корпоративный SAML, не предполагайте его наличие и бесплатность по аналогии с OIDC: сверьтесь с описанием вашей редакции и версии до заказа сервера. С OIDC такая проверка тоже не лишняя, но именно он присутствует в официальном примере конфигурации.

Что понадобится на практике при OIDC

Независимо от провайдера, договорённость обычно сводится к нескольким предметным вещам:

1. Публичный адрес Outline с HTTPS. Провайдер вернёт пользователя именно туда, поэтому адрес должен быть окончательным, а не «временным на IP».
2. Адрес возврата, зарегистрированный у провайдера. Если он не совпадёт с тем, который использует приложение, вход закончится ошибкой на стороне провайдера, и в логах Outline вы можете ничего интересного не увидеть.
3. Идентификатор клиента и секрет клиента, выданные провайдером.
4. Адреса конечных точек провайдера, которые приложение должно уметь открыть с вашего сервера.

Последний пункт часто упускают. Вход — это не только «пользователь идёт к провайдеру». Приложение само обращается к провайдеру с сервера. Если провайдер находится за корпоративным периметром, вашему VPS нужен до него сетевой путь. Это вопрос расположения, а не удачи: прежде чем выбирать локацию сервера из списка (в публичном предложении названы UK, US, RU и FR), убедитесь, что провайдер входа доступен оттуда, где будет жить приложение. Доступность стороннего сервиса из конкретной страны нельзя считать само собой разумеющейся, её проверяют на месте.

Куда положить секрет клиента

Секрет клиента — это то, что нельзя оставлять лежать где попало. Если вы разворачиваете Outline через Docker Compose, у Compose есть механизм секретов: документация Docker Compose описывает, что доступ к секрету выдаётся конкретному сервису явно, а сам секрет монтируется в контейнер файлом. Это снижает вероятность случайной утечки через вывод переменных окружения и через чужие контейнеры в том же проекте, которым вы секрет не выдавали.

Но здесь важна трезвая оговорка, которую документация тоже делает: передача файлом не означает, что исходный файл зашифрован, и не лишает владельца хоста доступа. Тот, у кого root на сервере, прочитает и сам файл, и смонтированный секрет. Для вашего VPS это значит простую вещь: секрет защищён настолько, насколько защищён доступ к самому серверу. Плюс механизма — аккуратная выдача сервисам, а не криптографическая защита от администратора машины. Кроме того, описанный механизм относится к контейнерам Linux, что для VPS с Linux обычно как раз нужный случай.

Какие значения стоит считать секретными в этой конфигурации: секрет клиента OIDC, пароль SMTP, пароль базы, ключи доступа к S3 (если вы его выберете). Часть значений приложение ждёт в переменных окружения, поэтому на практике нужно проверить, как именно ваша версия образа умеет читать секрет из файла, и не придумывать это по аналогии. Если такого чтения нет, остаётся обычная переменная окружения со всеми её свойствами, и тогда доступ к серверу и к файлам проекта нужно ограничивать ещё строже.

Вложения: диск или S3, и по какому признаку выбирать

Теперь второй путь: пользователь вставляет скриншот в документ и позже открывает его. Из документированных фактов следует важное для планирования: файловое хранилище может быть либо локальным, либо S3-совместимым. При локальном варианте вложения и изображения сохраняются на диске. Никакого обязательного объектного хранилища нет, и считать S3 единственным путём было бы ошибкой.

Поэтому правильный вопрос не «как подключить S3», а «что у нас за файлы и кто будет за ними следить».

Local: просто, пока вы готовы обслуживать диск

Локальное хранение хорошо тем, что в схеме меньше зависимостей: нет внешнего сервиса, ключей доступа и отдельной сетевой точки отказа. Файлы лежат там же, где работает приложение. Для небольшой команды, у которой вложения в основном скриншоты и небольшие PDF, это разумная отправная точка.

Цена этой простоты в том, что диск сервера теперь хранит и систему, и базу, и файлы. Вспомним про ресурсы: у линейки VPS MAATRIX диски разные. Ba — 40 ГБ NVMe, Uab — 80 ГБ, Heka — 160 ГБ, Maat — 240 ГБ, Djed — 320 ГБ. Эти цифры описывают конфигурацию, но не обещание ёмкости под вашу нагрузку, поэтому планировать нужно от своих данных, а не от красивого числа в таблице тарифов.

Условный расчёт, чтобы увидеть логику (числа выдуманы для примера, подставьте свои). Допустим, в команде 20 человек, и каждый добавляет в среднем 15 вложений в месяц. Если средний файл занимает 1,5 МБ, то за месяц набегает около 450 МБ, а за год чуть больше 5 ГБ. Для диска на 80 ГБ это терпимо. Но если команда регулярно прикладывает презентации и записи экрана, средний размер вырастает до 20 МБ, и тот же поток даёт уже около 6 ГБ в месяц и порядка 70 ГБ за год. Диск на 80 ГБ в таком сценарии не выдержит вместе с системой и базой. Разница между двумя сценариями в десятки раз, и она определяется не количеством пользователей, а типом файлов. Поэтому прежде чем выбирать тариф, спросите у команды, что именно они будут вкладывать.

У локального хранения есть и менее заметные последствия:

• Файлы привязаны к одному серверу. Если вы решите переехать, их придётся переносить вместе с приложением и базой, причём согласованно: документ в базе ссылается на файл, который должен оказаться на новом месте.
• Резервная копия документов без файлов — это документы с «битыми» картинками. Копировать нужно и базу, и каталог вложений, а автоматические копии на стороне хостинга для всех тарифов в публичных фактах не заявлены, так что план копирования ваш собственный.
• Рост вложений съедает место, нужное базе. Заполненный диск ломает не только загрузку файлов, но и сам PostgreSQL.

S3-compatible: когда файлы живут отдельно от сервера

S3-совместимое хранилище разделяет два вопроса: где работает приложение и где лежат файлы. Объём вложений перестаёт зависеть от диска VPS, а перенос приложения на другой сервер не требует таскать каталог с файлами: достаточно указать то же хранилище. Для команды с тяжёлыми вложениями или с планами менять инфраструктуру это серьёзное преимущество.

Платой становятся новые сущности: бакет, ключи доступа, правила доступа к объектам, адрес хранилища и его сетевая доступность с вашего сервера. И новый вид отказа: приложение работает, документы открываются, а картинки не грузятся, потому что ключ истёк или бакет недоступен. Кроме того, у S3-совместимого хранилища появляется свой владелец и свой счёт, а значит, отдельный вопрос, кто за него отвечает.

Есть и деталь, которую легко упустить: пользователь открывает вложение не через ваш сервер «в вакууме», а по пути, который определяет схема хранения. При локальном варианте браузер получает файл от приложения. При внешнем хранилище участвует ещё один адрес, и он должен быть доступен тому, кто открывает документ, а не только серверу приложения. Если хранилище находится во внутренней сети, а читают документы из дома, схема развалится. Проверяйте доступность именно с точки зрения пользователя.

Как выбрать без догм

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

Письма: что делает SMTP и когда без него не обойтись

Третий путь — письмо. В конфигурации Outline SMTP нужен для транзакционных писем и для входа по почте. Транзакционные письма — это уведомления и приглашения, то есть то, что приложение отправляет в ответ на действие. Если вы делаете ставку на OIDC, вход по почте вам может быть не нужен. Но приглашения и уведомления всё равно захотят письма, так что SMTP не исчезает из плана, даже когда вход идёт мимо него.

Если же вход по почте у вас основной (например, у команды нет каталога учётных записей), SMTP становится критичной зависимостью в буквальном смысле: письмо со ссылкой не дошло, и человек не может войти. Здесь важно не путать «приложение отправило» и «пользователь получил». Между ними почтовый провайдер, репутация домена отправителя и фильтры получателя.

Что нужно подготовить:

• Почтовый сервис или собственный сервер отправки с доступом по SMTP: адрес, порт, логин и пароль.
• Адрес отправителя на домене, которым вы владеете и можете управлять его DNS-записями, иначе письма рискуют оседать в спаме.
• Уверенность, что ваш VPS может подключаться к SMTP-серверу. Некоторые сети ограничивают исходящую почту, и это стоит выяснить до того, как вы поймёте это по молчанию приложения.

Собственный почтовый сервер на том же VPS возможен, но это отдельный проект с отдельным обслуживанием и вопросами репутации, и для запуска Outline его обычно разумнее заменить внешним каналом отправки.

Схема трёх путей

Сведём всё в одну карту. Для каждого пути видно, через какие зависимости он проходит и где обрывается.

Все три пути объединяет одно: каждый зависит от звена, которое находится вне VPS или хотя бы вне самого приложения. И у каждого свой тип отказа, который выглядит по-разному. Обрыв входа виден сразу и громко. Обрыв вложений коварнее: документы открываются, пропадают только картинки. Обрыв писем самый тихий: приложение считает, что всё отправило.

Как проверять зависимости: глазами приложения и глазами человека

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

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

Практичная последовательность такая:

1. Убедиться, что база и Redis доступны приложению: без них оно даже не начнёт обслуживать запросы.
2. Пройти вход под обычной учётной записью, не под той, которой вы настраивали провайдера. Администратор часто обладает правами, которые маскируют ошибки настройки.
3. Создать документ, вставить изображение, выйти, зайти снова и открыть документ. Файл должен пережить не только загрузку, но и повторное открытие.
4. Отправить приглашение на внешний адрес и убедиться, что письмо пришло, а не лежит в спаме.
5. Перезапустить приложение и повторить пункты 2 и 3: проверка, что настройки и файлы не живут только в памяти контейнера.

Последний пункт особенно важен при локальном хранении. Если каталог вложений не вынесен за пределы контейнера, файлы исчезнут при пересоздании контейнера, а база по-прежнему будет на них ссылаться. Эта ошибка проявляется не сразу, а через первое обновление.

Что решить до заказа сервера

Большая часть решений, влияющих на выбор VPS, принимается не про сервер. Тариф определяется вашими ответами на несколько вопросов, и порядок здесь действительно имеет значение:

• Какой способ входа будет основным и у кого лежат его настройки? От этого зависит, нужна ли вам отдельная служба входа и нужен ли SMTP как критичная часть.
• Сколько и каких файлов команда будет вкладывать? От этого зависит, хватит ли диска и нужен ли внешний бакет. Для небольшой команды с лёгкими вложениями и Ba, и Uab могут оказаться разумными по диску, но окончательное решение принимается по вашему расчёту и по реальной нагрузке, а не по таблице.
• Откуда сервер будет обращаться к провайдеру входа и SMTP? От этого зависит выбор локации из доступных.
• Какая редакция и версия Outline вам нужна и содержит ли она нужный способ входа?

Когда эти ответы есть, заказ сервера превращается в техническую формальность. Оплата картой РФ или СБП и создание VPS примерно за пару минут после оплаты — это уже последний шаг, а не первый. Root-доступ позволит развернуть приложение, базу, Redis и обратный прокси так, как вы запланировали.

Первый прогон: от стартовой страницы до документа

Вернёмся к исходному экрану, на котором нет кнопки. Допустим, вы потратили время на подготовку: провайдер входа зарегистрировал Outline как клиента, секрет лежит там, где доступен только нужному сервису, хранилище выбрано, SMTP подключён. Теперь первый настоящий прогон выглядит иначе.

Коллега открывает адрес Outline в обычном окне браузера. На странице есть кнопка входа через провайдера. Он нажимает её, попадает на страницу своей организации, подтверждает личность и возвращается на ваш адрес уже с открытой сессией. Это первый путь, и он закончился там, где должен.

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

Только после этого можно считать, что Outline установлен. Не когда открылась стартовая страница и не когда контейнеры показали статус «работает», а когда живой человек прошёл весь путь до документа и не споткнулся ни об один из внешних сервисов. Сервер дал для этого машину; всё остальное вы подготовили заранее.