Бөлісу құралы:

Разработка Функции Azure локально с помощью основных средств

  • Мақала

Функции Azure Core Tools позволяет разрабатывать и тестировать функции на локальном компьютере. Когда вы будете готовы, вы также можете использовать основные средства для развертывания проекта кода в Azure и работы с параметрами приложения.

Вы просматриваете версию C# этой статьи. Выберите предпочитаемый язык программирования функций в верхней части статьи.

Если вы хотите начать работу сразу, выполните краткое руководство по основным средствам.

Вы просматриваете версию Java этой статьи. Выберите предпочитаемый язык программирования функций в верхней части статьи.

Если вы хотите начать работу сразу, выполните краткое руководство по основным средствам.

Вы просматриваете версию JavaScript этой статьи. Выберите предпочитаемый язык программирования функций в верхней части статьи.

Если вы хотите начать работу сразу, выполните краткое руководство по основным средствам.

Вы просматриваете версию PowerShell этой статьи. Выберите предпочитаемый язык программирования функций в верхней части статьи.

Если вы хотите начать работу сразу, выполните краткое руководство по основным средствам.

Вы просматриваете версию Python этой статьи. Выберите предпочитаемый язык программирования функций в верхней части статьи.

Если вы хотите начать работу сразу, выполните краткое руководство по основным средствам.

Вы просматриваете версию TypeScript этой статьи. Выберите предпочитаемый язык программирования функций в верхней части статьи.

Если вы хотите начать работу сразу, выполните краткое руководство по основным средствам.

Установка основных инструментов Функций Azure

Рекомендуемый способ установки основных средств зависит от операционной системы локального компьютера разработки.

Следующая процедура устанавливает Core Tools версии v4.x с помощью установщика Windows (MSI). Дополнительные сведения о других установщиках на основе пакетов, см. в файле readme для Core Tools.

Скачайте и запустите установщик Core Tools для используемой версии Windows:

Если вы ранее использовали установщик Windows (MSI) для установки основных инструментов в Windows, перед установкой последней версии удалите старую версию из команды "Добавить программы".

Сведения о проблемах, связанных с версиями, см. в разделе "Основные инструменты".

Создание локального проекта

Внимание

Для Python необходимо выполнить команды Core Tools в виртуальной среде. Дополнительные сведения см . в кратком руководстве по созданию функции Python в Azure из командной строки.

В окне терминала или из командной строки выполните следующую команду, чтобы создать проект в папке MyProjFolder :

func init MyProjFolder --worker-runtime dotnet-isolated

По умолчанию эта команда создает проект, который выполняется в процессе с узлом Функций в текущей версии долгосрочной поддержки (LTS) .NET Core. Вы можете использовать --target-framework этот параметр для назначения определенной поддерживаемой версии .NET, включая платформа .NET Framework. См. справочник по func init.

Сравнение двух моделей процессов .NET см. в статье о сравнении режима процесса.

Java использует архетип Maven для создания локального проекта вместе с первой активированной функцией HTTP. Вместо использования func init и func newвместо этого следует выполнить действия, описанные в кратком руководстве по командной строке.

func init MyProjFolder --worker-runtime javascript --model V4

Эта команда создает проект JavaScript, использующий нужную версию модели программирования.

func init MyProjFolder --worker-runtime typescript --model V4

Эта команда создает проект TypeScript, использующий нужную версию модели программирования.

func init MyProjFolder --worker-runtime powershell

func init MyProjFolder --worker-runtime python --model V2

Эта команда создает проект Python, использующий нужную версию модели программирования.

При запуске func init без --worker-runtime параметра вам будет предложено выбрать язык проекта. Дополнительные сведения о доступных параметрах для func init команды см. в справочнике func init .

Создание функции

Чтобы добавить функцию в проект, выполните func new команду с помощью --template параметра, чтобы выбрать шаблон триггера. В следующем примере создается триггер HTTP с именем MyHttpTrigger:

func new --template "Http Trigger" --name MyHttpTrigger

В этом примере создается триггер Хранилища очередей с именем MyQueueTrigger:

func new --template "Azure Queue Storage Trigger" --name MyQueueTrigger

