Хранение файлов томов БСП в хранилище с OpenStack API

25.10.20

Разработка - Групповая разработка (Git, хранилище)

+15 –
В статье опишу вариант реализации хранения файлов в томах с использованием хранилища OpenStack API на примере облачного хранилища Selectel.

Файлы

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование Скачано Купить файл
ВнешнееХранениеФайлов
.cfe 26,12Kb
12 3 000 руб. Купить

Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний

Оформите подписку на компанию для решения рабочих задач

Оформить подписку и скачать решение со скидкой

Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

Вводные

  • Конфигурация 1С на БСП 3.1.2
  • Нужно хранить файлы во внешнем хранилище (не в сетевой папке)

 

Вариант реализации

Для хранения можно использовать

Выбрал OpenStack в реализации selectel.ru (ссылка на документацию), уже есть хранилище и опыт работы с сервисом, относительно простая аутентификация. Технически можно написать корректоры к остальным вариантам.

 

Реализовал в виде расширения.

Добавил перечисление "внеш_хф_ТипыХранилищ"

В спр. ТомаХраненияФайлов

  • добавил реквизит внеш_хф_ТипХранилища (внеш_хф_ТипыХранилищ)
  • добавил реквизиты аутентификации в сервисе selectel
  • доработал форму элемента для ввода данных аутентификации

Основная работа с файлами томов реализована в "РаботаСФайламиВТомахСлужебный", в нем изменил

  • ДобавитьФайл()
  • ДанныеФайла()
  • ОбновитьФайл()
  • УдалитьДанныеФайла()
  • СкопироватьФайл()
  • ПереименоватьФайл()
  • Сделал рефакторинг для переиспользования кода

Реализация БСП подразумевает работу сервера с сетевыми папками томов без ограничений, поэтому часть функционала упрощено, для примера процедура УдалитьФайл(ПутьКФайлу), без указания тома, это усложняет доработку. При операциях копирования/перемещения нет проверки на наличие файла с именем файла назначения.

Функции обращения к сервису вынес в общий модуль "внеш_хф_SelectelSwiftAPI"

 

Протестировал

  • Добавление файла
  • Чтение добавленного файла
  • Изменение файла
  • Переименование файла

Ссылка на исходный код.

Разработка в состоянии "alpha", предложения и замечания рассматриваю, по возможности оперативно решаю.

 

Итог

Файлы в томах можно хранить во внешнем хранилище, за счет этого решается

  • вопрос хранения вне базы при отсутствии сетевой папки (облачные сервисы)
  • вопрос переноса файлов между узлами РИБ

 

Благодарю за внимание.

Вступайте в нашу телеграмм-группу Инфостарт

+15 –

См. также

Практический курс по разработке на 1С с AI-агентами

Разработка Инструментарий разработчика Групповая разработка (Git, хранилище) Программист Платные (руб)

Практический курс по работе с AI-агентами для разработчиков 1С уровня middle и senior, а также тимлидов команд: от постановки задач и передачи контекста до создания расширений, интеграций, MCP-инструментов, тестов и проверки готового решения.

50000 руб.

10.09.2026    266    1    0    

0
Маскирование данных через pg_anon в CI/CD без промежуточных копий

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) Информационная безопасность Инструменты администратора БД Системный администратор Программист 1С 8.3 Беларусь Россия Казахстан Абонемент ($m)

Как реализовать безопасное маскирование данных в процессе CI/CD без создания промежуточных копий баз. Объясняем, как использовать инструмент pg_anon для автоматизации скрытия персональных данных при тестировании и развёртывании, сохраняя целостность и структуру информации. Материал объединяет практику Site Reliability Engineering (SRE) с задачами защиты данных, демонстрируя подход, при котором разработчики и DevOps;инженеры могут работать с реалистичными, но обезличенными данными, не нарушая требования безопасности и конфиденциальности.

1 стартмани

11.09.2026    447    Ninel_S    0    

0
1C:SRE-Suite — разворачиваем отказоустойчивый кластер PostgreSQL на базе Patroni и etcd с помощью Ansible

DevOps и автоматизация разработки Администрирование СУБД Групповая разработка (Git, хранилище) Системный администратор Программист Руководитель проекта Стажер 1С 8.3 1С:Бухгалтерия государственного учреждения 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1C:ERP Беларусь Россия Казахстан Абонемент ($m)

В четвёртой части серии 1C:SRE-Suite мы переходим к практической автоматизации развёртывания отказоустойчивого кластера PostgreSQL для высоконагруженных систем 1С на Linux. В материале подробно разбирается инженерное решение без HAProxy — с использованием виртуального IP-адреса и vip-manager от CYBERTEC, обеспечивающего прямое подключение к активному мастеру без лишних задержек и точек отказа. Показана структура Ansible-модуля: подготовка ОС, развёртывание etcd, настройка Patroni с параметрами для больших нагрузок 1С. В конфигурационный шаблон Patroni автоматически закладываются параметры, критически важные для высоконагруженных баз данных, запуск vip-manager и полная автоматизация создания трёхнодового кластера. В конце — пошаговый Quick Start и планы развития модуля, включая резервное копирование, оптимизацию ОС Linux и rolling updates PostgreSQL.

