For today’s post, we’re going to do a REST call towards an Azure API. For this we’re going to create a “Servce Principal” and afterwards use the credentials from this object to get an access token (via the Oauth2 Client Credentials Grant) for our API.
What’s the flow going to be?
- The application does a clients_credential call. Here it’ll provide ;
- it’s application id as a client_id
- it’s secret as the client_secret
- choose “clients_credentials” as the grant_type
- set the “resource” to “https://management.azure.com”
- AAD will return an access token
- You can now call the API adding an additional header ;
- Header Name = Authorization
- Header Value = “Bearer *accesstoken*”
- The API will return a response
(Source : https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-service-to-service )
Now let’s see how that would look in reality?
Continue reading “Azure : “My first REST API Call”-tutorial”
Today’s post is conceptually a rather simple one… Let’s see how we can go from this ;
To here ;
By using a CI/CD pipeline.
Flow of the day
What will we be doing today?
- Kick-off a VSTS build once a change has been made to our Github repo
- Build a container via VSTS
- Publish the container to an ACR (Azure Container Registry)
- Kick-off a VSTS release once the build succeeded
- Use an ARM template to deploy an ACI (Azure Container Instance) with our docker container underneath
Sound cool? Let’s get to it!
Continue reading “From Github to ACI – A tale how to use Visual Studio Team Services & Azure Container Registry for Container CI/CD”
From template code to deployment… If we really want to control this, then we’ll be pushing these templates through a CI/CD (continuous integration / continuous deployment) pipeline. What does that mean? We are going to put our template in a source code repository (like Github). Everytime we update the code, we’ll going to kick in a “build”. During this build we’ll be packaging it (read : create a zip file of it) and it is also strongly advised to do testing here too. Next up, if all goes well, we’ll be using that package to deploy to all our environments. And in the end, we want to be able to have a nice view on this too…
Why do it like this? Quality! We all make mistakes. We want to detect them early and not repeat them. And every change, we want to put it through the exact same process… time and time again!
Starting off, I’m assuming you already have VSTS (Visual Studio Team Services) in place. If not, register for it! It’s free up till 5 users. And let’s be honest, at about 5€ per user / month & 8€ per build agent per month, … it’s still a steal! 😉
Continue reading “Azure : Pushing Azure Resource Manager Templates through a CI/CD (release) pipeline with Visual Studio Team Services”
Today’s blog post will showcase how you can leverage the DSC pull feature of Azure Automation when deploying workloads to Azure. To many, the following question will pop up ; “Why use a pull mechanism, whilst I could use the DSC extension to push my configs?”. The answer is pretty simple The pull mechanism facilitates the lifecycle flow of workloads better. You can easily update the config of the virtual machine and do follow-up on the rollout of your configuration.
Now how would such a flow go?
- We’ll use an ARM template to deploy (and afterwards keep) our Azure Automation Account (up-to-date)
- We’ll use a script to import the Powershell modules into our Azure Automation Account, which are needed to compile configurations.
- We’ll use a script to import & compile the DSC configurations into ou Azure Automation Account.
- We’ll use an ARM template to deploy the domain controller.
- This ARM template will also register the VM with the Azure Automation Account and link it with a given DSC configuration.
- The configuration will be applied and the updates will be reported back to the Azure Automation Account.
(EDIT 30/7/17 : Added network pre-req)
Continue reading “Azure : Deploying a domain controller via DSC pull”
In my last post I talked about the possibility to manage “Azure Resource Manager Policies” via the portal. Where the policy is a good location to view the policies, this is not the area you want to be managing your policies! In today’s post, we’ll look how we can automate these things. This to ensure that all policies are effective towards their scope and remain that way. Once your subscriptions grows, you can have way too many resources & resource groups at your hands. Setting up things manually is not the way to go…
Microsoft Azure Enterprise Scaffold
How to do governance in Azure is a very common questions. So if you have found yourself asking questions in regards to that topic, do not feel strange! One of the prime resources I can recommend in this area is the “Microsoft Azure Enterprise Scaffold” ;
The scaffold is based on practices we have gathered from many engagements with clients of various sizes. Those clients range from small organizations developing solutions in the cloud to Fortune 500 enterprises and independent software vendors who are migrating and developing solutions in the cloud. The enterprise scaffold is “purpose-built” to be flexible to support both traditional IT workloads and agile workloads; such as, developers creating software-as-a-service (SaaS) applications based on Azure capabilities.
Continue reading “Azure Governance – Policy Automation”
In the past I’ve noticed a lot of people are afraid of “Azure Resource Manager Templates“. I can imagine that a bulk of JSON code isn’t always that user friendly… So today we’ll take a look at another IaC (Infrastructure-as-Code) approach you might like. We’re going to do a small demo where we’ll be using “Terraform” to deploy a network on Azure. So how to get started?
- We’ll be creating a kind of service user in Azure which Terraform will use to log in.
- We’ll be authoring a small configuration file that will serve as the input for our network
- We’ll be applying that configuration file.
Seem simple enough? Let’s get started!
Continue reading “An alternative way to landscaping in Azure… Terraform!”
There are various articles/blogs/etc that compare logicapps vs flow vs functions vs azure automation, etc… Though there was one use case where I often struggled what to use ;
What to use when I want to retrieve a file from X on a Y timed interval?
Azure Functions? Great abstraction, though the output files have random names. Sometimes / Often I want to be able to control that.
Flow? Doesn’t allow the customization I was looking for. More to integrate existing / popular services.
Azure Automation? Very good and gets the job done. The only downside, you need to code a lot of logic yourself.
Azure Logic Apps? Shows potential, but doesn’t let you include custom functions. Or does it…?!?
You can link Azure Functions to Logic Apps and create some the flow I was looking for.
So what do I want to do?
- On a daily basis
- Retrieve content from an authenticated API
- Save the content to a Blob storage
And afterwards I’ll use other services to process that data. 🙂
What do I want to achieve? On a daily basis I want to retrieve data from a service provider that serves sports data. And if you are looking for such a thing, check out MySportsFeed! So back to our proof-of-concept; how will this look in Logic Apps?
Let’s dissect this flow…
Continue reading “Azure : Mixing LogicApps & Functions as a periodic data retriever”