Введение
Прислушавшись к совету Steelvan, о том, что в качестве темы для демонстрационных примеров надо использовать какие-то массовые, понятные широкой аудитории кейсы, в качестве темы для настоящего демонстрационного примера, была выбрана тема управления информационными базами.
На infostart’е существует множество публикаций, о различных инструментах и методиках (gitlab-ci, xUnitFor1C, deployka и другие), которые позволяют построить полный цикл от разработки до развертывания программных решений на платформе 1С:Предприятие. Однако в реальной жизни, достаточно часто встречаются и менее масштабные задачи, такие как создание, обновление и учет различных тестовых информационных баз (Перезаливатор), автоматизации которых c использованием конфигурации АИТП (проект на GitHub) и посвящен настоящий демонстрационный пример.
Системные требования
Версия конфигурации АИТП не ниже 0.4.13.67
Версия платформы 1С:Предприятие не ниже 8.3.10.2252
Операционная система – Linux.
Начальные и граничные условия
В дальнейшем предполагается, что у вас развернута инфраструктура 1С:Предприятие, примерно соответствующая лабораторной среде, описанной в этой или этой публикации.
Также предполагается, что в качестве сервера 1С:Предприятие используется x32 версия сервера, исполняемые файлы которого расположены в папке /opt/1C/v8.3/i386/.
Предполагается, что на каждом главном сервере кластеров 1С:Предприятие развернута служба ras, которая настроена для запуска в качестве демона.
Предполагается, что в качестве пользователя, для доступа к СУБД используется стандартный пользователь postgres, для которого настроена проверка по паролю для внешних подключений и разрешены подключения без пароля для локальных подключений.
Цели автоматизации
Учет информационных баз
При интенсивной работе, разработчики могут генерировать достаточно большое количество различных тестовых баз, которые могут использоваться для проверки различных гипотез, оценки каких-то сторонних конфигураций etc. Иногда разработчики забывают их удалять, что приводит (особенно после увольнения сотрудника) к возникновению большого количества “зависших” информационных баз, о назначении которых никому ничего не известно.
Соответственно имеет смысл учитывать все создаваемые информационные базы, с привязкой их к автору.
Контракторы и консультанты
В работе с контракторами, достаточно распространенным вариантом является создание тестовой базы, идентичной продуктивной, в которой контрактор производит необходимые доработки, а также тестирует функционал. Как правило, периодически возникает потребность в обновлении данных тестовой базы свежими данными из продуктивной базы. В связи с тем, что как правило контракторы имеют ограниченный доступ к инфраструктуре предприятия, им приходится запрашивать обновления у сотрудников компании, что может занять достаточно длительное время и отвлекать ресурсы сотрудников компании.
Аналогичная задача может стоять перед консультантами, которым для демонстрации или в других случаях необходимо обновить предварительно преднастроенную информационную базу свежими данными.
Программисты
Как было описано выше, в ходе работы, программисты могут создавать, удалять или обновлять различные тестовые информационные базы. Поскольку в компании среда разработки и тестирования может быть отделена от продуктивной среды (для тестовой и продуктивной среды используются отдельные серверы СУБД и серверы приложений), имеет смысл автоматизировать работу с информационными базами таким образом, чтобы работа с ними происходила в тестовом контуре.
Процессы и роли
На основе анализа целей автоматизации, автоматизируемыми процессами будут – обновление, создание, а также удаление информационных баз, а ролями пользователей в системе – контрактор/консультант и программист. Поскольку роль контрактора/консультанта является ограниченной и кто-то должен создать и настроить информационную базу для использования консультантом или контрактором, добавим роль администратор, которая будет обладать привилегиями на выполнения всех операций как в тестовой так и в продуктивной средах.
Соответственно матрица ролей/процессов будет иметь нижеследующий вид:
|
Роль |
Тестовые базы |
Продуктивные базы |
||||
|
Обновление |
Создание |
Удаление |
Обновление |
Создание |
Удаление |
|
|
Контрактор |
X |
|
|
|
|
|
|
Консультант |
X |
|
|
|
|
|
|
Программист |
X |
X |
X |
|
|
|
|
Администратор |
X |
X |
X |
X |
X |
X |
Вспомогательные объекты конфигурации
Роли
В соответствии с описанными бизнес-ролями, создадим соответствующие роли в нашей демонстрационной конфигурации (см. рис. 1.).
Рисунок 1. Список ролей.
Бизнес-роль Контрактор/Консультант реализуется ролью – ОбновлениеТестовойБазы, бизнес-роль Программист – реализуется комбинацией предыдущей роли и роли СозданиеТестовойБазы.
Бизнес-роль Администратор – ролью УправлениеИнформационнымиБазами.
Необходимые данные
Для автоматического выполнения процессов, наша система должна иметь некоторую информацию, об инфраструктуре компании, а также хранить необходимую информацию о созданных информационных базах, настройках доступа к ним etc. (см. рис. 2.).
Рисунок 2. Объекты конфигурации, для хранения данных.
Константы Сервер1СПоУмолчанию и СерверСУБДПоУмолчанию используются для хранения информации о том, на каких серверах будет размещаться вновь создаваемая информационная база, если при создании они не были указаны. Поскольку правом установки серверов для создания информационных баз обладают только администраторы, эти константы должны указывать на вашу тестовую среду.
Справочники Серверы1С, СерверыСУБД, ИнформационныеБазы, БазыСУБД – хранят информацию о соответствующих объектах инфраструктуры, а также об информационных базах и связанных с ними базами СУБД.
Регистр сведений ДоступКИнформационнымБазам содержит информацию о разрешениях пользователей, применительно к конкретным информационным базам. Соответствующие разрешения позволяют пользователю обновлять, удалять информационную базу, а также использовать ее как источник обновления.
При создании информационной базы, пользователю, который ее создал (владельцу), назначаются все вышеперечисленные разрешения, однако администратор может их скорректировать.
Регистр сведений ИсточникиОбновленийИнформационныхБаз – содержит информацию об источнике для обновления по умолчанию. Если такой источник существует – он автоматически выбирается при попытке обновления информационной базы.
Источники событий для старта процессов
Поскольку пользователь каким-то образом должен сообщить системе о своих намерениях, для их фиксации, в конфигурации созданы соответствующие документы (см. рис. 3.).
Рисунок 3. Документы фиксации намерений пользователя.
Моментом подтверждения намерений и соответственно стартом необходимых процессов, является проведение соответствующего документа. Создание экземпляров процессов и их старт реализованы в соответствующих подписках на события.
Описание процессов
Создание информационной базы
Схема процесса создания информационной базы представлена на рис. 4.
Рисунок 4. Схема процесса создания информационной базы.
Первым действием, пытаемся создать информационную базу, на определенном кластере 1С:Предприятие и сервере СУБД (1). Затем анализируем результат выполнения задачи (2). В случае возникновения ошибки – формируем задачу на обработку ошибки (3), с которой в дальнейшем будут работать администраторы. После выполнения диагностических и иных действий, администратор может повторить, продолжить, завершить или отменить процесс. Результат обработки ошибки анализируется в блоке (4). При отмене процесса, создаваемая база помечается как неактивная (11), затем, автору отправляется сообщение об отмене процесса (13) и происходит завершение процесса (14). При завершении процесса, производится отправка сообщения об отмене (13), с последующим завершением процесса (14).
При успешном создании информационной базы или выборе варианта Продолжить при обработке ошибки, производится добавление разрешений для автора, в регистр сведений ДоступКИнформационнымБазам, а также при необходимости добавляется запись источника обновлений по умолчанию в регистр ИсточникиОбновленийИнформационныхБаз (5). После анализа результатов выполнения действия (6), в случае возникновения ошибки создается задача на обработку ошибки (7). Действия по результатам обработки ошибки (8), аналогичны действиям по предыдущей задачи за исключением того, что при отмене процесса, происходит удаление созданной информационной базы (12).
При успешном выполнении задачи (5), автору отправляется сообщение об успешном создании информационной базы (9), с последующим завершением процесса (10).
Удаление информационной базы
Схема процесса удаления информационной базы представлена на рис. 5.
Рисунок 5. Схема процесса удаления информационной базы.
Первым шагом, удаляем базу СУБД, соответствующую удаляемой информационной базе (1). Для этого создаем и выполняем служебный дочерний процесс.
Далее, анализируем результат удаления базы СУБД (2). Если база не была удалена, отправляем сообщение об отмене (3) и завершаем процесс (10).
Если удаление базы СУБД выполнено успешно, удаляем информационную базу из списка баз (4).
После анализа результатов действия по удалению информационной базы (5), в случае успешного выполнения, отправляем сообщение автору об успешном завершении процесса (9) и завершаем процесс (10).
В случае возникновения ошибки, формируем задачу обработки ошибки (6), с которой в дальнейшем будут работать администраторы. Поскольку база данных уже удалена, отмена процесса и восстановление первоначальной функциональности невозможно, поэтому отмена и завершение процесса не имеют смысла и их выбор приводит к повторению попытки удаления информационной базы.
После удаления информационной базы, производится пометка удаляемой базы как неактивной (8), отправка сообщения об удалении (9) и завершение процесса (10).
Обновление информационной базы
Схема процесса обновления информационной базы представлена на рис. 6, 7.
Рисунок 6. Схема процесса обновления информационной базы, часть 1.
Рисунок 7. Схема процесса обновления информационной базы, часть 2.
Вобщем и целом логика обработки ошибок, а также других вспомогательных шагов, аналогична логике работы в предыдущих процессах, поэтому ниже, кратко описан алгоритм основной ветки процесса.
Создаем временную базу СУБД (1). Запускаем процесс восстановления из базы источника во временную базу (2). Поскольку время восстановления нам неизвестно и может варьироваться в широких пределах, выполняем восстановление асинхронно.
Периодически, проверяем окончание режима восстановления (3) и при необходимости ожидаем определенное время перед повторной проверкой (4).
Получаем результат выполнения восстановления (5). Если восстановление прошло неудачно, формируем задачу для администраторов (6). Администраторы могут принять решение о повторном запуске операции восстановления, либо-же об отмене процесса.
В случае успешной операции восстановления, производится удаление рабочей СУБД информационной базы (7) и переименование временной базы СУБД таким образом, чтобы ее имя совпадало с именем рабочей базы (8). Затем, автору отправляется сообщение об успешном завершении (9) и происходит завершение процесса (10).
Итог
Таким образом мы получили описания наших процессов в виде блок-схем. Следующим этапом необходимо реализовать действия, описанные в процессах.
Реализация действий
Поскольку детальное описание реализации всех действий достаточно трудозатратно и значительно увеличит объем публикации, далее, реализация действий рассмотрена на примере действия запуска восстановления базы СУБД.
Далее будем полагать, что запуск баз на восстановление будет выполняться последовательно.
Сначала, реализуем обработчики ПриСоздании и ПриВыполнении для нашей задачи.
Далее, создадим регламентное задание, которое будет запускаться для запуска задач восстановления, а также обработчик запуска восстановления.
Как можно увидеть, запуск восстановления со стороны 1С выглядит как асинхронный запуск скрипта, на рабочем сервере OneScript.
В нашем демонстрационном случае, вместо операции восстановления из файла резервной копии, мы используем одновременное резервное копирование и восстановление без создания твердых резервных копий. Ограничением данного подхода, является тот факт, что база источник и база назначения должны находиться на одном физическом сервере СУБД. Для нашего демонстрационного случая – это вполне допустимо.
Текст скрипта представлен ниже:
Как можно увидеть, скрипт достаточно прост и логика его работы заключается в подключении к серверу СУБД по протоколу SSH, с последующим выполнением команд pg_dump для создания резервной копии и psql для ее восстановления.
Аналогичным образом реализуются и другие действия.
Таким образом, на данном этапе мы реализовали действия наших процессов и фактически готовы опробовать то, что у нас получилось.
Тестирование функционала
В режиме конфигуратора, создадим пользователей Админ, Контрактор, Разработчик и АдминистраторБаз. Пользователю Админ, дадим полные права. Этот пользователь необходим для настройки других пользователей.
Запустим конфигурацию в режиме предприятие с пользователем Админ, создадим соответствующих пользователей АИТП, разрешим им запуск тонкого клиента, а также добавим им базовые права на подсистему АИТП (см. рис 8.).
Рисунок 8. Пользователи системы.
Также, добавим пользователю Контрактор права на обновление информационных баз, пользователю Разработчик – права на создание и обновление информационных баз, пользователю АдминистраторБаз права, на администрирование информационных баз. При необходимости добавим сетевые хосты (см. рис. 9.), соответствующие серверам СУБД и серверам 1С:Предприятие, а также учетные записи для доступа к ним и работы с СУБД (см рис.10).
Рисунок 9. Сетевые хосты.
Рисунок 10. Учетные записи.
Для работы почтовых уведомлений, также необходимо настроить параметры отправки почты в настройках оркестратора, а также создать и сопоставить созданным пользователям контакты с адресами электронной почты.
Запустим конфигурацию под пользователем АдминистраторБаз, создадим серверы 1С:Предприятие (см. рис. 11), а также серверы СУБД (см. рис. 12), а также настроим серверы по умолчанию, для создания информационных баз, а также интервал ожидания, перед повторной проверкой завершения восстановления информационной базы (см. рис. 12а.).
Рисунок 11. Серверы 1С:Предприятие.
Рисунок 12. Серверы СУБД.
Рисунок 12а. Параметры подсистемы управления информационными базами.
Создадим документ Добавление информационной базы (см. рис. 13) и проведем его.
Рисунок 13. Документ Добавление информационной базы.
Поскольку мы не настраивали оповещения, подождем некоторое время и увидим в консоли администрирования созданную информационную базу (см. рис 14.).
Рисунок 14. Созданная информационная база.
Откроем базу в режиме конфигуратора, добавим объект метаданных (в нашем случае справочник), запустим конфигурацию в пользовательском режиме и добавим несколько элементов в наш справочник.
Таким образом, мы создали продуктивную базу, которую в дальнейшем будем использовать как источник для обновлений.
Также создадим еще одну, тестовую базу, доступ к которой предоставим пользователю Контрактор (см. рис. 15.). В качестве источника для обновления, выберем продуктивную базу, созданную ранее.
Рисунок 15. Тестовая база для контрактора.
После создания базы, добавим разрешения для пользователя Контрактор, на обновление тестовой базы, а также на использование продуктивной базы в качестве источника для обновления (см. рис. 16, 17.).
Рисунок 16. Права контрактора на тестовую базу.
Рисунок 17. Права контрактора на продуктивную базу.
Запустим конфигурацию из под аккаунта Контрактор.
Как можно увидеть на рис 18, контрактор может только обновлять информационные базы.
Рисунок 18. Пользовательский интерфейс контрактора.
Создадим документ Обновление информационной базы (см. рис. 19.).
Рисунок 19. Обновление информационной базы.
Как можно видеть, в качестве информационной базы для обновления, доступна только тестовая информационная база, которая создавалась для контрактора, а в качестве базы-источника, автоматически подставлена продуктивная база. Конечно ограничения только на уровне пользовательского интерфейса не являются достаточными и в реальных системах необходимо проводить проверки допустимости действий во время выполнения процесса, однако для нашей демонстрационной конфигурации это простительно.
Проведем документ и подождем, пока соответствующий процесс будет завершен. Проверить состояние процесса и соответствующих действий можно из-под аккаунта, имеющего доступ к оркестратору (см. рис. 20.). В нашем случае – это аккаунт Админ. Для оперативного информирования инженеров, обслуживающих инфраструктуру, можно настроить адресацию задач и оповещений, как описано здесь.
Рисунок 20. Задачи по процессу обновления информационной базы.
Подключившись к тестовой базе можно увидеть, что она идентична продуктивной базе.
Запустим конфигурацию в пользовательском режиме из-под аккаунта Разработчик. Как можно увидеть, разработчику доступны функции добавления, обновления, а также удаления информационных баз (см. рис. 21.).
Рисунок 21. Пользовательский интерфейс разработчика.
Протестируем создание, обновление и удаление информационных баз аналогично тому, как мы это делали ранее.
Как можно увидеть, разработчик, лишен возможности выбора сервера 1С:Предприятие и сервера СУБД, при создании информационных баз. Соответственно, они создаются на серверах по умолчанию.
Также, по умолчанию, разработчик имеет разрешения на обновление, удаление и использование в качестве источника только для своих баз. Предоставление иных прав, осуществляется пользователем с ролью администратора информационных баз аналогично тому, как это было сделано для контрактора.
Заключение
Вот таким вот нехитрым способом, можно автоматизировать ваши ИТ-процессы с использованием конфигурации АИТП.
Автоматизируйте свои процессы и процессы клиентов, делитесь результатами с сообществом (возможно и не безвозмездно). В общем надеюсь, что конфигурация АИТП будет вам удобным помощником в автоматизации ИТ-процессов.