1 стартмани

11.09.2026    359    Ninel_S    0    

0
Предельные режимы. Часть1. Архитектурные границы масштабирования учетных систем. Потоковый сбор технологического журнала

DevOps и автоматизация разработки Администрирование СУБД Групповая разработка (Git, хранилище) Системный администратор Программист Руководитель проекта Стажер 1С 8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Управление холдингом 1С:Зарплата и Управление Персоналом 3.x 1С:Предприятие 8. Транспортная логистика, экспедирование и управление автотранспортом КОРП 1C:ERP Беларусь Россия Казахстан Абонемент ($m)

В корпоративных инсталляциях «1С:Предприятие 8.3» под управлением PostgreSQL всё чаще проявляются архитектурные пределы масштабирования: рост числа пользователей, обязательная маркировка, плотный поток API-интеграций и высокая стоимость простоя. Вводная часть цикла разбирает ключевые факторы современной эксплуатационной нагрузки и формирует инженерную методологию эволюционной модернизации без остановки продуктивного контура. Материал основан на практическом кейсе «Торговый контур» и показывает, как определить целевые метрики (p95, MTTR, APDEX), выстроить наблюдаемость, стабилизировать работу кластера и подготовить инфраструктуру к дальнейшему масштабированию. Публикация задаёт фундамент для последующих частей, посвящённых телеметрии, оптимизации PostgreSQL, CI/CD и архитектурному росту.

1 стартмани

10.09.2026    455    Ninel_S    0    

4
Предельные режимы. Границы масштабирования учетных систем. Вводный обзор цикла статей.

DevOps и автоматизация разработки Linux HighLoad оптимизация Групповая разработка (Git, хранилище) Системный администратор Программист Руководитель проекта 1С:Предприятие 8 1С 8.3 1С:Документооборот 1С:ERP Управление предприятием 2 1С:Управление холдингом 1С:Комплексная автоматизация 2.х Беларусь Россия Казахстан Абонемент ($m)

Системный анализ архитектурных границ масштабирования учетных систем «1С:Предприятие 8.3» под управлением PostgreSQL в ОС Linux. Формулирование инженерной методологии сквозного проекта «Торговый контур», определение измеримых целевых показателей (p95, MTTR, APDEX) и стратегии поэтапной модернизации эксплуатационного контура без остановки промышленных учетных процессов.

1 стартмани

07.09.2026    789    Ninel_S    9    

1
Автоматизируем непрерывную интеграцию (CI) через GitHub Actions

Linux Групповая разработка (Git, хранилище) Администрирование СУБД Системный администратор Программист 1С 8.3 Абонемент ($m)