При добавлении функций применяются следующие рекомендации.

  • При запуске func new без --template параметра вам будет предложено выбрать шаблон.

  • func templates list Используйте команду, чтобы просмотреть полный список доступных шаблонов для вашего языка.

  • При добавлении триггера, подключающегося к службе, необходимо также добавить параметр приложения, ссылающийся на строка подключения или управляемое удостоверение в файл local.settings.json. Использование параметров приложения таким образом предотвращает внедрение учетных данных в код. Дополнительные сведения см. в разделе "Работа с параметрами приложения" локально.

  • Core Tools также добавляет ссылку на конкретное расширение привязки в проект C#.

Дополнительные сведения о доступных параметрах для func new команды см. в справочнике func new .

Добавление привязки в функцию

Функции предоставляют набор входных и выходных привязок для конкретной службы, что упрощает подключение функции к другим службам Azure без использования клиентских пакетов SDK для конкретной службы. См. дополнительные сведения о триггерах и привязках в Функциях Azure.

Чтобы добавить входную или выходную привязку к существующей функции, необходимо вручную обновить определение функции.

В следующем примере показано определение функции после добавления выходной привязки хранилища очередей к триггерной функции HTTP:

Так как функция, активировавшая HTTP, также возвращает http-ответ, функция возвращает MultiResponse объект, представляющий выходные данные HTTP и очереди.

