Pulumi Blog: Top 5 Things for Azure Developers Series

Top 5 Things an Azure Developer Needs to Know: DevOps

Sophia Parafina — Thu, 26 Aug 2021 00:00:00 +0000

What comes to mind when you hear DevOps? Frequently, DevOps is described as a cultural practice that enables an organization to deliver high-quality applications quickly. The DevOps model emphasizes the “breaking down of silos” and combining development and operations into a single team. Developing, deploying, and maintaining an application is the responsibility of both developers and operators across the application lifecycle.

DevOps processes rely on tooling to automate delivering and maintaining applications. This article demonstrates how to implement Azure Pipelines to build and deploy applications.

Azure Pipelines

Azure Pipelines is a Continuous Integration/Continuous Delivery (CI/CD) system that builds and tests code. A key practice of DevOps is Continuous Integration (CI), which merges and tests code automatically. CI catches bugs with automated testing before software is released, which decreases the cost to fix. The Azure DevOps Build process produces artifacts that drive small and frequent deployments. Continuous Delivery (CD) tests and deploys the artifacts in test or production environments. The automated release process updates existing systems with patches, bug fixes, and new features.

CI/CD systems store environment-specific configurations for every artifact produced. They use this information to perform any changes to the environment when software is deployed. For example, these systems can refresh database connections or restart services on a deployment.

Azure Pipelines supports the following tools:

version control systems - Git and Team Foundation Version Control
languages - Python, Java, JavaScript, PHP, Ruby, C#, C++, and Go
application types - tasks to build .Net, Java, Node, Android, Xcode, and C++ applications
deployment targets - virtual machines, containers, on-premises and cloud platforms, or PaaS services
continuous testing - automating build-deploy-test workflows with the technologies and frameworks you choose
package formats - supports publishing NuGet, npm, or Maven packages.

Deploy code with Pipelines

Let’s go step-by-step to create a pipeline.

Step 1: Sign in to your Azure DevOps organization or create one if you don’t have one.

Step 2: Create a project.

Step 3: Create a pipeline.

Step 4: Connect and select your repository.

Step 5: Connect the pipeline to the repository on GitHub by approving the install.

Step 6: Examine the pipeline YAML and, if everything appears correct, select Save and run.

You can follow the Azure DevOps Pipelines tutorial, which covers creating software artifacts. However, because we are deploying infrastructure and an application, we will need to expand pipeline tasks with an extension.

The Pulumi task extension for Azure DevOps

The Pulumi task extension runs the Pulumi CLI in your CI/CD pipelines. The pipeline builds your application and deploys the infrastructure it runs on in the same pipeline. You can install the Pulumi task extension from the Visual Studio Marketplace into your Azure DevOps Organization.

The task has two requirements:

The pipeline must connect to your Azure Subscription through a service connection.
The build variable, pulumi.access.token is mapped to the environment variable PULUMI_ACCESS_TOKEN, which the CLI uses for non-interactive logins.

There are two ways to run the pipeline. You can use the console to configure the pipeline or add an azure-pipelines.yml file to your repository. Let’s look at an example YAML file.

# A minimal Azure Pipelines build configuration file for running
# Pulumi apps that use the dotnet runtime and the Azure Native
# Nuget package.

trigger:
 batch: true
 branches:
 include:
 - master
 paths:
 include:
 - "**/*"

pool:
 vmImage: "ubuntu-latest"

variables:
 solution: "**/*.sln"
 buildPlatform: "Any CPU"
 buildConfiguration: "Release"

jobs:
 - job: infrastructure
 steps:
 - task: NuGetToolInstaller@1

 - task: Pulumi@1
 inputs:
 # To use an Azure Service Connection, un-comment the following line.
 azureSubscription: "$(ServiceConnectName)"
 # Pulumi will automatically build/restore the dotnet project.
 # Unless you are using a pre-built binary.
 command: "preview"
 stack: "$(StackName)"
 cwd: "./"

Let’s focus on jobs. The first step is to find, download, and install NuGet, which is required to build this C# application. The second task uses the Pulumi task extension to run a Pulumi preview of the stack ($(StackName)) located at the root of the Pulumi project. The complete example is available on GitHub.

If we wanted to build and deploy the infrastructure, we could add another task. The azure-pipelines.yml file would be similar to this.

jobs:
 - job: infrastructure
 steps:
 - task: NuGetToolInstaller@1

 - task: Pulumi@1
 inputs:
 # To use an Azure Service Connection, un-comment the following line.
 azureSubscription: "$(ServiceConnectName)"
 # Pulumi will automatically build/restore the dotnet project.
 # Unless you are using a pre-built binary.
 command: "preview"
 stack: "$(StackName)"
 cwd: "./"
 - task: Pulumi@1
 inputs:
 # To use an Azure Service Connection, un-comment the following line.
 azureSubscription: "$(ServiceConnectName)"
 # Pulumi will automatically build/restore the dotnet project.
 # Unless you are using a pre-built binary.
 command: "up"
 stack: "$(StackName)"
 cwd: "./"

You can chain tasks to run the build process, including building and deploying applications in the same pipeline. The Pulumi Continuous Delivery User Guide provides an in-depth walkthrough for configuring an Azure pipeline.

Summary

As a developer on a DevOps team, you may not be the person to configure a pipeline. However, it’s a good cloud engineering practice to understand how your application is built and deployed. Although we focus on Azure, the Pulumi task extension works with many other CI/CD systems. Check out our User Guides for all the CI/CD systems Pulumi supports.

Top 5 Things an Azure Developer Needs to Know: Kubernetes Applications

Sophia Parafina — Mon, 16 Aug 2021 00:00:00 +0000

All modern software is cloud software, and it’s more than likely that it runs on Kubernetes. Developers are faced with the challenge of deploy applications composed of many microservices. And each microservice adds to the complexity of the deployment.

This article reviews the different methods for deploying applications on Azure Kubernetes Service (AKS).

A quick review on application deployment

If you’re not familiar with deploying applications on Kubernetes, these articles cover the basic and advance cases:

Setting up the AKS sandbox

We’ll set up an AKS sandbox composed of an AKS cluster and Azure Container Registry (ACR) for this article. Make sure you have the Azure CLI installed, and you’re logged into Azure, e.g., az login.

Create a container registry

We’ll create a resource group first, followed by the registry.

$ az group create --resource-group aks-group --location westus2
$ az acr create --resource-group aks-group --name pulumipusContainerRegistry --sku Basic

When the registry is created, the Azure CLI returns JSON with metadata about the registry. Under the id key, you’ll find the URL to the login server.

...
 "id": "/subscriptions/fceb55a3-db15-4f3a-bffa-81271e7b7676/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/azContainerRegistryPulumi",
 "identity": null,
 "location": "eastus",
 "loginServer": "pulumipuscontainerregistry.azurecr.io",
 "name": "azContainerRegistryPulumi",
...

At this point, you can push and pull container images from your registry. If you want to try out the registry and push an image, you’ll need Docker installed. This example pulls an image from Docker Hub and tags it with the URL to the Azure container registry. We then log into the registry and push the image. To verify the image, we use the Azure CLI to list the images in the registry.

$ docker pull hello-world
$ docker tag hello-world pulumipuscontainerregistry.azurecr.io/hello-world:v1
$ az acr login --name pulumipusContainerRegistry
$ docker push pulumipuscontainerregistry.azurecr.io/hello-world:v1
$ az acr repository list --name pulumipusContainerRegistry
[
 "hello-world"
]

Create an AKS cluster

The previous article this series demonstrated how to create an AKS cluster with the Azure portal and code to illustrate creating an AKS cluster. For this example, we’ll use the CLI. In the example below, the first line creates a basic cluster, and the second line retrieves the cluster credentials that let us connect to it.

$ az aks create --resource-group aks-group --name aks-cluster --node-count 3 --generate-ssh-keys -s Standard_B2ms --disable-rbac
$ az aks get-credentials -g aks-group -n aks-cluster

Deploy an NGINX container on AKS with Helm

Helm is an application package manager for Kubernetes. Follow the directions on helm.sh to install Helm. Helm can install packages from repositories such as ArtifactHUB, Bitnami, and the Azure Marketplace.

First, we’ll add the Azure Marketplace repository to helm and update it. Next, we install the NGINX helm chart to our AKS cluster.

