Хранилище инструментов и артефактов на TrueNAS: пошаговая настройка в 2026 году

TrueNAS закрывает задачу хранения инструментов и артефактов на одном узле: ZFS отвечает за целостность и снапшоты, SMB и NFS дают сетевой доступ, встроенные задачи репликации и Cloud Sync выгружают копии на второй сервер или в S3.

Рабочий сценарий выглядит так. Датасет tank/tools держит скрипты развёртывания и утилиты, tank/artifacts принимает сборки Jenkins и GitLab CI, tank/docker отдаёт слои образов, tank/backups хранит резервные копии конфигураций. Доступ по SMB получают рабочие станции, по NFS - Linux-раннеры и серверы сборки. Снапшоты снимаются по расписанию, копии уходят на второй NAS и в облако.

В 2026 году живут две ветки: TrueNAS SCALE на Linux и CORE на FreeBSD. Новую установку ставят на SCALE, CORE остаётся для систем, которые уже работают на FreeBSD и пока не готовы к переезду.

Что даёт TrueNAS как хранилище инструментов и артефактов

Один узел TrueNAS с пулом ZFS решает четыре задачи: хранит файлы, раздаёт их по SMB и NFS, снимает снапшоты без остановки сервисов и отправляет копии на второй сервер или в облако. Команде из пяти DevOps-инженеров этого хватает, чтобы держать 3 ТБ артефактов сборки, 400 ГБ Docker-образов и набор скриптов развёртывания.

Выгоды измеримы. Снапшот датасета на 2 ТБ создаётся за доли секунды, потому что ZFS копирует указатели, а не блоки. Сжатие lz4 возвращает 20-40% ёмкости на текстовых файлах, логах и бинарниках с повторами. ACL NFSv4 раздают права конкретным пользователям и группам, включая сервисные учётные записи раннеров. Репликация переносит только изменившиеся блоки, и ночная копия 3 ТБ проходит за минуты.

Границы применимости тоже известны. TrueNAS не заменяет объектное хранилище для CI с тысячами параллельных загрузок: один узел и его диски ограничивают число одновременных операций. Дедупликацию на датасете с артефактами включать не стоит, таблица DDT съест RAM, которую ZFS отдала бы под кеш ARC. Пул, собранный без плана, потом приходится пересобирать вместе с данными.

TrueNAS SCALE или CORE: что выбрать в 2026 году

SCALE работает на Linux, поэтому контейнеры Docker и виртуальные машины Incus запускаются нативно, а CI-образы переносятся на NAS без прослоек. Стабильная ветка на сентябрь 2026 года - SCALE 25.04, предыдущий релиз 24.10 (Electric Eel) ещё получает исправления. CORE на FreeBSD остаётся надёжной системой, но 13.x - последняя крупная ветка: новые приложения и функции выходят только для SCALE.

Для новой установки берите SCALE. Переезд с CORE на SCALE возможен и почти всегда делается через репликацию пула, но требует планирования: часть плагинов CORE в SCALE отсутствует, а их замену подбирают заранее.

Пример из практики: команда из пяти DevOps-инженеров развернула SCALE 25.04 на одном сервере, джобы Jenkins и GitLab CI пишут артефакты в /mnt/tank/artifacts через NFS, а сами раннеры забирают утилиты из /mnt/tank/tools. Месячный прирост данных держится в районе 250 ГБ, снапшоты и репликация не требуют ручных действий.

Требования к железу под ZFS-хранилище

RAM определяет скорость чтения. ZFS кеширует в ARC метаданные и горячие блоки; рабочее правило - 1 ГБ памяти на 1 ТБ ёмкости пула, минимум 8 ГБ на любую инсталляцию. Для массива на 64 ТБ это 64 ГБ. ECC-память полезна, но обязательной не является: ZFS проверяет контрольные суммы блоков на дисках независимо от типа памяти.

Диски разделяют по назначению. Данные кладут на HDD в RAIDZ2 при шести дисках и больше, mirror берут для двух-четырёх дисков. NVMe отдают под метаданные, SLOG для синхронной записи (NFS sync, базы данных) и L2ARC для чтения, когда RAM не вмещает рабочее множество. Как посчитать размер ARC и оценить пользу L2ARC, разобрано в руководстве по настройке кеширования в TrueNAS.

Готовая сборка под артефакты: 64 ГБ RAM, 8x8 ТБ HDD в RAIDZ2, 2x1 ТБ NVMe в mirror под SLOG и метаданные, коннектор 10 GbE, UPS. Такой узел отдаёт 600-900 МБ/с последовательного чтения по NFS при синхронной записи через SLOG.

