I'm creating a test environment in Azure. I want to have an accurate script of what of the configuration so it's easy to replicate for other test, pre-prod and prod environments later on. The environment has an existing subscription, and I want the entire hierarchy of resources from Resource Groups through to Web Apps to be created by script.
I'm currently rolling my own script in PowerShell utilising AzureRm. This is working well, but I can't help feel I'm reinventing the wheel. What is the existing method for creating an entire Azure environment by script?
Yes, that way is called Azure Resource Manager Templates. Quote:
With Resource Manager, you can create a template (in JSON format) that defines the infrastructure and configuration of your Azure solution. By using a template, you can repeatedly deploy your solution throughout its lifecycle and have confidence your resources are deployed in a consistent state. When you create a solution from the portal, the solution automatically includes a deployment template. You do not have to create your template from scratch because you can start with the template for your solution and customize it to meet your specific needs. You can retrieve a template for an existing resource group by either exporting the current state of the resource group, or viewing the template used for a particular deployment. Viewing the exported template is a helpful way to learn about the template syntax.
Reference: https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview#template-deployment
Edit: you can use powershell, azure cli, azure cli2, azure sdk to deploy those templates (or simply Azure portal, search for "Template Deployment")
Related
Ì would like to deploy Storage, SQL Logical Server and SQL database with ARM. Currently templates are all located under own folder in repo /Storage /SQLLogicalServer /SQLDB
I can deploy they one by one with dedicated pipeline currently.
What is best practice to deploy several Azure resources with single pipeline?
Is it good idea to use one master ARM template that call each resource ARM?
Any tutorial or article about this scenario?
What is best practice to deploy several Azure resources with single
pipeline? Is it good idea to use one master ARM template that call
each resource ARM? Any tutorial or article about this scenario?
You can follow Deploy nested Azure Resource Manager templates for testing environments to combine your three templates into one, then you would easily use one single pipeline to deploy them together. Here's a similar scenario like yours.
Note:
If you have separate pipelines for your three ARM templates, you can easily customize them. E.g: You can set the pipeline to be triggered only when the corresponding ARM template repo is changed. If the ARM templates are in one pipeline, they would be deployed even when only one of them is changed. (In that scenario, you can use this as workaround.)
Whether it's good idea totally depends on your needs/scenarios. Hope it helps :)
I need help to understand better how to create complete CI/CD with Azure Devops for APim. Ok I already has explored the tools and read docs:
https://github.com/Azure/azure-api-management-devops-resource-kit
But I still have questions, my scenario:
APim dev instance with APi and operations created and others settings, as well APim prod instance created but empty.
I ran the extract tool and got the templates (not all), still need the Master (linked templates), and on this point seat my doubt, I already have 2 repos too(dev and prod).
How can I create the Master template, and how my changes from dev environment will be automatically applied to prod?
I didn't used the policyXMLBaseUrl parameters not sure what Path insert there, although seems #miaojiang inserted a folder from azure storage.
After some search and tries I deployed API's and Operations from an environment to another, but we still don't have a full automated scenario, where I make a change in a instance and that is automatically available.Is necessary to edit policies and definitions directly on the repositories or run the extract tool again.
I'm using Visual Studio Team Services and I'm trying to set up Release Management to allow automated deployments for our Azure Web App to multiple environments. I would like the same source to be deployed to each environment, but with modified configuration settings.
I was hoping that I could create a single Build for my application, and then modify the configuration at deployment time for each environment. I'm aware that this can be done for appSettings and connectionStrings (either through Tokenization, or even managing those settings via the Azure portal), but I'd like to be able to make more general changes to the web.config file. For example, I want to be able to:
Update 'simple' settings such as appSettings/connectionStrings
Update multiple attributes on elements (like httpErrors)
Insert or rewrite sections of the config file itself (for example to add IIS rewrite rules, or to remove unwanted HTTP handlers for production)
Currently we achieve this by using config file transformations and separate publish profiles for each environment (manual deployment). I can't see a way to re-use this if I want a single release pipeline.
I'm hoping someone can help point me in the right direction. I'm also happy to accept alternative solutions - ultimately I just want to be able to deploy the same source (e.g. from the same commit in source control) to multiple environments, with different configuration, while keeping some kind of flow from dev, to test, to eventually production.
You can use Tokenization Task to update the files base on the environment variables.
More similar extensions: Replace Tokens and Colin's ALM Corner Build & Release Tools.
When creating a new release definition in VSTS using the Azure Website Deployment template you get two tasks added automatically.
One of those tasks is the "Deploy Website to Azure". In that task there is a setting called "Additional Arguments". What is this setting for? And what does the defaults do?
-connectionString #{"$(ConnectionStringName)"="Server=tcp:$(ServerName).database.windows.net,1433;Database=$(DatabaseName);User ID=$(AdministratorLogin)#$(ServerName);Password=$(AdministratorLoginPassword);Trusted_Connection=False;Encrypt=True;"}
I have checked the docs at https://www.visualstudio.com/docs/overview but I can't find a single paragraph where someone talks about this feature. Google hasn't been of any help either unfortunately. I would appreciate it if someone could explain.
The Azure Web App Deployment task uses Publish-AzureWebsiteProject command to publish the web deployment package just as starain mentioned. With this command, you can specify the "-ConnectionString" argument to configure the connection strings in the deployment. The setting in the task is used to do this.
As soon as you create a release definition with "Azure Website Deployment", you will see this setting, and you will also see the related variables created if you select "Configure variables...":
You can then update the connection strings by update the value of these variables.
Based on this article: https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/AzureWebPowerShellDeployment/Publish-AzureWebDeployment.ps1, it uses Publish-AzureWebsiteProject command. https://msdn.microsoft.com/en-us/library/dn722468.aspx
The Additional Arguments is used for extra arguments that not included, for example, the -connectionstring argument, which is to use for the deployment.
You may want to consider utilizing the Deploy Azure RM Web App task instead as it provides more capabilities and leverages the Azure Resource Manager (ARM) APIs instead of the legacy Azure Service Management infrastructure. Both use Web Deploy for actual deployment of the application. Please note that to use the ARM-based tasks, you need to configure a Azure Resource Manager Service endpoint (link is in the documentation referenced)
I have a project that uses Entity Framework 6.x, ASP .NET WebApi 5.x. Data Access is in a secondary project inside the solution. I want to use VSTS (aka Visual Studio Online) to build and release it as a website to environments for integration/dev, qa, stage, and production. There are some great videos on Channel 9 that deal with the generic high-level description. (for example https://channel9.msdn.com/Series/DevOps-Release-Management and https://channel9.msdn.com/Series/DevOps-Fundamentals/Infrastructure-as-Code) There are all kinds of articles and videos about how to do migrations from inside Visual Studio including generating scripts.
Searching around the web I don't even find any older resources or concrete examples of continuous deployment with code first migrations. There must be examples and best practices for methods other than auto-migrations or SQL scripts.
I have configured a Web Deployment Package publish profile. I use it via the PublishProfile msbuild.exe directive. The package is added to the artifacts and then deployed by the Azure Web App Deployment task in each Release environment. However once this package is built, I don't know of a way of changing the connection string in the build package for each time it is released to an environment.
There is probably something I am overlooking, but how should environment specific migrations be done with via VSTS Release?
For Code First Migration, you can "Write App_Start code to run Migrations" or "Write Web.config transforms to configure the MigrateDatabaseToLatestVersion initializer to run", refer to this article for details: http://blogs.msdn.com/b/webdev/archive/2014/04/09/ef-code-first-migrations-deployment-to-an-azure-cloud-service.aspx
For the connection string transformation with profile, you need to add a web.config file for the publish profile and then enter the connection string in this web.config. Refer to this link for details: http://awaitwisdom.com/publish-profile-config-transform/
I hate to answer my own questions here but, ultimately my research took me to the conclusion I am posting at length here. In sort, Web.config and Parameters.xml require some custom scripting that will require you to maintain your own deployment automation. These routes will still require you to additionally create your resource groups or manage them manually.
To avoid these complications and cobbling tools and scripts together, the whole operation can be achieved with two JSON files. These JSON deployment templates allow you to create or update your resource group when your deployment runs. They also allow you to automate setting appsettings and connectionstrings that overwrite your Web.config values in the same manner as you can through the Azure Portal.
the steps: (1) Add the two JSON files to the project setting the name of you connection string on line 88 (2) Add a Azure Resource Group Deployment task to the Release environment. (3) Set Template (WebSite.json) and Template Parameters (WebSite.parameters.json) paths in the task. (4) Set Override Template parameters to -hostingPlanName "myHostingPlan" -webSiteName "myWebsiteName" -connectionString "the-actual-connection-string" (5) make sure you are using the same website name in your Azure App Deployment task.
This does depend on having your code first migrations run via App_Start or something similar. I took the first part of #Eddie's suggestion since App_Start is easy to deal with and doesn't seem to run too often.
As a bonus you can add environment variables for any of this configuration so you can clone the environment and then just change the variables. This ultimately makes your application or api connection string a Release variable.