We would like have a DR and staging subscriptions at my Azure. Also we do not want to pay for not used resources. We have Continuous deployment server. We would like to have the same deployment process in different environments.
Process
1.We read the current live subscription configuration from Azure resource manager
2.Modify some parts
3.Create DR and Staging
4.Deactivate them when not used using API calls triggered from the Continuous deployment server
5.Activate them when not used using API calls triggered from the Continuous deployment server
From time to time we are updating the resources.
Questions
What are the best practices ?
What are the API calls we can use?
I would argue that this is not possible (I might be wrong, never tried disabling subscription with active resources and see what happens) and not viable (for sure).
First of all, most PaaS offering cannot be switched off in Azure. That means you cannot achieve what you want (well, unless you can disable the entire sub and enable it after with all the resources starting to work like nothing happened). To try and figure the REST call to disable the sub I would go and capture the rest request with fiddler and try to reproduce it. Because I'm quite sure this call is not documented
The route I would go in this case - I would create ARM templates to make deployments repeatable and use those to deploy needed resources into prod\dev\stage\whatever with a flip of a switch. This would allow you to have the same deployment process you crave for.
Related
We currently have an Azure account set up through a third party who happens to be a CSP. As expected, this took several hours to set up and configure.
We're looking to move from that CSP partner to an account that we manage ourselves. The feedback we're getting is that that's not something easily done.
Has anyone experienced difficulties moving from a CSP to a pay as you go subscription, or is this company we're dealing with holding something back? I obviously want to avoid the several hours of re-setting up all of our resources.
Migrating resources across accounts are not something I have seen done. But you may get the Azure resource manager template for each resource. See attached link.
At the same time I would encourage you to implement infrastructure as code as part of your best practice for development in your organization. Infrastructure as Code is a process of managing and provisioning computing infrastructure in Azure with some declarative approach while setting their configuration using definition files instead of traditional interactive configuration tools.
The key benefits of IaC are:
Consistently achieve standardised provisioning or deployment
Accelerating provisioning or deployment rapidly
Reusable JSON code for repeatable or similar provisioning or deployment
Extensible JSON code for incorporating with additional items
Export template: https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-export-template
Infrastructure as code: https://blogs.msdn.microsoft.com/azuredev/2017/02/11/iac-on-azure-an-introduction-of-infrastructure-as-code-iac-with-azure-resource-manager-arm-template/
I have implemented a WebApi that is now running in Azure. Now I need to implement a recurrent service that will run everyday. The main problem is I do now know the best and safer way to achieve it since I have never done anything like it.
I know that in Azure I can create a configurable scheduler or webjob that will call an endpoint recurrently, but for that I think my WebApi needs to expose the endpoint to be accessed. To be honest, this would facilitate my life since I have all my code there with easy access to the storages and stuff, but I have no idea if it can't cause a security problem.
I also read about Fluent Scheduler which can run in my WebApi and I liked this approach, but sincerely I do not know what is the best way to achieve what I pretend.
I suggest you create a WebJob and use the Azure Scheduler to schedule it to run once per day at a set time.
Microsoft has some great documentation, check out the section "Create a scheduled WebJob using the Azure Scheduler".
My company developed an Azure Resource Manager-based solution that deploys a set of resources (essentially a Storage, SQL DB and Web App), and it is already implemented as our provisioning process for new customers.
However, we are now studying the best way to perform updates, and one of the hypotheses we are considering is having a specific template that updates the binaries of this application.
The idea is to have a separate template, that only has the web app, an app host and a MSDeploy resource that gets the latest version of our package and reuploads it to that web app.
The only problem I'm seeing with this solution is the ability to handle any changes in configuration that are necessary with newer version of the binaries - we do not want users to have to re-input any parameters they placed for the original deploy (done via a Deploy To Azure button), so, any configurations will have to be performed within the application - the plan is for it to use the Microsoft.WindowsAzure.Management.WebSites library.
The major limitation with using Microsoft.WindowsAzure.Management.WebSites is that you are restricted to authenticating with either a certificate or a service principal. Ideally we would like to find a way for the updates to not need any authentication other than the one you provide when you are deploying the update.
Is there any recommendation of best practices to follow for this kind of scenario?
Thank you.
Link to the equivalent discussion on TechNet
It is possible to update only via ARM templates.
For example connection strings can be added automatically to the application settings even when creating the dependent resources themselves.
Ex. Account storage connection string.
Only first time creation of your web sites will take a bit more time, something like 30 sec.
ARM will not destroy your WebApps if they exist already. it will update only.
If there are no changes, then the deployment is very fast.
If your changes require a new Appsettings parameter, you can enter it in ARM , check in to your repository.
and next deployment will pick up and update the WebApp.
So no need for anyone to log-in and update.
Our final decision was to give up on using ARM exclusively. The Service Principal solution, through the SDK, would allow us to use a Web Job or a Site Extension to perform (automatic or prompted) updates that included configuration changes. However, it would require "too many" privileges - why would a customer trust an application that can, at will, create new resources or update existing ones to increase his Azure bill?
The decision was made to utilize Powershell only for updates - if the customer can see the scripts and authenticate himself, this is not a concern. Sadly, this increases update complexity, but we found it to be a necessary evil.
I created my custom Azure Worker Role. This code is ready. What I'm trying to do is to create instances of this Azure-Worker-Role in specific Azure data-center, at the requested time. For example, I'm want to send command to Azure to create 10 instances of my Custom-Azure-Worker in West-Europe data-center - now.
It's important to pass this command also a parameter that will be the input problem to be solved by my workers.
I pretty sure that this automation task must be covered by Azure automation. Is that true? Looking for more information\directions.
Thank you!
You can use Azure Management Libraries to create and deploy your cloud services from C# code. Just create application (eg ASP.NET MVC) to manage your cloud services by sending commands and deploy it also on Azure or even keep it locally.
See this article for more details http://www.bradygaster.com/post/getting-started-with-the-windows-azure-management-libraries
You'll want to leverage the service management API to spin up and tear down roles. It can be accessed any number of way, including directly via REST.
RE: providing a parameter to the worker role, one option is leveraging the cloud service configuration file that you provide with the cspkg. Define specifics for the role there.
Depending on the complexity or simplicity of your scenario, you may also get away with simply having a table in storage that you personally poke with desired configuration values and that the worker can read to retrieve.
The Azure Automation service should definitely be able to automate this task for you. Anything you can script via the Azure PowerShell module, can be imported as a runbook and called manually, via a third-party system, or on a schedule in Azure Automation.
Whether there is an existing runbook for the specific task you are looking to automate, I do not know. But Azure Automation has a gallery of community-contributed content for many common processes, so this may be available there.
We are thinking of using Windows Azure for simulation. ~100 VM nodes each working on it's problem set and reporting back the result to a Master node.
I have created VM instances from the web UI. In order for this to work, we would need to use Azure API to bring servers up and shut them down once they are done.
Does anyone have any experience with something like this? I am looking for advise, gotchas etc.
thanks.
You sure can do it and I have helped other to make it happen on hundreds on nodes. Take a look at Windows Azure Rest API to configure your role as described here. While others may have other idea, I think the general steps would be as below:
Create a master machine or a webrole to manage your roles using REST API
Create a worker role instance and use it to clone multiple instances as if needed
Use REST API to start and shutdown worker role along with update the instance count when in need
Use Azure Boot Strapper to bootstrap the VM depend on your requirement
Azure REST based Service Management API can work from a web app or a standalone app, so you can also have a web role to make it happen from anywhere in world. This way you don't need any on premise components at all as it will be totally cloud solution. If you need any help on creating web role I sure can help.
You can provision Virtual Machines using Service Management REST API (there's also a managed API on NuGet).
But in your case you might want to consider using Cloud Services (PaaS). With Cloud Services you simply build your application, you package it and deploy it. Then using the portal or the management API you can simply configure the number of instances. There is even a command line tool (csmanage.exe) which allows you to to change the number of instances through the service configuration.