I'm migrating a pretty serious multi-tenant application to Azure, and one of the challenges I see coming is that it hosts over a hundred domains.
On the Azure side, the only way I see to add a custom domain is hand-entering them via the portal. I would really like to script this out with Azure PowerShell or (perhaps less desirable for this one-off operation) one of the .Net APIs.
I did find this, which shows that it can be done with one of the REST APIs: Add a domain to an Azure web site via code
Is there anything for PowerShell?
you can use -
Set-AzureWebsite -Name "ramisample" -HostNames #('www.abc.com', 'abc.com')
Make sure you point the CNAME records before adding them as domains.
Related
I would like to be able to call Powershell scripts using a REST API. (Please note that I am describing the _opposite_ of calling a REST API from Powershell.) Are there any prebuilt API gateways that support this use case? I've looked at Ocelot, but it currently only acts as a gateway to other REST APIs. Ideally I would simply design my Powershell script functions to follow a defined interface pattern, put the files into a defined directory, and the API gateway would either immediately make those functions available as REST API calls or with minimal configuration.
EDIT: To clarify, I am looking for something self hosted, not cloud based. I haven't found anything yet that is exactly what I need, I may create something myself.
You can try AWS Lambda and API gateway integration.
Here is an example: https://aws.amazon.com/blogs/developer/creating-a-powershell-rest-api/
Amazon offer 12 month free tier plan for this.
A couple of options. If you are on Azure you could expose your Powershell Scripts through Azure Automation :
https://learn.microsoft.com/en-us/azure/automation/automation-webhooks
That'd be a lightweight way of having your scripts enabled through a HTTP POST scenario.
You could also combine or mix it with adding API Management in front to support various scenarios (adding GET/PUT/DELETE support e.g.) or even automate or proxy more things. API Management could of course also be automated.
https://azure.microsoft.com/en-us/services/api-management/
You could also create a folder structure with modules & sub-functions and create a full REST API by using Azure Functions with PowerShell:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-reference-powershell
The latter would also be able to execute in containers & in the supported Azure Function
runtimes.
Has anyone come up with a complete solution to protect and replicate VMs from on-prem (either VMware or HyperV) to Azure using either the REST API or the Powershell module?
I recently completed a POC with ASR and was able to replicate a couple dozen VMs associated with three different applications. I replicated out of VMware and into Azure. I was able to failover and failback successfully.
I did all of the POC work using the GUI (portal.azure.com). Now I have to figure out how to protect ~2000 VMs and there is no way that I am going to do that with the GUI. But the MS documentation has me running in circles.
(https://learn.microsoft.com/en-us/azure/site-recovery/)
It would be very helpful if any of you can share the sequence of steps to protect and replicate a VM. The MS documentation does not lay out how the various components (fabrics, protection policies, protection containers, protection items, etc.) are related to each other.
I do not need specific syntax. The documentation does a passable job of detailing the syntax. I could use some guidance on the task sequence.
If it helps to understand the bigger picture, my intention is to use a System Center Orchestrator runbook to ingest a CSV list of VMs, parse that out into input for the Azure REST API / Powershell, and then enable protection.
Thanks in advance for any assistance or guidance that you are able to provide.
You can find recovery service API documentation here:
https://learn.microsoft.com/en-us/rest/api/recoveryservices/
When you have one definition put in place(manually from portal), you may also be able to study it from resource.azure.com to see how properties are composited. *not all resource available thru this portal
After that, you should be able to create template for either REST call or Resource Manager, depending on preference.
To authenticate to Azure and use the Azure Resource Manager cmdlets, I currently use the methods outlined here, namely using an Azure Active Directory account, encrypting the password, storing the encrypted string in a text file, and reading that into a credential object when using it in the script.
But I get the sense that maybe I should be using management certificates instead.
There is a documented method to use a publish settings file, but apparently that doesn't work for AzureRm cmdlets, only older cmdlets.
I have seen examples for using Powershell to create an application_id and service principal, and for authenticating a C# app, for instance, but I can't seem to find anything showing how to use management certificates for authentication in a powershell script, to use AzureRm cmdlets.
Maybe the secure string password storage method is the right one. But I don't have a good sense for that.
What do you use?
The best way to do it? It depends what is important to you. Ease of use, security, scripting?
Microsoft Azure Tooling (Visual Studio, Azure Powershell and CLI) lately moved to a more fine-granular, role-based access control approach based on Azure AD. This is currently a pretty good way to do it, since Management certificates allow owners to manage at subscription level and have proven to be rather difficult in environments like Azure Automation.
Refs
https://azure.microsoft.com/de-de/blog/azure-automation-authenticating-to-azure-using-azure-active-directory/
https://azure.microsoft.com/en-us/documentation/articles/cloud-services-certs-create/#what-are-management-certificates
http://blogs.msdn.com/b/cloud_solution_architect/archive/2015/03/17/rbac-and-the-azure-resource-manager.aspx
https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/
https://azure.microsoft.com/en-us/documentation/articles/resource-group-rbac/#concepts
You should have a look to Service Principal
https://azure.microsoft.com/en-us/documentation/articles/resource-group-create-service-principal-portal/
https://azure.microsoft.com/en-us/documentation/articles/resource-group-authenticate-service-principal/
I would like to find out what the best practices are for managing developers' access to a sub-set of resources on a client's subscription?
I've searched Google and the Azure documentation looking for definitive answers, but I have yet to come across an article that puts it all together. Because Azure is still developing so rapidly I often find it difficult to determine whether a particular article may still be relevant.
To sum up our situation:
I've been tasked with researching and implementing the Azure infrastructure for a web site our company is developing for a client. At the moment our manager and I have access to the client's entire subscription on the Azure Portal by means of the Service Administrator's credentials, even though we're managing only:
Azure Cloud Service running a Web-Role (2-instances with Production and Staging environments).
Azure SQL Database.
Azure Blob Storage for deployments, diagnostics etc.
We're now moving into a phase where more of the developers in the team will require access to perform maintenance type tasks such as performing a VIP swap, retrieving diagnostic info etc.
What is the proper way to manage developer's access on such a project?
The approach I've taken was to implement Role Based Access Control (https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/)
Move 1, 2, and 3 above into a new Resource Group according to http://blog.kloud.com.au/2015/03/24/moving-resources-between-azure-resource-groups/
Creating a new User Group for our company, say "GroupXYZ".
Adding the "GroupXYZ" to the Contributor role.
Adding the particular developer's company accounts to "GroupXYZ"
Motivation for taking the role-based approach
From what I understand giving everyone access as a Co-Administrator would mean that they have full access to every subscription in the portal.
Account-based authentication is preferable to certificate-based authentication due to the complexity added by managing the certificates.
What caused me to question my approach was the fact that I could not perform a VIP swap against the Cloud Service using PowerShell; I received an error message stating that a certificate could not be found.
Do such role-based accounts only have access to Azure by means of the Resource Manager Commandlets?
I had to switch PowerShell to the Azure Service Manager (ASM) Mode before having access to the Move-AzureDeployment commandlet.
Something else I'm not sure of is whether or not Visual Studio will have access to those resources (in the Resource Group) when using Role Based Access Control.
When you apply RBAC to Azure as you have or just in general, give access to an account via RBAC, then those accounts can only access Azure via the Azure Resource Manager APIs, whether that's PowerShell, REST or VS.
VS 2015 can access Azure resources via RBAC when using the 2.7 SDK. VS 2013 will have support for it soon.
What is the best way to create a new Windows Azure Hosted service from a running role using a package and configuration that I have stored in blob storage?
I am guessing that I could use a Service Management REST API Create Deployment request, however running a cmdlet from my worker role might be better. Any thoughts? If the cmdlet route is better, bonus points if you can point me in the right direction on how to run them from a worker role.
Not sure what is 'best' here because it depends on what you are trying to do. If you just need to create a hosted service programmatically it would be about the same to create a REST client, upload a cert, and just do it versus using the cmdlets or anything else.
As the creator of the cmdlets, they have a special place in my heart, but I would probably stick to using those for IT admin tasks. They rock for cmd line automation.
That being said, it is not terribly hard to roll your own client, but I typically recommend that you download the Service Managements contracts from csmanage. That way, you have a simple wrapper around this to get going. While it does use WCF, it is not too onerous.