This article is part of a series. Here's a list of all available parts.
- Part 0: Introduction to the article series
- Part 1: Create an AzureRm Active Directory (AAD) Application using PowerShell
- Part 2: Getting started with the AzureRm PowerShell cmdlets
- Part 3: Build an application using C# which is using the Azure Resource Manager API's
- Part 4: Tip: Azure Resource Explorer Tool
- Part 5: Tip: Get all available api-version alternatives for the ARM endpoints
- Part 6: Move Azure Resources from one Resource Group to another
- Part 7: Download an Azure Publishing Profile (xml) programmatically using REST
- Part 8: Programmatically export Resource Group template using the REST API
Around the web there's a lot of tips on how you can manually download the publishing profile for e.g. a Web Site, API App or other resource in Azure.
From the modern Azure Portal this is very simple from the UI:
However, one of the main things I've been searching for is a way to do this fully automated from my code, scripts or other automatic processes - in order to avoid those manual steps, but also to ensure that I always get the correct and updated data (like deployment credentials).
In this post we'll take a look at how we can use the Azure Resource Manager REST API's to in a very simple request get the Publishing Profile xml for an Azure Web Site (or other resource with publishing profiles).
Use the Azure Resource Manager REST Api to download an Azure Publishing Profile
There's almost nothing to it. Simply make sure to send the correct POST request and you should be golden. See how below.
If you're looking for the basics of getting started, please check out the other posts in this article series. Start here.
The POST Request
In the Azure Resource Manager REST API, there's an endpoint called
publishxml which you can do a
POST request to get from any of your web sites.
Here's an example of what that looks like:
For this request you do not need any payload, you simply target your website and then append
/publishxml to specify that you want to get the publish profile as xml.
The XML Response
Upon performing that request, you'll get a response that contains the Publishing Profile XML, which looks like this:
<?xml version="1.0" encoding="UTF-8"?> <publishData> <publishProfile profileName="FacebookConnector17ec2275 - Web Deploy" publishMethod="MSDeploy" publishUrl="facebookconnector17ec2275.scm.azurewebsites.net:443" msdeploySite="FacebookConnector17ec2275" userName="$FacebookConnector17ec2275" userPWD="febBcaeyzZCk2mSjyTupWvBbnyYJmePMND71627zKunpruogyNQngE4vMlRAPF" destinationAppUrl="http://facebookconnector17ec2275.azurewebsites.net" SQLServerDBConnectionString="" mySQLDBConnectionString="" hostingProviderForumLink="" controlPanelLink="http://windows.azure.com" webSystem="WebSites"> <databases /> </publishProfile> <publishProfile profileName="FacebookConnector17ec2275 - FTP" publishMethod="FTP" publishUrl="ftp://waws-prod-db3-039.ftp.azurewebsites.windows.net/site/wwwroot" ftpPassiveMode="True" userName="FacebookConnector17ec2275\$FacebookConnector17ec2275" userPWD="febBcaeyzZCk2mSjyTupWvBbnyYJmePMND71627zKunpruogyNQngE4vMlRAPF" destinationAppUrl="http://facebookconnector17ec2275.azurewebsites.net" SQLServerDBConnectionString="" mySQLDBConnectionString="" hostingProviderForumLink="" controlPanelLink="http://windows.azure.com" webSystem="WebSites"> <databases /> </publishProfile> </publishData>
Based on the data that I just got back, I can choose to execute
Kudu API's or deployments or anything else that would require me to have this specific site's publishing profile.
Why not use user-level credentials instead?
One of the requirements for me is to automatically get this site's deployment credentials specifically, and ONLY this site's credentials. I don't want to use, nor do I want to incorporate code that uses my global azure deployment credentials.
Unique credentials per web site is a lot better to use for any deployment tasks where you're managing a load of different sites, in my opinion. Separation of concerns and isolation of credentials and data is a top priority for me.
An added benefit on top of this is of course that if the password changes for the user deployment credentials, your code is now unaffected - you simply request the publishing profile, and therefore the credentials, when you need them - always getting a set of fresh credentials, but without storing them in your source code or anywhere else they might pose a danger if exposed.