1-888-317-7920 info@2ndwatch.com

Azure Cloud Shell is a Hidden Gem

The simple way to describe Azure Cloud Shell is an on-demand Linux VM with a managed toolset that is accessible from virtually anywhere. You can access it via the Azure Portal, shell.azure.com, the Azure Mobile App, and Visual Studio Code. Pricing is simple. you only need to pay for storage that is used to persist your files between Cloud Shell sessions. Finally, Cloud Shell offers two shell experiences – Bash and PowerShell – however you can access PowerShell from Bash and Bash from PowerShell, so just choose whatever you are most comfortable with. 

Cloud Shell contains the following tools: 

  • Linux Tools– bash, zsh, sh, tmux, dig
  • Azure Tools– Azure CLI, AzCopy, Service Fabric CLI
  • Programming Languages– .NET Core, Go, Java, Node.js, PowerShell, Python
  • Editors– vim, nano, emacs, code
  • Source Control– git
  • Build Tools– make, maven, npm, pip
  • Containers– Docker CLI / Docker Machine, Kubectl, Helm, DC/OS CLI
  • Databases– MySQL client, PostgreSQL client, sqlcmd utility, mssql-scripter
  • Other– iPython Client, Cloud Foundry CLI, Terraform, Ansible, Chef InSpec

You are probably thinking to yourself, that’s great, but what can I use it for? Good question… 

Got a bunch of Azure management scripts that you have developed and need to be able to run? Cloud Shell is a great way to run and manage those scripts. You can leverage git for version control and run PowerShell, Bash, or Python scripts whenever and wherever you are. For example, you are grabbing some lunch and the boss sends you an email asking how many VMs are currently running in your environment and wants the answer right now. Being that this isn’t the first time that the boss has asked this question, you have already created a script that will send a report with how many VMs are currently running. So, you load the Azure Mobile App on your phone, connect to Cloud Shell to run the script and get back to your lunch without having to run back to the office. 

Are you an Azure CLI master? Cloud Shell has you covered! Cloud Shell always has the latest version of the Azure CLI without you ever having to maintain a VM or update your local installation. 

Need to deploy an agent to a bunch of VMs but don’t want to manage a Configuration Management tool? Once again, Cloud Shell has you covered. Use the built-in Ansible to run a playbook that deploys the agent you need installed. 

Do you run a multi-cloud shop? Need to deploy things to both Azure and AWS? Then you are in luck! With Cloud Shell you can use Terraform to deploy both Azure and AWS resources. Another multi-cloud idea would be to install the AWSPowerShell.NetCore PowerShell module to be able to perform day-to-day tasks and automation of AWS. 

There are some limitations of Cloud Shell, such as your Cloud Shell session being temporary. It will be recycled after your session is inactive after 20 minutes.  

The pricing for Azure Cloud Shell is great. Like I mentioned before, you only pay for storage. Storage is used to persist data between instances of Cloud Shell. If you install a PowerShell module or use git to clone a repo, the next time you fire up Cloud Shell, those files are still there. 

Azure Cloud Shell can help with a lot of different use cases and requires very little management. For more information on Azure Cloud Shell visit https://docs.microsoft.com/en-us/azure/cloud-shell/overview or for help getting started with Azure, contact us. 

-Russell Slater, Senior Cloud Consultant

Facebooktwittergoogle_pluslinkedinmailrss

Managing Azure Cloud Governance with Resource Policies

I love an all you can eat buffet. One can get a ton of value from a lot to choose from, and you can eat as much as you want or not, for a fixed price.

In the same regards, I love the freedom and vast array of technologies that the cloud allows you. A technological all you can eat buffet, if you will. However, there is no fixed price when it comes to the cloud. You pay for every resource! And as you can imagine, it can become quite costly if you are not mindful.

So, how do organizations govern and ensure that their cloud spend is managed efficiently? Well, in Microsoft’s Azure cloud you can mitigate this issue using Azure resource policies.

Azure resource policies allow you to define what, where or how resources are provisioned, thus allowing an organization to set restrictions and enable some granular control over their cloud spend.

Azure resource policies allow an organization to control things like:

  • Where resources are deployed – Azure has more than 20 regions all over the world. Resource policies can dictate what regions their deployments should remain within.
  • Virtual Machine SKUs – Resource policies can define only the VM sizes that the organization allows.
  • Azure resources – Resource policies can define the specific resources that are within an organization’s supportable technologies and restrict others that are outside the standards. For instance, your organization supports SQL and Oracle databases but not Cosmos or MySQL, resource policies can enforce these standards.
  • OS types – Resource policies can define which OS flavors and versions are deployable in an organization’s environment. No longer support Windows Server 2008, or want to limit the Linux distros to a small handful? Resource policies can assist.

Azure resource policies are applied at the resource group or the subscription level. This allows granular control of the policy assignments. For instance, in a non-prod subscription you may want to allow non-standard and non-supported resources to allow the development teams the ability to test and vet new technologies, without hampering innovation. But in a production environment standards and supportability are of the utmost importance, and deployments should be highly controlled. Policies can also be excluded from a scope. For instance, an application that requires a non-standard resource can be excluded at the resource level from the subscription policy to allow the exception.

A number of pre-defined Azure resource policies are available for your use, including:

  • Allowed locations – Used to enforce geo-location requirements by restricting which regions resources can be deployed in.
  • Allowed virtual machine SKUs – Restricts the virtual machines sizes/ SKUs that can be deployed to a predefined set of SKUs. Useful for controlling costs of virtual machine resources.
  • Enforce tag and its value – Requires resources to be tagged. This is useful for tracking resource costs for purposes of department chargebacks.
  • Not allowed resource types – Identifies resource types that cannot be deployed. For example, you may want to prevent a costly HDInsight cluster deployment if you know your group would never need it.

Azure also allows custom resource policies when you need some restriction not defined in a custom policy. A policy definition is described using JSON and includes a policy rule.

This JSON example denies a storage account from being created without blob encryption being enabled:

{
 
"if": {
 
"allOf": [
 
{
 
"field": "type",
 
"equals": "Microsoft.Storage/ storageAccounts"
 
},
 
{
 
"field": "Microsoft.Storage/ storageAccounts/ enableBlobEncryption",
 
"equals": "false"
 
}
 
]
 
},
 
"then": { "effect": "deny"
 
}
 
}

The use of Azure Resource Policies can go a long way in assisting you to ensure that your organization’s Azure deployments meet your governance and compliance goals. For more information on Azure Resource Policies visit https://docs.microsoft.com/en-us/azure/azure-policy/azure-policy-introduction.

For help in getting started with Azure resource policies, contact us.

-David Muxo, Sr Cloud Consultant

Facebooktwittergoogle_pluslinkedinmailrss