I would like to restart my Azure Web App on 06:00 everyday.
I find a reference from Azure App Services: Automate Application restart using Web Job
But, there's some error in this post.
Save-AzureProfile => Save-AzureRmContext
Select-AzureRmProfile => Import-AzureRmContext
After fix this, run at local ,it's perfect.
When i create a web job on my Azure Web App, that get a error
Looks like it's not support Stop-AzureRmWebApp
Is there a soluction？
I tested it on my side. The PowerShell code which provided by the blob is working fine on my side. Here are the detail steps I did.
Step 1. Create a folder named TestRestartWebApp.
Step 2. Generate the profile file to that folder.
Save-AzureRmProfile -Path "D:\TestRestartWebApp\azureprofile.json"
Step 3. Create a PS file named run.ps1 in that folder.
Step 4. Following are the code which I put in run.ps1.
$ProgressPreference= "SilentlyContinue"
Select-AzureRmProfile -Path "azureprofile.json"
Select-AzureRmSubscription -SubscriptionId 'my subscription id'
Stop-AzureRmWebApp -Name 'my web app name' -ResourceGroupName 'my resource group name'
Step 5. Compress this folder and create a WebJob using the compressed file.
After upper steps, I can see the logs in WebJob dashboard. The Web App has been stopped.
Please double check your steps, are there any differences between yours and mine. Have you set the right path for profile file in run.ps1 file.
Related
I have been checking for ways to deploy a web job to azure automatically using PowerShell. I saw some blogs that depict the steps and the following summarizes what I have tried
I build my application (ASP.NET Console Application) in release mode and Zipped the contents of bin/Release to a folder.
In PowerShell, I logged in with az login
Then I tried the following commmand
Invoke-WebRequest -Uri https://$applicationName.scm.azurewebsites.net/site/wwwroot/app_data/jobs/triggered/$webJobName ` -InFile $ZipFile -ContentType "application/zip" -Method Put
$ZipFile has the path to the folder I created on step 1.
The output I get is the following
Invoke-WebRequest : The page was not displayed because the request entity is too large
Please let me know if you know what the issue is or If you have any reference that would help.
Thanks in advance!
Thanks for pitching in everyone! Your input was helpful, however I would like to update the answer with the solution I found that was so easy and saved me so much time. I will like to update you on how I could successfully deploy the app service and web job in a single go. Its very easy and since it deploys web app and corresponding web jobs in a single go, this was the perfect solution for my scenario. Thanks to my colleague who helped me with this solution.
The following depicts the steps I had to go through.
Lets suppose that my app service in Azure is "appService1" and I want to create a triggered web job under appService1 that goes by the name "webJob1".
I followed zip-deployment with azure cli.
Publish your web application (For the app service) solution in release mode to get the files you will have to deploy. Let this folder be WebAppBuild.
Build your application (a console application in my case) that would serve as the web job for the app service in release mode.
Inside the published folder for the web application (for app service ie WebAppBuild in our example), add a folder with the following path
app_data\jobs\triggered\webJob1
(If you need more than one web jobs deployed, you can create more than one folders like webJob2, webJob3 etc)
Add the files you have in step 2 to this folder. This is basically the files needed for your web job
Zip the contents in a single folder that acts as your deployment folder for web app and web job
Go to powershell and run az login (works if you have installed azure cli, otherwise you will have to install it as well)
Log into your respective account with the prompt window
Run the following commands that sets run from package property to true for your web app and the second command is the actual deployment command
az webapp config appsettings set --resource-group <<resourceGroupName>> --name <<appServiceName>> --settings WEBSITE_RUN_FROM_PACKAGE="1" ;
az webapp deployment source config-zip --resource-group <<resourceGroupName>> --name <<appServiceName>> --src <<zipFilePath>>
Now login to your azure portal and navigate to your web app. Check under web jobs option and you will see that the web job has been created with the files you deployed.
For more help on starting, stopping, deleting the web job with azure cli, go through the following document.
Check here
I have 1 function app that for some reason doesn't want to deploy (All 30 other function apps I manage deploy fine with the same ZipDeploy method).
After running the following AzureCLI command to deploy to an existing consumption based function app:
az functionapp deployment source config-zip --resource-group $resourceGroupName --name $functionAppName --src $artifactPath
This returns a successful deployment result (see bottom of question for the full JSON result), however looking in the Functions blade for the function app, this is empty:
My question is this - what am i doing wrong here? Why does deploying a function via AzureCLI fail?
A bit of background:
Functions we're using are precompiled C#
The function apps are created by Terraform
This function is a service bus trigger function that has the same host.json/functions.json as other successful function deployments
Things i've tried so far:
Deployed via the 'Publish' route in Visual Studio 2019 as a test. This works successfully.
Running the AzureCLI command locally, same result
Checked the function code structure against the suggested folder structure, this complies
Compared the zipped artifact i'm deploying against other successful deployment zips. Same structure as working functions.
Full logging from the AzureCLI command:
Setting SCM_DO_BUILD_DURING_DEPLOYMENT to false
Waiting SCM site to be updated with the latest app settings
Getting scm site credentials for zip deployment
Starting zip deployment. This operation can take a while to complete ...
Deployment endpoint responded with status code 202
Full JSON response from the AzureCLI command:
active : True
author : N/A
author_email : N/A
complete : True
deployer : ZipDeploy
end_time : 23/09/2020 16:32:28
id : 02c6219516244615beca1c126749baa1
is_readonly : True
is_temp : False
last_success_end_time : 23/09/2020 16:32:28
log_url : https://xxxx.scm.azurewebsites.net/api/deployments/latest/log
message : Created via a push deployment
progress :
provisioningState :
received_time : 23/09/2020 16:31:55
site_name : xxxx
start_time : 23/09/2020 16:31:55
status : 4
status_text :
url : https://xxxx.scm.azurewebsites.net/api/deployments/latest
EDIT 1: Here are the contents of the wwwroot folder for anyone interested - they follow the same structure as other functions we have (which deploy fine and display in the Functions view in the portal):
After long last we found out the cause of why the function app didn't deploy.
Turns out it deployed fine (the files were deployed in the right place) - it's just that the function runtime crashed on startup.
We found the usage of 'builder.Services.AddMvc()' caused this issue:
Which makes sense, given Azure Functions aren't Mvc. Derp!
We removed this line and voila, no more issues.
I might know what's wrong during your ZipDeploy process. Maybe the way you get your zip folder is wrong.
As I said, you can check if the destiny function app name is correct, and check if the content in https://<functionAppName>.scm.azurewebsites.net/DebugConsole -->site-->wwwroot(kudu) is correct.
The correct step of ZipDepoly is:
1. Click Publish option just like deployed via the 'Publish' route in Visual Studio 2019
2. Choose folder to create publish file.
3. Compress the publish file content you got from last step. The structure of publish file is same as in docs.
Publish.zip
| - bin
| - host.json
| - FunctionName
| | - function.json
4. Publish that zip file by your command. And the content of wwwroot should be same as publish file:
possible to have a public Azure Function that can overwrite and save code files in wwwroot of other azure applications? in particular aspx and run.csx files?
I understand the security risks, but the idea to have the Azure Function do this with a hard coded specific service account with rights and for two very specific aspx and run.csx files.
Neither of these requires a compile step in the Azure portal UI and wonder about that as well.
Just a question, not looking for best practices or reasons why we should not do this.
If you dont need to compile, just save the code and files,that is no problem.
But it can only be saved, it will not be a real web app, just some files.
You can use zip deploy or FTP to deploy the azure function app to azure and include the files you want to save.
If you Use zip deploy, just zip the files and code with the function app. And then use this command to deploy them to azure:
Azure CLI:
az functionapp deployment source config-zip -g <resource_group> -n <app_name> --src <zip_file_path>
PowerShell:
Publish-AzWebapp -ResourceGroupName <group-name> -Name <app-name> -ArchivePath <zip-file-path>
This is offcial doc:
https://learn.microsoft.com/en-us/azure/azure-functions/deployment-zip-push
Or you can use FTP to upload files.
Go to this place to get the host name:
Go to this place to get the username and password:
And then use them to connect to your function physical path:
At last you can upload anything to the wwwroot of your function app on azure.
This is the offcial doc:
https://learn.microsoft.com/en-us/azure/app-service/deploy-ftp
If you just want to rewrite the file under wwwroot folder, yes this is possible.
I have two function in the portal, in the HttpTrigger1 function I rewrite the HttpTrigger2 content. Below is HttpTrigger2 original content.
Below is HttpTrigger1 code, write a string to HttpTrigger2 run.csx.
Here is the result, after running HttpTrigger1, the HttpTrigger2 content is changed.
I have a c# web application running on IIS in a windows server core container.
In the dockerfile I create a new user 'myUser' without password.
I add the credentials to my Azure File store in the Dockerfile as well:
USER myUser
RUN powershell "cmdkey /add:mystore.file.core.windows.net /user:AZURE\mystore /pass:XXXXXXXXXXXXXXXXXXXXXXXXXXXXX=="
I add a new application pool Identity using 'myUser', and use that application pool for my application.
When I start the container and connect using 'docker exec', I am logged on as the new user.
I can access the path with 'ls \mystore.file.core.windows.net\dockerstore\'
The credentials are listed okay with 'cmdkey /list'.
However, my application which runs under the same user complaints it cannot reach the store. System.IO.IOException reported on Directory.Exists().
I have done this execise on my local box as well, and the application runs without issues.
I have tried using a user with password as well, to no avail.
The application use the full UNC-path to the store.
Tried the same thing on a windows service application. Same thing: Can list files in a powershell session, but my application cannot access it.
Am I missing something?
Edit: Here's what I did:
NET USER myAzureFilesUser myAzureFilesPasswordXXXXXXXXXXX== /add /y
NET LOCALGROUP Administrators /add myAzureFilesUser
Import-Module WebAdministration
$processModelProperties = #{userName='myAzureFilesUser ';password='myAzureFilesPasswordXXXXXXXXXXX==';identitytype=3}
Set-ItemProperty (Join-Path 'IIS:\AppPools\' 'My AppPool Name') -name processModel -value $processModelProperties
You need to create local user account with the same username and password as Azure File storage account and perform some additional tasks as described here. https://blogs.iis.net/davidso/azurefile
I can't describe this problem but it happened after I restore a site collection from our development machine to the production server. I see the same error page also when I try to access the site collection.
I tried to set customErrors to Off on all web.config files on the server but no luck.
I deleted the Site collection and the web application of that site but nothing changed. other site collections are working just fine.
Please help.
This is what I see when trying to create a new Web Application.
Maybe One reason is There is already a web application with the same name or same port in Central Application ,
Confirm that that is not the case?
You can try to follow steps given below:
Go to Central Admin->System Settings->Mange Service on server
Check status of following service:
Microsoft SharePoint Foundation Web Application
If it is stuck at stopping state, follow the steps given below:
Open command Prompt
Navigate to 14 Hive/Bin path
Enter following command
stsadm -o provisionservice -action stop -servicetype spwebservice
perform IISRESET with "Noforce" attribute
Execute following command
stsadm -o provisionservice -action start -servicetype spwebservice
Perform IISRESEt with "Noforce" attribute
Hope this helps