[Function("HttpExample")]
public static MultiResponse Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req,
    FunctionContext executionContext)
{

В этом примере приведено определение MultiResponse объекта, включающего выходную привязку:

public class MultiResponse
{
    [QueueOutput("outqueue",Connection = "AzureWebJobsStorage")]
    public string[] Messages { get; set; }
    public IActionResult HttpResponse { get; set; }
}

При применении этого примера к собственному проекту может потребоваться измениться HttpRequest на HttpRequestData и IActionResult в HttpResponseDataзависимости от того, используется ли интеграция ASP.NET Core или нет.

Сообщения отправляются в очередь по завершении работы функции. Способ определения выходной привязки зависит от модели процесса. Дополнительные сведения, включая ссылки на пример кода привязки, к которому можно обратиться, см. в разделе "Добавление привязок к функции".

@FunctionName("HttpExample")
public HttpResponseMessage run(
        @HttpTrigger(name = "req", methods = {HttpMethod.GET, HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS) 
        HttpRequestMessage<Optional<String>> request, 
        @QueueOutput(name = "msg", queueName = "outqueue", 
        connection = "AzureWebJobsStorage") OutputBinding<String> msg, 
        final ExecutionContext context) {

Дополнительные сведения, включая ссылки на пример кода привязки, к которому можно обратиться, см. в разделе "Добавление привязок к функции".

Пример привязки для модели Node.js версии 4 еще недоступен.

Способ определения выходной привязки зависит от версии модели Node.js. Дополнительные сведения, включая ссылки на пример кода привязки, к которому можно обратиться, см. в разделе "Добавление привязок к функции".

$outputMsg = $name
Push-OutputBinding -name msg -Value $outputMsg

Дополнительные сведения, включая ссылки на пример кода привязки, к которому можно обратиться, см. в разделе "Добавление привязок к функции".

@app.route(route="HttpExample")
@app.queue_output(arg_name="msg", queue_name="outqueue", connection="AzureWebJobsStorage")
def HttpExample(req: func.HttpRequest, msg: func.Out [func.QueueMessage]) -> func.HttpResponse:
    logging.info('Python HTTP trigger function processed a request.')

Способ определения выходной привязки зависит от версии модели Python. Дополнительные сведения, включая ссылки на пример кода привязки, к которому можно обратиться, см. в разделе "Добавление привязок к функции".

Пример привязки для модели Node.js версии 4 еще недоступен.

Способ определения выходной привязки зависит от версии модели Node.js. Дополнительные сведения, включая ссылки на пример кода привязки, к которому можно обратиться, см. в разделе "Добавление привязок к функции".

При добавлении привязок в функцию применяются следующие рекомендации.

  • При добавлении привязок, подключающихся к службе, необходимо также добавить параметр приложения, ссылающийся на строка подключения или управляемое удостоверение в файл local.settings.json. Дополнительные сведения см. в разделе "Работа с параметрами приложения" локально.
  • При добавлении поддерживаемой привязки расширение должно быть уже установлено, когда приложение использует пакет расширений. Дополнительные сведения см . в пакетах расширений.
  • При добавлении привязки, требующей нового расширения привязки, необходимо также добавить ссылку на это расширение привязки в проекте C#.

Дополнительные сведения, включая ссылки на пример кода привязки, к которому можно обратиться, см. в разделе "Добавление привязок к функции".

Дополнительные сведения, включая ссылки на пример кода привязки, к которому можно обратиться, см. в разделе "Добавление привязок к функции".

Дополнительные сведения, включая ссылки на пример кода привязки, к которому можно обратиться, см. в разделе "Добавление привязок к функции".

Дополнительные сведения, включая ссылки на пример кода привязки, к которому можно обратиться, см. в разделе "Добавление привязок к функции".

Дополнительные сведения, включая ссылки на пример кода привязки, к которому можно обратиться, см. в разделе "Добавление привязок к функции".

Дополнительные сведения, включая ссылки на пример кода привязки, к которому можно обратиться, см. в разделе "Добавление привязок к функции".

Запуск среды выполнения функций

Перед запуском или отладкой функций в проекте необходимо запустить узел Функций из корневого каталога проекта. Узел включает триггеры для всех функций в проекте. Используйте эту команду для запуска локальной среды выполнения:

mvn clean package 
mvn azure-functions:run

func start

func start

npm install
npm start

Эта команда должна выполняться в виртуальной среде.

При запуске узла Функций выводится список функций в проекте, включая URL-адреса всех функций, активируемых HTTP, например в этом примере:

Found the following functions:
Host.Functions.MyHttpTrigger

Job host started
Http Function MyHttpTrigger: http://localhost:7071/api/MyHttpTrigger

Помните, что при локальном выполнении функций следует учитывать следующие рекомендации.

  • По умолчанию авторизация не применяется локально для конечных точек HTTP. Это означает, что все локальные HTTP-запросы будут обрабатываться как authLevel = "anonymous". Дополнительные сведения см . на уровне авторизации. Вы можете использовать --enableAuth параметр, чтобы требовать авторизацию при локальном запуске. Дополнительные сведения см. в разделе func start.

  • Локальный эмулятор Azurite можно использовать при локальном выполнении функций, требующих доступа к службам служба хранилища Azure (хранилище очередей, хранилище BLOB-объектов и хранилище таблиц) без подключения к этим службам в Azure. При использовании локальной эмуляции перед запуском локального узла (func.exe) обязательно запустите Azurite. Дополнительные сведения см. в статье эмуляции локального хранилища.

  • Вы можете использовать локальную эмуляцию Azurite для удовлетворения требований к хранилищу рабочей роли Python версии 2.

  • Функции, отличные от HTTP, можно запускать локально, не подключаясь к динамической службе. Дополнительные сведения см. в разделе "Запуск локальной функции".

  • При включении сведений о подключении Application Insights в файл local.settings.json данные локального журнала записываются в конкретный экземпляр Application Insights. Чтобы сохранить данные локальной телеметрии отдельно от рабочих данных, рассмотрите возможность использования отдельного экземпляра Application Insights для разработки и тестирования.

  • При использовании версии 1.x основных средств вместо этого используйте func host start команду для запуска локальной среды выполнения.

Запуск локальной функции

При выполнении локального узла функций (func.exe) теперь можно активировать отдельные функции для запуска и отладки кода функции. Способ выполнения отдельной функции зависит от типа триггера.

Примечание.

В примерах в этой статье используется инструмент cURL для отправки HTTP-запросов из терминала или командной строки. Вы можете использовать любой инструмент для отправки HTTP-запросов к локальному серверу. Средство cURL доступно по умолчанию во всех системах на основе Linux и в Windows 10 сборки 17063 и выше. В более старых версиях Windows необходимо сначала скачать и установить средство cURL.

Триггеры HTTP запускаются путем отправки HTTP-запроса на локальную конечную точку и порт, как показано в выходных данных func.exe, который имеет этот общий формат:

http://localhost:<PORT>/api/<FUNCTION_NAME>

В этом шаблоне <FUNCTION_NAME> URL-адреса имя функции или маршрута и <PORT> является локальным портом, на котором func.exe прослушивается.

Например, эта команда cURL активирует MyHttpTrigger функцию быстрого запуска из запроса GET с параметром имени , переданным в строке запроса:

curl --get http://localhost:7071/api/MyHttpTrigger?name=Azure%20Rocks

Этот пример является одной и той же функцией, вызываемой из запроса POST, передаваемого в тексте запроса, как для оболочки Bash, так и командной строки Windows:

curl --request POST http://localhost:7071/api/MyHttpTrigger --data '{"name":"Azure Rocks"}'

curl --request POST http://localhost:7071/api/MyHttpTrigger --data "{'name':'Azure Rocks'}"

При локальном вызове конечных точек HTTP следует учитывать следующие рекомендации.

  • Запросы GET можно выполнять из браузера, передавая данные в строке запроса. Для всех других методов HTTP необходимо использовать средство тестирования HTTP, которое также обеспечивает безопасность данных. Дополнительные сведения см. в средствах тестирования HTTP.

  • Используйте то же имя сервера и порт, прослушиваемый узлом службы "Функции". Вы увидите конечную точку, как это, в выходных данных, созданных при запуске узла функции. Этот URL-адрес можно вызвать с помощью любого метода HTTP с поддержкой триггера.

Публикация в Azure

Azure Functions Core Tools поддерживает три типа развертывания:

Тип развертывания Команда Description
Файлы проекта func azure functionapp publish Развертывает файлы проекта функции непосредственно в приложении-функции с помощью ZIP-развертывания.
Приложения-контейнеры Azure func azurecontainerapps deploy Развертывает контейнерное приложение-функцию в существующей среде приложений контейнеров.
Кластер Kubernetes func kubernetes deploy Развертывает приложение-функцию Linux в качестве настраиваемого контейнера Docker в кластере Kubernetes.

Для публикации в Azure из Основных инструментов необходимо установить Azure CLI или Azure PowerShell локально. По умолчанию Core Tools использует эти средства для проверки подлинности с помощью учетной записи Azure.

Если у вас нет этих средств, необходимо вместо этого получить действительный маркер доступа для использования во время развертывания. Маркер доступа можно представить с помощью --access-token параметра в командах развертывания.

Развертывание файлов проекта

Чтобы опубликовать локальный код в приложении-функции в Azure, используйте func azure functionapp publish команду, как показано в следующем примере:

func azure functionapp publish <FunctionAppName>

Эта команда публикует файлы проекта из текущего каталога <FunctionAppName> в виде пакета развертывания .zip. Если для проекта требуется компиляция, она выполняется удаленно во время развертывания.

Java использует Maven для публикации локального проекта в Azure вместо основных инструментов. Используйте следующую команду Maven для публикации проекта в Azure:

mvn azure-functions:deploy

При выполнении этой команды ресурсы Azure создаются во время первоначального развертывания на основе параметров в файле pom.xml . Дополнительные сведения см. в статье "Развертывание проекта функции в Azure".

К этому типу развертывания относятся следующие соображения:

  • Публикация перезаписывает существующие файлы в развертывании удаленного приложения-функции.

  • Вы уже должны были создать приложение-функцию в подписке Azure. Core Tools развертывает код проекта в этом ресурсе приложения-функции. Сведения о том, как создать приложение-функцию из командной строки или окна терминала с помощью Azure CLI или Azure PowerShell, см. в статье Создание приложения-функции для выполнения без сервера. Эти ресурсы также можно создать в портал Azure. При попытке публикации <FunctionAppName> в подписке возникает ошибка.

  • Папка проекта может содержать файлы и каталоги для конкретного языка, которые не должны публиковаться. Такие исключения перечисляются в файле .funcignore в корневой папке проекта.

  • По умолчанию проект развертывается таким образом, чтобы он запускался из пакета развертывания. Чтобы отключить этот рекомендуемый режим развертывания, используйте параметр --nozip.

  • Для скомпилированных проектов выполняется удаленная сборка. Это можно контролировать с помощью параметра --no-build.

  • --publish-local-settings Используйте параметр автоматического создания параметров приложения в приложении-функции на основе значений в файле local.settings.json.

  • Чтобы опубликовать в определенном именованном слоте в приложении-функции, используйте --slot этот параметр.

Развертывание контейнеров

Основные средства позволяют развернуть контейнерное приложение-функцию как в управляемых средах приложений контейнеров Azure, так и в кластерах Kubernetes, которыми вы управляете.

Используйте следующую func azurecontainerapps deploy команду, чтобы развернуть существующий образ контейнера в среде приложений контейнеров:

func azurecontainerapps deploy --name <APP_NAME> --environment <ENVIRONMENT_NAME> --storage-account <STORAGE_CONNECTION> --resource-group <RESOURCE_GROUP> --image-name <IMAGE_NAME> [--registry-password] [--registry-server] [--registry-username]

При развертывании в среде приложений контейнеров Azure применяются следующие рекомендации.

  • Среда и учетная запись хранения уже должны существовать. Учетная запись хранения, строка подключения которую вы предоставляете, используется развернутыми приложением-функцией.

  • При развертывании в контейнерных приложениях не требуется создать отдельный ресурс приложения-функции.

  • Строка подключения хранилища и другие учетные данные службы являются важными секретами. Не забудьте безопасно хранить файлы скриптов с помощью func azurecontainerapps deploy и не хранить их в общедоступных системах управления версиями. Вы можете зашифровать файл local.settings.json для дополнительной безопасности.

Дополнительные сведения см. в статье "Приложения контейнеров Azure" для размещения Функции Azure.

Работа с параметрами приложения локально

При запуске в приложении-функции в Azure параметры для функций безопасно хранятся в параметрах приложения. Во время локальной разработки эти параметры вместо этого добавляются Values в коллекцию в файле local.settings.json. Файл local.settings.json также хранит параметры, используемые локальными средствами разработки.

Элементы в коллекции в Values файле local.settings.json проекта предназначены для зеркального отображения элементов в параметрах приложения-функции в Azure.

При работе с локальным файлом параметров применяются следующие рекомендации.

  • Так как файл local.settings.json может содержать секреты, например строки подключения, его не следует хранить в удаленном репозитории. Основные инструменты помогают шифровать этот локальный файл параметров для повышения безопасности. Подробнее см. в разделе Файл локальных параметров. Вы также можете зашифровать файл local.settings.json для дополнительной безопасности.

  • По умолчанию локальные параметры не переносятся автоматически при публикации проекта в Azure. --publish-local-settings Используйте параметр при публикации файлов проекта, чтобы убедиться, что эти параметры добавлены в приложение-функцию в Azure. Значения из раздела ConnectionStrings никогда не публикуются. Вы также можете отправлять параметры из файла local.settings.json в любое время.

  • Параметры можно скачать и перезаписать в файле local.settings.json с параметрами из приложения-функции в Azure. Дополнительные сведения см. в разделе "Скачать параметры приложения".

  • Эти значения параметров приложения-функции также могут считываться в коде как переменные среды. Дополнительную информацию см. в разделе Переменные среды.
  • Эти значения параметров приложения-функции также могут считываться в коде как переменные среды. Дополнительную информацию см. в разделе Переменные среды.
  • Эти значения параметров приложения-функции также могут считываться в коде как переменные среды. Дополнительную информацию см. в разделе Переменные среды.
  • Эти значения параметров приложения-функции также могут считываться в коде как переменные среды. Дополнительную информацию см. в разделе Переменные среды.
  • Эти значения параметров приложения-функции также могут считываться в коде как переменные среды. Дополнительную информацию см. в разделе Переменные среды.
  • Если для нее не задано AzureWebJobsStorage допустимое строка подключения хранилища, а локальный эмулятор хранилища не используется, отображается ошибка. С помощью основных средств можно скачать определенные строка подключения из любой учетной записи служба хранилища Azure.

Скачивание параметров приложения

В корневом каталоге проекта используйте следующую команду, чтобы скачать все параметры приложения из myfunctionapp12345 приложения в Azure:

func azure functionapp fetch-app-settings myfunctionapp12345

Эта команда перезаписывает все существующие параметры в файле local.settings.json со значениями из Azure. Если они еще не присутствуют, новые элементы добавляются в коллекцию. Дополнительные сведения см. в команде func azure functionapp fetch-app-settings .

Скачивание строка подключения хранилища

Основные инструменты также упрощают получение строка подключения любой учетной записи хранения, к которой у вас есть доступ. В корневом каталоге проекта используйте следующую команду, чтобы скачать строка подключения из учетной записи хранения с именемmystorage12345.

func azure storage fetch-connection-string mystorage12345

Эта команда добавляет параметр с именем mystorage12345_STORAGE в файл local.settings.json, который содержит строка подключения для учетной mystorage12345 записи. Дополнительные сведения см. в команде func azure storage fetch-connection-string .

Для повышения безопасности во время разработки рекомендуется зашифровать файл local.settings.json.

Отправка локальных параметров в Azure

При публикации файлов проекта в Azure без использования --publish-local-settings параметра параметры в файле local.settings.json не задаются в приложении-функции. Вы всегда можете повторно запустить func azure functionapp publish параметр для --publish-settings-only отправки только параметров без повторной публикации файлов проекта.

В следующем примере передаются только параметры из Values коллекции в файле local.settings.json в приложение-функцию в Azure с именем myfunctionapp12345:

func azure functionapp publish myfunctionapp12345 --publish-settings-only

Шифрование локального файла параметров

Чтобы повысить безопасность строка подключения и других ценных данных в локальных параметрах, Core Tools позволяет зашифровать файл local.settings.json. При шифровании этого файла среда выполнения автоматически расшифровывает параметры при необходимости так же, как и с параметрами приложения в Azure. Вы также можете расшифровать локально зашифрованный файл для работы с параметрами.

Используйте следующую команду, чтобы зашифровать локальный файл параметров для проекта:

func settings encrypt

Используйте следующую команду, чтобы расшифровать зашифрованный локальный параметр, чтобы с ним можно было работать:

func settings decrypt

Когда файл параметров зашифрован и расшифровывается, параметр файла IsEncrypted также обновляется.

Настройка расширений привязки

Триггеры и привязки функций реализуются в виде пакетов расширения .NET (NuGet). Чтобы использовать определенное расширение привязки, это расширение должно быть установлено в проекте.

Этот раздел не относится к версии 1.x среды выполнения Функций. В версии 1.x поддерживаемые привязки были включены в основное расширение продукта.

Для проектов библиотеки классов C# добавьте ссылки на определенные пакеты NuGet для расширений привязки, необходимых вашим функциям. Проект скрипта C# (CSX) должен использовать пакеты расширений.

Функции предоставляют пакеты расширений , которые упрощают работу с расширениями привязки в проекте. Пакеты расширений, которые имеют версию и определены в файле host.json, установите полный набор совместимых пакетов расширений привязки для приложения. У host.json уже должны быть включены пакеты расширений. Если по какой-то причине необходимо добавить или обновить пакет расширений в файле host.json, ознакомьтесь с пакетами расширений.

Если необходимо использовать расширение привязки или версию расширения, не в поддерживаемом пакете, необходимо вручную установить расширения. Для таких редких сценариев см. func extensions install команду.

Версии Core Tools

Основные версии Функции Azure Core Tools связаны с определенными основными версиями среды выполнения Функции Azure. Например, версия 4.x Core Tools поддерживает версию 4.x среды выполнения функций. Эта версия является рекомендуемой основной версией среды выполнения функций и основных инструментов. Последнюю версию Core Tools можно определить в репозитории основных средств Функции Azure Core Tools.

Начиная с версии 4.0.6517 основных инструментов проекты модели в процессе должны ссылаться на версию 4.5.0 или более поздней версии Microsoft.NET.Sdk.Functions. Если используется более ранняя версия, func start команда будет ошибкой.

Выполните следующую команду, чтобы определить версию текущей установки Core Tools:

func --version

Если иное не указано, примеры, приведенные в этой статье, предназначены для версии 4.x.

Следующие рекомендации относятся к установкам Core Tools:

  • На каждом компьютере можно установить только одну версию Core Tools.

  • При обновлении до последней версии Core Tools следует использовать тот же метод, который использовался для первоначальной установки для выполнения обновления. Например, если вы использовали MSI в Windows, удалите текущий MSI и установите последнюю версию. Или, если вы использовали npm, повторно запустите npm install commandфайл .

  • Версии 2.x и 3.x core Tools использовались с версиями 2.x и 3.x среды выполнения функций, которые достигли их окончания поддержки. Дополнительные сведения см. в обзоре версий среды выполнения Функций Azure.

  • Версия 1.x core Tools требуется при использовании версии 1.x среды выполнения функций, которая по-прежнему поддерживается. Эта версия основных инструментов может выполняться только локально на компьютерах Windows. Если вы работаете в настоящее время в версии 1.x, рекомендуется перенести приложение на версию 4.x сегодня.

Следующие шаги

Узнайте, как разрабатывать, тестировать и публиковать функции Azure с помощью основных средств Функции Azure. Основные инструменты службы "Функции Azure" имеют открытый код и размещаются на GitHub. Чтобы зарегистрировать ошибку или отправить запрос на функцию, откройте вопрос на GitHub.