Today I want to show a really useful Azure feature to help you with the governance of your Azure Subscriptions: Azure Resource Policies:
The standard input and output bindings in Azure Functions are written in a declarative pattern using the function.json. When defining input and output declarative, you do not have the option to change some of the bindings properties like the name or make multiple outputs from one input. An imperative binding can do this for you. In this blog post I’ll show how to use imperative blob bindings.
Imperative binder pattern
The imperative binder uses a pattern where you add the Binder object in the signature of your Run method. In the function you use attributes to bind the output to the binder. You can bind multiple outputs to the binder, and you are able to combine a declarative binding with the imperative binding. In this case the BlobTrigger is defined in function.json. Do not include the output binding in you function.json:
I’ve created a new VSTS Build & Release task to help you interact with the (VFS) Virtual File System API (Part of KUDU API of your Azure Web App). Currently this task can only be used to delete specific files or directories from the web app during your build or release workflow. It will be updated in the near future to also be able to list files or to upload / download files through the VFS API
The reason i made this task was that i needed it at my current customer. We’re deploying our custom solution to a Sitecore website running on Azure web apps using MSDeploy. The deployment consists of 2 parts: an install of the out-of-the-box Sitecore installation and the deployment of our customisations. When deploying new versions we want to keep the Sitecore installation and MSDeploy will update most of our customisations. Some customisations however create artifacts that stay on the server and aren’t in control of the MSDeploy package that can cause errors on our web application. This new VSTS Build / Release task can help you delete these files. In the future this task will be updated with other functionality of the VFS API such as listing, uploading or downloading files.
Let’s have a look how to use this task and how it works under the hood.
Azure functions are great to build small specialized services really fast. When you create an Azure Functions project by using the built-in template from the SDK in Visual Studio you’ll automatically get a function made in a CSX file. This looks like plain old C# but in fact it is actually is C# Script. When you’re deploying these files to Azure you don’t have to compile them locally or on a build server but you can just upload them to your Azure Storage directly.
In the last update for Azure Functions the option to build precompiled functions was added. Doing this is actually pretty simple. I’ve created a sample project on Github containing a precompiled Azure function, unit tests for the function and an ARM template to deploy the function. Lets go over the steps to create a precompiled Azure function.
From Visual Studio Team Services (VSTS) it’s possible to deploy to an Azure Subscription using an Active Directory Service Principal.
Although the information on the blog post for the 3-clicks setup is still actual, the script link provided for the manual configuration is not available anymore (not found, probably because the Git repo has been moved/renamed).
For both the suggested ways (3-clicks or manual), there are some concerns from my side about the principal setup, which I think they could be improved:
- The principal which is created during the process gets the “Contributor” role granted on the whole Azure subscription, and using the manual powershell script, the default role is even “Owner” (this can be modified).
- The name of the Active Directory Application/Principal is some random guid which is difficult to be identified, see this picture:
Azure Functions enable you to easily run small pieces of code in the cloud. To do this right, you need to setup continuous delivery of the infrastructure and the code involved. Otherwise you will end with an uncontrolled environment where nobody knows what code is actually running. In this blog post I’ll describe how to setup a deployment pipeline for Functions with VSTS. This will enable you to deploy Functions as Infrastructure as Code.
From an deployment perspective an Azure Function contains of two parts:
In my previous blog post Lock Azure resources to prevent accidental deletion, I showed how to add a lock to a resource with an ARM template to protect it from accidental deletion. When you want to delete the resource, you first need to remove the lock. A lock cannot be removed with an ARM template. To remove the lock you can use:
In some cases you want to protect critical resources from accidental deletion. Some examples are a storage account with source data for processing, a Key Vault with disk encryption keys, or another key component in your infrastructure. When losing some resources that are key in your infrastructure, recovery can be dramatic. Resource Manager locks will enable you to protect these critical resources from deletion.
When running ARM templates to deploy Linux with disk encryption on Azure I encountered a few errors. The errors where coming when I rerun the same template multiple times. In this post I explain the errors and how I fixed them.
In this post I want to show you what I think it’s the best way to setup VSTS working with Azure Resource Manager Templates.
At the customer I am currently working for, we are setting up a new Azure Big Data ingestion environment and we wanted to do it using the Infrastructure as Code approach. With Azure this obviously goes with ARM Templates.
For source control, build and deployment we use Visual Studio Team Services (VSTS).
About VSTS, Build and Release Management
I have seen different setups with VSTS, some of them where the deployment take place from the build, or directly in Release Management without a build.
My approach is to have a clear separation of concerns between the Build and the Release Management.
The Build is for compiling, (Unit) Testing and creating artifacts for the deployment.
The Release Management’s responsibility is for deploying the artifacts created during the Build process.