Создание пулов ZFS и датасетов под инструменты

Порядок действий в веб-интерфейсе: Storage, затем Create Pool, выбираете диски, тип RAIDZ2 для массива из шести и более накопителей, задаёте имя пула (в примерах tank), подтверждаете создание. Пул получает шифрование и автотримминг по умолчанию, менять эти опции на работающей системе позже дорого.

Дальше создаются датасеты: tank/tools, tank/artifacts, tank/tools и tank/backups. Для каждого указываете recordsize, compression, quota и ACL type. Перед работой сверьтесь с базовым руководством по настройке TrueNAS от установки до SMB и NFS, чтобы не пропустить сетевые параметры. Проверка результата: zpool status показывает состояние всех дисков, zfs list выводит список датасетов с занятым и доступным местом.

Параметры датасетов: recordsize, compression, quota

recordsize задаёт размер блока для файлов. Значение 128K подходит для скриптов, конфигураций и мелких утилит, 1M ускоряет потоковую запись крупных сборок и образов, 16K нужен базам данных, которые живут на NFS. compression=lz4 даёт баланс скорости и сжатия и подходит почти везде, zstd выжимает больше места на текстовых архивах ценой нагрузки на CPU.

quota ограничивает датасет вместе со снапшотами, refquota считает только сами данные и оставляет снапшотам свободу расти. Для артефактов удобнее refquota: снапшоты не блокируют запись при заполнении. Помните, что изменившиеся блоки удерживаются снапшотами и продолжают занимать место до истечения retention.

Разделение датасетов по типам артефактов

Отдельные датасеты дают три преимущества: свои расписания снапшотов, свои квоты и свои права доступа. Сборки Jenkins удобно чистить чаще, чем скрипты развёртывания, а Docker-слои нет смысла реплицировать с той же частотой, что рабочие артефакты.

• tank/tools - общие скрипты, CLI-утилиты, шпаргалки команды.
• tank/artifacts/jenkins - сборки и архивы Jenkins.
• tank/artifacts/gitlab - артефакты GitLab CI и кеш пакетов.
• tank/docker - слои образов, отдаваемые реестром.
• tank/backups - дампы конфигураций и выгрузки из внешних систем.

Вложенные датасеты наследуют свойства родителя, включая compression и ACL type, и переопределяют только то, что указано явно. Это экономит время: создали tank/artifacts с compression=zstd, а tank/artifacts/jenkins уже унаследовал настройку.

Настройка SMB/NFS-шар и прав доступа

SMB берут для рабочих станций Windows и macOS, NFS - для Linux-серверов и раннеров. В интерфейсе это раздел Sharing, затем Add. Для SMB-шары /mnt/tank/tools включают ACL и указывают группы, для NFS-шары /mnt/tank/artifacts задают maproot или mapall, иначе раннеры не смогут писать. Сравнение протоколов по скорости и сценариям собрано в материале про iSCSI, NFS и SMB для систем хранения.

Проверка с клиентов занимает минуту: smbclient -L показывает список шар и доступность сервера, showmount -e выводит экспортированные NFS-каталоги и разрешённые сети. Если шара не видна, смотрите сначала файрвол и привязку сервиса к интерфейсу, потом права.

ACL в ZFS: POSIX или NFSv4

POSIX ACL проще и знаком большинству администраторов, но управляет только тремя базовыми классами прав и плохо совместим с Windows-клиентами. NFSv4 ACL поддерживает наследование, тонкие маски и нормально работает в смешанной среде с SMB. Для хранилища артефактов выбирайте acltype=nfsv4.

Смену acltype на существующем датасете ZFS не выполняет автоматически: права придётся переприменить, а часть унаследованных ACE может потеряться. Решение принимают до заливки данных, а не после. В домене Windows или FreeIPA включите Kerberos, тогда права считаются по SID, а не по локальным UID.

Права для CI/CD: maproot, mapall и UID/GID

NFS по умолчанию подменяет root на анонимного пользователя, и раннер, пишущий от root, получает ошибку доступа. Два рабочих варианта: maproot=root для доверенного CI-сервера или mapall=uid:gid для конкретной сервисной учётки. Первый проще и опаснее, поэтому его обязательно ограничивают списком IP в настройках экспорта.

Пример: Jenkins стоит на отдельном сервере и монтирует NFS с maproot=root, а GitLab Runner пишет от пользователя gitlab-runner с mapall=1000:1000. Гостевой доступ (guest access) в продакшене отключён, для анонимного чтения оставлен единственный датасет с публичными утилитами. UID и GID сервисных учёток на TrueNAS и на клиентах держат одинаковыми, иначе права разъезжаются после переустановки раннера.

