Deploying the Azure Functions
Karlo K edited this page Dec 11, 2020
·
1 revision
- An Azure Storage account
- An Azure Storage Container the Persistor will save the data to
- An existing messaging service (Event Grid/Event Hub/Service Bus)
After generating the folders of the Function Apps locally, one of the ways to deploy them would be manually, with Visual Studio Code. This method requires having Python and Visual Studio Code. The steps can be summarized as follows:
- In Visual Studio code, ensure that you have the Azure extension enabled.
- In Visual Studio Code, open up the folder containing one of the Persistor Function Apps. (You will need to repeat this process for every different folder you ended up with in your "output" folder after the generator has created the functions.)
- When prompted to configure the Azure Function project for use with Visual Studio Code, accept; this will create a Python virtual environment in your Function App folder, which Visual Studio Code will only use for deployment operations.
- Going to the Azure tab on the left side of the screen, you should see your "Local Project". Select it, and click on the blue arrow pointing upwards to initiaze the deployment. Depending on your needs and preferences, choose your subscription and choose whether to create the New Azure Function in either the standard or advanced mode.
- Upon deployment, make sure to upload the local settings. You should find this option immediately upon deploying with Visual Studio Code, in the lower right corner of the window. Then, when you go to the Azure Portal, you can fill in the setting fields appropriately. Please consult this wiki's App Settings Overview page to determine the meaning of certain configuration fields if unsure from the name.
A few specific things to note, depending on which service/variant you're using the Persistor with:
- Event Grid-bound function is set to an Event Grid topic by creating a Subscription on the topic and setting the deployed function as an endpoint.
- For Service Bus and Event Hub functions that utilize BINDING, the service they are set to is set through App Configuration (by providing namespace strings and hub/topic/subscription names). Please try to perform those configuration values as soon as possible, given that the function will start reporting errors in your logs, as it will find itself impossible to bind to anything.
- PULL variants, as mentioned before, are all HTTP-triggered functions. When sending HTTP requests to trigger them, make sure to include an "N" parameter (no quotes, obviously), that contains the number of concurrent PULL tasks for a single function to trigger.
- If you are using the Invoker variant, you will have to set the "FUNC_TO_INVOKE" configuration setting with the URL link to the PULL function itself, and then run the invoker. Similarly as before, you set the number of Azure Functions to be called through the "N" parameter. Additionally, you can send the "N_per_func" parameter, which will active N_per_func concurrent tasks on each of the independent Azure Functions.
- You should not deploy two types of the same Persistor into the same function app. They will share the Configuration variables they read from and effectively do the same thing if deployed this way.