Введение
В настоящее время, практики DevOps активно используются в различных областях ИТ-индустрии, в том числе и специалистами, работающими с 1С:Предприятие. В результате этого, появилась масса программных продуктов, позволяющих автоматизировать различные аспекты процессов разработки и эксплуатации программного обеспечения, управления ИТ-инфраструктурой, а также интеграции между различными ИТ-системами. И если для автоматизации процесса разработки и тестирования (Dev) существует достаточно большое количество различных программных продуктов (tester, xUnitFor1C, vanessa-add и др.), разработанных на базе платформы 1С:Предприятие, то для автоматизации управления ИТ-инфраструктурой (Ops), как правило используются “сторонние” программные продукты, такие как Microsoft System Center, Zabbix, puppet, ANSIBLE, Terraform etc. Это очень мощные продукты с огромным функционалом, рассчитанные на управление большими инфраструктурами. Следствием этого, является высокий порог вхождения для работы с ними, а также приличное количество ресурсов, которое надо затратить на их покупку, развертывание, настройку и обслуживание. К тому-же, как правило ИТ-системы не существуют в вакууме и зачастую требуется обеспечить их взаимодействие с пользователями, что может оказаться нетривиальной задачей.
Таким образом, настоящая разработка (проект на GitHub) — это попытка создать простое решение, которое позволит автоматизировать действия по администрированию и управлению ИТ-инфраструктурой, соединив преимущества платформы 1С:Предприятие, в части создания пользовательского интерфейса и структур для хранения данных, и различные скриптовые языки программирования, такие как PowerShell, bash, Python, OneScript и т.п., которые реально используются для задач администрирования и управления.
Системные требования
Платформа 1С:Предприятие, версии не ниже 8.3.10.2252.
Операционная система Windows или Linux.
Концепция решения
Концепция настоящего решения не отличается большой оригинальностью и позаимствована из Microsoft System Center Orchestrator. Суть ее заключается в том, что последовательность автоматизируемых действий оформляется в виде некоего процесса (workbook в System Center, playbook в Ansible и т.п.), который может быть запущен на выполнение при наступлении определенных условий. В качестве среды для создания и выполнения процессов используется платформа 1С:Предприятие, а также рабочие серверы, которые обеспечивают выполнение действий, которые не могут быть выполнены напрямую из платформы. Схема инфраструктуры представлена на рис. 1.
Рисунок 1. Схема инфраструктуры.
Настоящая конфигурация не требует наличия БСП и может использоваться как самостоятельно, так и в составе других решений.
Описание
Создание описания процесса
В качестве базового механизма для создания процессов используется механизм бизнес-процессов, платформы 1С:Предприятие. Процессы создаются в режиме конфигуратора, в дизайнере карты маршрута бизнес-процесса. Такой подход обусловлен соображениями безопасности, а также простотой разработки и отладки.
В качестве примера, рассмотрим процесс отправки http-запроса, схема которого представлена на рис. 2.
Рисунок 2. Схема процесса отправки http-запроса.
Как можно увидеть, схема процесса включает в себя задачи, по которым необходимо выполнить определенные действия, а также блоки анализа результата этих действий.
Задачи, могут быть нижеследующих типов:
Действие — собственно выполнение какого-либо действия.
Ожидание выполнения — задача, которая ожидает наступления определенных даты и времени. При наступлении указанных даты и времени, автоматически помечается как выполненная.
Обработка ошибки — задача, которая создается при возникновении ошибки при выполнении действия. Как правило используется для коммуникации с людьми, для устранения причин ошибки.
Каждая задача имеет результат выполнения:
Положительный — действие было успешно выполнено.
Отрицательный — действие не было выполнено.
Ошибка — при выполнении действия возникла ошибка.
Также, каждая задача имеет информацию о дальнейших действиях:
Продолжить — продолжить выполнение процесса.
Повторить — повторить выполнение.
Завершить — завершить выполнение процесса.
Отменить — отменить выполнение процесса.
Соответственно анализ результатов выполнения, а также дальнейших действий позволяет направить последовательность выполнения по нужному пути.
Задание соответствующих свойств, а также анализ результатов, производится в обработчиках соответствующих элементов схемы процесса.
Реализация действий
Итак, мы имеем схему бизнес-процесса с описанной последовательностью действий. Теперь необходимо реализовать их.
Каждое действие выполняется независимо в фоновом задании, при этом поддерживается два варианта выполнения. Первый — для каждого экземпляра процесса и точки маршрута запускается отдельное фоновое задание. Второй — для каждой точки маршрута запускается отдельное фоновое задание, которое выполняет действия по всем экземплярам процессов. Первый вариант является более производительным, однако при большом количестве одновременно выполняющихся процессов может привести к чрезмерному потреблению ресурсов и снижению производительности.
Соответственно, при втором варианте использования, необходимо для каждой точки маршрута с типом действие создать регламентное задание, где и реализовать необходимое действие. Пример реализации действия отправки http-запроса представлен на рис. 3.
Рисунок 3. Реализация действия по точке маршрута.
В настоящей конфигурации можно реализовать действия, которые могут быть выполнены средствами платформы 1С:Предприятие. Однако, с использованием публикации //infostart.ru/public/936455/ и разработки https://github.com/asosnoviy/oscript-ssh вполне реально реализовать задачи по управлению серверами и сетевым оборудованием.
Запуск процессов на выполнение
Запуск процессов на выполнение сводится к созданию экземпляра соответствующего бизнес-процесса, с последующим помещением его в очередь для выполнения. Старт процесса будет произведен автоматически.
Существует достаточно большое количество ситуаций, когда старт процессов зависит от выполнения других процессов. Для обеспечения этого функционала реализован механизм зависимостей. Каждый экземпляр процесса имеет набор пар ключ/значение, от которых он зависит, а также соответствующий набор, указывающий на что он влияет. Пример создания процесса для выполнения представлен ниже.
Настройка адресации задач
Поскольку администрирование и управление ИТ-инфраструктуры более-менее крупного размера является командной работой, реализован механизм, позволяющий адресовать определенные задачи определенным группам специалистов.
Для этого необходимо создать группу адресации задач
Рисунок 4. Создание группы адресации задач.
Добавить в нее необходимых специалистов
Рисунок 5. Добавление членов в группу адресации задач
И назначить задачу по точке маршрута группе адресации
Рисунок 6. Назначение задачи по точке маршрута группе адресации
Настройка оповещений
Оповещение ИТ-специалистов о процессах, происходящих в системе, в частности о факте необходимости обработать ошибку выполнения является неплохой идеей. Для этого в конфигурации реализован механизм оповещения пользователей. В качестве канала для оповещений выбрана электронная почта.
Для настройки оповещений, необходимо создать контакты получателей
Рисунок 7. Создание контакта
Создать группу контактов и добавить в нее необходимых членов
Рисунок 8. Создание группы контактов
А затем, настроить оповещение по определенному событию для указанной группы
Рисунок 9. Настройка оповещения
В данном примере, оповещение будет отправлено членам группы Тестовая группа, при создании задачи обработки ошибки в бизнес-процессе – отправка http-запроса.
Тестирование
Теперь протестируем все вместе.
Отправим два http-запроса на несуществующий домен.
Рисунок 10. Отправка http-запроса.
Просмотрим очередь бизнес процессов и убедимся, что в очереди два созданных нами процесса.
Рисунок 11. Очередь бизнес-процессов.
Просмотрим свойства процесса, который был создан вторым и убедимся, что он не стартован.
Рисунок 12. Свойства бизнес-процесса
При правильной настройке smtp сервера, на почту членов группы оповещения прийдет электронное письмо, примерно следующего вида
Рисунок 13. Оповещение по электронной почте
Войдем в систему с аккаунтами Инженер1 и Инженер2 и убедимся, что в списке “Мои задачи” каждого пользователя появилась задача на обработку ошибки.
Рисунок 14. Список “Мои задачи”
Откроем задачу
Рисунок 15. Задача обработки ошибки
И просмотрим сообщение об ошибке, которое было сгенерировано при выполнении http-запроса.
Также посмотрим схему бизнес-процесса и текущее положение на карте маршрута
Рисунок 16. Текущее положение на карте маршрута
Установим пользователя Инженер2 исполнителем задачи и убедимся, что задача исчезла из списка задач у пользователя Инженер1.
Рисунок 17. Установка исполнителя задачи.
Также исполнитель может установить исполнителем другого пользователя или очистить поле Исполнитель. В этом случае, задача будет снова доступна всем членам групп адресации.
Нередки ситуации, когда над задачей может работать несколько человек. Для передачи информации по задачи другим пользователям может использоваться механизм заметок.
Рисунок 18. Заметки по задаче.
Поскольку в данном случае проблема заключается в невозможности разрешить DNS имя url, на который мы отправили запрос, завершим процесс.
Рисунок 19. Установка дальнейших действий
Ну вот, собственно и все.
Заключение
Надеюсь, что данная разработка поможет вам в администрировании, управлении и обслуживании вашей ИТ-инфраструктуры.
Также конфигурация доступна для загрузки на github.
P.S.
Замечания, предложения, улучшения и конструктивная критика – приветствуются.
Заплюсовал. За применение 1Script отдельное спасибо!
(1)Да не за что 🙂 Еще бы отладчик для web в OneScript.
(0) крутая штука. Можно использовать не только в администрировании, но и в том же тестировании — запускать тесты по расписанию, тестировать доступность сервисов.
Крутая штука, очень рад подобным идеям, хоть как-то подружить админов и прогеров. Но бизнес-процессы. Только конфигуратор и всё на редактирование. Я всегда стремился к автономности системы от прогеров. Иначе нет смысла.
(4)
Любая система от кого-то зависит 🙂 Возьмём набор скриптов, они зависят от людей, которые их пишут и поддерживают. В этом случае админы выступают в роли программистов. Да и никто не запрещает им создавать бизнес-процессы в конфигураторе, благо это не сложно. Но конечно если отчёты, скд — то да, без программистов не обойтись 🙂
За сохранность данных отвечает один кто то перед кем то. Главбух или финдир перед директором, сисадмин или программист 1с перед главбухом или финдиром. Не двое сразу.
Или сисадмин отвечает за технику и бакапы перед программистом 1с или программист 1с сдает доработки сисадмину и получает от него команды обновлять или проводить.
Руководитель ит отдела может быть только один, неважно как он называется. И он должен встать из гроба и прийти на работу и он принимает то, что заказывает. А тот, кого вызвали написать обработку или починить принтер — подождёт пока вызовут и пока примут работу.
Если нет ни того ни другого — тогда бухгалтерия решает коллегиально.
Какой именно руководитель ит требуется компании — железячник, сисадмин, dba или 1с ник зависит от компании и текущего проекта.
Но вероятность того что это будет 1с ник снижается с развитием технологий.
ЦКК, ЦА, 1C:ITIL, СППР… Неужели всего этого 1С-Зоопарка кому-то не хватило для «решения рутинных задач администрирования»?
(7)Все перечисленные Вами системы предназначены для решения задач по определённой тематике:
ЦКК — центр контроля качества.
ЦППР — центр проектирования прикладных решений.
Само название продуктов как-бы намекает, что они немного для другого 🙂
Вот наверное ITIL и ЦА — это уже ближе к теме.
ITIL — хороший продукт, однако на мой взгляд больше ориентирован на управление и учёт, чем на автоматизацию действий.
1С:ЦА — центр администрирования. Относительно молодой продукт (вышел по моему в 2018). Пожалуй наиболее удачный пример из приведенных Вами. Однако «рабочей лошадкой» являются скрипты на python, что требует установки оного на все управляемые устройства. Что в общем-то для серверов под Linux в общем-то и нормально, но для windows будет выглядеть как-то странновато, учитывая наличие штатных средств в лице PowerShell и .net. К тому- же создание workflow в режиме предприятие, а также расширение внешними обработками — это вопрос, на мой взгляд не бесспорный.
Ну вот как-то так 🙂
И если не секрет, почему Вы назвали эти продукты зоопарком?
(6)Честно говоря не понял Вашу мысль. Не могли бы Вы её пояснить?
(8) ЦКК — Есть задачи и сценарии автоматизации, также на Powershell
СППР — есть задачи, ошибки и сценарии автоматизации — тоже на скриптах
ITIL — бизнеспроцессы такие что документооборот позавидует, ну и да, тоже можно выполнять скрипты
ЦА — Можно делать практически всё.
Не говоря уже о том что всё это имеет специализированные интеграционные Web сервисы и может быть интегрировано между собой если вдруг так случилось что чего то не хватило…
И при этом люди продолжают
упоротоупорно писать свои системы автоматизации администрирования на 1С.Лучше бы нашелся кто-то кто агента на C++ написал без сторонних библиотек и кросплатформенного. В 1С сделали в ЦА и ЦКК но в своём любимом стиле «через задницу», но они 1С — им можно.
Зоопарк — это когда один и тот же функционал присутствует в 4 системах, ой простите уже в 5-ти.
(10)
ЦКК — Есть задачи и сценарии автоматизации, также на Powershell
СППР — есть задачи, ошибки и сценарии автоматизации — тоже на скриптах
ITIL — бизнеспроцессы такие что документооборот позавидует, ну и да, тоже можно выполнять скрипты
ЦА — Можно делать практически всё.
Почему же по Вашему так вышло, что на рынке столько продуктов с одинаковым, по Вашим словам функционалом?
Вас ничего не смущает?
Полагаю, что его не пишут потому, что в нем нет необходимости, т.к. в современных ОС достаточно штатных средств удаленного управления.
(10) и за каждую из этих 5 систем с пересекающимся функционалом надо платить.
Выигрывает либо лидер у которого есть все и есть немножко времени у того ПО, которое может то чего пока не может лидер. И только это, ничего кроссфункционального. Это как кока кола пепси кола. Одно было когда то лекарством от головной боли, другое слабительным. В советском союзе предпочтение отдавали пепси.
(11)
Я написал что с одинаковым? Я писал что столько продуктов, покрывающих функционал вашего решения… Он уже 4 раза реализован в разных продуктах. Только и всего. В каждом из них есть свой полезный функционал.
Это не в ваш огород камень, это к тому что 1С явно не хватает модульности и политики по управлению своими продуктами
Да ну? Ansible и Zabbix агент никому не нужны? :)))) Вы просто слабо себе представляете крупную распределенную архитектуру. Если бы представляли — не было бы этих вопросов.
(12)
А вы, я так понимаю, из тех кто всё ещё верит в существование бесплатного ПО? И в Деда Мороза тоже? :)))
Бесплатного ПО не бывает. Теперь ваша жизнь больше никогда не будет прежней :))))
(14)Я не об этом. Любое ПО имеет срок годности.
Как понять что сроки прошли, если амортизация нематериальных активов в бухучете в общем случае не связана с производственной необходимостью обновить что либо.
(15) А… ну тут поддержу — вопрос конечно философский. Но в любом случае, если думать об амортизации — надо ориентироваться на ПО с наибольшим числом внедрений. Я пытаюсь донести только то что своё пилить надо в самом крайнем случае…
(16)будем иметь ввиду.
(13)
Тут конечно трудно с Вами не согласиться, не представляю :), поэтому пользуясь случаем задаю Вам глупые вопросы, чтобы расширить свой кругозор.
А поясните пожалуйста, что на Ваш взгляд явилось причиной создания агентов в этих продуктах и может быть есть какие-либо системы, которые обходятся без агентов и используют штатные средства ОС?
И может быть все-таки Zabbix является системой мониторинга и ее стоит использовать именно для того, для чего она предназначена, как и ЦКК с СППР?
P.S.
Вопрос
ЦА — Можно делать практически всё.
В 1С сделали в ЦА и ЦКК но в своём любимом стиле «через задницу»
Вы не раскрыли.
(18)
Не на мой, а на общий. Ликбез делать не буду — намекну что у нормальных ребят все удаленные сервера и станции прикрыты файрволом по самые небалуйся.
Почему ЦКК и ЦА «через задницу»…. Ну вы сами раскрыли… Java + Python для Windows машины… для службы агента которая должна быть доступной скоростной и незаметной… ну как бы…
(19)
Не на мой, а на общий. Ликбез делать не буду — намекну что у нормальных ребят все удаленные сервера и станции прикрыты файрволом по самые небалуйся.
Полностью с Вами согласен, что безопасность — один из важнейших аспектов.
Теперь давайте посмотрим вот на что:
С одной стороны — самописный агент, который нужно создать для различных ОС, следить за его работоспособностью в зависимости от обновлений ОС в различных окружениях, регулярно проверять на уязвимости, а также обновлять на всех хостах, где он установлен.
С другой — штатные средства ОС — SSH и PowerShell, которые создавались не посредственными инженерами, проверяются на уязвимости лучше, чем Вы можете себе позволить, которые протестированы на миллионах устройств, регулярно обновляются, поддерживаются и де-факто являются стандартом.
Как Вы считаете, не будет ли более разумным использовать эти стандартные средства, вместо создания собственного аналога?
Почему ЦКК и ЦА «через задницу»…. Ну вы сами раскрыли… Java + Python для Windows машины… для службы агента которая должна быть доступной скоростной и незаметной… ну как бы…
ОК. Тогда как Вы считаете, продукты, в которых чуть менее «через задницу» имеют право на жизнь?
(20)
Рукалицо. Прочитайте какую-нить книжку пожалуйста. Я сдаюсь. Когда разберётесь как работает файрвол и отличите входящие от исходящих коннектов готов буду донести до вас свою мысль. Сейчас это бесполезно
(21)
Можете начинать доносить Вашу мысль:)
(22) Я попробую ещё раз — это интересно:
Опишите зачем нужен ftp сервер и зачем в нём пассивный режим если есть «общие папки» Windows. Почему вы не будете использовать «Штатные средства ОС» которые лучше защищены и всё такое в случае если вам надо собрать файлы с 500+, станций или серверов, к примеру? Зачем вам централизованный ftp сервер если можно файлики забирать с конечных станций? Что такое пассивный режим FTP и зачем его придумали?
Если после того как ответите на эти вопросы моя мысль не дойдёт сама я всё-таки не смогу ничего сделать, хотя пытался.
(23)Мысль о том, что можно при помощи групповых политик, ограничить доступ к рабочим станциям по интересующим Вас протоколам, доступом только с определенных хостов/подсетей и продублировать эти настройки на сетевом оборудовании Вы находите контрпродуктивной? Мы ведь рассматриваем корпоративную сеть на основе Windows?
P.S.
Поскольку дискуссия перешла в русло, не относящееся напрямую к теме публикации, предлагаю Вам создать отдельную публикацию, где Вы сможете поделиться своими мыслями и концепциями с сообществом, детально рассмотрев все за и против различных подходов. Либо создайте тему в курилке, где если Вам интересно, мы рассмотрим эти вопросы.
(25)
О боги!
Да, именно :).
Эта возможность доступна, начиная с Windows XP SP2 🙂
Сконфигурировать машины типа XP можно в ветке GPO
Computer ConfigurationAdministrative TemplatesNetworkNetwork ConnectionsWindows Firewall
Начиная с по моему Windows Vista , появился Windows Firewall With Advanced Security.
Там появились дополнительные фичи:
Возможность контроля не только входящих, но и исходящих подключений, правила безопасности подключения (вместо политк IPSEC в 2003), возможность проверки подлинности компьютера на уровне сети, возможность указания сервисов/программ, которым разрешены входящие/исходящие подключения etc.
Сконфигурировать можно в ветке GPO
Computer ConfigurationPoliciesWindows SettingsSecurity SettingsWindows Firewall With Advanced Security
Это правильное решение.
Вам надо ознакомиться с базовыми возможностями ОС Windows, а также изменить тональность общения.
Не увидел в описании есть ли возможность сортировки баз
Чтобы потом по имени базы в консоле в дереве было отсортировано?
(27)
Не совсем понял, о каких базах идет речь.
Не могли бы Вы более развернуто сформулировать вопрос?