Декларативный pipeline в GitHub Actions, тонкости лицензирования в Docker (--net=host), изоляция RUN_ID и интеграция со сборочным конвейером 1C:SRE-Suite. Вторая часть практического руководства (https://infostart.ru/public/2779597): от первого коммита до детерминированного синтаксического гейта на headless-раннере Linux

1 стартмани

03.09.2026    1007    Ninel_S    0    

3
Как я сделал инструмент, о котором мечтал много лет

DevOps и автоматизация разработки Тестирование QA Групповая разработка (Git, хранилище) Программист 1С:Предприятие 8 Бесплатно (free)

Четыре года в интеграторе я работал с git и EDT. Git после хранилища полюбил сразу: видно, кто и что менял. С EDT сложнее: тормозит, ошибки при обновлении ERP, автономный сервер внутри него работает только с файловой базой. На новой работе команда захотела перейти на git, я развернул EDT, и оно на второй день разрушило проект при загрузке расширения. Тогда я решил дать команде git с привычным Конфигуратором и инструмент, который за минуту доносит коммит до базы через ibcmd, вместо получасовой загрузки из файлов. На новой работе разрешили ИИ, и я написал это приложение с его помощью: от чтения документации и первого ТЗ до идей в электричке. Впервые за годы снова почувствовал себя творцом, а не закрывателем задач. По дороге приросли выгрузка, объединение и проверка конфигурации по коммитам, YAxUnit и режим MCP-сервера. В статье: схемы, скриншоты, грабли и честный список ограничений. Ссылки пока нет: хочу понять, нужно ли это кому-то, кроме меня.

03.09.2026    10169    KatanaDragon511    28    

38
1C:SRE-Suite - DevOps & Stability Suite для 1С на Linux

Linux Групповая разработка (Git, хранилище) Администрирование СУБД Системный администратор Программист 1С 8.3 Бесплатно (free)

Пакетный запуск Конфигуратора 1С на Linux таит опасную ловушку: при критических ошибках утилита DESIGNER завершается с кодом возврата 0 - «всё хорошо». Дефект уходит на продуктив. Мы открываем проект 1C:SRE-Suite - набор проверенных инструментов для надёжной эксплуатации 1С на Linux: • пятислойный сборочный скрипт с защитой от False Success (BOM, кодировки, lock-файлы, diff с Git) • Мягкая ротация процессов "rphost" через RAS API без обрыва сеансов • EDT ; Конфигуратор: CLI-мост для CI/CD на Node.js • Готовые конфиги logcfg.xml и nethasp.ini для боевого сервера • systemd-шаблоны для фонового мониторинга кластера Проект в активной разработке, лицензия MIT. Ждём ваших тест-репортов и PR.

03.09.2026    980    Ninel_S    0    

1
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. davdykin 25 11.08.20 09:30 Сейчас в теме
Мне кажется вы в публикации упустили самый главный вопрос - вопрос производительности... насколько по времени будет отличаться сетевая папка и это хранилище при загрузке/выгрузки 10-20 файлов, хотя бы примерно? Просто без этой информации, как мне кажется, понять полезная эта штука или нет - невозможно.
+ – Ответить
2. malikov_pro 1403 11.08.20 11:55 Сейчас в теме
(2) Отчасти Вы правы, если использовать внешние сервисы, то есть задержка до сервиса, тема разобрана в https://habr.com/ru/post/348542/, но хранилище можно развернуть и локально, пример.

Тема по поводу производительности локальных сервисов разбиралась в комментариях к моей статье https://infostart.ru/public/68079/.

Эта статья больше как посыл что можно доработать механизм БСП, доделать условие и обращение к FTP просто, к S3 чуть сложнее из за аутентификации.
+ – Ответить
3. kosmo0 113 14.08.20 04:18 Сейчас в теме
И сразу же продумываем что делать если вдруг интернет отвалится. Для начала - сможет ли конфигурация в принципе работать?

Элементарно узнаем сколько денег потеряет бизнес если вдруг будет отключение.

А вариантов прекращения работы уйма - неполадки у провайдера, неполадки на линии связи (банальные поломки, штормовой ветер и дождь в городе при котором что-то заливает, а кабеля рвет, экскаваторщик который начал копать не там), отключение интернета на уровне страны и города (из свежего - Минск, из глобального - противостояние с США), действия не затрагивающие напрямую вашу организацию (война с телеграмом при которой отключалось масса непричастных ресурсов), да и тупо маршрутизатор в конторе сдох.
Это как с архивированием данных - бэкапы обязательно делают те, кто терял данные (ибо знает сколько жизни отнимается при восстановлении). А есть счастливчики которые не теряли данные. Если вы из категории последних - то можно и не засорять голову чем попало. :)
+ – Ответить
4. malikov_pro 1403 14.08.20 10:24 Сейчас в теме
(3) "И сразу же продумываем что делать если вдруг интернет отвалится" - Это вопрос системного администрирования, сделайте резервный канал. "Если вы из категории последних" - опыта системного администрирования хватает. Если нужно хранить данные локально то разверните FTP, OpenStack локально и пользуйтесь.


Реальный кейс: база с 20к картинок (чертежи) хостится на Рарус-облаке, размер картинок более 2 ГБ. У раруса на тарифе стандарт размер диска 2ГБ и увеличить объем невозможно, хранить относительно рядом (датацентры МСК СПБ) вполне нормально.
+ – Ответить
5. kosmo0 113 20.08.20 11:17 Сейчас в теме
(4) Опыт это знание сотен граблей которые могут вылезти в самый неподходящий момент.
В теории проведение документа это пара десятков строк в которых данные переносятся в регистры, на практике - это еще сотня строк на проверку корректность и полноту данных перед проведением.

Резервный канал спасет от проблем на облаке на котором вы храните картинки? (а проблемы возникают у всех, даже у интернет-гигантов).

И как-то не последовало ответа - будет ли работать конфигурация если вдруг доступа к картинкам в облаке не будет? Или пользователей будет элементарно вышибать при открытии справочника Номенклатура? (а в худшем случае будет вышибать при открытии любого документа в котором есть реквизиты с типом справочник.номенклатура).

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

