В первой части статьи был рассмотрен собственно Автономный сервер – приложение ibsrv, его преимущества, ограничения, показания к использованию.
Перейдем ко второй части, представляющей для кого-то, возможно, даже больший интерес. В первую очередь, думаю, это должно заинтересовать адептов CI-CD.
Утилита администрирования – ibcmd
Утилита администрирования на текущий момент предоставляет два режима работы
- Server – в этом режиме создаются или изменяются конфигурационные файлы для Автономного сервера.
- Infobase – предназначен для выполнения различных действий с информационными базами: создание, загрузка/выгрузка, импорт/экспорт и т.д.
Режим "server"
Режим работы server тесно связан с самим «Автономным сервером»
Главным его назначением является формирование корректного файла настроек для Автономного сервера, в формате YML.
Например, приведенная ниже команда, на основании переданных параметров и значений по умолчанию, сформирует файл sb_demo.yml, который далее можно указывать как самому серверу ibsrv, так и утилите управления ibcmd вместо длинной цепочки параметров.
Содержимое созданного файла sb_demo.yml:
server:
address: localhost
port: 8314
database:
dbms: MSSQLServer
server: localhost
name: sb_demo
user: test_db_user
password: test_pwd_123
infobase:
id: 9f28e93a-85a7-4c5c-9860-78e461a83815
name: 9f28e93a-85a7-4c5c-9860-78e461a83815
distribute-licenses: yes
schedule-jobs: allow
http:
base: /
На этом, пожалуй, описание режима server можно считать исчерпанным.
Режим "infobase"
Второй режим работы, infobase, совершенно не зависим от Автономного сервера и может применяться самостоятельно, с любыми базами – файловыми или расположенными в СУБД. Для СУБД-баз при этом совершенно не важно, зарегистрирована ли база на сервере 1С или нет. Взаимодействие идет напрямую с СУБД.
Возможности утилиты я продемонстрирую на примерах. В замечаниях будут указаны особенности, определенные экспериментально или в переписке с разработчиками на партнерском форуме.
Все примеры буду приводить с заполнением параметров командной строкой. Но в каждом из них можно вместо общих ключей указать путь к файлу конфигурации подобным образом:
Создание базы
Начнем, как обычно, с самого простого примера. Создадим файловую базу.
[ INFO] Создание информационной базы...
[ INFO] Создание информационной базы успешно завершено
В результате выполнения команды, создан каталог "d:\test\demo_db" и в нём размещена пустая база 1С – файл 1Cv8.1CD (и пара служебных файлов .cfl)
Одновременно с созданием, одной командой можно выполнить дополнительные действия:
- Загрузить базу из dt-файла
- Загрузить конфигурацию из cf-файла
- Загрузить конфигурацию из XML-файлов
Создать и загрузить выгрузку из dt-файла.
[ INFO] Создание информационной базы...
[ INFO] Создание информационной базы успешно завершено
[ INFO] Загрузка информационной базы...
[ INFO] Загрузка информационной базы успешно завершена
Создать и загрузить Конфигурацию из cf-файла.
Для разнообразия создадим новую базу с размещением в СУБД. Добавляем ключ загрузки из cf-файла и путь к нему. Повторяющиеся ключи и параметры в дальнейших примерах будут затенены серым шрифтом.
[ INFO] Создание информационной базы...
[ INFO] Создание информационной базы успешно завершено
[ INFO] Загрузка конфигурации...
[ INFO] Загрузка конфигурации успешно завершена
Замечание. При создании базы в СУБД, смысл команды create правильнее было бы назвать «инициализацией», т.к. выполняется создание структуры таблиц и индексов в существующей базе данных. Если же базы данных не существует, будет выдана ошибка. Чтобы при отсутствии базы данных она была создана, требуется указать ключ --create-database, аналогично установке флажка «Создать базу данных в случае её отсутствия» в консоли кластера.
Создать и загрузить Конфигурацию из XML-файлов.
Меняем ключ загрузки на --import и указываем каталог с исходниками.
[ INFO] Создание информационной базы...
[ INFO] Создание информационной базы успешно завершено
[ INFO] Импорт конфигурации из XML...
[ INFO] Импорт конфигурации из XML успешно завершен
Замечание. Загрузка конфигурации из cf-файла или XML-файлов выполняется в «основную» Конфигурацию информационной базы. Конфигурация базы данных после такой операции остается прежней. Чтобы сразу после загрузки произвести обновление конфигурации базы данных, можно добавить ключ --apply.
Загрузка и выгрузка сf, cfe, dt, xml
Разумеется, загрузку dt, cf, cfe, xml-файлов можно выполнить и отдельными командами, без создания информационной базы. Выгрузка во всех поддерживаемых форматах также присутствует.
Загрузка dt-файла:
Выгрузка dt-файла:
Загрузка конфигурации из cf-файла:
Выгрузка конфигурации в cf-файл:
Замечание. Для команды выгрузки конфигурации save по умолчанию выгружается конфигурация базы данных, а не основная. Для того, чтобы сохранить основную конфигурацию, необходимо указать ключ --staging
Загрузка конфигурации из XML-файлов:
Выгрузка конфигурации в XML-файлы:
Замечание. Для команд загрузки и выгрузки конфигурации доступно указание ключа --extension и имени расширения, которое нужно загрузить или выгрузить.
Обновление конфигурации базы данных
После загрузки Конфигурации или расширения, конечно же, требуется обновить конфигурацию базы данных.
[ INFO] Обновление конфигурации базы данных...
[ INFO] Проверка корректности метаданных...
[ INFO] Обработка структуры базы данных...
[ INFO] Обработка данных: Реструктуризация Перечисление.РезультатыОбработкиЗапросовНаИспользованиеВнешнихРесурсовВМоделиСервиса
..............................................
[ INFO] Новый объект: РегламентноеЗадание.ЧтениеНовостейСлужбыПоддержки
[ INFO] Новый объект: РегламентноеЗадание.ЭкспортОценкиПроизводительности
[ INFO] Изменена структура таблиц базы данных
[ INFO] Принятие изменений...
[ INFO] Обновление конфигурации базы данных успешно завершено
Прочие команды
Без примеров оставлю последние три команды, что есть в текущей версии утилиты.
- config check - проверка конфигурации
- config reset - восстановление конфигурации базы данных.
- clear - очистка информационной базы
Для чего всё это нужно?
Предполагаю, что у Вас уже возник вопрос: «И чем это отличается от пакетного режима Конфигуратора, который делает всё то же самое, и даже больше, давным-давно?». Признаюсь, я ждал этого вопроса.
Отличия от пакетного режима Конфигуратора:
Во-первых, для выполнения описанных действий посредством Конфигуратора, нужно, как минимум, чтобы Клиентская часть Платформы была установлена. С этим не возникает проблем, когда Вы работаете на своем компьютере с локальной базой. Но когда база расположена на сервере, который является только сервером приложений 1С, для загрузок-выгрузок есть следующие варианты:
а) выполнять операции Конфигуратором по сети. Это может занимать очень продолжительное время ввиду особенностей сетевого обмена между компонентами Платформы.
б) устанавливать клиентскую часть Платформы на сервер. Исключительно с целью ускорения выгрузок-загрузок.
А если Ваш сервер – на Linux и без графического интерфейса? Конечно, можно установить пакет Xvfb, эмулирующий вывод на дисплей, но ведь это «костыли», как Вы считаете?
Выполнение действий утилитой ibcmd возможно непосредственно на сервере, без установленного Клиентского приложения. Специально ничего устанавливать не требуется. Утилита присутствует в дистрибутиве сервера приложений 1С.
Во-вторых, клиентское приложение, в частности и Конфигуратор, работающий в пакетном режиме, требует лицензию. И возможность получить лицензию Конфигуратором есть не всегда.
Пример: лицензии выдаются Сервером 1С, локальных лицензий нет. При этом требуется загрузка/выгрузка для файловой базы.
Для выполнения действий утилитой ibcmd лицензия не требуется. Ни клиентская, ни серверная.
В-третьих, все операции с базой, выполняемые Конфигуратором, требуют авторизации в этой базе.
Пример: требуется извлечь конфигурацию из dt-файла, который Вам достался, скажем, из архива и неизвестен пароль пользователя ИБ, обладающего административными правами в ней.
Традиционный способ – создать временную информационную базу в клиент-серверном варианте, чтобы иметь возможность очистки таблицы пользователей. Загрузить в неё dt-файл. Очистить таблицу пользователей базы в СУБД. Перезапустить Конфигуратор. Выгрузить конфигурацию в файл. Удалить временную базу из СУБД.
Для операций, выполняемых ibcmd не требуется авторизация информационной базы. Upd 15.12.21: Ниже, в комментариях, коллеги указывают, что в Платформе версий 8.3.18.1689, 8.3.20.1549 авторизация ИБ уже требуется.
Выполнение той же задачи посредством ibcmd, будет выглядеть следующим образом:
>ibcmd infobase config save --db-path="%tmp%\db" "%tmp%\some_infobase.cf"
Да, я в знаю что существуют разработки на Инфостарте, позволяющие извлечь конфигурацию в виде cf-файла непосредственно из dt-файла. Здесь я описываю штатные механизмы.
В-четвертых, для выгрузки конфигурации посредством ibcmd, не имеет значения, запущен ли в данный момент Конфигуратор этой базы у кого-то еще или нет. Просто потому что мы не запускаем Конфигуратор.
Более того, я пока не знаю, расценивать ли это как баг или как фичу, но для выгрузки dt-файла не требуется монопольный режим! Конечно же, пользоваться этим стоит с осторожностью. Не думаю что попытка сделать dt-шник в момент активной работы с базой пройдет без негативных эффектов.
В-пятых. Формат командной строки гораздо проще чем для Конфигуратора. Кроме того, есть возможность использования конфигурационного файла, чтобы не указывать повторяющиеся параметры подключения.
Возможно, Вы сможете добавить еще пару-тройку отличий, если заинтересуетесь инструментом и станете им пользоваться.
Чего не хватает для полного счастья
Перечислю функционал, который хотелось бы увидеть в релизе (первоочередные хотелки):
- Инкрементальная выгрузка в XML только тех файлов, версии которых изменены.
Сейчас доступна только полная выгрузка в XML.
- Работа с Хранилищем конфигураций: выгрузка версий, получение отчета по версиям.
- Экспорт непосредственно в формат EDT.
Об этом отдельно ниже.
- Логирование в Технологическом Журнале в полном объеме.
Сейчас привычных событий SDBL, DBMSSQL, DBPOSTGRS, DBV8DBENG в ТЖ нет. Пишется только служебное SYSTEM.
Мне представляется, что утилита ibcmd получилась очень функциональным и универсальным инструментом. Возможно, даже более универсальным, чем изначально предполагалось. И сейчас, пока инструмент в статусе беты, у нас есть возможность повлиять на его дальнейшее развитие. Одним из применений и векторов развития мне видится использование в контурах CI-CD. Как для "традиционной" разработки с использованием Хранилищ, так и для работы в новом формате EDT.
Чтобы заменить пакетный режим Конфигуратора в процессе синхронизации "традиционной" разработки с репозиторием Git, не хватает только возможности работы с Хранилищем.
В своей переписке на партнерском форуме с разработчиками я обозначил такой вектор возможного развития инструмента и получил обещание проанализировать и подумать. Ниже привожу цитату своего описания возможного сценария использования. Здесь я защищал предложения включить возможность работы с Хранилищем и выгрузки в формате EDT.
Полагаю, утилита ibcmd могла бы стать отличной заменой громоздкой связке из 1С:ГитКонвертера + EDT (не требующей к тому же java и клиентских лицензий) для целей:
- перевода существующих разработок в формат EDT
- совместной работы над общим Проектом, команд, ведущих разработку "традиционным методом" в Хранилище и "новаторских" с EDT. Пример такой работы приведен в статье "Постепенный переход на разработку в EDT".
- синхронизации Хранилища с репозиторием Git для целей CI-CD.
К недостаткам выполнения этих операций посредством 1С:ГитКонвертера я бы отнёс:
- необходимость установки Клиента и использование клиентских лицензий
- необходимость установки java
- необходимость установки самой EDT для конвертации XML-EDT
Использование ibcmd позволило бы избавиться от всех этих недостатков, а также гибко управлять процессом скриптами или из сервера сборок.
Также, одним из преимуществ перехода на использование репозитория Git вместо Хранилища, декларируется возможность работы с исходными кодами без использования какой-либо IDE, посредством "любимого текстового редактора". Однако сейчас получается, что для того, чтобы сначала получить из Конфигурации исходные коды, а после доработок собрать из них Конфигурацию, требуется установленная EDT, очень ресурсоемкая, надо сказать. Лишь для того, чтобы один формат XML-файлов привести к другому. Осмелюсь предположить, что выполнение этой задачи посредством ibcmd было бы гораздо более эффективным.
Заключение
Спасибо всем, кто дочитал до конца. Статья получилась значительно больше, чем я предполагал, создавая заготовку. Надеюсь, что я не зря потратил силы и время, и Вы открыли для себя что-то новое.