$ helm repo add azure-marketplace https://marketplace.azurecr.io/helm/v1/repo
$ helm repo update
$ helm install my-release azure-marketplace/nginx
NAME: my-release
LAST DEPLOYED: Mon Aug 16 13:58:26 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The NGINX Ingress Controller has been installed.

To find the URL for our NGINX deployment, use kubectl to get the external IP address.

$ kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 3h21m
my-release-nginx LoadBalancer 10.0.212.197 20.72.78.59 80:31251/TCP 175m

Deploy a custom container

In the previous section, we used a Helm chart to deploy an application from a repository. But what if we want to deploy our custom application. In this example, we’ll build our NGINX container, push it to our registry, and deploy it on the AKS cluster.

Create our application container

For this example, you will need Docker. We will replace the default NGINX page with our welcome page. Copy the sample below and save it as index.html.

<!doctype html>
<html lang="en">
<head>
 <meta charset="utf-8">
 <title>AKS NGINX</title>
</head>
<body>
 <h2>Hello from Azure AKS</h2>
</body>
</html>

Next, we’ll make a Dockerfile to build our custom NGINX container. Copy and save the following to a file called Dockerfile.

FROM nginx:latest
COPY ./index.html /usr/share/nginx/html/index.html

Build and tag the image with this command and push it to the repository we created earlier.

$ docker build -t pulumipuscontainerregistry.azurecr.io/my-nginx:v1
$ az acr login --name pulumipusContainerRegistry
$ docker push pulumipuscontainerregistry.azurecr.io/my-nginx:v1

Create a deployment manifest

In the previous example, we deployed NGINX with Helm. Manifests are another way to deploy applications. A manifest contains a deployment that defines pods that run a containerized application. It also contains services that route traffic to pods.

Copy and save the example below to a file named manifest.yml.

apiVersion: apps/v1
kind: Deployment
metadata:
 creationTimestamp: null
 labels:
 app: my-nginx
 name: my-nginx
spec:
 replicas: 3
 selector:
 matchLabels:
 app: my-nginx
 strategy: {}
 template:
 metadata:
 creationTimestamp: null
 labels:
 app: my-nginx
 spec:
 containers:
 - image: pulumipuscontainerregistry.azurecr.io/my-nginx:v1
 name: my-nginx
 imagePullPolicy: Always
 resources: {}
 ports:
 - containerPort: 80
status: {}

---

apiVersion: v1
kind: Service
metadata:
 name: my-nginx
 labels:
 run: my-nginx
spec:
 ports:
 - port: 80
 protocol: TCP
 selector:
 app: my-nginx
 type: LoadBalancer

Deploy the application to AKS

We’ll use kubectl to deploy the application with the manifest. But before we can do this, we need to attach the ACR pulumipuscontainerregistry to the AKS cluster, aks-cluster. Once the registry is added to the cluster configuration, we can deploy our application with kubectl.

$ az aks update --resource-group aks-group --name aks-cluster --attach-acr pulumipuscontainerregistry
$ kubectl create -f manifest.yml

Use kubectl get service to get the load balancer’s external IP as we did with the Helm example.

Deploy with Pulumi

The previous article in this series showed how to deploy AKS with code. Starting with the Python example from Github and add to it to create a complete solution

Create a container registry and custom container

First, we create the image registry to hold our custom NGINX container. Put the index.html and the Dockerfile files in a directory called app. The app directory is the context Docker uses to build an image. Note that the Docker provider builds and pushes the image to our repository.

