Azure Subscriptions : How to buy & migrate them?

Introduction

When looking towards consuming Azure, this first point to start is the “tenant”. This is basically what one would see as their Azure Active Directory, or for some “Office 365”. This is linked to a “Subscription”. The subscription is linked to certain contract type, which influences the billing model. Choosing a certain contact type will (strangely enough) have an impact for you. So today we’ll cover the various options with their (dis)advantages.

 

Contract Overview

Basically, we can distinguish the following contract types ;

  • Online
  • Enterprise Agreement
  • Cloud Solution Provider

In reality, there are a few more, though most Azure offers can be consolidated into the term “Online” I used earlier on. The above are the three most commonly used scenario’s, therefore I will limit the scope of the day to these.

Continue reading “Azure Subscriptions : How to buy & migrate them?”

Advertisements

Running the Powershell AzureRM module in a Linux Docker container

Introduction

Given my affinity towards containers & azure, it will not come as a surprise when I say I published a small container from which you can launch AzureRM commands!

 

Repositories

  • Docker Hub (build) : https://hub.docker.com/r/kvaes/docker-powershell-azure/
  • GitHub (source) : https://github.com/kvaes/docker-powershell-azure

 

Getting Started

First of all, we’ll launch the container ;

docker run -ti kvaes/docker-powershell-azure

2016-09-23-10_09_10-rootdocker02_

Next up you do the device login ;

Login-AzureRmAccount

2016-09-23-10_08_33-rootdocker02_

And check out which commands are available…

get-command *azure*”

2016-09-23-10_08_20-rootdocker02_
As you notice, the current preview release is quite limited in available commands. Expect more to be added over time off course!

 

TL;DR

  • Powershell on Linux works
  • The AzureRM module is in preview, and limited in commands
  • It all works inside a container too! 😀

Enforcing your DSC config on Linux

Introduction

In the previous post we talked about configuring a Linux host with DSC via Azure Automation. When using the default settings, as we did in that post, a node configuration will be set to “apply & monitor”. Today we’ll take a look at how you can force compliancy with a certain config.

 

Register.py

When we take a look at the Register.py, we notice that there is an option to change the “ConfigurationMode”.

root@docker02:/opt/microsoft/dsc# /opt/microsoft/dsc/Scripts/Register.py --help
Usage: Register.py [OPTIONS]
OPTIONS (case insensitive):
--RegistrationKey KEY
--ServerURL URL
--ConfigurationName NAME
--RefreshFrequencyMins NUM default=30
--ConfigurationModeFrequencyMins NUM default=15
--ConfigurationMode (ApplyAndMonitor,ApplyAndAutoCorrect,ApplyOnly) default=ApplyAndMonitor
--RefreshMode (Pull|Push) default=Pull
--Help

 

The default

By default it is set to “ApplyAndMonitor”… So when I would manually mess with the system, by removing a required package. Then that node would become “Non Compliant”.

2016-09-20-20_06_47-9_20_2016-4_30-pm-microsoft-azure

So our reporting will indicate that something is odd. But there will be no remediation.

 

Enforce!

By using the “ApplyAndAutoCorrect” option, we can ensure that DSC will take action when a system is non-compliant. To set this mode, use the following command ;

root@docker02:~# /opt/microsoft/dsc/Scripts/Register.py --RegistrationKey my-secret-key --ServerURL https://we-agentservice-prod-1.azure-automation.net/accounts/accountid --ConfigurationMode ApplyAndAutoCorrect

 

“The Test”

Let’s take a look what the node will do when we remove one of the packages that has been included in the node configuration. To speed up my process, I reduced the refresh frequencyso I don’t have to wait endlessly… 😉

–RefreshFrequencyMins 5
–ConfigurationModeFrequencyMins 5

Anyhow, all looks good!

2016-09-20-20_19_59-9_20_2016-8_16-pm-microsoft-azure

So now let’s screw up this node…

