Как получить исполняемый файл с произвольным именем
Обновлено: 30.06.2024
При использовании нашего SDK Integrations SDK для мониторинга инфраструктуры для создания пользовательской интеграции на хосте интеграция будет состоять как минимум из трех файлов: исполняемого файла и как минимум одного файла конфигурации. Исполняемый файл генерирует данные JSON, которые используются агентом мониторинга инфраструктуры и отправляются в New Relic. Мы называем объект JSON протоколом интеграции SDK.
Требования к исполняемому файлу
Исполняемым файлом может быть любой файл, который запускается из интерфейса командной строки; например:
- Сценарий оболочки
- Скрипт на языке сценариев
- Скомпилированный двоичный файл
Единственным требованием к вашему исполняемому файлу является то, что он должен экспортировать данные JSON в однострочном формате, который соответствует спецификациям, изложенным в этом документе.
Рекомендация: используйте Go для создания интеграций; это язык, который мы используем для создания локальных интеграций и инструментов построения интеграции. Однако вы можете создать интеграцию на любом языке.
Исполняемый файл находится в этом каталоге:
Линукс:
Windows:
Протокол интеграции v4: пример вывода JSON
В следующем разделе объясняется новая схема JSON (протокол интеграции v4). SDK v4 поддерживает только эту новую версию протокола. Вот самые важные изменения:
- Новый объект интеграции на верхнем уровне.
- Объекты сущности и показателей были изменены.
Дополнительную информацию см. в руководстве по переходу с версии 3 на версию 4.
Протокол интеграции v3: пример вывода JSON
JSON включает:
- Заголовок с основными данными интеграции (название, версия)
- Список данных, который включает один или несколько объектов, сообщающих данные (показатели, инвентарь и/или данные о событиях).
Вот пример вывода JSON (отформатирован с разрывами строк для удобочитаемости). Определения и спецификации следуют этому примеру:
JSON: общие характеристики
Вот общие характеристики вывода JSON:
Общий вывод и форматирование JSONДанные выводятся на стандартный вывод (стандартный вывод) в формате JSON. Агент будет обрабатывать файловые дескрипторы stdout и stderr как построчные буферы.
Используйте для вывода стандартный JSON, а не "красиво напечатанный" JSON. Рекомендация: включите необязательный параметр командной строки (например, --pretty ), чтобы сделать JSON "красиво напечатанным" для целей отладки.
Ошибки и ведение журналаИнформация об ошибках и отладке должна передаваться в stderr (стандартная ошибка). Следуйте рекомендациям и рекомендациям New Relic по ведению журнала интеграции.
Выход/закрытие исполняемого файлаКод выхода должен завершаться с кодом состояния 0 и соответствовать соглашениям для конкретных платформ. Например:
Linux: 0 == EX_OK
Windows: 0 == ERROR_SUCCESS
Если исполняемый файл завершается с ненулевым статусом, агент отбрасывает все данные из стандартного вывода и записывает в свой файл журнала сообщение с именем интеграции, кодом выхода и любой диагностической информацией, которую он может собрать.< /p>
Вот пример первой части вывода JSON интеграции на хосте:
Минимальной полезной нагрузкой будет объект JSON только с полями заголовка. Рекомендация: если нет данных для сбора, используйте код возврата программы и сообщения журнала, записываемые в stderr .
Поля заголовка JSON
Обязательно. Должно совпадать с полем имени в файле конфигурации.
Рекомендация: используйте обратные доменные имена для создания уникальных имен интеграции.
Обязательно. Номер версии протокола обмена между интеграцией и агентом, который использует исполняемый файл интеграции.
Текущая версия – 3. Для этого протокола требуется агент инфраструктуры 1.2.25 или более поздней версии.
Для протокола 2 требуется агент инфраструктуры 1.0.859 или более поздней версии.
Протокол 1 совместим со всеми агентами.
Дополнительную информацию см. в разделе Изменения SDK.
Необязательно. Интеграционная версия. Используется для отслеживания версии интеграции, работающей на каждом хосте.
Интеграция может иметь более одного исполняемого файла. Следовательно, это не просто версия исполняемого файла.
Необходимо для представления данных. Список, содержащий данные, полученные от одного или нескольких объектов.
В списке данных вывода JSON есть один или несколько объектов. Поля ввода сущности включают:
Поля объекта JSON
Обязательно. Данные или свойства объекта.
Необязательно. Список показателей, связанных с объектом.
Необязательно. Элементы инвентаря, связанные с сущностью.
Необязательно. Список событий, связанных с сущностью.
Необязательно. логический. Если задано значение true , метрики объекта будут дополнены именем хоста .
В списке данных вывода JSON находится один или несколько объектов и их данные. Запись сущности имеет два поля:
Поля данных объекта JSON
Обязательно. Идентификатор/имя объекта.
Рекомендация: используйте обратные доменные имена для создания уникальных имен интеграции.
Обязательно. Вид сущности. Он будет использоваться агентом инфраструктуры в качестве пространства имен для создания уникального идентификатора в сочетании с именем .
Необязательно. Список атрибутов ключ-значение, которые обеспечивают уникальность объекта. Они присоединяются к имени в форме ключ=значение, чтобы упростить чтение, предоставить дополнительную информацию и повысить уникальность имени объекта.
Атрибуты идентификатора полезны, когда имени объекта недостаточно для работы в качестве уникального идентификатора или когда оно не предоставляет достаточно значимой информации. Например:
Замена адресов обратной связи в именах сущностей
Начиная с версии агента инфраструктуры 1.2.25 или выше, протокол v3 улучшает уникальность удаленных объектов, добавляя замену локального адреса в именах объектов на уровне агента.
Если имя нескольких удаленных объектов основано на конечной точке (IP-адресе или имени хоста ) и это имя содержит петлевые адреса, возникает две проблемы:
- Это значение localhost не предоставляет ценной информации без дополнительного контекста.
- Имя может конфликтовать с другой службой, названной с локальным адресом.
Это происходит, когда:
- Имена конечных точек похожи на localhost:port .
- Порты, как правило, одинаковы для данной службы; например, 3306 для Mysql.
Во входящих данных протокола v3 агент инфраструктуры заменяет петлевые адреса в имени объекта (и ключе) первым доступным элементом из следующего списка:
- Идентификатор экземпляра облачного провайдера, полученный агентом, если применимо.
- Отображаемое имя, заданное с помощью параметра конфигурации агента display_name
- Имя хоста, полученное агентом
Например, если интеграция с использованием протокола v3 возвращает объект с именем localhost:3306 , а агент работает на «голом железе» (без идентификатора экземпляра облачного провайдера), display_name не задано, а имя хоста prod-mysql-01 , тогда агент заменит локальный хост и создаст имя объекта prod-mysql-01:3306 .
Агент инфраструктуры позволяет автоматически заменять адрес замыкания на себя для протокола интеграции v3. Вы также можете включить это для v2 с помощью флага конфигурации агента replace_v2_loopback_entity_names . В этом случае у всех интеграций, запускаемых агентом с использованием v2, будут заменены имена всякий раз, когда они содержат локальный адрес.
JSON: показатели, инвентарь и данные о событиях
Значения данных следуют за заголовком исполняемого файла. Вы можете записывать три типа данных:
Важно
С точки зрения информационных панелей New Relic метрики инфраструктуры и события классифицируются как данные о событиях.
Метрические данныеДанные показателей инфраструктуры обычно используются для простых числовых данных; например:
Количество запросов MySQL в очереди в секунду
Количество активных подключений к определенной системе в минуту
Помимо связанных метаданных, метрика — это, по сути, просто имя метрики и числовое значение. Чтобы узнать больше об этих данных, см. раздел Данные о событиях.
Вот пример данных метрики объекта в формате JSON:
Поле данных метрики JSON
Обязательно. event_type определяет, где будут храниться метрики. Каждый набор метрик хранится как образец внутри указанного типа события. Каждая интеграция должна хранить свои данные в своем собственном типе события. Если вы создаете несколько типов образцов из одной и той же интеграции, используйте разные типы событий для каждого из них.
Рекомендация: чтобы типы событий, используемые вашей интеграцией, были уникальными, добавляйте к типу события префикс с названием вашей компании или аббревиатурой. Например, если ваша пользовательская интеграция фиксирует метрики узла Cassandra и метрики семейства столбцов Cassandra в виде разных образцов, сохраните их в разных типах событий, таких как MyOrgCassandraSample и MyOrgCassandraColumnFamilySample .
Если тип события не существует, он будет создан автоматически, когда New Relic получит данные от вашей интеграции и сделает их доступными в пользовательском интерфейсе.
Одна или несколько пар ключ/значение данных метрики
Обязательно (хотя бы одно). Измерение метрики, содержащее имя (ключ) и его значение. Убедитесь, что они в целом соответствуют спецификации типа объекта для максимальной совместимости с функциями инфраструктуры.
Рекомендация: добавьте к метрике префикс категории, чтобы упростить навигацию по метрикам в пользовательском интерфейсе New Relic. В настоящее время интеграции New Relic используют:
net : количество подключений, запросов веб-сервера, байтов, переданных по сети, и т. д.; например, net.connectionsActive .
db : показатели внутренней базы данных; например, db.openTables .
Используйте многоуровневые префиксы для дополнительной группировки, когда это целесообразно; например, db.innodb.bufferPoolPagesFree .
Используйте формат именования innerCamelCase; например: net.requestsPerSecond .
Используйте название метрики как можно ближе к исходному, соблюдая при этом другие требования. Например:
Исходное название: Qcache_hits
Имя метрики: db.qCacheHits
Рекомендация. Укажите единицу измерения с помощью суффикса, если он еще не включен в исходное название показателя, как в следующих примерах:
- Проценты: используйте проценты; например: cpuUtilPercent .
- Коэффициенты: используйте такой формат, как PerSecond . Секунды — это стандартное измерение скорости, но вы также можете использовать другие единицы измерения, такие как "минута" или "день" .
- Измерения в байтах: используйте байты . Рекомендация. Если метрика измеряется в других единицах, например в мегабайтах, преобразуйте ее в байты. Например: db.allMemtablesOffHeapSizeBytes .
- Измерение времени: используйте миллисекунды . Рекомендация. Если метрика фиксируется в других единицах измерения, например, в секундах, преобразуйте ее в миллисекунды. Например: query.readLatency50thPercentileMilliseconds
Используйте строку или число (целое или с плавающей запятой). Строки можно использовать в качестве связанных метаданных, что позволяет фильтровать данные в пользовательском интерфейсе New Relic. Логическое значение должно быть выражено либо в виде строки ("true", "false"), либо в виде целого числа (1, 0). Не используйте сложные типы значений, такие как массивы или хэши.
Данные событияДанные об инфраструктурных событиях представляют собой произвольные разовые сообщения о ключевых действиях в системе; например:
Запуск определенной службы
Создание новой таблицы
Эти данные можно просмотреть на странице "События инфраструктуры" и на тепловой карте событий инфраструктуры. Вы также можете запросить тип события InfrastructureEvent в New Relic.
Вот пример полезной нагрузки JSON данных события интеграции, которая следует за заголовком JSON и определениями полей.
У вас есть новое программное обеспечение для Windows, которым вы хотите поделиться со всем миром? Вот как создать свой собственный установочный пакет EXE!
Что вы делаете, когда создаете новое программное обеспечение для Windows — от простого диагностического инструмента до сложной видеоигры для ПК — и хотите поделиться им со всем миром? Ну, вы можете сжать файлы в один ZIP-файл и распространять его.
Или вы можете проявить фантазию и вместо этого создать EXE-файл установщика.
В этом посте мы рассмотрим три разных способа создания EXE-файла: самораспаковывающийся пакет, простой установщик с использованием встроенного IExpress и расширенный установщик с помощью настраиваемого Inno Setup.
1. Создайте быстрый EXE-файл с помощью 7-Zip
Возможно, вы уже используете 7-Zip для извлечения всех типов архивных файлов и знаете, что 7-Zip может создавать архивные файлы, но знаете ли вы, что вы также можете использовать его для создания EXE-файла, который действует как установщик?< /p>
Он называется SFX-архивом (самораспаковывающимся) и работает, сжимая все ваши конечные файлы вместе, а затем встраивая в архив специальный файл EXE, который знает, как извлечь все.
Другими словами, получатель может извлечь SFX-архив (который выглядит как EXE-файл), даже если у него нет нужного программного обеспечения, что может произойти с такими форматами, как 7Z, RAR, TAR и ZIP.
Вот как создать архив SFX с помощью 7-Zip:
- Подготовьте все свои файлы и каталоги в одном главном каталоге и назовите этот каталог как хотите.
- Щелкните правой кнопкой мыши каталог и выберите 7-Zip > Добавить в архив.
- В разделе «Параметры» включите «Создать архив SFX» и выберите следующие параметры. > Формат архива: 7z> Уровень сжатия: Обычный> Метод сжатия: LZMA2> Размер словаря: 16 МБ> Размер слова: 32> Размер сплошного блока: 2 ГБ
- Наконец нажмите OK.
Обратите внимание, что SFX-архивы не являются настоящими установочными файлами. Они не помещают извлеченные файлы в назначенный целевой каталог. Они не изменяют реестр Windows. Кроме того, они не создают журналы установки и не отображаются как установленное программное обеспечение в приложении для удаления. Это буквально архивные файлы, одетые как EXE-файлы.
Загрузить: 7-Zip для Windows (бесплатно)
2. Как использовать IExpress для простого создания EXE
IExpress – это утилита, поставляемая в комплекте с версиями Windows, начиная с Windows XP и выше. Утилита поставляется с интерфейсным графическим интерфейсом (называемым IExpress Wizard), но вы также можете создавать файлы установщика, используя файлы директивы самоизвлечения (SED), созданные вручную. Мы рекомендуем Мастера.
Как и описанный выше 7-Zip, этот метод создает самораспаковывающийся архив, но с двумя основными отличиями: во-первых, конечный пользователь будет выполнять многостраничный мастер установки, а во-вторых, конечный пользователь может указать целевой каталог, в который инструмент будет извлекать файлы.
А вот как вы создаете EXE-файл установщика с помощью IExpress:
- Откройте окно «Выполнить» (клавиша Windows + R) и введите iexpress.exe, чтобы запустить мастер IExpress.
- Выберите «Создать новый файл директивы самоизвлечения» и нажмите «Далее».
- Выберите «Извлекать только файлы» и нажмите «Далее».
- Что касается названия пакета, безопасным выбором будет название вашего приложения.
- Для запроса на подтверждение выберите «Без запроса» или «Запрашивать пользователя с помощью». Это не имеет значения в любом случае. Для конечного пользователя включение одного — это всегда безопасный выбор.
- Для лицензионного соглашения выберите Показать лицензию, если вы хотите, чтобы конечный пользователь принял лицензионное соглашение с конечным пользователем (EULA). Если нет, можно выбрать Не отображать лицензию.
- Добавьте все файлы, которые вы хотите видеть установленными, нажав кнопку "Добавить", просмотрев расположение файлов и выбрав их все.
- Продолжите работу с мастером IExpress и выберите нужные параметры для подсказок "Показать окно" и "Завершенное сообщение".
- Чтобы узнать имя пакета, нажмите «Обзор», перейдите туда, где вы хотите создать EXE-файл установщика, и дайте ему имя. Это EXE-файл, который вы собираетесь распространять среди конечных пользователей. Нажмите "Далее".
- Наконец, выберите Сохранить файл директивы самоизвлечения (SED), если вы хотите создать измененный установщик позже, например, когда вы исправили программное обеспечение и вам нужен обновленный установщик. Если вы выберете Не сохранять, вам придется выполнить весь процесс с нуля.
- На странице "Создать пакет" нажмите "Далее".
Ваш пакет будет создан через несколько минут. Обратите внимание, что у IExpress есть некоторые особенности и проблемы:
- Не допускается включение пустых каталогов.
- Если в вашей установке есть подкаталоги, они не будут включены.
- Если у вас есть несколько файлов с одинаковыми именами, даже в разных каталогах, создание установщика завершится ошибкой.
Из-за этих странностей мы рекомендуем вместо этого использовать метод, описанный ниже.
3. Лучший способ создать EXE: использовать Inno Setup
Inno Setup – это утилита с открытым исходным кодом, которая активно разрабатывается с 1997 года. Она была создана частично в ответ на существовавшую в то время подпараметр InstallShield Express. С тех пор он стал предпочтительным установщиком для тех, кто не хочет изучать проприетарные варианты.
Самым большим преимуществом является гибкость. Inno Setup использует файлы сценариев с расширением ISS («Inno Setup Script») для настройки различных аспектов установщика: какие файлы включаются, где происходит установка, создавать ли ярлыки и т. д. Файлы ISS используют формат, аналогичный файлам INI, и можно создать с помощью мастера установки Inno.
Чтобы создать установщик с помощью Inno Setup, запустите приложение Inno Setup Compiler. В приветственном приглашении выберите Создать новый файл сценария с помощью мастера сценариев. Оттуда введите имя приложения и версию приложения. При желании вы также можете включить сведения об издателе приложения и веб-сайте приложения. Нажмите «Далее».
- Теперь выберите базовую папку назначения, по умолчанию это Program Files.
- Введите имя папки приложения, которое является именем основного каталога, в который будут помещены ваши установочные файлы. Нажмите "Далее".
- Для главного исполняемого файла приложения найдите и выберите основной EXE-файл, который запустит ваше приложение.
- Если вы не устанавливаете приложение, включите его. У приложения нет основного исполняемого файла. Затем добавьте файлы и папки в свою установку с помощью команды Добавить файлы. и Добавить папки. кнопки. Нажмите "Далее".
- На странице ярлыков приложений оставьте значения по умолчанию или измените их в соответствии со своими предпочтениями. Они все говорят сами за себя. Нажмите "Далее".
- На странице документации приложения вы можете указать до трех файлов TXT, которые будут отображаться на протяжении всего процесса установки конечного пользователя. Как правило, это LICENSE.TXT, INSTALL.TXT и README.TXT, но они могут быть любыми. Нажмите "Далее".
- На странице «Языки настройки» оставьте английский, но вы можете добавить любое количество других языков. Нажмите "Далее".
Теперь выполните следующие действия, описанные ниже:
На странице настроек компилятора вы можете настроить EXE-файл установщика:
- Выходная папка пользовательского компилятора — это место, куда будет помещен результирующий EXE-файл установщика.
- Имя выходного базового файла компилятора — это то, как будет называться EXE-файл. Значение по умолчанию — setup.exe.
- Файл значка пользовательской установки — это значок, который будет использоваться в EXE-файле программы установки. Это должен быть файл ICO, который можно загрузить или преобразовать из PNG.
- Пароль установки защитит неавторизованных пользователей от использования вашего установщика. Оставьте поле пустым, чтобы отключить эту функцию.
После настройки параметров нажмите Готово. Когда будет предложено скомпилировать новый скрипт, нажмите Да. При появлении запроса на сохранение сценария выберите Нет, если это одноразовый установочный файл. Выберите Да, если вы планируете изменить или обновить его позже.
Дождитесь завершения процесса, и вуаля, у вас будет исполняемый файл.
Загрузить: Inno Setup для Windows (бесплатно)
Какой метод лучше всего подходит для создания установщика EXE?
Если у вас базовое программное обеспечение или вы собираетесь распространять его среди ограниченного числа людей, используйте метод 7-Zip. Это просто, быстро и почти не требует технических знаний.
Если ваше программное обеспечение несколько простое и вы хотите предоставить конечным пользователям настоящий мастер установки, используйте метод IExpress. Наконец, выберите приложение Inno, если у вас сложное программное обеспечение и вы знаете, что делаете.
Каждое приложение "Функции" выполняется обработчиком для конкретного языка. Хотя в Функциях Azure по умолчанию используется множество обработчиков языков, в некоторых случаях может потребоваться использовать другие языки или среды выполнения.
Пользовательские обработчики лучше всего подходят для ситуаций, когда вы хотите:
- Реализуйте приложение-функцию на языке, который в настоящее время не предлагается в готовом виде, например на Go или Rust.
- Реализуйте приложение-функцию в среде выполнения, которая в настоящее время не поддерживается по умолчанию, например Deno.
Начните работу с пользовательскими обработчиками Функций Azure с помощью кратких руководств по Go и Rust.
Обзор
На следующей диаграмме показана взаимосвязь между хостом функций и веб-сервером, реализованным в виде пользовательского обработчика.
- Каждое событие инициирует отправку запроса на узел функций. Событие — это любой триггер, поддерживаемый функциями Azure.
- Затем хост функций отправляет полезные данные запроса на веб-сервер. Полезная нагрузка содержит триггер и входные данные привязки, а также другие метаданные для функции.
- Веб-сервер выполняет отдельную функцию и возвращает полезные данные ответа хосту функций.
- Хост функций передает данные из ответа выходным привязкам функции для обработки.
Приложение "Функции Azure", реализованное как настраиваемый обработчик, должно настроить файлы host.json, local.settings.json и function.json. файлов в соответствии с несколькими соглашениями.
Структура приложения
Чтобы реализовать пользовательский обработчик, вам потребуются следующие аспекты вашего приложения:
- Файл host.json в корне вашего приложения
- Файл local.settings.json в корне вашего приложения
- Файл function.json для каждой функции (внутри папки, имя которой соответствует названию функции)
- Команда, скрипт или исполняемый файл, запускающий веб-сервер
На следующей диаграмме показано, как эти файлы выглядят в файловой системе для функции с именем "MyQueueFunction" и пользовательского исполняемого файла обработчика с именем handler.exe.
Конфигурация
Приложение настраивается с помощью файлов host.json и local.settings.json.
host.json
Настраиваемый обработчик определяется путем настройки файла host.json с подробной информацией о том, как запустить веб-сервер, в разделе customHandler.
Раздел customHandler указывает на цель, определенную в defaultExecutablePath . Целью выполнения может быть команда, исполняемый файл или файл, в котором реализован веб-сервер.
Используйте массив arguments для передачи любых аргументов исполняемому файлу. Аргументы поддерживают расширение переменных среды (параметров приложения) с использованием нотации %%.
Вы также можете изменить рабочий каталог, используемый исполняемым файлом, с помощью workDirectory .
Поддержка привязок
Стандартные триггеры вместе с привязками ввода и вывода доступны при ссылке на пакеты расширений в файле host.json.
local.settings.json
local.settings.json определяет параметры приложения, используемые при локальном запуске приложения-функции. Поскольку файл local.settings.json может содержать секреты, его следует исключить из системы контроля версий. Вместо этого в Azure используйте настройки приложения.
Для пользовательских обработчиков задайте для FUNCTIONS_WORKER_RUNTIME значение Custom в local.settings.json.
Метаданные функции
При использовании с пользовательским обработчиком содержимое function.json ничем не отличается от того, как вы определяете функцию в любом другом контексте. Единственное требование состоит в том, что файлы function.json должны находиться в папке с именем, совпадающим с именем функции.
Следующий function.json настраивает функцию, которая имеет триггер очереди и привязку выходных данных очереди. Поскольку он находится в папке с именем MyQueueFunction, он определяет функцию с именем MyQueueFunction.
MyQueueFunction/function.json
Запрос полезной нагрузки
Следующий код представляет пример полезной нагрузки запроса.Полезная нагрузка включает структуру JSON с двумя элементами: данными и метаданными .
Элемент Data включает в себя ключи, соответствующие именам входных данных и триггеров, определенным в массиве привязок в файле function.json.
Полезная нагрузка ответа
По соглашению ответы функций форматируются как пары "ключ-значение". Поддерживаемые ключи включают:
Это пример полезной нагрузки ответа.
Примеры
Функция с привязками
Реализация
заказ/функция.json
В корне приложения файл host.json настроен для запуска исполняемого файла с именем handler.exe (handler в Linux или macOS).
Некоторые части полезной нагрузки были удалены для краткости.
handler.exe — это скомпилированная пользовательская программа-обработчик Go, которая запускает веб-сервер и отвечает на запросы вызова функций от хоста функций.
Ответ функции форматируется в виде пар ключ/значение, где элемент Outputs содержит значение JSON, где ключи соответствуют выходным данным, определенным в файле function.json.
Это пример полезной нагрузки, которую этот обработчик возвращает хосту функций.
Чтобы устранить эти обстоятельства, рассмотрите возможность запуска веб-приложений в службе приложений Azure.
Реализация
привет/function.json
Эта функция настроена на прием как GET-, так и POST-запросов, а значение результата передается через аргумент с именем res .
Ниже приведен запрос POST к хосту функций. Затем узел функций отправляет копию запроса пользовательскому обработчику по тому же пути.
Запросы GET обрабатываются путем возврата строки, а запросы POST имеют доступ к телу запроса.
Маршрут для функции заказа здесь /api/hello , такой же, как и исходный запрос.
FUNCTIONS_CUSTOMHANDLER_PORT не является общедоступным портом, используемым для вызова функции. Этот порт используется узлом функций для вызова пользовательского обработчика.
Развертывание
Настраиваемый обработчик можно развернуть для каждого варианта размещения Функций Azure. Если вашему обработчику требуются зависимости от операционной системы или платформы (например, языковая среда выполнения), вам может потребоваться использовать собственный контейнер.
При создании приложения-функции в Azure для пользовательских обработчиков мы рекомендуем выбрать .NET Core в качестве стека. В будущем будет добавлен «пользовательский» стек для пользовательских обработчиков.
Чтобы развернуть пользовательское приложение-обработчик с помощью основных инструментов Azure Functions, выполните следующую команду.
Убедитесь, что все файлы, необходимые для запуска пользовательского обработчика, находятся в папке и включены в развертывание. Если ваш пользовательский обработчик представляет собой двоичный исполняемый файл или имеет зависимости от платформы, убедитесь, что эти файлы соответствуют целевой платформе развертывания.
Ограничения
- Веб-сервер пользовательского обработчика должен быть запущен в течение 60 секунд.
Образцы
Обратитесь к репозиторию GitHub с примерами пользовательских обработчиков, чтобы узнать, как реализовать функции на разных языках.
Устранение неполадок и поддержка
Журналирование трассировки
Если ваш пользовательский процесс-обработчик не запускается или у него возникают проблемы со связью с хостом функций, вы можете увеличить уровень журнала приложения-функции до Trace, чтобы получать больше диагностических сообщений от хоста.
Чтобы изменить уровень журнала по умолчанию для приложения-функции, настройте параметр logLevel в разделе ведения журнала host.json.
Хост функций выводит дополнительные сообщения журнала, включая информацию, относящуюся к процессу пользовательского обработчика. Используйте журналы для исследования проблем, связанных с запуском процесса пользовательского обработчика или вызовом функций в вашем пользовательском обработчике.
Локально журналы выводятся на консоль.
В Azure запросите трассировки Application Insights, чтобы просмотреть сообщения журнала. Если ваше приложение создает большой объем журналов, в Application Insights отправляется только подмножество сообщений журнала. Отключите выборку, чтобы все сообщения регистрировались.
Тестировать пользовательский обработчик изолированно
Вы также можете использовать эту стратегию в своих конвейерах CI/CD для запуска автоматических тестов в вашем пользовательском обработчике.
Среда выполнения
Настраиваемые обработчики работают в той же среде, что и обычное приложение Функций Azure. Протестируйте свой обработчик, чтобы убедиться, что среда содержит все зависимости, необходимые для запуска. Для приложений, которым требуются дополнительные зависимости, может потребоваться запустить их с помощью пользовательского образа контейнера, размещенного в плане "Премиум" для функций Azure.
Получить поддержку
Если вам нужна помощь в приложении-функции с пользовательскими обработчиками, вы можете отправить запрос через обычные каналы поддержки. Однако из-за большого разнообразия возможных языков, используемых для создания пользовательских приложений-обработчиков, поддержка не безгранична.
Поддержка доступна, если у хоста функций возникают проблемы с запуском или обменом данными с пользовательским процессом обработчика.В случае проблем, характерных для внутренней работы вашего пользовательского процесса обработчика, таких как проблемы с выбранным языком или платформой, наша служба поддержки не может оказать помощь в этом контексте.
Дальнейшие шаги
Приступайте к созданию приложения "Функции Azure" на Go или Rust с помощью краткого руководства по пользовательским обработчикам.
Командлет New-Service создает новую запись для службы Windows в реестре и в базе данных службы. Для новой службы требуется исполняемый файл, который запускается во время службы.
Параметры этого командлета позволяют указать отображаемое имя, описание, тип запуска и зависимости службы.
Примеры
Пример 1. Создание службы
Эта команда создает службу с именем TestService.
Пример 2. Создание службы с описанием, типом запуска и отображаемым именем
Эта команда создает службу с именем TestService. Он использует параметры New-Service для указания описания, типа запуска и отображаемого имени новой службы.
Пример 3. Просмотр новой службы
Эта команда использует Get-CimInstance для получения объекта Win32_Service для новой службы. Этот объект включает в себя режим запуска и описание службы.
Пример 4. Установка SecurityDescriptor службы при создании.
В этом примере добавляется SecurityDescriptor создаваемой службы.
Описатель безопасности хранится в переменной $SDDLToSet. Параметр SecurityDescriptorSddl использует $SDDL для установки SecurityDescriptor новой службы.
Параметры
Указывает путь к исполняемому файлу службы. Этот параметр является обязательным.
Полный путь к двоичному файлу службы. Если путь содержит пробел, его необходимо заключить в кавычки, чтобы он правильно интерпретировался. Например, d:\my share\myservice.exe следует указывать как '"d:\my share\myservice.exe"' .
Путь также может включать аргументы для автозапуска службы. Например, '"d:\myshare\myservice.exe arg1 arg2"' . Эти аргументы передаются в точку входа службы.
Для получения дополнительной информации см. параметр lpBinaryPathName API CreateServiceW.
| Тип: | Строка |
| Псевдонимы: | Путь |
| Позиция: | 1 |
| Значение по умолчанию: | Нет | < /tr>
| Принимать ввод конвейера: | False |
| Допускать подстановочные знаки: | False |
| Тип: | SwitchParameter |
| Псевдонимы: | cf |
| Позиция: | Имя |
| Значение по умолчанию: | False | < /tr>
| Принимать ввод конвейера: | False |
| Допускать подстановочные знаки: | False |
| Тип: | PSCredential |
| Позиция: | Имя |
| Значение по умолчанию: | Нет |
| Принять ввод конвейера: | False |
| Допускать подстановочные знаки: | False |
Указывает имена других служб, от которых зависит новая служба. Чтобы ввести несколько имен служб, используйте запятую для разделения имен.
| Тип: | Строка [ ] |
| Позиция: | Название |
| Значение по умолчанию: | Нет |
| Принять ввод конвейера: | False< /td> |
| Допускать подстановочные знаки: | False |
Указывает описание службы.
| Тип: | Строка |
| Позиция: | Именованный |
| Значение по умолчанию: | Нет |
| Принять ввод конвейера: | False |
| Допускать подстановочные знаки: | False |
Указывает отображаемое имя службы.
| Тип: | Строка |
| Позиция: | Именованный |
| Значение по умолчанию: | Нет |
| Принять ввод конвейера: | False |
| Допускать подстановочные знаки: | False |
Указывает имя службы. Этот параметр является обязательным.
| Тип: | String |
| Псевдонимы: | ServiceName |
| Позиция: | 0 |
| Значение по умолчанию: | Нет | < /tr>
| Принимать ввод конвейера: | False |
| Допускать подстановочные знаки: | False |
| Тип: | String |
| Псевдонимы: | sd |
| Позиция: | Имя |
| Значение по умолчанию: | Нет | < /tr>
| Принимать ввод конвейера: | False |
| Допускать подстановочные знаки: | False |
| Тип: | SwitchParameter |
| Псевдонимы: | wi |
| Позиция: | Имя |
| Значение по умолчанию: | False | < /tr>
| Принимать ввод конвейера: | False |
| Допускать подстановочные знаки: | False |