Программист как пожарник - чем меньше он нужен окружающим, значит тем лучше работает (в подавляющем большинстве случаев). Хотя с другой стороны - весь в мыле спас ситуацию и все его хвалят (хотя, возможно, ранее именно этот программист элементарно не поставил три строки ПОПЫТКА-ИСКЛЮЧЕНИЕ-КОНЕЦПОПЫТКИ).
+ – Ответить
6. malikov_pro 1403 20.08.20 13:10 Сейчас в теме
(5)
Если вопрос резервного копирования, то описал решение через rclone https://infostart.ru/1c/articles/1183106/
Если вопрос доступности, то в текущей модели хранения нет хранений копий в разных местах в рамках одного хранилища. При реализации возникает вопрос о консистентности данных и приоритетности получения. Сейчас реализую работу с GDrive, будет выступать как доп хранилище для формирования документов DOC по шаблонам, в локальном будет хранится PDF. В планах написать реализацию к FTP и решать вопрос переноса файлов между хранилищами, дублирования и.т.д.


"будет ли работать конфигурация если вдруг доступа к картинкам в облаке не будет?" - да, исключения по отсутствию файла реализованы в БСП еще с 2.4 на сколько помню. Для проверки попробуйте отключить сетевую папку.
Продолжение к вопросу о доступности, по идее нужно разделять хранение на горячее и холодное, файлы которые часто используются добавлять в кеш (в текущей реализации РС "ДвоичныеДанныеФайлов"), малоиспользуемые удалять из кеша.

"Программист как пожарник" - нужно понимать что есть психологическая модель "геройства", а есть продуманная архитектура приложения.

Если есть идеи по реализации - пишите, продумаем совместно, возможно дойдет до реализации. Вариант использовать issue и PR на GitHub.
+ – Ответить
7. kosmo0 113 31.08.20 16:56 Сейчас в теме
(6) У меня нет желания ткнуть в код пальцем и крикнуть типа - "вот дурак". Иногда бывают ситуации когда проще потратить 5 минут чтобы ПОТОМ не тратить несколько часов (или даже дней) на устранение проблем. Если вдруг я буду реализовывать нечто подобное, то я предусмотрю защиту от ситуации "пропажи" связи с местом хранения. Как это реализовано у вас или других программистов мне в принципе все равно (не я буду, в случае чего, разгребать).

Есть такое понятие - "цена ошибки". То есть каковы будут потери (в том числе денежные) от ошибки. И при одной и той же ошибке в одной организации понесут тысячи или миллионы рублей ущерба, а в другой организации не заметят - это не работает, ладно займусь другим.

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

зы. не думайте что в жизни все предсказуемо - раньше ковида с сидением по домам пару месяцев тоже не было.
+ – Ответить
8. malikov_pro 1403 31.08.20 17:36 Сейчас в теме
(7) В статье написано "Разработка в состоянии "alpha", по делу напишите, как видите безопасное хранение. Из трех абзацев "нытье" про потенциальные потери. Выше писал что решение подбирается под ситуацию и решается комплексно, 1С является только клиентом к системе хранения.

Если есть кейс для обдумывания варианта решения - пишите, разберем. Если знаете как организовать хранилище опишите или напишите ссылку на статью с нормальной организацией хранения. Можете добавить по делу в код - PR в GitHub.

Статью про rclone написал после решения вопроса с бекапами у клиента, до этого теневые копии windows использовались. Статья про nginx сформировалась после решения вопроса с публикацией телефонии.

"вполне возможно, вашу разработку захотят использовать в организации где цена ошибки будет дорого стоить" - бездумное копирование кода проблема копирующего, поставляется AS IS.
+ – Ответить
9. kosmo0 113 18.09.20 17:39 Сейчас в теме
(8) Человека несколько постов тыкают в потенциальную серьезную проблему - нет, это нытье. У нас это не случалось, поэтому проблема надумана. (корновируса нет, его придумали - потому что я не болел).

зы. Понял свою глобальную ошибку.
Можно писать код учитывая полученные ошибки в прошлом (опыт называется). Но это гораздо дольше и чуточку сложнее. А можно просто написать код решающий проблему (без проверок) - и быстро и заказчику проблему решил (он и доволен). А потом, при наличии, исправлять ошибки и внезапно проявившиеся (прошу отличать от слова появившиеся) условия функционирования (а может так повезет что ошибок и особенностей функционирования не будет). Второй подход замечателен при программировании простых и относительно средних по сложности разработках. При критичных разработках - гнать в шею, ибо получается говнокод с кучей костылей (потому как на первоначальный код прикручивается масса добавлений, которые плохо стыкуются друг с другом). Но в 1С, в принципе, сойдет - не для космических же кораблей программируют.

за сим прощаюсь - можно завести лошадь в реку по шею, но невозможно заставить ее пить.
+ – Ответить
10. malikov_pro 1403 18.09.20 20:53 Сейчас в теме
(9) Разработка является прототипом, вы "тыкаете" на требования предъявляемые к решению используемому в продакте. Если нужно решение для конечного использования - заказываете за деньги.
В моих планах было обкатать у клиента прототип и дополнить публикацию, проект не состоялся.
+ – Ответить
Для отправки сообщения требуется регистрация/авторизация