Организация снапшотов и резервного копирования

Снапшоты в ZFS создаются в разделе Periodic Snapshot Tasks и не требуют агентов на клиентах. Сами снапшоты места почти не занимают, но удерживают изменённые блоки, поэтому расписание и retention планируют вместе с квотами.

Политика снапшотов: расписание и retention

Для артефактов сборки разумна трёхслойная схема: каждый час с хранением 24 часа, ежедневно с хранением 7 дней, еженедельно с хранением 4 недели. Скрипты и утилиты меняются редко, им хватает ежедневного снапшота с retention 30 дней. Важные снапшоты перед рискованными работами помечают hold, тогда автоматическая очистка их не удалит.

Занятое снапшотами место проверяют через zfs list -t snapshot с параметром space, а суммарный объём показывает zfs get usedbysnapshots на датасете. Если цифра растёт быстрее данных, сокращают retention по самому активному расписанию.

Репликация на второй NAS и в S3

Replication Task отправляет снапшоты на второй NAS по SSH и держит удалённую копию в актуальном состоянии. Cloud Sync выгружает датасет в S3-совместимое хранилище (AWS, MinIO, Backblaze B2) и закрывает сценарий потери обеих площадок. Там, где на приёмной стороне нет ZFS, остаётся rsync по расписанию.

Рабочая схема: репликация tank/artifacts на backup-nas каждые 6 часов, Cloud Sync в S3 раз в неделю, отдельная задача репликации tank/tools раз в сутки. Важное ограничение: репликация не защищает от удаления на источнике, если снапшот уничтожили и на источнике, и на приёмнике. Отдельный датасет tank/backups с более долгим retention снижает этот риск.

Типовые проблемы совместимости и производительности

Три класса проблем встречаются чаще остальных: скорость ниже ожидаемой, отказы доступа из CI и нехватка кеша. Диагностика идёт по одному маршруту: zpool iostat показывает нагрузку на диски, smbstatus - активные SMB-сессии, статистика ARC - попадания в кеш, dmesg - ошибки драйверов. На стороне клиента профилировщик perf подскажет, упирается ли задача в диск или в сеть.

Медленный SMB/NFS: диагностика и ускорение

Сначала измерьте сеть, потом обвиняйте NAS. iperf3 между клиентом и сервером показывает реальную пропускную способность канала; если он даёт 1 Гбит/с, а копирование по SMB идёт на 30 МБ/с, дело в настройках протокола, а не в дисках.

• SMB signing. Проверка подписи пакетов режет скорость в разы. В доверенной сети подпись отключают, в остальных случаях оставляют.
• Версия протокола. SMB3 быстрее и надёжнее SMB1, а SMB Multichannel складывает пропускную способность нескольких интерфейсов.
• NFS async. Синхронная запись по умолчанию надёжна, но медленна; при наличии SLOG включают async, а не отключают синхронизацию полностью.
• MTU и jumbo frames. Значение 9000 задают на всех узлах пути, иначе крупные пакеты фрагментируются и скорость падает.

Типовой случай: iperf3 показывает 1 Гбит/с, SMB отдаёт 30 МБ/с. Причина в SMB signing, после отключения в доверенном сегменте скорость поднялась до 110 МБ/с. Разбор похожих сценариев с командами для iostat и параметрами recordsize есть в статье про настройку производительности TrueNAS.

Ошибки прав доступа и UID/GID

Permission denied почти всегда сводится к несовпадению идентификаторов или неверному экспорту. Проверьте три точки: ACL на датасете через getfacl, карту maproot и mapall в настройках NFS, значения UID и GID на клиенте и сервере.

Пример: раннер GitLab не мог записать файл в NFS-шару. На клиенте пользователь gitlab-runner имел UID 1000, на TrueNAS тот же логин получил UID 1001. Правку сделали одной строкой: mapall=1001:1001 в параметрах экспорта. Для NFSv4 в домене дополнительно проверяют idmapd и совпадение домена, иначе сопоставление пользователей ломается.

Интеграция с CI/CD и инструментами разработки

TrueNAS подключается к системам сборки как обычное сетевое хранилище: NFS-монтирование на Linux-раннерах, SMB-шара для агентов Windows. Nexus и Artifactory кладут на такой датасет blobstore, Jenkins хранит архивы сборок, GitLab CI - артефакты и кеш пакетов.

Подключение Jenkins и GitLab CI к TrueNAS