root@docker02:/opt/microsoft/dsc# date && htop --help
Die Sep 20 20:16:38 CEST 2016
htop 2.0.1 - (C) 2004-2016 Hisham Muhammad
...
root@docker02:/opt/microsoft/dsc# date && apt-get remove htop -y
Die Sep 20 20:17:01 CEST 2016
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
htop
...

And the testing took a bit, longer as I noticed that the ConfigurationModeFrequencyMins option did not get set…

root@docker02:/opt/microsoft/dsc# Scripts/GetDscLocalConfigurationManager.py
instance of GetMetaConfiguration
{
ReturnValue=0
MetaConfiguration= instance of MSFT_DSCMetaConfiguration
{
ConfigurationModeFrequencyMins=30
RebootNodeIfNeeded=false
ConfigurationMode=ApplyAndAutoCorrect
Credential=NULL
RefreshMode=Pull
CertificateID=NULL
ConfigurationID=NULL
DownloadManagerName=NULL
DownloadManagerCustomData=NULL
RefreshFrequencyMins=1
AllowModuleOverwrite=false
LocalConfigurationManagerState=NULL
ConfigurationDownloadManagers=
{

 

… *waiting* …

Wait for it… and it’s back!

root@docker02:/opt/microsoft/dsc# date && htop --help
Die Sep 20 20:45:30 CEST 2016
htop 2.0.1 - (C) 2004-2016 Hisham Muhammad
Released under the GNU GPL.
...

2016-09-20-20_46_27-9_20_2016-8_45-pm-microsoft-azure

 

TL;DR

  • By default a non-compliant node will be reported, though no remediation will be done.
  • It is possible to configure the node to run in a mode where compliancy is enforced.

Managing Linux hosts with Desired State Configuration via Azure Automation

Introduction

For this post I’ll be assuming you know the basics of Desired State Configuration (or DSC in short). The objective of today is to test what Azure Automation can bring to the table in terms of managing Linux hosts. We all know about Puppet, Chef, Ansible, … but is Azure Automation a viable alternative? 

cmts1

 

First things first… Azure Automation Account

When getting started with DSC on linux, check out this documentation page as a reference. First up, we’ll create an Azure Automation account.

2016-09-15-14_05_03-inbox-karim-vaesxylos-com-outlook

Copy one of the keys and the URL, as we’ll need it to manually register our “OnPremise” host.

Continue reading “Managing Linux hosts with Desired State Configuration via Azure Automation”

Deploying OMS for Docker via Rancher

Introduction
Today we’ll be deploying Microsoft Operations Management Suite (OMS) for Docker via Rancher… Sound cool? It is! Basically we’re going to do the following guide and add Rancher to the twist.

For those unfamiliar with the Microsoft offering and more knowledgeable  in the OSS community. Imaging OMS as being the Microsoft counterpart of a typical ELK stack. The advantage is that it’s managed and that there are already a lot of integrations possible.

Continue reading “Deploying OMS for Docker via Rancher”

Azure : Billing Automation / Integration via the REST

Introduction
If you are an internal service provider needing to do chargebacks, or get an insight into your spending. Or if you are a cloud service provider in need to bill your customers for their Azure usage… You’ll find your self in need to get the raw usage data of your subscription(s). So today we’ll delve into getting your usage data from Azure via the REST api.

kvaes-azure-billing-consumption-usage-pricing-data-information

 

Environment Setup
For today’s post, we’ll be using “postman“. A very nice tool suggested by a co-worker of mine (Robin) and it’s really user-friendly to work with! What does the tool do? Basically it’ll let you craft REST calls without the need for custom scripts / coding effort. Why do we need it? Because we’re going to need to do authentication with each call, and let’s say… It isn’t that straightforward if you aren’t accustomed with it (like me at this time). 🙂

In order to set up your environment, I would suggest that you go through the following guide. So basically setup your environment …
2016-09-01 13_14_56-Postman
and your header preset ; Continue reading “Azure : Billing Automation / Integration via the REST”