Monat: Mai 2019

Azure Stack IaaS – part seven

If you do it often, automate it

In the virtualization days, before cloud and self-service, it took a while to get all the approvals, credentials, virtual LANs (VLANs), logical unit numbers (LUNs), etc. It took so long, that the actual creation part was easy. When cloud came along with self-service, not only was it easier to create a virtual machine (VM) without relying on others, but it changed our thinking about whether VMs were precious or disposable. At the same time developers were moving to a world of continuous delivery to serve their customers who expect apps with a constant stream of new features. This is the reason all real clouds provide automation APIs to quickly create VMs and other resources, including the infrastructure they rely on. This is often called “Infrastructure as code.” Azure’s API is governed by the Azure Resource Manager (ARM). When you set up Azure Stack, you get your own private instance of ARM.

In this blog post I will cover the automation options in your Cloud IaaS toolkit.

Azure portal

The best place to learn this is from first completing a VM deployment through the portal. Azure Stack provides the same portal as Azure. When you get to the last confirmation page, click the Download Template link. This will show you the template that will be used to deploy the VM you just specified on the previous screens.

As you look through the template – which is in JSON format – you can see how the virtual machine, network, and storage is defined. You’ll see an OS profile and hardware profile for your VM. Using this template, you could deploy this same VM over and over. This is perfect if you’re helping your developers with Continuous Integration and Delivery (CI/CD).

One thing about an ARM template is it is not a procedural script like you might get with standard automation tools. This template creates the resources as a single deployment transaction. ARM will either get to the goal state or the deployment will fail. If it fails, you have a chance to fix failure condition and move forward or delete the deployment and start over. This way you don’t get something other than what you specify.

Once you save your template, you can redeploy it in the portal, using the Template deployment item in the marketplace:

Learn more:
Azure Resource Manager overview
Quickstart: Create templates using the Azure Portal
Deploy resources in the portal using a custom template

Visual Studio and Visual Studio Code

Visual Studio can be scary for an infrastructure person, but if you can master some simple things, you can really help your team down the road of automation. The biggest thing that Visual Studio provides is the real-time feedback that you’re authoring the ARM JSON template correctly in terms of syntax. You don’t get this in Notepad. Get started by creating a new Azure Resource Group project:

A great way to start authoring a template is to use Quickstart templates. Azure Stack has a number of Quickstart templates you can use. When you start your new project in Select Azure Template, pick Azure Stack Quickstart from the drop-down list.

Visual Studio not only helps you author the template, it allows you to deploy the template directly to Azure Stack. When you sign into Visual Studio, all of your subscriptions in both Azure and Azure Stack show up as deployment targets. Since I use a number of Azure Stack environments, I have lots of deployment options:

Another way to create these templates is in Visual Studio Code. The ARM template is a JSON file, so you need a good lightweight authoring tool to work on the JSON file. Visual Studio Code (VS Code) is a great option.

After installing VS Code, you need to add the Azure Resource Manager Tools extension. This extension adds many features that simplify template authoring that help you manage variables, parameters, and resource blocks with features like including formatting and color coding. Check it out in the image below:

Learn more:
Install Visual Studio and Connect to Azure Stack
Deploy templates to Azure Stack using Visual Studio
Create a template in Visual Studio
Create a template in Visual Studio Code

PowerShell and Azure command-line interface

The Portal and Visual Studio are both deployment options for your template. PowerShell and the Azure command-line interface (CLI) are two other options. Since Azure Stack is your own private instance of the Azure Resource Manager, you need to connect to your unique instance.

To connect to Azure Stack with PowerShell, use the Add-AzureRMEnvironment cmdlet, specifying the ARM endpoint for your environment. Depending on how your Azure Stack environment has been set up, you will either authenticate using your Azure Active Directory credentials or your organization’s Azure Directory (referred to in the documentation as ADFS).

Azure CLI is Microsoft's cross-platform command-line experience for managing Azure resources. It works on Mac, Linux, and Windows. In Azure you can run the CLI in Cloud Shell. You can use Azure CLI to connect to Azure Stack and deploy IaaS templates. Just like PowerShell, you need to first connect to your Azure Stack’s unique ARM endpoint. For CLI you use the az cloud register command. To deploy your ARM template you use the az group deployment create command.

Please note: We have not implemented Cloud Shell on Azure Stack yet. Cloud Shell allows you to run the Azure CLI directly inside your browser. If you would like to see this, make sure you put in a vote on Azure Cloud Shell UserVoice.

Learn more:
Install PowerShell for Azure Stack
Connect to Azure Stack with PowerShell
Deploy in Azure Stack with PowerShell
Use Azure CLI on Azure Stack
Deploy Azure Resource Manager Templates with Azure CLI

The cloud is for automation

The more people use clouds like Azure and Azure Stack, the less they use the portal and the more they use automation. There is an automation option in Azure and Azure Stack for all your needs. Say goodbye to virtualization and say hello to Cloud IaaS with your automation toolkit.

In this blog series

We hope you come back to read future posts in this blog series. Here are some of our past and upcoming topics:

Azure Stack at its core is an Infrastructure-as-a-Service (IaaS) platform
Start with what you already have
Fundamentals of IaaS
Protect your stuff
Do it yourself
Pay for what you use
Build on the success of others
Journey to PaaS

Quelle: Azure

Deploy a FHIR sandbox in Azure

This blog post was authored by Michael Hansen, Senior Program Manager, Microsoft Azure.

In connection with HIMSS 2019, we announced the Azure API for FHIR, which provides our customers with an enterprise grade, managed FHIR® API in Azure. Since then, we have been busy improving the service with new configuration options and features. Some of the features we have been working on include authentication configuration and the SMART on FHIR Azure Active Directory Proxy, which enable the so-called SMART on FHIR EHR launch with the Azure API for FHIR.

We have developed a sandbox environment that illustrates how the service and the configuration options are used. In this blog post, we focus on how to deploy the sandbox in Azure. Later blog posts will dive into some of the technical details of the various configuration options.

The Azure API for FHIR team maintains a GitHub repository with sample applications. It is maintained by the product engineering team to ensure that it works with the latest features of the Azure API for FHIR. The repository contains a patient dashboard application, Azure Function that will load patient data generated with Synthea, and example templates for SMART on FHIR applications:

Deployment instructions

The repository contains fully automated PowerShell scripts that you can use to deploy the sandbox scenario. The deployment script will create Azure Active Directory application registrations and a test user. If you do not want to create these Azure Active Directory objects in the tenant associated with your Azure subscription, we recommend you create a separate Azure Active Directory tenant to use for data plane access control.

The deployment script is written for PowerShell and uses the AzureAd PowerShell module. If you don’t have access to PowerShell on your computer, you can use the Azure Cloud Shell. In the cloud shell, you can deploy the sandbox environment with:

# Clone source code repository
cd $HOME
git clone https://github.com/Microsoft/fhir-server-samples
cd fhir-server-samples/deploy/scripts

# Log in to Azure AD:
Connect-AzureAd -TenantDomain <mytenantdomain>.onmicrosoft.com

# Connect to Azure Subscription
Login-AzureRmAccount

# Selection subscription
Select-AzureRmSubscription -SubsciptionName “Name of your subscription”

# Deploy Sandbox
.Create-FhirServerSamplesEnvironment.ps1 -EnvironmentName <NameOfEnvironment> -EnvironmentLocation westus2 -AdminPassword $(ConvertTo-SecureString -AsPlainText -Force "MySuperSecretPassword")

It will take around 5 minutes to deploy the environment. The deployment script will create a resource group with the same name as the environment. In there, you will find all the resources associated with the sandbox.

Loading synthetic data

The environment resource group will contain a storage account with a container named “FhirImport.” If you upload Synthea patient bundles to this storage account, they will be ingested.

Using the patient dashboard

There are two versions of the patient dashboard, they can be located at:

https://<NameOfEnvironment>dash.azurewebsites.net: This is an ASP.NET patient dashboard. The GitHub repository contains the source code for this patient dashboard.
https://<NameOfEnvironment>js.azurewebsites.net: This is a single page JavaScript application. The source code is also in the GitHub repository.

When you navigate to either of those URLs, you will be prompted to log in. The administrator user is created by the deployment script and will have the username <NameOfEnvironment>-admin@<mytenantdomain>.onmicrosoft.com and the password is whatever you chose it to be during deployment. If you have uploaded some patients using the Synthea uploader, you should be able to display a list of patients. This shows the view in the JavaScript dashboard.

You can click details on a specific patient to get more information:

You can also use the links for the SMART on FHIR applications to get the growth chart application this patient:

The sandbox provides other useful tools. As an example, the “About me” link will provide you with details about the FHIR endpoint including a token that can be used to access the FIR API using tools like Postman.

Deleting the sandbox

When you are done exploring the Azure API for FHIR and the FHIR sandbox, it is easily deleted with:

.Delete-FhirServerSamplesEnvironment.ps1 -EnvironmentName <NameOfEnvironment>

FHIR® is the registered trademark of HL7 and is used with the permission of HL7
Quelle: Azure