| Table of Contents |
|---|
Objective
You have a working Azure Java Function and the source code is managed in a Git repository. The goal of the tutorial is to automate the deployment of one or more Java Functions to Azure Function App. This automation will include:
...
We will walk through each of the FlexDeploy features that will be created/configured to accomplish this goal and have the Java Function deployed in a very short amount of time.
Checklist
Checklist | Description |
|---|---|
Azure Tenant Id | Azure Tenant Id for the company |
Azure Subscription Id | Azure Subscription where the Function App exists |
Azure Client ID | Client ID to connect to desired Azure Subscription |
Azure Client Key | Password for the Client ID |
Azure Client ID permission | The Client ID must have relevant access in target Function App to deploy code |
Azure Function App | The Function App with relevant runtime should already be created |
Azure Resource Group | The Resource Group containing the Function App |
Azure CLI installation | Azure CLI needs to be installed where the plugin operation shall run (FlexDeploy server) |
Azure CLI in class path | Azure CLI should be added to class path on the FlexDeploy Server. Else the path can also be set under FlexDeploy environment level property |
Configure cloud account
First, an Azureaccount needs to be configured under Topology. FlexDeploy will connect to the right Azure Subscription with provided details and do the deployment.
...
Client Key is a password field and hence needs to be kept hidden. To update the same click on the pencil icon as shown below
Update the Client Key value under Secret Text. This is to make sure no one else can retrieve the password
...
Git repository structure
The Git repository should contain the codebase. Alongside it can also contain any Application Setting and Connection String related attributes in respective files(any naming convention allowed). These files are not mandatory, however, in case someone has any Application Setting and Connection String property to update this is recommended. Please review the Application Setting and Connection String property update for a detailed explanation.
The Sample Git repository structure is given below.
...
Build and Deploy Workflows
Navigate to the Workflows tab and create a workflow using the “+”(Click to create new Workflow) button as highlighted below.
...
The below step will execute the maven build with the project pom.xml and will create a Java executable(.jar) file inside the target directory.
...
Step-iii: Copy the properties file to the intermediate dir
Application Setting and Connection String JSON files(if applicable/present) will be moved to the intermediate directory. An intermediate directory can have any name, in this case, we are using the artifactsObjects folder inside the temp directory. File names are mentioned under File Filter with ‘##’ separated(as advised in the description). Application Setting and Connection String values can also be passed as input to deploy workflow. Application Setting and Connection String files are optional, please review the Application Setting and Connection String property update for a detailed explanation.
...
Step-iv: Create an archive of the executable in the intermediate dir
Per the Azure Function App deployment requirement, we have created an archive with the java executable inside it.
...
If we look inside the deploy.zip, it contains the jar file only. Basically, it contains the executable files that need to be copied to the Azure Function App backend. Azure Function App treats this as an executable package and runs it.
...
Note: the jar file(or any executable files) inside the .zip file shouldn’t be inside any subfolder. Else once the zip file is deployed to Azure Function App may not work.
Step-vnote: Each application will have separate directory structure hence the all paths need to be modified accordingly.
note: Its essential to make sure Consumes Artifacts and Produces Artifacts checkbox is marked only when required. Please follow the snapshots for all execution steps to avoid any discrepancy.
If the pom.xml is properly configured the java executable will be generated along other essential files as shown below under target/azure-functions folder.
...
Also for each Function sperate folder will be generated with corresponding function.json file in it. These will be automatically generated.
...
All of above files need to be copied to Azure Function App to execute properly.
Step-iii: Copy the properties file to the intermediate dir
Application Setting and Connection String json files(if applicable/present) will be moved to the intermediate directory. An intermediate directory can have any name, in this case, we are using the artifactsObjects folder inside the temp directory. File names are mentioned under File Filter with ‘##’ separated(as advised in the description). Application Setting and Connection String values can also be passed as input to deploy workflow. Application Setting and Connection String files are optional, please review the Application Setting and Connection String property update for a detailed explanation.
...
Step-iv: Create an archive of the executable in the intermediate dir
Post execution of the above steps the intermediate directory(artifactObjects) should contain files as shown below.
...
These objects are required as part of the deployment flow. Hence we create an archive(artifacts.zip) with them inside the Artifacts directory. We also enable Produces Artifacts checkbox to save the zip file as an artifact.
...
As part of the above step, all files inside the artifactObjects folder are archived to create an artifacts.zip which will be saved as an artifact for future reference from the Deployment workflow.
...
Note: The directory name/artifact name can be anything. The deployment workflow expects only one .zip file inside the artifact containing the executable(.jar file in this case). It will search for a .zip extension and treat it as a package archive for deployment.
Note: the deployFunctions operation(Azure plugin) will search for the Application Setting and Connection String file name provided as part of Project properties. Irrespective of folder structure it will find the file. In case more than one file exists with the same name, flow shall fail.
Below given is a sample deployment workflow to deploy the archive to Azure Function App.
...
This step first updates the Application Setting/Connection String values from the files present in the artifact(optional). Instead of using Application Setting and Connection String files, one can directly provide the values as part of plugin input.
In such case, we can create input variables on deployment workflow like given below and pass them as deployFunctions operation input argument. This is optional and any other way to pass the arguments(e.g. hardcoded value) is also acceptable.
First, navigate to the Workflow Definition tab and click on the Create/View Inputs button as shown below.
...
Create two input variables, one each for Application Setting and Connection String as shown below.
...
The input arguments are then mapped to the input properties of the deployFunctions operation as shown below. The plugin will take the input values and process them accordingly.
...
The deployFunctions operation returns four output variables. To capture them and use them for further processing/evaluation, one can create four variables and map them against the output parameters of deployFunctions operation. They can also be provisioned to be returned as workflow output variablesPer the Azure Function App deployment requirement, we have created an archive with the java executable and other associated files(generated through maven) in it.
...
note: Each application will have separate directory structure hence the all paths need to be modified accordingly.
If we look inside the deploy.zip, it contains the jar file along with other associated files. Basically, it contains all relevant files that need to be copied to the Azure Function App backend. Azure Function App treats the jar file as an executable package and runs it.
...
note: the jar file(or any executable files) inside the .zip file shouldn’t be inside any subfolder. Else once the zip file is deployed to Azure Function App may not work.
Step-v: Save all as Artifact from the intermediate dir
Post execution of the above steps the intermediate directory(artifactObjects) should contain files as shown below.
...
These objects are required as part of the deployment flow. Hence we create an archive(artifacts.zip) with them inside the Artifacts directory. We also enable Produces Artifacts checkbox to save the zip file as an artifact.
...
As part of the above step, all files inside the artifactObjects folder are archived to create an artifacts.zip which will be saved as an artifact for future reference from the Deployment workflow.
...
note: The directory name/artifact name can be anything. The deployment workflow expects only one .zip file inside the artifact containing the executable(.jar file in this case). It will search for a .zip extension and treat it as a package archive for deployment.
note: the deployFunctions operation(Azure plugin) will search for the Application Setting and Connection String file name provided as part of Project properties. Irrespective of folder structure it will find the file. In case more than one file exists with the same name, flow shall fail.
Below given is a sample deployment workflow to deploy the archive to Azure Function App.
...
This step first updates the Application Setting/Connection String values from the files present in the artifact(optional). Instead of using Application Setting and Connection String files, one can directly provide the values as part of plugin input.
In such case, we can create input variables on deployment workflow like given below and pass them as deployFunctions operation input argument. This is optional and any other way to pass the arguments(e.g. hardcoded value) is also acceptable.
First, navigate to the Workflow Definition tab and click on the
...
Next use Create option to add four output variables.
...
Map the variables against the output of the deployFunctions operation to capture the responses.
...
Project configuration
Navigate to the Project tab and create a Project with a logical name(JavaAzureFunction in this case)
...
Configure the Build and Deploy workflow that has been created in previous steps as shown below.
...
Configure the Source SCM repository under Source Control as shown below.
...
To configure Project specific Source Control one first need to navigate to the Project Configuration tab.
Next, expand the SOURCE CONTROL option from the left-hand pane.
Select SOURCES for configuring the Source Repository
Select the appropriate Source Control Type
Configure Source Repository.
For detailed steps of Source Control configuration please refer to Configure Source Control in FlexDeploy
Project Properties
...
To configure Project specific settings one can navigate to the Project Configuration tab as shown above.
...
Create/View Inputs button as shown below.
...
Create two input variables, one each for Application Setting and Connection String as shown below.
...
The input arguments are then mapped to the input properties of the deployFunctions operation as shown below. The plugin will take the input values and process them accordingly.
...
The deployFunctions operation returns four output variables. To capture them and use them for further processing/evaluation, one can create four variables and map them against the output parameters of deployFunctions operation. Return As Output drop down option should be set as Yes.
First, navigate to the Workflow Definition tab and click on the Variables button
Next use Create option to add four output variables.
...
Map the variables against the output of the deployFunctions operation to capture the responses.
...
Project configuration
Navigate to the Project tab and create a Project with a logical name(JavaAzureFunction in this case)
...
Configure the Build and Deploy workflow that has been created in previous steps as shown below.
...
| Anchor | ||||
|---|---|---|---|---|
|
Configure the Source SCM repository under Source Control as shown below.
...
To configure Project specific Source Control one first need to navigate to the Project Configuration tab.
Next, expand the SOURCE CONTROL option from the left-hand pane.
To deploy a Function to Azure Function App, the first two mandatory properties are the Function App Name and Resource Group Name. These need to be configured under Project properties.
Remote Build: This flag is applicable in case we want to upload the code to the Azure Function App backend and build it there itself(e.g: NET/node JsSelect SOURCES for configuring the Source Repository
Select the appropriate Source Control Type
Configure Source Repository.
For detailed steps of Source Control configuration please refer to Configure Source Control in FlexDeploy
Project Properties
...
To configure Project specific settings one can navigate to the Project Configuration tab as shown above.
Next, select the PROPERTIES option from the left-hand pane.
To deploy a Function to Azure Function App, the first two mandatory properties are the Function App Name and Resource Group Name. These need to be configured under Project properties.
Remote Build: This flag is applicable in case we want to upload the code to the Azure Function App backend and build it there itself (e.g.: .NET/Node.js). We are creating the Java executable(jar) file explicitly as part of the build workflow, hence this checkbox can be left unchecked for this flow.
Under Project properties, one also needs to provide the Application Setting/Connection String file names(if applicable).
Show deployment log: Once deployment is completed, in case someone wants to verify the execution steps, they need to check the below checkbox under Project properties.
In this case, the plugin will internally retrieve the deployment Id and will fetch the Deployment log(if available), and return the same as an Output variable.
This is applicable only for Code archive deployment(not for docker image deployment.)
...
Application Setting and Connection String values will be updated against the Function Slot Name configured at the environment level. Refer to the Deploy to Slot section for further details.
Target Properties
Select Topology from the menu and then select Topology Overview from the left menu. You will see a table that has Instances as the rows and Environments as the columns with colored circles representing the Environment Instance. Color coding represents:
RED - no required properties are set and/or the Endpoint is not configured
YELLOW - some of the required properties are set and/or the Endpoint is not configured
GREEN - all required properties are set and the Endpoint is configured
Selecting the GREEN circle for DEV will display the configurable properties/Endpoint and allows for the configuration of
...
Properties
...
Mandatory Field
...
Description
...
Function Slot Name
...
...
Target slot for deployment
...
Target Slot to swap
...
Optional
...
In case slot swap is required
...
Azure Cloud Account
...
...
Azure account with relevant details
...
Absolute path of Azure CLI
...
Optional
...
Not required if Azure CLI already added to workflow execution m/c class path
Below given are the environment-specific values which need to be updated.
Also in case, we are adding any environment-specific properties for Application Setting/Connection String(as mentioned in the previous step), those values should also be updated.
The Azure Could account needs to be set here from the drop-down. It will show all Cloud Accounts configured under Topology, which we have already mentioned earlier.
...
Azure Function App default slot is production. However, one can configure multiple slots and deploy Functions on those slots inside Function App. Function Slot Name is a mandatory field, where the code needs to deploy.
In case someone wants to do a slot swap, they can provide the Target Slot to swap with as shown below.
...
executeFunctionAppSlotSwap operation can be used to perform the slot swap.
Build Execution
For detailed steps on how to initiate Build Azure Function, review artifacts, and ultimately deploy to Azure Function App please refer to Build and deploy execution through FlexDeploy There could also be scenarios where someone only need to update the Application Setting or Connection String without actually deploying the code. In that case one can use upsertFunctionApplicationSetting or upsertFunctionConnectionString operations respectively. The workflow execution will be exactly same only the code archive creation /Docker image update step will not be required. Build workflow generated artifact should only container AppSetting.json or ConnString.json. These values can also be passed as input as already mentioned in detail in above section.
Target Properties
Select Topology from the menu and then select Topology Overview from the left menu. You will see a table that has Instances as the rows and Environments as the columns with colored circles representing the Environment Instance. Color coding represents:
RED - no required properties are set and/or the Endpoint is not configured
YELLOW - some of the required properties are set and/or the Endpoint is not configured
GREEN - all required properties are set and the Endpoint is configured
Selecting the GREEN circle for DEV will display the configurable properties/Endpoint and allows for the configuration of
Properties | Mandatory Field | Description |
|---|---|---|
Function Slot Name |
| Target slot for deployment |
Target Slot to swap | Optional | In case slot swap is required |
Azure Cloud Account |
| Azure account with relevant details |
Absolute path of Azure CLI | Optional | Not required if Azure CLI already added to workflow execution m/c class path |
GIT Path | Optional | Path to the Git executable. Required only if git is not on class path. |
Below given are the environment-specific values which need to be updated.
Also in case, we are adding any environment-specific properties for Application Setting/Connection String(as mentioned in the previous step), those values should also be updated.
The Azure Could account needs to be set here from the drop-down. It will show all Cloud Accounts configured under Topology, which we have already mentioned earlier.
...
| Anchor | ||||
|---|---|---|---|---|
|
Azure Function App default slot is production. However, one can configure multiple slots and deploy Functions on those slots inside Function App. Function Slot Name is a mandatory field, where the code needs to deploy.
In case someone wants to do a slot swap, they can provide the Target Slot to swap with as shown below.
...
executeFunctionAppSlotSwap operation can be used to perform the slot swap.
Build Execution
For detailed steps on how to initiate Build Azure Function, review artifacts, and ultimately deploy to Azure Function App please refer to Build and deploy execution through FlexDeploy
Post deployment debugging
Post deployment success from plugin it can take a little while for the function application up and running.
Currently once the application is deployed to Azure Function App through the plugin operation, Azure basically uploads the files to the backend. However if the application is up and running or have failed, can’t be verified immediately. It takes a little while for the service to start and accept requests.
Issues can happen if host.json has some issue. Sample error message shown below.
...
The function archive generated is not in desired format hence can’t be loaded. Sample error message shown below.
...
In such scenario functions deployed will reflect as none with Azure Function may be in unreachable state as shown below.
...
Best way to check logs: https://$func_name.scm.azurewebsites.net/api/logstream or logstream from console. As already in above scenarios, in case of failure we can easily debug the issue from log and get the issue fixed.
Congratulations! You have successfully completed the Java Application deployment to the Azure Function App tutorial.
...