# Create a private ACR registry.
rg = azure.core.ResourceGroup('azure-native-py-aks')
registry = azure.containerservice.Registry('pulumipuscontainerrepository',
 resource_group_name=rg.name,
 admin_enabled=True,
 sku='Basic'

# Get registry info (creds and endpoint).
image_name = "pulumipuscontainerrepository/my-nginx"
registry_info = docker.ImageRegistry(
 server=registry.login_server,
 username=registry.admin_username,
 password=registry.admin_password
)

import pulumi_docker as docker

# Build and publish the container image.
image = docker.Image('my-image',
 build='app',
 image_name=image_name,
 registry=registry_info,
)

Deploy the container

The code below creates a Deployment and a LoadBalancer Service similar to the manifest we used earlier. The script exports the IP address of the LoadBalancer at the end of the script.


# Create a NGINX Deployment
app_labels = { 'app': 'my-nginx' }
app_dep = k8s.apps.v1.Deployment('my-aks-deployment',
 spec={
 'selector': { 'matchLabels': app_labels },
 'replicas': 3,
 'template': {
 'metadata': { 'labels': app_labels },
 'spec': {
 'containers': [{
 'name': 'pulumipuscontainerrepository/my-nginx',
 'image': 'my-nginx;,
 'ports': [
 {
 'name': 'http',
 'containerPort': 80
 }
 ]
 }],
 },
 },
 },
)

# Create a Service
app_svc = k8s.core.v1.Service('my-aks-service',
 metadata={ 'labels': app_labels },
 spec={
 'type': 'LoadBalancer',
 'ports': [
 {
 'port': 80,
 'targetPort': 80,
 'protocol': 'TCP'
 }
 ],
 'selector': app_labels,
 }
)
pulumi.export('application IP', app_svc.status.apply(lambda status: status.loadbalancer.ingress[0].ip))

This example provides a sketch of the process to create an AKS cluster and deploy a custom container. For a fully worked example, check out the Azure Kubernetes Service (AKS) - Hello World! tutorial.

Summary

There are many ways to deploy applications on AKS, including ConfigMaps and Kustomize which were not discussed. We’ve covered deploying with Helm, manifests, and infrastructure as code. This article covers the basics of application deployment using Deployments and Services. To review, Deployments are declarative updates to a Pod such as specifying a container to run, and Services route traffic to Pods either within the cluster or permitting ingress with a LoadBalancer. We should note that templating methods such as Helm or manifests require file management, whereas using cloud engineering practices enables managing both infrastructure and application deployment in a versioned and repeatable way.

The following article will wrap up the series. We’ll examine how to implement DevOps practices with Azure.

Top 5 Things an Azure Developer Needs to Know: Kubernetes Infrastructure

Sophia Parafina — Thu, 12 Aug 2021 00:00:00 +0000

History lesson time! In 2011, microservices debuted as an architectural style suited for the cloud. In 2013, Docker simplified building containers. Combining containers and microservices sparked a change in how applications were built and distributed in the cloud. As performance, scaling, and reliability became an increasing concern, container orchestration platforms became widely available. Kubernetes became the dominant container orchestration through community and corporate support, and some have suggested it was inevitable. Every major cloud service provider, including Azure, offers a version of Kubernetes.

Kubernetes streamlines container deployment and management, making applications scale and accessible. This article demonstrates configuring and deploying Kubernetes with Azure.

A Kubernetes Review

If you’re not familiar with Kubernetes concepts and terminology, the Getting Started with Kubernetes series can help get you up to speed.

Azure Kubernetes Service

Azure Kubernetes Service (AKS) is a hosted Kubernetes service. Azure manages the Kubernetes master nodes, and you are responsible for managing the agent or worker nodes. You only pay for the worker nodes in your cluster that make up your application.

Kubernetes nodes are the worker machines that can be either physical or virtual. AKS nodes use Azure virtual machines (VMs); and you can add storage, upgrade cluster components, or even run multiple node pools with mixed operating systems.

You can create an AKS cluster with

the Azure CLI,
the Azure portal,
PowerShell, and
templates, such as Azure Resource Manager (ARM) templates.

AKS features

Configuring and deploying Kubernetes can be complex. AKS provides many features to simplify the process, including the following features:

Cluster node and pod scaling adjust the number of nodes or pods as resource demand changes. Pods can scale horizontally, and the cluster can also autoscale.
Kubernetes is a fast-moving open source project, and AKS supports multiple versions. You can upgrade the cluster nodes without interrupting the application.
If you perform machine learning, AKS can create GPU-enabled node pools for compute-intensive, graphics-intensive, and visualization workloads.
AKS supports access control through Kubernetes RBAC and Azure Active Directory.
Integrated logging and monitoring with Azure Monitor for Containers collects memory and processor metrics from containers, nodes, and controllers.
AKS lets you mount static or dynamic storage volumes for persistent data. Storage volumes use Azure Disks for single pod access or Azure Files for concurrent pod access.
Virtual networking for pods in the cluster and other nodes let you use a peered virtual network. The network also provides ingress for applications with HTTP application routing.
Integration with development tools for Helm and a Visual Studio Code extension for Kubernetes improves the developer experience.
Support for Docker images, including storage with Azure Container Registry, makes deployment easier.

Create an AKS Cluster with the Azure Portal

We’ll use the Azure Portal to illustrate the steps to configure and deploy an AKS Cluster.

Step 1: Create a Kubernetes Service.

Open the Azure Portal and select Create Resource.
Select Containers > Kubernetes Service.
Select Create.

Step 2: Create an AKS cluster.

For this example, we will configure several options in the Basic window but use defaults for most options.

In Subscription, select an Azure Subscription.
Create or select a Resource Group.
In Cluster details, set the Kubernetes cluster name.
Change the Region if needed.

Use the default values for Primary node pool, and select Next: node pools.

Step 3: Configure node pools.

A node pool is a logical grouping of nodes. Nodes in a pool can have different virtual machines, different Kubernetes versions, and other attributes. You can use different node pools for different purposes, such as grouping workflows, e.g., a node pool for production and one for dev or test.

For this example, use the default values for node pools.

Step 4: Configure authentication.

You can authenticate, authorize, secure, and control access to Kubernetes clusters with

Kubernetes role-based access control (Kubernetes RBAC) to grant access to service accounts or
Azure Active Directory integration that provides a multi-tenant, cloud-based directory and identity management service.

To configure Authentication for this example, set the Authentication method to System-assigned managed identity. You can set Role-based access control (RBAC) to enabled, but it’s unnecessary for the example. Use the default value for the Node pool OS disk encryption type.

Step 5: Configure networking

AKS can use either kubenet or Azure CNI networking. Kubenet is the default configuration for AKS cluster creation.

With kubenet, Azure creates and configures the virtual network. However, only the nodes receive a routable IP address and pods use a NAT to communicate with resources outside the AKS cluster. This approach reduces the number of IP addresses you need to reserve in your network space for pods to use.

Azure CNIassigns an IP address to every pod, which makes them directly accessible. The IP addresses must be unique and planned in advance. Each node must be configured for the maximum number of pods to reserve IP addresses per node. Without accounting for the number of pods, the network can run out of IP addresses to allocate or necessitate the need to rebuild clusters with a larger subnet.

For this example, we’ll use kubenet for it’s simplicity, but in production Azure CNI maybe the better choice for applications.

Step 6: Complete the deployment

Select Review + create to deploy. Deployment takes several minutes to complete. On completion, you can verify the Deployment details or select Connect to cluster.

Step 7: Connect to the cluster

You can manage your cluster with kubectl, a command line tool for managing Kubernetes. You can install kubectl on linux, macOS, and Windows.

Copy and paste the commands to connect and authenticate to your cluster using the Azure CLI.

After connecting and authenticating to your cluster, you can use kubectl to query your cluster.

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
aks-agentpool-19694923-vmss000000 Ready agent 9m35s v1.20.7
aks-agentpool-19694923-vmss000001 Ready agent 9m39s v1.20.7
aks-agentpool-19694923-vmss000002 Ready agent 9m47s v1.20.7
$ kubectl get all
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 11m

Your AKS cluster is deployed and running.

Deploying an AKS cluster with code

Now that we have reviewed the process for creating an AKS cluster using the Azure Portal, we can repeat the process using code.

Step 1: Create a Resource group and a Service principal for the cluster. Note that we used a System-assigned managed identity in the Azure Portal example.

 // Create an Azure Resource Group
var resourceGroup = new ResourceGroup("azure-cs-aks");
// Create an AD service principal
var adApp = new Application("aks", new ApplicationArgs
{
DisplayName = "aks"
});
var adSp = new ServicePrincipal("aksSp", new ServicePrincipalArgs
{
ApplicationId = adApp.ApplicationId
});
// Generate random password
var password = new RandomPassword("password", new RandomPasswordArgs
{
Length = 20,
Special = true
});
// Create the Service Principal Password
var adSpPassword = new ServicePrincipalPassword("aksSpPassword", new ServicePrincipalPasswordArgs
{
ServicePrincipalId = adSp.Id,
Value = password.Result,
EndDate = "2099-01-01T00:00:00Z"
});
// Generate an SSH key
var sshKey = new PrivateKey("ssh-key", new PrivateKeyArgs
{
Algorithm = "RSA",
RsaBits = 4096
});

 // Create an Azure Resource Group
resourceGroup, err := resources.NewResourceGroup(ctx, "azure-go-aks", nil)
if err != nil {
return err
}
// Create an AD service principal.
adApp, err := azuread.NewApplication(ctx, "aks", &azuread.ApplicationArgs{
DisplayName: pulumi.String("aks"),
})
if err != nil {
return err
}
adSp, err := azuread.NewServicePrincipal(ctx, "aksSp", &azuread.ServicePrincipalArgs{
ApplicationId: adApp.ApplicationId,
})
if err != nil {
return err
}
// Generate a random password.
password, err := random.NewRandomPassword(ctx, "password", &random.RandomPasswordArgs{
Length: pulumi.Int(20),
Special: pulumi.Bool(true),
})
if err != nil {
return err
}
// Create the Service Principal Password.
adSpPassword, err := azuread.NewServicePrincipalPassword(ctx, "aksSpPassword", &azuread.ServicePrincipalPasswordArgs{
ServicePrincipalId: adSp.ID(),
Value: password.Result,
EndDate: pulumi.String("2099-01-01T00:00:00Z"),
})
if err != nil {
return err
}
// Generate an SSH key.
sshArgs := tls.PrivateKeyArgs{
Algorithm: pulumi.String("RSA"),
RsaBits: pulumi.Int(4096),
}
sshKey, err := tls.NewPrivateKey(ctx, "ssh-key", &sshArgs)
if err != nil {
return err
}

 # Create new resource group
resource_group = resources.ResourceGroup("azure-native-py-aks")
# Create an AD service principal
ad_app = azuread.Application("aks", display_name="aks")
ad_sp = azuread.ServicePrincipal("aksSp", application_id=ad_app.application_id)
# Generate random password
password = random.RandomPassword("password", length=20, special=True)
# Create the Service Principal Password
ad_sp_password = azuread.ServicePrincipalPassword("aksSpPassword",
service_principal_id=ad_sp.id,
value=password.result,
end_date="2099-01-01T00:00:00Z")
# Generate an SSH key
ssh_key = tls.PrivateKey("ssh-key", algorithm="RSA", rsa_bits=4096)

 // Create an Azure Resource Group
const resourceGroup = new resources.ResourceGroup("azure-go-aks");
// Create an AD service principal
const adApp = new azuread.Application("aks", {
displayName: "aks",
});
const adSp = new azuread.ServicePrincipal("aksSp", {
applicationId: adApp.applicationId,
});
// Generate random password
const password = new random.RandomPassword("password", {
length: 20,
special: true,
});
// Create the Service Principal Password
const adSpPassword = new azuread.ServicePrincipalPassword("aksSpPassword", {
servicePrincipalId: adSp.id,
value: password.result,
endDate: "2099-01-01T00:00:00Z",
});
// Generate an SSH key
const sshKey = new tls.PrivateKey("ssh-key", {
algorithm: "RSA",
rsaBits: 4096,
});

Step 2: Configure the AKS cluster

We set the configuration options in ManagedClusterAgentPoolProfileArgs:

Count: Number of virtual machines
MaxPods: Maximum number of pods that can run on a node.
Mode: Sets the type of pool node, which can be system or user
Name: Name of the pool node
OsType: Specifies the OS type
Type: Choose between a VirtualMachineScaleSet or an AvailabilitySet
VmSize: The virtual machine size used by the cluster.

The remaining parameters set the Kubernetes version, enables RBAC, and configures the Linux profile for the ContainerService.

 var cluster = new ManagedCluster("my-aks", new ManagedClusterArgs
{
ResourceGroupName = resourceGroup.Name,
AgentPoolProfiles =
{
new ManagedClusterAgentPoolProfileArgs
{
Count = 3,
MaxPods = 110,
Mode = "System",
Name = "agentpool",
OsDiskSizeGB = 30,
OsType = "Linux",
Type = "VirtualMachineScaleSets",
VmSize = "Standard_DS2_v2",
}
},
DnsPrefix = "AzureNativeprovider",
EnableRBAC = true,
KubernetesVersion = "1.18.14",
LinuxProfile = new ContainerServiceLinuxProfileArgs
{
AdminUsername = "testuser",
Ssh = new ContainerServiceSshConfigurationArgs
{
PublicKeys =
{
new ContainerServiceSshPublicKeyArgs
{
KeyData = sshKey.PublicKeyOpenssh,
}
}
}
},
NodeResourceGroup = $"MC_azure-cs_my_aks",
ServicePrincipalProfile = new ManagedClusterServicePrincipalProfileArgs
{
ClientId = adApp.ApplicationId,
Secret = adSpPassword.Value
}
});

 // Create the Azure Kubernetes Service cluster.
cluster, err := containerservice.NewManagedCluster(ctx, "go-aks", &containerservice.ManagedClusterArgs{
ResourceGroupName: resourceGroup.Name,
AgentPoolProfiles: containerservice.ManagedClusterAgentPoolProfileArray{
&containerservice.ManagedClusterAgentPoolProfileArgs{
Name: pulumi.String("agentpool"),
Mode: pulumi.String("System"),
OsDiskSizeGB: pulumi.Int(30),
Count: pulumi.Int(3),
VmSize: pulumi.String("Standard_DS2_v2"),
OsType: pulumi.String("Linux"),
},
},
LinuxProfile: &containerservice.ContainerServiceLinuxProfileArgs{
AdminUsername: pulumi.String("testuser"),
Ssh: containerservice.ContainerServiceSshConfigurationArgs{
PublicKeys: containerservice.ContainerServiceSshPublicKeyArray{
containerservice.ContainerServiceSshPublicKeyArgs{
KeyData: sshKey.PublicKeyOpenssh,
},
},
},
},
DnsPrefix: resourceGroup.Name,
ServicePrincipalProfile: &containerservice.ManagedClusterServicePrincipalProfileArgs{
ClientId: adApp.ApplicationId,
Secret: adSpPassword.Value,
},
KubernetesVersion: pulumi.String("1.18.14"),
})
if err != nil {
return err
}

 # Create cluster
managed_cluster_name = config.get("managedClusterName")
if managed_cluster_name is None:
managed_cluster_name = "azure-native-aks"
managed_cluster = containerservice.ManagedCluster(
managed_cluster_name,
resource_group_name=resource_group.name,
agent_pool_profiles=[{
"count": 3,
"max_pods": 110,
"mode": "System",
"name": "agentpool",
"node_labels": {},
"os_disk_size_gb": 30,
"os_type": "Linux",
"type": "VirtualMachineScaleSets",
"vm_size": "Standard_DS2_v2",
}],
enable_rbac=True,
kubernetes_version="1.18.14",
linux_profile={
"admin_username": "testuser",
"ssh": {
"public_keys": [{
"key_data": ssh_key.public_key_openssh,
}],
},
},
dns_prefix=resource_group.name,
node_resource_group=f"MC_azure-native-go_{managed_cluster_name}_westus",
service_principal_profile={
"client_id": ad_app.application_id,
"secret": ad_sp_password.value
})

 const cluster = new containerservice.ManagedCluster(managedClusterName, {
resourceGroupName: resourceGroup.name,
agentPoolProfiles: [{
count: 3,
maxPods: 110,
mode: "System",
name: "agentpool",
nodeLabels: {},
osDiskSizeGB: 30,
osType: "Linux",
type: "VirtualMachineScaleSets",
vmSize: "Standard_DS2_v2",
}],
dnsPrefix: resourceGroup.name,
enableRBAC: true,
kubernetesVersion: "1.18.14",
linuxProfile: {
adminUsername: "testuser",
ssh: {
publicKeys: [{
keyData: sshKey.publicKeyOpenssh,
}],
},
},
nodeResourceGroup: `MC_azure-go_${managedClusterName}`,
servicePrincipalProfile: {
clientId: adApp.applicationId,
secret: adSpPassword.value,
},
});

Step 3: Export the kubeconfig file

A kubeconfig file organizes information about clusters and allows kubectl connect to the cluster.

...
// Export the KubeConfig
this.KubeConfig = Output.Tuple(resourceGroup.Name, cluster.Name).Apply(names =>
GetKubeConfig(names.Item1, names.Item2));
}
[Output]
public Output<string> KubeConfig { get; set; }
private static async Task<string> GetKubeConfig(string resourceGroupName, string clusterName)
{
var credentials = await ListManagedClusterUserCredentials.InvokeAsync(new ListManagedClusterUserCredentialsArgs
{
ResourceGroupName = resourceGroupName,
ResourceName = clusterName
});
var encoded = credentials.Kubeconfigs[0].Value;
var data = Convert.FromBase64String(encoded);
return Encoding.UTF8.GetString(data);
}

 ctx.Export("kubeconfig", pulumi.All(cluster.Name, resourceGroup.Name, resourceGroup.ID()).ApplyT(func(args interface{}) (string, error) {
clusterName := args.([]interface{})[0].(string)
resourceGroupName := args.([]interface{})[1].(string)
creds, err := containerservice.ListManagedClusterUserCredentials(ctx, &containerservice.ListManagedClusterUserCredentialsArgs{
ResourceGroupName: resourceGroupName,
ResourceName: clusterName,
})
if err != nil {
return "", err
}
encoded := creds.Kubeconfigs[0].Value
kubeconfig, err := base64.StdEncoding.DecodeString(encoded)
if err != nil {
return "", err
}
return string(kubeconfig), nil
}))

 # Export kubeconfig
