I tried different ways to deploy my local logic app from VS Community using powershell but none of them are working.
Any solutions for this?
Logic App deployment successful from Visual Studio (local) through PowerShell Command
The following command worked for me
New-AzResourceGroupDeployment -ResourceGroupName <Azure-resource-group-name> -TemplateUri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.logic/logic-app-create/azuredeploy.json
and here is the output:
Here is the process that I followed before running the above command.
Process Flow:
I have found that there are 2 ways of deploying logic app through PowerShell i.e., Azure RM Template Commands and AZ Modules Commands
To work with any of the following commands, we are required to install related package files:
To deploy using Azure RM Template Commands - Run this code on PowerShell:
Install-Module -Name AzureRM -AllowClobber
To deploy using AZ module commands - Run this code on PowerShell:
Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force
Checkout the following links to play with versions (uninstalling old and installing new), setting up the policies, connecting of Azure Accounts, etc in these:
Azure RM PowerShell Commands and Azure Az Module PowerShell Commands
Following is the process of which I have tried deploying the Local Visual Studio Logic App to Azure in PowerShell using Azure RM PowerShell Script commands:
Before deploying:
Create a Logic App in Visual Studio (File > New Project > Select 'Azure Resource Group' > Logic App)
Your solution will be ready in a few seconds, you will be able to see two json files. As you select prameters.json file you will be able to see json schema for logic app deployment.
To Connect your logic with your Azure Account, right click on LogicApp.json and select 'Open with logic app designer'. If you don't find this option, then install this extension in your project:
Right click on project and click on validate
Select your resource group, subscription and click on edit parameters - give custom name to your logic app. Otherwise, it will throw you error of null in logicAppName and shows template is invalid.
After validation, it shows the template is valid. It can be automatically validate during deployment process also, but it's good way to validate to get rid out of errors.
PowerShell Commands to deploy your logic App from visual studio (local):
Install this Power Shell provided by Microsoft Cloud.
Run in Administrator Mode > Login with Connect-AzureRmAccount command (it takes you to browser and connect with Azure account) > after that it imports your subscription and resource group details in the shell like below:
Use the following command to deploy your logic app
New-AzResourceGroupDeployment -ResourceGroupName "AzureAccountMail" -Templatefile "C:\LogicAppTemplats\template.json" -TemplateParameterFile "C:\LogicAppTemplats\parameters.json"
Check this following documentation for this command overview.
Done! Deployment Succeeded.
Now Check out in the azure portal:
Note:
Here you can find the template file and parameters.json file under your project:
Make Sure you given your logic app name value here in the parameters.json file:
And Provide the logic app name, deployment location values in the template.json file (LogicApp.json)
Related
I am using Azure CLI to use the azure. I am trying to create a staticwebapp and later try to add the configuration from CLI.
I tried to run this
az staticwebapp appsettings set -n appname --setting-names MONGO_CONNECTION_STRING="mongodb+srv://anirudha:testing#cluster4340.v45343.mongodb.net/?retryWrites=true&w=majority"
I am getting error
'w' is not recognized as an internal or external command,
operable program or batch file.
I go to portal and seen before &w=majority is added into configuration but this part is not added after &.
I tried to put singlequote and key=("val") but none of them working for me. I found this in azure app config github repo.
Anyone have idea how to make it work from CLI
--setting-names property accepts the app settings in 'key=value' format as mentioned here in this documentation of az staticwebapp app settings set cmdlet.
You need to change the above shared cmdlet to the below:
az staticwebapp appsettings set -n <staticWebAppName> --setting-names 'MONGO_CONNECTION_STRING=<AppsettingValue>'
I have tested this and it is working fine from my end Here is the sample output screenshot for your reference:
Updated Answer:
Alternatively, you can use this PowerShell cmdlet
(New-AzStaticWebAppSetting) to update the app settings of the static web app
New-AzStaticWebAppSetting -ResourceGroupName resourceGroup -Name staticweb01 -AppSetting #{'function01' = 'value01'; 'function02' = 'value02' }
I have 2 different function apps and deployment scripts. The first app (functionApp1) uses the az cli, and the second one is being written to use the new AZ Powershell modules.
I thought I wouldn't be impacting the az cli solution by installing/setting up the latest powershell cmdlets but I think functionApp1's deployment is broken since installing the new Az Powershell tools.
When I run the az cli deployment script for function App 1, it dies while trying to publish the application. The error message says:
You're trying to use v4 tooling to publish to a non-v4 function app
(FUNCTIONS_EXTENSION_VERSION is set to ~3). You can pass --force to
force update the app to v4, or downgrade tooling for publishing.
Code
In case it helps, here are some snippets of code from the deployment script for functionApp1 The following logic to create a resource group, application insights, and a storage account all works:
az login --service-principal --username $CLIENT_ID --password $SECRET --tenant $TENANT --allow-no-subscriptions
az account set --subscription $SUBSCRIPTION_ID
az group create -n $RESOURCE_GROUP_NAME -l $RESOURCE_LOCATION
az deployment group create --resource-group $RESOURCE_GROUP_NAME --template-file (Join-Path $PSScriptRoot "./resources/function1App.json")
Next I grab information from the new resources I created above, and I update my local.settings.json file. This also still works:
func settings add FUNCTIONS_WORKER_RUNTIME dotnet #explicitly set this.
#auto-update the local.settings.json file with connection string
func azure storage fetch-connection-string $storageAccount.name
#grab contents of local settings file.
$data = Get-Content 'local.settings.json' -raw | ConvertFrom-Json
#logic to update local settings.
Lastly I try to publish the functions in azure using my local settings file. And this is the part that is no longer working:
$functionDeploymentResult = func azure functionapp publish $FUNCTION_APP.name --publish-local-settings -i --overwrite-settings -y
But the error message I'm getting is this:
You're trying to use v4 tooling to publish to a non-v4 function app (FUNCTIONS_EXTENSION_VERSION is set to ~3).
You can pass --force to force update the app to v4, or downgrade tooling for publishing.
I tried to add the --force option and while it gets rid of the error message, when I try to actually run my test "hello world" function in azure, I see the following error message:
Microsoft.Azure.WebJobs.Script: One or more loaded extensions do not meet the minimum requirements. For more information see https://aka.ms/func-min-extension-versions.
ExtensionStartupType AzureStorageWebJobsStartup from assembly 'Microsoft.Azure.WebJobs.Extensions.Storage, Version=4.0.3.0, Culture=neutral, PublicKeyToken=asdfasdfasdf' does not meet the required minimum version of 4.0.4.0. Update your NuGet package reference for Microsoft.Azure.WebJobs.Extensions.Storage to 4.0.4 or later.
AZ CLI VERSION
PS C:\Users\me\Documents\src\functionapp1> az --version
azure-cli 2.30.0 *
core 2.30.0 *
telemetry 1.0.6
Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
Extensions directory 'C:\Users\me\.azure\cliextensions'
Python (Windows) 3.8.9 (tags/v3.8.9:a743f81, Apr 6 2021, 13:22:56) [MSC v.1928 32 bit (Intel)]
Legal docs and information: aka.ms/AzureCliLegal
You have 2 updates available. Consider updating your CLI installation with 'az upgrade'
Please let us know how we are doing: https://aka.ms/azureclihats
and let us know if you're interested in trying out our newest features: https://aka.ms/CLIUXstudy
.vscode/settings.json
{
"azureFunctions.deploySubpath": "src/bin/Release/netcoreapp3.1/publish",
"azureFunctions.projectLanguage": "C#",
"azureFunctions.projectRuntime": "~3",
"debug.internalConsoleOptions": "neverOpen",
"azureFunctions.preDeployTask": "publish (functions)"
}
I'm presently trying to do some research on how / what specifically to downgrade but any tips / suggestions would be appreciated.
Azure PowerShell does not interfere with Azure cli installation.
Based on the error message, it looks like the version of the Azure function tools you are using is v4 but the function app that you have deployed is v3 (likely defined so in the ARM template that you are using).
I am trying to automate the process of an Azure Active Directory (AAD) app registration using Azure DevOps release pipeline but it fails to do so. (Please note that the same command (powershell commands as well as azure commands) works perfectly fine if I am running the same commands from my laptop) and for that I created an azure powershell task in the release pipeline and used the following line of code in the "inline script section":
I tried creating the AAD app registration using the following 2 methods:
1. "Azure Powershell script task"
2. Azure commands
Following is inline script that I used in case of azure powershell task:
Import-Module AzureRM
Import-Module AzureAD
# Register an AAD app
$appURI = "https://knaabdapp123.azurewebsites.net"
$appHomePageUrl = "https://knaabdapp123.knandan.in"
$appReplyURLs = #($appURI, $appHomePageURL, "https://localhost:12345")
New-AzureADApplication -DisplayName knaabdapp123 -IdentifierUris $appURI -Homepage $appHomePageUrl -ReplyUrls $appReplyURLs
I get the following error when I do so:
2019-08-09T11:27:31.1039145Z ##[section]Starting: Azure PowerShell script: Register an AAD app and generate credential for the same
2019-08-09T11:27:31.1162119Z ==============================================================================
2019-08-09T11:27:31.1162226Z Task : Azure PowerShell
2019-08-09T11:27:31.1162310Z Description : Run a PowerShell script within an Azure environment
2019-08-09T11:27:31.1162378Z Version : 2.153.1
2019-08-09T11:27:31.1162446Z Author : Microsoft Corporation
2019-08-09T11:27:31.1162520Z Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/deploy/azure-powershell
2019-08-09T11:27:31.1162620Z ==============================================================================
2019-08-09T11:27:37.0179906Z ##[command]Import-Module -Name C:\Modules\AzureRm_5.1.1\AzureRM\5.1.1\AzureRM.psd1 -Global
2019-08-09T11:28:10.7554409Z ##[command]Clear-AzureRmContext -Scope Process
2019-08-09T11:28:11.2755157Z ##[command]Disable-AzureRmContextAutosave -ErrorAction Stop
2019-08-09T11:28:15.0230853Z ##[command]Add-AzureRMAccount -ServicePrincipal -Tenant *** -Credential System.Management.Automation.PSCredential -Environment AzureCloud #processScope
2019-08-09T11:28:16.5226685Z ##[command] Select-AzureRMSubscription -SubscriptionId a*******-ae1c-****-****-********** -TenantId ***
2019-08-09T11:28:16.8648715Z ##[command]& 'C:\Users\VssAdministrator\AppData\Local\Temp\2a55****-67c6-****-8f80-**********.ps1'
2019-08-09T11:28:17.0308219Z ##[error]The specified module 'AzureAD' was not loaded because no valid module file was found in any module directory.
2019-08-09T11:28:19.0607544Z ##[command]Remove-AzureRmAccount -Scope Process -ErrorAction Stop
2019-08-09T11:28:19.4371114Z ##[command]Clear-AzureRmContext -Scope Process -ErrorAction Stop
2019-08-09T11:28:19.8885329Z ##[error]The term 'New-AzureADApplication' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
I also used the Azure CLI task and used the following script, but that fails too:
az ad app create --display-name MyApplication123 --homepage "https://myapplication1232.nl" --reply-urls "https://localhost:12345" --identifier-uris "https://myapplication2.azurewebsites.net"
I get the following error in this case:
>az ad app create --display-name MyApplication123 --homepage "https://myapplication1232.nl" --reply-urls "https://localhost:12345" --identifier-uris "https://myapplication2.azurewebsites.net"
2019-08-09T11:47:46.5676945Z ERROR: Insufficient privileges to complete the operation.
2019-08-09T11:47:46.6721317Z ##[error]Script failed with error: Error: d:\a\_temp\azureclitaskscript1565351201021.bat failed with return code: 1
So, I have 2 questions:
Is it possible to create an AAD app registration using "Azure powershell" task script or "Azure CLI" task in Azure DevOps?
If yes, then what may I be doing wrong?
Is it possible to create an AAD app registration using "Azure
powershell" task script or "Azure CLI" task in Azure DevOps?
For this question, the answer is Yes, of course you can.
The cause of the error you received in Azure Powershell task is as default, the AzureAD powershell cmdlets will not be installed in agent.So, if you try to using this module directly, you will receive the message like "##[error]The specified module 'AzureAD' was not loaded because no valid module file was found in any module directory."
If yes, then what may I be doing wrong?
To solve this error message, please try with replacing your script Import-Module AzureAD as the follow script to use a correct way to get the AzureAD module.
$AzureADModulePath = $PSScriptRoot + "\AzureAD\2.0.1.16\AzureAD.psd1"
Import-Module $azureAdModulePath
This is the detailed info about AzureAD module in Powershell Gallery. And also, here has a blog you can refer.
Updated:
You must install AzureAD cmdlets module from the PowerShell gallery with the below script first:
Install-Module -Name AzureAD -RequiredVersion 2.0.1.16
Note: If get error like Install-Module : Administrator rights are required to install modules while you install with this script, please add -scope CurrentUser to the install script. It will running the script as administrator role.
And then, import the module from the installed path afterwards.
When releasing the build in VSO, I would like to release it in a webapp staging slot. I'm using NewRelic, so I have to stop the staging environment, and set AlwaysOn option to false, before deployment, then put it on and start after deployment.
This is what I'm doing using Azure CLI task before the deployment task :
call azure webapp config set --slot staging Default-Web-WestEurope instanceName --alwayson false
call azure webapp stop --slot staging Default-Web-WestEurope instanceName
It works well when I launch these commands on Azure CLI on my own desktop. But when I put this script on Azure CLI Task on VSO, it works... but on the production slot.
It's very annoying because it put the production down.
Do you know how to update WebApp slot configuration in VSO continuous integration ?
According to your description, I tested it on my side and I could reproduce this issue. You could add -vv option as follows to see more verbose output.
azure webapp stop --slot <slot name> <resource-group-name> <your-webapp-name> -vv
Here is the build log of Azure CLI task from my VSO:
Note: Since Azure CLI task is in preview. For a workaround, you could leverage Azure Powershell task to stop/start your web app slot and configure the AlwaysOn option as following steps:
1. Add the AZURE Powsershell task
2. Add the following powershell script and push it to your source repository
1) Stop web app slot by using Stop-AzureRmWebAppSlot
stop-azurermwebappslot -name "<webapp-name>" -slot "<webapp-slot-name>" -resourcegroupname "<resourcegroup-name>"
2) Configure AlwaysOn by using Set-AzureRmResource
Set-AzureRmResource -resourcename "<webapp-name>\slots\<webapp-slot-name>/web" -ResourceGroupName "<resourcegroup-name>" -ResourceType "Microsoft.Web/sites/config" -ApiVersion 2015-08-01 -propertyobject #{alwaysOn = $false;} -v -force
3. Configure your task
Then we could see the following build log:
Additionally, I found there is a similar issue about the options to stop/start web app during Azure Web App deployment, you could refer to it.
We have a solution featuring a web application project destined as a web role in a Windows Azure cloud service. It also bears a cloud service project that targets the cloud service only (production slot)
SlnRoot\WebApp1\WebApp1.csproj
SlnRoot\CloudDeployment\CloudServiceName\CloudServiceName.ccproj
Publishing (deploying) from Visual Studio is very easy; simply select the Publish... option from the cloud project's context menu and hit Publish with all the pre-configured cloud service settings.
Now we are going a further step of trying to automate this process so I'm trying it out from command-line and raw MSBuild without the aid of Visual Studio.
.nuget\nuget.exe restore
msbuild .\CloudDeployment\CloudServiceName\CloudServiceName.ccproj /t:Publish /p:PublishDir=..\..\pubout\ /fl1 /v:d
But it appears the Publish target is in reality the Package option in Visual Studio, only generating the cspkg file which has to be manually uploaded to Windows Azure portal. This will not do, of course. Is there a separate target to specify to carry out the additional step (Deploy is not it; no such target) that Visual Studio carries out so easily?
Thanks for your advice. The true answer to the gap in my knowledge however - how do MSBuild and PowerShell gel together in the first place - came from my colleague who crafted a custom MSBuild proj file to get it all working together. A basic sample follows with comments
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0"
DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- Declare configuration properties for this deployment -->
<!-- This custom.proj file is in a sub-directory in solution root -->
<PropertyGroup>
<SolutionDir Condition=" '$(SolutionDir)'=='' ">$(MSBuildThisFileDirectory)..\</SolutionDir>
<SolutionPath Condition=" '$(SolutionPath)'=='' ">$(MSBuildThisFileDirectory)..\CloudService.sln</SolutionPath>
<OutDir Condition=" '$(OutDir)'=='' ">$(MSBuildThisFileDirectory)\Output\Binaries\</OutDir>
<PackageOutDir>$(MSBuildThisFileDirectory)Output\Packages\</PackageOutDir>
<TargetCloudService>targetcloudservice</TargetCloudService>
<DeployConfig>BuildConfig</DeployConfig>
<PubSettingsPath>$(MSBuildThisFileDirectory)subscription.publishsettings</PubSettingsPath>
<SubscriptionName>subscription name</SubscriptionName>
<StorageAccount>targetstorageaccount</StorageAccount>
</PropertyGroup>
<!-- Target to restore all Nuget packages on a clean repo pull. -->
<Target Name="RestorePackages">
<Message Text="Restoring nuget..."/>
<Exec Command=""$(SolutionDir).nuget\NuGet.exe" restore "$(SolutionPath)"" />
</Target>
<!--
Target to package the indicated cloud project,
which will build the referenced web role project first with desired build config.
-->
<Target Name="PackageCloud" DependsOnTargets="RestorePackages">
<Message Text="Creating package for cloud deployment ..."/>
<MSBuild
Projects="$(MSBuildThisFileDirectory)..\CloudDeployment\$(TargetCloudService)\$(TargetCloudService).ccproj"
Properties="OutputPath=$(PackageOutDir)$(TargetCloudService)\;Configuration=$(DeployConfig);"
Targets="Publish"/>
</Target>
<!--
Target to deploy the package produced by the dependency target.
This is the part that launches PowerShell to execute custom ps1 script
with all the cloud service parameters (MSBuild variables above)
and cspkg package for deployment.
The custom script uses the Azure module cmdlets to make service checks and publish.
-->
<Target Name="DeployCloud" DependsOnTargets="PackageCloud">
<Message Text="Deploying package to cloud service ..."/>
<Exec WorkingDirectory="$(MSBuildThisFileDirectory)"
Command="$(windir)\system32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy ByPass -f $(MSBuildThisFileDirectory)PublishCloudService.ps1 -packageLocation "$(PackageOutDir)$(TargetCloudService)\app.publish\$(TargetCloudService).cspkg" -cloudConfigLocation "$(PackageOutDir)$(TargetCloudService)\app.publish\ServiceConfiguration.Cloud.cscfg" -subscriptionDataFile "$(PubSettingsPath)" -selectedsubscription "$(SubscriptionName)" -servicename $(TargetCloudService) -storageAccountName $(StorageAccount)" />
</Target>
</Project>
So a one-shot deployment invocation would be something like
msbuild.exe custom.proj /t:DeployCloud
As astaykov pointed out, MSBuild on it's own doesn't know how to deploy to Azure but you can install the Azure Powershell SDK to do the deployment.
Even using the publishsettings file, there are still some additional commands you need to perform to do the deployment beyond just the publish one:
Import-AzurePublishSettingsFile - to use the settings
Set-AzureSubscription - used to set a default storage account (where you will upload the package from msbuild)
Select-AzureSubscription - used to update the subscription for your powershell context
Get-AzureStorageContainer - get the container you're going to upload the package to
New-AzureStorageContainer - useful if the container doesn't already exist
Set-AzureStorageBlobContent - Upload the package to blob storage
Get-AzureStorageBlob - Read info about the blob, likes it's Uri
Get-AzureDeployment - Get info about a deployment in a slot of your service - useful before dpleoyment, while waiting for instances to start, etc
Remove-AzureDeployment - Removes a deployment - useful if you publish to staging and VIP swap into production
New-AzureDeployment - Create a new deployment from a given package (blob), config, etc in a service
Move-AzureDeployment - VIP swap staging/production slots
Set-AzureDeployment - Can be used to change the status of a deployment
I have a post around building a sample publication script here: Automated Deployment to Azure Hosted Services
It walks through the process in greater depth to use those scripts in building a deployment script that follows the "deploy to staging and VIP swap into production" path, but a lot of the details are still relevant for a direct upgrade deployment.
I use a similar method for several projects, but go one step further and swap out the configuration projects in between an msbuild call and packaging.
On the "publish settings" vs credentials, I think it comes down to where you are going to be running these builds (and who has access to that environment) and whether you feel more comfortable with a certificate enabling access or a set of credentials, based on portability and visibility/access in your build process. A lot of the core steps will be the same, though.
After you get your CSPKG and CSCONFIG files, you need to "manually" publish your project. MSBuild does not publish the project. You can use Azure PowerShell to publish the project. The Publish-AzureService is the cmdlet you are looking for.
You can also configure one (or more) users in your Azure AD tenant (something that each Azure subscription has) and enable fully automatic deployment with PowerShell without the need of .publishsettings file and client certificates. Check my Non-interactive login with Azure PowerShell and Azure AD blog post.
UPDATE
Fairly stright forward and easy to use PowerShell Script for creating new deployment on existing Cloud Service and existing Storage Account:
Add-AzureAccount
Select-AzureSubscription "<subscription name>"
Set-AzureSubscription -SubscriptionName "<subscription name>" `
-CurrentStorageAccountName "<storage_account_name>"
New-AzureDeployment -ServiceName "<cloud_service_name>" `
-Package "D:/tmp/cloud/myservice.cspkg" `
-Configuration "D:/tmp/cloud/ServiceConfiguration.Cloud.cscfg" `
-Slot "Staging"
And an Upgrade Script:
Add-AzureAccount
Select-AzureSubscription "<subscription name>"
Set-AzureSubscription -SubscriptionName "<subscription name>" `
-CurrentStorageAccountName "<storage_account_name>"
Set-AzureDeployment -Upgrade `
-ServiceName "<cloud_service_name>" `
-Package "D:/tmp/cloud/myservice.cspkg" `
-Configuration "D:/tmp/cloud/ServiceConfiguration.Cloud.cscfg" `
-Slot "Staging"
For Slot you can either use Staging or Production. For the case you use publish settings file, just replace the Add-AzureAccount with Import-AzurePublishSettingsFile.
Note that these are verified scripts.
A good example of a script that deploys to an Azure Cloud Service from Build vNext source code: Publish-AzureCloudDeployment.ps1