На сервере Jenkins ставят nfs-common, монтируют /mnt/tank/artifacts/jenkins в локальный каталог и указывают его в job как путь для archiveArtifacts. GitLab Runner получает тот же экспорт с mapall=1000:1000 и пишет артефакты в /mnt/tank/artifacts/gitlab. Обе системы требуют прав на запись и на удаление, поэтому ACL выдают на группу, а не на отдельного пользователя.

Если раннеры живут в облаке, а NAS стоит в офисе, разумно разделить роли: сборку выполняет облачный сервер (например, в Timeweb Cloud), а готовые артефакты складываются на TrueNAS через VPN. Такой вариант дешевле, чем гонять тяжёлые сборки через офисный канал. В пайплайнах, которые обращаются к моделям ИИ, ключи к API держат в секретах, а доступ ведут через единый шлюз вроде AiTunnel, чтобы контролировать бюджет и не раздавать ключи по джобам.

Docker-реестр и S3-совместимое хранилище на TrueNAS

SCALE позволяет развернуть MinIO как приложение и получить S3-совместимый шлюз на своём железе. Порядок такой: создаёте bucket docker-registry, выпускаете ключи доступа, указываете их в конфигурации реестра как storage driver s3. Слои образов удобно держать на SSD-пуле, иначе первый pull после обновления образа ждёт медленные диски.

Для высоких нагрузок объектное хранилище стоит выносить в отдельный кластер: MinIO на одном узле справляется с десятками тысяч операций в сутки, но не с тысячами параллельных запросов. Артефакты сборок, скрипты и утилиты остаются на TrueNAS, реестр с активным pull-трафиком переезжает туда, где есть избыточность на уровне узлов.

Проверка и валидация после настройки

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

Чек-лист проверки хранилища

• zpool status показывает все диски в состоянии ONLINE и ни одной ошибки чтения или записи.
• zfs list выводит созданные датасеты с ожидаемыми квотами и параметром compression.
• smbclient -L с рабочей станции видит SMB-шары и пускает под нужной учётной записью.
• showmount -e перечисляет NFS-экспорты и разрешённые подсети.
• zfs list -t snapshot подтверждает, что расписания снапшотов отрабатывают.
• Тестовая запись 1 ГБ по SMB и по NFS проходит без ошибок, скорость совпадает с ожидаемой для канала.
• Задача репликации и Cloud Sync отчитываются об успешном завершении.
• CI-раннер записывает и удаляет файл в своём датасете без правки прав вручную.

Тестовое восстановление из снапшота

Создайте файл test.txt в каталоге артефактов, дождитесь снапшота или сделайте его вручную из интерфейса, удалите файл, затем восстановите его из снапшота. Отдельный файл удобнее доставать через клон снапшота: клон монтируется как обычный датасет, из него копируется нужный файл, после чего клон удаляется.

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

Обновление и поддержка TrueNAS в 2026 году

Обновления выходят двумя потоками: текущий стабильный релиз (SCALE 25.04) и предыдущий (24.10), который получает исправления безопасности. Перед любым обновлением смотрите release notes и проверяйте upgrade path: пропуск крупной версии иногда требует промежуточного шага.

Планирование обновления без простоя

Последовательность такая: выгрузите файл конфигурации через System, General, Save Config, снимите снапшот всех датасетов, проверьте совместимость приложений с новой версией, назначьте окно обслуживания. Обновление SCALE с 24.10 на 25.04 на подготовленном узле занимает 20-30 минут, включая две перезагрузки. После обновления поднимите приложения и убедитесь, что экспорты NFS и шары SMB вернулись к работе. Пошаговый сценарий на реальной инсталляции описан в статье про полную настройку TrueNAS SCALE в 2026 году.

Миграция с CORE на SCALE

Переезд строят на репликации: поднимаете SCALE на новом железе, настраиваете Replication Task с CORE на SCALE, дожидаетесь синхронизации, переключаете клиентов на новый адрес. Простой сокращается до минут, потому что данные уже скопированы, а финальная репликация переносит только дельту.

Ограничения стоит принять заранее: часть плагинов CORE в SCALE недоступна, jails заменены контейнерами, а CORE 13.x приближается к концу поддержки, и обновления безопасности для него постепенно прекратятся. Планируйте миграцию до того, как останетесь на ветке без патчей.

Начните с малого: создайте датасет tank/tools, включите на нём ежедневные снапшоты и раздайте доступ группе DevOps. Работающая схема на одном датасете покажет реальные требования к кешу и сети быстрее, чем расчёты на бумаге.