encoded = creds.kubeconfigs[0].value
kubeconfig = encoded.apply(
lambda enc: base64.b64decode(enc).decode())
pulumi.export("kubeconfig", kubeconfig)

 const creds = pulumi.all([cluster.name, resourceGroup.name]).apply(([clusterName, rgName]) => {
return containerservice.listManagedClusterUserCredentials({
resourceGroupName: rgName,
resourceName: clusterName,
});
});
const encoded = creds.kubeconfigs[0].value;
export const kubeconfig = encoded.apply(enc => Buffer.from(enc, "base64").toString());

Step 4: Connect to the AKS cluster

We can use the kubeconfig file connect to the cluster. It’s common practice to copy the kubeconfig file to ~/.kube/config, which is the directory that kubectl looks for the file. However, you can use any directory with the --kubeconfig flag, e.g.,

$ kubectl --kubeconfig /path/to/kubeconfig_file get pods

As this example shows, deploying an AKS cluster requires setting parameters. This action can be done in the portal or with code. The advantage of code is that clusters can be created on demand without having to use the Azure portal. This setup is convenient when you have different environments, such as a dev/test environment and a production environment.

The complete code for deploying AKS is available on GitHub for Typescript, Python, Go, and C#.

Summary

Azure Kubernetes Service lets you deploy a Kubernetes cluster quickly and efficiently. An AKS deployment configures the worker nodes since the master nodes are provided by Azure. The Azure Portal provides a simplified interface for configuration, but if you want fine-grain control over the deployment, infrastructure as code is an option. This is particularly true for production deployments where the configuration requires tuning for an application deployment.

In the next article in this series, we’ll deploy an application on an AKS cluster using different methods.

Top 5 Things an Azure Developer Needs to Know: Static Websites

Sophia Parafina — Mon, 09 Aug 2021 00:00:00 +0000

Static web applications are a popular way to publish websites. There are many reasons for adopting static web applications, including speed, security, version control, scalability, and reduced cost.

This article goes into depth about the two types of static web applications that Azure offers. The first uses Azure Blob Storage to serve static data. The second method is Azure Static Web Apps which follows the pattern of Jamstack applications that use a static website generator integrated with source control that publishes to a Content Delivery Network. We’ll take an in-depth look at both methods and consider the pros and cons of each.

Static Websites with Azure Storage

Hosting a static website on Azure Store is an option for serving web content without a web server. You can upload HTML, CSS, images, and JavaScript to an Azure storage container named $web. Because the content is in a storage container, you can also use other PaaS services like Azure Functions or Azure CDN.

Azure Portal

Let’s get started using the Azure Portal.

Step 1: Create a storage account (optional if you have an existing storage account)

In the Azure Portal, navigate to Storage accounts, and follow the defaults.

Step 2: In the Storage account page, select Data management > Static website

Select enabled for the Static website, and enter values for the Index document and Error document fields. Save the changes.

Step 3: Upload files

Here are example files to upload or you can use your own.

index.html

<html>
 <body>
 <h1>This file is served from Blob Storage (courtesy of Pulumi!)</h1>
 </body>
</html>

404.html

<html>
 <body>
 <h1>That's a 404! Still, from the Blob Storage.</h1>
 </body>
</html>

