Powershell запуск 1с с параметрами
Суть рассматриваемого вопроса изложена в заголовке, повествование разобьем на три части. Отдельно внизу будут приведены тексты скриптов.
1) Предисловие
Вопрос необходимости резервного копирования в автоматическом режиме не подлежит сомнению ни у корифеев, ни у новичков. В статье рассмотрим резервное копирование средствами 1С (что имеет ряд преимуществ перед копированием средствами СУБД). При этом будут применены средства пакетного запуска платформы 1С, powershell и планировщик задач Windows.
Задачи обновления информационных давно автоматизированы, но только для типовых конфигураций, либо тех, что используют библиотеку стандартных подсистем. В моем случае мы работаем со старенькой Альфа-Авто редакции 4, которая распространяется на 12 серверов. Изменения вносятся примерно два раза в неделю, поэтому выгода от автоматизации налицо.
В обоих случаях мы имеем следующие исходные данные:
- Операционная система Windows Server (версии от 2008 до 2012);
- Клиент-серверный вариант платформы 1С 8.3 (с обязательно установленным компонентом COM-соединение).
2) Резервное копирование
После прочтения указанных ссылок мы уже знаем, что надо сделать, чтобы запустить скрипт powershell, поэтому сразу перейду к делу.
Сделать резервную копию информационной базы в пакетном режиме очень просто, надо только «выгнать» всех пользователей. Делать мы это будем, подключившись COM-объектом к базе данных. Это в нашем примере делает функция ExitAll. В тело функции зашито, что она вызывается на том сервере, на котором, собственно, установлен кластер серверов 1С. Вызовите эту функция безо всяких параметров в своем скрипте на сервере — и ВСЕ пользователи из ВСЕХ баз кластера вылетят.
Приношу свои извинения человеку, чьим кодом я воспользовался при написании этой процедуры — авторство восстановить не удалось.
После этого следует вызвать функцию BackUpBase с параметром — имя информационной базы. У меня во всех ИБ есть служебный администратор с одинаковыми учетными данными, поэтому я их просто захардкодил. При необходимости можно их параметризовать, либо обойтись аутентификацией ОС.
Итоговый скрипт сохраняем в файл.
В планировщике задач создаем «Простую задачу», имя, разумеется, на ваше усмотрение.
У меня работает ежедневно, но и тут хозяин — барин. Запускать лучше всего ночью, когда никто не работает, например, в 3:00. Действие для задачи — «Запустить программу». Сама программа у нас «powershell.exe». А вот ее аргументы —
где ExitAllUsersAndBackup.ps1 — как раз наш сохраненный скрипт.
-ExecutionPolicy RemoteSigned — ключ, который разрешает выполнение пакетных скриптов powershell, если в системе они глобально не разрешены. Работает через раз (возможно, не хватает компетенции чтобы разобраться, но закономерности не нашёл). В случаях, когда не работает с этим ключом, приходится разрешать выполнение скриптов для всего сервера.
Для этого Win+R, powershell.exe,
и подтверждаем действие.
Время работы с данными скриптами — более трех месяцев. Перебои были, но связаны с отключением электричества и прочими внешними факторами.
3) Обновление конфигурации
После того, как все пользователи вышли (или выгнаны, как в предыдущем случае), можно обновлять конфигурацию. Наличие регламентных заданий может помешать обновлению, так как с момента отключения всех пользователей и открытия конфигуратора для загрузки конфигурации вполне может начать работу какое-то задание. Поэтому расписание следует обдумать.
Конфигурацию мы храним на ftp-сервере, на который помещаем ее вручную. Файл конфигурации называется GK.cf, в приведенном примере обновляется одна единственная конфигурация. Потенциально можно так же обновлять и несколько различных конфигураций.
На ftp рядом с GK.cf помещаем файл с названием flag.txt. Наличие этого файла сигнализирует о том, что обновляться надо. Можно проверять наличие самого фйла GK.cf, но мы используем флаг так же для других целей.
Скрипт работает следующим образом:
- Удаляет GK.cf и flag.txt, если таковые есть в рабочем каталоге (у пользователя, от имени которого будет запускаться планировщик, должно быть право на запись в этот каталог);
- Предпринимается попытка скачать файл флага;
- Если такой файл скачать получилось — скачиваем .cf;
- Собственно, обновление функцией UpdateCf.
Надежность этого скрипта чуть меньше. Обновление проходит до конца на 100% в тех случаях, когда меняется структура метаданных. В других случаях бывает, как я предупреждал ранее, появление активного пользователя. В результате конфигурация загружена в базу, но конфигурация базы данных не обновлена (снова прошу прощения за подобную кривоватую терминологию перед людьми, не связанными с 1С). В остальном — полет нормальный.
Платформа 1С великолепна, замечательна и просто мощная. Обширный функционал доступен из коробки, а технология внешних компонент делает ее практически безграничной в части расширения возможностей. Но иногда.
Иногда все это не помогает и для достижения результатов, решения задачи - приходиться использовать сторонний софт. И ладно, если бы это были COM-объекты, которые хоть и являются устаревшей технологией, но до сих пор часто используются и даже получили некоторую вторую жизнь с последними событиями. Но есть и другой путь - запуск приложений напрямую из кода встроенного языка.
Сегодня мы поговорим о запуске приложений программным способом. А также о некоторых проблемах и способах их решений под Windows и Linux.
Часть подходов, которые будут описаны ниже, применяются в разработке "Командный интерпретатор для 1С", но скачивать ее для изучения не обязательно. Все есть здесь. Там лишь все это организовано в удобном виде для использования.
Исполни это
Причин, когда такое может понадобиться - много, очень много. Все их рассматривать точно не будем. Остановимся на одном простейшем примере - запуск команды ping, чтобы узнать доступность какого-либо ресурса в сети средствами 1С. Иногда еще ping запускают для эмулирования ожидания (метода Sleep), но мы такое извращение делать не будем :)
Наша задача - запустить какое-либо приложение с параметрами и получить результат его работы. И сделать мы это должны безопасным способом!
Последнее означает, что если запускаемое приложение зависнет, запросит интерактивных действий от пользователя (а на сервере мы ничем ему в этом случае помочь не сможем) или просто будет выполняться дольше выделенного для него времени, то мы должны завершить его работу и продолжить выполнение кода в обычном режиме и обработать исключение. Никому ведь не нужны зависшие сеансы 1С?
Мы рассмотрим несколько решений как для Windows, так и для Linux. И так, поехали.
My Little Windows
По классике, сначала мы сделаем плохо, а потом сделаем хорошо. Прежде чем начать дам несколько служебных функций, которые будут использоваться в примерах ниже.
Решения не идеальные, но простые. Например, там можно найти как сохранить файл в кодировке UTF-8 без BOM, получить путь к файлу PowerShell.exe и др. Решения всегда можно улучшать.
Плохой пример
И так, как обычно выполняется запуск приложений из кода встроенного языка? Правильно - с помощью процедуры "ЗапуститьПриложение()":
Первым параметром передаем строку команды запуска и параметры по необходимости. Во втором устанавливаем каталог, что не обязательно. Третий параметр позволяет дождаться завершения приложения, а четвертый получить код возврата. Обычно если код возврата не равен 0, значит что-то пошло не так.
Вернемся к нашей задаче. Выполним команду "ping infostart.ru".
Вариант рабочий и позволяет запускать большую часть команд и целых скриптов. Комментарии даны исчерпывающие. Используются только штатные возможности платформы 1С для выполнения команд. И это плюс. Но у этого подхода есть и большой минус - низкая надежность и непредсказуемость результата в тех случаях, когда точно не известно, как долго будет команда выполняться и не потребует ли приложение интерактивных действий пользователя. Если интерактивные действия потребуются на стороне сервера, где мы об этом даже и не узнаем, то сеанс 1С может подвиснуть на всегда.
В качестве решения может быть реализация таймаута выполнения команды, но для процедуры "ЗапуститьПриложение" такое реализовать практически невозможно. Можно, конечно, попробовать запустить приложение и ожидать файла-результата какое-то время, но это решит проблему частично. Зависания не будет, но приложение будет запущено и дальше, ожидая внешней команды.
WScript.Shell нас спасет
Мы же в среде Windows. Давайте используем ее средства в виде COM-Объекта "WScript.Shell":
Вот такая портянка для безопасного запуска приложений.
Если кратко, то для выполнения команды добавили таймаут. По истечении времени выполнения, приложение завершается и вызывается исключение.
Теперь приложение не зависнет и в случае чего мы сможем завершить его работу принудительно.
Мое имя Power, PowerShell
Пойдем дальше и сделаем наше решение более интересным. Что, если нам нужно запустить не простую команду CMD или BAT'ник, а команду или скрипт PowerShell, но на тех же условиях! Для примера опять же оставим запуск бесконечного пинга :)
Еще одна портянка кода, но куда без них.
Принцип тот же самый, что и в примере выше. Отличие находится в области "ПодготовкаСкриптаPowerShell", где выполняется подготовка скрипта PowerShell для запуска и установка необходимых параметров для приложения PowerShell.exe. Иначе параметры безопасности не дадут нормально запустить скрипт. Подробнее об этом читайте на MSDN.
Фактически, теперь можно запускать любые скрипты хоть CMD, хоть PowerShell. А если сильно хочется, то можно и GIT Bash под Windows использовать или даже подсистему WSL под Windows 10. Но все это уже другая история. Осталось поговорить про Linux.
*.nix is my own
Под *.nix привычнее всего использовать bash для выполнения команд. Можно ли использовать bash из встроенного языка платформы 1С? Да, можно. Можно запускать как отдельные команды, так и целые скрипты. При этом получать результат и, что самое главное, делать это безопасно как в примерах выше.
В далеком 2015 году на Mista была поднята тема "Запуск файлов *.sh в самой 1с". Возможно, информация ниже будет ответом на вопрос, т.к. точного ответа так там и нет. Но может быть я не прав :)
Запускаем bash-скрипты
Первое, что нужно понять - в Linux нет COM-объектов. Значит придется обойтись штатными средствами платформы 1С. Выглядеть это будет так:
Здесь мы устанавливаем произвольный текст команды для Bash и выполняем его. В чем то прием аналогичен тому, что мы делали для Windows. Комментарии даны полные, но на паре моментов остановимся подробнее.
Некоторые нюансы
Первое, что может показаться интересным - это вызов "dos2unix" для сформированного ранее файла скрипта. Зачем это нужно? В операционной системе Windows по умолчанию для переноса строк в файлах используется последовательность символов "\r\n" (перевод каретки + перенос строки). В Unix-подобных системах используется только символ переноса строки "\n". Для Windows символ перевода каретки был добавлен для того, чтобы в древние времена можно было отправлять на печать текст без каких-либо особых драйверов. Телетайп навсегда! Этот легаси остался и по сей день и никому не мешает, ну почти.
Нам же он может сильно помешать по двум причинам:
- Несмотря на то, что сервер 1С установлен под Linux - все равно стандартный перенос строки платформа формирует как "\r\n". Даже если для таких классов как "ЗаписьТекста" или "ТекстовыйДокумент" устанавливать символ переноса строки другой (например, Симполв.ПС или по коду символа переноса строки равному 10), то платформа все равно использует символ перевода каретки.
- Еще может быть ситуация, когда текст команды для выполнения передается с клиента под управлением Windows на сервер под Linux и символы перевода каретки будут там присутствовать.
Мешать они будут потому что Bash не понимает что с ними делать. Если в файле скрипта будет содержаться символ "\r", то мы получим ошибку:
Вот, например, обсуждение подобной проблемы. Так вот, с помощью команды "dos2unix" можно убрать все символы, несовместимые содержимым скрипта Bash и сделать его корректным. На скриншоте ниже показан пример преобразования содержимого скрипта. (Да, я использую Notepad++ даже в Linux, если Вы его узнали).
Конечно, тут есть минус - пакет "dos2unix" должен быть установлен на сервер. Сделать это проще простого. Вот так это, например, выглядит для Ubuntu:
Но это не единственная особенность. Для того, чтобы ограничить время выполнения команды мы используем штатные возможности - команду timeout. С ее помощью мы можем указать сколько времени выделяется для выполнения команды / скрипта.
В примере выше мы выполняем некоторый скрипт с таймаутом 10 секунд. Подробнее смотрите мануал :)
Теперь Вы можете запускать приложения, скрипты или команды с помощью Bash из Linux безопасным способом.
Скрытая угроза
Частным случаем запуска процессов небезопасным образом является использование COM-объектов. Не все COM-объекты порождают процессы, которые нужно контролировать. Но, например, всеми любимые Word и Excel, которые часто до сих пор ставят на сервера, делают именно так. Они запускают соответствующий процесс "word.exe" или "excel.exe" и дальше управляют им. Не говоря уже про чистоту использования лицензий (эта тема касалась здесь), это еще и не всегда безопасно с точки зрения работы этих приложений.
Тут все просто - в момент создания объекта документа для его обработки как-раз и создается процесс "word.exe". После завершения всех необходимых действий, метод "Quit" закрывает приложение и все работает как надо. Но что, если в момент выполнения алгоритма заполнения произойдет ошибка? Правильно, метод "Quit" не будет выполнен и процесс Word'а останется "висеть". Конечно, можно попытаться обезопасить себя как это рекомендует стандарт разработки 1С и добавить "попытку":
Тут мы пытаемся закрыть приложение и освободить все связанные ресурсы. Часть кейсов это решит, но, к сожалению, не все. Если, например, в момент работы с COM-объектом возникнет не исключение, а падение рабочего процесса, то никакие действия по освобождению ресурсов выполнены не будут и процесс останется висеть в памяти до перезагрузки сервера / компьютера. Ну или пока не будет "убит" принудительно.
К сожалению, при непредвиденном завершении рабочего процесса мы особо ничего не можем сделать для контроля завершения всех запущенных процессов из кода встроенного языка. Все-таки это нештатная ситуация и решать ее можно только нештатными средствами. Почти все "костыли" по этой теме дают сбои в той или иной степени.
А у Вас на сервере бывают ситуации с десятком запущенный процессов "excel.exe"? :)
Альтернативные подходы
В качестве многоточия для этой темы хотел бы упомянуть и альтернативные способы решения проблем с освобождением ресурсов запущенных из 1С процессов:
- Организовать bat/ps/bash скрипт, который будет ночью "убивать" определенные процессы. Например, те же "excel.exe". Костыль? Да. Работает? Да.
- Сохранять в базе 1С (например, в регистре сведений) информацию о запущенных процессах (идентификатор процесса, имя и др.). Ночью или в другое время запускать регл. задание, которое будет проверять завершение этих процессов. Костыль? Да. Работает? Да.
- Перезагружать сервер с периодичностью в несколько дней. О сколько проблем можно решить! :) Костыль? Да. Работает? Да :)))
Список можно продолжать и дальше. Но возможно правильным вариантом будет - поиск решения задач иным способом, а не запуском сторонних процессов. Если такое, конечно, возможно.
Удачи, друзья!
Всем чистого кода, хороших решений и меньше "костылей"! До следующих встреч!
А как Вы работаете со сторонними процессами из 1С?
Другие ссылки
-
- инструмент для выполнения команд CMD / PowerShell из 1С
Авторские разработки
Транслятор запросов 1С в SQL - инструмент для трансляции запросов платформы 1С в SQL, а также их диагностики.
Просмотр и анализ структуры базы данных (отчет на СКД) - отчет для просмотра и анализа структуры базы данных с поддержкой файловых баз (ограниченный режим), а также баз на SQL Server и PostgreSQL.
Просмотр и анализ журнала регистрации (отчет на СКД) - отчет на базе системы компоновки данных (СКД) для просмотра записей журнала регистрации.
История работы пользователей (отчет на СКД) - отчет для просмотра истории работы пользователей (СКД, просмотр для любого пользователя).
Экспорт журнала регистрации. Набор инструментов (приложения + исходный код) - набор инструментов для экспорта данных журнала регистрации во внешние хранилища для Windows и Linux. Готовые приложения и исходный код.
Путеводитель по истории релизов - отчет по истории выпуска релизов продуктов фирмы "1С" и анализа информации по обновлениям.
-
Помощник работы с идентификаторами объектов - инструмент для расширенного анализа идентификаторов объектов.
Анализ производительности APDEX (бесплатный) - отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.
Обозреватель криптографии - отчет для просмотра доступных провайдеров и сертификатов криптографии на сервере и клиенте.
Пакетная выгрузка / загрузка внешних отчетов и обработок - пакетная выгрузка / загрузка внешних отчетов и обработок для массовый манипуляций с ними.
Мастер полнотекстового поиска - набор инструментов для работы с полнотекстовым индексом платформы 1С. Стандартные и расширенные возможности.
Командный интерпретатор для 1С - инструмент для выполнения команд CMD / PowerShell из 1С
PowerShell - это средство автоматизации от компании Microsoft с открытым исходным кодом, которое поддерживается в Windows, Linux, MacOS и даже под ARM. Представляет из себя объектно-ориентированный программный движок и скриптовый язык с интерфейсом командной строки.
Из-за всего этого имеет достаточно большую распространенность и сферу применения. В одной из прошлых публикаций "Командный интерпретатор для 1С" мы рассматривали техническую возможность запуска скриптов на PowerShell из кода встроенного языка платформы 1С. Сегодня же мы рассмотрим небольшие готовые скрипты для отдельных задач, которые могут Вам помочь в повседневной работе, а также немного про установки и настройку этого "монстра".
Фактически, статья показывает как начать разработку скриптов на PowerShell, с каких материалов можно начать и дает примеры скриптов для старта.
Немного об установке
Процесс установки PowerShell различается в зависимости от ОС, ее версии и т.д. Подробнее об установке и обновлении текущих версий рекомендую посмотреть официальную документацию.
Стоит отметить, что в операционной системе Windows есть встроенный движок "Windows PowerShell", который уже немного отстает от актуальных версий. Иногда можно встретить путаницу между Windows PowerShell и актуальной версией PowerShell, которая выпускается уже в кроссплатформенном варианте. Все примеры скриптов ниже тестировались именно на Windows PowerShell, но все новые разработки и скрипты стараюсь делать на актуальных версиях PowerShell, что и Вам рекомендую.
Подробно расписывать шаги установки смысла нет - посмотрите ссылку выше. Там подробная инструкция как для Windows, так и для Linux.
Инструментарий
Еще немного хотелось бы сказать об инструментах для работы с PowerShell. В составе Windows с древних времен идет среда разработки "Windows PowerShell ISE", которой, конечно, можно пользоваться и сейчас. Но даже по внешнему виду можно понять, что она достаточно архаично выглядит, да и большинства удобств современных IDE там просто не найти. Поэтому лучший выбор - это использование Visual Studio Code.
Достаточно установить расширение "PowerShell" и Вы получите отладку, удобный редактор с автоподсказками и многое другое. В статье "Использование Visual Studio Code для разработки в PowerShell" можно найти подробное описание что и как устанавливать, чтобы получить рабочую среду разработки. Также там есть описание дополнительных шагов настройки, которые в некоторых случаях могут понадобиться. Все вышесказанное актуально как для Windows, так и для Linux.
Еще немного слов про терминал. Как известно, в Windows работа с терминалом всегда была не очень удобной. Но с появлением Windows Terminal ситуация изменилась, хоть еще и есть куда стремиться. Теперь, как минимум, мы можем открывать несколько терминалов в одном окне и с разным типом. Вот, например, сразу один терминал PowerShell, два под Linux (через подсистему WSL) и один это старый добрый CMD.
Под Linux список инструментов для работы с терминалом намного больше и сами инструменты функциональней. Для себя использую простой терминал Gnome. Вот можете выбрать себе более подходящий.
Спектр задач
И целой книги не хватит, чтобы описать и пройтись по всему спектру задач, которые решает PowerShell. Но мы и не собирались. Ниже приведено несколько скриптов, которые позволяют примерно понять что и зачем можно делать. Также они могут быть стартовой точкой для начала написания собственных скриптов или целых решений автоматизации.
Это лишь примеры скриптов, не являющиеся готовым решением, поэтому они не оформляются в какой-либо отдельный модуль или пакет. Скорее всего в Вашей ситуации их придется дорабатывать.
Установка и настройка 1С
Начнем с простого - списка установленных версий 1С и команда установки.
Из реестра Windows можно узнать список всех установленных версий 1С (32 и 64 битных).
Теперь мы можем легко получить список установленных версий платформы 1С на хосте.
Как известно, установщики приложений от 1С имеют возможность запуска с указанием параметров в командной строке. Воспользуемся этим.
Примерно этот же способ используют для установки 1С на множестве компьютеров, только каталог с установщиком находится в сетевом каталоге. Но вариантов установки, конечно же, много.
Проще простого, не так ли?
Управление службой
Частой задачей может быть перезапуск службы 1С или по крайней мере просмотр их списка.
Просто получим список установленных служб Windows, где файл приложения "ragent.exe". Искать службу по имени не всегда надежно, ведь их могут зарегистрировать вручную под любым именем.
Теперь у нас есть список с именем службы, ее состоянием и командой запуска.
И еще несколько примеров скриптов. Первый - это запуск остановленных служб 1С.
Далее остановка запущенных служб.
И, конечно же, перезапуск.
Ничего особого тут нет.
И тут тоже ничего сложного.
Старый, добрый COM
До сих пор с 1С во многих компаниях работа выполняется через COM, в том числе и с сервером 1С. Вот несколько команд в помощь для работы с COM.
Не забывайте запускать скрипт с правами администратора для успешной регистрации COM.
Аналогичная ситуация при отмене регистрации COM.
Также необходимы права администратора.
COM с нами еще надолго :)
Кластер под контролем
Еще немного о взаимодействии с кластером 1С.
Получим немного информации о кластере 1С без COM, только по данным службы Windows.
Теперь мы можем получить имя службы, состояние, версию платформы, путь к каталогу кластера 1С, используемые порты и каталог кластера.
Бывает ли у Вас такое, что используется несколько версий 1С и необходимо запускать консоль администрирования серверов 1С разных версий? Этот скрипт должен помочь.
Для регистрации компонентов нужны права администратора. А куда без них.
Пример скрипта, который завершит все сеансы 1С на сервере. Взаимодействие происходит через COM.
Будьте осторожны при запуске. Не сбросьте сеансы в рабочей базе в рабочее время :)
Периодически приходится чистить каталог сеансовых данных, особенно если встречаются непонятные "глюки" в работе сервера 1С.
COM не нужен, но права администратора все равно нужны для остановки и запуска служб.
Еще один пример работы через COM - блокировка работы со всеми информационными базами.
Ну а для снятия блокировки можно использовать следующий скрипт.
Еще один простой скрипт для получения размера сеансовых данных сервера 1С.
Может пригодиться для отслеживания работы сервера.
Многие системы мониторинга сохраняют информацию о сеансах. Следующие скрипты делают это, отправляя данные в базы данных PostgreSQL. Этот для сеансов.
Внутри скрипта также команды для создания базы данных.
А это скрипт для рабочих процессов.
Принцип тот же, что и для сеансов.
Прочь COM, да здравствует RAC
Работа через COM в какой-то мере устарела и все скрипты относятся теперь к легаси. Эффективнее теперь все подобные действия выполнять через RAC.
Вот пример скрипта для блокировки выполнения фоновых заданий для информационных баз.
Для других действий необходимо изучить документацию по RAC.
Только не заставляйте переписать все скрипты с COM на RAC :)
Запуск 1С
Пару лет назад был выпущен модуль "1C.Utils". Там есть хороший скрипт для запуска приложений 1С.
Жаль, что модуль больше не обновляется, но даже эти наработки можно использовать.
Великий SQL Server
Для работы со SQL Server также есть огромный функционал. Работу можно выполнять через ODBC, SMO и многими другими путями. Ниже два небольших примера.
Здесь мы будем использовать готовый модуль DBATools, о возможностях которого нам не хватит и целой статьи рассказать.
Еще один пример работы, но уже с помощью SMO. Здесь мы создаем копию базы данных с включенным сжатием PAGE. Может пригодиться для создания тестовых баз.
У такого подхода есть и еще один плюс - не нужно делать шринк, т.к. данные с нуля создаются в копии базы. Поэтому пустого зарезервированного места в файле данных просто не будет.
Капля в море, но нужно же с чего-то начинать :)
Совсем немного PostgreSQL
Для работы с PostgreSQL также можно использовать PowerShell, даже если установка выполнена на Linux. Следующий скрипт показывает простейший вызов команд с помощью psql.
Фишкой здесь является установка пароля пользователя, от которого выполняется обращение к СУБД, т.к. psql не имеет такого параметра явно. В остальном ничего сложного.
Можно выполнять множество других действий, но для примера оставим только этот скрипт.
Вызов стороннего API
Часто приходится иметь дело с различными REST-сервисами:
- Проверять их доступность
- Управлять учетными записями
- Автоматизировать настройку
- И др.
В этом случае с помощью PowerShell также можно решать поставленные задачи.
Например, с помощью следующего скрипта можно проверить доступность API сервера Zabbix.
Аналогично можно обращаться к любым REST-сервисам. Главное формировать запрос с учетом их требований.
Подобная тема актуальная и при работе с облаками (Azure, AWS и др.) или любыми другими сервисами.
Собственный бот
Очень удобно с этим работать, если оформить в модуль. Но это уже другая история.
Есть решения и для других мессенджеров (WhatsApp, Viber и т.д.), но рассматривать их сейчас не будем.
Отправка писем
Этот скрипт отправляет почту через сервис Yandex.Mail.
У Яндекс есть различные ограничения, о которых стоит прочитать в документации. Например, двухфакторная аутентификация уже не позволит таким способом отправлять почту. Есть и другие нюансы.
А Вы используете электронную почту для уведомлений?
Контролируй процессы
Часто приходится управлять различными процессами в системе. Например, завершить зависшие процессы или узнать потребляемые ими ресурсы. Тут то на сцену выходит PowerShell :)
Примеры команд для получения информации о процессах различными способами.
Кроме получения информации о процессах нужно еще и уметь их останавливать.
В первом примере выполняется остановка процессов по имени. Во втором остановка процессов, которые не отвечают. А третий пример наиболее интересен - завершаются процессы, во время выполнения которых появилась ошибка вида "Visual C++ Runtime Library".
Вот такие процессы и будут завершены.
Имей власть над процессами и будешь властвовать над ОС :)
Проверка свободного порта
Почти каждый сталкивался с проблемой, когда служба 1С могла не запускаться из-за занятого порта другим приложением. Для диагностики нужно проверить кто нужный порт занял. Тут на сцену выходит.
С помощью скрипта можно узнать кто и как занял порт.
Главное раскомментировать нужное условие для фильтрации результата.
Теперь можно не гадать, почему служба 1С не запустилась :)
Удаленное управление
PowerShell позволяет выполнять скрипты / команды на удаленных машинах, что значительно упрощает решение задач администрирования. Решается это с помощью PSRemoting. Ранее все удаленные взаимодействия выполнялись через WinRM, теперь же появилась возможность работать и через SSH. Вот материалы по удаленному управлению:
Ниже пример настройки для Windows и выполнение удаленной команды.
На обоих машинах нужно обязательно установить PowerShell и включить удаленное управление. Ниже пример скрипта для настройки.
Нужно учитывать, что это лишь пример скрипта, который не годится для рабочего окружения.
После настройки можно выполнять любой скрипт на удаленной машине. Ниже пример перезапуска удаленного хоста.
Никто не мешает удаленно выполнить любой скрипт из тех, что были показаны выше.
Еще еще еще
На этом примеры скриптов закончим. Многие другие скрипты и примеры можно найти в таких источниках:
- PowerShell- набор публичных скриптов под разные задачи.
- PowerShellTools- еще один репозиторий со скриптами.
А теперь пойдем дальше.
Меньше костылей
Создавать свои скрипты - это нормально, но некоторые задачи уже были решены до нас и мы можем этот опыт использовать. В контексте PowerShell это либо использовать скрипты других разработчиков, либо брать на вооружение целые готовые модули PowerShell от сообщества или компаний (обычно выпускают вместе с каким-либо продуктом, как это делает та же Microsoft).
В самом конце
Вместо использования готовых решений, сообщество и сама фирма "1С" пошли своим путем, создавая собственные инструменты автоматизации. Причем фирма "1С" проигнорировала труды сообщества в виде OneScript и создает собственный инструмент - 1С:Исполнитель.
Конечно, чем больше инструментов, тем лучше. Но средства автоматизации создаются не только для разработчиков 1С, но и для администраторов, DevOps'ов и других специалистов, которые могут и не иметь прямого отношения к 1С. А если администратору нужно будет автоматизировать процесс разворачивания клиентов 1С, сбор информации с сервера 1С или другую задачу автоматизации, то зачем ему изучать OneScript или 1С:Исполнитель? А ставить для их работы дополнительные компоненты, о которых в не1Сном сообществе не слышали и не могут доверять им.
Автор не противник OneScript или 1С:Исполнитель. Я фанат PowerShell и немного Bash. Понимаю, что коллеги проделали большую работу и продукт взлетел в определенном смысле. Но может сообществу 1С пора быть более открытым и не замыкаться свою экосистему саму на себя?
P.S. Все это риторические вопросы. Но если Вам есть что сказать - комментарии именно для этого.
P.P.S. Внимание! Если Вы пишите токсичный комментарий или добавляете сарказм, то пожалуйста добавьте его под спойлер, чтобы их читали только те, кому это действительно интересно :)))))
Другие ссылки
- Официальная документация по продуктам PowerShell.
- PowerShell на GitHub
- Командный интерпретатор для 1С
- Режим агента конфигуратора
- Полуавтоматическое обновление 1С посредством PowerShell
- 1С и PowerShell - обновление из хранилища
- Автозагрузка, установка платформы 1С (PowerShell)
- Мониторинг журнала регистрации при помощи Powershell
Авторские разработки
Анализ производительности APDEX - отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.
Путеводитель по истории релизов - отчет по истории выпуска релизов продуктов фирмы "1С" и анализа информации по обновлениям.
Просмотр и анализ структуры базы данных (отчет на СКД) - отчет для просмотра и анализа структуры базы данных с поддержкой файловых баз (ограниченный режим), а также баз на SQL Server и PostgreSQL.
Просмотр и анализ журнала регистрации (отчет на СКД) - отчет на базе системы компоновки данных (СКД) для просмотра записей журнала регистрации.
Обозреватель криптографии - отчет для просмотра доступных провайдеров и сертификатов криптографии на сервере и клиенте.
Пакетная выгрузка / загрузка внешних отчетов и обработок - пакетная выгрузка / загрузка внешних отчетов и обработок для массовый манипуляций с ними.
Командный интерпретатор для 1С - инструмент для выполнения команд CMD / PowerShell из 1С.
-
Помощник работы с идентификаторами объектов - инструмент для расширенного анализа идентификаторов объектов.
Анализ производительности APDEX (бесплатный) - отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.
Обозреватель криптографии - отчет для просмотра доступных провайдеров и сертификатов криптографии на сервере и клиенте.
Пакетная выгрузка / загрузка внешних отчетов и обработок - пакетная выгрузка / загрузка внешних отчетов и обработок для массовый манипуляций с ними.
Мастер полнотекстового поиска - набор инструментов для работы с полнотекстовым индексом платформы 1С. Стандартные и расширенные возможности.
Командный интерпретатор для 1С - инструмент для выполнения команд CMD / PowerShell из 1С
Диагностика контекста выполнения (внешняя компонента) - небольшая экспериментальная внешняя компонента для получения дополнительной информации о контексте выполнения.
Экспорт технологического журнала. Набор инструментов (приложения + исходный код) - набор инструментов для экспорта данных технологического журнала во внешнее хранилище для Windows и Linux.
Экспорт журнала регистрации. Набор инструментов (приложения + исходный код) - набор инструментов для экспорта данных журнала регистрации во внешние хранилища для Windows и Linux (SQL Server, PostgreSQL, MySQL, ClickHouse, ElasticSearch).
За несколько лет сначала вынужденного, а потом и вполне занимательного администрирования 1С у меня накопился набор решений под большинство особенностей продукта. Предлагаю отложить в сторону высокие материи про кластеры и тюнинг SQL, и перетряхнуть запасы скриптов и механизмов, которые облегчают жизнь с 1С.
Будут как простые инструменты создания новых пользователей и мониторинга "все ли вышли из базы", так и более изощренные интерфейсы проверки целостности базы и ее перемещения.
Как у большинства сложных приложений, у 1С через некоторое время работы вылезают странные ошибки, и возникает порой необъяснимое поведение. Специальные люди по 1С советуют в таких случаях почистить кэш.
Если запустить 1С с параметром /ClearCache, то будут очищены только клиент-серверные запросы. Локальные метаданные останутся и их нужно удалять отдельно на уровне файлов и папок. Эти данные хранятся в профиле пользователя, в папках с длинными названиями из GUID баз данных. Если баз на сервере немного, то такой кэш нетрудно удалить руками. Но если БД исчисляется десятками, то чистке вручную вы не обрадуетесь.
В подобных ситуациях выручит скрипт на Powershell, который запускается каждый раз при выходе пользователя из системы:
И никаких связанных со старым кэшем проблем.
Для исправления испорченной файловой базы в поставку 1С входит утилита chdbfl.exe, которая просто считывает содержимое базы во временный файл. Если какие-то данные считать не может — пропускает. При этом у нее нет ключей запуска для автоматизации, и проверку приходится запускать вручную.
Вообще, правильнее запускать проверку БД конфигуратором, но этот процесс проходит значительно дольше. Если же использовать только проверку физической целостности средствами chdbfl.exe, то не забывайте делать резервную копию из-за возможной потери данных.
Для баз 8.1 Андрей Скляров создал хороший инструмент Check1CD, с двумя параметрами запуска: "исправлять найденные ошибки" и “путь к базе”.
Но в Check1CD не хватает двух вещей:
Раз есть "хотелка" и немного свободного времени, то почему бы не попробовать решить вопрос самостоятельно?
Доработать код для передачи параметров через ключи командной строки — дело техники.
С выходом 1С 8.2 возникла проблема — путь к chdbfl менялся с установкой нового релиза. Что ж, дополним скрипт:
Надо сказать, недавно был опубликован исходный код Check1CD. Да, тоже на AutoIT.
Аналогичный механизм можно применять и для автоматического запуска различных регламентных механизмов, где нужно запускать 1С и ждать завершения операции.
При различных регламентных операциях с 1С (ночное обновление конфигурации или бэкап в .dt) важно обеспечить отсутствие подключенных к ней пользователей. Можно конечно запускать 1С: Предприятие с ключом /C ЗавершитьРаботуПользователей, но это не всегда удобно, да и хочется же потом написать личное письмо с рекомендациями по устранению склероза.
Можно использовать штатную возможность подключения к 1С через COMConnector и скрипт на AutoIT. Код написан под 1С 8.1 и позволяет выкинуть пользователей из базы с записью в журнал.
Но операцию иногда нужно проворачивать по просьбе самого пользователя, который запустил "тяжелый" отчет и повесил 1С. Если не хотите решать эти вопросы самостоятельно, то просто выведите любителям “тяжелых” отчётов ярлык на скомпилированный скрипт:
Еще COMConnector помогает проверить наличие обновлений конфигурации, получить какую-то информацию из базы, и автоматизировать заведение пользователей в 1С.
На мой взгляд, создавать новых пользователей 1С должен системный администратор, а не программист 1С. Но последнему нужно сделать процесс максимально простым. Чтобы администратору не приходилось "заглядывать" в каждую базу отдельно, можно использовать еще один скрипт.
Юрлиц развелось слишком много — нужно разбивать на столбцы.
Занятно, но после смены нескольких поколений администраторов в одной компании из далекого прошлого новенькие уже не знали как создать пользователя вручную.
Если нужно перенести базу 1С: Предприятия вместе с ее данными в SQL на другой сервер, то делать это вручную целесообразно только для 1-2 БД.
Список баз для миграции можно брать и из файла, а лог выводить в текстовый файл. Аналогичным образом можно конвертировать несколько десятков баз из файловых в SQL простой выгрузкой-загрузкой в .dt
Конечно, это далеко не все, что можно автоматизировать в связке с 1С. Но разного рода обмены, получение real-time информации из 1С в других приложениях и прочие сценарии не попали в этот обзор из-за узкой направленности и специфики.
Наверняка у вас тоже есть свой набор "ноу хау" для администрирования 1С — будет здорово если поделитесь с коллегами в комментариях.
Скрипты и ноу-хау предоставлены avelor, за что ему огромное спасибо!
Во второй части цикла рассматривались основы языка программирования PowerShell, а сейчас стоит разобраться с использованием написанного на нем кода для задач администрирования. Самый очевидный способ это сделать — запустить сценарий. Кроме него существует возможность создания собственных командлетов.
Оглавление:
Позиционные параметры
В сценарии и функции можно передавать позиционные параметры (аргументы), значения которых записываются во встроенную переменную $args. Этот одномерный массив не требует предварительного объявления, а область его видимости ограничивается скриптом или функцией. Для примера запустим простейший сценарий:
В функциях позиционные параметры используются аналогично:
Print-Args «Ноль» «Один»
Обратите внимание, что при вызове Print-Args мы не ставим запятую между параметрами: в функцию передается не массив, а отдельные значения, которые записываются в одномерный массив $args — его область видимости ограничена телом функции.
Описанный выше способ позволяет передать в сценарий или функцию любое количество параметров, но при вызове необходимо соблюдать порядок их следования, а обращаться к ним можно только по индексу массива — это не всегда удобно.
Блок Param()
В сценариях и функциях намного удобнее использовать именованные параметры. В предыдущей статье мы рассказывали об одном способе их описания:
Подобный синтаксис привычен разработчикам, но при вызове функции параметры (если они есть) разделяются пробелами, а не заключаются в круглые скобки — возникает некоторый диссонанс. Такова специфика shell-языков: для работы с командным интерпретатором в интерактивном режиме пробелы между значениями намного удобнее. Вызов test($value0) также корректен, но параметром при этом является все выражение в скобках, т.е. ($value0) вместо $value0. Передать таким способом несколько параметров уже не выйдет. В результате вызова test($value0, $value1) функция получит только один — массив из двух элементов со значениями $value0 и $value1.
Корпорация Microsoft рекомендует использовать блок Param() — этот синтаксис более универсален и позволяет задавать не только аргументы функций, но и параметры сценариев:
В теле функции это выглядит так:
Если список аргументов функции невелик, блок Param() только загромоздит конструкцию, но во многих случаях он делает код более читаемым и является помимо прочего элементом хорошего стиля программирования.
Дополнительные атрибуты параметров
При описании аргументов функции или параметров скрипта можно задать их дополнительные атрибуты. Самый простой пример — принудительная установка типа:
Помимо приведения типов можно использовать атрибут [parameter()]:
С его помощью нетрудно сделать параметр обязательным. Обратите внимание на одновременное использование нескольких атрибутов — в этом случае они идут друг за другом:
Position позволяет указать порядок следования параметра (по умолчанию он соответствует порядку объявления):
У атрибута [Parameter()] есть и другие аргументы, полный список которых доступен на сайте Microsoft. Там же описаны прочие атрибуты, с помощью которых можно провести валидацию переданных значений, проверить их с использованием регулярных выражений и т.д. Перечислим некоторые:
[Alias()] устанавливает псевдоним для параметра:
Оператор приведения типов [string[]] означает, что значение параметра — строковый массив.
[AllowNull()] разрешает $null в качестве обязательного параметра:
[AllowEmptyString()] разрешает пустую строку в качестве обязательного параметра:
[AllowEmptyCollection()] разрешает пустой массив в качестве обязательного параметра:
[ValidatePattern()] проверка с использованием регулярного выражения:
[ValidateLength()] проверяет длину строкового параметра:
Передача параметров через конвейер
В первой статье цикла мы рассказывали о возможности передачи данных в командлеты через конвейер (pipeline). В PowerShell командлеты и функции возвращают объекты или массивы объектов (результаты стейтментов), а также получают их на входе. Чтобы это увидеть, препарируем один из командлетов при помощи Get-Help:
Через конвейер можно принять значения параметров, для которых установлены соответствующие атрибуты (ByValue и/или ByPropertyName). В первом случае параметру будет сопоставлен поступивший по конвейеру объект при условии, что его тип соответствует ожидаемому. Во втором значением параметра будет свойство входящего объекта, имя которого соответствует имени или псевдониму этого параметра. Для установки атрибутов используется [parameter()] с булевыми аргументами ValueFromPipeline и ValueFromPipelineByPropertyName, значение которых по умолчанию равно $false:
ValueFromPipelineByPropertyName обычно используют при необходимости передать несколько параметров, чтобы не возникало путаницы, при этом аргумент можно применять одновременно с ValueFromPipeline:
Как видите, получать параметры через конвейер могут и скрипты, но все же практическое применение описанных выше атрибутов характерно скорее для расширенных функций, которые будут рассмотрены ниже.
Структура тела функции
В языке PowerShell функция может включать три необязательных блока заключенного в операторные скобки кода — Begin, Process и End. Выглядит она примерно так:
Первым однократно выполняется блок Begin, причем если параметры передаются в функцию через конвейер, код запустится еще до поступления первого объекта на обработку. Переменные $_ и $PSItem в блоке Begin в этом случае не будут содержать значений. Если же функция вызывается с использованием явным образом заданных параметров, они будут доступны и в блоке Begin, поскольку нет необходимости ожидать получения объектов из конвейера. Далее выполняется блок Process: если параметры передаются через конвейер, он будет поочередно запущен для каждого объекта. В случае явным образом заданных параметров блок Process запустится только один раз. Завершается работа функции однократным выполнением блока End. Очевидно, что использование этих конструкций оправдано, только если функция может принимать объекты из конвейера:
'один', 'два', 'три' | test -Param2 'четыре'
Атрибут [CmdletBinding()] и расширенные функции
На самом деле [CmdletBinding()] инициализирует новый экземпляр класса CmdletBindingAttribute через вызов конструктора, которому можно передать необязательные аргументы. Их подробное описание есть на сайте Microsoft. Атрибут CmdletBinding позволяет контролировать дополнительные возможности расширенной функции: добавление поддержки -Confirm и -WhatIf (через SupportsShouldProcess), -Force, -Verbose и -Debug, а также отключение позиционного связывания параметров и т.д. Дальше мы разберем использование специальных параметров.
Параметр -Force применяется для подавления запросов на проведение различных операций;
-WhatIf нужен для эмуляции запуска и отображения информации о последствиях выполнения функции (команды) без этого параметра. Обычно используется, если функция может выполнить деструктивные действия.
Remove-Item C:\Windows\notepad.exe -WhatIf
-Confirm требует подтверждения и также используется, если функция может выполнить деструктивные действия.
Для обработки -WhatIf и/или -Confirm вызывается метод ShouldProcess (SupportsShouldProcess=$true), который выводит запрос или эмулирует выполнение команды. Чтобы реализовать обработку -Force, мы поместили его первым в условие IF. Сначала проверяется выражение слева от оператора -or и если оно истинно, проверка останавливается — метод ShouldProcess вызываться не будет. Также в атрибуте [CmdletBinding()] мы указали аргумент ConfirmImpact, определяющий уровень воздействия кода на систему и включающий обработчик параметра -Confirm. Этот аргумент может принимать следующие значения:
Low — функция незначительно воздействует на систему и не создает существенных рисков потери данных.
Medium — среднее воздействие с незначительным риском потери данных в результате деструктивных действий.
High — код создает высокий риск потери данных в результате деструктивных действий.
По умолчанию для сессии PowerShell уровень воздействия считается высоким (High). Актуальное значение хранится в переменной $ConfirmPreference и если у кода уровень воздействия на систему такой же или более высокий, запрос на подтверждение будет выводиться всегда.
Параметры -Verbose и -Debug нужны для вывода отладочной информации. Их использование считается хорошим стилем программирования (забудьте про Write-Host, в расширенных функциях это не нужно). Первый параметр выводит информацию о ходе выполнения, а второй — детальную отладочную информацию. Также он дает возможность переключиться на пошаговое выполнение кода. Поведение -Verbose и -Debug определяется примерно так:
Для работы со специальными параметрами мы использовали переменную $PSBoundParameters. По умолчанию значения $VerbosePreference и $DebugPreference равны 'SilentlyContinue', поэтому даже при указании соответствующих параметров отладочная информация выводиться не будет — их нужно перевести в состояние 'Continue'.
Модули сценариев и создание командлетов
Приступим к созданию собственных командлетов. По сути это расширенные функции, которые описаны в т.н. модулях сценариев — текстовых файлах с расширением .psm1. Хранятся они в каталогах, определенных в переменной окружения PSModulePath. Посмотреть пути к ним можно при помощи следующей команды:
Get-ChildItem Env:\PSModulePath | Format-Table -AutoSize
Стандартный набор выглядит примерно так:
C:\Users\%UserName%\Documents\WindowsPowerShell\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\Windows\System32\WindowsPowerShell\v1.0\Modules
После создания файла ModuleName.psm1 с расширенной функцией Delete-File из предыдущего раздела, его нужно сохранить, например, в ]C:\Users\%UserName%\Documents\WindowsPowerShell\Modules\ModuleName. Обратите внимание, что модуль сценариев должен храниться в отдельном подкаталоге, имя которого совпадает с базовым именем (без расширения) файла .psm1. После запуска команды Import-Module ModuleName функция Delete-File станет доступна пользователю, а поскольку она расширенная, с практической точки зрения это тот же командлет.
В этой статье мы достаточно подробно разобрали передачу параметров в функции и скрипты. Следующая часть цикла будет посвящена объектно-ориентированному программированию.
Читайте также: