by Scott Muniz | Sep 22, 2020 | Azure, Technology, Uncategorized
This article is contributed. See the original author and article here.
There is a new kid on the block, his name is “Azure Arc” and he wants people to play with it. This is why we create the Azure Arc Jumpstart project and GitHub Repository.
The goal of the repo is for you to have a working Azure Arc demo environment spun up in no-time so you can focus on playing, demoing, upskilling yourself and your team and see the core values of Azure Arc.
Disclaimer: The intention of this repo is to focus on the core Azure Arc capabilities, deployment scenarios, use-cases and ease of use. It does not focus on Azure best-practices or the other tech and OSS projects being leveraged in the guides and code.
The Why – Design Principles
The repository was created with 3 main design principles in mind:
- Provide a “zero to hero” Azure Arc scenarios for multiple environments, cloud platforms and deployment types using as much automation as possible.
- Create a ”Supermarket” experience by being able to take “off the shelf” scenarios and implement (eat) them.
- Meeting Azure Arc customers and users where they are.
The How – Using & Implementing
Our goal with the repository is for you to be self-sufficient and for us to provide you with the right set of instructions and automation, no matter which platform you want to use.
The structure of the repo is aligned with the Azure Arc pillars; Servers, Kubernetes and Data Services and will have future Arc-related content as well. As you may have already noticed, the scenarios in the repo are split into two categories – Bootstrapping and Day-2.
So first, you will bootstrap and environment and then, you can move on to the Day-2 stuff. For example, spin-up an AWS EC2 instance, onboard it as an Azure Arc enabled Server and then apply tags, Azure Policies followed by hooking it to Azure Security Center or Azure Sentinel.
Another example could be provisioning a Google Kubernetes Engine (GKE) cluster, onboard it to Azure Arc enabled Kubernetes and then start creating GitOps Configurations and connect it to Azure Monitor for Containers.
So, as you can see, there is something for everyone with tons more scenarios in the repo. You even don’t have to have AWS or GCP account, we have included guides on how to deploy environments using tools like Hashicorp Vagrant or using a VMware vSphere environment you can leverage.
Get Started Today!
It’s very easy to get going with the repo and the scenarios. As you will notice, we also incl. Very detailed prerequisites section in each guide, again, so you will have everything you need to become Azure Arc Master Ninja.
Hop on to https://aka.ms/AzureArcJumpstart and start your Arc-journey 
!
In addition, check out these additional great Azure Arc blog posts!
by Scott Muniz | Sep 22, 2020 | Azure, Technology, Uncategorized
This article is contributed. See the original author and article here.
Azure Monitor for containers has been generally available for a while now, providing comprehensive viability to Azure Kubernetes Service (AKS) clusters and the applications deployed in it. Did you know this can be applied on Azure Arc enabled Kubernetes clusters as well?!
Monitor this, monitor that
As Kubernetes becomes more and more the de-facto container orchestration platform out there, the need for an organization’s operations maturity around it is facing a lot of challenges.
Now, it’s even if the current challenges are not enough, Kubernetes deployments sprawling across multiple cloud providers and on-premises is adding another dimension to these challenges.
Specifically, when you have different ways and interfaces to monitor those clusters and the applications deployed on top of it.
1st party experience
If you are an AKS user, you might already be leveraging the Azure Monitor for containers integrated experience and if not, well, you should.
With this integration, you are getting all the Kubernetes-related performance metrics, telemetry, and metadata you need. Not just on the cluster-level, but also the relevant information on the applications deployed on the cluster as you can see in the below figure.
Bring “outsiders” to the party
Having AKS integrate with Azure Monitor for containers, a 1st party Azure product is a given and mandatory but now that we have Azure Arc enabled Kubernetes clusters projected in Azure, wouldn’t make sense to have the same integration for these clusters as well?! Of course so!
By onboarding the Kubernetes clusters outside of Azure using Arc and deploy the Operations Management Suite Agent in the cluster, we are able to connect the clusters to an Azure Log Analytics workspace, same as we are doing for AKS and as a result, have the same monitoring experience for outside Kubernetes clusters.
As you can from the below figure, we are getting the same performance metrics, both on the cluster and the application-level, metadata and all the telemetry one might need but now, it is a Google Kubernetes Engine (GKE) cluster we are looking at – that’s dope!
Get Started Today
In this post, we briefly touched on Azure Monitor for containers integration with Azure Arc enabled Kubernetes clusters and showed how you can have a unified monitoring experience for both AKS clusters and the Kubernetes clusters deployed outside of Azure.
To get started, visit the Azure Arc Jumpstart GitHub repository, where you can find more than 30 Azure Arc deployment guides and automation, including how to onboard your Azure Arc enabled Kubernetes clusters and start using Azure Monitor for containers with it. I addition, visit the official Azure Arc documentation page where you can find more information.
Also, check out these additional great Azure Arc blog posts!
by Scott Muniz | Sep 22, 2020 | Azure, Technology, Uncategorized
This article is contributed. See the original author and article here.
Unified operations for hybrid IT
Azure Arc enabled servers is a powerful new technology that will help Microsoft customers and partners build seamless solutions for managing hybrid IT resources from a single pane of glass. Servers running outside of Azure such as AWS EC2 instances, on-premises VMware or physical machines, or devices in edge scenarios can now be projected into Azure as first-class resources. These resources can then be managed using Azure Policy, resource tags, and other Azure capabilities like update management, change tracking, monitoring, and more as if they were native Azure virtual machines. Azure Arc provides a unified governance and management strategy using Azure tools for our hybrid IT and multi-cloud environments.
Azure Arc Connected Machine agent
Azure Arc enabled servers interact with Azure via the Connected Machine agent. This agent interfaces with an Azure Resource Manager (ARM) resource provider which gives us the ability to perform management operations on the server via Azure Portal, Azure CLI, or Azure SDK. This agent contains logical components that control how an Azure Arc enabled server interfaces with various Azure services. The Hybrid Instance Metadata Service manages communication with Azure AD, while the Extension Manager service and Guest Configuration service allow the server to easily use Azure Virtual Machine extensions and to be governed using Azure Policy. The agent is configured with an Azure service principal and other parameters to manage scope and resource placement it can be deployed manually or as part of scripted automation.
Azure Arc enabled servers in action
Let’s take a closer look now at the above concepts in action. Imagine that we have a mature hybrid IT organization with server assets spread out over various public clouds and on-premises datacenters. We have standardized on using Azure Policy and other Azure governance tools (e.g., Log Analytics, Update Management, Backup, tagging). Because of the various hosting platforms for our virtual machines, we need an easy way to apply a common policy strategy across them all. To accomplish this, we will use Azure Arc enabled servers.
One of my requirements is that all virtual machines must send logs to Log Analytics to manage updates, change tracking, inventory, and monitoring. The onboarding of the Log Analytics agent must be done automatically via policy. To accomplish this, I have set up a Log Analytics workspace and enabled Update Management and Change Tracking, and I can deploy a built-in Azure Policy that checks for the presence of the Log Analytics agent and automatically deploys it if it is not found. Below you can see I have deployed this built-in policy and that will accomplish this.
If you look closely at the JSON in the screenshot below you can see that this policy is scoped to the Microsoft.HybridCompute/machines resource type. Once this policy is in place, new Azure Arc enabled servers that I onboard by deploying the Connected Machine agent should automatically have the Log Analytics agent deployed by the policy.
Onboarding a server
Our next step is to onboard some servers to Azure by deploying the Connected Machine agent. We can do this using our own Azure credentials, or we can use a service principal for automated scenarios. We can scope a service principal to the “Azure Connected Machine Onboarding” role to restrict actions using the service principal to onboarding Azure Arc enabled servers only.
Below, you can see I have deployed a virtual machine to AWS. This VM is running Ubuntu 18.04.
We can get the Connected Machine agent provisioned on this server by running some commands. First we will download the agent install script using wget and then install the agent by running the downloaded script.
#!/bin/bash
# Download the installation package
wget https://aka.ms/azcmagent -O ~/install_linux_azcmagent.sh
# Install the hybrid agent
sudo bash ~/install_linux_azcmagent.sh
The script will run and generate some output. When complete you should see something similar to the below screenshot.
Next, I will run azcmagent connect to onboard the server. We can see in the example below that this command requires us to pass our service principal and secret, Azure tenant and subscription id, which I am injecting as environment variables. I also pass an Azure region and resource group.
sudo azcmagent connect
--service-principal-id $TF_VAR_client_id
--service-principal-secret $TF_VAR_client_secret
--tenant-id $TF_VAR_tenant_id
--subscription-id $TF_VAR_subscription_id
--location "westus2"
--resource-group "Arc-AWS-Demo"
Now that the server has been onboarded I can open the Azure Portal and it as a resource in the resource group I specified when running azcmagent connect.
If I look at the Extensions blade, I can also see that the Log Analytics agent (MMAExtension) is provisioned. This happened automatically as a result of the policy we configured.
With the MMAExtension enabled and my server sending logs to my workspace, we can take advantage of many governance tools such as managing updates with Update Management, reviewing security posture with Azure Security Center, and proactively managing security and other incidents with Azure Sentinel.
Below we can see our server is missing some updates. With the Update Management solution we can apply the update automatically or generate an alert that creates an incident in Azure Sentinel if this is a critical security update.
We can also use Kusto to query logs on the server for custom reports or other monitoring scenarios.
By using this workflow of deploying policies that are scoped to Azure Arc enabled servers, I can enable a large variety of governance scenarios. Some other examples of using Azure Arc enabled servers with Azure Policy include:
- Automatically deploying Azure Security Center at scale on any server
- Hardening servers for compliance scenarios using Guest Configuration
- Applying inventory management tags for better organization of my diverse hybrid resources.
- Enable multi-tenant or multi-customer service provider solutions by using Azure Lighthouse together with Azure Arc
Next steps
I hope this has been a helpful primer on Azure Arc enabled servers. For additional Azure Arc content visit the Azure Arc Jumpstart GitHub repository, where you can find more than 30 Azure Arc deployment guides and automation and visit the official Azure Arc documentation page. Additionally, my colleagues have written some other articles on Azure Arc that you can read:
Enjoy the rest of Ignite 2020!
by Scott Muniz | Sep 22, 2020 | Azure, Technology, Uncategorized
This article is contributed. See the original author and article here.
We are excited to announce several updates to Azure Migrate’s assessment and migration capabilities. Cloud migration can be a complex project, which is why Microsoft is committed to advancing its migration services to support all your migration needs through expanded scenarios and capabilities. Azure Migrate is Microsoft’s central service for datacenter migration. It features a central hub of migration tools to discover, assess, and migrate your datacenter to the cloud. The service is free to use with your Azure subscription, accessible through the Azure portal.
First, begin your migration project by performing a datacenter discovery to plan the migration and mitigate risks. Azure Migrate helps you discover servers, inventory the applications running on them, and identify dependencies between servers. The discovery process helps you identify and group the workloads to be migrated and plan your migration waves. Server discovery is completely agentless and can discover servers running on any cloud including servers that are virtualized on VMware or Hyper-V, physical machines, or virtual machines running in other public clouds. For VMware virtual machines, Azure Migrate can perform agentless application discovery and dependency mapping at scale, with a single Azure Migrate appliance now capable of analyzing dependencies for up to 1000 virtual machines in one project. This allows you to visualize connections and process-level details between machines, which helps with grouping them for assessment and migration. You can learn more about agentless dependency mapping here.
With a better understanding of your server estate and dependencies, you can generate an assessment report to understand Azure readiness, cloud cost estimations, and right-sizing recommendations. Read more about best practices for assessments in our prioritizing assessments blog.
With the assessment complete, you’ll be ready to migrate your workloads safely and efficiently. The Azure Migrate Server Migration tool now lets you to migrate UEFI machines to Azure Gen 2 virtual machines. With no boot type conversion needed, you can migrate UEFI machines as is and take advantage of additional Gen 2 virtual machine features. You can now also select a specific Availability Zone to place migrated machines in when migrating to an Azure Region that supports Availability Zones to achieve increased resiliency and security.
Looking for more than just a lift-and-shift server migration for your datacenter? Azure Migrate now supports migrating .NET applications to Azure Kubernetes Service (AKS). The brand-new feature is available in preview, and allows you to containerize ASP.NET applications and run them on Windows containers in AKS.
by Scott Muniz | Sep 22, 2020 | Azure, Technology, Uncategorized
This article is contributed. See the original author and article here.
The cloud has simplified and reduced the operational expense (OpEx) and management burden in numerous areas of IT. Many systems that previously ran on-premises and were complex to maintain are now simple ‘point & click’ services in the cloud.
Likewise, running virtual machines (VMs) in Microsoft Azure opens the door to a wealth of convenient services that simplify and automate day-to-day operational requirements in areas such as security, anti-malware, compliance, disaster recovery, etc. We also provide best practices guidance outlining the services that we recommend you onboard your VMs to including each service’s respective configuration. You can find this actionable guidance in the Microsoft Cloud Adoption Framework for Azure.
A new service known as Azure Automanage reduces the OpEx burden for VMs further by automating the guidance mentioned above. Through its virtual machine best practices capability, select services are discovered, onboarded, and configured across the entire lifecycle of both dev/test and production VMs. You can add VMs individually or do so at scale safe in the knowledge that if your VMs deviate from best practices, Azure Automanage will detect and automatically correct it.
Specifically, the VM best practices capability of Azure Automanage does the following five things:
- Intelligently onboards to select best practices Azure services
- Automatically configures each service per Azure best practices
- Configures guest operating system per Microsoft baseline configuration
- Automatically monitors for drift and corrects for it when detected
- Simple experience: Point, click, set, forget -> done
The capabilities of Azure Automanage translate into the following customer benefits:
- Reduced cost by automating Windows Server management
- Improved workload uptime with optimized operations
- Implementation of security best practices
How does it work?
Configuration profiles
Azure Automanage uses configuration profiles to determine what Azure services will be enabled for that VM. At launch, there are two configuration profiles:
- Azure virtual machine best practices – Production
- Azure virtual machine best practices – Dev/Test
Each profile onboards a set of services that fit the workload type. For example, dev/test VMs will not be onboarded to Azure Backup since dev/test VMs are typically short-lived and of low or no direct business impact. Hence, paying for backup storage is unnecessary. On a production VM, however, Azure Backup is configured. For more details about configuration profiles and the services they automatically configure, see the detailed documentation here.
NOTE: While Azure Automanage is currently available only for Windows Server VMs, it will be extended to Linux VMs in the future.
You can assign a configuration profile to a VM using any of the methods:
Configuration profile preferences
Some of the services that the configuration profiles onboard VMs to support a variety of best practice configurations. For example, Azure Backup best practices might require a daily backup with a 6-month retention. However, a twice daily backup with a 3-month retention still conforms to best practices. In scenarios like these, configuration profile preferences provide a way to override the default best practices.
Like configuration profiles, preferences are Azure resources and are assigned to a VM the same way configuration profiles are.
Automanage account
An Automanage account is an Azure System Managed Service Identity (MSI) under which Automanage operations are performed on VMs. You must have at least one Automanage account before you can assign a configuration profile to a VM. When using the Azure portal, an Automanage account will be automatically created if one does not already exist; existing Automanage accounts will be used if permitted for the logged-on user.
Get started
You can assign a configuration profile to both new and existing VMs.
To begin using Azure Automanage VM best practices, visit the Azure portal and search for Automanage as shown below:
For new VMs, after the deployment is complete, you will see this recommended next step to enable Automanage.
For more information, please take a look at the full documentation here.
Recent Comments