We’ll use Storage Explorer (preview), and select BLOB CONTAINERS > $web. In the Upload blob pane, add the index.html and 404.html files, and select Upload.

Step 4: Get the URL

Select Static website in the overview pane, and the URL is the Primary endpoint.

Build and deploy a static website with code

We can repeat the same process using a programming language. The process includes:

Create a storage account
Enable Static website
Upload files
Configure and publish endpoints

We can reproduce this process in code with C#, Go, Python, Typescript, or in any language Pulumi supports. Let’s step through the code.

Step 1: Create a Resource group and Storage account.

 var resourceGroup = new Resources.ResourceGroup("resourceGroup");
var storageAccount = new Storage.StorageAccount("storageaccount", new Storage.StorageAccountArgs
{
Kind = Storage.Kind.StorageV2,
ResourceGroupName = resourceGroup.Name,
Sku = new Storage.Inputs.SkuArgs
{
Name = Storage.SkuName.Standard_LRS,
},
});

 pulumi.Run(func(ctx *pulumi.Context) error {
resourceGroup, err := resources.NewResourceGroup(ctx, "website-rg", nil)
if err != nil {
return err
}
storageAccount, err := storage.NewStorageAccount(ctx, "sa", &storage.StorageAccountArgs{
ResourceGroupName: resourceGroup.Name,
Kind: storage.KindStorageV2,
Sku: &storage.SkuArgs{
Name: storage.SkuName_Standard_LRS,
},
})
if err != nil {
return err
}

resource_group = resources.ResourceGroup("resourceGroup")
storage_account = storage.StorageAccount(
"storageaccount",
access_tier=storage.AccessTier.HOT,
enable_https_traffic_only=True,
encryption=storage.EncryptionArgs(
key_source=storage.KeySource.MICROSOFT_STORAGE,
services=storage.EncryptionServicesArgs(
blob=storage.EncryptionServiceArgs(
enabled=True,
),
file=storage.EncryptionServiceArgs(
enabled=True,
),
),
),
kind=storage.Kind.STORAGE_V2,
network_rule_set=storage.NetworkRuleSetArgs(
bypass=storage.Bypass.AZURE_SERVICES,
default_action=storage.DefaultAction.ALLOW,
),
resource_group_name=resource_group.name,
sku=storage.SkuArgs(
name=storage.SkuName.STANDARD_LRS,
))

const resourceGroup = new resources.ResourceGroup("resourceGroup");
const storageAccount = new storage.StorageAccount("storageaccount", {
enableHttpsTrafficOnly: true,
kind: storage.Kind.StorageV2,
resourceGroupName: resourceGroup.name,
sku: {
name: storage.SkuName.Standard_LRS,
},
});

Step 2: Enable static website

// Enable static website support
var staticWebsite = new Storage.StorageAccountStaticWebsite("staticWebsite", new Storage.StorageAccountStaticWebsiteArgs
{
AccountName = storageAccount.Name,
ResourceGroupName = resourceGroup.Name,
IndexDocument = "index.html",
Error404Document = "404.html",
});

// Enable static website support
staticWebsite, err := storage.NewStorageAccountStaticWebsite(ctx, "staticWebsite", &storage.StorageAccountStaticWebsiteArgs{
AccountName: storageAccount.Name,
ResourceGroupName: resourceGroup.Name,
IndexDocument: pulumi.String("index.html"),
Error404Document: pulumi.String("404.html"),
})
if err != nil {
return err
}

# Enable static website support
static_website = storage.StorageAccountStaticWebsite(
"staticWebsite",
account_name=storage_account.name,
resource_group_name=resource_group.name,
index_document="index.html",
error404_document="404.html")

// Enable static website support
const staticWebsite = new storage.StorageAccountStaticWebsite("staticWebsite", {
accountName: storageAccount.name,
resourceGroupName: resourceGroup.name,
indexDocument: "index.html",
error404Document: "404.html",
});

Step 3: Upload content

var index_html = new Storage.Blob("index.html", new Storage.BlobArgs
{
ResourceGroupName = resourceGroup.Name,
AccountName = storageAccount.Name,
ContainerName = staticWebsite.ContainerName,
Source = new FileAsset("./wwwroot/index.html"),
ContentType = "text/html",
});
var notfound_html = new Storage.Blob("404.html", new Storage.BlobArgs
{
ResourceGroupName = resourceGroup.Name,
AccountName = storageAccount.Name,
ContainerName = staticWebsite.ContainerName,
Source = new FileAsset("./wwwroot/404.html"),
ContentType = "text/html",
});

// Upload the files
_, err = storage.NewBlob(ctx, "index.html", &storage.BlobArgs{
ResourceGroupName: resourceGroup.Name,
AccountName: storageAccount.Name,
ContainerName: staticWebsite.ContainerName,
Source: pulumi.NewFileAsset("./wwwroot/index.html"),
ContentType: pulumi.String("text/html"),
})
if err != nil {
return err
}
_, err = storage.NewBlob(ctx, "404.html", &storage.BlobArgs{
ResourceGroupName: resourceGroup.Name,
AccountName: storageAccount.Name,
ContainerName: staticWebsite.ContainerName,
Source: pulumi.NewFileAsset("./wwwroot/404.html"),
ContentType: pulumi.String("text/html"),
})
if err != nil {
return err
}

# Upload the files
index_html = storage.Blob(
"index_html",
resource_group_name=resource_group.name,
account_name=storage_account.name,
container_name=static_website.container_name,
source=pulumi.FileAsset("./wwwroot/index.html"),
content_type="text/html")
notfound_html = storage.Blob(
"notfound_html",
resource_group_name=resource_group.name,
account_name=storage_account.name,
container_name=static_website.container_name,
source=pulumi.FileAsset("./wwwroot/404.html"),
content_type="text/html")

// Upload the files
["index.html", "404.html"].map(name =>
new storage.Blob(name, {
resourceGroupName: resourceGroup.name,
accountName: storageAccount.name,
containerName: staticWebsite.containerName,
source: new pulumi.asset.FileAsset(`./wwwroot/${name}`),
contentType: "text/html",
}),
);

Step 4: Configure and publish endpoints

// Web endpoint to the website
this.StaticEndpoint = storageAccount.PrimaryEndpoints.Apply(primaryEndpoints => primaryEndpoints.Web);
// (Optional) Add a CDN in front of the storage account.
var profile = new Cdn.Profile("profile", new Cdn.ProfileArgs
{
ResourceGroupName = resourceGroup.Name,
Location = "global",
Sku = new Cdn.Inputs.SkuArgs
{
Name = Cdn.SkuName.Standard_Microsoft,
},
});
var endpointOrigin = storageAccount.PrimaryEndpoints.Apply(pe => pe.Web.Replace("https://", "").Replace("/", ""));
[Output("staticEndpoint")]
public Output<string> StaticEndpoint { get; set; }
}

endpointOrigin := storageAccount.PrimaryEndpoints.Web().ApplyT(func(endpoint string) string {
endpoint = strings.ReplaceAll(endpoint, "https://", "")
endpoint = strings.ReplaceAll(endpoint, "/", "")
return endpoint
}).(pulumi.StringOutput)
// Web endpoint to the website
ctx.Export("staticEndpoint", storageAccount.PrimaryEndpoints.Web())
}

endpoint_origin = storage_account.primary_endpoints.apply(
lambda primary_endpoints: primary_endpoints.web.replace("https://", "").replace("/", ""))
# Web endpoint to the website
pulumi.export("staticEndpoint", storage_account.primary_endpoints.web)

// Web endpoint to the website
export const staticEndpoint = storageAccount.primaryEndpoints.web;

The complete examples for C#, Go, Python, and Typescript are on Github.

Azure Static Web Apps

Azure Static Web Apps (SWA) builds and deploys web apps from a code repository. Azure works directly with GitHub or Azure DevOps to watch a branch on your repository. When you push a commit or accept a pull request, your app is built and deployed to Azure. When you build web apps with SWA, your static assets are deployed to a CDN that serves files from geographically distributed points.

Static web apps can be built with popular frameworks that don’t require server-side rendering, such as React, Angular, and Vue. Web applications typically include HTML, JavaScript, images, and CSS. In addition to these assets, you can create API endpoints hosted in an Azure Function.

The key thing to remember with SWAs is that you build the application from a repository.

Let’s jump into Azure Static Web Apps!

Build and deploy

We’ll use Visual Studio Code’s Azure Static Web App Extension and a GitHub account.

Step 1: Install the Azure Web Static Web Apps extension.

Follow the instructions to authorize Visual Studio Code to access your GitHub account.

Step 2: Create a web application

For convenience, we can use the Azure template for generating web applications. Open this link and click the Use this template button to generate a basic React application.

Clone the repository to your computer.

$ git clone https://github.com/spara/bookish-doodle.git

Step 3: Create a static web app with Visual Studio Code

Open your repository with Visual Studio Code and activate the Azure extension. On the APP SERVICE item, select the + to create a web app.

Follow the prompts:

Create a unique name.

Select a project structure.

Select an application directory.

Select a build directory.

When VS Code completes configuring your application, you will be prompted to deploy.

You can view the application in the browser.

Step 3: Change the code

Edit ./src/app.js and change World to Cloud Engineers.

function App() {
 const value = 'Cloud Engineers';
 return <div>Hello {value}</div>;
}

Add, commit, and push your changes to GitHub.

$ git add .
$ git commit -m 'changed message'
$ git push

Select the Actions tab of your repository to see the workflows. Select the changed message, and then select Build and Deploy Job.

To see the details of the deployment, select Build and Deploy.

So what happened here? First, we used the Azure Static Web Apps for Visual Studio Code to authorize access to GitHub. Next, we created a deployment using the extension, created a GitHub Actions workflow, and deployed the application. We edited the code and pushed it to the repository. The push triggered the GitHub Action, rebuilt, and deployed the application.

The Azure Static Web Apps service lets you create a complete DevOps workflow.

Build and deploy with code and Pulumi

Can we create a complete DevOps workflow with code? Of course, we can! The Pulumi Azure Native provider uses the same API as VS Code. In the example below, we can duplicate the process without using an extension or the Azure CLI.

import pulumi
import pulumi_azure_native as azure_native

static_site = azure_native.web.StaticSite("staticSite",
 branch="master",
 build_properties=azure_native.web.StaticSiteBuildPropertiesArgs(
 api_location="api",
 app_artifact_location="build",
 app_location="app",
 ),
 location="West US 2",
 name="testStaticSite0",
 repository_token="repoToken123",
 repository_url="https://github.com/username/RepoName",
 resource_group_name="rg",
 sku=azure_native.web.SkuDescriptionArgs(
 name="Basic",
 tier="Basic",
 ))

In the example above, creating a static web app requires configuring the same parameters we used in the Visual Studio Code example. The difference is that we create a Pulumi Project with our application at the root of the project directory in a folder called app. Once the static web app stack is created, you can push changes and trigger a deployment. One of the advantages of using infrastructure as code is that you can use the development environment and toolchain that you prefer. You are not bound to using a specific extension or development environment. We can be productive with our toolchain and create a complete deployment workflow using GitHub Actions with cloud engineering and Azure Static Web Apps.

Summary

This article demonstrates two ways to build static websites with Azure. The first way is to use Azure Storage to deploy the website. We showed how to use the Azure Portal and infrastructure as code to deploy. The other way to deploy a static website is to use the Azure Static Web Apps Service. We used the Visual Studio Code extension to configure GitHub Actions to deploy the React application in this example. We demonstrated how to deploy using code because the Pulumi Azure Native provider uses the Azure API. Infrastructure as code lets us choose our development environment where we are productive. In the next installment of this series, we’ll tackle deploying Kubernetes.

Top 5 Things an Azure Developer Needs to Know: Serverless

Sophia Parafina — Fri, 06 Aug 2021 00:00:00 +0000

The previous article was a deep dive into virtual machines. First, we used the Azure Portal to create and deploy a virtual machine; then, we repeated the process using infrastructure as code. We further demonstrated how to automate provisioning as part of cloud engineering’s build and deploy processes.

This article will explore the other end of the cloud infrastructure with serverless, which is an on-demand, fully-managed cloud architecture.

What is serverless, and when to use it?

Serverless is an event-driven architecture that executes code when triggered. Azure implements serverless with Azure Functions and Events. A function typically performs a single task, such as saving a log file. A function can perform multiple tasks, but in general, functions adhere to the principle of “you only had one job.” Functions can be written in any Azure supported language: C #, F#, JavaScript, PowerShell, Python, and Typescript.

An Event calls a function to execute. It can be a webhook, an HTTP request, or a scheduled trigger. Azure provides many function templates with a range of triggers; furthermore, they can be customized to application requirements.

Azure Functions are ideal for specific use cases that include:

when demand varies unpredictably, serverless can scale automatically
when a service is used infrequently, serverless can reduce costs by only charging per use
serverless can eliminate maintenance costs
when you have client-heavy applications, where most of the business logic is in the client
if you have high latency tasks like data processing

Serverless is not ideal if the application runs constantly, needs a quick response (otherwise known as the cold start problem, or is a long-running process that can exceed the timeout period for your execution plan.

With those caveats, let’s jump into creating a serverless function using the Azure Portal to understand how to write a function and how the pieces work together.

Our first serverless function

For this example, we’ll use Visual Studio Code and the Azure Functions extension.

Step 1: With the Azure Functions extension installed, click on the Activity Bar and click on Create New Project.

Select a folder for your project.
Select a language, use Typescript.
Select HTTP trigger.
Name your function, e.g., myHttpTrigger.
Set the Authorization level to Anonymous

When finished, you’ll have a template.

import { AzureFunction, Context, HttpRequest } from "@azure/functions"

const httpTrigger: AzureFunction = async function (context: Context, req: HttpRequest): Promise<void> {
 context.log('HTTP trigger function processed a request.');
 const name = (req.query.name || (req.body && req.body.name));
 const responseMessage = name
 ? "Hello, " + name + ". This HTTP triggered function executed successfully."
 : "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response.";

 context.res = {
 // status: 200, /* Defaults to 200 */
 body: responseMessage
 };

};

export default httpTrigger;

Step 2: (Optional) If you have Azure Functions Core tools installed, you can run the function locally. Press F5 or click on Run > Start debugging.

The service will run locally and provide you with a URL:

Functions:

 myHttpTrigger: [GET,POST] http://localhost:7071/api/myHttpTrigger

Navigate to the URL in a browser or use curl.

$ curl http://localhost:7071/api/myHttpTrigger
This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response.

Press Control-C in the terminal to stop the debugger.

Step 3: Publish the function to Azure.

Make sure you are signed into Azure and click on Deploy function app…

Select Create a new Function App in Azure and enter a name, “exampleHttpTrigger”
Select a runtime stack, Node.js 14 LTS
Select a location for new resources, East US

In the terminal pane, click on the Output tab, and you’ll see the URL for the function. You can call the function with curl with the name parameter.

$ curl https://myazurehttptrigger.azurewebsites.net/api/myhttptrigger?name=Pulumipus
Hello, Pulumipus. This HTTP triggered function executed successfully.

Don’t forget to delete the function in the Azure Portal!

Deploying Azure Functions with code

Creating and deploying an Azure Function is a bit more involved than using the Azure Function extension with VS Code. What goes on behind the scenes after you write the function is a process that includes:

Creating a ResourceGroup

// Create a separate resource group for this example.
const resourceGroup = new resources.ResourceGroup("functions-rg");

Creating the storage account and code container that holds the function

// Storage account is required by Function App.
// Also, we will upload the function code to the same storage account.
const storageAccount = new storage.StorageAccount("sa", {
 resourceGroupName: resourceGroup.name,
 sku: {
 name: storage.SkuName.Standard_LRS,
 },
 kind: storage.Kind.StorageV2,
});

// Function code archives will be stored in this container.
const codeContainer = new storage.BlobContainer("zips", {
 resourceGroupName: resourceGroup.name,
 accountName: storageAccount.name,
});

Uploading the function code as a zip file to the storage account. Note that the source parameter points to the function’s directory.

// Upload Azure Function's code as a zip archive to the storage account.
const codeBlob = new storage.Blob("zip", {
 resourceGroupName: resourceGroup.name,
 accountName: storageAccount.name,
 containerName: codeContainer.name,
 source: new pulumi.asset.FileArchive("./javascript"),
});

Setting the Consumption Plan to determine how to bill when the function executes

// Define a Consumption Plan for the Function App.
// You can change the SKU to Premium or App Service Plan if needed.
const plan = new web.AppServicePlan("plan", {
 resourceGroupName: resourceGroup.name,
 sku: {
 name: "Y1",
 tier: "Dynamic",
 },
});

Set the connection string to the storage account and the zip archive’s Shared Access Signature (SAS) to grant rights to use the storage account. We will need these to create the function in Azure.

// Build the connection string and zip archive's SAS URL. They will go to Function App's settings.
const storageConnectionString = getConnectionString(resourceGroup.name, storageAccount.name);
const codeBlobUrl = signedBlobReadUrl(codeBlob, codeContainer, storageAccount, resourceGroup);

Now that we have all the parameters needed to deploy the function: the resource group, the billing plan, the connection string to Azure storage, the Functions version (3), the runtime (Node.js), the runtime Node version (14.0), and the SAS url for the function code, we can build and deploy our Azure Function.

const app = new web.WebApp("fa", {
 resourceGroupName: resourceGroup.name,
 serverFarmId: plan.id,
 kind: "functionapp",
 siteConfig: {
 appSettings: [
 { name: "AzureWebJobsStorage", value: storageConnectionString },
 { name: "FUNCTIONS_EXTENSION_VERSION", value: "~3" },
 { name: "FUNCTIONS_WORKER_RUNTIME", value: "node" },
 { name: "WEBSITE_NODE_DEFAULT_VERSION", value: "~14" },
 { name: "WEBSITE_RUN_FROM_PACKAGE", value: codeBlobUrl },
 ],
 http20Enabled: true,
 nodeVersion: "~14",
 },
});

export const endpoint = pulumi.interpolate`https://${app.defaultHostName}/api/HelloNode?name=Pulumi`;

At the very end of the script, we export the URL to the service for you to trigger.

Why is it so complicated?

Isn’t infrastructure as code supposed to simplify infrastructure deployments? This seems more effort than using the Visual Studio Code extension or even the Azure CLI on the surface. However, it’s important to note that this is boiler-plate code that you can reuse to deploy multiple functions with different runtimes and Consumption Plans. The key to using infrastructure code is that it is repeatable, customizable, and a CI/CD pipeline can deploy changes automatically.

Try out the complete example in either Typescript or C# to get familiar with Azure Functions. You can also learn how Functions are written in all supported languages by checking out the Azure Functions in All Supported Languages example.

In the following article, we’ll do a deep dive into Azure static websites, which is a popular option for Jamstacks.

Top 5 Things an Azure Developer Needs to Know: VMs

Sophia Parafina — Wed, 04 Aug 2021 00:00:00 +0000

So you want to be an Azure dev and all-around infrastructure wizard? Let’s start with the basics, virtual machines! In the previous article, the common use case for virtual machines is migrating applications from dedicated hardware. You want full control of the machine to install required software for the application or configure storage and networking.

Azure provides many ways to create and configure virtual machines ranging from the Azure CLI to the Azure Portal. In this article, we’ll first create a virtual machine using the portal to understand the requirements and process; then, we’ll do it with code using Pulumi’s Azure Native provider, which is built directly from the Azure Resource Manager API.

Creating a VM with the Azure Portal

When creating virtual machines, you should consider the operating system, storage requirements, and VM size with regard to CPU to memory ratio. Azure offers many sizes for virtual machines depending on your workload. If you’re migrating a traditional n-tier application to the cloud, it’s best to start with virtual machines that match your current configuration.

This article uses a simple example to deploy a static web application on a virtual machine to illustrate the process. To get started, sign in to the Azure Portal.

Step 1:

Under Azure Services, select Virtual machines

Select Create > Virtual Machine

Step 2: Create a Resource Group

A Resource Group is a logical collection of virtual machines, storage, virtual networks, web apps, and databases. Users will commonly group an application’s related resources. We’ll create myResourceGroup for our application.

Step 3: Configure the VM

Next, we’ll provide details for the VM by giving it a name, myVM, setting the Region and Availability options to No infrastructure redundancy required. We’ll use an Ubuntu image and set the VM size Standard_DS1_v2.

Step 4: Configure the Administrator Account

Virtual machines are Infrastructure as a Service, which means you will have to perform provisioning, updates, and maintenance. You’ll need an administrator account to perform these tasks. To keep this example simple, we’ll use Password as the Authentication type, but in practice, you should use Public Key Infrastructure (PKI) because it is more secure than a password that can be brute-forced.

Step 5: Configure inbound ports

You have to log into your virtual machine as well as allowing inbound requests to the static website. Select both HTTP (80) and SSH (22) then click on Review + create. Note that you can also add storage by clicking on Disks, but we’ll use the defaults for this example.

If your configuration is valid, you’ll see the following screen. Click Create to instantiate the vm.

Step 6: Enjoy your success

You can go and check out your VM by clicking on Go to resource.

Well, that seems simple and easy, but what if you had to deploy several virtual machines for the application that includes a web server, a worker to process requests, a message queuing system, and a database? What if your current system has multiple web servers and backend workers behind a load balancer? You’ll have to create, deploy, and maintain each VM because this is an IaaS.

There’s a better way using infrastructure as code and cloud engineering methodologies to create an automated process for creating, provisioning, and maintaining virtual machines.

Cloud Engineering to the Rescue!

Creating and provisioning one VM isn’t difficult, but migrating a traditional n-tier application often requires multiple virtual machines including those needed for horizontal scaling. This is where infrastructure as code excels. By using cloud engineering, we can automate build, deploy, and manage process for any infrastructure or application.

Let’s look at an example of deploying a web server using a virtual machine. The complete example is available in either Python or Typescript. We will examine the Python code.

We’re using the Azure Native provider, which implements the best possible support for the Azure platform in Pulumi. It exposes the entire API surface of Azure to developers and operators. The native provider supports over 1,000 resource types, with more added as they are released by Azure.

The script starts with importing the Pulumi Azure Native SDK modules and retrieving configuration parameters such as the username and password required to log into the server for provisioning. It also creates a resource group.

import base64
from pulumi import Config, Output, export
import pulumi_azure_native.compute as compute
import pulumi_azure_native.network as network
import pulumi_azure_native.resources as resources

config = Config()
username = config.require("username")
password = config.require("password")

resource_group = resources.ResourceGroup("server")

The next part creates the networking resources, including a dynamically allocated public IP address for the server.

net = network.VirtualNetwork(
 "server-network",
 resource_group_name=resource_group.name,
 address_space=network.AddressSpaceArgs(
 address_prefixes=["10.0.0.0/16"],
 ),
 subnets=[network.SubnetArgs(
 name="default",
 address_prefix="10.0.1.0/24",
 )])

public_ip = network.PublicIPAddress(
 "server-ip",
 resource_group_name=resource_group.name,
 public_ip_allocation_method=network.IPAllocationMethod.DYNAMIC)

network_iface = network.NetworkInterface(
 "server-nic",
 resource_group_name=resource_group.name,
 ip_configurations=[network.NetworkInterfaceIPConfigurationArgs(
 name="webserveripcfg",
 subnet=network.SubnetArgs(id=net.subnets[0].id),
 private_ip_allocation_method=network.IPAllocationMethod.DYNAMIC,
 public_ip_address=network.PublicIPAddressArgs(id=public_ip.id),
 )])

And here’s our web server and index page using Python’s simpleHTTPServer.

init_script = """#!/bin/bash
echo "Hello, World!" > index.html
nohup python -m SimpleHTTPServer 80 &"""

Finally, here’s how we create the virtual machine. We add the VM to the resource group and associate the network_profile to network_iface that we defined previously. We set the vm_size, set up the os_profile with the hostname and username and password. In the example, we create a storage profile and use Ubuntu for the image profile. The script ends by exporting the public IP address of the webserver.

vm = compute.VirtualMachine(
 "server-vm",
 resource_group_name=resource_group.name,
 network_profile=compute.NetworkProfileArgs(
 network_interfaces=[
 compute.NetworkInterfaceReferenceArgs(id=network_iface.id),
 ],
 ),
 hardware_profile=compute.HardwareProfileArgs(
 vm_size=compute.VirtualMachineSizeTypes.STANDARD_A0,
 ),
 os_profile=compute.OSProfileArgs(
 computer_name="hostname",
 admin_username=username,
 admin_password=password,
 custom_data=base64.b64encode(init_script.encode("ascii")).decode("ascii"),
 linux_configuration=compute.LinuxConfigurationArgs(
 disable_password_authentication=False,
 ),
 ),
 storage_profile=compute.StorageProfileArgs(
 os_disk=compute.OSDiskArgs(
 create_option=compute.DiskCreateOptionTypes.FROM_IMAGE,
 name="myosdisk1",
 ),
 image_reference=compute.ImageReferenceArgs(
 publisher="canonical",
 offer="UbuntuServer",
 sku="16.04-LTS",
 version="latest",
 ),
 ))

combined_output = Output.all(vm.id, public_ip.name, resource_group.name)
public_ip_addr = combined_output.apply(
 lambda lst: network.get_public_ip_address(
 public_ip_address_name=lst[1],
 resource_group_name=lst[2]))
export("public_ip", public_ip_addr.ip_address)

On the face of it, this seems more complex than using the Azure Portal. The critical thing to remember is that this process is reproducible, so if you require additional virtual machines, you can add a loop to create the necessary number of VMs.

But what about provisioning? Because this is code, you can write a provisioning script using Pulumi’s dynamic provider that connects to the webserver, copies files, and executes commands. Here’s a code snippet of a dynamic provider that copies files to your VM using scp.

# CopyFileProvider implements the resource lifecycle for the CopyFile resource type below.
class CopyFileProvider(ProvisionerProvider):
 def on_create(self, inputs: Any) -> Any:
 ssh = connect(inputs['conn'])
 scp = ssh.open_sftp()
 try:
 scp.put(inputs['src'], inputs['dest'])
 finally:
 scp.close()
 ssh.close()
 return inputs

# CopyFile is a provisioner step that can copy a file over an SSH connection.
class CopyFile(dynamic.Resource):
 def __init__(self, name: str, conn: pulumi.Input[ConnectionArgs],
 src: str, dest: str, opts: Optional[pulumi.ResourceOptions] = None):
 self.conn = conn
 """conn contains information on how to connect to the destination, in addition to dependency information."""
 self.src = src
 """
 src is the source of the file or directory to copy. It can be specified as relative to the current
 working directory or as an absolute path. This cannot be specified if content is set.
 """
 self.dest = dest
 """dest is required and specifies the absolute path on the target where the file will be copied to."""

 super().__init__(
 CopyFileProvider(),
 name,
 {
 'dep': conn,
 'conn': conn,
 'src': src,
 'dest': dest,
 'fileHash': sha256sum(src),
 },
 opts,
 )

Summary

Although it’s relatively simple to create virtual machines using the Azure Portal or the Azure CLI, provisioning and maintaining them manually can be complex and error-prone. If we use code to build, deploy, and manage VMs and applications, we can automate the process making updates and maintenance repeatable processes and reduce errors. We can tear down existing VMs and replace them with updated and provisioned versions using infrastructure as code. This is a lot of information if you’re starting your Azure cloud journey, so try something fun and deploy Minecraft on Azure!

Top 5 Things an Azure Developer Needs to Know: Introduction

Sophia Parafina — Mon, 02 Aug 2021 00:00:00 +0000

The Azure cloud platform includes over 200 products and cloud services. Wherever you are in your Microsoft cloud engineering journey, you should be familiar with these top 5 cloud tasks that are essential building blocks commonly used to deploy applications and infrastructure to the Azure cloud.

In this series of articles, we’ll go in-depth on virtual machines, Azure Functions, static websites, building an Azure Kubernetes Service cluster and deploying applications on AKS, and DevOps with Azure App Service.

Azure - a comprehensive cloud platform

With Azure, you can develop, test, deploy and manage your applications in an integrated cloud computing environment. With the Azure Portal, you can manage the cloud infrastructure for your applications. Azure gives you the choice of a portal for managing services or managing them programmatically using service APIs and templates.

With over 200 services, knowing which one to use can be confusing. Deciding where to host your application is the first step. This series of articles covers the most commonly used Azure services such as virtual machines, serverless functions, static websites, Kubernetes, and Azure App Service. In addition, we’ll cover how to deploy applications using Azure DevOps.

In this article, we’ll match use cases to cloud services to help you navigate Azure.

Azure Virtual Machines

A common cloud migration path is to use virtual machines if you have existing infrastructure or on-premise applications. It is especially true if you want complete control over the infrastructure and application environment.

Azure provides Infrastructure as a Service (IaaS) for deploying your applications on either Linux or Windows VMs. IaaS includes all necessary support, such as Azure Virtual Network and storage. As with any IaaS solution, you are responsible for the installation of software, configuration, and maintenance of your application and any maintenance the VM might require, such as operating system patches.

If your application doesn’t fit into a Platform as a Service (PaaS) model, consider using virtual machines to provide the fine-grained control required for your deployment.

Serverless

At the opposite end of cloud infrastructure is serverless computing. Serverless eliminates the need to manage infrastructure and lets you focus on writing and deploying code. Azure automatically provisions, scales, and manages the infrastructure. You can write code that runs in response to events or on a schedule.

Azure Functions lets you focus on the application’s business logic, and the code executes when called by a webhook, an HTTP or REST request, a schedule, or an event. Serverless is particularly appealing because you can use the development language of your choice, ranging from PHP, Python, Node.js, or .NET languages. Azure functions scale as needed, and consumption-based pricing means that you’re charged only when the code runs.

If you don’t need a completely hosted project and only pay for what you use, choose Azure Functions triggered by web-based events, a schedule, or other Azure services.

Static websites

Static websites are quickly becoming the defacto way to publish content. Built from libraries and frameworks that don’t use server side rendering like React, Angular, or Vue, they include HTML, CSS, image assets, and Javascript in the application. Instead of serving assets from a server or servers scaled horizontally, the static assets are distributed through a Content Delivery Network (CDN). This reduces latency, resulting in faster websites and increased customer satisfaction.

Azure provides two ways to deploy static websites. Azure lets you deploy a static web application with Azure App Service and the recently released Azure Static Web Apps. Azure App Service deploys websites by uploading the website to Azure storage configured to serve web content. Azure App Service automatically builds and deploys full stack web apps to Azure from a code repository, which follows the Jamstack model for developing and deploying websites.

We’ll look at both methods and discuss the pros and cons of both methods.

Kubernetes

Kubernetes is the leading container orchestration service. Azure Kubernetes Service (AKS) is a hosted service that can deploy, scale, and manage containerized applications in a cluster. AKS fulfills many different use cases, for example:

If you have an existing application, think n-tier applications, you can containerize the components and “lift and shift” your application to run in Kubernetes.
You can deploy microservices on AKS to add horizontal scaling, load balancing, secrets management, and self-healing.
Data scientists are training machine learning models on AKS using TensorFlow and Kubeflow.
You can even use AKS as part of a build pipeline by pairing with a CI, such as Jenkins, to build containers for your application.

AKS supports many use cases by providing provisioning, scaling, and resource upgrades without requiring expertise in container orchestration. With AKS, the Kubernetes master nodes are managed by Azure, and you are only charged for the worker nodes in your cluster.

We’ll do two separate deep dives into deploying AKS clusters and deploying applications in AKS in this series.

Deploy AKS

Azure provides many ways to deploy an AKS cluster, including:

When you deploy an AKS Cluster, the worker nodes and Kubernetes master are configured with a basic configuration. You can additionally configure networking, storage, monitoring, and policies. We’ll cover configuring AKS in this series.

Deploy Applications

Deploying applications on AKS is equally flexible, and you can deploy using:

kubectl and YAML manifests
Helm, an open-source Kubernetes packaging tool
Azure Pipelines Infrastructure as Code

We’ll examine these options and do a deep dive on application deployment in a follow-up article.

DevOps integration

Before Continuous integration (CI) and Continuous Deployment (CD) became prevalent, applications were manually built, compiled, and maintained in a large codebase. CI/CD automation lets you build quickly, test, and deploy services. Both application fixes and new features are shipped quickly to your customers, and you can rapidly respond to changing customer demands. For example, if demand increases, you can quickly add resources to your application or add a serverless function that increases and decreases resources as needed.

If you’re deploying applications on Azure Functions, virtual machines, AKS, or provisioning infrastructure, the build process should be automated. Azure offers a range of services such as Azure Container Registry, AKS, and Azure Cosmos DB that can integrate with popular CI/CD pipelines like Azure DevOps, Jenkins, Github, and TeamCity.

If you’re interested in using Azure DevOps to automate infrastructure and application delivery, stay tuned!

Let’s Get Started!

So here are the top 5 things essential to know as an Azure developer:

configuring and deploying virtual machines
developing and deploying Azure Functions
deploying static websites on Azure
configuring Azure Kubernetes Service and deploying containerized applications
using Azure DevOps to automate the building and deployment of infrastructure and applications

First up and next in this series of articles is deploying Azure virtual machines with an application.