Pulumi Blog: Azure

Best Infrastructure as Code (IaC) Tools for 2026

Asaf Ashirov — Sun, 05 Jul 2026 00:00:00 +0000

Infrastructure as Code (IaC) has evolved beyond simple automation into a fundamental shift toward applying software engineering practices to infrastructure management. In 2026, leading organizations aren’t just provisioning infrastructure—they’re treating it as software, complete with testing, version control, code reviews, and continuous integration.

As infrastructure complexity grows, teams increasingly seek approaches that provide the same developer productivity tools they use for application development. While template-based and domain-specific language approaches serve many use cases effectively, teams with complex requirements or programming backgrounds often find that general-purpose programming languages offer advantages in testing, abstraction, and collaboration.

This comprehensive guide examines the most effective infrastructure as code tools available today, providing detailed analysis of core IaC platforms, complementary tools, and related technologies through the lens of software engineering best practices. Whether you’re starting fresh with IaC or evaluating alternatives to overcome limitations in your current toolchain, we’ll help you navigate this complex landscape and choose solutions that truly bring software engineering to infrastructure.

Ready to try one of these approaches yourself? Get started with Pulumi for free and provision your first resource in minutes, or see Pulumi Neo in action to explore how an AI agent can manage infrastructure changes alongside your team.

What is Infrastructure as Code?

Infrastructure as Code (IaC) is an approach to automating the provisioning and management of infrastructure using software engineering principles, approaches, and tools. Rather than manually configuring servers, networks, and cloud resources through user interfaces or command-line tools, IaC enables you to define your entire infrastructure declaratively through code.

This approach brings the same benefits that have revolutionized software development—version control, automated testing, code reviews, and CI/CD pipelines—to infrastructure management.

What Are Infrastructure as Code Tools?

Infrastructure as Code tools are platforms and frameworks that enable you to define, provision, and manage infrastructure resources through code rather than manual processes. These tools translate your infrastructure definitions into API calls that create, modify, or destroy cloud resources across various providers.

The most effective IaC tools share several key characteristics:

Goal-state focus: Define your desired infrastructure outcome, whether through declarative syntax (like YAML/JSON templates) or imperative languages that express declarative intent
Multi-cloud support: Work across different cloud providers and services
State management: Track the current state of your infrastructure
Preview capabilities: Show what changes will be made before applying them
Idempotency: Safe to run multiple times with consistent results

Why Infrastructure as Code Tools Are Essential

The shift to IaC tools addresses fundamental challenges that manual infrastructure management cannot solve at scale:

Accelerates Deployment Velocity: Teams can provision complex multi-cloud architectures in minutes instead of weeks. This speed enables faster time-to-market and more frequent, reliable deployments.

Enables True Collaboration: Infrastructure becomes code that teams can review, test, and approve together. This collaborative approach reduces errors and ensures knowledge sharing across the organization.

Eliminates Configuration Drift: Manual changes lead to inconsistencies between environments. IaC ensures your production, staging, and development environments remain identical, eliminating the notorious “works on my machine” syndrome for infrastructure.

Provides Cost Control: Automated provisioning and deprovisioning prevents resource sprawl. Teams can easily track infrastructure costs, set budget alerts, and optimize resource usage across environments.

Ensures Compliance and Security: Codified security policies and compliance requirements are automatically enforced across all deployments. Audit trails become automatic, and policy violations are caught before deployment.

Guarantees Business Continuity: Complete infrastructure definitions stored in version control enable rapid disaster recovery. Organizations can reconstruct entire environments from code, minimizing downtime and data loss.

Infrastructure as Code Tools Overview

This guide covers the following infrastructure as code tools and platforms:

10 Most Used IaC Tools in 2026

Pulumi IaC - Modern IaC with general-purpose programming languages
Terraform - BSL-licensed IaC from HashiCorp that uses the HCL domain-specific language
AWS CDK - Cloud Development Kit for AWS
AWS CloudFormation - Native AWS integration
Azure Resource Manager (ARM) - Native Azure JSON templates
Azure Bicep - Azure-native domain-specific language that compiles to ARM
Google Cloud Infrastructure Manager - Terraform-based solution for Google Cloud
Kubernetes YAML - Native Kubernetes resource definitions
Crossplane - Kubernetes as universal control plane
OpenTofu - Open-source Terraform alternative

Configuration Management Tools

Chef - Configuration management and compliance automation
Puppet - Configuration management and compliance automation
Salt - Configuration management and remote execution

Application and Platform Management Tools

Kubernetes - Container orchestration platform

Security and Compliance Tools

Pulumi ESC - Configuration and secrets management platform
Pulumi Insights - Cloud resource search, analytics, and compliance platform
Snyk - Developer security platform with IaC scanning
Wiz - Comprehensive cloud security platform
HashiCorp Sentinel - Policy-as-code framework for Terraform
Checkov - Static analysis for IaC security
TFLint - Terraform linting and validation

Infrastructure Automation and Management Platforms

Pulumi Cloud - Managed service for Pulumi IaC with enterprise features
HashiCorp Cloud Platform - Enterprise SaaS platform for Terraform management and automation
Spacelift - Automation platform for IaC workflows (not an IaC tool itself)
Env0 - Governance and automation platform for existing IaC tools

Core Infrastructure as Code Tools

Here’s how the core IaC tools compare at a glance before we go deep on each one:

Tool	Language / approach	Clouds supported	State management	Best for
Pulumi	Python, TypeScript, Go, C#, Java, or YAML	AWS, Azure, Google Cloud, Kubernetes, and 150+ other providers	Pulumi Cloud (managed, free tier available) or self-managed backend	Teams who want flexible, language-agnostic IaC for infrastructure and operations
Terraform	HCL (HashiCorp’s DSL)	AWS, Azure, Google Cloud, and hundreds of community providers	State file, self-managed or via HCP Terraform	Teams with existing Terraform expertise and established workflows
AWS CDK	TypeScript, Python, Java, C#, Go (compiles to CloudFormation)	AWS only	Delegated to the underlying CloudFormation stack	AWS-focused teams who prefer programming languages over templates
AWS CloudFormation	JSON/YAML templates	AWS only	Managed entirely by AWS	AWS-only deployments requiring deep service integration
Azure ARM	JSON templates	Azure only	Managed entirely by Azure	Azure-native deployments requiring comprehensive platform integration
Azure Bicep	Bicep DSL (compiles to ARM JSON)	Azure only	Managed entirely by Azure (via ARM)	Azure deployments requiring improved readability and developer experience
Google Cloud Infrastructure Manager	HCL (Terraform-based)	Google Cloud	Terraform state, managed by Google	Google Cloud Platform deployments using Terraform
Kubernetes YAML	YAML manifests	Any Kubernetes cluster	Kubernetes cluster state (etcd)	Teams managing container-native applications and cloud-native infrastructure
Crossplane	YAML / Kubernetes CRDs	Multi-cloud, orchestrated through Kubernetes	Kubernetes cluster state (etcd)	Kubernetes-first organizations managing multi-cloud infrastructure
OpenTofu	HCL (community-governed Terraform fork)	AWS, Azure, Google Cloud, and the Terraform provider ecosystem	State file, self-managed or via compatible remote backends	Teams seeking an open-source Terraform alternative with community governance

Use the table as a map: each tool links to its full breakdown below, where you’ll find licensing, key features, and the tradeoffs behind each “best for.”

1. Pulumi

License: Apache 2.0
Best For: Teams who want flexible, language-agnostic IaC for infrastructure and operations

Pulumi IaC represents a modern approach to infrastructure as code, fundamentally changing how teams approach infrastructure by enabling the use of general-purpose programming languages like Python, TypeScript, Go, C#, and Java, plus YAML for simpler configurations. Unlike tools that force teams to learn proprietary domain-specific languages (DSLs), Pulumi leverages familiar languages and software engineering practices, providing unprecedented flexibility, powerful abstractions, and seamless integration with existing development workflows.

Pulumi’s approach combines the best of both imperative and declarative paradigms: you use imperative programming languages to define your desired infrastructure state, but the Pulumi engine processes this declaratively to determine what changes are needed to achieve your intended outcome.

Key Features:

Universal language support: Use Python, TypeScript, Go, C#, Java, or YAML configurations—no new DSL to learn
Any cloud, any architecture: Deploy to AWS, Azure, Google Cloud, Kubernetes, and 150+ other providers
Real programming constructs: Leverage loops, conditionals, functions, classes, packages, and third-party libraries
Superior developer experience: Full IDE support with IntelliSense, debugging, and refactoring
Built-in testing: Unit and integration testing for infrastructure code
Policy as Code: Enforce compliance and security policies with CrossGuard
Component ecosystem: Rich library of reusable infrastructure components

Universal Language Code Examples:

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx";

// Create a VPC with automatic subnets
const vpc = new awsx.ec2.Vpc("main-vpc", {
 cidrBlock: "10.0.0.0/16",
 numberOfAvailabilityZones: 2,
});

// Create an ECS cluster
const cluster = new aws.ecs.Cluster("app-cluster");

// Create an Application Load Balancer
const alb = new awsx.elasticloadbalancingv2.ApplicationLoadBalancer("app-alb", {
 vpcId: vpc.vpcId,
 subnetIds: vpc.publicSubnetIds,
});

// Deploy a containerized application
const service = new awsx.ecs.FargateService("app-service", {
 cluster: cluster.arn,
 taskDefinitionArgs: {
 container: {
 image: "nginx:latest",
 memory: 128,
 ports: [{
 containerPort: 80,
 targetGroup: alb.defaultTargetGroup,
 }],
 },
 },
});

export const vpcId = vpc.vpcId;
export const serviceUrl = alb.loadBalancer.dnsName;

import pulumi
import pulumi_aws as aws
import pulumi_awsx as awsx

# Create a VPC with automatic subnets
vpc = awsx.ec2.Vpc("main-vpc",
 cidr_block="10.0.0.0/16",
 number_of_availability_zones=2)

# Create an ECS cluster
cluster = aws.ecs.Cluster("app-cluster")

# Create an Application Load Balancer
alb = awsx.elasticloadbalancingv2.ApplicationLoadBalancer("app-alb",
 vpc_id=vpc.vpc_id,
 subnet_ids=vpc.public_subnet_ids)

# Deploy a containerized application
service = awsx.ecs.FargateService("app-service",
 cluster=cluster.arn,
 task_definition_args=awsx.ecs.FargateServiceTaskDefinitionArgs(
 container=awsx.ecs.TaskDefinitionContainerDefinitionArgs(
 image="nginx:latest",
 memory=128,
 ports=[awsx.ecs.TaskDefinitionPortMappingArgs(
 container_port=80,
 target_group=alb.default_target_group
 )]
 )
 ))

pulumi.export("vpc_id", vpc.vpc_id)
pulumi.export("service_url", alb.load_balancer.dns_name)

package main

import (
 "github.com/pulumi/pulumi-aws/sdk/v6/go/aws/ecs"
 "github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/ec2"
 "github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/elasticloadbalancingv2"
 awsxecs "github.com/pulumi/pulumi-awsx/sdk/v2/go/awsx/ecs"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 // Create a VPC with automatic subnets
 vpc, err := ec2.NewVpc(ctx, "main-vpc", &ec2.VpcArgs{
 CidrBlock: pulumi.String("10.0.0.0/16"),
 NumberOfAvailabilityZones: pulumi.Int(2),
 })
 if err != nil {
 return err
 }

 // Create an ECS cluster
 cluster, err := ecs.NewCluster(ctx, "app-cluster", nil)
 if err != nil {
 return err
 }

 // Create an Application Load Balancer
 alb, err := elasticloadbalancingv2.NewApplicationLoadBalancer(ctx, "app-alb", &elasticloadbalancingv2.ApplicationLoadBalancerArgs{
 VpcId: vpc.VpcId,
 SubnetIds: vpc.PublicSubnetIds,
 })
 if err != nil {
 return err
 }

 // Deploy a containerized application
 _, err = awsxecs.NewFargateService(ctx, "app-service", &awsxecs.FargateServiceArgs{
 Cluster: cluster.Arn,
 TaskDefinitionArgs: &awsxecs.FargateServiceTaskDefinitionArgs{
 Container: &awsxecs.TaskDefinitionContainerDefinitionArgs{
 Image: pulumi.String("nginx:latest"),
 Memory: pulumi.Int(128),
 Ports: awsxecs.TaskDefinitionPortMappingArray{
 &awsxecs.TaskDefinitionPortMappingArgs{
 ContainerPort: pulumi.Int(80),
 TargetGroup: alb.DefaultTargetGroup,
 },
 },
 },
 },
 })
 if err != nil {
 return err
 }

 ctx.Export("vpcId", vpc.VpcId)
 ctx.Export("serviceUrl", alb.LoadBalancer.DnsName())
 return nil
 })
}

using System.Collections.Generic;
using Pulumi;
using Aws = Pulumi.Aws;
using Awsx = Pulumi.Awsx;

return await Deployment.RunAsync(() =>
{
 // Create a VPC with automatic subnets
 var vpc = new Awsx.Ec2.Vpc("main-vpc", new()
 {
 CidrBlock = "10.0.0.0/16",
 NumberOfAvailabilityZones = 2,
 });

 // Create an ECS cluster
 var cluster = new Aws.Ecs.Cluster("app-cluster");

 // Create an Application Load Balancer
 var alb = new Awsx.ElasticLoadBalancingV2.ApplicationLoadBalancer("app-alb", new()
 {
 VpcId = vpc.VpcId,
 SubnetIds = vpc.PublicSubnetIds,
 });

 // Deploy a containerized application
 var service = new Awsx.Ecs.FargateService("app-service", new()
 {
 Cluster = cluster.Arn,
 TaskDefinitionArgs = new Awsx.Ecs.Inputs.FargateServiceTaskDefinitionArgs
 {
 Container = new Awsx.Ecs.Inputs.TaskDefinitionContainerDefinitionArgs
 {
 Image = "nginx:latest",
 Memory = 128,
 Ports = new[]
 {
 new Awsx.Ecs.Inputs.TaskDefinitionPortMappingArgs
 {
 ContainerPort = 80,
 TargetGroup = alb.DefaultTargetGroup,
 },
 },
 },
 },
 });

 return new Dictionary<string, object?>
 {
 ["vpcId"] = vpc.VpcId,
 ["serviceUrl"] = alb.LoadBalancer.Apply(lb => lb.DnsName),
 };
});

name: aws-ecs-example
runtime: yaml
description: An example that deploys an ECS Fargate service with load balancer

resources:
 # Create a VPC with automatic subnets
 main-vpc:
 type: awsx:ec2:Vpc
 properties:
 cidrBlock: "10.0.0.0/16"
 numberOfAvailabilityZones: 2

 # Create an ECS cluster
 app-cluster:
 type: aws:ecs:Cluster

 # Create an Application Load Balancer
 app-alb:
 type: awsx:elasticloadbalancingv2:ApplicationLoadBalancer
 properties:
 vpcId: ${main-vpc.vpcId}
 subnetIds: ${main-vpc.publicSubnetIds}

 # Deploy a containerized application
 app-service:
 type: awsx:ecs:FargateService
 properties:
 cluster: ${app-cluster.arn}
 taskDefinitionArgs:
 container:
 image: "nginx:latest"
 memory: 128
 ports:
 - containerPort: 80
 targetGroup: ${app-alb.defaultTargetGroup}

outputs:
 vpcId: ${main-vpc.vpcId}
 serviceUrl: ${app-alb.loadBalancer.dnsName}

Key Features:

General-purpose language support: Use Python, TypeScript, Go, C#, Java, or YAML without learning new DSLs
Software engineering practices: Full IDE support, comprehensive testing frameworks, debugging capabilities
Multi-cloud flexibility: Native cloud provider SDKs with same-day feature access across 150+ providers
Incremental adoption: Migration tools and state integration for gradual transitions
Open source licensing: Apache 2.0 ensures long-term freedom and flexibility

Considerations:

Learning curve: Teams new to programming may prefer template-based approaches initially
Ecosystem maturity: Smaller community compared to more established tools like Terraform
Tool complexity: Advanced features may require more setup than simpler template systems

Organizations like Unity, Snowflake, and Starburst have reported significant productivity improvements (80-90% deployment time reductions) when adopting programming language-based approaches. These improvements typically occur when transitioning from manual processes or basic template systems to automated approaches with comprehensive testing, IDE integration, and code reusability. Results vary based on starting point, team expertise, infrastructure complexity, and specific use cases.

Ready to get started? Experience Pulumi’s programming language approach and see how familiar languages can transform your infrastructure management with comprehensive testing, powerful abstractions, and seamless multi-cloud support.

2. Terraform

License: Business Source License (BSL) 1.1 (Not Open Source)
Best For: Teams with existing Terraform expertise and established workflows

Terraform uses HashiCorp Configuration Language (HCL) to define infrastructure across multiple cloud providers. However, its 2023 licensing change to BSL (no longer open source) and inherent limitations with domain-specific languages create challenges for teams requiring advanced software engineering practices.

Key Features:

Extensive provider ecosystem: Largest collection of community-maintained providers covering virtually every cloud service
Established workflows: Mature plan-and-apply process with extensive tooling and CI/CD integrations
Community and resources: Vast ecosystem of modules, extensive documentation, training materials, and community support
Enterprise adoption: Widely adopted in enterprises with established processes and expertise
Module ecosystem: Rich collection of reusable Terraform modules for common patterns

When Terraform Works Well:

Teams with existing HCL expertise and Terraform investments
Infrastructure patterns that fit well within HCL’s declarative model
Teams comfortable with template-based approaches

Considerations for Complex Scenarios:

Language constraints: HCL’s domain-specific nature can require workarounds for complex logic compared to general-purpose programming languages
Testing approach: Primarily supports integration testing; teams needing comprehensive unit testing may require additional tooling
IDE experience: While improving, HCL tooling provides less comprehensive support than mature programming language ecosystems
State management: Requires manual backend configuration and locking setup for team collaboration

Code Example:

data "aws_availability_zones" "available" {}

resource "aws_vpc" "main" {
 cidr_block = "10.0.0.0/16"

 tags = {
 Name = "main-vpc"
 }
}

resource "aws_subnet" "public" {
 count = 2
 vpc_id = aws_vpc.main.id
 cidr_block = "10.0.${count.index + 1}.0/24"
 availability_zone = data.aws_availability_zones.available.names[count.index]

 tags = {
 Name = "public-subnet-${count.index + 1}"
 }
}

3. AWS Cloud Development Kit (CDK)

License: Apache 2.0
Best For: AWS-focused teams who prefer programming languages over templates

AWS CDK allows you to define AWS infrastructure using familiar programming languages, synthesizing CloudFormation templates for deployment while providing higher-level abstractions. CDK addresses many limitations of traditional template-based approaches by enabling general-purpose programming languages.

Key Features:

General-purpose programming languages: TypeScript, Python, Java, C#, JavaScript support with full IDE integration (Go available in Developer Preview)
AWS-optimized constructs: High-level components encapsulating AWS best practices
Type safety: Compile-time checking and IntelliSense support
CloudFormation reliability: Built on AWS’s proven deployment engine

Notable Limitations:

AWS-only ecosystem: Locked into single cloud provider, limiting multi-cloud strategies
CloudFormation constraints: Inherits template size limits and deployment restrictions
Vendor lock-in: Deep AWS integration makes migration to other clouds challenging
Limited cross-cloud consistency: Teams need different tools and approaches for multi-cloud deployments

CDK represents a significant improvement over CloudFormation templates but constrains organizations to AWS-only infrastructure strategies.

Code Example:

import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import { Construct } from 'constructs';

export class MyStack extends cdk.Stack {
 constructor(scope: Construct, id: string, props?: cdk.StackProps) {
 super(scope, id, props);

 const vpc = new ec2.Vpc(this, 'MyVpc', {
 maxAzs: 2
 });

 const cluster = new ecs.Cluster(this, 'MyCluster', {
 vpc: vpc
 });

 const taskDefinition = new ecs.FargateTaskDefinition(this, 'TaskDef', {
 memoryLimitMiB: 512,
 cpu: 256
 });

 taskDefinition.addContainer('web', {
 image: ecs.ContainerImage.fromRegistry('nginx:latest'),
 portMappings: [{ containerPort: 80 }]
 });

 new ecs.FargateService(this, 'MyService', {
 cluster: cluster,
 taskDefinition: taskDefinition
 });
 }
}

4. AWS CloudFormation

License: Proprietary (AWS Service)
Best For: AWS-only deployments requiring deep service integration

AWS CloudFormation provides the foundation for infrastructure as code on AWS, offering native integration with all AWS services and deep platform-specific features.

Pulumi Integration: Pulumi provides native AWS providers that offer the same comprehensive AWS service coverage as CloudFormation, with the added benefit of using general-purpose programming languages. You can also import existing CloudFormation stacks into Pulumi for gradual migration or hybrid management approaches.

Key Features:

AWS-native: First-party support for all AWS services
JSON/YAML templates: Declarative resource definitions
Stack management: Organized resource grouping and lifecycle management
Change sets: Preview infrastructure changes before deployment
Service integration: Deep integration with other AWS services

Code Example:

AWSTemplateFormatVersion: '2010-09-09'
Resources:
 MyVPC:
 Type: AWS::EC2::VPC
 Properties:
 CidrBlock: 10.0.0.0/16
 EnableDnsHostnames: true
 Tags:
 - Key: Name
 Value: MyVPC

 MySubnet:
 Type: AWS::EC2::Subnet
 Properties:
 VpcId: !Ref MyVPC
 CidrBlock: 10.0.1.0/24
 AvailabilityZone: !Select [0, !GetAZs '']

5. Azure Resource Manager (ARM)

License: Proprietary (Microsoft Service)
Best For: Azure-native deployments requiring comprehensive platform integration

Azure Resource Manager provides the foundational infrastructure as code solution for Microsoft Azure, offering complete support for Azure services through JSON-based ARM templates. As Azure’s native IaC solution, ARM templates provide the most comprehensive coverage of Azure services and features.

Pulumi Integration: Pulumi’s native Azure providers offer equivalent comprehensive Azure service coverage with general-purpose programming languages. ARM templates can be imported into Pulumi, and you can reference ARM deployments from Pulumi programs for hybrid scenarios.

Key Features:

Azure-native: Complete Azure service coverage with first-party support
JSON templates: Declarative resource definitions in JSON format
Resource groups: Logical organization of related resources
Deployment modes: Complete or incremental deployment options
Comprehensive integration: Deep integration with Azure services and features

Code Example:

{
 "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
 "resources": [
 {
 "type": "Microsoft.Storage/storageAccounts",
 "apiVersion": "2023-01-01",
 "name": "mystorageaccount",
 "location": "[resourceGroup().location]",
 "sku": {
 "name": "Standard_LRS"
 },
 "kind": "StorageV2"
 }
 ]
}

6. Azure Bicep

License: MIT
Best For: Azure deployments requiring improved readability and developer experience

Azure Bicep is a domain-specific language (DSL) that simplifies Azure Resource Manager template authoring. Bicep files compile transparently to ARM templates, providing all the capabilities of ARM with significantly improved syntax and developer experience.

Key Features:

Simplified syntax: Clean, readable syntax compared to JSON ARM templates
ARM compilation: Compiles to ARM templates for deployment, ensuring full compatibility
Type safety: Strong typing and IntelliSense support in development environments
Modular design: Support for modules and code reuse across projects
Azure-native: Complete Azure service coverage through ARM template compilation

Code Example:

@description('Storage Account type')
@allowed([
 'Standard_LRS'
 'Standard_GRS'
 'Standard_ZRS'
 'Premium_LRS'
])
param storageAccountType string = 'Standard_LRS'

@description('Location for the storage account.')
param location string = resourceGroup().location

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
 name: 'mystorageaccount'
 location: location
 sku: {
 name: storageAccountType
 }
 kind: 'StorageV2'
 properties: {}
}

7. Google Cloud Infrastructure Manager

License: Proprietary (Google Service)
Best For: Google Cloud Platform deployments using Terraform

Google Cloud Infrastructure Manager automates the deployment and management of Google Cloud infrastructure resources using Terraform configurations, representing Google’s modern approach to infrastructure as code. Infrastructure Manager replaces Google Cloud Deployment Manager, which reached end of support on December 31, 2025.

Key Features:

Terraform-based: Uses standard Terraform configurations declaratively
Automated workflows: Handles Terraform init, validate, and apply operations
Version control integration: Supports Git repositories and Cloud Storage
Deployment tracking: Comprehensive metadata storage and logging
Multiple Terraform versions: Flexibility in Terraform version selection
Cloud Build integration: Leverages Google Cloud Build for execution environment
Migration path: Provides upgrade path from legacy Cloud Deployment Manager

Code Example:

# main.tf - Terraform configuration for Infrastructure Manager
resource "google_compute_instance" "vm_instance" {
 name = "my-vm"
 machine_type = "e2-medium"
 zone = "us-central1-a"

 boot_disk {
 initialize_params {
 image = "debian-cloud/debian-11"
 }
 }

 network_interface {
 network = "default"
 access_config {
 // Ephemeral public IP
 }
 }

 metadata = {
 startup-script = "echo Hello from Infrastructure Manager!"
 }
}

output "instance_ip" {
 value = google_compute_instance.vm_instance.network_interface[0].access_config[0].nat_ip
}

8. Kubernetes YAML

License: Apache 2.0
Best For: Teams managing container-native applications and cloud-native infrastructure

Kubernetes YAML manifests represent one of the most widely adopted forms of infrastructure as code, enabling teams to define, version, and manage containerized applications and their supporting infrastructure through declarative configuration files.

Key Features:

Declarative configuration: Define desired state through human-readable YAML files
Native Kubernetes integration: Direct integration with Kubernetes API without additional tools
GitOps compatibility: Version control YAML files for automated deployment workflows
Resource relationships: Define dependencies and relationships between Kubernetes resources
Extensive ecosystem: Rich ecosystem of operators and custom resources extending functionality

Code Example:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: web-app
 labels:
 app: web-app
spec:
 replicas: 3
 selector:
 matchLabels:
 app: web-app
 template:
 metadata:
 labels:
 app: web-app
 spec:
 containers:
 - name: web-app
 image: nginx:1.21
 ports:
 - containerPort: 80
 resources:
 requests:
 memory: "64Mi"
 cpu: "250m"
 limits:
 memory: "128Mi"
 cpu: "500m"
---
apiVersion: v1
kind: Service
metadata:
 name: web-app-service
spec:
 selector:
 app: web-app
 ports:
 - port: 80
 targetPort: 80
 type: LoadBalancer

9. Crossplane

License: Apache 2.0
Best For: Kubernetes-first organizations managing multi-cloud infrastructure

Crossplane is a Cloud-Native Framework for Platform Engineering that extends Kubernetes to help organizations build custom infrastructure management platforms, allowing teams to provision and manage cloud resources using Kubernetes APIs and patterns.

Pulumi Integration: Pulumi offers the Pulumi Kubernetes Operator (PKO) that provides similar Kubernetes-native infrastructure management capabilities, plus support for YAML-based definitions. Teams can also use Pulumi programs to provision the underlying infrastructure that Crossplane manages, creating layered infrastructure management approaches.

Key Features:

Kubernetes-native: Uses CRDs and standard Kubernetes patterns
Composite resources: Create higher-level infrastructure abstractions
GitOps compatibility: Seamless integration with GitOps workflows
Multi-cloud support: Provision resources across cloud providers
Policy integration: Leverage Kubernetes RBAC and admission controllers

Code Example:

apiVersion: ec2.aws.crossplane.io/v1alpha1
kind: VPC
metadata:
 name: sample-vpc
spec:
 cidrBlock: 10.0.0.0/16
 region: us-east-1
 tags:
 Name: sample-vpc
 providerConfigRef:
 name: aws-provider-config

10. OpenTofu

License: Mozilla Public License 2.0
Best For: Teams seeking an open-source Terraform alternative with community governance

OpenTofu emerged as a fork of Terraform v1.5.x following HashiCorp’s license change, maintained by the Linux Foundation. It provides high, but not full, compatibility with Terraform while ensuring long-term open-source availability under MPL 2.0 licensing.

Key Features:

True open source: MPL 2.0 license with community governance via Linux Foundation ensuring long-term accessibility
Terraform compatibility: Largely maintains existing workflows, modules, and provider ecosystem, with some divergence emerging as the projects evolve independently
Community-driven development: Transparent roadmap, open contribution process, and vendor-neutral governance
License certainty: Removes concerns about future licensing restrictions for commercial use

When OpenTofu Makes Sense:

Organizations requiring guaranteed open-source licensing for compliance or philosophical reasons
Teams with significant Terraform investments wanting to avoid vendor lock-in
Environments where community governance and transparency are priorities
Projects needing long-term license stability

Architectural Considerations: As a Terraform fork, OpenTofu inherits the same architectural approach, which means teams evaluating it should consider whether HCL-based infrastructure definition meets their long-term needs for testing, IDE integration, and developer productivity, or whether a programming language-based approach might better serve complex scenarios.

Code Example:

resource "aws_instance" "web" {
 ami = "ami-0c55b159cbfafe1d0"
 instance_type = "t3.micro"

 tags = {
 Name = "HelloWorld"
 }
}

output "instance_ip" {
 value = aws_instance.web.public_ip
}

Ansible

License: GPL v3
Best For: Configuration management with some infrastructure provisioning capabilities

Ansible is primarily a configuration management tool, not a pure Infrastructure as Code tool. While Ansible can provision some cloud resources, its core strength lies in configuring and managing software on existing systems rather than comprehensive infrastructure provisioning.

Ansible provides configuration management and limited infrastructure provisioning through its agentless architecture and simple YAML-based playbooks.

Pulumi Integration: Rather than competing with Ansible, Pulumi complements it perfectly. Use Pulumi for infrastructure provisioning and Ansible for configuration management. Pulumi’s Command provider can execute Ansible playbooks as part of your infrastructure deployment, and many Pulumi customers use both tools together for comprehensive infrastructure automation. See example: Deploy WordPress to AWS using Pulumi and Ansible.

Key Features:

Agentless architecture: No software installation required on target systems
YAML playbooks: Human-readable automation definitions
Idempotent operations: Safe to run multiple times
Large module library: Extensive built-in functionality for various systems
Push-based execution: Centralized control and execution

Code Example:

---
- name: Provision AWS infrastructure
 hosts: localhost
 tasks:
 - name: Create VPC
 amazon.aws.ec2_vpc_net:
 name: ansible-vpc
 cidr_block: 10.0.0.0/16
 region: us-east-1
 tags:
 Environment: production
 register: vpc

 - name: Create subnet
 amazon.aws.ec2_vpc_subnet:
 vpc_id: "{{ vpc.vpc.id }}"
 cidr: 10.0.1.0/24
 region: us-east-1
 tags:
 Name: ansible-subnet

Chef

License: Apache 2.0
Best For: Complex configuration management scenarios requiring programmable logic

Chef is a configuration management tool, not an Infrastructure as Code tool. Chef focuses on configuring and maintaining software, services, and system settings on existing infrastructure rather than provisioning cloud resources.

Chef provides configuration management and system automation using Ruby-based recipes and cookbooks, offering powerful programmability for complex configuration scenarios.

Key Features:

Ruby DSL: Full programming language for configuration logic
Agent-based architecture: Continuous compliance and drift detection
Cookbook ecosystem: Reusable configuration patterns and community recipes
Test Kitchen: Infrastructure testing and validation framework
Enterprise features: Advanced reporting and compliance capabilities

Code Example:

# cookbook/recipes/default.rb
package 'nginx' do
 action :install
end

service 'nginx' do
 action [:enable, :start]
end

template '/etc/nginx/sites-available/default' do
 source 'default.erb'
 owner 'root'
 group 'root'
 mode '0644'
 notifies :restart, 'service[nginx]'
end

Puppet

License: Apache 2.0
Best For: Enterprise environments requiring strong governance and compliance

Puppet is primarily a configuration management tool, not a pure Infrastructure as Code tool. Puppet specializes in maintaining desired configuration state on existing systems and ensuring compliance, rather than provisioning cloud infrastructure.

Puppet offers enterprise-grade configuration management with a focus on compliance, governance, and declarative system state management.

Key Features:

Declarative language: Puppet DSL for describing desired system state
Compliance reporting: Built-in governance and audit capabilities
Forge marketplace: Community modules and enterprise content
Enterprise support: Professional services and enterprise features
Continuous enforcement: Ongoing configuration compliance monitoring

Code Example:

# manifests/webserver.pp
class webserver {
 package { 'nginx':
 ensure => installed,
 }

 service { 'nginx':
 ensure => running,
 enable => true,
 require => Package['nginx'],
 }

 file { '/var/www/html/index.html':
 ensure => file,
 content => '<h1>Hello from Puppet!</h1>',
 owner => 'www-data',
 group => 'www-data',
 mode => '0644',
 }
}

Salt

License: Apache 2.0
Best For: Python-oriented teams requiring high-performance configuration management

Salt is primarily a configuration management and remote execution tool, not a pure Infrastructure as Code tool. While Salt can manage some infrastructure components, its primary focus is on configuring systems and executing commands across large infrastructures.

Salt provides fast, scalable configuration management and remote execution using Python, designed for high-performance system automation at scale.

Key Features:

Python-based: Leverage the Python ecosystem and libraries
High performance: Fast execution across large infrastructures
Event-driven automation: Reactive automation and orchestration
Pillar data system: Secure, hierarchical data management
Flexible communication: Support for various communication patterns

Code Example:

# /srv/salt/webserver.sls
nginx:
 pkg.installed: []
 service.running:
 - enable: True
 - require:
 - pkg: nginx

/var/www/html/index.html:
 file.managed:
 - source: salt://files/index.html
 - user: www-data
 - group: www-data
 - mode: 644

Infrastructure as Code Tools

Kubernetes - Container Orchestration Platform

License: Apache 2.0
Best For: Container-native infrastructure and application management

While primarily a container orchestration platform, Kubernetes itself serves as an infrastructure as code tool through its declarative YAML manifests and API-driven resource management.

Key Features:

Declarative configuration: YAML-based resource definitions
API-driven: RESTful API for all resource operations
Self-healing: Automatic recovery and reconciliation
Extensible: Custom resources and controllers
GitOps compatible: Works seamlessly with Git-based workflows

Code Example:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
spec:
 replicas: 3
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: nginx
 image: nginx:1.21
 ports:
 - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
 name: nginx-service
spec:
 selector:
 app: nginx
 ports:
 - port: 80
 targetPort: 80
 type: LoadBalancer

Infrastructure as Code Security and Compliance Tools

While the tools above focus on provisioning and managing infrastructure, a complete IaC ecosystem includes security scanning and compliance tools. These tools complement your primary IaC tool by providing security analysis, policy enforcement, and compliance checking:

Security Scanning Tools

Snyk - License: Proprietary
Leading developer security platform that includes comprehensive infrastructure as code scanning alongside container and application security. Provides real-time vulnerability detection, compliance checking, and automated remediation guidance. Integrates with popular development tools and CI/CD pipelines with extensive enterprise adoption.

Wiz - License: Proprietary
Comprehensive cloud security platform that includes infrastructure as code scanning capabilities. Provides vulnerability management, compliance monitoring, and security posture assessment across cloud environments. Offers integration with development workflows and supports multiple IaC formats with strong enterprise presence.

Checkov - License: Apache 2.0
Popular open-source static analysis tool for infrastructure as code that scans cloud infrastructure configurations for security and compliance issues. Supports Terraform, CloudFormation, Kubernetes, Helm, ARM templates, and more. Integrates with CI/CD pipelines and provides over 1000+ built-in policies covering CIS benchmarks, PCI DSS, and GDPR compliance.

Linting and Validation Tools

TFLint - License: MPL 2.0
Terraform linter focused on possible errors, best practices, and security issues in Terraform configurations. Provides pluggable rule sets for cloud providers (AWS, Azure, GCP) and helps enforce coding standards, detect deprecated syntax, and prevent common configuration errors.

These security tools integrate into CI/CD pipelines alongside your chosen IaC tool to provide comprehensive security coverage throughout the infrastructure lifecycle.

Pulumi ESC

License: Apache 2.0 (Open Source) / Proprietary (SaaS)
Best For: Teams needing centralized configuration and secrets management across environments and tools

Pulumi ESC (Environments, Secrets, and Configuration) is a comprehensive platform for managing configuration data, secrets, and environment variables across your entire infrastructure and application stack. ESC provides a single source of truth for configuration that works with any infrastructure tool, not just Pulumi.

Key Features:

Universal configuration management: Works with any infrastructure tool, CI/CD system, or application
Hierarchical environments: Compose configuration from multiple sources with inheritance and overrides
Dynamic secrets: Integration with cloud providers for short-lived credentials and just-in-time access
Policy-based access control: Fine-grained permissions and audit logging for configuration access
Multiple consumption methods: CLI, REST API, SDK integration, and direct cloud provider integration
GitOps workflows: Version control integration with pull request-based configuration management

Code Example:

# Production environment configuration
values:
 app:
 name: myapp
 version: ${fn.fromJSON(aws.ecr.getAuthorizationToken).password}
 database:
 connectionString: ${pulumi.database.connectionString}
imports:
 - shared/common
 - aws/production

Pulumi Insights

License: Proprietary (SaaS)
Best For: Organizations needing comprehensive cloud resource visibility, search, and compliance monitoring

Pulumi Insights provides cloud resource search, analytics, and compliance capabilities across your entire multi-cloud infrastructure, regardless of how resources were provisioned. It offers a unified view of your cloud resources with powerful search, cost analysis, and policy enforcement.

Key Features:

Universal cloud inventory: Discover and catalog resources across AWS, Azure, Google Cloud, and Kubernetes
Advanced search and analytics: Query resources by tags, properties, relationships, and compliance status
Cost optimization insights: Resource cost analysis, trends, and optimization recommendations
Compliance monitoring: Continuous policy evaluation and drift detection across all cloud resources
Resource relationships: Understand dependencies and relationships between cloud resources
Integration with any IaC tool: Works with resources created by Pulumi, Terraform, CloudFormation, or manually

Use Cases:

Cloud governance: Ensure compliance with organizational policies and industry standards
Cost management: Identify unused resources and optimization opportunities
Security auditing: Track resource configurations and detect security misconfigurations
Multi-cloud visibility: Single pane of glass for resources across different cloud providers

Infrastructure Automation and Management Platforms

While the above tools focus on defining and provisioning infrastructure, several platforms provide automation, orchestration, and management capabilities that work with Infrastructure as Code tools. Important: These are not IaC tools themselves, but rather automation platforms that rely on underlying IaC tools.

IaC Automation Platforms

Pulumi Cloud Best For: Teams using Pulumi IaC who need enterprise-grade collaboration, security, and governance

Pulumi Cloud is the smartest and easiest way to automate, secure, and manage everything you run in the cloud. It serves as the managed service companion to Pulumi’s open-source infrastructure as code tool, providing enterprise capabilities that extend beyond basic IaC functionality.

The relationship between Pulumi IaC and Pulumi Cloud follows a Git/GitHub model: Pulumi IaC is like Git (fully open source and functional on its own), while Pulumi Cloud is like GitHub (a managed service that makes the open-source tool much easier to use securely at scale with teams).

Key Features:

Managed state backend: Secure, scalable state management with transactional protocols
Team collaboration: Full audit logs, RBAC, and identity provider integration
Centralized secrets management: Pulumi ESC for configuration and secrets across environments
Cloud inventory and insights: Pulumi Insights for search, compliance, and drift detection
Remote deployments: CI/CD integrations and automated workflows
Policy enforcement: Built-in security and compliance policy as code
Multi-product platform: Integrated IaC, secrets management, and cloud insights

Pulumi IaC works with or without Pulumi Cloud - you can use DIY backends (S3, Azure Blob, etc.) or the managed service. However, Pulumi Cloud becomes the default experience when you install the Pulumi CLI, providing instant collaboration capabilities without the overhead of building and maintaining your own infrastructure management platform.

HashiCorp Cloud Platform (HCP) - License: Proprietary (SaaS)
Best For: Organizations standardizing on HashiCorp tools across infrastructure and security lifecycle management

HashiCorp Cloud Platform (HCP) is an enterprise-grade SaaS platform that provides unified lifecycle management for infrastructure and security operations. HCP Terraform (formerly Terraform Cloud) serves as the managed service for Terraform/OpenTofu workflows, while the broader platform integrates multiple HashiCorp tools.

Key Features:

HCP Terraform management: Workspace organization, remote execution, and state management for Terraform
Infrastructure lifecycle automation: Continuous validation, drift detection, and module lifecycle management
Private VCS access: Secure integration with private version control repositories
Policy enforcement: Sentinel policy-as-code framework for compliance and governance
Integrated security services: HCP Vault for secrets management, HCP Consul for service networking
Enterprise access controls: RBAC, SAML SSO integration, and fine-grained permissions
Module and image management: HCP Packer for automated machine/container image creation

HCP focuses specifically on HashiCorp tool integration and provides a comprehensive platform for organizations that have standardized on the HashiCorp ecosystem for infrastructure and security operations.

Spacelift - Spacelift is not an Infrastructure as Code tool—it’s an automation and workflow platform that relies on other IaC tools like Terraform, OpenTofu, Pulumi, CloudFormation, and Kubernetes. Spacelift provides CI/CD pipelines, policy enforcement, and collaboration features for teams using these underlying IaC tools.

Env0 - Env0 is not an Infrastructure as Code tool—it’s an automation platform that provides workflow management, governance, and collaboration features for existing IaC tools like Terraform, OpenTofu, and Terragrunt. It adds CI/CD pipelines, cost management, and policy enforcement on top of these tools.

Atlantis - An open-source tool that provides GitOps-style workflows for Terraform and OpenTofu by automatically running terraform plan and apply operations via pull request automation.

Development Environment Tools

Vagrant - Vagrant is not an Infrastructure as Code tool—it’s a development environment management tool that creates and configures lightweight, reproducible virtual development environments. While it can provision VMs, its focus is on local development environments rather than cloud infrastructure provisioning.

Docker Compose - While not an IaC tool, Docker Compose defines multi-container applications and can be used alongside IaC tools for application deployment after infrastructure provisioning.

These platforms and tools serve important roles in the infrastructure automation ecosystem but should not be confused with Infrastructure as Code tools themselves. They enhance and orchestrate the work of actual IaC tools rather than replacing them.

The Future of Infrastructure as Code

The infrastructure as code landscape is rapidly evolving toward software engineering maturity, with several transformative trends reshaping how organizations approach infrastructure:

Software Engineering Convergence: The most significant trend is the convergence of infrastructure and software engineering practices. Organizations are moving away from limited DSLs toward full programming languages that enable testing, debugging, refactoring, and other software engineering best practices. This shift enables infrastructure teams to leverage the same tools, skills, and methodologies that have proven successful in application development.

Real-Time Cloud Integration: Native cloud provider SDK integration is becoming the standard, replacing community-maintained providers that lag behind new cloud features. Organizations expect same-day access to new cloud services without waiting weeks or months for provider updates.

Comprehensive Testing Paradigms: Infrastructure testing is evolving beyond basic integration tests to include unit testing, property-based testing, and continuous validation. Teams are applying test-driven development principles to infrastructure, catching issues before deployment rather than discovering them in production.

Internal Developer Platform Evolution: Organizations are building sophisticated Internal Developer Platforms that provide self-service infrastructure capabilities while maintaining governance and compliance. These platforms leverage infrastructure as code tools to create standardized, reusable components that accelerate development velocity.

AI-Enhanced Development: Integration of AI tools to help generate, optimize, and troubleshoot infrastructure code, with particular strength in environments that use familiar programming languages where AI assistance is most mature. Emerging technologies like Model Context Protocol (MCP) and AI prompt templates are beginning to enable more sophisticated AI-infrastructure interactions.

These trends favor tools that embrace software engineering principles from the ground up, rather than attempting to retrofit programming capabilities onto template-based or DSL-limited approaches.

Bring software engineering to IaC

Define infrastructure across AWS, Azure, Google Cloud, and Kubernetes in the language your team already knows, with testing, IDE support, and reusable components.

Get started

Migration and Adoption Strategies

Organizations don’t need to choose between maintaining existing infrastructure and adopting modern IaC approaches. Proven migration strategies enable gradual adoption while preserving operational stability.

Incremental Adoption Approaches

Team-by-Team Migration: Start with new projects or specific teams, allowing gradual skill development and process refinement. Teams can maintain existing infrastructure while building new capabilities with modern tools.

Project-by-Project Transition: Migrate individual applications or services incrementally, enabling teams to learn and optimize approaches before expanding scope.

Hybrid Operations: Use state integration and import tools to reference existing infrastructure while building new components with modern IaC tools.

Proven Migration Timelines

Real-world migrations demonstrate that adoption can be remarkably fast with proper tooling:

Atlassian Bitbucket: Complete Terraform to Pulumi migration in 2 days using automated conversion tools. This rapid migration was enabled by existing Python expertise on the team, well-structured Terraform code, and straightforward infrastructure patterns that converted cleanly.
Enterprise migrations: Typical team migrations complete in weeks, not months, depending on infrastructure complexity and team preparation
Learning curve: Teams with programming experience adapt to language-based IaC approaches within days, while those new to programming may require additional training time

Migration Tools and Resources

Automated Conversion: Tools like tf2pulumi and pulumi convert automatically translate existing infrastructure definitions, preserving logic and structure while upgrading to modern approaches.

State Integration: Import existing cloud resources and reference Terraform state during transition periods, enabling zero-downtime migrations.

Training and Support: Comprehensive documentation, tutorials, and community resources accelerate team onboarding and reduce migration risks.

Best Practices for Successful Adoption

Start with pilot projects to build confidence and establish patterns
Leverage automated migration tools to reduce manual conversion effort
Maintain state integration during transition periods for operational continuity
Invest in team training to maximize productivity gains from modern approaches
Establish testing practices early to realize reliability and quality benefits

The key insight: migration to modern IaC approaches is a technical upgrade, not a complete rebuild. Organizations can preserve existing investments while gaining access to superior tooling and practices.

Frequently Asked Questions

Which IaC tool should I choose for AWS?

For teams wanting programming languages: Pulumi IaC and AWS CDK both offer excellent developer experiences with general-purpose programming languages. Pulumi provides multi-cloud flexibility, while CDK offers deep AWS-native integration.

For AWS-only deployments: CloudFormation provides the deepest native AWS service support and direct integration with AWS services.

For Terraform ecosystem users: OpenTofu provides open-source licensing with Terraform compatibility, while Terraform offers extensive community resources and established workflows.

Is Terraform still worth learning in 2026?

Terraform remains a valuable skill and viable choice for many scenarios, though teams should consider their specific needs and long-term goals:

When Terraform Makes Sense:

Teams building on existing Terraform infrastructure and expertise
Organizations with successful Terraform workflows and established processes
Projects that benefit from Terraform’s extensive module ecosystem
Teams comfortable with HCL and template-based approaches

When to Consider Alternatives:

Teams wanting comprehensive testing capabilities (unit, property, integration testing)
Organizations requiring full IDE support with debugging and refactoring
Projects needing complex programmatic logic or extensive code reuse
Teams with strong programming backgrounds who prefer familiar languages

Key Considerations:

Licensing: Terraform’s Business Source License may create restrictions for some commercial scenarios
Ecosystem: Terraform has the largest provider ecosystem and community resources
Learning investment: Consider whether learning HCL aligns with your team’s skill development goals
Migration options: Tools exist for migrating between different IaC platforms when needs change

The choice often depends on team background, infrastructure complexity, and development workflow preferences rather than one approach being universally superior.

How do I get started with infrastructure as code?

Choose Based on Your Team Profile:

Programming-oriented teams: Consider Pulumi IaC for familiar languages with full IDE support, testing frameworks, and multi-cloud flexibility
Template-oriented teams: OpenTofu or Terraform offer extensive community resources, established workflows, and broad ecosystem support
Cloud-specific teams: Native tools (AWS CDK/CloudFormation, Azure ARM/Bicep, Google Cloud Infrastructure Manager) provide deep platform integration
Kubernetes-focused teams: Consider Crossplane or Pulumi Kubernetes Operator for container-native approaches

Getting Started Steps:

Start small: Begin with simple projects like deploying a single application or basic infrastructure
Use examples: Leverage existing templates, tutorials, and community examples to accelerate learning
Plan for growth: Consider how your tool choice will scale with team size and infrastructure complexity
Experiment: Most tools offer free tiers or trials - try multiple approaches with simple projects to find what fits your team best

What’s the difference between configuration management and infrastructure provisioning?

Infrastructure provisioning (Pulumi IaC, Terraform, CloudFormation) creates and manages cloud resources like VMs, networks, and databases
Configuration management (Ansible, Chef, Puppet) configures and maintains software on existing systems
Many modern tools do both, with Pulumi IaC and Ansible offering comprehensive capabilities across both domains

Can I use multiple IaC tools together?

Absolutely! Many organizations use complementary tools for different aspects of infrastructure management:

Pulumi + Configuration Management:

Pulumi + Ansible: Infrastructure provisioning + server configuration (example)
Pulumi + Chef/Puppet: Cloud resources + complex configuration management

Pulumi + Native Cloud Tools:

Reference existing CloudFormation/ARM deployments from Pulumi programs
Import CloudFormation/ARM resources into Pulumi for gradual migration
Use Pulumi alongside CDK for different parts of AWS infrastructure

Pulumi + Kubernetes:

Pulumi Kubernetes Operator (PKO) for GitOps workflows
Pulumi + Crossplane for layered infrastructure management
Pulumi + security scanners like Checkov or Terrascan for compliance

Terraform + Pulumi Coexistence:

Use Terraform for base infrastructure and Pulumi for Internal Developer Platforms (IDPs)
Reference existing Terraform state from Pulumi programs during gradual migration
Manage different infrastructure layers with different tools based on team expertise

Pulumi IaC is designed for heterogeneous environments where multiple tools may be in use. For example, you can manage existing Terraform or CloudFormation resources with Pulumi, either using both tools in tandem or for temporary management while migrating to native Pulumi IaC code. Other Pulumi tools, like Pulumi IDP, also enable you to manage IaC self-service workflows like other tools on this list. See what’s possible when migrating to Pulumi.

Which tool has the best learning resources?

Pulumi: Excellent documentation with examples in multiple languages, comprehensive tutorials
Terraform/OpenTofu: Extensive community content, many courses and books available
AWS CDK: Outstanding official documentation with workshops and examples
Kubernetes: Vast ecosystem but steeper learning curve

How important is open-source licensing for IaC tools?

Very important for long-term strategy:

Apache 2.0 (Pulumi, CDK) offers maximum flexibility
MPL 2.0 (OpenTofu) ensures open-source availability
BSL (Terraform) restricts commercial competitors
Proprietary (CloudFormation, ARM) ties you to specific vendors

Choose open-source tools like Pulumi or OpenTofu to avoid vendor lock-in.

What about security and compliance?

All major IaC tools support security best practices:

Built-in policy engines: Pulumi CrossGuard, AWS Config, Azure Policy
Third-party scanners: Checkov, KICS, Terrascan work with all tools
Compliance frameworks: Most tools support SOC 2, PCI DSS, CIS benchmarks
Secret management: Integration with Vault, AWS Secrets Manager, Azure Key Vault

Pulumi offers the most comprehensive built-in security features with CrossGuard policy as code.

Can I migrate from one IaC tool to another?

Yes, and many organizations are successfully migrating to overcome limitations in their current tools. Migration tools and proven approaches exist:

Proven Migration Success Stories:

Atlassian Bitbucket: Completed migration from Terraform to Pulumi’s Python-based IaC in just 2 days using migration tools
Starburst: Achieved 112x faster deployments after incrementally migrating from Terraform
Multiple organizations: Report 80-90% deployment time reductions after moving to programming language-based approaches

Available Migration Tools:

Pulumi: Offers pulumi convert for importing from Terraform, ARM, and CloudFormation with state integration
Terraformer: Can import existing cloud resources into Terraform/OpenTofu
CDK Migrate: Helps move from CloudFormation to CDK
Manual migration: Always possible by recreating resources in the new tool

Migration Strategies:

Incremental adoption: Migrate team-by-team or project-by-project without disruption
State integration: Reference existing infrastructure during transition periods
Zero downtime: Tools like Pulumi enable seamless migration without service interruption

The key is choosing tools that provide comprehensive migration support and incremental adoption paths rather than requiring “rip and replace” approaches.

Conclusion: The Evolution of Infrastructure as Code

The infrastructure as code landscape in 2026 reflects a maturing field where different approaches serve different organizational needs and team preferences. The evolution from manual processes to automated infrastructure has branched into multiple viable paths, each with distinct advantages.

The Spectrum of Approaches:

Template-based tools like Terraform and OpenTofu continue to serve teams effectively, particularly those comfortable with declarative configuration and established HCL workflows. Cloud-native solutions provide deep platform integration for single-cloud strategies. Programming language-based approaches offer familiar development experiences for teams seeking comprehensive testing, IDE integration, and code reusability.

Evidence of Success Across Approaches:

Organizations achieve significant improvements regardless of their chosen path—the key is selecting tools that align with team expertise and infrastructure requirements. Understanding what DevOps is and platform engineering concepts helps inform these decisions. Success stories span the entire ecosystem, from Terraform’s widespread enterprise adoption to programming language approaches enabling dramatic productivity gains at companies like Unity, Snowflake, and Starburst.

Choosing Your Path:

The most successful organizations focus on key decision criteria:

Team background: Match tools to existing skills and preferred development approaches
Infrastructure complexity: Consider testing, abstraction, and maintainability needs
Organizational constraints: Factor in licensing, governance, and compliance requirements
Growth trajectory: Plan for how needs may evolve with scale and team expansion
Integration requirements: Ensure compatibility with existing workflows and toolchains

The Future of Infrastructure:

The industry continues evolving toward treating infrastructure as software, but this transformation takes many forms. Organizations exploring serverless architectures and container strategies particularly benefit from programmable infrastructure approaches. Whether through enhanced DSLs, visual design tools, programming languages, or hybrid approaches, the goal remains consistent: enabling teams to manage infrastructure with the same reliability, collaboration, and velocity they expect from modern software development.

For teams ready to embrace programming language-based infrastructure as code, get started with Pulumi for free to experience how familiar languages and software engineering practices can transform infrastructure management with comprehensive testing, powerful abstractions, and seamless multi-cloud support. Want to see where infrastructure is headed next? Explore Pulumi Neo, the AI agent that proposes changes, runs previews, and opens PRs alongside your team.

Fully Automated AI Inference on AWS, Azure, and Google Cloud with Pulumi

Engin Diri — Tue, 30 Jun 2026 00:00:00 +0000

Putting Ollama on a cloud GPU is something I keep coming back to. A while ago I wrote up running open-source LLMs on an AWS EC2 box with Ollama and Pulumi, and the shape never really changes: a GPU instance, a model server, and a firewall rule in front. Infrastructure as code earned its place by making that kind of setup predictable and repeatable, and AI infrastructure is no exception. A GPU box serving a model is still a VM, a disk, and a firewall rule, and it should be declared like one.

Thorsten Hans made exactly that case in his Akamai post, Fully Automated AI Infrastructures with Terraform and Akamai Cloud, which stands up a single GPU instance on Linode, installs the drivers, runs Ollama, and pulls a model, with no manual steps after terraform apply.

I liked the shape of it, so this post ports the same idea to Pulumi and runs it across AWS, Azure, and Google Cloud instead of one. The result is one program shape per cloud: a single pulumi up brings up a GPU box that installs its own driver, runs Ollama, and pulls a model with no manual steps, and a single pulumi destroy takes it back down. Along the way it drops the two imperative bits the Terraform version leans on: a static access token sitting in an environment variable, and a null_resource running a shell loop to wait for the model. The first becomes an OIDC login from a Pulumi ESC environment, so no long-lived key lives anywhere. The second turns out not to be a resource at all.

What you are building

Strip away the per-cloud naming and every version of this is the same three things: a GPU virtual machine, a firewall in front of it, and a cloud-init script that turns a bare Ubuntu box into a running inference server. The model serving runs on Ollama, which exposes an HTTP API on port 11434 and keeps the model resident in GPU memory between requests.

flowchart LR
Dev([Your machine / curl]) -->|"HTTP :11434"| FW["Firewall / security group<br/>(allow 11434, optional 22)"]
FW --> VM["GPU VM (Ubuntu 24.04)<br/>NVIDIA driver + Ollama"]
VM -->|"resident in GPU memory"| Model["qwen2.5:14b"]
ESC["Pulumi ESC<br/>pulumi-idp/auth"] -.->|"OIDC login (short-lived creds)"| Pulumi["pulumi up"]
Pulumi -.->|"AWS / Azure / GCP"| VM

Component	Port	Description
GPU VM	-	Ubuntu 24.04 with an NVIDIA T4-class GPU. Installs the driver and Ollama from cloud-init, then pulls the model.
Ollama	11434	Serves the model over an HTTP API and keeps it in GPU memory between calls.
Firewall / security group	-	Allows inbound `11434` (and `22` when you ask for it). Open to the world for a demo; lock the CIDR down for anything real.
`pulumi-idp/auth` (ESC)	-	One environment that brokers an OIDC login into AWS, Azure, and GCP. No static keys in code or CI.

One detail here is worth pausing on, and it explains why the Pulumi version comes out shorter than the Terraform one. The Akamai project ends with a null_resource that runs a curl loop in local-exec to block terraform apply until the model finishes downloading. That is not infrastructure but a runtime check wearing a resource costume. Pulumi has a Command provider that would let you reproduce it line for line, and this post deliberately does not. The program provisions the box, the box pulls the model on its own, and the program prints the endpoint. Whether the model has finished downloading yet is a question you answer with a curl, not a question your IaC tool should be holding a deployment open to ask.

Prerequisites

Before getting started, ensure you have:

Pulumi CLI installed and configured
A Pulumi Cloud account (ESC and OIDC live here)
An account on at least one of AWS, Azure, or Google Cloud, with an OIDC trust set up for Pulumi (covered below)
Enough GPU quota in your target region for one T4-class instance; a fresh account often starts at zero, which is the most common reason a first deploy fails, so check it before you run pulumi up
Node.js 18+ for the TypeScript program
curl to talk to the inference endpoint once it comes up

This post serves the qwen2.5:14b model, the same one the Akamai article uses, because the 4-bit quant fits comfortably on a single 16 GB T4. The model is one config value (model), so swap in anything Ollama supports; match the GPU to the model’s memory footprint, because a model that overflows VRAM still runs but spills onto the CPU and crawls.

Credentials without the copy-paste

The Terraform version authenticates the only way a single-cloud demo can: you mint a personal access token, export it as LINODE_TOKEN, and the provider reads it from the environment. It works, but that token is long-lived, it sits in your shell history and your CI secrets, and you mint one per cloud. Across three clouds that is three static keys to rotate and worry about.

Pulumi ESC (Environments, Secrets, and Configuration) replaces it all with an OIDC login. The idea: instead of storing a cloud key, you store a trust relationship. At deploy time, ESC presents a short-lived OIDC token to AWS, Azure, or Google Cloud, and each one hands back temporary credentials scoped to a role you control. Nothing long-lived is ever written down.

I keep that wiring in one environment, pulumi-idp/auth, and every stack imports it. Here is the whole thing:

# pulumi-idp/auth: one ESC environment that brokers an OIDC login into all three
# clouds. Every stack imports it. No static cloud key lives here or anywhere else.
values:
 aws:
 login:
 fn::open::aws-login:
 oidc:
 roleArn: arn:aws:iam::123456789012:role/pulumi-esc
 sessionName: pulumi-esc
 azure:
 login:
 fn::open::azure-login:
 clientId: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
 tenantId: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
 subscriptionId: /subscriptions/00000000-0000-0000-0000-000000000000
 oidc: true
 gcp:
 login:
 fn::open::gcp-login:
 project: 123456789012 # numeric project number, not the project ID
 oidc:
 workloadPoolId: pulumi-esc
 providerId: pulumi-esc
 serviceAccount: pulumi-esc@my-project.iam.gserviceaccount.com
 environmentVariables:
 # AWS: read by the Pulumi AWS provider, the AWS SDKs, and the aws CLI
 AWS_ACCESS_KEY_ID: ${aws.login.accessKeyId}
 AWS_SECRET_ACCESS_KEY: ${aws.login.secretAccessKey}
 AWS_SESSION_TOKEN: ${aws.login.sessionToken}
 # Azure: read by the azure-native provider
 ARM_USE_OIDC: "true"
 ARM_CLIENT_ID: ${azure.login.clientId}
 ARM_TENANT_ID: ${azure.login.tenantId}
 ARM_SUBSCRIPTION_ID: ${azure.login.subscriptionId}
 ARM_OIDC_TOKEN: ${azure.login.oidc.token}
 # Google Cloud: read by the Pulumi Google Cloud provider
 GOOGLE_CLOUD_PROJECT: ${gcp.login.project}
 GOOGLE_OAUTH_ACCESS_TOKEN: ${gcp.login.accessToken}

You only need the blocks for the clouds you actually deploy to. Opening this environment makes ESC perform a live OIDC login for each cloud listed, so trim it to the one you use, or keep all three if, like me, you bounce between them.

Each cloud needs a one-time trust setup so this login is allowed at all: an IAM OIDC identity provider and role on AWS, a federated credential on an Azure app registration, and a Workload Identity Pool on Google Cloud. You do that once; after that, pulumi-idp/auth is the only thing any stack references for credentials.

A stack opts into it with one block in its stack config. The AWS stack’s Pulumi.aws.yaml:

# Pulumi.aws.yaml
environment:
 - pulumi-idp/auth

That is the entire credential story. No keys in the program, no keys in CI, nothing to rotate. The program below never mentions a secret; it only creates resources, and the ambient credentials from pulumi-idp/auth carry the request.

One cloud-init, three clouds

The part that turns a bare Ubuntu box into an inference server is identical on every cloud, so it lives in one file, cloud-init.yaml, that all three programs read. It follows the Akamai cloud-config closely, with a couple of robustness tweaks for a multi-cloud run, and it runs in a deliberate order because the GPU driver needs a reboot before Ollama can see the card:

Update packages and install the kernel headers and ubuntu-drivers.
Install the NVIDIA driver, then reboot so the kernel loads it.
On the next boot, a one-shot systemd service installs Ollama, binds it to 0.0.0.0:11434, and pulls the model.
The service disables itself, so it never runs again.

#cloud-config
# Zero-touch Ollama GPU box. Cloud-agnostic: no provider metadata, no static creds.
# The Pulumi program substitutes the model name on the `ollama pull` line below
# before this is passed as user-data (AWS/GCP) or custom-data (Azure).

write_files:
 # Make Ollama listen on every interface and never unload the model from VRAM.
 - path: /etc/systemd/system/ollama.service.d/override.conf
 content: |
 [Service]
 Environment="OLLAMA_HOST=0.0.0.0:11434"
 Environment="OLLAMA_KEEP_ALIVE=-1"

 # Runs once on the post-reboot boot, after the GPU driver is loaded.
 - path: /usr/local/bin/ollama-setup.sh
 permissions: '0755'
 content: |
 #!/usr/bin/env bash
 set -euxo pipefail

 # Install Ollama; the installer creates and starts the ollama systemd unit.
 curl -fsSL https://ollama.com/install.sh | sh

 # Pick up the OLLAMA_HOST / OLLAMA_KEEP_ALIVE override written above.
 systemctl daemon-reload
 systemctl enable ollama.service
 systemctl restart ollama.service

 # Wait for the daemon to bind its socket before pulling. This is the box
 # waiting on its OWN local daemon, not an external readiness gate.
 until curl -fsS http://127.0.0.1:11434/api/tags >/dev/null 2>&1; do
 sleep 2
 done

 # Pre-pull the model so the endpoint answers on the very first request.
 ollama pull __MODEL__

 # One-shot: never run again on future boots.
 systemctl disable ollama-setup.service

 - path: /etc/systemd/system/ollama-setup.service
 content: |
 [Unit]
 Description=One-time Ollama install and model pull
 After=network-online.target
 Wants=network-online.target

 [Service]
 Type=oneshot
 ExecStart=/usr/local/bin/ollama-setup.sh
 RemainAfterExit=true
 # The model pull runs for several minutes; without this, systemd's default
 # 90s start timeout kills the service mid-download and the model never lands.
 TimeoutStartSec=0

 [Install]
 WantedBy=multi-user.target

runcmd:
 - apt-get update
 - DEBIAN_FRONTEND=noninteractive apt-get -y upgrade
 # linux-headers-generic also covers the kernel the upgrade above may have pulled
 # in, so DKMS builds the NVIDIA module for the kernel that boots next.
 - DEBIAN_FRONTEND=noninteractive apt-get install -y "linux-headers-$(uname -r)" linux-headers-generic ubuntu-drivers-common
 # --gpgpu selects the headless server driver branch, the right one for a compute
 # GPU like the T4; bare `ubuntu-drivers install` would pull the desktop stack.
 - ubuntu-drivers install --gpgpu
 - systemctl enable ollama-setup.service

power_state:
 mode: reboot
 message: Rebooting to load the NVIDIA driver before Ollama setup
 condition: true

The model name is the literal token __MODEL__. The Pulumi program reads this file at deploy time and substitutes your model config value before handing it to the instance. Two environment settings are doing quiet but important work: OLLAMA_HOST=0.0.0.0:11434 makes Ollama listen on every interface instead of localhost alone, and OLLAMA_KEEP_ALIVE=-1 keeps the model pinned in GPU memory so only the first request pays the load cost.

The programs

Every program has the same five beats: read the config, template the cloud-init.yaml, open the inbound ports, launch the GPU instance with that cloud-init as its user data, and export the endpoint. What differs is only the dialect each cloud speaks for “GPU instance” and “firewall rule.”

The shared contract keeps the three listings legible side by side: the same model and allowSsh config keys, the same cloud-init.yaml, and the same four exports (publicIp, ollamaEndpoint, generateEndpoint, tagsEndpoint). Pick your cloud:

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as fs from "fs";

const cfg = new pulumi.Config();
const model = cfg.get("model") ?? "qwen2.5:14b";
const allowSsh = cfg.getBoolean("allowSsh") ?? false;
const region = (cfg.get("region") ?? "us-east-1") as aws.Region;

// Inject the model name into cloud-init at deploy time (a file read, not a shell-out).
const userData = fs.readFileSync("cloud-init.yaml", "utf8").replace(/__MODEL__/g, model);

// Region comes from config; credentials arrive ambiently from pulumi-idp/auth.
const provider = new aws.Provider("aws", { region });

// Most recent Ubuntu 24.04 LTS (amd64, hvm, gp3) published by Canonical.
const ubuntu = aws.ec2.getAmi({
 mostRecent: true,
 owners: ["099720109477"],
 filters: [
 { name: "name", values: ["ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"] },
 { name: "virtualization-type", values: ["hvm"] },
 ],
}, { provider });

const ingress: aws.types.input.ec2.SecurityGroupIngress[] = [{
 description: "Ollama HTTP API. NOTE: restrict cidrBlocks to your own range in production.",
 fromPort: 11434,
 toPort: 11434,
 protocol: "tcp",
 cidrBlocks: ["0.0.0.0/0"],
}];

if (allowSsh) {
 ingress.push({
 description: "SSH",
 fromPort: 22,
 toPort: 22,
 protocol: "tcp",
 cidrBlocks: ["0.0.0.0/0"],
 });
}

const sg = new aws.ec2.SecurityGroup("ollama", {
 description: "Ollama inferencing access",
 ingress,
 egress: [{
 description: "Allow all outbound",
 fromPort: 0,
 toPort: 0,
 protocol: "-1",
 cidrBlocks: ["0.0.0.0/0"],
 }],
}, {
 provider,
});

const server = new aws.ec2.Instance("ollama", {
 ami: ubuntu.then(a => a.id),
 instanceType: "g4dn.xlarge", // 1x NVIDIA T4
 vpcSecurityGroupIds: [sg.id],
 associatePublicIpAddress: true,
 userData, // plain text; the AWS provider base64-encodes it for you
 rootBlockDevice: {
 volumeSize: 40,
 volumeType: "gp3",
 },
 tags: { Name: "ollama" },
}, {
 provider,
});

export const publicIp = server.publicIp;
export const ollamaEndpoint = pulumi.interpolate`http://${publicIp}:11434`;
export const generateEndpoint = pulumi.interpolate`http://${publicIp}:11434/api/generate`;
export const tagsEndpoint = pulumi.interpolate`http://${publicIp}:11434/api/tags`;

import * as pulumi from "@pulumi/pulumi";
import * as gcp from "@pulumi/gcp";
import * as fs from "fs";

const cfg = new pulumi.Config();
const model = cfg.get("model") ?? "qwen2.5:14b";
const allowSsh = cfg.getBoolean("allowSsh") ?? false;
const project = cfg.get("project");
const zone = cfg.get("zone") ?? "us-central1-a";

// Inject the model name into cloud-init at deploy time (a file read, not a shell-out).
const userData = fs.readFileSync("cloud-init.yaml", "utf8").replace(/__MODEL__/g, model);

// Latest Ubuntu 24.04 LTS amd64 image.
const ubuntu = gcp.compute.getImage({
 family: "ubuntu-2404-lts-amd64",
 project: "ubuntu-os-cloud",
});

// Network tag binds the firewall rule to this instance.
const networkTag = "ollama";

const firewall = new gcp.compute.Firewall("ollama-fw", {
 network: "default",
 project: project,
 // Inbound to Ollama from anywhere; restrict this CIDR for production.
 allows: allowSsh
 ? [{ protocol: "tcp", ports: ["11434"] }, { protocol: "tcp", ports: ["22"] }]
 : [{ protocol: "tcp", ports: ["11434"] }],
 sourceRanges: ["0.0.0.0/0"],
 targetTags: [networkTag],
});

const instance = new gcp.compute.Instance("ollama", {
 machineType: "n1-standard-4",
 zone: zone,
 project: project,
 tags: [networkTag],
 bootDisk: {
 initializeParams: {
 image: ubuntu.then(i => i.selfLink),
 size: 40,
 },
 },
 guestAccelerators: [{
 type: "nvidia-tesla-t4",
 count: 1,
 }],
 // GPUs cannot live-migrate, so host maintenance must terminate (and restart) the VM.
 scheduling: {
 onHostMaintenance: "TERMINATE",
 automaticRestart: true,
 },
 networkInterfaces: [{
 network: "default",
 accessConfigs: [{}], // an empty config requests an ephemeral public IP
 }],
 metadata: {
 "user-data": userData, // Ubuntu cloud-init reads this key, not startup-script
 },
}, {
 dependsOn: firewall,
});

export const publicIp = instance.networkInterfaces.apply(nics => nics[0].accessConfigs![0].natIp);
export const ollamaEndpoint = pulumi.interpolate`http://${publicIp}:11434`;
export const generateEndpoint = pulumi.interpolate`http://${publicIp}:11434/api/generate`;
export const tagsEndpoint = pulumi.interpolate`http://${publicIp}:11434/api/tags`;

import * as pulumi from "@pulumi/pulumi";
import * as resources from "@pulumi/azure-native/resources";
import * as network from "@pulumi/azure-native/network";
import * as compute from "@pulumi/azure-native/compute";
import * as random from "@pulumi/random";
import * as fs from "fs";

const cfg = new pulumi.Config();
const model = cfg.get("model") ?? "qwen2.5:14b";
const allowSsh = cfg.getBoolean("allowSsh") ?? false;
const location = cfg.get("location") ?? "eastus";

// Inject the model name into cloud-init at deploy time (a file read, not a shell-out).
const userData = fs.readFileSync("cloud-init.yaml", "utf8").replace(/__MODEL__/g, model);

const resourceGroup = new resources.ResourceGroup("ollama-rg", {
 location,
});

const vnet = new network.VirtualNetwork("ollama-vnet", {
 resourceGroupName: resourceGroup.name,
 addressSpace: { addressPrefixes: ["10.0.0.0/16"] },
});

const subnet = new network.Subnet("ollama-subnet", {
 resourceGroupName: resourceGroup.name,
 virtualNetworkName: vnet.name,
 addressPrefix: "10.0.1.0/24",
});

// Standard SKU public IPs use static allocation.
const publicIpAddress = new network.PublicIPAddress("ollama-pip", {
 resourceGroupName: resourceGroup.name,
 sku: { name: network.PublicIPAddressSkuName.Standard },
 publicIPAllocationMethod: network.IPAllocationMethod.Static,
});

// Azure permits all outbound by default, so only inbound rules are needed.
const nsg = new network.NetworkSecurityGroup("ollama-nsg", {
 resourceGroupName: resourceGroup.name,
 securityRules: [
 {
 name: "allow-ollama",
 priority: 1000,
 direction: network.SecurityRuleDirection.Inbound,
 access: network.SecurityRuleAccess.Allow,
 protocol: network.SecurityRuleProtocol.Tcp,
 sourcePortRange: "*",
 destinationPortRange: "11434",
 sourceAddressPrefix: "0.0.0.0/0", // prod: restrict to your client CIDR
 destinationAddressPrefix: "*",
 },
 ...(allowSsh ? [{
 name: "allow-ssh",
 priority: 1001,
 direction: network.SecurityRuleDirection.Inbound,
 access: network.SecurityRuleAccess.Allow,
 protocol: network.SecurityRuleProtocol.Tcp,
 sourcePortRange: "*",
 destinationPortRange: "22",
 sourceAddressPrefix: "0.0.0.0/0",
 destinationAddressPrefix: "*",
 }] : []),
 ],
});

const nic = new network.NetworkInterface("ollama-nic", {
 resourceGroupName: resourceGroup.name,
 networkSecurityGroup: { id: nsg.id },
 ipConfigurations: [{
 name: "ipconfig1",
 subnet: { id: subnet.id },
 publicIPAddress: { id: publicIpAddress.id },
 privateIPAllocationMethod: network.IPAllocationMethod.Dynamic,
 primary: true,
 }],
});

// Azure requires an admin credential even though we never log in. Generate one
// instead of hard-coding it; it stays a Pulumi secret and is never exported.
const adminPassword = new random.RandomPassword("ollama-admin-password", {
 length: 24,
 special: true,
 overrideSpecial: "!#$%*",
 minLower: 1,
 minUpper: 1,
 minNumeric: 1,
 minSpecial: 1, // Azure requires 3 of 4 character classes
});

const vm = new compute.VirtualMachine("ollama-vm", {
 resourceGroupName: resourceGroup.name,
 hardwareProfile: { vmSize: "Standard_NC4as_T4_v3" }, // 1x NVIDIA T4
 networkProfile: {
 networkInterfaces: [{ id: nic.id, primary: true }],
 },
 osProfile: {
 computerName: "ollama",
 adminUsername: "azureuser",
 adminPassword: adminPassword.result,
 customData: Buffer.from(userData).toString("base64"), // Azure wants base64
 linuxConfiguration: {
 disablePasswordAuthentication: false,
 },
 },
 storageProfile: {
 imageReference: {
 publisher: "Canonical",
 offer: "ubuntu-24_04-lts",
 sku: "server", // Gen2; NC4as_T4_v3 is a Gen2 size
 version: "latest",
 },
 osDisk: {
 name: "ollama-osdisk",
 createOption: "FromImage",
 diskSizeGB: 40,
 managedDisk: { storageAccountType: "StandardSSD_LRS" },
 },
 },
});

// A Standard/Static public IP is reserved at creation, so its address is known
// once the resource exists; no separate lookup needed.
export const publicIp = publicIpAddress.ipAddress.apply(ip => ip!);
export const ollamaEndpoint = pulumi.interpolate`http://${publicIp}:11434`;
export const generateEndpoint = pulumi.interpolate`http://${publicIp}:11434/api/generate`;
export const tagsEndpoint = pulumi.interpolate`http://${publicIp}:11434/api/tags`;

A few per-cloud details are worth calling out, since they are the places the “same program” abstraction leaks:

AWS is the shortest program, because the GPU comes with the instance shape: a g4dn.xlarge is a T4 box, so there is no separate accelerator to attach. The one thing to do before you deploy is raise the Running On-Demand G and VT instances vCPU quota in your region; a fresh account starts at zero, and pulumi up fails with VcpuLimitExceeded until you do.
Google Cloud attaches the GPU explicitly with guestAccelerators, and that brings the rule that trips people up: a GPU instance cannot live-migrate, so scheduling.onHostMaintenance must be "TERMINATE" or the apply is rejected. The cloud-init also has to ride on the user-data metadata key, not startup-script, and the empty accessConfigs: [{}] is what hands the box a public IP. T4 quota is also zero on a new project.
Azure is the longest listing, because the network is à la carte: the resource group, virtual network, subnet, public IP, security group, and NIC are each their own resource before you reach the VM. One detail surprises people: a Linux VM requires an admin credential even when you never log in, so the program generates a throwaway password with random.RandomPassword rather than committing one. The NC4as_T4_v3 is a compute GPU, so the standard server (CUDA) driver from the cloud-init is the right choice here; the GRID driver is only needed for GPU-accelerated visualization workloads.

The full programs, all three Pulumi.<cloud>.yaml files, and the shared cloud-init.yaml are in the companion repo:

github.com/dirien/fully-automated-ai-inference-pulumi

Run GPU inference across three clouds

Stand up an Ollama GPU box on AWS, Azure, or Google Cloud from one Pulumi program, with short-lived credentials brokered by Pulumi ESC and no static keys to rotate.

Get started

Deploying

Create a project, install the provider for your cloud, point the stack at pulumi-idp/auth, and deploy. For AWS:

mkdir ai-inference && cd ai-inference
pulumi new typescript
npm install @pulumi/aws

Drop the AWS listing into index.ts, copy the cloud-init.yaml shown earlier into the same directory (or grab it from the companion repo), point the stack at the auth environment, and set your region:

pulumi stack init aws
# add `environment: [pulumi-idp/auth]` to Pulumi.aws.yaml (shown above)
pulumi config set region us-east-1
pulumi config set model qwen2.5:14b
pulumi up

The other two clouds are the same flow with a different provider package and a couple of config keys: npm install @pulumi/gcp with pulumi config set project <your-project-id> and pulumi config set zone us-central1-a, or npm install @pulumi/azure-native @pulumi/random with pulumi config set location eastus.

The slow part is the GPU box: it boots, installs the driver, reboots, installs Ollama, and pulls the model, all without you. Depending on the instance, the region, and the model size, plan on roughly 10 to 15 minutes before the endpoint answers. When pulumi up finishes you get the endpoints straight back as stack outputs:

Outputs:
 generateEndpoint: "http://<public-ip>:11434/api/generate"
 ollamaEndpoint : "http://<public-ip>:11434"
 publicIp : "<public-ip>"
 tagsEndpoint : "http://<public-ip>:11434/api/tags"

Testing the inference server

pulumi up returns as soon as the infrastructure exists, which is before the model has finished downloading. This is exactly where Terraform reached for that null_resource loop, and where Pulumi hands you a URL instead. To check whether the model is ready, ask Ollama what it has loaded:

curl -s $(pulumi stack output tagsEndpoint) | grep -q "qwen2.5:14b" && echo "ready" || echo "still pulling"

Once it reports ready, send it a prompt. This is the same request the Akamai post makes, pointed at your generateEndpoint output:

curl -s $(pulumi stack output generateEndpoint) -d '{
 "model": "qwen2.5:14b",
 "system": "Answer every question with a three-line poem.",
 "prompt": "Why is the sky blue?",
 "stream": false
}'

The first call is slower, because Ollama loads the model into GPU memory before it answers. Every call after that is fast, since OLLAMA_KEEP_ALIVE=-1 keeps it resident:

{
 "model": "qwen2.5:14b",
 "response": "Sunlight scatters, short waves fly,\nBlue light paints the open sky,\nViolet fades as day drifts by.",
 "done": true
}

When you are done, take it all down with one command, so the GPU stops billing:

pulumi destroy

Cost

A GPU instance is the whole bill, and you pay by the hour whether the model is busy or idle. The numbers below are rough on-demand rates for a single T4-class box left running 24/7; in practice you spin it up, use it, and pulumi destroy it, so what you actually pay tracks the hours it stays up.

Cloud	Instance	GPU	~Hourly	~Monthly (24/7)
AWS	`g4dn.xlarge`	1× T4 (16 GB)	~$0.53	~$384
Azure	`Standard_NC4as_T4_v3`	1× T4 (16 GB)	~$0.53	~$384
Google Cloud	`n1-standard-4` + 1× T4	1× T4 (16 GB)	~$0.54	~$394

These are on-demand Linux rates in a cheap US region (us-east-1, eastus, us-central1) as of mid-2026, and the GPU dominates the bill. Spot or preemptible capacity cuts it sharply if your workload tolerates interruption (often 60 to 70 percent off), Google Cloud’s sustained-use discount trims an always-on instance on its own, and the 40 GB disk adds only a few dollars a month.

A GPU box left running overnight is the expensive mistake here. Because the whole stack is declarative, the safe habit is cheap: pulumi destroy when you stop using it, pulumi up when you need it back. The state and config are version-controlled, so standing it up again is one command, not a rebuild.

Security considerations

The architecture in this post matches the Akamai original on purpose, which means it carries the same caveat: Ollama is exposed over plain HTTP on a port open to the entire internet. That is fine for a demo on a box you tear down the same day. It is not fine for anything that outlives the afternoon, and self-hosted AI endpoints get found fast: scanners like Shodan enumerate a freshly exposed one within hours, and an open Ollama instance is free compute for whoever finds it first.

The credential side, though, is genuinely better than a static-token setup, and that is the part worth keeping. There is no long-lived cloud key in the program, in your shell, or in CI; every deploy gets short-lived credentials minted through pulumi-idp/auth and thrown away when it finishes.

Concern	Akamai/Terraform demo	This deployment
Cloud credentials	Static PAT in an env var	OIDC login, short-lived, via `pulumi-idp/auth`
Inbound exposure	Port 11434 open to `0.0.0.0/0`	Same by default; one config flag scopes the CIDR
Transport	Plain HTTP	Plain HTTP (front with TLS for real use)
Readiness wait	`null_resource` + `local-exec` shell loop	A runtime `curl`, no resource

My recommendations for taking this past a demo:

Scope the inbound rule to your own CIDR instead of 0.0.0.0/0; the allowSsh flag in the program is the pattern to copy for the Ollama port
Put a reverse proxy with TLS in front of Ollama, or keep the box off the public internet entirely and reach it over a private network or a Tailscale tailnet, the way I did for the Hermes agent
Keep credentials on OIDC through ESC; never fall back to a static key to “just get it working”
Treat the box as disposable, and pulumi destroy it when you are not using it, which shrinks both the bill and the attack window

What’s next?

The program is a foundation, and the interesting work is what you layer on once a model is a pulumi up away:

Lock it down. Scope the firewall, add TLS, or move the box behind a private network so the endpoint is not on the public internet at all.
Scale the model to the GPU. qwen2.5:14b on a T4 is the entry point. Bigger models want more memory, which means an A10G, an L4, or an A100, and the only change in the program is the instance type and the model value.
Swap the serving engine. Ollama is the simplest thing that works. For higher throughput, the same shape holds with vLLM in place of Ollama in the cloud-init.
Generate the next one. Pulumi Neo can take a target like “a GPU inference box on Azure behind a private endpoint” and produce a first draft of the program, which you then review in a PR like any other change.

Conclusion

Declaring an AI inference server as code buys you the same thing it buys for any other infrastructure: you can reproduce it on any of the three clouds, version-control it, and tear it down with a single pulumi destroy. Porting the Akamai project made the contrast sharp. The credentials moved from a static token to an OIDC login that leaves nothing behind, and the readiness wait disappeared entirely once you stop treating a runtime check as a resource.

That is the line worth carrying to the next thing you deploy. Not every step in a runbook is a resource. A GPU box and a firewall rule are; waiting for a download to finish is not. Draw that line first, and the program gets shorter on its own.

If you run into issues or have questions, drop by the Pulumi Community Slack or GitHub Discussions. New to Pulumi? Get started here.

Six Live Kubernetes Recommendations: AKS, Cilium, Rate Limiting, and More

Adam Gordon Bell — Mon, 15 Jun 2026 12:00:00 +0000

On June 10th, Engin and I ran a live workshop building an AKS cluster, an Azure Container Registry, and a random-cat web app from scratch in C#. This is the writeup, including the parts we didn’t get to live.

Live demos keep you honest. On June 10th my AKS workshop went a little sideways. Partway through, Docker Hub rate-limited my image pull and we had to adapt the content on the fly. The original plan was to stand up an AKS cluster with Cilium, an Azure Container Registry with the cluster’s pull permission wired in code, and a random-cat web app, then split the infrastructure from the workload into separate Pulumi stacks. Live, we didn’t make it through all of that, but we had some fun tangents and it turned out to be a great session. So here are my six recommendations for working with Kubernetes on Azure from this recent workshop.

1. Pick the language your team already uses

I opened the session by asking the room what language they prefer to work in, with one caveat from me: “Hopefully, it’s not PowerShell because this is not in PowerShell.” We got some C# answers and zero requests for PowerShell, which works out, because the whole workshop is in ~~PowerShell~~ C#.

I chose C# because, first, I genuinely love the language. I spent the early part of my career as a C# developer, and on Azure it just makes sense. Second, an Azure workshop tends to draw a big turnout of C# devs, and if they aren’t C# devs themselves, they often work somewhere the backend team uses C#. Pulumi lets you bring that language to your infrastructure rather than learn a new DSL.

AI coding assistants also came up. LLMs have substantially more C# and Go in their training data than HCL or Bicep. As I put it live: “If you’re working in HCL, well, there’s not that much out there in the training set, but there’s lots of C#. There’s lots of Go.” I co-authored parts of the workshop code with Claude.

Pick the language your team already writes.

Pulumi runs on the language your backend engineers know, and that language has more AI assistant training data behind it too.

Aside: everyone’s path ran through Docker Swarm

We also had some fun historical conversations about orchestrators. I asked Engin: “Did you use anything before Kubernetes became popular? Like Mesosphere or any of those other interesting solutions of the heyday?”

Engin had walked the same road most of us did.

Engin: “We used the classical Ansible powered provisioning of VMs… And then we switched to Consul to have a little bit more control… And then we had a short intermezzo with Docker Swarm… So Docker Swarm with Portainer was really goated. And Kubernetes then took over.”

My own history rhymed with his.

Adam: “I worked at a place where we used a bunch of shell scripts to have like JVM services, like a red green deploy… And then it was Docker Swarm for a little bit. And then it was Kubernetes.”

No single tool won. Teams picked what fit their existing skills and shifted gradually as the ecosystem matured.

2. Use Cilium on AKS if you can

By default, Kubernetes on AKS doesn’t turn on Cilium. My strong recommendation is to turn it on. The option is called Azure CNI Powered by Cilium, and it takes one config block:

NetworkProfile = new ACI.ContainerServiceNetworkProfileArgs
{
 NetworkDataplane = "cilium",
 NetworkPlugin = "azure",
 NetworkPluginMode = "overlay",
 NetworkPolicy = "cilium",
 PodCidr = "192.168.0.0/16",
},

This buys you eBPF networking instead of kube-proxy and iptables. eBPF lets you run sandboxed programs inside the Linux kernel itself, so packet handling and NetworkPolicy enforcement happen down in the kernel instead of up in userspace. You also get Hubble flow visibility built in, the same technology as GKE’s Dataplane V2. As I said live, “this is very easy to set up on Azure. You just network data plane, set it to Cilium. Network policy, set it to Cilium.”

Self-hosted, Cilium is helm install cilium with a dozen flags and a lifecycle you own forever. On AKS, it’s these five lines and Azure runs it. On a getting-started cluster, I’ll take the managed version every time. Owning that lifecycle yourself buys you nothing here.

Full code: 01-cluster/Program.cs

On managed Kubernetes, complexity you’d self-host becomes a field you set.

AKS gives you the managed version of eBPF networking. Pulumi makes the configuration code instead of portal clicks.

3. Debugging Kubernetes is easier when your tools have the full context

The rate limit wasn’t even the first failure of the hour. That honor went to Azure, which refused to provision the cluster on the first pulumi up. I was running in Canada Central, and Pulumi Neo read the error and diagnosed it:

Neo: “Capacity constraints in the selected region. We might need to change our location.”

Adam: “Maybe this Canadian Azure instance is not all it’s cracked up to be.”

Engin: “East US is always a good bet.”

We switched the region to East US, and the cluster came up. That is the kind of diagnosis a stack-aware assistant is good at, reading the actual provisioning error instead of leaving me to guess.

Then the image step hit. The workshop’s original flow pulled the cat app image into ACR with az acr import --source docker.io/agbell/my-random-cat, and Docker Hub rate-limited me, even though I was the only person in the room running the code. So how do you blow through an anonymous pull limit all by yourself? The trick is that az acr import runs server-side. Azure does the pull from Docker Hub, not my laptop, and it goes out over an egress IP shared by who-knows-how-many other Azure tenants. Docker Hub counts anonymous pulls per IP address, so all of that shared traffic lands in one bucket. It flagged me at the worst possible moment: “I just got flagged by Docker Hub. That is awesome. That will be a challenge for this demo.”

Nothing focuses a workshop like watching your own demo get rate-limited in front of a live audience.

Live, I asked Neo to route around it: “we’re using Neo. And Neo is going to switch us out to a nice Hello World project.” Neo could see the whole stack, down to the failing image reference, and it swapped the workload over to a standard hello-world image hosted on Azure, so the deploy no longer depended on Docker Hub. A few minutes later: “we should have a Hello World container running here. It’s way less fun than my image… just a bunch of random cats. But here we can see that this is working.” I won’t oversell it. The cat was gone, and we didn’t get through every planned stage. But the cluster was up with a workload deployed, and the session kept moving.

That’s the case for a stack-aware assistant over a chatbot. A general chatbot can tell you that Docker Hub has rate limits and that you should host images closer to home. Neo was working with the actual program state, so the workaround it proposed was already wired to my resources. Engin put it this way: “for me, Pulumi Neo, the subcommand is the new Pulumi app.” When something breaks mid-demo, the tool that can read your stack is the one that helps.

The long-term fix was switching to az acr build, building the image in ACR from source, so the app image never has to come from Docker Hub at all. Every stage in the repo now builds the cat image this way, from source shipped in each stage’s app/ folder:

az acr build --registry <your-acr> --image my-random-cat:latest app

No local Docker, and the app image never touches Docker Hub. The only Docker Hub dependency left is the base image (python:3.9-slim), pulled server-side by ACR’s build instead of by an import you re-run every time.

Full code: 02-app/Program.cs

An assistant that can read your stack beats one that can’t.

A general chatbot knows Docker Hub has rate limits. Neo could see the deployment and the failing image reference, and that context is what turned advice into a working fix mid-session.

4. You don’t have to abandon Terraform to start

One attendee, Martin, had been using Terraform for eight-plus years. His question, put directly: “I’m using TF for eight plus years. Why should I consider Pulumi? Where is the strength?… It seems unnecessary to TF for me. At least from what I’m seeing now.”

Fair question, and the honest answer is you don’t have to abandon your modules. Pulumi has first-class Terraform module support, so you can reference existing modules from a Pulumi program. Python ML teams can import infrastructure modules, and platform teams can wrap them in typed abstractions. The portfolio doesn’t change. The programs that use it just get more capable.

The sharper reason is about edges. HCL and Bicep are purpose-built DSLs, and when you hit what they can’t express, there’s no escape hatch inside the language. With a general-purpose language you can always drop to the SDK or shell out. The edges still exist. They’re just further out, and that’s the whole difference once a project gets past the basics.

You don’t have to rip and replace.

Pulumi can reference existing Terraform modules. Move what makes sense now. The DSL/language tradeoff shows up at the edges, not the basics.

5. Split slow infrastructure from fast workloads

Once we had the cluster up and the app running, the single program had grown: cluster, ACR, AcrPull, image build, deployment, service. Every new workload meant editing the file that also declares the cluster. We had planned this turn in the session in advance. I posed the problem and Engin had the recommendation ready:

Adam: “What do you think the problem is with my code here, Engin? … The problem is like every time I want to add a new service to my Kubernetes cluster, I have to go into this file that declares the cluster and all its infrastructure. I think I would prefer to split it.”

Engin: “Create other stacks which are then referencing each other to get the values out. Actually, I highly recommend.”

Adam: “Yes, I totally agree with you, Engin. We should split these out into two separate stacks.”

So that’s what we did. The infrastructure stack exports the kubeconfig and registry URL. The workload stack references those outputs via StackReference. The slow-moving infra and the fast-moving app become independent deployment units. The infra team and the app team can ship on their own cadences, without fighting over one file.

// workload/Program.cs — pulls cluster outputs, never touches cluster resources
var clusterStack = new StackReference(cfg.Require("clusterStack"));
var kubeconfig = clusterStack.GetOutput("kubeconfig");
var acrLoginServer = clusterStack.GetOutput("acrLoginServer");

The tricky part is one we didn’t cover live, which is how you split a running workload without taking down the running services. The real answer is migrating the stack state, moving resources between stacks instead of destroying and recreating them. As I noted in the session: “now we are just removing the service from our project. If this was actual production stuff, I don’t think I’d be just shutting down the service… You can actually just make changes to the state rather than tearing them down.”

For the workshop, a simpler move kept the Kubernetes cluster up and the demo moving: keep the project name. Pulumi identifies stacks as org/project/stack, so if you move the cluster code into aks-cluster/ while keeping the project name kube-kitties, Pulumi still sees org/kube-kitties/dev. Same stack, nothing recreated. Rename the project and you get a second cluster.

In stage four of the demo, I showed how to extend this pattern to work with existing YAML manifests: ConfigGroup drives raw Kubernetes YAML through the Pulumi provider, giving you previews and dependency ordering without rewriting files. One transformation swaps the Docker Hub image reference for the ACR copy, so manifests stay portable and pods pull from your private registry.

Code: 03-split/ and 04-split-yaml/

Keep the project name when you split, and the cluster doesn’t move.

Pulumi identifies stacks as org/project/stack. Same project name means the same stack. Rename it and you spin up a new cluster.

Run Kubernetes on AKS with code

Provision your AKS cluster, container registry, and workloads in C#, then split infrastructure from apps into separate stacks so each ships on its own cadence.

Get started

6. GitOps is the way

The final stage of the workshop is left as homework, and it’s a great one to pick up. GitOps is the standard way to run Kubernetes at this point, the One True Way™ depending on who you ask. My position from the call: “I think I’m on team GitOps.”

The take-home is the 05-gitops folder. We didn’t demo it live, but the code is real and verified: Pulumi stands up the cluster, installs Argo CD, and registers the cat as an Argo Application. From there, changes are git push.

To see Kubernetes and GitOps worked through end to end, watch the video above. Engin also recently ran a GCP workshop with great examples of GitOps with Pulumi, using Flux.

Let Pulumi stand up the cluster, then let GitOps run the apps.

Pulumi installs Argo CD or Flux as part of the infrastructure. From there, workload changes are a git push. Stage 5 of the workshop repo is a complete Argo CD example.

Try it yourself

That’s the whole workshop, six recommendations and two live failures that ended with a cat app running on AKS. To run it yourself, clone the repo. There’s a DEMO.md with every step of this session, and the stage folders mirror the arc above. 01-cluster is the infrastructure checkpoint, 02-app adds the cat app built into your own registry, 03-split and 04-split-yaml separate infrastructure from workload, and 05-gitops is the homework.

Pick a stage and bring it up:

git clone https://github.com/pulumi/workshops
cd workshops/az-getting-started-aks/02-app
pulumi up
curl http://$(pulumi stack output catServiceIp)/

Expect 5 to 8 minutes waiting on cluster create. That’s just how long AKS takes. And since each folder is a complete, runnable checkpoint with its own stack, run pulumi destroy before moving to the next stage, or you’ll have several clusters billing at once.

You’ll need an Azure subscription, the Pulumi CLI, and the .NET SDK. Basic Kubernetes familiarity helps. For more on the building blocks, see the Azure Native provider and the Kubernetes provider in the Pulumi Registry.

The full workshop code lives at github.com/pulumi/workshops under az-getting-started-aks. Check out our upcoming sessions on the workshop page, or subscribe to the newsletter to hear what’s coming up.

If there’s a seventh recommendation hiding in here, it’s the one I learned the hard way: never pull from Docker Hub live again. I’ll be keeping my images on a paid cloud registry from now on.

Engin and I will be doing more of these, and we’d love to see you at the next one.

Parts of the workshop code were authored by Claude and Pulumi Neo, and parts of this writeup got help from both as well.

Automate Azure App Secret Rotation with ESC

Sean Yeh — Mon, 06 Apr 2026 00:00:00 +0000

Microsoft Entra ID (formerly Azure Active Directory) is Azure’s identity and access management service. Any time your application needs to authenticate with Entra ID, you create an app registration and give it a client secret that proves its identity. But those secrets expire, and if you don’t rotate them in time, your app loses access.

If you or your team manages Azure app registrations, you know that keeping track of client secrets is a constant hassle. Forgetting to rotate them before they expire can lead to broken authentication and unexpected outages. With Pulumi ESC’s azure-app-secret rotator, you can automate client secret rotation for your Azure apps, so you never have to worry about expired credentials again.

Setup

Prerequisites

An Azure App Registration
An azure-login environment
- Note for OIDC users: Since Azure does not support wildcard subject matches, you will need to add a federated credential for the azure-login environment as well as each environment that imports it.
- The Azure identity used for rotation must have the Application.ReadWrite.All Graph API permission, or the identity must be added as an Owner of the specific app registration whose secrets will be rotated.

How it works

Let’s assume your azure-login environment looks like this:

# my-org/logins/production
values:
 azure:
 login:
 fn::open::azure-login:
 clientId: <your-client-id>
 tenantId: <your-tenant-id>
 subscriptionId: <your-subscription-id>
 oidc: true

Create a new environment for your rotator. If you have the existing credentials, set them in the state object so the rotator will treat them as the current credentials.

# my-org/rotators/secret-rotator
values:
 appSecret:
 fn::rotate::azure-app-secret:
 inputs:
 login: ${environments.logins.production.azure.login}
 clientId: <target-app-client-id>
 lifetimeInDays: 180 # How long each new secret is valid (max 730 days)
 state:
 current:
 secretId: <secret-id>
 secretValue:
 fn::secret: <secret-value>

The lifetimeInDays field controls how long each generated secret remains valid before it expires. Azure allows a maximum of 730 days (two years), but shorter lifetimes are recommended for better security. Make sure to set a rotation schedule that runs before the lifetime expires so your credentials are always fresh.

Azure app registrations can have at most two client secrets at any given time, so the rotator maintains a current and previous secret. When a rotation occurs, the existing current secret becomes the previous secret, and a new secret is created to take its place as the new current. This ensures a smooth rollover with no downtime, since the previous secret remains valid until the next rotation.

Once this is set up, you’re ready to go! You never need to worry about your client secrets expiring, and you will always have the latest credentials in your ESC Environment.

Learn more

The fn::rotate::azure-app-secret rotator is available now in all Pulumi ESC environments. For more information, check out the fn::rotate::azure-app-secret documentation!

Expanded Version Control Support in Pulumi Cloud

Luke Ward — Mon, 09 Mar 2026 00:00:00 +0000

Your version control provider shouldn’t limit your infrastructure workflows. Pulumi Cloud now works with GitHub, GitHub Enterprise Server, Azure DevOps, and GitLab. Every team gets the same deployment pipelines, PR previews, and AI-powered change summaries regardless of where their code lives.

Connect multiple providers and accounts

You can connect multiple VCS providers to a single Pulumi organization simultaneously, like GitHub, GitLab, and Azure DevOps all at once. You can also connect multiple accounts of the same provider, such as two separate GitHub organizations or two GitLab groups. This means teams that work across different repositories, providers, or organizational boundaries can manage everything from one place.

GitHub Enterprise Server is currently limited to one connection per Pulumi organization.

What your team can do

Deploy on every push

Connect a repository to a stack, and infrastructure deploys automatically when you push. Configure path filters to trigger only when relevant files change, and manage environment variables and secrets directly in Pulumi Cloud. No external CI/CD pipeline required.

Preview changes on pull requests

Every pull request gets an infrastructure preview so reviewers can see exactly what will change before merging. The preview runs the same Pulumi operations your deployment would, giving your team confidence that a merge won’t break anything.

Neo explains your changes

Neo posts AI-generated summaries on your pull requests explaining what infrastructure changes mean in plain language. Reviewers who aren’t Pulumi experts can still understand the impact of a change without reading resource diffs.

Let Neo open pull requests for you

Ask Neo to make infrastructure changes and it opens pull requests directly against your connected repositories. Describe what you want in natural language, and Neo writes the code, opens the PR, and kicks off a preview, all without leaving Pulumi Cloud.

Detect and fix drift

Schedule drift detection to catch out-of-band changes automatically. When someone modifies infrastructure outside of your Pulumi programs, drift detection flags the difference so your team can remediate before it causes issues.

Secure authentication

Pulumi Cloud authenticates with your VCS provider using OIDC or OAuth so no long-lived credentials need to be stored. Short-lived tokens keep your deployment pipelines secure without manual secret rotation.

Set up new projects from your VCS

The new project wizard discovers your organizations, repositories, and branches so you can scaffold and deploy a new stack without leaving Pulumi Cloud. Pick your repo, choose a branch, and you’re ready to deploy.

Getting started

An org admin configures the integration under Settings > Version Control.
Authorize with your VCS provider.
Deploy infrastructure with first-class workflows.

For setup details, see the docs for GitHub, GitHub Enterprise Server, Azure DevOps, and GitLab.

Connect your VCS

Neo: Zero-downtime migration from CDK, Terraform & Azure ARM

Pulumi Neo Team — Wed, 21 Jan 2026 00:00:00 +0000

The barrier to migrating to Pulumi has always been the infrastructure you already have. Your existing resources can’t be disrupted, and manually importing them into a new tool is risky and time-consuming. Today, we’re excited to share how Neo removes this barrier entirely with automated, zero-downtime migration to Pulumi from AWS CDK, AWS CloudFormation, Terraform, CDKTF, and Azure ARM templates.

Why IaC migrations are hard

The promise of Infrastructure as Code is that your code perfectly describes your running infrastructure. But switching IaC tools breaks this promise in dangerous ways.

When you rewrite your infrastructure code in a new tool, you have two choices, both problematic. You can destroy and recreate all your resources to match the new code, accepting downtime and risk. Or you can try to import existing resources, which requires perfect knowledge of how every resource maps between the old and new systems. Many teams get stuck here, wanting Pulumi’s modern platform but unable to safely make the switch.

Neo’s insight: State knowledge enables perfect migrations

The key to safe migration isn’t just converting code - it’s understanding the complete relationship between your existing IaC tool’s state and your actual cloud resources. Each IaC tool maintains this relationship differently: CDK through CloudFormation stacks, Terraform/CDKTF through state files, and ARM through Azure deployments. But they all have complete knowledge of what they manage.

Neo leverages this existing state knowledge to orchestrate perfect resource transitions. Instead of asking you to manually find resource IDs and construct migration commands, Neo reads your current tool’s state, discovers every resource’s physical identity, and brings them under Pulumi management. This isn’t just automation - it’s using the source tool’s own knowledge against the migration problem.

In practice, this means Neo can bridge the gap between how tools name resources and where they actually live. A Lambda function that CDK knows as OrderHandler9I0J1K2L actually exists in AWS as my-app-OrderHandler-9I0J1K2L, while a Terraform resource at address aws_instance.web[2] maps to EC2 instance i-0abc123def456. Neo understands these mappings and handles the complex cases like composite IDs (FunctionName|StatementId), resource references, and dependency chains that must be migrated in order.

Because Neo uses the source tool’s own state knowledge, your infrastructure doesn’t change at all during migration. Not a single resource is modified, recreated, or even touched. We’re simply transferring ownership from one IaC tool to another.

This approach delivers three critical guarantees:

Zero downtime: Resources are never deleted or recreated
Zero risk: Since nothing changes, you can abandon the migration at any point without consequence
Zero surprises: Preview confirms no infrastructure changes before you commit

Migration in action: Four tools, one approach

Neo adapts its migration strategy to each tool’s unique characteristics while maintaining the same zero-downtime guarantee. Let’s explore how Neo handles migrations from each major IaC tool.

AWS CDK to Pulumi

For teams using AWS CDK, Neo leverages the CloudFormation layer that underpins CDK deployments. CDK’s architecture actually makes migration straightforward: since CDK synthesizes to CloudFormation templates, Neo can read the deployed stacks directly to understand every resource and its configuration. For detailed migration steps, see our CDK migration guide.

The challenge with CDK migrations isn’t the CloudFormation layer - it’s the cryptic resource naming. CDK generates logical IDs like OrdersTableA7B2C3D4 that map to physical resources with completely different names. These mappings are buried in CloudFormation metadata, and getting them wrong means either orphaning resources or accidentally creating duplicates. Neo navigates this complexity by reading CloudFormation’s own stack outputs and resource metadata, discovering the exact physical ID for every logical resource.

CDK also introduces complexity through its construct hierarchy. A single high-level construct might expand into dozens of CloudFormation resources, each with dependencies and references to others. Neo preserves these relationships during migration, ensuring that IAM roles still reference the right Lambda functions, API Gateway deployments still point to the correct stages, and security groups maintain their exact rules. The migration completes with your infrastructure unchanged and Pulumi’s preview confirming zero modifications.

Start a Neo task Migrate your CDK application

AWS CloudFormation to Pulumi

For teams using CloudFormation directly (rather than through CDK), Neo provides a streamlined migration path. CloudFormation stacks contain complete resource metadata - every resource’s logical ID maps to a physical resource in AWS, and CloudFormation tracks these relationships in its stack state. Neo reads this state directly to build a complete picture of your infrastructure. For detailed migration steps, see our CloudFormation migration guide.

The main challenge with CloudFormation migrations is the template language itself. CloudFormation templates use intrinsic functions like !Ref, !GetAtt, and !Sub that create implicit dependencies between resources. A security group might reference a VPC using !Ref MyVpc, while a Lambda function’s role uses !GetAtt LambdaRole.Arn. Neo evaluates these expressions against the actual deployed stack to resolve every reference to its concrete value.

CloudFormation also supports features like conditionals, mappings, and nested stacks that add layers of indirection. Neo handles these by examining what actually got deployed rather than trying to interpret every possible template path. The result is Pulumi code that manages your exact infrastructure configuration - not a theoretical interpretation of your template. The migration completes with pulumi preview confirming zero changes to your running resources.

Start a Neo task Migrate your CloudFormation stack

Terraform to Pulumi

Terraform and CDKTF migrations require two transformations: converting state to establish Pulumi’s connection to your resources, and transforming HCL configuration into Pulumi code. The state conversion is direct - Neo reads your Terraform state and converts it into Pulumi state, preserving the mappings between resource names and cloud IDs. This ensures Pulumi knows that aws_instance.web[2] corresponds to EC2 instance i-0abc123def456.

The code transformation analyzes your HCL to generate equivalent Pulumi code. Neo handles Terraform patterns like count and for_each loops, module structures, and resource dependencies, recreating them idiomatically in Pulumi. The generated code manages your existing infrastructure without modifications - pulumi preview confirms zero changes. For complete migration instructions, see our Terraform migration guide.

Start a Neo task Migrate your Terraform application

Azure ARM to Pulumi

ARM templates present unique migration challenges. Unlike CDK and Terraform, which maintain clear separation between code and state, ARM templates blur this line. The template is both the definition and, through deployment history, part of the state tracking. ARM’s template expression language, with its concat functions and resource ID constructors, makes it difficult to determine what resources actually exist until deployment time. For step-by-step migration guidance, see our ARM migration guide.

Neo orchestrates ARM migrations through intelligent AI-driven conversion. When an ARM template uses functions like concat(parameters('appName'), '-plan'), the conversion process evaluates these expressions using the actual parameter values to generate the correct resource names. Azure resource IDs follow predictable patterns - subscription IDs, resource groups, providers, and resource names - and Neo ensures these are correctly brought under Pulumi management using inline resource specifications directly in the generated code.

The biggest challenge with ARM migrations is handling the implicit dependencies and resource provider quirks. An App Service might implicitly create a service plan, a SQL database requires a server that might be defined in a linked template, and child resources like application settings need separate migration steps. Neo understands these Azure-specific patterns and generates the appropriate Pulumi code to manage every resource. The migration completes with a zero-diff preview, confirming your exact Azure configuration is preserved while giving you a more maintainable, type-safe way to manage it going forward.

Start a Neo task Migrate your ARM template

The architecture powering it all

While each tool requires specific handling, Neo’s core architecture remains consistent:

Universal orchestration layer

Neo acts as the intelligent migration coordinator, regardless of source tool:

Credential verification: Ensures proper cloud credentials are configured in Pulumi ESC
Resource inventory: Builds a complete catalog of existing resources
Conversion orchestration: Manages the code transformation
State migration: Brings existing resources under Pulumi management
Audit trail generation: Creates comprehensive migration reports

Unified state management engine

The state management engine works consistently across all tools:

Maps source resource IDs to Pulumi’s state management
Handles complex and composite resource identifiers
Provides fallback strategies for edge cases
Ensures idempotent operations

Human oversight

While Neo automates the heavy lifting, we maintain human checkpoints:

Review generated code before migrating resources
Verify preview shows zero changes
Approve the resulting pull request

What this means for your team

Migration friction no longer locks you into your current IaC tool. If you want Pulumi’s programming model, policy engine, and multi-cloud support, Neo gets you there without disrupting your infrastructure.

Ready to migrate? Check out our migration guides for CDK, CloudFormation, Terraform, or Azure ARM. Join us in the Pulumi Community Slack or reach out to your account team for a guided migration session.

Azure Native 3.8: Unified Credentials and Private Clouds

Eron Wright — Thu, 04 Sep 2025 12:00:00 -0700

Today we’re excited to announce Azure Native Provider v3.8, featuring several enhancements that simplify authentication and extend support to private Azure environments. These updates make it easier than ever to manage Azure infrastructure using credentials provided by the hosting environment, such as in Azure Kubernetes Service (AKS), Azure VM, and Azure Cloud Shell.

Simplified Authentication Across Environments

The highlight of this release is a new authentication mode based on DefaultAzureCredential, a feature of the Azure SDK that unifies authentication-related settings across deployment environments.

What’s New

DefaultAzureCredential automatically discovers and uses the best available authentication method for your environment, eliminating the need for an environment-specific configuration. It follows the Azure SDK’s standard credential chain:

Order	Credential	Description
1	Environment	Reads environment variables (e.g., `AZURE_TENANT_ID`, `AZURE_CLIENT_ID`) to authenticate as a service principal.
2	Workload Identity	For programs run on an Azure Kubernetes Service (AKS) cluster.
3	Managed Identity	For programs deployed to an Azure compute resource (e.g., Azure Virtual Machines) or App hosting platform.
4	Azure CLI	For local development using Azure CLI’s `az login` command.
5	Azure Developer CLI	For local development using Azure Developer CLI’s `azd auth login` command.

Real-World Benefits

This means your Pulumi programs can now run seamlessly across:

Local development machines using Azure CLI credentials
CI/CD pipelines with service principals via environment variables
Azure Kubernetes Service with Workload Identity
Azure VMs and App Services with Managed Identity

All without changing a single line of configuration code.

Getting Started

Enable DefaultAzureCredential using Pulumi configuration:

pulumi config set azure-native:useDefaultAzureCredential true
pulumi config set azure-native:subscriptionId <your-subscription-id>

Note that subscriptionId is a required configuration setting in this (and most) authentication modes; it ensures your resources are deployed to the correct Azure subscription.

Private Azure Cloud Support

This release brings improved support for Azure private clouds. A private cloud is a dedicated cloud computing environment used by a single organization.

The provider can now automatically discover, and configure itself for, any Azure cloud based on the ARM_METADATA_HOSTNAME environment variable. Note that this takes precedence over the ARM_ENVIRONMENT variable.

How To Use

The provider can query the Azure metadata service to automatically configure itself for your specific Azure environment:

# Using environment variable
export ARM_METADATA_HOSTNAME=management.azure.example

# Or via Pulumi configuration
pulumi config set azure-native:metadataHost management.azure.example

The provider expects the 2022-09-01 metadata schema, which resembles:

{
 "authentication": {
 "loginEndpoint": "https://login.microsoftonline.com",
 "audiences": [
 "https://management.core.windows.net/",
 "https://management.azure.com/"
 ]
 },
 "name": "AzureCloud",
 "suffixes": {
 "keyVaultDns": "vault.azure.net",
 "storage": "core.windows.net"
 },
 "resourceManager": "https://management.azure.com/",
 "microsoftGraphResourceId": "https://graph.microsoft.com/"
}

The provider automatically retrieves the correct endpoints for authentication, resource management, and other services.

Disabling Instance Discovery

Also in this release is a new setting, disableInstanceDiscovery, to determine whether the provider requests Microsoft Entra instance metadata from the login endpoint (https://login.microsoftonline.com) before authenticating. This setting is for Pulumi programs authenticating in disconnected clouds or private clouds.

Setting disableInstanceDiscovery to true will completely disable both instance discovery and authority validation. Please ensure that the configured authority host is valid and trustworthy.

How To Use

The provider can be configured to disable instance discovery:

# Using environment variable
export ARM_DISABLE_INSTANCE_DISCOVERY=true

# Or via Pulumi configuration
pulumi config set azure-native:disableInstanceDiscovery true

Authentication in AKS with Workload Identity

For programs run in a pod on an Azure Kubernetes Service (AKS) cluster, DefaultAzureCredential automatically uses the workload identity of the pod’s service account. This workload identity could then be granted roles in Azure to deploy stack resources.

Ensure that the application pods using workload identity include the label azure.workload.identity/use: "true" in the pod spec.

Walkthrough

Let’s use Pulumi Kubernetes Operator (PKO) to demonstrate a use case where you’d run Pulumi deployment operations in a pod and could benefit from workload identity.

The operator allocates a dedicated pod for each Pulumi stack under its management, to serve as the execution environment for stack operations. Each stack may use the same or a different service account. With AKS, that service account has a workload identity that providers may use to authenticate to Azure cloud and even to Pulumi cloud.

Create an AKS Cluster

Please follow the steps in “Deploy and configure workload identity on an Azure Kubernetes Service (AKS) cluster” to create an AKS cluster, managed identity, and Kubernetes service account. Those steps are:

You now have an Azure managed identity and associated Kubernetes service account that DefaultAzureCredential can use to authenticate to Azure cloud.

Take note of the clientId that represents the managed identity:

az identity show --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --query clientId
"c2bbe0f5-6349-480a-9f6f-3a5cb3e4ecf9"

Install the Pulumi Kubernetes Operator

Install the operator into the pulumi-kubernetes-operator namespace:

kubectl apply -f https://raw.githubusercontent.com/pulumi/pulumi-kubernetes-operator/refs/tags/v2.0.0/deploy/quickstart/install.yaml

Configure a Pulumi Cloud Access Token

By default, the operator uses Pulumi Cloud as the state backend for your stacks. Please create a Secret containing a Pulumi access token to be used to authenticate to Pulumi Cloud. Follow these instructions to create a personal, organization, or team access token.

kubectl create secret generic -n ${SERVICE_ACCOUNT_NAMESPACE} pulumi-api-secret --from-literal=accessToken=${PULUMI_ACCESS_TOKEN}

Update the Kubernetes Service Account

To use the service account that was created earlier, we need to grant it the system:auth-delegator role:

cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: "${SERVICE_ACCOUNT_NAMESPACE}-${SERVICE_ACCOUNT_NAME}:system:auth-delegator"
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: system:auth-delegator
subjects:
- kind: ServiceAccount
 name: "${SERVICE_ACCOUNT_NAME}"
 namespace: "${SERVICE_ACCOUNT_NAMESPACE}"
EOF

Define an Example Program

Let’s define a simple Pulumi program that uses Azure Native 3.8 and calls the “getClientConfig” function to access the current identity of the provider.

cat <<"EOF" | kubectl apply -n ${SERVICE_ACCOUNT_NAMESPACE} -f -
apiVersion: pulumi.com/v1
kind: Program
metadata:
 name: sample-workload-identity
program:
 variables:
 clientConfig:
 fn::invoke:
 function: azure-native:authorization:getClientConfig
 clientToken:
 fn::secret:
 fn::invoke:
 function: azure-native:authorization:getClientToken
 outputs:
 clientConfig: ${clientConfig}
 clientToken: ${clientToken}
EOF

Run the Program using Workload Identity

Create a Stack object to run the Pulumi program using your service account and with azure-native:useDefaultAzureCredential enabled.

cat <<EOF | kubectl apply -f -
apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: sample-workload-identity
 namespace: "${SERVICE_ACCOUNT_NAMESPACE}"
spec:
 programRef:
 name: sample-workload-identity
 stack: sample-workload-identity
 envRefs:
 PULUMI_ACCESS_TOKEN:
 type: Secret
 secret:
 name: pulumi-api-secret
 key: accessToken
 serviceAccountName: "${SERVICE_ACCOUNT_NAME}"
 config:
 azure-native:useDefaultAzureCredential: "true"
 azure-native:subscriptionId: "${SUBSCRIPTION}"
 workspaceTemplate:
 spec:
 podTemplate:
 metadata:
 labels:
 azure.workload.identity/use: "true"
EOF

Checking the stack outputs, we see a clientId matching that of the managed identity!

kubectl get stack/sample-workload-identity -oyaml

apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: sample-workload-identity
 namespace: default
status:
 conditions:
 - lastTransitionTime: "2025-09-04T23:32:11Z"
 message: the stack has been processed and is up to date
 reason: ProcessingCompleted
 status: "True"
 type: Ready
 outputs:
 clientConfig:
 clientId: c2bbe0f5-6349-480a-9f6f-3a5cb3e4ecf9
 objectId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 subscriptionId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 tenantId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 clientToken: '[secret]'

Conclusion

Azure Native Provider v3.8 represents our commitment to making Azure infrastructure management work seamlessly across all deployment scenarios, from local development to production, from public cloud to private cloud.

Have questions or feedback? Open an issue on GitHub or join the conversation in our Community Slack (#azure channel).

Why Azure Teams Are Moving from ARM Templates to .NET

Sara Huddleston — Fri, 22 Aug 2025 01:41:10 +0000

Azure Resource Manager (ARM) templates are powerful, but painful. If you’ve ever tried to provision cloud infrastructure using ARM, you know the challenges:

Templates that started simple… and now span thousands of lines
Manual configuration stitched together with bespoke deployment logic
Lack of support for key services like Databricks
Slow, error-prone deployments that require multiple manual steps
No reuse, no testing, and no relief

ARM wasn’t built for the complexity of modern Azure workloads. If you’re already familiar with general-purpose languages, there’s a better path: Pulumi.

Top Pain Points of ARM Templates

Pain Point	ARM Templates	Pulumi (C#)
Language	JSON	C#, Python, TypeScript, or Go
Code Reuse	None—copy/paste only	Classes, functions, modules
Logic	Complex condition syntax	if / switch / for loops
IDE Support	Very limited	Full IntelliSense and refactoring
Testing	None	Unit tests with xUnit/NUnit
Debugging	Post-deploy troubleshooting	Step-through debugging in IDE
Refactoring	Manual edits	Standard IDE workflows

Pulumi: The Obvious Upgrade for .NET and Azure

Pulumi solves these problems at their root. It lets you define your Azure infrastructure using C#, the same language you’re already using to build your applications. With Pulumi, you get:

✅ Familiar programming languages ✅ Type safety and compile-time validation ✅ Full IDE support (IntelliSense, refactoring, debugging) ✅ Built-in support for Databricks, Kubernetes, and more ✅ Automated config and secrets management ✅ Easy testing, reuse, and CI/CD integration

From Static Templates to Software Engineering

Here’s an example of how different it is to build a storage account:

⛔ ARM Template (JSON)

{
 "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
 "parameters": {
 "storageAccountName": {
 "type": "string",
 "metadata": { "description": "Globally unique, 3–24 lowercase letters and numbers." }
 }
 },
 "resources": [
 {
 "type": "Microsoft.Storage/storageAccounts",
 "apiVersion": "2021-09-01",
 "name": "[parameters('storageAccountName')]",
 "location": "[resourceGroup().location]",
 "sku": { "name": "Standard_LRS" },
 "kind": "StorageV2",
 "properties": {}
 }
 ],
 "outputs": {
 "storageAccountId": {
 "type": "string",
 "value": "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]"
 }
 }
}

✅ Azure with Pulumi in C#

using Pulumi;
using Pulumi.AzureNative.Storage;

class MyStack : Stack
{
 public MyStack()
 {
 var storageAccount = new StorageAccount("mystorage", new StorageAccountArgs
 {
 ResourceGroupName = "my-rg",
 Sku = new SkuArgs { Name = SkuName.Standard_LRS },
 Kind = Kind.StorageV2
 });
 }
}

It’s clean. It’s familiar. And it works seamlessly with your .NET tooling. Pulumi is open source, and your Pulumi Cloud account is free for individuals and small teams, with advanced editions for large enterprises. Try Pulumi Cloud for FREE->

Why It Just Works for .NET Teams

If your organization is built on Azure and .NET:

Use C# across both infrastructure and application layers
Share libraries and logic between services
Test infrastructure the same way you test code
Integrate with Azure DevOps and GitHub Actions
Manage secrets, environments, and policies as code

Pulumi supports all the Azure services ARM does (and more), while giving you flexibility and control ARM never could.

Summary

ARM templatesweren’t designed to scale with the complexity of today’s cloud environments. They’re static, verbose, hard to test, and increasingly brittle.

Pulumi gives you the tools to manage Azure the way you manage software: modular, testable, scalable, and secure.

If you’re already building with C# and .NET, you’re 90% of the way there. Why suffer through another slow, error-prone ARM deployment?

Azure Native V3: A Leaner, Faster SDK for Microsoft Azure

Thomas Kappler — Thu, 03 Apr 2025 00:00:00 +0000

Pulumi Azure Native V3 is the most comprehensive infrastructure as code (IaC) solution for Microsoft Azure, combining full resource coverage with dramatic improvements in performance and developer experience.

With V3, the Pulumi Azure Native SDK is 75% smaller while maintaining 100% coverage of the Azure Resource Manager (ARM) API. This makes it the most efficient and complete way to define and manage Azure infrastructure with real programming languages.

Pulumi Azure Native provides direct access to the Azure Resource Manager API, making it hands-down the best infrastructure as code solution for Microsoft Azure. Unlike traditional providers that abstract away cloud APIs, Azure Native gives you more resource and property coverage compared to Terraform by directly mapping to Azure’s native REST API. This means:

Complete API coverage: Access every Azure resource available in ARM
Same-day updates: New Azure services and properties are available immediately
Advanced property support: Work with every resource property, not just a subset
Latest API versions: Always up to date with the newest stable Azure APIs

And with V3’s slimmer SDK footprint, developers benefit from faster IDE performance, reduced memory usage, quicker installs, and improved CI/CD pipeline efficiency.

These improvements came about through our RFC process, where we explored various options to balance SDK size with the flexibility needed by advanced users.

A Slimmer, More Efficient SDK

The most significant improvement in Azure Native V3 is the dramatic 75% reduction in SDK size across all languages. By optimizing the SDK to include only the default API versions, we’ve solved one of the main pain points reported by our users, the size of the package:

Language	Before	After	Reduction
.NET	77 MB	15 MB	80.5%
JS/TS	494 MB	87 MB	82.4%
Python	104.6 MB	25 MB	76.3%
Go (source)	910 MB	167 MB	81.6%
Java (explicit versions were not supported in v2)	68 MB	71 MB	+4.4%
YAML	no SDK	no SDK	-

This transformation delivers immediate benefits that every developer will notice: faster IDE performance with reduced load times, more responsive language servers for better autocompletion, reduced memory consumption, significantly quicker package installation, and improved CI/CD pipeline performance.

Additional Enhancements in Azure Native V3

Azure Native V3 introduces more than just SDK size optimization. Other improvements include:

Reorganized module structure better aligned with Azure SDK conventions
Improved resource naming for clearer distinction between similar resources
Enhanced handling of nested properties to avoid accidental overwriting
Better state management with the removal of unnecessary __inputs fields (most noticeable with large stacks)

Understanding Azure Versioning

The Pulumi Azure Native provider needs to manage two different versioning systems:

Pulumi’s Semantic Versioning: Our SDKs follow the traditional major.minor.patch format (e.g., 3.0.0)
- Patch versions (3.0.1) contain bug fixes only
- Minor versions (3.1.0) add new resources and non-breaking features
- Major versions (3.0.0) may contain breaking changes
Azure’s Date-based API Versions: Azure resources use date-based versions like “2024-01-01” or “2023-05-15-preview”
- Each Azure service (resource provider) has its own set of API versions
- Breaking changes can occur between different API versions
- Preview versions (with “-preview” suffix) contain newer features that may not be stable yet

Default API Versions

Azure Native V3 includes refreshed default API versions across nearly all resources, ensuring you’re automatically working with the latest stable Azure features and capabilities without any extra configuration. The new default versions unlock powerful new Azure functionality out of the box, such as:

EventGrid (now 2025-02-15): Support for advanced filtering, dead-lettering, and custom event schemas
MachineLearningServices (now 2024-10-01): Enhanced compute instance capabilities and new model deployment options
Storage (now 2024-01-01): Improved performance tiers and expanded security features
KeyVault (now 2024-03-01): Enhanced certificate management and expanded access policy options

Using Non-Default API Versions

Most users (approximately 95% based on our Pulumi Cloud data) will be perfectly served by these default API versions. However, there are situations where you might need to use a specific API version.

For these cases, Azure Native V3 provides two flexible approaches:

Option 1: Accessing Explicit API Versions via Local Packages

The most type-safe way to use explicit API versions is through local packages. This approach gives you the full SDK experience with strong typing, auto-completion, and documentation.

Add the specific API version package

Use the Pulumi CLI to add just the packages and versions you need:

pulumi package add azure-native storage v20240101

For more details on the package add command, see the CLI documentation.

Step 2: Import and use the versioned package

Once added, you can import and use the specific API version in your code:

import * as resources from "@pulumi/azure-native/resources";
import * as storage_v20240101 from "@pulumi/azure-native_storage_v20240101";

const resourceGroup = new resources.ResourceGroup("resourceGroup");

const storageAccount = new storage_v20240101.storage.StorageAccount("sa", {
 resourceGroupName: resourceGroup.name,
 sku: {
 name: storage_v20240101.storage.SkuName.Standard_LRS,
 },
 kind: storage_v20240101.storage.Kind.StorageV2,
});

import pulumi
from pulumi_azure_native import resources
import pulumi_azure_native_storage_v20240101 as storage_v20240101

resource_group = resources.ResourceGroup("resource_group")

storage_account = storage_v20240101.storage.StorageAccount("sa",
 resource_group_name=resource_group.name,
 sku=storage_v20240101.storage.SkuArgs(
 name=storage_v20240101.storage.SkuName.STANDARD_LRS,
 ),
 kind=storage_v20240101.storage.Kind.STORAGE_V2)

using Pulumi;
using Pulumi.AzureNative.Resources;
using Storage_v20240101 = Pulumi.AzureNative_Storage_v20240101;

class MyStack : Stack
{
 public MyStack()
 {
 var resourceGroup = new ResourceGroup("resourceGroup");

 var storageAccount = new Storage_v20240101.Storage.StorageAccount("sa", new()
 {
 ResourceGroupName = resourceGroup.Name,
 Sku = new Storage_v20240101.Storage.SkuArgs
 {
 Name = Storage_v20240101.Storage.SkuName.Standard_LRS,
 },
 Kind = Storage_v20240101.Storage.Kind.StorageV2,
 });
 }
}

package main

import (
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
 "github.com/pulumi/pulumi-azure-native/sdk/go/azure/resources"
 storage_v20240101 "github.com/pulumi-azure-native-storage-v20240101/sdk/go/azure/storage"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 resourceGroup, err := resources.NewResourceGroup(ctx, "resourceGroup", nil)
 if err != nil {
 return err
 }

 storageAccount, err := storage_v20240101.NewStorageAccount(ctx, "sa", &storage_v20240101.StorageAccountArgs{
 ResourceGroupName: resourceGroup.Name,
 Sku: &storage_v20240101.SkuArgs{
 Name: storage_v20240101.SkuNameStandard_LRS,
 },
 Kind: storage_v20240101.KindStorageV2,
 })
 if err != nil {
 return err
 }

 return nil
 })
}

name: azure-native-example
runtime: yaml
description: A minimal Azure Native Pulumi YAML program
resources:
 resourceGroup:
 type: azure-native:resources:ResourceGroup
 properties:
 location: westus2

 # Using specific API version package
 storageAccount:
 type: azure-native_storage_v20240101:storage:StorageAccount
 properties:
 resourceGroupName: ${resourceGroup.name}
 sku:
 name: Standard_LRS
 kind: StorageV2

package myproject;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.azurenative.resources.ResourceGroup;
import com.pulumi.azurenative.resources.ResourceGroupArgs;
import com.pulumi.azurenative_storage_v20240101.storage.StorageAccount;
import com.pulumi.azurenative_storage_v20240101.storage.StorageAccountArgs;
import com.pulumi.azurenative_storage_v20240101.storage.enums.Kind;
import com.pulumi.azurenative_storage_v20240101.storage.enums.SkuName;
import com.pulumi.azurenative_storage_v20240101.storage.inputs.SkuArgs;

public class App {
 public static void main(String[] args) {
 Pulumi.run(App::stack);
 }

 private static void stack(Context ctx) {
 var resourceGroup = new ResourceGroup("resourceGroup");

 var storageAccount = new StorageAccount("sa", StorageAccountArgs.builder()
 .resourceGroupName(resourceGroup.name())
 .sku(SkuArgs.builder()
 .name(SkuName.Standard_LRS)
 .build())
 .kind(Kind.StorageV2)
 .build());
 }
}

Option 2: Using the Generic Resource

An alternative approach is to use the generic azure-native.resources.Resource. This special resource allows you to access any Azure resource at any API version, including older versions that might not be available through local packages.

While not as type-safe as the local package approach, the generic resource offers maximum flexibility and is useful when you need to access a resource that is not yet supported by the Pulumi provider or when an issue prevents you from using a specific resource.

In most cases, we recommend using the local packages approach when you need a specific API version, and only falling back to the generic resource for special cases or resources not yet supported by the Pulumi provider.

For more details, see the Azure Native version guide.

Getting Started with Azure Native V3

If You’re Already Using Pulumi Azure Native

Upgrading ensures you benefit from the smaller SDK, refreshed defaults, and the best performance when managing Azure at scale.

Upgrading from v2: Follow the v2 to v3 migration guide.
Upgrading from v1: First move to v2 using our v1 to v2 upgrade guide, the follow the v2 to v3 migration guide. This two-step process resolves deprecation warnings and ensures a smoother migration.

For language-specific installation instructions, see our Azure Native setup guide.

If You’re New to Pulumi

Pulumi makes it easy to define, deploy, and manage Azure infrastructure using your favorite programming languages. To get started:

Sign up for Pulumi Cloud - free for individuals and teams.
Explore the Azure Native installation guide.
Try a quickstart project to provision real Azure resources in minutes.

Conclusion

Pulumi Azure Native V3 is the most complete and efficient solution for managing Azure infrastructure as code. With a dramatically smaller SDK, updated defaults, flexible API versioning, and enhanced developer experience, it offers the best combination of performance, coverage, and control for Microsoft Azure users.

We’d like to thank our community for their valuable feedback throughout the development of V3. Your input helped shape this release, and we’re excited to see what you’ll build with it.

Have questions or suggestions? Open an issue on GitHub, join our Community Slack.

Enforcing Policy as Code on Discovered Resources with Pulumi

Tyler D — Tue, 04 Feb 2025 00:00:00 +0000

In this post, we’re introducing a powerful new capability in Pulumi Insights that extends policy as code (PaC) beyond infrastructure as code to automatically govern all cloud resources in your environment. By unifying policy enforcement across both IaC and discovered resources, you can now write policies once and apply them universally - dramatically simplifying how organizations maintain security and compliance standards at scale.

What is Policy as Code (PaC)?

Policy as Code (PaC) is a way to define and enforce infrastructure policies using code. Instead of relying on manual processes or static configuration files, PaC enables automated policy enforcement in a consistent, versioned way. Pulumi’s CrossGuard feature allows you to write policies in general purpose programming languages, applying them across various cloud platforms such as AWS, Azure, GCP, and Kubernetes.

You can read more about CrossGuard in Pulumi’s CrossGuard documentation.

Accounts and Insights

Before diving into how you can configure PaC for discovered resources, it’s important to understand how Pulumi discovers resources within your cloud environment regardless of how they were created. Pulumi Insights provides visibility into the state of your cloud resources by using read only access to your cloud environment in order to catalog the resources it contains. This is done through the Accounts page in Pulumi, which shows all the accounts for discovering resources you have added to your Pulumi organization. On this page, you can add new accounts which you can then add to policy groups to begin evaluating all of your cloud resources using your organization’s policy as code.

After you have added an account, you can connect it with one or multiple Policy Groups to enforce the policies within those groups across your stacks and Insights accounts. Once linked to a Policy Group, your resources will be automatically evaluated against the policies you define whenever those policies or resources are updated.

Setting Up Policy Groups for Discovered Resources

To apply policies to your discovered resources, you first need to set up a Policy Group. A Policy Group in Pulumi enforces policies across a group of stacks and accounts in your organization. Each Policy Group can contain multiple stacks and accounts, and you can assign multiple Policy Packs to these groups.

Here’s an example of the Policy Group configuration page, where you can create and manage policy groups:

Once your Policy Group is set up, you can add Insights Accounts to the group, which will ensure that the resources in those accounts are evaluated against the policies in the group.

Running Policies on Discovered Resources

Now that your Policy Group is set up, you can start running policies against your discovered resources. Currently, Pulumi Insights supports running resource policies against all resource types supported by Pulumi Insights with support for stack policies coming soon. Pulumi Insights will evaluate each resource against the policies defined in your Policy Pack. If the resources violate any of the defined policies, those violations will show up on the Policy Violations page, which gives you a detailed view of any non-compliant resources.

Each violation includes details about the resource and the reason for the violation, helping you quickly identify and address issues.

Key Takeaways

With Pulumi’s new PaC over discovered resources feature, you can now apply the same policies to both IaC and discovered resources across your cloud environment. This enables you to write a policy once and have it apply across all of your cloud resources. This results in consistent, compliant infrastructure no matter how resources are provisioned.

To begin securing your cloud infrastructure, here are the steps to take:

Set up Policy Groups to enforce policies across stacks and accounts.
Link Insights Accounts to your Policy Groups.
View violations on the Policy Violations page and take action to resolve them.

This new capability is available for AWS, Azure, OCI, and Kubernetes. Stay tuned for more updates on policy enforcement and discover how you can leverage Pulumi for cloud security and compliance.

Try it yourself: Start enforcing policies across your discovered resources in minutes with Pulumi Insights. Check out our getting started guide to begin securing your entire cloud environment with policy as code.

For more information on getting started with Policy as Code, check out the following resources:

When to Use Cosmos DB

Adam Gordon Bell — Mon, 11 Nov 2024 17:39:54 -0500

When should you use Cosmos DB on Azure? It’s a hard question to answer.

Azure Cosmos DB tries to do it all - which makes it both powerful and, honestly, kind of confusing. The marketing doesn’t help either. Yeah, it’s a flexible database, but before you jump in, you need to understand how it actually works under the hood, what it’ll cost you, and what trade-offs you’re making by choosing it.

I’m going to break all that down. Here’s a roadmap:

TL;DR

The short version is: you should use it on Azure when you’d use DynamoDB on AWS. That’s to say, you should use it when you’re OK with being cloud-specific, when you want hands-off scalability, and when you know the query pattern and potential cost ramifications ahead of time.

But let’s start at the beginning.

What is Cosmos DB? Features & Architecture Explained

Cosmos DB is Microsoft high availability distributed database. First released as DocumentDB in 2014 and rebranded to Cosmos DB in 2017, its used internally at MS for Bing and Office 365 and available on Azure in all regions.

Types Of Databases

Different databases are good at different things. Relational databases focus on strong consistency and complex relationships. Key-value stores are optimized for speed and simplicity. Document databases trade schema rigidity for flexibility. NewSQL systems attempt to combine consistency and scale.

Type	Example	Best For
Relational	PostgreSQL	Traditional business applications with complex transactions
Key-Value	Redis	Caching and session management
Document	MongoDB	Applications with evolving data structures
NewSQL	Spanner, CockroachDB	Global applications requiring both scale and consistency
Dynamo-Inspired	DynamoDB, Cassandra	High write throughput, eventually consistent applications

Cosmos DB can look like each of those categories. This is because it’s a multi-model DB, with a number of APIs that correspond to each model type. Despite it having a SQL interface (often recognized as the most used and recommended interface), and despite it purporting to be multi-model, at its lowest layer, it is actually backed by a document-based storage layer. It is a powerful document database, one with tunable consistency, distribution by logical and physical partition, and more, but it’s helpful to know how the storage layer works to understand everything else. I’m going to show some examples, but first let’s clear up what Cosmos DB is not.

If you are going to use Cosmos DB, you should probably be using the Core API, also called the “API for NoSQL”. It’s the quickest to get new features. Confusingly, despite being called a NoSQL API, data is queried and added using SQL.

Cosmos DB Vs. SQL Server ( Azure SQL Database ) or Postgres

This is a personal opinion, but if you have a use case that is well served by a traditional relational database, you should choose that. Postgres and SQL Server are both great and both available on Azure ( Postgres as Azure Database for PostgreSQL ). They both have great query planners; they have great tooling for migration and backups, as well as schema management. The SQL API from Cosmos should not be considered an alternative to a relational database unless you have specific needs because it’s a different type of beast designed for different use cases. But let me show you.

If you grab our CosmoDB how to guide and pulumi up, you’ll see from that, the first hint of its document roots in that the pulumi namespace is Pulumi.AzureNative.DocumentDB, but it goes deeper because although I can insert and select with sql in Cosmos DB, there is no schema.

How to Insert & Query Data in Cosmos DB NoSQL

If I insert this customer:

CosmosDatabase database = await client.
 CreateDatabaseIfNotExistsAsync(databaseId);
CosmosContainer container = await database.
 CreateContainerIfNotExistsAsync(containerId, "/customerId");

// Insert a customer document
var customer = new Customer
{
 Id = Guid.NewGuid().ToString(),
 CustomerId = "12345", // Cosmos DB Partition key
 Name = "John Doe",
 Email = "john.doe@example.com"
};

await InsertCustomer(container, customer);

I can do selects against it like SELECT * FROM c WHERE c.customerId = '12345" but when I look in that container in Azure Data Explorer, I see something like this:

{
 "id": "1d4e26b3-7a02-4e97-8a9d-eccc0b2fd537",
 "customerId": "12345",
 "name": "John Doe",
 "email": "john.doe@example.com",
 "_rid": "<resource id>",
 "_self": "<document URI>",
 "_etag": "\"00000000-0000-0000-0000-000000000000\"",
 "_attachments": "attachments/",
 "_ts": 1609459200
}

As with any document database, rather than a schema, it’s just a JSON document. That’s all good, but because there is no schema, if I needed to do something like migrate name to fullname, how do I do it? Well, there are a bunch of strategies, but they all involve writing some application code to go record by record and move the value from name to full name.

So don’t be fooled by the SQL usage in the API. Cosmos DB is not a relational database; before you use a document database, you should be clear of the trade-offs.

Document Database / NoSQL Trade-Offs

Joins and Relationships: Cosmos DB lacks support for complex joins and foreign key constraints. Cosmos DB typically requires denormalization or application-level management of relationships.
ACID Transactions and Consistency: Cosmos DB supports ACID transactions but only within single partitions (more on partitions soon). Cross-partition operations in Cosmos DB may require manual consistency handling.
Schema Evolution and Migrations: Relational databases enforce a schema and support migration tools. Cosmos DB’s schemaless design offers flexibility but requires custom logic for data migrations, which can increase operational overhead with frequent schema changes.
Query Optimization and Indexing: Postgres, SQL Server, and any relational database will have a query optimization layer with a sophisticated planner and manual indexing control. Cosmos DB auto-indexes all fields, simplifying queries but potentially increasing costs. Custom indexing policies offer less control than you would see in SQL Server or Postgres.
Cost Structure: Relational database costs are tied to compute and storage resources. Scaling might be a challenge past some point, but costs are fixed. Cosmos DB uses Request Units (RUs) for billing and charging per read, write, and query. This can lead to unpredictable costs if not carefully tuned.
Operational Maturity: Relational databases are mature with mature solutions for backup, replication, and monitoring. Cosmos DB is fully managed but has fewer third-party tools. Postgres or another relational DB may be easier to integrate into existing workflows requiring mature operational support.

If your use case aligns well with relational databases, consider using PostgreSQL or SQL Server. You have multiple Azure options, including Azure Database for PostgreSQL and Azure SQL Database. There’s even Azure Cosmos DB for PostgreSQL, which confusingly uses native PostgreSQL combined with the Citus extension for distributed capabilities. It’s not based on Cosmos DB’s NoSQL DocumentDB storage layer and is a Postgres database.

Cosmos DB is best for other use cases, so on we go to ‘NoSQL’ document databases.

Azure offers various services under the “Cosmos DB” brand like Azure Cosmos DB for PostgreSQL, Azure Cosmos DB for MongoDB (VCore), and a managed instance for Cassandra. These are not based on the core Cosmos DB engine, they are not an API into Cosmos, they are a whole different things - hosted instances of specific database types.

Cosmos DB Vs MongoDB

So, let’s talk MongoDB then. Cosmos DB is multi-model in a specific way. It has a single storage layer, the DocumentDB, and then various APIs. One of these is a MongoDB interface. This Mongo interface, on top of Cosmos DB, might be a great choice if you are used to Mongo, because you can often just change your query string on your existing mongodb code and start using cosmos.

using MongoDB.Driver;
using MongoDB.Bson;

// Connect to Cosmos DB using MongoDB API
var client = new MongoClient("mongodb://<account>:<key>@<account>.mongo.cosmos.azure.com:10255/?ssl=true");
var db = client.GetDatabase("customersdb");
var collection = db.GetCollection<BsonDocument>("customers");

var docs = await collection.Find(
 new BsonDocument("customerId", "12345")
).ToListAsync();

That will totally work. You can query using MQL, assuming you avoid Mongo’s advanced features. Still, you will quickly need to understand Cosmos-specific things, like RUs and partitions, or else you might end up with unexpected performance or costs.

Reddit Azure users report some challenges with using the Mongo API, and Microsoft also recommends using the SQL-based “API for NoSQL” if you can. So Mongo fans may want to consider not choosing Cosmos’ Mongo API.

However, the big advantage of Cosmos over Mongo is distribution and scaling up. But to understand that, we need to explain partitions.

With MongoDB, you’re setting up shards, configuring keys, and managing replica sets. Sure, you get control, but you’re also the one staying up late managing infrastructure as your data grows.

In Cosmos DB, scaling and partitioning are more hands-off – you just have to enable ‘automatic scaling’ – but you need the correct partition key from the start. So you need to understand your access patterns and be aware that ‘automatic scaling’ does what it says, but costs will increase as you scale.

How Cosmos DB Partitions & Scales Data Efficiently

In MongoDB, a shard is a collection of data stored on a specific server, used to distribute data across multiple servers for horizontal scaling. Partitioning is really an improvement on this idea. Cosmos separates partitions into logical and physical partitions. You choose the logical partitions only and leave the DB to decide the best way to group these onto specific physical servers. The physical groupings are physical partitions, and the system manages scaling by handling data distribution across physical partitions without user intervention.

Cosmos DB Partitioning

Logical Partitions: Like MongoDB’s shards, logical partitions group documents with the same partition key. However, each logical partition can store up to 20 GB of data and is automatically managed by Cosmos DB.
Physical Partitions: Cosmos DB hides the complexity of managing the physical servers. Physical partitions store and serve one or more logical partitions, and Cosmos DB handles how data is distributed across physical partitions for you. This allows Cosmos DB to automatically scale and balance the load as needed.

Comparison To MongoDB

Feature	MongoDB Sharding	Cosmos DB Partitioning
Data Distribution	Manual sharding with shard key and replica sets	Automatic partitioning with partition key
Scaling	Manual scaling (add shards)	Automatic scaling (Azure-managed)
Operational Complexity	Requires manual setup and maintenance	Minimal operational overhead
Global Distribution	Requires manual setup of replica sets	Built-in global distribution
Consistency Models	Eventual (with strong for replica sets)	5 consistency models, including strong
Query Performance	Requires index management, can result in scatter-gather queries	Auto-indexing, but cross-partition queries can be costly
Cost Model	Based on instance, storage, and IO usage	Request Units (RUs) per operation, with potential for high costs

MongoDB Vs. Cosmos DB Cost Comparison

Your exact numbers may vary, but by my back-of-the-napkin math, Cosmos DB is cheaper more than MongoDB Atlas for similar workloads. It also has SLAs on read speed and scaling is much easier.

Service	Cost (500 reads/sec, 50 writes/sec, 10 KB document)	Pricing Model
MongoDB Atlas	~$387.62/month	Based on instance size (M30), fixed pricing
Cosmos DB	~$227.28/month	Request Units (RUs) based, scales with document size and operations

Cosmos DB Vs Cassandra

After learning about partitioning and seeing the Cassandra API, you might think Cosmos DB is basically managed by Cassandra. And there are some key similarities. In many ways, Cosmos DB is Cassandra-inspired, but there are key differences.

You might also like:

How Cosmos DB and Cassandra Relate

Partitioning: Both use logical partition keys for scalability to distribute data across nodes. Cassandra requires manual management, while Cosmos DB automates partitioning and scaling, reducing operational burdens, though at the cost of flexibility.
Tunable Consistency: Like Cassandra, Cosmos DB offers tunable consistency but expands on it with five levels: Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual—allowing finer control over consistency vs. performance.

Key Differences

Cassandra API: Though Cosmos DB offers a Cassandra API, it’s not running Cassandra under the hood. So, while the API is familiar, the system behaves differently, especially in terms of performance.
Operational Complexity: Cassandra gives complete control over nodes and replication but requires hands-on management. Cosmos DB automates these tasks, offering hands-off operations while maintaining high availability, making it easier to manage at scale.

API for Apache Cassandra

If you have existing Apache Cassandra usage, in theory, the API for Apache Cassandra lets you use CosmosDB equivalently by just changing the query string. As with the Mongo API above, if possible you are probably better to use Core NoSQL API, but that will required rewriting dataaccess code.

Cosmos DB CQL Querying

using Cassandra;

// Connect to Cosmos DB's Cassandra API
var cluster = Cluster.Builder()
 .WithCredentials("<username>", "<password>") // From Azure Portal
 .WithPort(10350)
 .AddContactPoint("<account>.cassandra.cosmos.azure.com")
 .WithSSL()
 .Build();

var session = await cluster.ConnectAsync();

var cql = "SELECT * FROM customersdb.customers WHERE customer_id = ?";
var results = await session.ExecuteAsync(cql, "12345");

foreach (var row in results)
{
 Console.WriteLine($"Customer: {row["name"]}");
}

When to Use Cassandra Vs Cosmos DB

Cassandra: Use when you need control and can manage partitioning and scaling manually.
Cosmos DB: Use when you want hands-off scalability and a fully managed service with the option to use Cassandra-like APIs.

So use Cassandra when you need complete control over partitioning and scaling and are prepared to manage infrastructure manually. Opt for Cosmos DB when you want a hands-off managed service that handles the operational complexity for you, even if you’re using the familiar Cassandra API.

Dynamo DB Vs Cosmos DB

After comparing Cosmos DB to Cassandra, it’s natural to think of DynamoDB next. Like Cosmos DB, DynamoDB is fully managed and Dynamo-inspired, but being part of AWS, it operates differently from both Cassandra and Cosmos DB, especially in terms of operational simplicity and pricing.

Managed Operations

DynamoDB and Cosmos DB remove the ops overhead you’d get with Cassandra. If Cassandra gives you full control over nodes and partitioning, DynamoDB and Cosmos DB automate much of the complexity behind the scenes. With DynamoDB, you don’t have to manually manage shards or replication—AWS handles that for you, just like Cosmos DB on Azure.

Both databases also rely heavily on partition keys for data distribution. In DynamoDB, choosing the right partition key is critical to avoid hot spots, just like you need a well-thought-out partition key in Cosmos DB to balance the load across physical partitions. But where DynamoDB allows you to toggle between on-demand and provisioned capacity to manage scaling, Cosmos DB simply auto-scales as your traffic grows, offering a more seamless experience if you’re willing to pay for it.

Cosmos DB Consistency Levels

While Cassandra offers tunable consistency, DynamoDB simplifies this down to just two options: eventual consistency (default) or strong consistency. It’s enough for many use cases, but Cosmos DB follows Cassandra in covering many levels of consistency ranging from strong to eventual. One level, Session level consistency, seems both unique to Cosmos and valuable. It ensures you are always able to read your writes in the same session without impacting performance as much as higher consistency levels can. This makes Cosmos DB pretty unique if you to fine-tune consistency for globally distributed applications.

Cosmos DB vs Dynamo DB Costs

Again, using some back-of-the-napkin math, DynamoDB in provisioned Mode is more cost-effective than Cosmos DB for the same workload with 10 kb document sizes, but the numbers could swing the other way based on your use case. This is with estimating 500 reads / second ( 400 point reads or get-time, 100 more complex queries) and 50 writes.

Service	Workload (500 reads/sec, 50 writes/sec)	3 KB Document Size	10 KB Document Size	Key Difference
DynamoDB	500 reads/sec, 50 writes/sec	$137.67/month	$54.84/month
Cosmos DB	500 reads/sec, 50 writes/sec	$227.28/month	$212.92/month

Tangent: Azure Table Storage vs. Cosmos DB

Cosmos DB also has a Azure Table API and marketing material saying it’s a better choice than Azure Table Storage. My take is Azure Table and Cosmos DB’s Table API both provide key-value storage with distinct trade-offs. Azure Table Storage is cost-effective and ideal for simpler, predictable workloads, requiring minimal complexity. Cosmos DB’s Table API adds flexibility, optional global distribution, and tunable consistency, but also brings more complexity and cost.

While both offer similar functionality, Cosmos DB’s advanced features will cost you. If you know you aren’t going to need scale read and writes or need multi-region writes or other features, Azure Table Storage’s simpler, predictable pricing is the way to go.

Provision Azure databases as code

Whether you land on Cosmos DB, Azure SQL, or PostgreSQL, Pulumi lets you define and manage your entire Azure data layer in the language you already use.

Get started

When Cosmos DB Makes Sense

OK, I think all these comparisons give us a solid grounding to talk about trade-offs. So, with all this in mind, when should you use Cosmos DB?

Document Database with Global Distribution: Cosmos DB is a strong choice if you need a document database that supports global distribution with multiple consistency models. Its automatic scaling and geo-replication mean you can reach a global audience and a high level of throughput with minimal operational overhead.
Hands-Off Scalability: This came up again and again. When you want to focus more on development and less on database administration, Cosmos DB offers hands-off scalability. It automatically handles partitioning, indexing, and replication, which is great for teams that prefer highly managed services.
Schema Flexibility: When your data structure is not fixed and might evolve over time, Cosmos DB’s schema-less nature is an advantage. This flexibility is helpful in cases where your application data needs to adapt frequently without the constraints of a rigid schema. Also, there is a taste aspect to this. While I like schemas and structure, some teams have extensive experience working with document-based NoSQL solutions, and they will find CosmosDB a great fit.

When to Avoid Cosmos DB

Cost Sensitivity: Cosmos DB can be expensive, when you start working multi-region or start writing a lot of data per partition. If cost is a primary concern, especially for smaller projects, it might be better to consider alternatives.
Complex Joins and Transactions: If your application requires complex joins, foreign key relationships, or cross-partition transactions, Cosmos DB might not be the best fit. A relational database like PostgreSQL or SQL Server would serve these requirements more effectively.
Predictable Workloads with Lower Complexity: For applications that have predictable workloads and do not need the complexity of multi-region consistency or scaling to varying demand levels, a simpler solution like a traditional relational database might be more cost-effective and easier to manage.
Need for Strong Schema Enforcement: Long-term, there is a lot to be said for having a scheme and an easy way to evolve your data. If your application benefits from strict schema enforcement to ensure data integrity and reduce developer errors, a relational database like PostgreSQL or SQL Server will be a better choice than Cosmos DB. Cosmos DB’s schema-less nature can introduce challenges if your data model needs strict consistency and structure.
Avoiding Vendor Lock-In: If you want to maintain portability and avoid vendor lock-in, Cosmos DB might not be ideal for you. A highly managed database service, whether CosmosDB, Dynamo, or Spanner, will be hard to replace on another cloud vendor. A more portable database like PostgreSQL or Cassandra might be preferable for multi-cloud or cloud-agnostic strategies.

More Reasons for Cosmos DB ( Update )

Since this article came out, I’ve had a chance to talk to several Cosmos DB users inside and outside Microsoft. I spoke with Mark Brown on the Cosmos DB team, and he highlighted two additional reasons why teams choose Cosmos DB, that I had originally under emphasized:

High Availability: Cosmos DB is designed for mission-critical applications requiring always-on availability. It’s the only Azure database with five 9s availability and active-active multi-region writes. This high availability is why services like Azure Active Directory and Teams use it.
Guaranteed Low Latency: Cosmos DB offers SLAs on read and write latency (<10ms P99), a guarantee few other databases can match. This speed is achieved by co-locating compute and storage on the same cluster, minimizing data access times.

Managing Database Infrastructure with Pulumi

Whether you choose Cosmos DB, PostgreSQL, or Azure Table Storage Pulumi simplifies the process of provisioning and managing database infrastructure on Azure. With infrastructure as code in your favorite programming languages, you can define, deploy, and maintain your entire database infrastructure using familiar development practices. Pulumi’s Azure Native provider helps you implement the right database solution for your specific needs.

With Pulumi, you get:

Rich Azure database provisioning capabilities for Cosmos DB, PostgreSQL, and Azure SQL
Automated configuration management to handle connection strings and secrets securely
Infrastructure testing capabilities to validate your database configuration before deployment
Stack references for managing multiple database environments
Custom components for creating reusable database infrastructure patterns

Ready to streamline your database infrastructure management?

Try Pulumi for Free

Summary

If you need something that is document-based, scales globally, and handles different consistency levels well, Cosmos DB could be a great choice - especially if you’re already using Azure. Azure takes it seriously - it’s in every data center they have, and they treat it as mission-critical. But here’s the thing - while it’s easier to manage than the alternatives we looked at, you’ll pay more for that convenience.

Many times, that cost is not the variable being optimized for. Data is paramount, and Cosmos DB works well for many. James Thurley, Co-founder of Canopy Simulations, found it a perfect fit for their needs:

We’ve been using Cosmos DB as a document database since it was called DocumentDB, and it’s been fast, reliable, and straightforward for our needs. We store large, arbitrarily structured JSON documents, and Cosmos DB’s full indexing has handled that effortlessly. For us, the simplicity works—we don’t need to scale to millions of users, and with auto-scaling, each customer’s database runs smoothly without any partitioning.

For help provisioning Cosmos DB, check out our Azure Cosmos DB How to guide and if you decide to go with Azure Tables instead, our Azure Native provider is there to help you all the same.

And if you have a Cosmos DB experience to share ( or I got something wrong ): reach out. And, if you haven’t already, give Pulumi IaC a try:

Get Started with Pulumi

Use Pulumi's open-source SDK to create, deploy, and manage infrastructure on any cloud.

Pulumi Azure Classic Provider Version 6.0.0

Daniel Bradley — Fri, 27 Sep 2024 12:04:00 +0000

The latest major release of the Azure Classic Pulumi Provider is available now! Our 6.0 release contains the latest upstream changes to keep you up-to-date along with the latest features and improvements from Pulumi.

The Azure Classic provider is derived from the upstream Terraform AzureRM provider and can be used to provision most resources on Azure. The Azure Classic provider can be used to complement the Pulumi Azure Native provider, our recommended provider, which has amazing resource coverage due to being derived directly from the official specifications. The provider is open source and available on GitHub so you can always follow along with current issues and developments, or even open your first pull request.

Here are a few links to help you get started if you are new to Pulumi:

Getting Started - A guided walkthrough for creating your first project
Setup & Install - Instructions on installing the Azure Classic provider
How-to guides - Learn how to use the Azure Classic provider to provision specific resources
Pulumi Neo - Ask Pulumi Neo to create a new project

Looking Back

Since the last major release of this provider, we have continuously shipped improvements to our ecosystem, bringing the latest Pulumi features to your production stack. We have rolled out an improved diffing strategy and fixed state upgrades in the Pulumi Terraform Bridge, removing spurious diffs on preview and increasing confidence when deploying. Additionally we have improved accuracy and coverage for registry documentation, via better example conversion and general docs improvements for bridged providers.

New Modules

Over the last two years, we have added support for several new modules. Among these are:

API Coverage Growth

The below chart shows the growth of this provider by resource, function, and supporting types since Version 5.

Upgrading

You can find our v5 to v6 Migration Guide on the Pulumi Registry.

Pulumi + Azure Deployment Environments: Better Together for Enterprise Developers

Mikhail Shilkov — Tue, 21 May 2024 00:00:00 +0000

We are excited to announce the support for authoring Azure Deployment Environments (ADE) environment definitions in Pulumi Infrastructure as Code (IaC) empowering developers to self-serve app infrastructure required to deploy and test cloud-based applications. With Pulumi support, you can now manage your Azure resources in these environments using the same familiar programming model and the full power of our IaC platform.

Azure Deployment Environments is a service that enables developers to quickly spin up app infrastructure with project-based templates, all while maintaining centralized management and governance. Azure Deployment Environments also provides developers with an intuitive self-service portal where they can choose a curated, project-specific template to deploy new environments with just a few clicks. Thanks to the ADE extensibility model, you can now turn any Pulumi program into an environment definition and use it directly to securely provision application infrastructure in Azure. This post will guide you through creating ADE templates and deploying resources from the Microsoft developer portal.

How It Works

Azure Deployment Environments natively supports the Azure Resource Manager (ARM) and Bicep IaC frameworks. In addition, ADE provides an extensibility model that enables customers to create custom container images to author environment definitions.

The Azure Deployment Environments and Pulumi teams collaborated to publish a standard container image that our joint customers can use directly to run Pulumi programs in ADE: pulumi/azure-deployment-environments. The image leverages ADE’s extensibility model to run Pulumi programs in the container.

When used with Pulumi, each environment definition consists of two components:

An environment.yaml file that describes the environment by referencing the Pulumi Docker image and pointing to a Pulumi program. Here is an example of such a file:

name: MyPulumiEnvironment
version: 1.0.0
summary: My First Pulumi-Enabled Environment
description: Deploys a Pulumi stack into ADE
runner: pulumi/azure-deployment-environments:latest
templatePath: Pulumi.yaml

A Pulumi program that defines the resources to deploy. This program can use any of the Pulumi Azure providers to define resources in the environment. Here is a very simple Pulumi program defined in YAML:

name: ade-pulumi
runtime: yaml
description: My first Pulumi program in ADE
config:
resource-group-name:
 type: string
resources:
sa:
 type: azure-native:storage:StorageAccount
 properties:
 kind: Storage
 resourceGroupName: ${resource-group-name}
 sku:
 name: Standard_LRS

This is all you need to define a Pulumi environment in ADE. If you prefer to use a programming language like C#, TypeScript, Python, or Go, you will also need to add the code next to the Pulumi.yaml file.

Once the environment definition is added to the catalog, a user simply chooses an applicable environment in their developer portal. After accepting parameter values, ADE will run the Pulumi program in the container to provision Azure resources. In the case of the above program, it will create a new Storage Account in the environment, and the user will be able to use the resources once they are provisioned by Pulumi.

Getting Started

To get started, you must have the Azure Deployment Environments service configured. You can manually create one in the Azure Portal by following the instructions or using our sample Pulumi program to provision all the required resources.

Once you have an ADE instance, you can start authoring your environment definitions. You can use the Pulumi Azure Deployment Environments samples as a starting point. The folder contains four simple Pulumi programs in four different languages, each creating a Storage Account in the environment. The programs also show how to use parameters to integrate with ADE’s configuration system.

Once you have the definitions, you will publish them to a GitHub or Azure DevOps repository and attach the repository as a Catalog in Azure Deployment Environments. You can do so manually using the Azure Portal or configure it within your Pulumi project, as illustrated in our sample.

Finally, navigate to the Microsoft developer portal to create a new environment. You will see the list of available templates, including the ones you just published.

Bring a Custom Container Image

The Pulumi container image pulumi/azure-deployment-environments is a great starting point for your environment definitions. However, if you want to customize the behavior to your needs, you can also bring your own container image to run Pulumi programs in ADE. To do so, refer to the Configure a container image to execute deployments with Pulumi article on Microsoft Learn.

One benefit of using a custom image is the ability to provide a Pulumi Cloud access token to the image via the PULUMI_ACCESS_TOKEN environment variable. This allows the image to authenticate with the Pulumi Cloud backend without requiring additional configuration. Pulumi Cloud securely encrypts and stores your infrastructure state, manages secrets, provides search and clear visibility across all your cloud resources, runs remote deployments, integrates with CI/CD pipelines, detects configuration drift, and enables centralized policy enforcement. Additional features such as RBAC and audit logging enable your team to collaborate easily, ship faster, more securely and with confidence for every deployment.

If you have a suggestion for improving the standard Pulumi container image, please open an issue on our GitHub repository. We are always looking for ways to improve the experience for our Azure users.

Conclusion

Together with the Azure Deployment Environments team, Pulumi is excited to enable our shared customers to take advantage of the ADE extensibility model, Pulumi IaC platform, and empower developers with self-service of Azure App infrastructure, within enterprise guardrails. We hope that this new capability will help you streamline your development processes and make it easier for your teams to provision new environments in Azure quickly.

If you want to learn more:

Attend our workshop Platform Engineering with Microsoft Azure and Pulumi that takes place on June 20
Read the announcement on the Azure blog
Explore the code at pulumi/azure-deployment-environments

Converting Bicep code to Pulumi

Zaid Ajaj — Fri, 29 Sep 2023 00:00:00 +0000

Bicep is a DSL developed by Microsoft to simplify the authoring of ARM templates and deploy resources to Azure. Today I will be sharing with you a new Pulumi converter plugin that I have been working on that converts Bicep code to any of the supported Pulumi languages.

The Bicep language is a domain-specific language for Infrastructure-As-Code built by Microsoft that uses declarative syntax to deploy Azure resources. It was made to address the shortcomings of authoring ARM templates that are written in JSON. Compared to ARM templates, Bicep is much more concise and readable. However, here at Pulumi we believe that using general-purpose programming languages that are familiar to developers is the best way to author Infrastructure-As-Code. Besides being able to use a general-purpose language, you and your team can benefit from using Pulumi Cloud as you scale to larger projects and teams with features such as Pulumi Deployments, Organization Access Tokens, Review Stacks and more.

That is why I have been working on a new Pulumi converter plugin that converts Bicep code to any of the supported Pulumi languages using the Pulumi CLI via pulumi convert.

Installing and using the plugin

First, install the converter plugin using the Pulumi CLI:

pulumi plugin install converter bicep

This command will install the plugin from the latest GitHub release of the repository.

Once installed, you can use it to convert Bicep code to Pulumi. For example, let’s say we have the following Bicep code in a file called example.bicep which deploys a storage account:

resource storage 'Microsoft.Storage/storageAccounts@2022-09-01' = {
 name: 'storageaccount'
 location: resourceGroup().location
 kind: 'StorageV2'
 sku: {
 name: 'Standard_LRS'
 }
}

Navigate to the directory where the file is located and run the following command. For example to generate TypeScript code from the Bicep code above, run:

pulumi convert --from bicep --language typescript --out output -- --entry example.bicep

This command will use the Bicep converter plugin we just installed to convert the code in example.bicep to TypeScript and place the generated code in the output directory.

You can change typescript to any of the supported languages such as csharp, python, go, java or yaml and you are good to go.

If you don’t specify the --entry flag, the plugin will look for the first file with the .bicep extension in the current directory.

Let us look at the generated code from the example above:

import * as pulumi from "@pulumi/pulumi";
import * as azure_native from "@pulumi/azure-native";

const config = new pulumi.Config();
// The name of the resource group to operate on
const resourceGroupName = config.require("resourceGroupName");
const currentResourceGroup = azure_native.resources.getResourceGroupOutput({
 resourceGroupName: resourceGroupName,
});
const storage = new azure_native.storage.StorageAccount("storageaccount", {
 accountName: "storageaccount",
 kind: "StorageV2",
 location: currentResourceGroup.apply(currentResourceGroup => currentResourceGroup.location),
 resourceGroupName: currentResourceGroup.apply(currentResourceGroup => currentResourceGroup.name),
 sku: {
 name: "Standard_LRS",
 },
});

import pulumi
import pulumi_azure_native as azure_native

config = pulumi.Config()
# The name of the resource group to operate on
resource_group_name = config.require("resourceGroupName")
current_resource_group = azure_native.resources.get_resource_group_output(resource_group_name=resource_group_name)
storage = azure_native.storage.StorageAccount("storageaccount",
 account_name="storageaccount",
 kind="StorageV2",
 location=current_resource_group.location,
 resource_group_name=current_resource_group.name,
 sku=azure_native.storage.SkuArgs(
 name="Standard_LRS",
 ))

package main

import (
 "github.com/pulumi/pulumi-azure-native-sdk/v2/resources"
 "github.com/pulumi/pulumi-azure-native-sdk/v2/storage"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi/config"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 cfg := config.New(ctx, "")
 // The name of the resource group to operate on
 resourceGroupName := cfg.Require("resourceGroupName")
 currentResourceGroup, err := resources.LookupResourceGroup(ctx, &resources.LookupResourceGroupArgs{
 ResourceGroupName: resourceGroupName,
 }, nil)
 if err != nil {
 return err
 }
 _, err = storage.NewStorageAccount(ctx, "storageaccount", &storage.StorageAccountArgs{
 AccountName: pulumi.String("storageaccount"),
 Kind: pulumi.String("StorageV2"),
 Location: *pulumi.String(currentResourceGroup.Location),
 ResourceGroupName: *pulumi.String(currentResourceGroup.Name),
 Sku: &storage.SkuArgs{
 Name: pulumi.String("Standard_LRS"),
 },
 })
 if err != nil {
 return err
 }
 return nil
 })
}

using System.Collections.Generic;
using System.Linq;
using Pulumi;
using AzureNative = Pulumi.AzureNative;

return await Deployment.RunAsync(() =>
{
 var config = new Config();
 // The name of the resource group to operate on
 var resourceGroupName = config.Require("resourceGroupName");
 var currentResourceGroup = AzureNative.Resources.GetResourceGroup.Invoke(new()
 {
 ResourceGroupName = resourceGroupName,
 });

 var storage = new AzureNative.Storage.StorageAccount("storageaccount", new()
 {
 AccountName = "storageaccount",
 Kind = "StorageV2",
 Location = currentResourceGroup.Apply(getResourceGroupResult => getResourceGroupResult.Location),
 ResourceGroupName = currentResourceGroup.Apply(getResourceGroupResult => getResourceGroupResult.Name),
 Sku = new AzureNative.Storage.Inputs.SkuArgs
 {
 Name = "Standard_LRS",
 },
 });

});

package generated_program;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.azurenative.resources.ResourcesFunctions;
import com.pulumi.azurenative.resources.inputs.GetResourceGroupArgs;
import com.pulumi.azurenative.storage.StorageAccount;
import com.pulumi.azurenative.storage.StorageAccountArgs;
import com.pulumi.azurenative.storage.inputs.SkuArgs;
import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import java.io.File;
import java.nio.file.Files;
import java.nio.file.Paths;

public class App {
 public static void main(String[] args) {
 Pulumi.run(App::stack);
 }

 public static void stack(Context ctx) {
 final var config = ctx.config();
 final var resourceGroupName = config.get("resourceGroupName");
 final var currentResourceGroup = ResourcesFunctions.getResourceGroup(GetResourceGroupArgs.builder()
 .resourceGroupName(resourceGroupName)
 .build());

 var storage = new StorageAccount("storage", StorageAccountArgs.builder()
 .accountName("storageaccount")
 .kind("StorageV2")
 .location(currentResourceGroup.applyValue(getResourceGroupResult -> getResourceGroupResult.location()))
 .resourceGroupName(currentResourceGroup.applyValue(getResourceGroupResult -> getResourceGroupResult.name()))
 .sku(SkuArgs.builder()
 .name("Standard_LRS")
 .build())
 .build());

 }
}

configuration:
 resourceGroupName:
 type: string
resources:
 storageaccount:
 type: azure-native:storage:StorageAccount
 properties:
 accountName: storageaccount
 kind: StorageV2
 location: ${currentResourceGroup.location}
 resourceGroupName: ${currentResourceGroup.name}
 sku:
 name: Standard_LRS
variables:
 currentResourceGroup:
 fn::invoke:
 Function: azure-native:resources:getResourceGroup
 Arguments:
 resourceGroupName: ${resourceGroupName}

Notice how the in the original Bicep code, we reference the location of the implicit resource group via resourceGroup().location. When the converter generates code for the target language, it replaces this implicit resource group with an explicit one by parameterizing the program by a resource group name and using that resource group when deploying the resources.

Early days for the converter

Currently the converter supports most of the features of Bicep such as parameters, variables, modules, resources, outputs and a number of built-in functions. That said, the converter plugin is still in its early days and it’s not yet tested against many real-world Bicep programs. I am actively working on improving it and making it support most of the Bicep language features. The source code is available on this GitHub repository. If you find any issues or have any feedback, please open an issue on the repository.

How does it work?

The converter plugin is a native binary built using .NET in F# and new Pulumi Converter SDK. Using the core Pulumi nuget package, we shipped an experimental API that allows you to easily build converter plugins that can extend the functionality of pulumi convert.

Building a language converter plugin involves taking the source language, in this case Bicep, and converting it to our internal Pulumi Configuration Language, or PCL for short. The converter implements a function of the following shape:

let convertProgram (request: ConvertProgramRequest): ConvertProgramResponse =
 let sourceDirectory = request.SourceDirectory
 let targetDirectory = request.TargetDirectory
 let args = request.Args
 // conversion logic here

In our case, we read the Bicep code from the source directory, convert it to PCL and write out the PCL code in the target directory. Then, Pulumi uses the built-in program generation facilities to take care of the rest of the work of generating the target language code from the PCL code so that we don’t have to worry about language-specific details. The converter only needs to know how to generate PCL.

To build the actual transformation from Bicep to PCL, I made use the of the Azure.Bicep.Core package available for .NET which allowed me to parse the Bicep code and generate a typed Abstract Syntax Tree (AST) from it. Building an AST from the source language allows us to easily traverse the tree, analyze it and symbolically rewrite pieces of it. Working at the AST level also makes it easy to test source code transformation using structure rather than text. Once we have obtained the Bicep AST, we transform it into a Pulumi AST that represents a PCL program. Finally, we print out the Pulumi AST to a string and write it to the target directory.

If you are curious about the specification of the AST that represents Bicep programs, head over to this file from the source code. You will find types such as BicepProgram and BicepSyntax that model almost every aspect of Bicep code. As for the AST of PCL programs, you can find the type definitions here.

The F# language is great for almost everything, but is especially amazing for writing language converters because of its powerful pattern-matching capabilities and the ability to write code in a functional style. Many of us working at Pulumi are big fans of F#!

Here is a snippet of the transformation pipeline written in F# that takes the input Bicep program and converts it to the final PCL text

bicepProgram
|> BicepProgram.dropResourceUnknowns
|> BicepProgram.reduceScopeParameter
|> BicepProgram.parameterizeByTenantAndSubscriptionId
|> BicepProgram.addResourceGroupNameParameterToModules
|> BicepProgram.parameterizeByResourceGroup
|> Transform.bicepProgramToPulumi
|> Transform.modifyComponentPaths rewriteComponentPath
|> Printer.printProgram

You can learn more on the implementation of these functions from the source code on GitHub. I’ve written it in a way that is easy to follow, understand and contribute to. Most of these functions are fully unit-tested and I am working on adding more tests to cover more of the Bicep language features.

Bonus converter: ARM to Pulumi

Those who are familiar with the Bicep CLI, know that it has a built-in decompiler that converts ARM templates to Bicep. I thought it would be fun to build another converter that takes ARM templates to Pulumi but without writing any conversion logic for it. Instead, I would decompile the ARM template to Bicep, then use the logic from the Bicep converter to generate the final PCL code. Fortunately, the decompiler code is embedded in the nuget package Azure.Bicep.Core so we don’t have to rely on the existence of the Bicep CLI in order to make this converter work.

From all of this, I created another converter pulumi-converter-arm that works exactly like the Bicep converter but takes ARM templates as input. Head over to the repository to learn more about how to install it and how to use it.

Depending on how well this ARM converter does its job, we might consider deprecating arm2pulumi in favor of it. However, we first need to test it against more templates and iron out the rough edges. It would be the ideal situation because there are virtually zero maintenance costs, any improvements to the Bicep converter would automatically get picked up here. Also, improvements to the decompiler from the Azure.Bicep.Core nuget package would benefit the converter as well.

Building your own Pulumi language converter

Converter plugins are a great way to extend the Pulumi CLI with pulumi convert to support new languages. When we shipped support for Converting full Terraform Programs To Pulumi, we extended the pulumi convert command to allow installing and using converter plugins that are shipped independently from the Pulumi CLI.

In essence, those plugins are executable binaries that can be written in any language, which serves up a gRPC server that implements the Converter contract:

// Converter is a service for converting between other ecosystems and Pulumi.
// This is currently unstable and experimental.
service Converter {
 // ConvertState converts state from the target ecosystem into a form that can be imported into Pulumi.
 rpc ConvertState(ConvertStateRequest) returns (ConvertStateResponse) {}

 // ConvertProgram converts a program from the target ecosystem into a form that can be used with Pulumi.
 rpc ConvertProgram(ConvertProgramRequest) returns (ConvertProgramResponse) {}
}

This Converter interface is considered experimental and is subject to change in the future.

Now, learning how to setup gRPC servers and implement the Converter contract is not an easy task unless you are familiar with it. For .NET, we shipped the experimental Pulumi converter SDK to the main Pulumi nuget package that makes it extremely easy to build converter plugins.

A bare-bones converter plugin that does nothing looks like this in F#:

open Pulumi.Experimental.Converter
open Pulumi.Codegen

let convertProgram (request: ConvertProgramRequest): ConvertProgramResponse =
 // TODO: Implement the conversion logic here
 ConvertProgramResponse.Empty

convertProgram
|> Converter.CreateSimple
|> Converter.Serve
|> Async.AwaitTask
|> Async.RunSynchronously

This will spin up a gRPC server that implements the Converter contract and will serve it on a random port assigned during startup. The Pulumi converter SDK automatically implements gRPC reflection which allows tools such as Postman to discover the available gRPC services and methods and send example requests to them. See Postman with gRPC.

Publishing converter plugins

The easiest way to make your converter plugin available to others is to publish it on GitHub releases. The Pulumi CLI expects a naming convention pulumi-converter-<name> and will automatically download the plugin from the latest GitHub release of the repository when given the --server flag during pulumi plugin install converter <name> --server <url>.

Converter plugins written in .NET are simple console applications that are compiled to native binaries for each target platform. To see how this is done, refer to this createAndPublishArtifacts function written for the Bicep converter that does the heavy lifting of building the native binaries for each platform, putting them in an archive then publishing them to GitHub releases.

Note: when publishing native binaries for macOS, the Github Action executing the publishing process must be using a macOS runner so that the generated binary from dotnet publish gets signed with a developer certificate. This is required for the binary to be executable on macOS.

Final thoughts

I hope you enjoyed this article and learned something new about the Pulumi converter plugins and Pulumi internals. I am very excited about the Bicep converter plugin and I am looking forward to hearing your feedback on it from the community. It was a lot of fun writing this in F# and made writing complex pieces of code very trivial.

If you have any questions or feedback, don’t hesitate to reach out!

The Real AI Challenge is Cloud, not Code!

Kat Morgan — Wed, 30 Aug 2023 00:00:00 +0000

The AI industry is stealing the show as tech’s goldrush of the ’20s. Just looking at ChatGPT’s record setting user growth, and rapid 3rd party integration by top brands, it is not surprising the hype suggests this is the beginning of a major digital transformation.

However, using AI/ML in your own products has some major challenges and obstacles. Below is a diagram of the end to end workflow of building and using an AI model: preparing the data, training a model, fine-tuning a model, hosting and running a model, building a backend service to serve the model, and building the user interface that interacts with the model. Most AI engineers are only involved in a few steps of the process. However, there is one challenge that is common across the entire workflow: creating and managing the cloud infrastructure is hard.

Figure 1. A sneak peak at the map of ML development and product path

Training a model requires spinning up hyper scale GPU clusters. Preparing and consuming the training or fine-tuning data requires managing data warehouses and buckets of object storage. Building an AI backend service requires packaging the model, deploying and scaling the model across compute infrastructure, creating and managing the network infrastructure like load balancing, and managing the vector databases. Building great frontend user experiences requires provisioning and managing CDNs and web application services. Suffice to say: The most difficult challenge that we face with AI today is a problem of cloud orchestration.

Most of this cloud orchestration today is done manually or with complex scripts. This is usually fraught with errors and simply doesn’t scale. Too much time is spent making cloud infrastructure work instead of focusing on actual AI/ML tasks. Infrastructure as code (IaC) is a key component to solving the cloud orchestration challenge present in AI/ML. By applying the rigor and precision of software development practices to cloud operations, IaC offers AI/ML professionals an efficient, reliable, and predictable way to develop at the highest velocity. Pulumi is an open source infrastructure as code platform that allows engineers to use any programming languages, including Python, to provision and manage AI infrastructure.

This blog post is the first installment of a series on AI Infrastructure as Python. We will start this journey with building an AI backend service for a chatbot. In this post, we will deploy a LLM model behind an API backend running on compute infrastructure in the cloud. This entire infrastructure pipeline will be deployed using IaC written in Python. The series will follow this AI backend service through its evolution into a robust and resilient cloud native service.

The most difficult challenge that we face with AI today is a problem of cloud orchestration

Before we get into the details of using Pulumi to deploy a private LlaMa 2 API chatbot service—in 30 minutes or less, of course—let’s start with some quick terminology/context:

Katwalk Server is a demo AI application written to host your choice of LLM either locally or in the cloud, and serve it as an OpenAI API compatible service. As a practical, hands-on introduction to IaC for the MLOps space, this project aims to demystify the concepts and showcase the benefits Pulumi can bring to your AI/ML projects.
Large Language Models or LLMs (like ChatGPT) are machine learning models trained to generate human-like conversational text which have already become essential tools for businesses and individuals, transforming every day tasks and how we interact with technology.
LlaMa is an LLM created by Meta, available for free for research and commercial use.

Figure 2. Or just let ChatGPT describe itself

Deploy a private LlaMa 2 API chatbot service … in 30 minutes or less!

If you are ready to try the #MLOpsChallenge along with us, then let’s double check a few requirements before starting the clock on our 30 minute chatbot challenge. While Pulumi supports many languages, we chose Python for this project, as Python is a familiar language in the AI industry.

Requirements

Choose one of the following deployment platforms. (You can actually choose more than one, if you’d like!)

Now, for the real fun, let’s start the timer and deploy our own chatbot! Note that the instructions below are for Runpod; instructions for the other two deployment platforms are found in the GitHub repository.

1. Prepare your Pulumi IaC directory

First we need to clone our IaC repository from GitHub and prepare our Python environment.

# Clone the repository and cd to the pulumi iac directory
git clone https://github.com/pulumiverse/katwalk && cd katwalk/pulumi

# Create and initialize the python virtual env
python3 -m venv venv && source venv/bin/activate

# Install python dependencies
python3 -m pip install -r requirements.txt

Next, let’s setup our state and secrets store in Pulumi Cloud.

# There are many ways to store Pulumi state, here we use Pulumi Cloud
# Other state backends include S3, local file, and more
pulumi login

# Initialize your stack
# Here we name the stack "dev"
pulumi stack init --stack dev

3. Configure required credentials

Configure your Huggingface credentials. If you open the Pulumi.${stackName}.yaml file, you can see the encrypted secrets in this plain text YAML configuration.

# Set Huggingface.co username
pulumi config set hfUsername <huggingface_username>

# Configure token as secret
pulumi config set --secret hfToken <huggingface_api_token>

# Set the model that you want to download
pulumi config set hfModel "meta-llama/Llama-2-7b-chat-hf"

4. Deploy in the cloud on Runpod.io

While there are three providers already supported in this codebase, this post illustrates deploying to Runpod.io, a GPU and ML dedicated cloud catering to AI workloads and development tasks.

# This enables the IaC to deploy Katwalk Server
pulumi config set deploy True

# Set the deploy runtime to runpod to deploy on the Runpod cloud
pulumi config set runtime runpod

# Configure your Runpod API Token as a secure Pulumi secret
# API token available at https://www.runpod.io/console/user/settings
pulumi config set --secret runpodToken <your_runpod_api_token>

# Finally, run `pulumi up` to deploy!
pulumi up

# When done, you can 'destroy' the stack to deprovision your deployment
pulumi destroy

There’s currently a bug in the code that does not return the fully-qualified domain name (FQDN) from Runpod for your chatbot instance. To get the FQDN (referenced later in this post as RUNPOD_FQDN), you’ll need to log into Runpod and retrieve that information.

5. Build the Katwalk container

While there are many other ways to orchestrate ML services in the cloud and locally, in this project we are taking ownership of the full application and infrastructure story. In fact, all three supported providers use the same container image to serve the LlaMa LLM API Service, and you can build it yourself just like this:

# Set image build to True
pulumi config set imageBuild True

# Let's build this without pushing to a registry for now
pulumi config set imagePush False

# Give your katwalk image a project name
pulumi config set registryProject $(whoami)

# Now build the image!
pulumi up

6. Talk to your chatbot!

Once your Katwalk LlaMa server is running, you can interact with the API by sending prompts as a JSON payload. In future posts we will orchestrate a chat frontend for our chatbot but for now we’ll use a curl command. You can also substitute an API developer tool such as Postman or Insomnia!

# send a prompt with curl
curl -s -X 'POST' 'http://${RUNPOD_FQDN}/v1/chat' -H 'accept: application/json' -H 'Content-Type: application/json' -d '{"prompt": "Write a short story about a robot."}'
{
 "text": [
 "\nOnce upon a time, there was a little robot named R2. R2 was a friendly and curious robot who lived in a big city. One day, R2 decided to go on an adventure. He set out to explore the city and learn about all the different things he could see and do.\nAs R2 explored the city, he met all kinds of people. Some were kind and welcoming, while others were scared or suspicious of him. Despite this, R2 continued to be friendly and curious, always asking questions and trying to learn more about the world around him.\nOne day, while R2 was exploring a busy market, he saw a group of people gathered around a little girl who was"
 ]
}

Figure 3. A prompt and response from meta-llama/Llama-2-7b-chat-hf hosted on Katwalk Server

In a world where “data is the new black gold” and tokens are money, deploying a chatbot in 30 minutes is not just interesting, it is a novel capability quickly becoming a necessity.

Platform engineering, DevOps, or MLOps may be the next hardest step in building the AI future. Pulumi offers a reliable path to higher velocity AI App development and MLOps. Together with Python-based IaC, it empowers the MLOps community to build equity in common AI platform code, and share IaC in a familiar language.

If you followed along then tell us how it worked out for you! We would love to know what you are looking forward to, or if you have ideas for future installments of the Pulumi Python + MLOps series!

Join us in the Pulumi Community Slack or in the Pulumiverse Community Katwalk Github repository to decide what #aiChallenge we tackle next!

Figure 4. Midjourney generated image of an imagined machine learning research engineer working among cables, computers, keyboards, and screens, in the glow of electronic lights. Image was generated from a prompt ~80% produced by ChatGPT based on this blog post content and a few superficial details about the author

How a Bank Modernized Its Software Engineering With Infrastructure as Code Automation

George Huang — Thu, 03 Aug 2023 00:00:00 +0000

This blog post summarizes a presentation by Dennis Sauvé at PulumiUP 2023.

Washington Trust Bank, the largest independently-owned full-service commercial bank in the Northwest, has served personal, private, commercial and wealth management clients throughout the region since 1902. It has assets exceeding $11 billion and currently has 42 branches and offices in Idaho, Oregon, and Washington.

As an FDIC-governed financial institution, it is imperative for the bank to maintain secure, reliable, and compliant cloud resources to protect clients’ personal data. On the other hand, it also aimed to create more agile development teams as it modernized its software development and infrastructure. Dennis Sauvé, the bank’s first DevOps Engineer, recognized Infrastructure as Code (IaC) as the solution to these challenges.

Embracing an Infrastructure as Code approach would allow them to automate building and deploying their cloud infrastructure, eliminate infrastructure provisioning as a bottleneck, and empower developers to self-service infrastructure and increase productivity.

Background

The main challenge was managing Azure infrastructure in an efficient and secure way that kept pace with the bank’s rapid growth. Previously, they ran on-premise infrastructure and deployed with BAT and Powershell scripts. Now, they had migrated to Azure and wanted to increase development speed through CI/CD for cloud infrastructure.

In addition, cloud resources’ security and reliability were paramount. They needed a way for the infrastructure and information security teams to work together to implement security best practices for infrastructure, including how to prevent insecure resources from being provisioned.

The bank decided to adopt IaC to create reliable and rapid deployments while ensuring that its cloud infrastructure stayed compliant and secure.

Why Washington Trust Bank Chose Pulumi

The bank evaluated several options, including Terraform and Azure Bicep. However, Pulumi stood out due to its versatility, support for multiple clouds and native Azure support, and the ability to write IaC in the bank’s preferred language, TypeScript. The ease of using Pulumi with GitHub, its ability to be used in conjunction with Azure CLI, and its comprehensive support for CI/CD through GitHub Actions were also compelling factors.

Dennis praised Pulumi, saying, “Pulumi was exactly the Swiss Army Knife versatility we were looking for. We’ve only uncovered more of what we love about Pulumi as our relationship has evolved.”

Benefits of Using Pulumi

Pulumi helped Washington Trust Bank improve efficiency by maintaining its infrastructure in code, promoting the security of its infrastructure, and accelerating development speeds. It automated deployment of web services for its development teams, data management tools for its business insights team, and orchestrated its entire hub-and-spoke cloud architecture.

Improved Development Speed with Reusable Infrastructure Packages and CI/CD

Pulumi’s automation capabilities played a transformational role. By freeing the infrastructure team from handling manual deployments, it could focus on improving developer productivity. The team created reusable and repeatable infrastructure components built around strict IT security standards in the form of Frazure, an internal NPM package.

Frazure allows the bank’s developers to easily provision out-of-the-box resources for cloud services and covers the necessary Azure resource groups, vnets, and other resources. The package encapsulates best practices, such as how resource groups and their virtual networks can be created, including subnet IP spaces, peerings to and from the hub virtual network, user-defined routes and more.

To deploy, developers open a pull request which kicks off a CI/CD pipeline in GitHub Actions and provisions testing environments and tests. Once the PR is reviewed and approved, the changes are automatically deployed to staging and live environments. This automated process enabled the bank to accelerate the building, testing, and deployment of new applications, translating into rapid value delivery to their customers.

Safeguards for Infrastructure

Pulumi also gave the bank total confidence in being able to rapidly recover its cloud infrastructure in the case of a failure in Azure. The integration of Pulumi with GitHub Actions provided the team with a precise delta of changes to be made to the environment. Coupled with mandatory reviews from InfoSec and infrastructure, this significantly reduced the likelihood of deploying unapproved changes, thereby enhancing the reliability of their deployment processes.

Policy as Code Guardrails with Pulumi CrossGuard

Pulumi CrossGuard adds an extra layer of security and control and is used in conjunction with Azure Policies, which are used for auditing purposes. CrossGuard prevents the deployment of undesired, insecure, or expensive resources during the preview and deployment stage, thus preventing developers from even reaching Azure to provision resources. Custom error messages give developers context on why their deployment was not allowed.

Pulumi Cloud Policy Packs allow them to group and deploy many policies simultaneously. The Policy Packs prevent specified resources from being deployed into staging and live environments. For example, one policy requires all SQL databases to use TLS 1.2 by default and another ensures all storage buckets have public access disabled by default. These capabilities helped bolster the security of the bank’s cloud infrastructure.

Financial services cloud modernization with Pulumi

The DevOps and development teams at Washington Trust Bank rely on Pulumi as a key tool in their cloud modernization, while maintaining high security and quality standards. Pulumi played a vital role in streamlining their cloud infrastructure management, enabling their developers to be more productive, and improving the security and reliability of its cloud infrastructure.

Sign up for a free account to try deploying infrastructure on any cloud, or register for an upcoming workshop to learn more about how Pulumi can help you ship cloud infrastructure faster and more safely.

Go to more case studies

Azure Native Provider 2.0: Streamlined, Expanded, and More Powerful than Ever

Monica Rodriguez — Wed, 14 Jun 2023 14:00:00 -0400

Update: this content was updated on July 11 2023 to reflect the general availability of the 2.0 release.

We are thrilled to announce the release of the Pulumi Azure Native Provider 2.0, a significant upgrade to Pulumi’s native provider for Microsoft Azure. The Azure Native provider offers the most complete support for Azure possible - with same day access to the entire surface area of the Azure features from Azure Resource Manager. Every property of each module is always represented in the SDKs. The 2.0 release brings a host of exciting features and improvements for performance and usability that will enhance your experience with managing Azure resources and empower you to build robust and scalable cloud infrastructure more efficiently.

At Pulumi, we understand the importance of keeping up with the ever-evolving cloud landscape. The Pulumi Azure Native Provider 2.0 represents our commitment to providing you with the best tools to harness the full power of Microsoft Azure. With automatic generation from Azure API specs, we are able to provide you with same-day access to the entire Azure API surface including all available properties. Let’s dive into some of the key enhancements in this release!

Join Pulumi, Azure, and GitHub on Tuesday, September 19, 2023 for a live workshop on getting started with infrastructure as code on azure. You’ll learn how to use the Azure Native Provider and set up an automated deployment workflow through GitHub.

Reduced SDK Size for Faster Development

We’ve listened to your feedback and have made significant optimizations to the Azure Native Provider SDKs. With careful fine-tuning and restructuring, we have achieved a significant decrease in size of over 50% for SDKs with multi-versioned modules. This improvement translates into faster development times, reduced resource consumption, and an overall smoother experience when working with the provider.

So, how did we accomplish this? For starters, we’ve removed all deprecated Azure API modules up to the 2.0 release date. The bigger impact was made by identifying and removing all forward-compatible module versions. That is to say we’ve excluded any redundant versions and kept only the versions that introduce breaking changes. Where these versions are not the current latest and new default, they remain available as explicit versions.

You may be wondering about the significance between explicit and default versions. Well, when Azure releases new features they often create a new version of a service API. These versions are named using dates such as “2021-01-02” or “2022-05-08-preview”. There’s many versions of each module in the SDK, so we pick a version of each module for the top-level default. To learn more about module versions, visit the Azure Native Version Guide.

Refreshed Default Module Versions

In the latest release, we have refreshed the default module versions to align with the latest Azure API versions from Microsoft. With our continued commitment to same-day access to Azure API surface, you always have access to the most up-to-date features and capabilities offered by Azure services. By leveraging the latest module versions, you can take advantage of the latest and most desired features directly from Azure while building your infrastructure with Pulumi.

If you would like to upgrade to 2.x, but continue using the same Azure API version that was used in your 1.x, you can do that by specifying the compatible explicit version available in the 2.x provider. Shown below are examples of how that change might look.

- import { EventSubscription } from "@pulumi/azure-native/eventgrid";
+ import { EventSubscription } from "@pulumi/azure-native/eventgrid/v20200601";

- from pulumi_azure_native import eventgrid
+ from pulumi_azure_native.eventgrid import v20200601 as eventgrid20200601

- using EventGrid = Pulumi.AzureNative.EventGrid;
+ using EventGrid20200601 = Pulumi.AzureNative.EventGrid.V20200601;

- import eventgrid "github.com/pulumi/pulumi-azure-native-sdk/eventgrid/v2"
+ import eventgrid20200601 "github.com/pulumi/pulumi-azure-native-sdk/eventgrid/v2/v20200601”

- type: azure-native:eventgrid:Topic
+ type: azure-native:eventgrid/v20200601:Topic

Expanded Top-Level Default Module Coverage

We’re excited to expand our top-level default version coverage by 226 resources, 274 functions, and 5526 input properties in this release, bringing the total to 1,637, 2,015, and 30,652 respectively. With this extensive collection of modules at your disposal, you can easily provision and manage the full range of Azure services using Pulumi. Whether you’re working with virtual machines, databases, networking, or any other Azure service, the Azure Native Provider has you covered.

Resolved Title Case Inconsistency

For a consistent and predictable experience across the provider, we have resolved an issue with title case inconsistencies across resources and functions. All previous resource names have been aliased, and do not require any changes to the Pulumi program. However, functions that have a corrected name will need to be updated. This enhancement ensures a unified and predictable experience while working across resource types, making it easier for you to navigate and understand the provider’s capabilities.

Simplified User Assigned Identity Inputs

We have simplified the representation of user assigned identity inputs by recognizing them as string arrays. This change provides a more intuitive and clear approach when configuring user assigned identities for your Azure modules. You can now reference these as UserAssignedIdentities: [exampleUserAssignedIdentity.id] without jumping through any hoops.

import * as resources from "@pulumi/azure-native/resources";
import * as managedidentity from "@pulumi/azure-native/managedidentity";
import * as storage from "@pulumi/azure-native/storage";

// Create a resource group
const resourceGroup = new resources.ResourceGroup("my-resource-group");

// Create a user-assigned managed identity
const userAssignedIdentity = new managedidentity.UserAssignedIdentity("my-user-assigned-identity", {
 resourceGroupName: resourceGroup.name,
});

// Create a storage account that references the user-assigned managed identity
const storageAccount = new storage.StorageAccount("mystorageaccount", {
 resourceGroupName: resourceGroup.name,
 kind: "StorageV2",
 location: resourceGroup.location,
 identity: {
 type: "UserAssigned",
 userAssignedIdentities: [userAssignedIdentity.id],
 },
 sku: {
 name: "Standard_LRS",
 },
});

Before this change, the identity block would need to use an apply as follows:

user_assigned_identity.id.apply(lambda id: {id: {}})

Migrating from 1.x to 2.x

We recommend you update to the latest version of Azure Native 1.x prior to moving to 2.x. This will enable you to address existing deprecations and see the recommended substitutions ahead of the major version upgrade. Head over to the migration guide which outlines the necessary steps to update your existing Pulumi projects and ensuring a smooth migration experience.

Current users of the Pulumi Azure Classic Provider can follow the classic to native migration guide to take advantage of all the latest and greatest features available in Pulumi the Azure Native Provider.

While you can immediately start leveraging the improved performance, you may need to make some changes in order to continue using specific Azure API module versions or user assigned identity inputs. Use the Pulumi Azure Native Provider documentation within your IDE to determine the explicit API version that is available and fully compatible with your existing deployment.

The Pulumi Azure Native Provider 2.0 is available today for Pulumi programs using TypeScript, Python, .NET, and Go. To learn more about the Pulumi Azure Native Provider 2.0 and explore its capabilities, check out our updated documentation and resources. We value your feedback and encourage you to reach out in community slack or open an issue for any questions or suggestions.

Try out the Pulumi Azure Native Provider 2.0 today and take the next step in your journey with infrastructure as code on Microsoft Azure!

Getting Started

Try Infrastructure as Code on Azure by following this quick getting started guide.

Announcing OIDC Support for Pulumi Azure Providers

Thomas Kappler — Thu, 01 Jun 2023 00:00:00 +0000

We are happy to announce the delivery of Azure OIDC authentication, one of the most requested features for the Pulumi Azure Native Provider. With the v1.100.0 release, OpenID Connect (OIDC) authentication is now fully supported in both the Azure Native and Azure Classic providers. Let’s dig in to learn what it is, how it works, and why it’s useful.

Pulumi announced OIDC support for Deployments in January. This article is about the same OIDC protocol, used to authenticate your Pulumi program with Azure instead of Pulumi Deployments.

The What and Why of OIDC

OIDC stands for OpenID Connect, a standardized protocol for federated identity. This means that if you maintain an identity with two service providers, you can tell one of them to trust the other. Then, you can use credentials for the trusted service to get credentials for the other.

As an example, we’ll use a Pulumi program running in CI on GitHub Workflows, creating Azure resources. Without OIDC, this program would need a secret to authenticate with Azure - a client secret or a certificate. With OIDC, your program doesn’t need a secret. It can send its GitHub token to Azure instead. Based on the trust relationship between the two, Azure will exchange the GitHub token for an Azure token.

Secrets need to be safeguarded, rotated, and possibly revoked. If you’ve ever managed a system, whether production or CI/CD, the possibility of managing fewer secrets will be enticing. So how do we go about implementing this?

Enabling OIDC

There are two parts to enabling your Pulumi program to authenticate via OIDC. One is establishing the trust relationship between Azure and the other service that’s involved, like GitHub. This is a one-time operation. The second one is providing your program with the necessary configuration to perform the OIDC token exchange at runtime.

Fortunately, Microsoft has the first step covered with their establishing the trust relationship guide. The idea is that an Active Directory app registration holds the necessary federated credentials. Your program will then use this app’s tenant id to request the token exchange. The setup depends on whether you run on GitHub Actions, Kubernetes, or other providers.

On to the second step, configuring your Pulumi program. First, tell the Pulumi provider to use OIDC by setting the environment variable ARM_USE_OIDC or the Pulumi configuration azure-native:useOidc to true. Next, you’re in luck if your program runs on GitHub Actions: you’re done. GitHub exports the necessary values in form of variables that Pulumi understands.

For GitHub, pay close attention to the “entity type” of your Azure Active Directory credential as documented in the Azure guide. It can be a Git branch or tag, a pull request, or an environment as specified in the GitHub workflow. When your Action requests the OIDC token exchange, one of these needs to match exactly. This means that the only way to configure OIDC authentication for all branches or tags is to use environments in your workflows.

For other providers, you need to provide your Pulumi program with two more settings. Environment variable ARM_OIDC_REQUEST_TOKEN or configuration azure-native:oidcRequestToken is your provider’s token to exchange for an Azure token. ARM_OIDC_REQUEST_URL or azure-native:oidcRequestUrl is the URL to contact to initiate the token exchange.

A complete example

Let’s take a look at how the CI end-to-end tests of the Pulumi Azure Native provider are set up.

Configuration

First, we have an Active Directory App creatively named oidc-test. We simply copy its client and tenant ids and set them in the CI workflow, along with our subscription:

env:
ARM_CLIENT_ID: 11223344-****-****-****-************ [redacted]
ARM_SUBSCRIPTION_ID: 55667788-****-****-****-************ [redacted]
ARM_TENANT_ID: 99aabbcc-****-****-****-************ [redacted]
ARM_USE_OIDC=true

Note how there is no secret or certificate present.

We also give the required permissions to the workflow step where the authentication happens:

permissions:
id-token: write # required for OIDC auth

In Azure, we added the required credentials to the Active Directory App. You’ll find this under “Certificates & secrets” -> “Federated credentials” on the app’s page. Let’s look at two of the credentials. Both enable OIDC for all pull requests on the repository, one for each Azure provider.

End to End Flow

Now, when our GitHub workflow for CI tests runs, the Azure provider knows to authenticate via OIDC because ARM_USE_OIDC is set. It performs the following steps:

Call GitHub’s OIDC provider, found at the URL that GitHub automatically exports as ACTIONS_ID_TOKEN_REQUEST_URL. For authentication, it includes a token GitHub generates for each workflow run and exports as ACTIONS_ID_TOKEN_REQUEST_TOKEN. The response is an OIDC token in form of a JSON Web Token (JWT).
Send the OIDC token to Azure’s Active Directory endpoint. Include the client and tenant ids of our Active Directory App that we configured via ARM_CLIENT_ID and ARM_TENANT_ID. Active Directory looks up the trust relationship we configured and validates the token, and responds with a valid access token for Azure.
The Pulumi provider can now access Azure resources.

That’s it! Your CI job now runs without maintaining an Azure secret in GitHub, or wherever your Pulumi program runs.

Wrapping up

This article only demonstrated the basics. You can also customize your OIDC token’s claims to control access to Azure in a more fine-grained manner.

I hope this helps you simplify your Azure authentication. Please try it out and let us know if you hit any issues in the Pulumi Community Slack!

Managing NOAA Open Data across Multiple Clouds with Pulumi

Denis Willett, PhD — Tue, 08 Nov 2022 21:01:21 +0000

Denis Willett is a software engineer at the North Carolina Institute of Climate Studies who works on the NOAA Open Data Dissemination Program. His work focuses on leveraging cloud technologies for the development of data processing and machine learning pipelines. Denis did his PhD in Entomology and Nematology at University of Florida and his undergraduate and masters work in Earth Systems at Stanford University. You can read his full bio here.

NOAA Open Data Dissemination (NODD) makes environmental data freely and publicly accessible across Amazon Web Services (AWS), Microsoft Azure (Azure), and Google Cloud Platform (GCP). These data include near real-time satellite imagery, weather models, radar feeds, drought information, ocean databases, and a suite of climate data records among many others. This program supports more than 220 datasets and over 24PB of open data. Since its inception, the program has been growing rapidly, almost doubling in size over the past year.

Availability of the petabyte scale environmental data on the cloud is only one aspect of NODD. The program places a premium of performant data delivery and access. NODD data pipelines provide resilient and low, in many cases near real-time, latencies to NOAA’s core data offerings. In addition, NODD provides performant, parallel access to these data supporting billions of requests per day and accessions of individual datasets exceeding 1PB in a single day.

To support this program, the North Carolina Institute for Climate Studies (NCICS) through the Cooperative Institute for Satellite Earth System Studies (CISESS) engineers infrastructure on all three major public clouds ranging from object stores to messaging platforms, data ingest and transformation pipelines, and monitoring systems. These systems are deployed and managed by a very small team that, by necessity, must be agile, resilient and facilitate low latency data transfers at petabyte scale. Given the scale and diversity of resources managed through this initiative, we began looking for tools to facilitate multi-cloud management using infrastructure as code (IAC).

Before Pulumi

Prior to beginning to transition to Pulumi, our team built infrastructure primarily using the Command Line Interface (CLIs) and consoles of each cloud service provider. While this worked well, it required extensive Cloud Service Partner (CSP) specific training to be able to not only navigate the nuances of each provider’s offerings, but also the unique interface to deploy resources. Changing and updating infrastructure in this manner resulted in long development cycles where upgrades were mostly manual and composed of repetitive tasks.

Because of the manual nature of these deployments across three different cloud service providers, infrastructure began to sprawl. A clear snapshot of what resources were deployed where became difficult to compile and management of legacy and deprecated systems depended on manual intervention for clean-up. Infrastructure also began to drift. What started as uniform deployment of resources across multiple cloud platforms morphed as manual updates to each instance resulted in unique environments that were hard to replicate if they had to be deleted and redeployed.

As an example, our program relies on Apache NiFi deployments on AWS, GCP, and Azure to coordinate and manage petabyte scale data transfers while managing data provenance. Drift in these deployments makes it especially difficult to redeploy identical configurations (even though we were using Ansible and Containerization) if they go down.

An additional consequence of this approach is knowledge silos. The team member who deployed a group of resources on AWS had trouble (even with extensive documentation) communicating reusable architectures to another team member who was working on similar situations in Azure. While there are obvious nuances relevant to each cloud environment, our need to replicate similar infrastructure in a multi-cloud environment at scale necessitated extensive detailed communication in a team environment. Questions like: “What is the ARN of the most recent version of this service?” and “What queues do we have on GCP?” required communication and time taken by the individual responsible to answer those questions.

How and why we chose Pulumi

As our team grew and our platform scaled (more than doubling in storage size over the past year by more than 10PB), we began to explore tooling to help us better navigate and manage our multi-cloud and multi-account environment. The nature of the NOAA Open Data Dissemination program agreements with each cloud service provider (CSP) meant that we had multiple accounts with different permissions, funding, and configuration on each CSP, resulting in flexible options.

We began looking at infrastructure as code (IAC) solutions and initially considered many of the cloud-specific options: CloudFormation on AWS, Deployment Manager on Google, and Resource Manager on Azure. While these were nice for automation, we quickly discarded these as options because each had an individual learning curve for that environment; they did not translate well in a multi-cloud environment. These tools also did not have the control features of a full-fledged programming language; looping and if-then statements were challenging to implement.

We also considered other Infrastructure as Code providers. While these solutions would meet a lot of our needs, and one of our team members had extensive experience with one of these tools, the ability to use a common tool seamlessly in a multi-cloud environment was attractive. However, the learning curve associated with a domain specific language was cause for reticence. In addition, we really wanted to be able to use the features of a full-fledged programming language.

After experimenting with a few IAC options, our research institute began using Pulumi in late 2021 and immediately began implementing it to expand our infrastructure.

Benefits of using Pulumi for multi-cloud infrastructure as code

Pulumi had all the benefits we were looking for in a multi-cloud infrastructure as code platform. In terms of automation, manual checklists could be converted to code reducing both deployment time and human errors in deployment. This automation with infrastructure as code (and accompanying state management) allowed us to adopt an immutable infrastructure paradigm where old resources are replaced with new updated infrastructure. While these benefits are accessible via other IAC tools, we particularly appreciated the Pulumi interface to be able to quickly access and inspect infrastructure deployments.

We saw immediate wins for our teams in the following areas:

Drift was eliminated. Single source of truth, version controlled (and tagged) code documented exactly what was deployed where. When updates were needed, the code was updated and redeployed without manually tweaking individual resources through the console.
Management of legacy and deprecated resources were obviated. With IAC managed deployment that would automatically clean up old resources, we saved many future hours cleaning up unused cloud resources.
Team collaboration was enhanced. With a single source of truth and a visual snapshot of resources and deployments, the number of ‘What was the ARN of that resource again?” type questions dropped considerably. Team members could simply look at the deployment in one location and see all of the resources across all three major clouds. This type of friction-reduction really enhances team productivity.

In addition to these IAC benefits, we saw a number of key advantages in implementing Pulumi. First and foremost was the ability to use full-featured programming languages to deploy IAC solutions in a multi-cloud environment. This not only allowed us to fully take advantage of programming control structures (e.g., need 100 different rules on AWS? Now you do not have to manually script each one, just put it in a loop), but also flattened the learning curve for adoption. Our team already used Python extensively in our day-to-day work. Adopting Pulumi was almost as simple as importing a package. Accessing Pulumi through Python made it much easier to embrace.

This accessibility through Python also meant that learning how to create, deploy, and share reusable templates was trivial as all team members already knew how to build, share, and import modules in Python. The ability to rapidly share these templates accelerated our development and allowed for standardization around best practices. For example, we use serverless capabilities on all three CSPs. Once we had a template for deploying our function as a service (FAAS) code on one platform, we did not have to reinvent the wheel or remember to go through a checklist; it was as simple as importing our internal FAAS module and pointing it to the correct code to deploy.

Next steps

Pulumi has become an automation and collaboration tool that is accelerating our ability to provide petabyte scale data to the public in a multi-cloud environment. As we continue to scale our program, Pulumi is allowing us to leverage a small team to manage increasingly larger, more complex deployments in a dynamic environment. In addition, it is rapidly becoming a key player in a cross-cloud fabric that we are building to facilitate working across multiple platforms. By providing a similar, intuitive interface through our language of choice, Python, it is allowing us to more quickly adapt and reproducibly deploy infrastructure across AWS, Azure, and GCP.

Please reach out to us with your thoughts, reactions, and comments at NODD@NOAA.GOV.

Introducing the Azure Static Website Component

Sean Holung — Tue, 11 Oct 2022 00:00:00 +0000

Deploying a static website often involves provisioning a number of pieces of infrastructure and stitching those pieces together in a way to make the site accessible to your users. A static website typically consists of HTML, CSS, and JavaScript files along with any other static assets the site might need to render such as PNG and SVG files for example. These files are then uploaded to a storage bucket where they can be served from. This post will demonstrate how to easily deploy your static website to Azure and make it available for public access.

Azure Static Website Component

Pulumi components enable us to create re-usable abstractions that can perform complex tasks all behind a simple interface the user can programmatically interact with. The Azure Static Website component looks to take all of the complexity of getting a static website deployed to Azure and simplify it down to just consuming a simple component and passing it a few input arguments. This component relieves the complexities of this process by allowing you to simply tell the component where your files are located and it will take care of all the rest.

This component does the following:

Provisions an Azure storage account
Uploads the website contents located in the specified directory
Optionally can configure a CDN, custom domain, and certs.

Using the component to deploy a static website

Let’s walk through a simple example of using this component to deploy a static website. Today, we are going to provision a storage account, upload the website contents, and wire it up to an Azure CDN.

In order to follow along with this example you will need to have the following:

Pulumi CLI installed on your machine
Access to an Azure account to provision the infrastructure
Static site to upload

See our getting started guide for information on how to configure Pulumi and Azure.

We will provision a number of pieces of infrastructure in Azure to enable serving our static website. The main ones are a Storage Account to contain all of our website files and a CDN. Let’s start by creating a new Pulumi project. First, create a new directory on your machine where the Pulumi project will live. A common pattern is to include the infrastructure configuration in a directory alongside the website you will be deploying. You can create a directory called infrastructure to house the Pulumi program or you can use another name if you prefer. This allows us to easily reference the location of the contents of your site as well as keeps your infrastructure code along-side your application. Pulumi supports multiple programming languages such as TypeScript, Python, Go, .NET, and even markup languages like YAML. Once you have created the directory, run the following command for your language of choice inside the directory:

pulumi new azure-typescript

pulumi new azure-python

pulumi new azure-csharp

pulumi new azure-go

pulumi new azure-yaml

There will be some prompts that appear asking you a few questions. Feel free to accept the defaults or change them to your desired preference. This command generated a new project and created a few files for you. You can copy the code examples below for the language you chose to use.

import * as pulumi from "@pulumi/pulumi";
import * as website from "@pulumi/azure-static-website";

const site = new website.Website("site", {
 sitePath: "../site", // replace with path containing website contents
 withCDN: true,
});

export const cdnURL = site;

import pulumi
import pulumi_azure_static_website as azure_static_website

site = azure_static_website.Website("site",
 site_path="../site", # replace with path containing website contents
 with_cdn=True)
pulumi.export("cdnURL", site.cdn_url)

using System.Collections.Generic;
using Pulumi;
using AzureStaticWebsite = Pulumi.AzureStaticWebsite;

return await Deployment.RunAsync(() =>
{
 var web = new AzureStaticWebsite.Website("web", new()
 {
 WithCDN = true,
 SitePath = "../site", // replace with path containing website contents
 });

 return new Dictionary<string, object?>
 {
 ["websiteURL"] = web.CdnURL,
 };
});

package main

import (
 "github.com/pulumi/pulumi-azure-static-website/sdk/go/azure-static-website"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 web, err := azure - static - website.NewWebsite(ctx, "web", &azure-static-website.WebsiteArgs{
 WithCDN: pulumi.Bool(true),
 SitePath: pulumi.String("../site"), // replace with path containing website contents
 })
 if err != nil {
 return err
 }
 ctx.Export("websiteURL", web.CdnURL)
 return nil
 })
}

name: az-website
runtime: yaml
description: A static website build with pulumi-azure-static-website.
resources:
 web:
 type: "azure-static-website:index:Website"
 properties:
 withCDN: true
 sitePath: "../site"
outputs:
 websiteURL: ${web.cdnURL}

This code creates a new instance of the Website component and sets a couple of properties. sitePath is the location where your website contents live. The sitePath specified should be the output location of your website’s build not the overall directory where your application lives. For example, if using a framework like React, the build output is usually placed in a directory called build. In addition, we set withCDN to true to let the component know that you would like to provision a CDN as well. It also exports the cdnURL property, which is the URL where the site can be accessed. That’s all that is needed and now we are ready to deploy!

You can now run pulumi up to deploy the site to Azure. This will first show a preview of the resources that will be provisioned. You can go ahead and accept by selecting yes.

In a few minutes your site will be provisioned and ready to access. Use the cdnURL that was output at the end of the provisioning to access the site!

As you can see, the Azure static website component made this task very easy. With just a few lines of code we were able to provision our site.

If you would like to learn more about Pulumi, here are some links you may find interesting:

Visit our Getting Started to quickly get up and running with Pulumi.
View the GitHub repo for the Azure static website component.
Visit our registry page to more components we have available for you to consume.
Check out our new templates that make it quick and easy to deploy common cloud architectures.

How Elkjøp Nordic enables self-service infrastructure for developers

George Huang — Fri, 01 Jul 2022 00:00:00 +0000

At PulumiUP 2022, Tomas Jansson, software architect at Elkjøp Nordic, gave a presentation on how to enable developers to self-service infrastructure by using Pulumi’s Automation API.

Elkjøp Nordic is the leading consumer electronics retailer in the Nordics. The company sells consumer electronics, mobile phones, computers, white goods, domestic appliances, and services linked to these products both directly to consumers and to businesses. It is an omnichannel retailer and serves customers both online and through more than 400 stores. Elkjøp has retail outlets in Norway, Sweden, Finland and Denmark, and franchise operations in Greenland and Faroe Islands.

To support the company’s modernization strategy, Tomas developed a self-service infrastructure platform that would enable any developer to easily provision cloud infrastructure that uses approved resources and security practices. The goal was to empower teams at Elkjøp to increase their development velocity by using the cloud, while maintaining guardrails that uphold security and compliance.

Watch the full presentation below or read on to learn the highlights of his presentation:

The Problem: Balancing Agility and Governance

To achieve his goals, Tomas knew he had to solve the problem of balancing freedom with control. On the one hand, he wanted to foster the creativity of his developers and encourage innovation. He wanted his team to feel they were trusted and had the room to create the best solutions they could. On the other hand, he knew he had to maintain some control. Elkjøp needed to keep its applications secure. It also needed good governance so that teams can keep track of who is making changes. Tomas also wanted to limit the impact of deploying untested code. Code that was still being developed needed to be confined to the developer’s own environment. Finding the right balance between independence and control was paramount. Tomas believed this would result in great software and in developers who would enjoy their work.

The Solution: A Self-Service Infrastructure Platform

Tomas’ solution was to build a self-service infrastructure platform. Self-service infrastructure makes it possible for developers to easily access the infrastructure they need while limiting access to resources they don’t need. In effect, self-service infrastructure is a walled garden. Within the garden, developers have all the freedom they need. However, nothing they do affects what’s outside the wall. Code that causes unintended changes only affects them and no one else.

Tomas built an application that provides a “walled garden” of self-service infrastructure. Developers can create the environments they need, including an Azure resource group and a Kubernetes namespace, all through a graphical user interface. Developers can define whether the environment is for development, test or production. They can also assign values, such as which team members should have admin privileges to the associated GitHub repositories or who can contribute. From there, the platform handles provisioning and configuring all of these resources.

Here is an example that shows how a developer can create a repository simply by selecting a few parameters from a drop-down list.

Tomas determined that the best way to implement self-service infrastructure was with Pulumi and its Automation API. By using Pulumi, he could use standard programming languages to define infrastructure while using familiar software tools like IDEs and test frameworks. Pulumi also natively supports Azure and Kubernetes with 100% coverage of each provider’s APIs and same-day access to new features and updates. Finally, the Pulumi Automation API would enable him to program infrastructure automation directly into his application.

The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI. Automation API encapsulates the functionality of the CLI (pulumi up, pulumi preview, pulumi destroy, pulumi stack init, etc.) but with more flexibility since infrastructure operations can be controlled programmatically.

How the self-service infrastructure platform was built

Here is the workflow for the Elkjøp self-service infrastructure platform.

The self-service platform is a web application that runs the Pulumi Automation API on the server side. The application uses Pulumi to provision and configure every environment resource such as Azure resource groups, Kubernetes namespaces, service principals, and Kubernetes service accounts. Each environment comes with a Git repository that’s used by developers to manage their deployments. The Git repositories are the locus of each environment because they store everything needed to deploy changes such as infrastructure code and environment credentials.

Using the Pulumi Automation API, the application creates an Azure resource group, a team in both Azure AD and GitHub, and a new GitHub repository. The application then grants administrative access to the GitHub repo to members of the AD group. In addition to creating a Git repository for each environment, the application uses stack references for each Azure environment to inject the associated credentials into the GitHub Secret Store. These credentials are scoped to each GitHub environment so that developers can only work in their own environment. If a team has multiple environments, each environment has its own credentials so developers can’t, for example, deploy from a test environment to a production environment. Secrets are managed through the Pulumi Service.

Every new repository comes with Pulumi programs that developers can use to deploy their application. GitHub Actions initiate the deployment. When an action triggers, Pulumi reads the credentials that were generated by the self-service application, allowing Pulumi to deploy new Kubernetes or Azure resources to the environment.

Watch the demo

To illustrate how Elkjøp’s self-service platform works, Tomas presented a simplified demo application that’s based on Elkjøp’s production platform. The code for the application is available at https://github.com/mastoj/pulumi-automation-demo.

The demo is a TypeScript application that includes an API that provisions Azure and GitHub resources. Pulumi Automation API code is used to deploy new stacks by calling handler code, which is a Pulumi program that defines resources and outputs. The handler code can create Azure resource groups or GitHub repositories, and stack references are used so that outputs generated by the Azure resources can be stored in GitHub (e.g., resource group credentials).

Ready to dive into how this works in detail? Watch the demo in the video below starting around 10:20.

Next steps

After watching the demo of a self-service infrastructure platform, you can try it out for yourself by checking out the demo code. You can also learn more about Pulumi Automation API in our documentation.

If you’re new to Pulumi, then follow our getting started guide.

Deploy Azure Container Apps with Docker and Pulumi

Mikhail Shilkov — Tue, 02 Nov 2021 09:00:00 -0700

Today, Microsoft announced a new general-purpose serverless container platform: Azure Container Apps. Container Apps is a fully managed platform for microservice applications that runs on top of Kubernetes and open-source technologies like KEDA, Envoy, and Dapr.

Container Apps are designed to abstract infrastructure management with flexible serverless containers. Developers can run containers at scale without the burden of standing up and managing a Kubernetes cluster manually.

We are happy to announce same-day support for Azure Container Apps in the Pulumi Azure Native Provider, which covers 100% of the Azure Resource Manager APIs and gives you highest fidelity integration with Azure’s resources.

Azure Container Apps QuickStart

Ready to get up and running quickly right away?

Bootstrap a project $ pulumi new https://github.com/pulumi/apps/container-apps
Add your container logic to the app folder
Deploy with $ pulumi up
Test with $ curl $(pulumi stack output url)

For additional information on how Azure Container Apps work and advanced options, please read on.

The new service supports a broad range of usage scenarios, including

Microservices over HTTP or gRPC
HTTP APIs and websites
Event processing workers
Long-running background jobs

Serverless containers

Container Apps provide serverless containers for microservice developers.

Managed infrastructure. Microsoft operates the control plane that takes care of orchestrating containers and their configuration, allowing developers to focus on apps, not cloud infrastructure.
Fully integrated auto-scaling with scale to zero. The platform relies on Kubernetes Event-driven Autoscaling (KEDA) to scale apps and microservices dynamically based on HTTP traffic or event workload.
Consumption pricing. The billing model is based on the actual resource consumption with per-second granularity. Applications incur charges per request, compute time and memory used with no need to pre-provision a fixed capacity.
Any language, any base image. Container Apps put no limitation on the container images. You may use an arbitrary base image and host any web server or a console application, ensuring flexibility and interoperability with other container orchestrators.

How it works

Microsoft has built Container Apps as a managed service on the foundation of open-source technology in the Kubernetes ecosystem. This enables teams to build microservices without having to manage Kubernetes directly while providing application portability by leveraging open standards and APIs. Behind the scenes, every container app runs on the Azure Kubernetes Service (AKS). Enabling open-source integrations include:

Envoy, a built-in ingress controller that exposes user containers internally and externally via HTTP endpoints. It supports multiple container versions with dynamic load balancing and several traffic rollout strategies.

KEDA enables dynamic auto-scaling for user applications based on the current workload, including scaling down to zero during idle periods.

Container Apps are also tightly integrated with Dapr—an open-source runtime system designed to support cloud-native microservice applications. It provides extra blocks for service discovery, state management, asynchronous message passing.

How it’s different

A few other services provided by Microsoft Azure and other cloud providers operate in the space of running container-based workloads:

Azure Kubernetes Service delivers the full power of Kubernetes but requires expertise in configuring and operating the cluster. When building on AKS, users handle most infrastructure management aspects themselves. Instead, Container Apps provide a platform built on top of AKS, focusing on developer productivity and switching to consumption-based pricing.

Azure Container Instances (ACI) provides atomic infrastructure units with per-usage pricing. However, ACI comes without higher-level functionality like auto-scaling, load balancing, versioning, and managed rollouts.

Azure App Service is a Platform-as-a-Service comparable to Container Apps in terms of being simple-to-operate and developer-friendly. App Service can also run arbitrary containers. However, it is best suited to run websites. The billing model is mostly capacity-based with some built-in autoscaling but without scaling to zero.

Azure Functions is a developer-oriented truly-serverless offering. However, it comes with an opinionated programming model that is focused on achieving a high developer productivity as long as your application can use the Azure Functions SDK or container base images. Unlike Container APps, it does not support long-running jobs in consumption mode.

Comparing to other vendors: Azure Container Apps are in the same space as Google Cloud Run and AWS App Runner. In contrast to the competition, Azure Container Apps is built on Kubernetes and related open-source projects, which should benefit its users in terms of interoperability and transparency. Additionally, Container Apps is the only service that provides features like service discovery for microservices-style communication out of the box.

Example: Run an HTTP API with Azure Container Apps and Pulumi

Let’s walk through the steps to build an example application with Azure Container Apps using infrastructure as code in familiar languages. In this scenario, we create an HTTP application that is available via a public domain name. We’ll use Pulumi to provision the necessary resources. In this example, we will use TypeScript however you could also use JavaScript, Python, Go, and C#.

You can check out the complete source code in the Pulumi Examples:

Define a Dockerfile and app

Here are the key features of the container image for our application:

Based on the node:8.9.3-alpine image
Installs express with NPM
Runs a node web app using index.js and index.html user files

Full Dockerfile.

Set up the environment

The resource KubeEnvironment defines a cluster that can host multiple Container Apps. Behind the scenes, it creates an AKS cluster in a subscription managed internally by Microsoft and deploys the Apps control plane.

import * as web from "@pulumi/azure-native/web/v20210301";

const env = new web.KubeEnvironment("env", {
 resourceGroupName: resourceGroup.name,
 type: "Managed",
});

using Pulumi.AzureNative.Web.V20210301;

var kubeEnv = new KubeEnvironment("env", new KubeEnvironmentArgs
{
 ResourceGroupName = resourceGroup.Name,
 Type = "Managed"
});

import pulumi_azure_native.web.v20210301 as web

kube_env = web.KubeEnvironment("env",
 resource_group_name=resource_group.name,
 type="Managed")

import web "github.com/pulumi/pulumi-azure-native/sdk/go/azure/web/v20210301"

kubeEnvironment, err := web.NewKubeEnvironment(ctx, "kubeEnvironment", &web.KubeEnvironmentArgs{
 ResourceGroupName: resourceGroup.Name,
 Type: pulumi.String("Managed"),
})

Build and publish a container image

We can build the Docker image and publish it to a new Azure Container Registry (ACR) repository. The code below assumes

import * as docker from "@pulumi/docker";
import * as containerregistry from "@pulumi/azure-native/containerregistry";

const customImage = "node-app";
const registry = new containerregistry.Registry("registry", {
 resourceGroupName: resourceGroup.name,
 sku: {
 name: "Basic",
 },
 adminUserEnabled: true,
});

const credentials = containerregistry.listRegistryCredentialsOutput({
 resourceGroupName: resourceGroup.name,
 registryName: registry.name,
});
const adminUsername = credentials.apply(c => c.username!);
const adminPassword = credentials.apply(c => c.passwords![0].value!);

const myImage = new docker.Image(customImage, {
 imageName: pulumi.interpolate`${registry.loginServer}/${customImage}:v1.0.0`,
 build: { context: `./${customImage}` },
 registry: {
 server: registry.loginServer,
 username: adminUsername,
 password: adminPassword,
 },
});

using Pulumi.AzureNative.ContainerRegistry;
using Pulumi.Docker;

var registry = new Registry("registry", new RegistryArgs
{
 ResourceGroupName = resourceGroup.Name,
 Sku = new SkuArgs { Name = "Basic" },
 AdminUserEnabled = true
});

var credentials = Output.Tuple(resourceGroup.Name, registry.Name)
 .Apply(items =>
 ListRegistryCredentials.InvokeAsync(new ListRegistryCredentialsArgs
 {
 ResourceGroupName = items.Item1,
 RegistryName = items.Item2
 }));
var adminUsername = credentials.Apply(c => c.Username);
var adminPassword = credentials.Apply(c => c.Passwords[0].Value);

var customImage = "node-app";
var myImage = new Image(customImage, new ImageArgs
{
 ImageName = Output.Format($"{registry.LoginServer}/{customImage}:v1.0.0"),
 Build = new DockerBuild { Context = $"./{customImage}" },
 Registry = new ImageRegistry
 {
 Server = registry.LoginServer,
 Username = adminUsername,
 Password = adminPassword
 }
});

from pulumi_azure_native import containerregistry
import pulumi_docker as docker

registry = containerregistry.Registry("registry",
 resource_group_name=resource_group.name,
 sku=containerregistry.SkuArgs(name="Basic"),
 admin_user_enabled=True)

credentials = pulumi.Output.all(resource_group.name, registry.name).apply(
 lambda args: containerregistry.list_registry_credentials(
 resource_group_name=args[0],
 registry_name=args[1]))
admin_username = credentials.username
admin_password = credentials.passwords[0]["value"]

custom_image = "node-app"
my_image = docker.Image(custom_image,
 image_name=registry.login_server.apply(
 lambda login_server: f"{login_server}/{custom_image}:v1.0.0"),
 build=docker.DockerBuild(context=f"./{custom_image}"),
 registry=docker.ImageRegistry(
 server=registry.login_server,
 username=admin_username,
 password=admin_password))

import (
 "github.com/pulumi/pulumi-azure-native/sdk/go/azure/containerregistry"
 "github.com/pulumi/pulumi-docker/sdk/v3/go/docker"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

registry, err := containerregistry.NewRegistry(ctx, "registry", &containerregistry.RegistryArgs{
 ResourceGroupName: resourceGroup.Name,
 Sku: containerregistry.SkuArgs{
 Name: pulumi.String("Basic"),
 },
 AdminUserEnabled: pulumi.Bool(true),
})
if err != nil {
 return err
}
credentials := pulumi.All(resourceGroup.Name, registry.Name).ApplyT(
 func(args []interface{}) (*containerregistry.ListRegistryCredentialsResult, error) {
 resourceGroupName := args[0].(string)
 registryName := args[1].(string)
 return containerregistry.ListRegistryCredentials(ctx, &containerregistry.ListRegistryCredentialsArgs{
 ResourceGroupName: resourceGroupName,
 RegistryName: registryName,
 })
 },
)

adminUsername := credentials.ApplyT(func(result interface{}) (string, error) {
 credentials := result.(*containerregistry.ListRegistryCredentialsResult)
 return *credentials.Username, nil
}).(pulumi.StringOutput)
adminPassword := credentials.ApplyT(func(result interface{}) (string, error) {
 credentials := result.(*containerregistry.ListRegistryCredentialsResult)
 return *credentials.Passwords[0].Value, nil
}).(pulumi.StringOutput)

newImage, err := docker.NewImage(ctx, "node-app", &docker.ImageArgs{
 ImageName: pulumi.Sprintf("https://%s/node-app:v1.0.0", registry.LoginServer),
 Build: docker.DockerBuildArgs{
 Context: pulumi.String("/node-app"),
 },
 Registry: docker.ImageRegistryArgs{
 Server: registry.LoginServer,
 Username: adminUsername,
 Password: adminPassword,
 },
})
if err != nil {
 return err
}

Ship containers to Azure with Pulumi

Use the Azure Native provider to build a Docker image, publish it to Azure Container Registry, and deploy a serverless Container App from one program. Provision and manage it all in the language you already use.

Get started

Deploy the container app

Finally, we can define the Container App itself. We point the App to the environment resource and instruct it to run our custom image. Image container credentials are specified in the configuration block, with the password marked as a secret. We’ve also enabled external ingress to publish the app on the web.

const containerApp = new web.ContainerApp("app", {
 resourceGroupName: resourceGroup.name,
 kubeEnvironmentId: env.id,
 configuration: {
 ingress: {
 external: true,
 targetPort: 80,
 },
 registries: [{
 server: registry.loginServer,
 username: adminUsername,
 passwordSecretRef: "pwd",
 }],
 secrets: [{
 name: "pwd",
 value: adminPassword,
 }],
 },
 template: {
 containers: [{
 name: "myapp",
 image: myImage.imageName,
 }],
 }
});

export const url = pulumi.interpolate`https://${containerApp.configuration.ingress.fqdn}`;

var containerApp = new ContainerApp("app", new ContainerAppArgs
{
 ResourceGroupName = resourceGroup.Name,
 KubeEnvironmentId = kubeEnv.Id,
 Configuration = new ConfigurationArgs
 {
 Ingress = new IngressArgs
 {
 External = true,
 TargetPort = 80
 },
 Registries = {
 new RegistryCredentialsArgs
 {
 Server = registry.LoginServer,
 Username = adminUsername,
 PasswordSecretRef = "pwd"
 }
 },
 Secrets = {
 new SecretArgs
 {
 Name = "pwd",
 Value = adminPassword
 }
 },
 },
 Template = new TemplateArgs
 {
 Containers = {
 new ContainerArgs
 {
 Name = "myapp",
 Image = myImage.ImageName
 }
 }
 }
});

this.Url = Output.Format($"https://{containerApp.Configuration.Apply(c => c.Ingress).Apply(i => i.Fqdn)}");

container_app = web.ContainerApp("app",
 resource_group_name=resource_group.name,
 kube_environment_id=kube_env.id,
 configuration=web.ConfigurationArgs(
 ingress=web.IngressArgs(
 external=True,
 target_port=80),
 registries=[web.RegistryCredentialsArgs(
 server=registry.login_server,
 username=admin_username,
 password_secret_ref="pwd")],
 secrets=[web.SecretArgs(
 name="pwd",
 value=admin_password)],
 ),
 template=web.TemplateArgs(
 containers=[web.ContainerArgs(
 name="myapp",
 image=my_image.image_name)]))

pulumi.export("url", container_app.configuration.apply(lambda c: c.ingress).apply(lambda i: i.fqdn))

containerApp, err := web.NewContainerApp(ctx, "app", &web.ContainerAppArgs{
 ResourceGroupName: resourceGroup.Name,
 KubeEnvironmentId: kubeEnvironment.ID(),
 Configuration: web.ConfigurationArgs{
 Ingress: web.IngressArgs{
 External: pulumi.Bool(true),
 TargetPort: pulumi.IntPtr(80),
 },
 Registries: web.RegistryCredentialsArray{
 web.RegistryCredentialsArgs{
 Server: registry.LoginServer,
 Username: adminUsername,
 PasswordSecretRef: pulumi.String("pwd")},
 },
 Secrets: web.SecretArray{
 web.SecretArgs{
 Name: pulumi.String("pwd"),
 Value: adminPassword,
 },
 },
 },
 Template: web.TemplateArgs{
 Containers: web.ContainerArray{
 web.ContainerArgs{
 Name: pulumi.String("myapp"),
 Image: newImage.ImageName,
 },
 },
 },
})
if err != nil {
 return err
}

ctx.Export("url", pulumi.Sprintf("https://%s", containerApp.LatestRevisionFqdn))

Test the app

And that is it! We run pulumi up to get the application up and running. Once the deployment completes, we can send an HTTP request and check the response.

$ curl $(pulumi stack output url)
<html>
<body>
<h1>Your custom docker image is running in Azure Container Apps!</h1>
</body>
</html>

Conclusion

Azure Container Apps enable you to build applications in your favorite language with any dependencies and tools, package them as a container image, and deploy them in seconds. Container Apps abstract away infrastructure management by automatically scaling up and down to zero and only charging for the exact resources you use.

This post shows how to use Pulumi to build a container image and publish it as an Azure Container App. Pulumi makes it easy to create artifacts and provision and manage cloud infrastructure on any cloud using familiar programming languages, including C#, TypeScript, Python, and Go. Docker images, ACR registries, container environments, and Apps can be managed within the same infrastructure definition.

Further steps

Complete Azure Container Apps example

Azure Container Services Compared: ACI vs App Service vs AKS

Lee Briggs — Tue, 12 Oct 2021 08:00:00 -0700

Containers have emerged as one of the de facto standards for running software. When adopted with the right mindset, they can drastically improve the development lifecycle and help to close the loop between local development and running your applications in the cloud.

If you’re at the stage of trying to run your application in Microsoft Azure, the choices can be overwhelming. The Azure Container product page lists 7 different products on their landing page, and for new users it can often be difficult to decide which of the myriad products is right for their use case. What can make it even more confusing is that often these container services can be interoperable, meaning you can use one container product from another!

In this post, we’re going to examine each of the main container services offered in Azure and then examine what they’re good for and what they might not be so good for. Let’s take a look!

Azure Container Instances

Azure Container Instances (ACI) bills itself as an offering that lets you “easily run containers on Azure without managing servers.”

Launched in July 2017, it was arguably the first “serverless” container offering from the major cloud providers.

What’s good about it?

ACI is a Platform-as-a-Service (PaaS) type of product that is designed to remove the burden of launching and running containers.

Simplicity

Azure Container Instances has been designed from the ground up to be straightforward to use. It’s designed to get your container launched as quickly as possible, even including integrations with many of the tools you’re probably already familiar with if you’re using containers. One example is the integration with the Docker CLI.

In many cases, the only configuration options you need to pass to your ACI provisioning mechanism is the image you’re running and some sizing decisions, like how many CPUs and how much memory you need. There is some flexibility in this decision process, but having fewer required options means you’re not bogged down with complex architectural decisions when trying to get your container running.

This lends itself particularly well to web server projects, especially at smaller scales. You can launch applications very quickly and easily by specifying the image you’ve built, and your application can be running in very short order.

Start-Up Times

ACI Containers start fast—often in a matter of seconds. This speed really helps the developer lifecycle and helps to create productivity when you’re developing your application.

Pricing

ACI will only bill you for the time your applications are running. It offers no start-up costs (which goes great with the fast start times!) and per-second billing, meaning you only pay for every second the application is actually up. The pricing is also extremely competitive against other cloud providers.

The Other Stuff

From a security perspective, ACI separates your container from others running in the same environment, meaning your application will have the same level of security as if it was running on a different virtual machine. This separation really helps to provide peace of mind and is yet another benefit of the serverless model—less infrastructure means less worries.

As expected from Microsoft, ACI has excellent support for Windows containers and .NET platform applications, which is lacking around other cloud providers. If you need to run Windows containers, this support is a huge benefit.

What’s not great about it?

Scaling

ACI supports customizing the amount of resources you can assign to a container, but it will only run one copy. There’s no horizontal scaling available, so if you need more resources, you only have one option: scaling vertically. It is possible to run N number of ACI instances and configuring load balancers across them, but it’s a very manual process and can be awkward to manage and scale successfully.

If you’re running a webserver application, horizontal scaling behind a load balancer might be a better option, so this lack of scaling flexibility and manual processing can be a real shortcoming.

In addition to this opinionated scaling mechanism, there’s also no auto scaling option for ACI. If you’re finding that you’re hitting the limits of your ACI deployment, you’ll need to manually scale the service.

Configuration

ACI has some configuration options missing, which you’d expect would be there from the beginning. One glaring omission is port mapping (for example mapping public port 80 to container port 8080). This omission can mean modifying your container just to get it running in ACI.

ACI’s opinionated architecture seems to have been designed for ease-of-use, which often means more complex workloads just aren’t possible. If you have some unique configuration options, like needing access to privileged container options or complex network requirements, ACI might not be able to support you.

What we’d use it for

The lack of flexibility in ACI means that some workloads just aren’t able to run there. If you have full control over the container images you’re building and if you just want to get off the ground quickly with minimal fuss and configuration, ACI is a great choice.

Applications with smaller and more predictable usage patterns are a great use case for ACI. The lack of horizontal scaling could be seen as a negative, but from another perspective, it means the use case is straightforward and simple. If you just want to get your application into the hands of your users and think you can accurately predict your usage patterns, choose ACI.

Azure App Service

Azure App Service is a more fully-featured offering for hosting applications, focusing more on WebApps and API services. It started life as several differing offerings (Azure Websites, Azure Mobile Service, and Azure BizTalk) before being bundled into a single service in March 2015. Its origins as multiple solutions means it has developed tight integrations with other Azure solutions and offers many value-add features depending on your use case.

Because of the myriad features Azure App Service offers, running containers is only a small part of what you can do with it.

With that in mind, let’s take a look at where it shines with regard to running containers.

What’s it good for?

Azure App Services is designed to be a one-stop shop for your web application needs, so it’s highly opinionated and pushes you in a certain direction.

Integrations

Azure App Service has many integrations with Azure. As an example, if you need to add a CDN to your web service, it’s extremely straightforward to do so with Azure CDN.

This tight integration with Azure’s many other services makes it likely to meet the needs of your application and extend it as needed, introducing common architecture components like message queues and databases. This is particularly useful when it comes to the integration with Azure’s networking model. You can run an Azure App Service inside an Azure Virtual Network which is extremely useful in many scenarios where network separation is needed, like enterprise applications.

Scaling & Availability

Azure App Service has a myriad of available scaling capabilities built out of the box. Not only can you scale the actual container you’ve deployed (while also simultaneously placing pricing caps on your service), but you can also scale related resources if necessary, which fits well with the tight integration we mentioned previously.

App service scaling for your container can either scale up (i.e., increase the amount of resources associated with your container) or scale out (ie: have more containers behind your load balancer).

This flexibility in scaling means you can be safe to assume your application will meet spiking traffic requirements and service your users’ needs.

What’s not great about it?

Opinionated

Azure App Service is highly opinionated. Its tight integrations with other Azure services mean that you’re expected to follow established patterns for achieving your goals.

This opinionated implementation means that the initial learning curve can be steep. The origins of app services means the product has grown in complexity along with its opinionated implementation, and as a result it can be overwhelming when getting started.

In addition to the learning curve, App Service is primarily focused towards web app workloads, and support for running other applications is limited at best.

What we’d use it for

The scaling options available to App Service means that it’s extremely well positioned to handle your large scale, fluctuating web applications. If you expect to have traffic spikes during peak hours, you can configure App Service to scale relatively easily in a manner that suits your budget and needs.

Azure Kubernetes Service

Azure Kubernetes Service (AKS) is Azure’s managed Kubernetes offering, which has been available since October 2017.

Azure was very quick to market with its Kubernetes offering and hired several prominent Kubernetes engineers like Brendan Burns to head up the engineering departments building the service.

Kubernetes is a very fully featured product, and AKS is a very conformant implementation of Kubernetes. Therefore, a lot of our good and bad considerations next will be an evaluation of Kubernetes, as well as AKS.

What’s it good for?

Extensibility

Kubernetes is incredibly feature rich. Out of the box with AKS, you’ll get application self-healing capabilities via the mechanism of reconcile loops built into Kubernetes, the ability to run different types of workload via native Kubernetes resources such as StatefulSets, Deployments and Jobs, and a large amount of extensibility via Kubernetes’ Custom Resource Definitions capability.

Familiarity

Kubernetes also offers a familiar API regardless of the cloud provider you’re working with. If you’re new to AKS, but have used a managed Kubernetes service from another cloud provider, you might find it relatively easy to get your container up and running in AKS.

What’s not great about it?

Complexity

Kubernetes has a steep learning curve, and AKS is no exception. A lot of the knowledge needed to run and operate Kubernetes is handled by AKS itself, but you still have to have an in-depth understanding of how Kubernetes works to get your container running.

In addition, the specification for a simple Kubernetes job can often be hundreds of lines of code. You have to learn not only how to run the container but also understand how Kubernetes exposes services to the world.

What we’d use it for

The flexibility and extensibility offered by Kubernetes as a platform means it’s possible to run many types of workloads. Large companies have battle-tested Kubernetes (and by extension, AKS), running everything from web applications to machine learning.

If you’re able to invest time into learning and understanding the ecosystem and can dedicate people to maintaining and managing your Kubernetes implementation, AKS is a fantastic option for almost any workload you might consider.

Everything Else

Azure Red Hat OpenShift

Azure Red Hat OpenShift is an enterprise grade implementation of Kubernetes developed by Red Hat. OpenShift builds on Kubernetes by adding support, enterprise-grade security, and Platform-as-a-Service integrations.

If the idea of using Kubernetes for your container solutions seems appealing but you need service level agreements (SLAs) around support and integrations, Azure’s Red Hat OpenShift solution is a great option.

Azure Service Fabric

Azure Service Fabric is a container service focused on distributed applications, like microservice architectures or complex distributed compute environments.

If you’re planning on running a complex architecture, Azure Service Fabric can be a great fit. It provides more orchestration capabilities than Azure App Service. Service Fabric can also extend outside Azure’s cloud into your on-premise data center if necessary.

If your application has needs related to low latency, especially across distributed regions, Service Fabric is a great fit.

However, Azure Service Fabric can be extremely difficult to use. It is only targeted towards distributed, complex systems - if you’re not planning on building one of those, it’s probably not the correct choice.

Azure Batch

Azure Batch is a service focused on High Performance Compute (HPC) workloads. These workloads can often scale horizontally to thousands of processes and can be difficult to orchestrate.

Azure Batch makes this process simpler by providing a managed service to handle the difficult processes.

If you’re planning on passing large amounts of data to your application via a queuing mechanism and having that data processed very quickly, Azure Batch is definitely a service you should consider.

Azure Functions

Azure Functions is Azure’s Function-as-a-Service implementation. It supports launching “function apps” inside containers as a deployment mechanism.

Function-as-a-Service products are often designed for short-lived, event-driven workloads. If you need to run a script to react to a worker queue or other event, Azure Functions are a great option. It’s important to remember that Functions are often billed based on how long they run, so short-lived workloads are often better suited.

You might also like:

Wrap-Up

There are a number of options for running containers in Azure, and choosing the right one for your workload might be difficult. We’ve tried to give an overview of the current state of the world, but Microsoft continues to add options and capabilities to all these products.

If you’ve settled on a container solution, and are ready to get started, Pulumi’s Azure Native provider supports all of the methods of running containers and can quickly get you started. Check out our Azure getting started guide, or join one of our upcoming Azure Workshops!

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.

Full Coverage of Azure Resources with Azure-Native

Mikhail Shilkov — Tue, 02 Mar 2021 00:00:00 +0000

Last September, we announced the beta release of Pulumi Azure NextGen: a new Microsoft Azure provider for Pulumi that combines same-day access to the entire Azure API surface with the excellent Pulumi experience you know and love, including version-less resources, auto-naming, and auto-location.

Today, we’re excited to announce that this new provider is now the default way to manage Azure resources with Pulumi. We’re also excited to announce its final name: the native Azure provider for Pulumi, or “Azure-Native” for short. You can get started with the new provider using our newly-updated getting started guide.

Already use the classic Pulumi-Azure provider? You can migrate to Azure-Native now using the migration guide. If you prefer to wait until general availability, stay tuned for updates: we expect to reach general availability in the spring of this year.

Alongside this announcement, we’re also formalizing a new concept: a Pulumi “native provider”. A native provider provides functionality mapped directly from the underlying API; in the case of the new Azure Provider, functionality is mapped directly from the Azure Resource Manager API surface. Going forward, you’ll be able to find these next-generation Pulumi providers directly from the name by looking for the “-Native” suffix.

Native to Azure

The native Azure provider implements the best possible support for the Azure platform in Pulumi. It exposes the entire API surface of Azure to developers and operators, now and forever. As of today, the native provider supports 1,010 resource types, 120 of them added since the initial preview in September 2020. Every property of each resource is always represented in the SDKs.

Unlike the classic Azure provider, which requires manual work to keep updated, we designed the native provider to stay always up-to-date with Azure API additions and changes. We generate Pulumi SDKs for the native Azure provider automatically from Azure API specifications published by Microsoft. We publish daily builds of the provider and have published 210 versions of the provider in the last six months.

Native to Pulumi

The native Azure provider comes with several significant improvements over the Azure NextGen preview. These changes bring more features of the Pulumi experience to the native Azure provider.

Top-level Resources

Every resource is now available in the top-level (versionless) module of its resource provider. You don’t have to choose the API version explicitly: we will apply the default for you.

import * as azure from "@pulumi/azure-native";

const resourceGroup = new azure.resources.ResourceGroup("resourceGroup");

const storageAccount = new azure.storage.StorageAccount("sa", {
 resourceGroupName: resourceGroup.name,
 sku: {
 name: azure.storage.SkuName.Standard_LRS,
 },
 kind: azure.storage.Kind.StorageV2,
});

import pulumi_azure_native as azure

resource_group = azure.resources.ResourceGroup('resource_group')

account = azure.storage.StorageAccount('sa',
 resource_group_name=resource_group.name,
 sku=storage.SkuArgs(
 name=azure.storage.SkuName.STANDARD_LRS,
 ),
 kind=azure.storage.Kind.STORAGE_V2)

using Pulumi;
using Pulumi.AzureNative.Resources;
using Pulumi.AzureNative.Storage;
using Pulumi.AzureNative.Storage.Inputs;

class MyStack : Stack
{
 public MyStack()
 {
 var resourceGroup = new ResourceGroup("resourceGroup");

 var storageAccount = new StorageAccount("sa", new StorageAccountArgs
 {
 ResourceGroupName = resourceGroup.Name,
 Sku = new SkuArgs
 {
 Name = SkuName.Standard_LRS
 },
 Kind = Kind.StorageV2
 });
 }
}

package main

import (
 "github.com/pulumi/pulumi-azure-native/sdk/go/azure/resources"
 "github.com/pulumi/pulumi-azure-native/sdk/go/azure/storage"
 "github.com/pulumi/pulumi/sdk/v2/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 resourceGroup, err := resources.NewResourceGroup(ctx, "resourceGroup", nil)
 if err != nil {
 return err
 }

 account, err := storage.NewStorageAccount(ctx, "sa", &storage.StorageAccountArgs{
 ResourceGroupName: resourceGroup.Name,
 Sku: &storage.SkuArgs{
 Name: storage.SkuName_Standard_LRS,
 },
 Kind: storage.KindStorageV2,
 })

 return err
 })
}

The top-level resources will use stable API versions and take no arbitrary breaking changes within a given major version of the package once we reach general availability; during the preview, breaking changes may appear in 0.x minor versions.

We still provide access to every version of every ARM API if you want to use the latest version or a specific version from the past. Each API version is mapped to its own module or namespace within the resource provider.

Auto-Naming

The original preview of the native Azure provider (then called “Azure NextGen”) didn’t yet support auto-naming, a common feature of other Pulumi providers. Now, it provides full support for auto-naming. Azure resources will get a random suffix in the name by default. In the following example, Pulumi will create a resource group called, for instance, rg53acf911.

import * as azure from "@pulumi/azure-native";
const resourceGroup = new azure.resources.ResourceGroup("rg");

import pulumi_azure_native as azure
resource_group = azure.resources.ResourceGroup('rg')

using Pulumi;
using Pulumi.AzureNative.Resources;
class MyStack : Stack
{
 public MyStack()
 {
 var resourceGroup = new ResourceGroup("rg");
 }
}

package main

import (
 resources "github.com/pulumi/pulumi-azure-native/sdk/go/azure/resources"
 "github.com/pulumi/pulumi/sdk/v2/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 _, err := resources.NewResourceGroup(ctx, "resourceGroup", nil)
 return err
 })
}

Pass an explicit value to the resourceGroupName property if you want to control the resource’s exact name.

However, suppose you create a sub-resource, e.g., a container under a storage account, a database under a database account, or a slot under a web app. In that case, Pulumi will not append a random suffix because those resources names don’t have to be globally unique.

You can also apply transformations to define your own naming schemas: see this example from our community.

Auto-Location

Like the classic Azure provider, all resources’ location property is now optional in the native Azure provider. In the examples above, we did not have to specify the location of resources. Instead, we can run the following command to configure it for the whole stack:

pulumi config set azure-native:location WestUS2

You can also specify the location explicitly for a resource group but leave it out for resources under that resource group: the resources will deploy to the same region by default. Of course, you are free to override the defaults at any time.

Beyond ARM API

Unfortunately, some Azure capabilities aren’t yet available via the Azure Resource Manager APIs used by the native Azure provider. To ensure that you can still use some of the missing capabilities, we’ve introduced several resources that go beyond what’s currently possible with ARM (and ARM templates):

Exposing Azure Storage as a static website.
Uploading files and directories as Azure Storage Blobs.
Managing Azure KeyVault secrets and keys.

By combining full support for the ARM APIs with these additional extensions, Pulumi’s native Azure provider provides the broadest support for managing Azure resources with infrastructure-as-code.

Open-Source

The native Azure provider for Pulumi is fully open-source. The code is available on GitHub at pulumi-azure-native.

Migrate from Azure NextGen to Azure-Native

Migration from Azure NextGen to Azure-Native is simple and non-disruptive:

Reference the pulumi-azure-native package from your program.
Update all import/using statements from nextgen to native.
Run pulumi up and make sure the program ran successfully. The preview should show no changes.
If so, choose yes to run the update that will overwrite the state to the native provider.

Note that the Azure resources are not affected by this migration.

Getting Started

If you are new to Pulumi, follow our Get Started guide.

From now on, the azure-* templates will reference the native Azure provider. It’s easier to get started than ever:

$ pulumi new azure-typescript

$ pulumi new azure-python

$ pulumi new azure-csharp

$ pulumi new azure-go

Several more extensive examples are available in the Pulumi Examples repo:

Web Applications with Azure App Service and Docker: TypeScript, C#, Python, Go
Azure AKS cluster: TypeScript, C#, Python, Go
Web Application with Azure Container Instances: TypeScript, C#, Python, Go
Web Server Using Azure Virtual Machine: TypeScript, Python

You can browse API reference docs with inline examples or explore the Pulumi Azure-Native SDKs repository.

Get Up and Running with Azure Synapse and Pulumi

Mikhail Shilkov — Fri, 04 Dec 2020 00:00:00 +0000

Azure Synapse is an integrated analytics service that combines enterprise data warehousing of Azure SQL Data Warehouse and Big Data analytics of Apache Spark. Azure Synapse is a managed service well integrated with other Azure services for data ingestion and business analytics.

You could use the Azure portal to get started with Azure Synapse, but it can be hard to define sophisticated infrastructure for your analytics pipeline using the portal alone, and many users need to apply version control to their cloud configurations.

The alternative is to use an infrastructure as code tool to automate building and deploying cloud resources. This article demonstrates how to provision an Azure Synapse workspace using Pulumi and general-purpose programming languages like Python and C#.

Azure Synapse Quick Start

Ready to get up and running quickly right away?

Bootstrap a project $ pulumi new https://github.com/pulumi/examples/tree/master/azure-py-synapse.
Follow the steps outlined in README.
Go to https://web.azuresynapse.net and sign in to your new workspace.

For additional information on how provisioning Azure Synapse with infrastructure as code, please read on.

Azure Synapse Components

Let’s start by introducing the components required to provision a basic Azure Synapse workspace. To follow along with the Synapse Getting Started Guide, you need the following key Azure infrastructure components:

Resource Group to contain all other resources.
Storage Account to store input data and analytics artifacts.
Azure Synapse Workspace—a collaboration boundary for cloud-based analytics in Azure.
SQL Pool—a dedicated Synapse SQL pool to run T-SQL based analytics.
Spark Pool to use Apache Spark analytics.
IP Filters and Role Assignments for secure access control.

Infrastructure as Code

Let’s walk through the steps to build a workspace with all the components mentioned above. We’ll use Pulumi to provision the necessary resources. Feel free to pick the language of your choice that will apply to all code snippets.

You can check out the full source code in the Pulumi Examples.

Resource Group

Let’s start by defining a resource group to contain all other resources. Be sure to adjust its name and region to your preferred values.

Choose the language below to adjust the contents of this blog. Your choice is applied throughout the article.

resource_group = resources.ResourceGroup("resourceGroup",
 resource_group_name="synapse-rg",
 location="westus2")

var resourceGroup = new ResourceGroup("resourceGroup", new ResourceGroupArgs
{
 ResourceGroupName = "synapse-rg",
 Location = "westus2
});

const resourceGroup = new resources.ResourceGroup('resourceGroup', {
 resourceGroupName: 'synapse-rg',
 location: 'westus2',
});

Data Lake Storage Account

Synapse workspace will store data in a data lake storage account. We use a Standard Read-Access Geo-Redundant Storage account (SKU Standard_RAGRS) for this purpose. Make sure to change the accountName to your own globally unique name.

storage_account = storage.StorageAccount("storageAccount",
 resource_group_name=resource_group.name,
 location=resource_group.location,
 account_name="yoursynapsesa",
 access_tier="Hot",
 enable_https_traffic_only=True,
 is_hns_enabled=True,
 kind="StorageV2",
 sku=storage.SkuArgs(
 name="Standard_RAGRS",
 ))

var storageAccount = new StorageAccount("storageAccount", new StorageAccountArgs
{
 ResourceGroupName = resourceGroup.Name,
 Location = resourceGroup.Location,
 AccountName = "synapsesa",
 AccessTier = "Hot",
 EnableHttpsTrafficOnly = true,
 IsHnsEnabled = true,
 Kind = "StorageV2",
 Sku = new SkuArgs
 {
 Name = "Standard_RAGRS"
 },
});

const storageAccount = new storage.StorageAccount("storageAccount", {
 resourceGroupName: resourceGroup.name,
 location: resourceGroup.location,
 accountName: "yoursynapsesa",
 accessTier: "Hot",
 enableHttpsTrafficOnly: true,
 isHnsEnabled: true,
 kind: "StorageV2",
 sku: {
 name: "Standard_RAGRS",
 },
});

Let’s build a data lake URL for this storage account.

data_lake_storage_account_url = storage_account.name.apply(lambda name: f"https://{name}.dfs.core.windows.net")

var dataLakeStorageAccountUrl = Output.Format($"https://{storageAccount.Name}.dfs.core.windows.net");

const dataLakeStorageAccountUrl = pulumi.interpolate`https://${storageAccount.name}.dfs.core.windows.net`;

We’ll use the users blob container as the analytics file system.

users = storage.BlobContainer("users",
 resource_group_name=resource_group.name,
 account_name=storage_account.name,
 container_name="users",
 public_access="None")

var users = new BlobContainer("users", new BlobContainerArgs
{
 ResourceGroupName = resourceGroup.Name,
 AccountName = storageAccount.Name,
 ContainerName = "users",
 PublicAccess = "None"
});

new storage.BlobContainer("users", {
 resourceGroupName: resourceGroup.name,
 accountName: storageAccount.name,
 containerName: "users",
 publicAccess: "None",
});

Synapse Workspace

It’s time to use all of the above to provision an Azure Synapse workspace! Adjust the name and the SQL credentials in the definition below.

workspace = synapse.Workspace("workspace",
 resource_group_name=resource_group.name,
 location=resource_group.location,
 workspace_name="mysynapse",
 default_data_lake_storage=synapse.DataLakeStorageAccountDetailsArgs(
 account_url=data_lake_storage_account_url,
 filesystem="users",
 ),
 identity=synapse.ManagedIdentityArgs(
 type="SystemAssigned",
 ),
 sql_administrator_login="sqladminuser",
 sql_administrator_login_password=random.RandomPassword("workspacePwd", length=12).result)

var workspace = new Workspace("workspace", new WorkspaceArgs
{
 ResourceGroupName = resourceGroup.Name,
 Location = resourceGroup.Location,
 WorkspaceName = "my-workspace",
 DefaultDataLakeStorage = new DataLakeStorageAccountDetailsArgs
 {
 AccountUrl = dataLakeStorageAccountUrl,
 Filesystem = "users"
 },
 Identity = new ManagedIdentityArgs
 {
 Type = "SystemAssigned"
 },
 SqlAdministratorLogin = "sqladminuser",
 SqlAdministratorLoginPassword = "YourStrongPassword"
});

const workspace = new synapse.Workspace("workspace", {
 resourceGroupName: resourceGroup.name,
 location: resourceGroup.location,
 workspaceName: "mysynapse",
 defaultDataLakeStorage: {
 accountUrl: dataLakeStorageAccountUrl,
 filesystem: "users",
 },
 identity: {
 type: "SystemAssigned",
 },
 sqlAdministratorLogin: "sqladminuser",
 sqlAdministratorLoginPassword: "YourSecurePassword",
});

Note that we also defined a system-assigned managed identity for the workspace.

Security Setup

You need to allow access to the workspace with a firewall rule. The following is a blank access rule but feel free to restrict it to your target IP range.

allow_all = synapse.IpFirewallRule("allowAll",
 resource_group_name=resource_group.name,
 workspace_name=workspace.name,
 rule_name="allowAll",
 end_ip_address="255.255.255.255",
 start_ip_address="0.0.0.0")

var allowAll = new IpFirewallRule("allowAll", new IpFirewallRuleArgs
{
 ResourceGroupName = resourceGroup.Name,
 WorkspaceName = workspace.Name,
 RuleName = "allowAll",
 EndIpAddress = "255.255.255.255",
 StartIpAddress = "0.0.0.0"
});

new synapse.IpFirewallRule("allowAll", {
 resourceGroupName: resourceGroup.name,
 workspaceName: workspace.name,
 ruleName: "allowAll",
 endIpAddress: "255.255.255.255",
 startIpAddress: "0.0.0.0",
});

The following snippet assigns the Storage Blob Data Contributor role to the workspace managed identity and your target user. If you use the Azure CLI, run az ad signed-in-user show --query=objectId to look up your user ID.

subscription_id = resource_group.id.apply(lambda id: id.split('/')[2])
role_definition_id = subscription_id.apply(lambda id: f"/subscriptions/{id}/providers/Microsoft.Authorization/roleDefinitions/ba92f5b4-2d11-453d-a403-e96b0029c9fe")

authorization.RoleAssignment("storageAccess",
 role_assignment_name=random.RandomUuid("roleName").result,
 scope=storage_account.id,
 principal_id=workspace.identity.principal_id.apply(lambda v: v or "<preview>"),
 principal_type="ServicePrincipal",
 role_definition_id=role_definition_id)

authorization.RoleAssignment("userAccess",
 role_assignment_name=random.RandomUuid("userRoleName").result,
 scope=storage_account.id,
 principal_id=config.get("userObjectId"),
 principal_type="User",
 role_definition_id=role_definition_id)

var subscriptionId = resourceGroup.Id.Apply(id => id.Split('/')[2]);
var roleDefinitionId = $"/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/ba92f5b4-2d11-453d-a403-e96b0029c9fe";

new RoleAssignment("storageAccess", new RoleAssignmentArgs
{
 RoleAssignmentName = new RandomUuid("roleName").Result,
 Scope = storageAccount.Id,
 PrincipalId = workspace.Identity.Apply(identity => identity.PrincipalId).Apply(v => v ?? "<preview>"),
 PrincipalType = "ServicePrincipal",
 RoleDefinitionId = roleDefinitionId
});
new RoleAssignment("userAccess", new RoleAssignmentArgs
{
 RoleAssignmentName = new RandomUuid("userRoleName").Result,
 Scope = storageAccount.Id,
 PrincipalId = config.Require("userObjectId"),
 PrincipalType = "User",
 RoleDefinitionId = roleDefinitionId
});

const subscriptionId = resourceGroup.id.apply(id => id.split('/')[2]);
const roleDefinitionId = pulumi.interpolate`/subscriptions/${subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/ba92f5b4-2d11-453d-a403-e96b0029c9fe`;

new authorization.RoleAssignment("storageAccess", {
 roleAssignmentName: new random.RandomUuid("roleName").result,
 scope: storageAccount.id,
 principalId: workspace.identity.principalId,
 principalType: "ServicePrincipal",
 roleDefinitionId: roleDefinitionId,
});

new authorization.RoleAssignment("userAccess", {
 roleAssignmentName: new random.RandomUuid("userRoleName").result,
 scope: storageAccount.id,
 principalId: "your-synapse-user-object-uuid",
 principalType: "User",
 roleDefinitionId: roleDefinitionId,
});

SQL and Spark Pools

Finally, let’s add two worker pools to the Synapse workspace. A SQL pool for T-SQL analytic queries…

sql_pool = synapse.SqlPool("sqlPool",
 resource_group_name=resource_group.name,
 location=resource_group.location,
 workspace_name=workspace.name,
 sql_pool_name="SQLPOOL1",
 collation="SQL_Latin1_General_CP1_CI_AS",
 create_mode="Default",
 sku=synapse.SkuArgs(
 name="DW100c",
 ))

var sqlPool = new SqlPool("sqlPool", new SqlPoolArgs
{
 ResourceGroupName = resourceGroup.Name,
 Location = resourceGroup.Location,
 WorkspaceName = workspace.Name,
 SqlPoolName = "SQLPOOL1",
 Collation = "SQL_Latin1_General_CP1_CI_AS",
 CreateMode = "Default",
 Sku = new Pulumi.AzureNative.Synapse.Inputs.SkuArgs
 {
 Name = "DW100c"
 },
});

const sqlPool = new synapse.SqlPool("sqlPool", {
 resourceGroupName: resourceGroup.name,
 location: resourceGroup.location,
 workspaceName: workspace.name,
 sqlPoolName: "SQLPOOL1",
 collation: "SQL_Latin1_General_CP1_CI_AS",
 createMode: "Default",
 sku: {
 name: "DW100c",
 },
});

… and a Spark pool for Big Data analytics.

spark_pool = synapse.BigDataPool("sparkPool",
 resource_group_name=resource_group.name,
 location=resource_group.location,
 workspace_name=workspace.name,
 big_data_pool_name="Spark1",
 auto_pause=synapse.AutoPausePropertiesArgs(
 delay_in_minutes=15,
 enabled=True,
 ),
 auto_scale=synapse.AutoScalePropertiesArgs(
 enabled=True,
 max_node_count=3,
 min_node_count=3,
 ),
 node_count=3,
 node_size="Small",
 node_size_family="MemoryOptimized",
 spark_version="2.4")

var sparkPool = new BigDataPool("sparkPool", new BigDataPoolArgs
{
 ResourceGroupName = resourceGroup.Name,
 Location = resourceGroup.Location,
 WorkspaceName = workspace.Name,
 BigDataPoolName = "Spark1",
 AutoPause = new AutoPausePropertiesArgs
 {
 DelayInMinutes = 15,
 Enabled = true,
 },
 AutoScale = new AutoScalePropertiesArgs
 {
 Enabled = true,
 MaxNodeCount = 3,
 MinNodeCount = 3,
 },
 NodeCount = 3,
 NodeSize = "Small",
 NodeSizeFamily = "MemoryOptimized",
 SparkVersion = "2.4"
});

const bigDataPoolResource = new synapse.BigDataPool("sparkPool", {
 resourceGroupName: resourceGroup.name,
 location: resourceGroup.location,
 workspaceName: workspace.name,
 bigDataPoolName: "Spark1",
 autoPause: {
 delayInMinutes: 15,
 enabled: true,
 },
 autoScale: {
 enabled: true,
 maxNodeCount: 3,
 minNodeCount: 3,
 },
 nodeCount: 3,
 nodeSize: "Small",
 nodeSizeFamily: "MemoryOptimized",
 sparkVersion: "2.4",
});

Ready to Dive into Analytics

Our resource definitions are ready. Run pulumi up to provision your Azure Synapse infrastructure.

$ pulumi up
...
Do you want to perform this update? yes
Updating (dev)

 Type Name Plan
 + pulumi:pulumi:Stack azure-py-synapse-dev created
 + ├─ azure-native:resources:ResourceGroup resourceGroup created
 + ├─ azure-native:storage:StorageAccount storageAccount created
 + ├─ azure-native:storage:BlobContainer users created
 + ├─ azure-native:synapse:Workspace workspace created
 + ├─ random:index:RandomUuid roleName created
 + └─ azure-native:authorization:RoleAssignment storageAccess created
 + ├─ random:index:RandomUuid userRoleName created
 + ├─ azure-native:authorization:RoleAssignment userAccess created
 + ├─ azure-native:synapse:IpFirewallRule allowAll created
 + ├─ azure-native:synapse:SqlPool sqlPool created
 + ├─ azure-native:synapse:BigDataPool sparkPool created

 Resources:
 + 12 created

Duration: 10m51s

You can now navigate to the Azure Synapse Quickstart, Step 2, and follow along with the data analysis tutorial.

Conclusion

Azure Synapse is a managed analytics service that accelerates time to insight across data warehouses and big data workloads. A Synapse workspace is a critical component of your cloud infrastructure that you should provision with infrastructure as code and other management best practices.

Pulumi and the native Azure provider open up full access to all types of Azure resources using your favorite programming languages, including Python, C#, and TypeScript. Navigate to the complete Azure Synapse example in Python, C#, or TypeScript and get started today.

Deploying Minecraft on Azure

Sophia Parafina — Wed, 04 Nov 2020 00:00:00 +0000

This article demonstrates how to deploy and provision a virtual machine in Azure using the Pulumi Azure-Native provider. While there are numerous examples of using the Azure console, the Azure CLI, or ARM templates to deploy and provision virtual machines, we’ll use Python to implement a repeatable deployment.

Build it

There are several parts to the process. First, we need to create the network resources to make the virtual machine accessible to Minecraft clients. Second, the virtual machine needs to be created and configured with network resources, storage for server files and logs, and a way to administer it remotely. Finally, the virtual machine needs to be provisioned with the server and all the dependencies that it requires, such as Java. Let’s go step by step through the process.

Resource Group

Resource groups hold all the resources that you use for building infrastructure on Azure. They can contain all the resources for your Azure infrastructure or only the resources that you want to manage together. Resource groups let you deploy, update, and delete resources as a group.

Declaring a resource group with Pulumi is straightforward and requires a name and the location of the region.

resource_group = resources.ResourceGroup("server-rg",
 resource_group_name="minecraft",
 location=location)

Networking resources

Next, we want to create all the resources needed to deploy a virtual machine as a server and make it accessible to clients on the Internet, which, in our case, is a Minecraft client.

We’ll create a virtual network for the server to communicate with other resources and to the Internet. The virtual network needs the resource group name, the location, and a name. We set a private IP address range and Azure will assign an IP address if a resource is deployed in that address space.

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

To make the virtual machine accessible on the Internet, we create a public IP. The public IP address is dedicated to a resource unless they are unassigned by you. They are resources in their own right and can be associated with other resources such as firewalls, load balancers, and virtual machines.

public_ip = network.PublicIPAddress(
 "server-ip",
 resource_group_name=resource_group.name,
 location=location,
 public_ip_address_name="server-ip",
 public_ip_allocation_method="Dynamic"
)

Finally, we need a resource to tie the virtual network to the virtual machine. A network interface lets a virtual machine communicate with other resources in the resource group and the Internet. In the code below we specify the subnet we created in the virtual network and set the public IP to the resource we previously created.

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

Now that we have the networking resources available let’s create the virtual machine.

Virtual machine

There are several parts to creating a virtual machine, so we’ll go through the code piece by piece. In the previous step, we created a network interface resource. We’ll use that to set up the network profile for the virtual machine.

network_profile=compute.NetworkProfileArgs(
 network_interfaces=[
 compute.NetworkInterfaceReferenceArgs(id=network_iface.id),
 ],
 ),

Next, we set the hardware profile that sets the virtual machine size, determining the number of cores, amount of memory, and storage size.

 hardware_profile=compute.HardwareProfileArgs(
 vm_size="Standard_A2",
 ),

We need to set up access to the virtual machine. The code below sets the user name and optionally the password if needed. We disable password authentication and opt to use OpenSSH keypairs to authenticate logins to the virtual machine.

os_profile=compute.OSProfileArgs(
 computer_name="hostname",
 admin_username=admin_username,
 #admin_password=admin_password,
 linux_configuration=compute.LinuxConfigurationArgs(
 disable_password_authentication=True,
 ssh= {
 'publicKeys': [{
 'keyData': public_key,
 'path': ssh_path,
 }],
 },
 ),
 ),

To complete the virtual machine, we add storage via an OS disk. Note that OS disks are ephemeral and they will not retain data if the virtual machine is terminated.

storage_profile=compute.StorageProfileArgs(
 os_disk=compute.OSDiskArgs(
 create_option="FromImage",
 name="myosdisk1",
 caching= "ReadWrite",
 disk_size_gb= 100,
 ),
 image_reference=compute.ImageReferenceArgs(
 publisher="canonical",
 offer="UbuntuServer",
 sku="18.04-LTS",
 version="latest",
 ),
 ),

Provisioning the server

Once the virtual machine has been created, we need to provision it with the Minecraft server. The install.sh script installs the prerequisite software, the Minecraft server, and creates the service for starting and stopping the server. We could use scp to copy the install script to the virtual machine from our local machine and then ssh into a terminal to run the script. The alternative is to use a Pulumi dynamic resource provider to provision the virtual machine. The provisioners.py script creates a dynamic provider that enable using scp to transfer files and send commands via ssh. Creating dynamic providers are beyond the scope of this article, but more information is available on the Pulumi docs.

We provision our Minecraft server by creating the conn connection object defined in provisioners.py.

conn = provisioners.ConnectionArgs(
 host= public_ip_addr.ip_address,
 username=admin_username,
 private_key=private_key,
 private_key_passphrase=private_key_passphrase,
)

We pass in the conn object to the CopyFile method which copies install.sh to the virtual machine via scp.

cp_config = provisioners.CopyFile('config',
 conn=conn,
 src='install.sh',
 dest='install.sh',
 opts=pulumi.ResourceOptions(depends_on=[server]),
)

To provision the virtual machine, we call the RemoteExec method to make install.sh executable and run the script as root. The script installs all the prerequisites including Java, downloads the Minecraft server jar and configures it, and creates a service to run the Minecraft server.

install = provisioners.RemoteExec('install',
 conn=conn,
 commands=['sudo chmod 755 install.sh && sudo ./install.sh'],
 opts=pulumi.ResourceOptions(depends_on=[cp_config]),
)

Once the virtual machine is created and provisioned, we publish the virtual machines public IP address, and we’re ready to join the server!

export("Minecraft Server IP Address", public_ip_addr.ip_address)

Next Steps

This article demonstrates the process to create a virtual machine and provision it with a Minecraft server. However, there’s always room for improvement, such as adding Azure Disk Storage to provide durable storage, add a configuration file to customize the server, and automatically updating the server jar file when a new version is released. All these options are available to you when you build your infrastructure with code.

You can download the code from the Pulumi examples repository on Github.

See these resources to learn more about deploying infrastructure on Azure.

Announcing Next Generation Pulumi Azure Provider

Mikhail Shilkov — Mon, 21 Sep 2020 00:00:00 +0000

The next-generation Azure provider is now Azure-Native.

We are excited to announce the beta release of a next generation Microsoft Azure provider for Pulumi. Azure has been a rapidly growing cloud platform among Pulumi users over the last year, and with the next generation Azure provider, we are doubling down on providing the best support possible for the Azure platform in Pulumi. We designed the new provider to expose the entire API surface of Azure to developers and operators, now and forever.

The new Azure provider for Pulumi (azure-nextgen) works directly with the Azure Resource Manager (ARM) platform instead of depending on a handwritten layer as with the previous provider. This approach ensures higher quality and higher fidelity with the Azure platform.

Full API Coverage

The next generation Pulumi Azure provider covers 100% of the resources available in Azure Resource Manager. The new provider supports 890 resource types at launch, nearly double the number supported by the previous Pulumi Azure Provider. Every property of each resource is always represented in the SDKs.

The provider also contains functions to retrieve keys, secrets, and connection strings from all resources that expose them.

The new SDKs include full coverage for Azure services, including Azure Static Web Apps, Azure Synapse Analytics, Azure Logic Apps, Azure Service Fabric, Azure Blockchain Service, Azure API Management, and dozens of other services.

If you can deploy a resource with ARM Templates, you can deploy it with the next Generation Pulumi Azure provider!

Always Up-to-Date

Unlike the original Azure provider, which requires manual work to keep updated, the new provider is designed to be always up-to-date with additions and changes to Azure APIs.

We generate Pulumi SDKs for azure-nextgen automatically from Azure API specifications published by Microsoft. An automated pipeline releases updated resources within hours after any current API specifications are merged. We publish daily updates via automated builds and cut minor SDK versions every two weeks.

By generating the SDKs directly from the Azure Resource Manager resource model specifications maintained by Azure service teams, the Azure NextGen provider is robust and reliable, with fewer moving parts involved and fewer sources of potential bugs and incompatibilities.

Excited about a new service announced by Microsoft? Chances are it’s already in the latest Azure NextGen package!

API Versions

The Azure Resource Manager API is structured around Resource Providers—high-level groups like “storage”, “compute”, or “web”. We map Resource Providers to top-level modules or namespaces in Pulumi SDKs.

Each resource provider defines one or more API versions, for example, “2015-05-01”, “2020-09-01”, or “2020-08-01-preview”. Every version of every ARM API is available in Pulumi SDKs, and each version has its own module or namespace.

In addition, a latest version in the Pulumi SDK maps to the latest stable API version as determined by the Azure SDK teams. Using a specific version ensures full compatibility, while using the latest version is a quick way to start, but does not guarantee compatibility between minor versions of the provider.

Now, you always have access to the latest and greatest, but at the same time, we don’t force you to upgrade your production resources unless you are ready.

Every Language

The next generation Azure provider is available in preview today for all Pulumi languages. The new azure-nextgen SDKs are open source on GitHub and available in NPM, NuGet, PyPI, and Go Modules.

import * as resources from "@pulumi/azure-nextgen/resources/latest";
import * as storage from "@pulumi/azure-nextgen/storage/latest";

const resourceGroup = new resources.ResourceGroup("resourceGroup", {
 resourceGroupName: "my-rg",
 location: "WestUS",
});

const storageAccount = new storage.StorageAccount("sa", {
 resourceGroupName: resourceGroup.name,
 accountName: "mystorageaccount",
 location: resourceGroup.location,
 sku: {
 name: "Standard_LRS",
 tier: "Standard",
 },
 kind: "StorageV2",
});

from pulumi_azure_nextgen.storage import latest as storage
from pulumi_azure_nextgen.resources import latest as resources

resource_group = resources.ResourceGroup('resource_group',
 resource_group_name='my-rg',
 location='WestUS')

account = storage.StorageAccount('sa',
 account_name='mystorageaccount',
 resource_group_name=resource_group.name,
 location=resource_group.location,
 sku=storage.SkuArgs(
 name='Standard_LRS',
 tier='Standard',
 ),
 kind='StorageV2')

using Pulumi;
using Pulumi.AzureNextGen.Resources.Latest;
using Pulumi.AzureNextGen.Storage.Latest;
using Pulumi.AzureNextGen.Storage.Latest.Inputs;

class MyStack : Stack
{
 public MyStack()
 {
 var resourceGroup = new ResourceGroup("resourceGroup", new ResourceGroupArgs
 {
 ResourceGroupName = "my-rg",
 Location = "WestUS"
 });

 var storageAccount = new StorageAccount("sa", new StorageAccountArgs
 {
 ResourceGroupName = resourceGroup.Name,
 AccountName = "mystorageaccount",
 Location = resourceGroup.Location,
 Sku = new SkuArgs
 {
 Name = "Standard_LRS",
 Tier = "Standard"
 },
 Kind = "StorageV2"
 });
 }
}

package main

import (
 resources "github.com/pulumi/pulumi-azure-nextgen/sdk/go/azure/resources/latest"
 storage "github.com/pulumi/pulumi-azure-nextgen/sdk/go/azure/storage/latest"
 "github.com/pulumi/pulumi/sdk/v2/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 resourceGroup, err := resources.NewResourceGroup(ctx, "resourceGroup", &resources.ResourceGroupArgs{
 ResourceGroupName: pulumi.String("my-rg"),
 Location: pulumi.String("WestUS"),
 })
 if err != nil {
 return err
 }

 account, err := storage.NewStorageAccount(ctx, "sa", &storage.StorageAccountArgs{
 ResourceGroupName: resourceGroup.Name,
 AccountName: pulumi.String("mystorageaccount"),
 Location: resourceGroup.Location,
 Sku: &storage.SkuArgs{
 Name: pulumi.String("Standard_LRS"),
 Tier: pulumi.String("Standard"),
 },
 Kind: pulumi.String("StorageV2"),
 })

 return err
 })
}

API documentation is available at Azure NextGen API Reference and includes more than 1,000 resource examples.

Integrated with Azure Ecosystem

Relying on the shape of the Azure API, we can integrate the NextGen provider into the broader Azure ecosystem. In the coming weeks, we will release several capabilities to simplify the adoption of the new provider:

Command-line and web-based tools to convert Azure Resource Manager Templates to Pulumi programs in the language of your choice
A flow to import an existing Azure Resource Group and all its resources to your Pulumi project
A multi-language component resource to embed ARM Templates in Pulumi programs, including per-resource previews
Integrations with ARM Template generation tools like Project Bicep and Farmer

Bring your existing resources and assets and start managing them with the NextGen Azure provider!

Provider Coexistence

We will continue to invest in the existing azure provider, and Pulumi users can use either provider or both, side-by-side, in their applications.

A single Pulumi project can use both providers. Each provider must be configured independently, but they accept mostly the same configuration options. The outputs of a resource from one provider can flow to inputs of a resource from the other provider. In both cases, they are the values available from Azure itself, such as the name or id of an Azure resource.

Pulumi has a separate azuread provider, which will continue to manage Azure Active Directory resources.

If you have existing projects using the current Pulumi Azure provider, you can continue to use that provider, and it will be updated indefinitely. You can add new cloud resources using the existing provider or start creating new infrastructure with the new provider.

New Pulumi Azure projects will default to use the azure-nextgen provider once the provider reaches general availability.

Getting Started

New Pulumi templates are available for the new azure-nextgen provider:

$ pulumi new azure-nextgen-typescript

$ pulumi new azure-nextgen-python

$ pulumi new azure-nextgen-csharp

$ pulumi new azure-nextgen-go

Several larger examples are available in the Pulumi Examples repo:

Web Applications with Azure App Service and Docker: TypeScript, C#, Python, Go
Azure AKS cluster: TypeScript, C#, Python, Go
Web Application with Azure Container Instances: TypeScript, C#, Python, Go
Web Server Using Azure Virtual Machine: TypeScript, Python

You can browse API reference docs with inline examples or explore the Pulumi Azure NextGen SDKs repository.

Deploy a Serverless RabbitMQ Cluster on Azure with .NET

Itay Podhajcer — Thu, 16 Jul 2020 00:00:00 +0000

Itay Podhajcer is Chief Architect at Velocity Career Labs and a highly experienced software development and technology professional, consultant, architect & project manager. He shared his article on building an Azure serverless cluster for deploying RabbitMQ with C#. The original article was published here.

Pulumi, an open source cloud development platform that supports multiple languages and platforms, allows programming and managing cloud environments using a consistent model and the power of full programming languages.

One of those supported languages is C#, which we will be using to deploy a geo-redundant serverless cluster of the well-known messaging solution RabbitMQ. To run the cluster, we will be using three regions, in which we will be deploying:

Two peered virtual networks, one internal for the containers, and one external for connecting to the other regions. Two networks are required because (at least at the writing of this article) Azure Container Instances only support one peered network, so to overcome that, we will be peering the network with the containers with an additional network in the region, which in turn, connects with the external networks from the other regions.
A RabbitMQ node using Azure Container Instances that will be deployed in the internal virtual network.
An Azure Firewall, which will be deployed in the external virtual network, acting as a network virtual appliance (NVA) with rules for forwarding traffic between the internal node and the other regions.
Route tables with routes that will enable the inter-network transfer of data.
A storage account with file shares for maintaining the node’s state.

Additionally, as we will be using RabbitMQ’s DNS based cluster peer discovery mechanism, we will also be deploying at the global level:

DNS zone for the node’s A records and the discovery record required by RabbitMQ.
A reverse DNS zone for the PTR records of the nodes required by RabbitMQ.

Geo-redundant serverless RabbitMQ cluster

Prerequisites

As we will be using Pulumi for .NET to deploy to Azure, we will need the following installed on our workstation:

Azure CLI: installation guide is available here.
.N ET Core SDK: download is available here.
Pulumi: installation guide is available here.

Example Repository

The complete example of deploying the RabbitMQ cluster can be downloaded or cloned for the following GitHub repository:

When running pulumi up you will be asked to create a stack (you can use whatever you here like Example) and set a passphrase (you can leave it empty and press enter as there are no stored secrets in this stack).

Setup the Project

After all the required tools are installed, we can start by creating the empty Pulumi project running pulumi new azure-csharp inside an empty folder. Set a name for the project (like Example), a description (like RabbitMQ Serverless Cluster), a stack name (like Example), a passphrase (you can use an empty one and just press enter as we won’t be storing secrets in the stack) and an Azure location (just use the default).

Now that we have an initial project, we will also add the Pulumi.Random package to the project by running the command dotnet add package Pulumi.Random, as we will be using it to generate the cluster sec, And rename the MyStack class and file to ExampleStack (it also needs to be changed inside Program.cs which holds the code that triggers the deployment of the stack).

Lastly, we call dotnet restore to also download the Pulumi.Azure package that was included in the project when it was created.

Writing the Stack

We will start by defining a few constants, the constructor, an empty method called Stack(), which will be called by the constructor to start creating the resources and a property named Cookie, which will hold the cluster’s secret, decorated with the Output attribute to let Pulumi know that the value needs to be printed out once the deployment is complete:

Now that we have our initial class, we can start writing methods for the resources we will be creating:

Resource groups:
Private DNS zone:

Private reverse DNS zone:

Random string for the RabbitMQ cluster secret:

DNS zone links:

RabbitMQ node container:

Note that we are overriding RabbitMQ docker image’s default command with `{ “/bin/bash”, “-c”, $”(sleep {ContainerStartupDelay} && docker-entrypoint.sh rabbitmq-server) & wait” }` to delay the startup of the container, but still keep it responsive. More on this later.

Container mounted volumes:

Storage accounts:

File shares:

Container ports:

Virtual networks:

Internal virtual network subnets:

Note that we are creating it with the Microsoft.Storage service endpoint to allow access to storage accounts and the Microsoft.ContainerInstance/containerGroups delegation, which is required for deploying containers into virtual networks.

Network profiles, also required for deploying containers into virtual networks:

External virtual network subnets:

Internal and external virtual networks peering:

External virtual network firewalls:

Internal and external virtual networks routing:

RabbitMQ nodes DNS records:

RabbitMQ nodes reverse DNS records:

Reversing the IP address as required by a reverse PTR record:

Firewall IP forwarding rules:

RabbitMQ’s discovery DNS record:

Global peering of the external virtual networks:

Global routes for the virtual networks:

Firewall virtual appliance routes:

Internet outbound routes:

Now that we can create all the necessary resources, it is time to put it all together inside the empty Stack() method we created earlier:

Note that we are using two loops to create the required resources. The first one creates most of the resources (storage, firewall, networks, container, etc.) and the second one creates the DNS A records of the nodes. The second loop combined with the custom container startup command helps us ensure that the nodes will start without failing only when the entire infrastructure is ready.

This workaround is required because (at the writing of the article) Azure Container Instances do not allow manual allocation of private IP address, and because RabibtMQ’s discovery record requires those IPs which are available only after the containers are created, we end up in a chicken-and-the-egg situation. To overcome that, we need to allow the containers to start, but delay the execution of RabbitMQ’s startup script without blocking the container and use to our advantage the fact that RabbitMQ doesn’t start when it can‘t resolve its own hostname (that is why we create those DNS records last).

Deploying the Stack

Once the script is complete, we can call pulumi up --yes to deploy it, where the --yes argument just skips the question whether to deploy or not once Pulumi has built the deployment app and discovered all the resources.

Remember that you need to call Azure CLI to login to your subscription, so that Pulumi can execute the deployment. You can call az login to login to the Azure portal in an interactive manner. Checking the Cluster

Checking the Cluster

To check that all nodes have managed to join the cluster we will connect to one of the nodes using az container exec to stream a shell from within that container (see more on the exec command here).

Once the shell is connected, you can call rabbitmqctl cluster_status and you should see all three nodes in the printed information.

Conclusion

The example in this article can be used as a base for a complete solution, which includes additional containers and managed services provided by Azure. Also, the code for deploying the example, in a real-world scenario, would be better split off to smaller files, as looking at all the code in one large file is overwhelming, therefore harder to maintain.

Announcing Pulumi Azure Provider 2.0

Mikhail Shilkov — Mon, 16 Mar 2020 00:00:00 +0000

This blog post is outdated and no longer accurate. Go to our Azure Classic package page for up to date details.

We are happy to announce the release of a new major version of the Pulumi Azure provider. Pulumi Azure 2.0 is based on the 2.0 release of the upstream provider and brings several improvements and breaking changes.

This article outlines the most significant changes:

Improvements in Azure Storage resources
New resources for VMs & VM Scale Sets
Removed deprecated resources and fields
Latest versions in Callback Functions
Configuring custom timeouts
How to migrate and where to get help if needed

The provider release is not directly related to our Pulumi 2.0 plans.

Improvements in Azure Storage

We streamlined the experience of working with Azure Storage resources.

The Storage Account resource has finally received native support for static website provisioning: it’s as simple as declaring a staticWebsite property:

const storageAccount = new azure.storage.Account("mywebsite", {
 resourceGroupName: resourceGroup.name,
 accountReplicationType: "LRS",
 accountKind: "StorageV2",
 staticWebsite: {
 indexDocument: "index.html",
 },
});

In version 1.x, the Blob resource could upload a file to a storage container, while the ZipBlob would take a local directory, zip it, and upload the archive file to a storage container. In 2.0, we deprecated the ZipBlob resource and combined both capabilities in Blob.

Blob can now accept an instance of the FileAsset class. FileAsset watches the contents of the file on disk, so if the file changes, Pulumi re-uploads the file on the next update.

The following snippet uploads a list of files from a local disk to the newly created static website:

foreach (let file in files)
 new azure.storage.Blob(file, {
 storageAccountName: storageAccount.name,
 storageContainerName: "$web",
 type: "Block",
 source: new pulumi.asset.FileAsset(`./wwwroot/${file}`),
 contentType: "text/html",
 }),
);

Note that resourceGroupName properties were removed from all storage resources except the account: blobs or queues can’t belong to a resource group on their own.

New Resources for Virtual Machine & Virtual Machine Scale Set

There are four new resources for Virtual Machine & Virtual Machine Scale Set separated by operating system: LinuxVirtualMachine, WindowsVirtualMachine, LinuxVirtualMachineScaleSet, WindowsVirtualMachineScaleSet. The old-style generic VirtualMachine and VirtualMachineScaleSet are still available, so you can take your time before migrating existing stacks.

Here is a snippet that defines an Ubuntu VM:

const vm = new azure.compute.LinuxVirtualMachine("server-vm", {
 resourceGroupName,
 networkInterfaceIds: [networkInterface.id],
 size: "Standard_A0",
 sourceImageReference: {
 publisher: "Canonical",
 offer: "UbuntuServer",
 sku: "16.04-LTS",
 version: "latest",
 },
 osDisk: {
 caching: "ReadWrite",
 storageAccountType: "Standard_LRS",
 },
 computerName: "hostname",
 adminUsername: username,
 adminPassword: password,
 disablePasswordAuthentication: false,
);

Removing Deprecated Resources, Invokes, and Fields

Azure Active Directory now has its own Pulumi provider, so all the AD resources were removed from the AD namespace of the Azure Provider 2.0.

A number of other resources, invokes, and fields were removed too, following the changes in the upstream provider.

Default Versions in Callback Functions

Serverless as Callbacks running on Azure Functions have bumped the default version of the Azure Functions runtime to ~3 and Node.js to ~12. As always, you can override the default to set the versions that you require.

Callback Functions also moved from ZipBlob to Blob deploy as described above, so expect another replacement operation while upgrading.

Custom Timeouts

Some types of resources take longer to create than others. For instance, provisioning a new Cosmos DB account may take from 10 minutes to over an hour depending on the number of geo locations and other factors.

If the creation of a target resource times out, you can override the default timeout using resource options:

const cosmosdbAccount = new azure.cosmosdb.Account("cosmosdb", {
 resourceGroupName: resourceGroup.name,
 offerType: "Standard",
 geoLocations: manyLocations,
 consistencyPolicy: { consistencyLevel: "Session" },
}, {
 customTimeouts: {
 create: "30m",
 update: "60m",
 },
});

You shouldn’t need this ability often, but it can be a lifesaver when you do.

Explicit Adoption

Pulumi comes with a way to adopt existing cloud resources by specifying import options.

With the 1.x versions of the Azure provider, some resources could become adopted accidentally: if a name would match an existing resource, the upsert operation could succeed, and Pulumi would start managing the existing resource.

The 2.0 version of the provider is rigorous in checking the presence of existing resources with matching names before attempting to create new ones. This measure prevents inadvertent adoption and undesired side effects.

Getting Started with Migration

To get started with Azure provider 2.0, update the versions in your package manager:

// package.json
"@pulumi/azure": "^2.0.0",

// csproj/fsproj/vbproj
<PackageReference Include="Pulumi.Azure" Version="2.1.0-preview" />

# requirements.txt
pulumi-azure>=2.0.0

// Gopkg.toml
[constraint]]
 version = "v2.0.0"
 name = "github.com/pulumi/pulumi-azure"

There are quite a few breaking changes, so you may need to adjust your code before you can run the program successfully again.

To help with this process, we upgraded all our Azure templates and examples to 2.0.

If you want to stay with the 1.x version, please pin your version to ^1.0.0 or 1.14.0 in the package manager.

If you have issues or questions, reach out to us on Pulumi Community Slack, and we’ll help you through migration.

Modern Cloud Infrastructure in Go - The Road to 2.0

Evan Boyle — Thu, 27 Feb 2020 00:00:00 +0000

Here at Pulumi, everyone on our engineering team is a Gopher. Go has quickly become the “language of the cloud,” and so when we chose to build our open-source pulumi/pulumi engine and SaaS backend, we chose Go. As such, we are very excited to welcome Go to the family of supported infrastructure as code languages as part of Pulumi 2.0.

What is Pulumi?

Go has become the lingua franca of cloud-native infrastructure development. From projects like Docker, to Kubernetes, the community has embraced Go. The result is an ecosystem rich in tooling and packages designed for systems and cloud engineering.

Pulumi lets you use familiar languages to express your application’s infrastructure needs, using a powerful technique called “infrastructure as code.” Using infrastructure as code, you declare desired infrastructure, and an engine provisions it for you so that it’s automated, easy to replicate, and robust enough for demanding production requirements. Pulumi improves this process by leveraging general-purpose languages and making modern cloud infrastructure patterns, such as containers and serverless programs, first-class and easy.

Automatically create, update, or delete cloud resources using Pulumi’s infrastructure as code engine, removing manual point-and-clicking in the cloud provider consoles, UIs, and ad-hoc scripts.
Use your favorite IDEs and tools, including Visual Studio Code, taking advantage of features like auto-completion, refactoring, and interactive documentation.
Catch mistakes early on with standard compiler errors, and an infrastructure-specific policy engine for enforcing security, compliance, and best practices.
Reuse any existing go packages, or distribute your own, whether that’s for infrastructure best practices, productivity, or just general programming patterns.
Build scalable cloud applications using classic infrastructure cloud-native technologies. including serverless functions, and highly scalable databases such as AWS Aurora, into your core development experience, bringing them closer to your application code.

Pulumi’s free open source SDK, which includes a CLI and assortment of libraries, enables these capabilities.

Creating an AWS S3 Bucket is a familiar and simple example that demonstrates these advantages:

package main

import (
 "github.com/pulumi/pulumi-aws/sdk/go/aws/s3"
 "github.com/pulumi/pulumi/sdk/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 // Create an AWS resource (S3 Bucket)
 bucket, err := s3.NewBucket(ctx, "my-bucket", nil)
 if err != nil {
 return err
 }

 // Export the name of the bucket
 ctx.Export("bucketName", bucket.ID())
 return nil
 })
}

Although this code looks remarkably similar to using your cloud’s Go SDK to imperatively change infrastructure, there is a major and important difference: this is declarative infrastructure as code. This code declares to Pulumi a goal state for our infrastructure which Pulumi can then carry out. That means we can preview changes with full diffs before they are made, that we always have a history of changes we’ve made to our infrastructure, and that it works both for the initial provisioning of a new environment as well as revisions to an existing one.

An Expressive and Idiomatic Type System

Making Go a first-class citizen is a goal for the Pulumi 2.0 release. We especially wanted Go to have more idiomatic and stronger typing than interface{}.

Pulumi’s programming model is inherently asynchronous. Consider creating a new AWS SecurityGroup, and using it to provision an EC2 instance. The EC2 instance must wait for the Group to finish provisioning, and the Pulumi engine must track this dependency. While two resources, modern cloud deployments commonly manage hundreds of resources. Pulumi models these resources using promise-like wrappers referred to as Inputs and Outputs allowing us to build a dependency graph, and parallelize cloud resource provisioning where possible.

Inputs, Outputs, and functions that operate over them (All, Apply, Sprintf) must be compatible with raw type primitives (string, integer, list, map, boolean), and user-defined structs. In other words, we must support polymorphism in a language that doesn’t have generics. We hide the gritty details behind a rich, strongly-typed API that we were able to iterate on easily thanks to the utilization of code generation.

Try Pulumi + Go Today

Although Pulumi for Go is in “preview” status until 2.0 is released, it supports all of the essential Pulumi programming model features (and the rest is on its way). Our goal is to gather feedback and over the next few weeks, and work hard to improve the Go experience across the board, including more examples and better documentation. To get started check out:

GoDoc
Getting started with Go and AWS, Azure, or Google Cloud.
Author and deploy serverless functions in Go on AWS Lambda and GCP Cloud Functions.
Build a serverless container-based application on AWS ECS Fargate.
Deploy a web server on a virtual machine with AWS or Azure.
Deploy a Kubernetes cluster using Azure Kubernetes Service.

To keep up with our progress, follow Pulumi on Github, and feel free to open a new issue with ideas, feedback, and bugs. Join the community in Slack to discuss your scenarios, and to get any needed assistance from the team and other end users.

Coming Soon

Some exciting things to keep an eye out for:

Manage Any Infrastructure with Policy as Code

Sophia Parafina — Tue, 18 Feb 2020 00:00:00 +0000

In an earlier article, we introduced examples of Policy as Code to prevent two of the most common causes of data breaches. Policies are the guardrails of infrastructure. They control access, set limits, and manage how infrastructure operates. In many systems, policies are created by clicking on a GUI, making it difficult to replicate or version. Pulumi implements policy by writing it in Typescript, which ensures that you can write policies using software development practices such as automated testing, deployment, and version control.

Gareth Rushgrove said in a QCon presentation:

“My policy kit doesn’t need to just be about bits on disk and packages, and files, and my SSH config, and my firewall rules, and my network rules. It can be about my cloud instances and how they’re actually configured and set up at the API level. Ultimately, there’s an API somewhere, and I have a bunch of resources, and I want to set some policies about them.”

Pulumi released the CrossGuard preview last fall. CrossGuard lets you verify, enforce, and apply custom policies on resources in your infrastructure. You can run policies against any Pulumi stack, which means that you can apply policies written in TypeScript to stacks written in any language supported by Pulumi such as Python, Go, and .NET languages. Policy Packs are bundles of policies, and when you run pulumi up, CrossGuard evaluates every resource in the stack against the Policy Pack. CrossGuard works in AWS, Azure, Google Cloud Platform, and Kubernetes.

The CrossGuard preview provides the following key features:

Policy SDK for coding custom policies using TypeScript or Javascript
Running a Policy Pack locally to speed up development and testing of policies. Validate infrastructure before deployment.
AWSGuard is a ready-to-apply playbook for enforcing AWS best practices for security, reliability, and cost
Apply a Policy Pack across an organization to validate all the infrastructure deployed

CrossGuard ensures that you can enforce best practices for cost, compliance, security, and team practices for a single project or across your organization. Let’s look at how we can apply policies to infrastructure deployed across cloud providers and Kubernetes.

Controlling cost on AWS

The amount of an AWS monthly bill has become a cliché in the tech industry. From services using improperly sized AMIs to orphaned infrastructure left running, there are many ways to incur a huge bill. One way to limit infrastructure spend is to set a not to exceed policy. We want to calculate the costs before deployment. The pricing data is available online, but calculating the cost using configuration data to enumerate resources and services can be a manual process. However, if your infrastructure as code solution is Pulumi, you can use your preferred programming language to calculate the cost before deployment and check it against your policy.

The example below shows how the policy finds all the instances and validates the aggregate cost against the maximum monthly amount allowed. It does this by finding the monthly on-demand price and aggregating all the costs.

import * as aws from "@pulumi/aws";
import { PolicyPack, validateStackResourcesOfType } from "@pulumi/policy";
import { getMonthlyOnDemandPrice, formatAmount } from "./utils";
import { maxMonthlyCost } from "./config";

new PolicyPack("aws", {
 policies: [
 {
 name: "instance-cost-estimate",
 description: `Limit instance costs to $${maxMonthlyCost}.`,
 enforcementLevel: "mandatory",
 validateStack: validateStackResourcesOfType(aws.ec2.Instance, (instances, args, reportViolation) => {
 // Aggregate costs.
 let totalMonthlyAmount = 0;
 instances.forEach(instance => {
 totalMonthlyAmount += getMonthlyOnDemandPrice(instance.instanceType);
 });

 if (totalMonthlyAmount > maxMonthlyCost) {
 reportViolation(`Estimated monthly cost [${formatAmount(totalMonthlyAmount)}] exceeds [${formatAmount(maxMonthlyCost)}].`);
 }
 }),
 }
 ],
});

Setting the maximum amount and calculating the monthly on-demand price for all ec2 instances is aided by two helper classes config and utils. You can set variables such as maxMonthlyCost in config.ts. The utils can calculate costs from either a static file of prices, as demonstrated in the example, or through the Amazon Pricing API. Because we’re using a modern programming language, we can go beyond what a policy encoded in YAML or JSON can do.

config.ts

export const maxMonthlyCost = 500;

utils.ts

import * as fs from "fs";
import * as zlib from "zlib";

/**
* Cost-related helpers
*/
export const getPricingData = function (): (any) {
 const localFilePath = "./offers-ec2-us-east-1.json.gz";
 if (!fs.existsSync(localFilePath)) {
 throw new Error();
 }
 const localPricingDataGz = fs.readFileSync(localFilePath);
 const localPricingData = zlib.gunzipSync(localPricingDataGz);
 return JSON.parse(localPricingData.toString());
}

export const getMonthlyOnDemandPrice = function (instanceType: string): (number) {
 const pricingData: any = getPricingData();
 const pricingDataProducts: any = pricingData["products"];
 const pricingDataTermsOnDemand: any = pricingData["terms"]["OnDemand"];

 const arrValues = Array.from(Object.values(pricingDataProducts));
 const skus: any[] = arrValues.filter((it: any) =>
 it["attributes"]["instanceType"] === instanceType
 && it["attributes"]["operatingSystem"] === "Linux" // TODO: use AMI to determine this
 && it["attributes"]["preInstalledSw"] === "NA"
 && it["attributes"]["usagetype"] === `BoxUsage:${instanceType}`
 );
 if (skus.length > 1) {
 console.log("Shouldn't find more than one sku. Continuing with first...");
 }
 const sku = skus[0]["sku"];

 const skuCode = `${sku}.JRTCKXETXF`; // JRTCKXETXF = On demand offer term code
 const skuPricing: any = pricingDataTermsOnDemand[sku][skuCode];

 const priceRateCode = `${skuCode}.6YS6EN2CT7`; // 6YS6EN2CT7 = Price per hour rate code
 const priceDimension: any = skuPricing["priceDimensions"][priceRateCode];

 const pricePerHour = Number(priceDimension["pricePerUnit"]["USD"]);
 const costPerMonth = pricePerHour * 24 * 30;
 return costPerMonth;
}

export const formatAmount = function (amount: number): (string) {
 return '$' + amount.toFixed(2);
}

Compliance with Azure

The breadth and depth of services provided by cloud providers are vast. Beyond infrastructure services, you can access machine learning, image recognition, and voice services. If you can think of a service, it’s very likely a product offering. However, it’s best practice to operate your infrastructure under the principle of least privilege, i.e., only allowing access to resources needed to perform a job.

Azure Cloud Computing Services provides a list of services such as blockchain, mixed reality, Internet of Things. A best security practice is not to let unknown devices attach to your network. The policy below prohibits the use of IoT services because the endpoints are potentially untrusted and could be an entry point for bad actors.

import * as azure from "@pulumi/azure";
import * as pulumi from "@pulumi/pulumi";
import { PolicyPack, ReportViolation, ResourceValidationArgs, } from "@pulumi/policy";

const policies = new PolicyPack("azure", {
 policies: [
 {
 name: "prohibited-iot",
 description: "Use of IOT services is prohibited.",
 enforcementLevel: "mandatory",
 validateResource: (args: ResourceValidationArgs, reportViolation: ReportViolation) => {
 if (args.type.startsWith("azure:iot")) {
 reportViolation(`Use of [${args.type}] is prohibited.`);
 }
 },
 },
 ],
});

Control Ingress and Egress with Google Cloud Platform

Access control to resources is a fundamental part of infrastructure security. While production deployments may be tightly controlled, it’s not uncommon to spin up a dev infrastructure for testing during the development cycle. It isn’t unknown for devs to leave resources with public addresses on the Internet for a quick test and forget to tear it down after completing testing.

It’s a best practice to control ingress and egress of resources and not expose them on the Internet unless needed. The policy below issues a warning if a compute instance, or virtual machine has a public IP address, and it prohibits ingress from the public internet. When we run pulumi up or pulumi preview, the resource graph will show if either condition is met, and the deployment can be revised to follow the policies.

import * as gcp from "@pulumi/gcp";
import { validateResourceofType, PolicyPack, } from "@pulumi/policy";

const policies = new PolicyPack("gcp", {
 policies: [
 {
 name: "discouraged-gcp-public-ip-address",
 description: "Associating public IP addresses is discouraged.",
 enforcementLevel: "advisory",
 validateResource: validateResourceOfType(gcp.compute.Instance, (instance, _, reportViolation) => {
 const publicIps = instance.networkInterfaces.find(net => net.accessConfigs !== undefined);
 if (publicIps !== undefined) {
 reportViolation("`accessConfigs` should be undefined in most cases.");
 }
 }),
 },
 {
 name: "prohibited-public-internet",
 description: "Ingress rules with public internet access are prohibited.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(gcp.compute.Firewall, (firewall, _, reportViolation) => {
 const publicInternetRules = (firewall.sourceRanges || []).find(ranges =>
 ranges === "0.0.0.0/0"
 );
 if (publicInternetRules !== undefined) {
 reportViolation("`sourceRanges` should not be '0.0.0.0/0'");
 }
 }),
 },
 ],
});

Enforcing best practices with Kubernetes

Immutability was one of the fundamental concepts behind containers. All application dependencies were locked in place, guaranteeing that the application would run regardless of where it was deployed. That principle can be carried forward to Kubernetes; a deployment should pin the containers to a specific version to keep the infrastructure consistent.

During development, an application may use containers tagged latest. Given the complexity of modern applications, these containers may pass testing and go into production. It isn’t until the application is in production and a new pod spins up to replace a failing pod that the containers tagged latest break a dependency. The new pod with the latest tags would cause the application to fail. The policy example below would prevent deploying pods from using containers tagged latest.

import * as k8s from "@pulumi/kubernetes";
import { PolicyPack, validateResourceOfType } from "@pulumi/policy";

new PolicyPack("k8s", {
 policies: [
 {
 name: "pin-image-versions",
 description: "Images should be pinned to a specific version",
 enforcementLevel: "advisory",
 validateResource: validateResourceOfType(k8s.apps.v1.Deployment, (deployment, _, reportViolation) => {
 (deployment?.spec?.template?.spec?.containers || []).forEach(container => {
 if (container.image && container.image.endsWith(":latest")) {
 reportViolation("Image version should not be 'latest'.");
 }
 })
 }),
 },
 ],
});

Conclusion

Whether you deploy your infrastructure on AWS, Azure, GCP, or Kubernetes, Pulumi’s CrossGuard can help manage your infrastructure. We’ve shown four policies for controlling cost on AWS, ensuring that Azure infrastructure is compliant by allowing only approved resources, controlled access to and from VMs in Google Cloud Platform, and enforced best practices on Kubernetes by pinning container versions by tag. These policies work across many different resources because they use a familiar programming language that provides the ability to create policies that can use external data sources to determine costs, reuse the same policy on different providers, and allow us to see any violations, advisory or mandatory, before deployment. Learn more about policy as code:

Inside Crosswalk for Kubernetes

Sophia Parafina — Thu, 21 Nov 2019 00:00:00 +0000

This post describes an early version of Crosswalk for Kubernetes. Some of the links, examples, and implementation details may have changed. For the most up-to-date information, see the Pulumi Kubernetes documentation.

Running Kubernetes in production can be challenging. This past year, Pulumi has collected common patterns of usage informed by best practices for provisioning Kubernetes infrastructure and running containerized applications. We call this Pulumi Crosswalk for Kubernetes: a collection of playbooks and libraries to help you to successfully configure, deploy, and manage Kubernetes in a way that works for teams in production.

Kubernetes is Vast and Complex

Kubernetes is the standard multi-cloud platform for modern containerized applications. Usage has grown by 50% in just six months according to a DZone article. There is also a strong trend for public cloud container adoption shifting to Kubernetes.

Rapid adoption of a complex platform such as Kubernetes presents challenges. For example, enterprise teams can take six to twelve months to on-ramp to Kubernetes, containers, and the cloud before their application goes into production. Once deployed, misconfigured infrastructure accounts for 40 to 50% of production outages.

Managed Kubernetes clusters, such as AWS Elastic Kubernetes Services (EKS), Azure Kubernetes Services (AKS), Google Kubernetes Engine and Digital Ocean, have become popular because they help tame the complexity of building and maintaining clusters. However, managed Kubernetes solutions are just the starting point and require adding and configuring additional infrastructure and services before they are secure, robust, and ready for deploying your production applications.

How Crosswalk for Kubernetes Is Organized

We have been working with customers and open source users of our infrastructure as code tools for Kubernetes and we’ve seen several common patterns that we’ve distilled into six distinct playbooks realized as stacks:

Identity
Managed Infrastructure
Cluster Configuration
Cluster Services
Application Services
Applications

By leveraging stacks, we can tackle each unique concern one at a time in a way that composes nicely.

Identity

Establishing identities and roles for organizations and CI/CD is a requirement for secure production software configuration. An identity stack contains identities and roles for the team and service accounts for CI/CD and bots that automate processes. Each cloud provider establishes identity in their unique way and the guides provide instructions for AWS IAM, GCP IAM, and Azure AD. Example code is available for each cloud provider: AWS Identity and Access Management, GCP Identity and Access Management, Azure Active Directory.

After completing this step, your cluster and CI/CD deployment procedures can use IAM to ensure access to your cluster, the ability to change applications and configuration and the resulting runtime environment is secure using similar techniques to what you might have already been using on your cloud of choice.

Managed Infrastructure

Many of us are shifting to infrastructure running on a managed cloud provider. While there are benefits to using managed cluster infrastructure, additional related resources often need to be provisioned. At the minimum, this requires building networking infrastructure, storage backends and any number of resources such as CMS, container registries, and data pipelines.

Crosswalk for Kubernetes covers two of the most common tasks, configuring networking and provisioning storage, in detail. Kubernetes will typically use private subnets for load balancers, private subnets for workers and managed Pod networking. Another requirement of Kubernetes is storage which provides data persistence through either shared storage and or volumes for Pods. There are many types of volumes and they vary from cloud provider but can generally be divided into mechanical drives and SSDs and network backed storage such as CephFS or NFS.

The guide provides instructions and full code examples to implement managed infrastructure stacks for both networking for AWS, Azure, and GCP.

After completing these guides, you will have all of the underlying infrastructure required to begin configuring your actual Kubernetes cluster itself.

Cluster Configuration

Managed Kubernetes services, such as AWS EKS, Azure AKS, and Google GKE, provide a simple way to deploy a barebones Kubernetes cluster with reasonable defaults. The cluster requires cluster-wide services to be used in production, this includes creating resources for the application and logically segmenting the cluster and setting policies and quotas.

The guide demonstrates how to create names for cluster services such as logging and monitoring, application services like ingress and DNS services, and applications. An example of resource quotas across all Pods in a namespace, and how to set PodSecurityPolicies for setting cluster level security controls. Complete examples for AWS, Azure, and GCP are on GitHub.

After this step, you’ll have a fully-functioning Kubernetes cluster. Before moving on to deploying applications into it, however, you will want to set up some services to make your cluster more manageable and ready to connect applications to the outside world.

Cluster Services

Cluster services are scoped at the Kubernetes cluster level and typically shared between many applications deployed to the same cluster. Common cluster services are logging, monitoring, policy enforcement, container registries, and service meshes. The guide provides an example of how to configure logging and monitoring, including how to set up Datadog to aggregate node and container metrics and events. Examples are also provided on how to configure native cloud provider logging solutions. Full examples are available for AWS and Azure on Github.

Application Services

Applications also require additional services such as ingress controllers, DNS and TLS, and data stores. The guide covers how to implement datastores and general application services such as a NGINX ingress controller.

Configuring data stores is another common task-specific to your application. In many cases, end-users are more successful when leveraging hosted data services like AWS S3 or RDS, Azure CosmosDB, or Google Bigtable, rather than worrying about configuring stateful containers. The AWS example and the GCP example shows how to deploy and configure PostgreSQL and Redis. The Azure example example demonstrates how to deploy Cosmos DB and MongoDB.

Now that we’ve configured our cluster and all of the services required to run an application, the next step is to configure and deploy your application. This begins with the authoring experience and ends with continuous delivery.

Applications

Deploying applications can involve many types of tasks, ranging from building and deploying apps in a container, deploying with Helm charts, deploying a job, a DaemonSet, and StatefulSet. One of the most common tasks in a microservices architecture is building a container, pushing it to a registry and deploying it to Kubernetes. For comparison, the example is written in typescript with just the Pulumi for Kubernetes library and the Kubernetes Crosswalk. Note the difference in deployment.

Pulumi supports the entire Kubernetes object model out of the box so you can use languages like TypeScript and Python rather than YAML. Crosswalk for Kubernetes also includes a library to reduce boilerplate in your application’s configuration and help you be more productive. For comparison, this example is written in TypeScript first using the raw Pulumi for Kubernetes library, and then using Kubernetes Crosswalk. Although the differences here are small, for large configurations, we often see a reduction of code by over 50%.

Pulumi for Kubernetes

// Create a Deployment of the built container.
const appLabels = { app: customImage };
const appDeployment = new k8s.apps.v1.Deployment("app", {
 spec: {
 selector: { matchLabels: appLabels },
 replicas: 1,
 template: {
 metadata: { labels: appLabels },
 spec: {
 containers: [{
 name: customImage,
 image: appImage,
 ports: [{name: "http", containerPort: 80}],
 }],
 }
 },
 }
}, { provider: provider });

Crosswalk for Kubernetes

// Define the Pod for the Deployment.
const pb = new kx.PodBuilder({
 containers: [{
 image: appImage,
 ports: { "http": 80 },
 }],
});

// Create a Deployment of the Pod defined by the PodBuilder.
const appDeploymentKx = new kx.Deployment("app-kx", {
 spec: pb.asDeploymentSpec(),
}, { provider: provider });

There are many more application examples in the Guide. Complete code examples for building and deploying a container in a Kubernetes cluster are available on Github. Additional application examples for other common application tasks are also available on Github.

Often teams will start with manual CLI-driven deployments, which is great for a fast initial development experience. Afterward, however, most teams will adopt CI/CD, so that deployments are triggered automatically by other events such as Git commits or Slack commands. This helps multiple team members collaborate on reviews and shared changes, ensure that practices such as testing are well-integrated into the workflow, and help promotions between multiple environments. A series of guides walks through how to continuously deliver your Kubernetes applications using many popular CI/CD systems, such as GitLab, Codefresh, Azure DevOps Pipelines, and more.

Playbooks for Multiple Audiences

Crosswalk for Kubernetes was informed by our experience working with developers and operators. We have grouped common tasks in playbooks that make deploying applications on Kubernetes accessible regardless of what part of the deployment you are working on. If you work with Kubernetes, we invite you to try infrastructure as code using Crosswalk for Kubernetes.

Azure Functions on Kubernetes with KEDA

Mikhail Shilkov — Thu, 10 Oct 2019 00:00:00 +0000

Azure Functions is a managed service for serverless applications in the Azure cloud. More broadly, Azure Functions is a runtime with multiple hosting possibilities. KEDA (Kubernetes-based Event-Driven Autoscaling) is an emerging option to host this runtime in Kubernetes.

In the first part of this post, I compare KEDA with cloud-based scaling and outline the required components. In the second part, I define infrastructure as code to deploy a sample KEDA application to an Azure Kubernetes Service (AKS) cluster.

The result is a fully working example and a high-level idea of how it works. Kubernetes expertise is not required!

Autoscaling Primer

When you deploy an Azure Function, it runs within the Azure Functions runtime. The runtime is a host process which knows how to pull events from an event source (defined by the function trigger) and pass those to your function:

However, one instance of runtime rarely provides adequate processing capacity. If you only get one message per day, having an instance always running is wasteful. If you get thousands of events per second, one instance won’t be able to process all of them.

Automatic horizontal scaling solves the problem. At any point in time, several identical workers are crunching the events. The number N is optimized continuously to fit the current workload by adding new workers and removing underutilized ones.

Components of an automatically scaled application

Instance Provisioner is an extra component in the auto-scaled system. It monitors the stream of metrics from the event source and decides to add or remove workers. A massive standby pool of idle generic workers provides the workforce. Such a generic worker pulls the artifact of the assigned function, plugs it into the runtime, and starts processing events.

Azure Functions Consumption Plan

Consumption Plan is the serverless hosting option where Azure manages all the scaling components internally. Let’s consider an example of an Azure Function triggered by a Storage Queue:

Azure Functions Consumption Plan

The deployment artifact is just the code packaged as a zip archive and uploaded to Blob Storage. Scale Controller is an internal Azure component that observes the target queue and allocates Function App instances based on the queue length fluctuations. Each instance bootstraps itself with a zip file, connects to the queue, and pulls messages to process.

The cloud provider manages all the components of the system, so developers can focus on writing business logic code. It can be as simple as a JavaScript callback:

queue.onEvent("MyHandler", async (context, msg) => {
 console.log("New message: " + JSON.stringify(msg));
});

KEDA

Over the last few years, Kubernetes has gained traction across many industries. KEDA is provides a way to design and run event-driven applications inside a Kubernetes cluster. KEDA implements the autoscaling components in terms of Kubernetes tools.

The target Function App is packaged together with the Azure Functions runtime into a custom Docker image and published to a registry. A Kubernetes deployment utilizes that image and configures the parameters to connect it to the target event source (for instance, a queue):

The application can then run on one or many instances, or pods in Kubernetes terms. Kubernetes has a built-in component to scale out the pods: Horizontal Pod Autoscaler (HPA). By default, HPA makes scaling decisions based on the processor utilization of existing pods. CPU turns out to be a poor metric for event-driven applications: many workloads are not CPU-bound, so the scale-out won’t be aggressive enough to keep the queue empty. Therefore, KEDA introduces a ScaledObject—a custom resource which pulls metric values from the event source and feeds them as a custom metric to HPA:

Kubernetes-based Event-Driven Autoscaling

At the time of the initial KEDA preview announcement and until Kubernetes version 1.16, Horizontal Pod Autoscaler wasn’t able to scale a deployment down to zero pods. Therefore, KEDA includes an extra controller to disable the deployment if the event source is empty and re-enable it when new events come in. This duty might be delegated back to HPA in the future versions.

Now, when we know what KEDA is and how it works, it’s time to deploy a Function App!

Deploy a Function App with KEDA and Pulumi

Here is the list of the components required to run a Function App in Kubernetes with KEDA:

Azure Kubernetes Service cluster
Azure Container Registry
Helm chart keda-edge with KEDA service and custom resource definition
Azure Storage Queue as a sample event source
Docker image of the queue processor application
Deployment of this image
Scaled Object custom resource

All these components can be defined and deployed within a single Pulumi program. Below I highlight the main blocks of the program. Navigate to the following section to look at a short and reusable component.

AKS Cluster

KEDA can run on any Kubernetes cluster, but I choose to do so on managed AKS. My custom AksCluster component defines a cluster, including the required Active Directory and networking configuration. It makes multiple assumptions, so I only need to specify the main properties:

const resourceGroup = new azure.core.ResourceGroup("keda-sample");

const aks = new AksCluster("keda-cluster", {
 resourceGroupName: resourceGroup.name,
 kubernetesVersion: "1.13.5",
 vmSize: "Standard_B2s",
 vmCount: 3,
});

aks.cluster now has all the required output values, for instance, aks.cluster.kubeConfigRaw configuration.

Shared Cluster Components

The next group of components needs to be deployed just once.

Azure Container Registry is not part of the AKS cluster. Its purpose is to host Docker images of applications.

const registry = new azure.containerservice.Registry("registry", {
 resourceGroupName: args.resourceGroup.name,
 adminEnabled: true,
 sku: "Premium",
});

A Helm chart kedacore/keda-edge deploys the KEDA service and the ScaledObject custom resource definition.

const keda = new k8s.helm.v2.Chart("keda-edge", {
 repo: "kedacore",
 chart: "keda-edge",
 version: "0.0.1-2019.07.24.21.37.42-8ffd9a3",
 values: {
 logLevel: "debug",
 },
}, { providers: { kubernetes: aks.provider } });

Event Source

KEDA supports multiple types of event sources, and the current list is available here. An event source is supported if there is a scaler which knows how to pull metrics out of it and turn them into a custom metric for HPA.

My example uses an Azure Storage Queue as the event source:

const storageAccount = new azure.storage.Account("kedasa", {
 resourceGroupName: resourceGroup.name,
 accountTier: "Standard",
 accountReplicationType: "LRS",
});

const queue = new azure.storage.Queue("kedaqueue", {
 storageAccountName: storageAccount.name,
});

Docker Image

The same Pulumi program is capable of building a Docker image and uploading it to the Container Registry.

const dockerImage = new docker.Image("image", {
 imageName: pulumi.interpolate`${registry.loginServer}/${args.queue.name}:v1.0.0`,
 build: {
 context: "./functionapp",
 },
 registry: {
 server: registry.loginServer,
 username: registry.adminUsername,
 password: registry.adminPassword,
 },
});

The image refers to the folder with a Dockerfile in it and uses the registry variables to fill the credentials.

Deployment

Now, we can define a Deployment which uses the Docker image to run our Function App on Kubernetes pods.

const appLabels = { app: name };
const deployment = new k8s.apps.v1.Deployment(name, {
 apiVersion: "apps/v1",
 kind: "Deployment",
 metadata: {
 labels: appLabels,
 },
 spec: {
 selector: { matchLabels: appLabels },
 template: {
 metadata: {
 labels: appLabels,
 },
 spec: {
 containers: [{
 name,
 image: dockerImage.imageName,
 env: [{ name: "queuename", value: args.queue.name }],
 envFrom: [{ secretRef: {name: secretQueue.metadata.name } }],
 }],
 imagePullSecrets: [{ name: args.service.registrySecretName }],
 },
 },
 },
}, { provider: aks.provider });

The deployment refers to the secret value which stores the connection string to our target Storage Queue:

const secretQueue = new k8s.core.v1.Secret("queue-secret", {
 data: {
 queueConnectionString:
 args.storageAccount.primaryConnectionString.apply(c => Buffer.from(c).toString("base64")),
 },
}, { provider: aks.provider });

Scaled Object

Finally, we need to deploy an instance of the ScaledObject custom resource, which takes care of feeding the metrics from the queue to the Horizontal Pod Autoscaler.

const scaledObject = new k8s.apiextensions.CustomResource("scaledobject", {
 apiVersion: "keda.k8s.io/v1alpha1",
 kind: "ScaledObject",
 metadata: {
 labels: { deploymentName: name },
 },
 spec: {
 scaleTargetRef: { deploymentName: name },
 triggers: [{
 type: "azure-queue",
 metadata: {
 type: "queueTrigger",
 connection: "queueConnectionString",
 queueName: args.queue.name,
 name: "myQueueItem",
 },
 }],
 },
}, { provider: aks.provider });

Reusable Components

We can simplify the program further by creating reusable Pulumi components for a Cluster, a Service, and a Function app. After those are done, here is all the code required to deploy a Kubernetes cluster with a Function App and KEDA.

// Create an AKS K8s cluster
const aks = new AksCluster("keda-cluster", {
 resourceGroupName: resourceGroup.name,
 kubernetesVersion: "1.13.5",
 vmSize: "Standard_B2s",
 vmCount: 3,
});

// Deploy shared components of KEDA (container registry, kedacore/keda-edge Helm chart)
const service = new KedaService("keda-edge", {
 resourceGroup,
 k8sProvider: aks.provider,
});

// Deploy a Function App which subscribes to the Storage Queue
const app = new KedaStorageQueueHandler("queue-handler", {
 resourceGroup,
 storageAccount,
 queue,
 service,
 path: "./functionapp",
});

You can find the full code of the components, the sample program, and steps to run it in this example.

Conclusion

If your company is betting on Kubernetes as the standard application platform and you see high value in event-driven fine-grained applications, KEDA might be an exciting option for the future. As of March 31, 2020, Kubernetes Event-driven Autoscaling (KEDA) has joined the CNCF as an official sandbox project.

Pulumi is a great tool to get your KEDA application running quickly and effortlessly. You can combine Docker image creation, Kubernetes cluster provisioning, Helm chart installation, and KEDA deployment in a single program, written in your favorite general-purpose language.

Get started with Azure Kubernetes Service (AKS) Cluster and Azure Functions with KEDA.

How To Build Globally Distributed Apps with Azure Cosmos DB

Mikhail Shilkov — Tue, 24 Sep 2019 00:00:00 +0000

In a previous blog post, I shared how easy it is to create a globally distributed, highly-available, low-latency application with Azure Functions, Azure Cosmos DB, and Pulumi.

Today, I want to show how the same approach can be generalized for any cloud compute service, including containers, virtual machines, and serverless functions.

E-commerce Example

Let’s consider an example of an e-commerce website which targets a worldwide audience. The architecture of such a website should address several challenges.

Multiple Teams

A large e-commerce website is a sophisticated software application and consists of many subcomponents. Many engineers in multiple teams work on it simultaneously.

A typical approach is to organize engineers into smaller teams and make each team autonomous and responsible for one or several business domains. This strategy leads to microservices architecture when the application is built out of loosely coupled components. Each component represents a “vertical slice”: a team owns functionality across the vertical stack, from its user interface and service API to the data storage layer and underlying infrastructure.

Here is an example of such a breakdown:

Multiple components on a single web page

Diversity of Technology Decisions

One of the guiding principles of microservices architecture is that each team makes decisions regarding which tools and technologies to use. They are free to choose programming languages, databases, or cloud services that are the best fit for the service. In practice, some restrictions do apply—for instance, the teams might need to share the same cloud provider.

In our hypothetical example, the whole product is hosted on Azure cloud, however other aspects differ:

Product Page team runs JavaScript serverless functions and stores data in a document database
Shopping Cart team uses C# and .NET Core, packages the code in a Docker container, and uses event sourcing to store every action ever made by users while shopping
Pricing Engine team has a mix of Java and C++ code with a bunch of third-party libraries and deploys the services to Ubuntu VMs that use MongoDB drivers for storage

Global Presence

Regardless of the tech, the user-facing services must serve customers across the globe and serve them fast. This requirement demands a geo-distributed infrastructure so that user requests could be handled by the nearest data center to minimize the latency and ensure excellent user experience.

Each team has to solve the following problems in a way which fits their tech stack:

Distribute the data across the globe
Run their compute workload in each region next to the data
Manage all this infrastructure in a reliable way

Let’s consider these goals and possible solutions.

Azure Cosmos DB

Distributing data across many data centers while keeping them consistent and available is one of the hardest problems in computer science and engineering. Delegating this challenge to a specialized service or product is usually a sensible idea.

Azure Cosmos DB is the database of choice for global applications running in the Azure cloud. Cosmos DB provides a turn-key global distribution to any number of regions worldwide. Regions can be added or removed along the way while running production workloads and without having any impact on high availability. The accounts can be provisioned with a single write region or in multi-master mode with every region being writable, thus enabling writes that are local to each region.

Azure Cosmos DB with multiple locations

Cosmos DB supports multiple models of data: key-value, document, column family, graph, with wire-protocol compatible APIs for MongoDB, Apache Cassandra, SQL, etcd, Gremlin, etc. It also supports multiple well-defined and practical consistency levels, from eventual to strong consistency, so that each application can strike the right balance between latency, availability, and consistency guarantees. All of this is offered as a fully-managed service, with the comprehensive SLAs covering latency, throughput, consistency, and 99.999% high availability for both reads and writes.

Sounds great, but how do we build applications to leverage this power?

Distributed Web Applications

In contrast to Cosmos accounts, compute services in Azure are located in a single region. This holds true for Virtual Machines, Container Instances, Serverless Functions, and managed Azure Kubernetes Service.

If an application is deployed to a single location, we are not making good use of geographic redundancy of the database. If a user happens to be far from the application region, their request has to travel across the globe. Moreover, the application connects to the nearest region of Cosmos DB, while all other regions stay idle:

Application deployed in a single location

Instead, we should deploy a copy of application infrastructure to each of the target regions:

Application deployed in multiple locations

Each application instance has to be configured to connect to the endpoint of the Cosmos DB in the same region to enjoy local single-digit-milliseconds latency for reads and writes.

While beneficial to end-users, such setup brings much extra complexity in terms of infrastructure management:

Application regions must stay in sync with Cosmos DB regions, including the correct configuration of preferred locations.
With the growth of the number of regions, the traditional capacity planning gets harder and harder. This makes a dynamic auto-scaling configuration increasingly important.
A central routing service must be configured to flow the traffic from end-users to the closest application instance.
Each team must execute all these tasks, independently but coherently.

Let’s see how infrastructure as code and a general-purpose programming language come to the rescue.

Search for a Reusable Abstraction

In our example, three teams have a common goal of providing high-quality service to customers around the world, but they differ in the compute services they want to use.

Product Card team relies on serverless functions, so their infrastructure may look like this:

Global application with Azure Functions

Shopping Cart team packages their code as a Docker container, which they put into Azure Container Registry, and then use Azure Container Instances to run the application. The Registry is a global Azure resource, while Container Instances are deployed separately per region.

Global application with Azure Container Instances

Pricing Engine team runs their code on Infrastructure-as-a-Service (IaaS), so they have a task of creating Virtual Machine images, and then deploying those to an Azure Virtual Machine Scale Set, fronting it with a Load Balancer, and configuring all the networking infrastructure including Virtual Networks, Subnets, Public IPs, Network Security Groups, etc. Once again, this has to be done for each location independently.

Global application with Virtual Machines

Each team has the same global structure of infrastructure, including a Traffic Manager front-end and a Cosmos DB data store. At the same time, the per-region compute infrastructure differs substantially.

Instead of copying the common pieces of infrastructure between the teams, we can think of a reusable abstraction which could be shared by every service.

Global application pattern

For this blog post, I created a custom Pulumi component called CosmosApp which implements such abstraction and simplifies the provisioning of global web applications. The component creates distributed Cosmos DB resources, as well as the front-end routing component, while allowing pluggable compute layer implementation.

Cosmos App with Azure Functions

Let’s look at an example of how the component can be used. Creating a globally-distributed application requires three steps:

List the Regions

We define a configuration value to contain a comma-separated list of Azure regions that we’ll deploy the application to.

$ pulumi config set locations WestUS,WestEurope,SouthEastAsia,SouthBrazil,AustraliaCentral

This value can be loaded and parsed into a JavaScript array:

const locations = new pulumi.Config().require("locations").split(",");

Build a Region Template

We define a factory function to create the infrastructure in each location. Its signature is a bit unusual in that we return a function from another function. I’ll explain the motivation in the next example. For now, it’s important to understand the following:

We get a Cosmos account and a location as input arguments
We create a Function App in the specified location with connection settings pointing to the local Cosmos DB replica
We return the identifier of the Function App so that a Traffic Manager endpoint could point to it

Here is the function:

function buildProductApp({ cosmosAccount }: GlobalContext) {
 return ({ location }: RegionalContext) => {
 const app = new azure.appservice.ArchiveFunctionApp("function-app", {
 resourceGroupName: resourceGroup.name,
 location,
 archive: new pulumi.asset.FileArchive("./app"),
 appSettings: {
 COSMOSDB_ENDPOINT: cosmosAccount.endpoint,
 COSMOSDB_KEY: cosmosAccount.primaryMasterKey,
 COSMOSDB_LOCATION: location,
 },
 });

 return {
 id: app.functionApp.id,
 };
 };
}

Instantiate a Cosmos App

Finally, we use the buildProductApp factory function to create the geo-distributed application:

const products = new CosmosApp("products", {
 resourceGroup,
 locations,
 databaseName: "productsdb",
 containerName: "products",
 factory: buildProductApp,
});

[ Full Example ]

Cosmos App with Container Instances

The Shopping Cart team will have to follow the same steps but define their compute infrastructure accordingly.

A significant difference to the Functions-based example is the fact that the Container-based application needs some infrastructure to be shared across regions. The top block of the factory function defines an instance of Azure Container Registry, builds a Docker image, and puts that image into the Registry:

function buildShoppingCartApp({ cosmosAccount, database, container }: GlobalContext) {

 const registry = new azure.containerservice.Registry("global", {
 resourceGroupName: resourceGroup.name,
 adminEnabled: true,
 sku: "Premium",
 }, opts);

 const dockerImage = new docker.Image("node-app", {
 imageName: pulumi.interpolate`${registry.loginServer}/mynodeapp:v1.0.0`,
 build: {
 context: "./container",
 },
 registry: {
 server: registry.loginServer,
 username: registry.adminUsername,
 password: registry.adminPassword,
 },
 });

 return ({ location }: RegionalContext) => {
 // ... see the next sample
 };
}

Now, the factory function that builds per-region infrastructure can directly reference the Registry and the image to deploy an Azure Container Instances group. Note how registry and dockerImage are used as any other TypeScript variable inside the closure factory function:

function buildShoppingCartApp({ cosmosAccount, database, container }: GlobalContext) {

 const registry = new azure.containerservice.Registry(/* ... */);
 const dockerImage = new docker.Image(/* ... */);

 return ({ location }: RegionalContext) => {
 const group = new azure.containerservice.Group(`aci-${location}`, {
 resourceGroupName: resourceGroup.name,
 location,
 imageRegistryCredentials: [{
 server: registry.loginServer,
 username: registry.adminUsername,
 password: registry.adminPassword,
 }],
 osType: "Linux",
 containers: [
 {
 cpu: 0.5,
 image: dockerImage.imageName,
 memory: 1.5,
 name: "web-server",
 ports: [{
 port: 80,
 protocol: "TCP",
 }],
 environmentVariables: {
 ENDPOINT: cosmosAccount.endpoint,
 MASTER_KEY: cosmosAccount.primaryMasterKey,
 DATABASE: database.name,
 COLLECTION: container.name,
 LOCATION: location,
 },
 },
 ],
 ipAddressType: "public",
 dnsNameLabel: `acishop-${location}`,
 });

 return {
 url: group.fqdn,
 };
 };
}

Finally, a CosmosApp is defined:

const aci = new CosmosApp("aci", {
 resourceGroup,
 locations,
 databaseName: "cartdb",
 containerName: "items",
 factory: buildShoppingCartApp,
 enableMultiMaster: true,
});

Shopping Cart workload expects both reads and writes from the end-users, so the team decides to enable multi-master support in their Cosmos DB instance.

[ Full Example ]

Cosmos App with Virtual Machine Scale Sets

The Pricing Engine team has to go through the same steps but employ IaaS-based infrastructure to run application code. The factory function creates a dozen resources related to virtual machines, load balancing, networking, and auto-scaling. You may define as many resources as needed in the code, as long as it returns a pointer to the proper resource to link the endpoint.

function buildVMScaleSetApp({ cosmosAccount, database }: GlobalContext) {

 // Build a VM image here...

 // Define a MongoDB compatible collection
 const collection = new azure.cosmosdb.MongoCollection(`mongo-${name}`, {
 resourceGroupName: resourceGroup.name,
 accountName: cosmosAccount.name,
 databaseName: database.name,
 });

 return ({ location }: RegionalContext) => {

 const publicIp = new azure.network.PublicIp(/* ... */);
 const loadBalancer = new azure.lb.LoadBalancer(/* ... */);
 const bpepool = new azure.lb.BackendAddressPool(/* ... */);
 const probe = new azure.lb.Probe(/* ... */);
 const rule = new azure.lb.Rule(/* ... */);
 const vnet = new azure.network.VirtualNetwork(/* ... */);
 const subnet = new azure.network.Subnet(/* ... */);
 const scaleSet = new azure.compute.ScaleSet(/* ... */);
 const autoscale = new azure.monitoring.AutoscaleSetting(/* ... */);

 return {
 id: publicIp.id,
 };
 };
}

The code also uses a collection with the MongoDB protocol compatibility because that’s what the application expects.

[ Full Example ]

Conclusion

Azure Cloud Platform offers an amazing array of capabilities for application developers. Azure Cosmos DB takes care of distributing the data globally, reliably, consistently, and with low-latency access anywhere around the world. Nonetheless, developers still need to take care of adequately provisioning the application layer for efficiently serving users around the globe.

Cosmos App component is an excellent example of the power of using a general-purpose programming language to define cloud infrastructure. Such a component can let you codify the best practices and let multiple teams or companies share the implementation. The component and applications can evolve independently, with tools like versioning, package managers, compilers, and automated tests helping to maintain high-quality standards.

Ten Pearls With Azure Functions in Pulumi

Mikhail Shilkov — Wed, 21 Aug 2019 00:00:00 +0000

In this post, we’ll take a look at 10 “pearls”—bite-sized code snippets—that demonstrate using Pulumi to build serverless applications with Azure Functions and infrastructure as code. These pearls are organized into four categories, each demonstrating a unique scenario:

Function App Deployment: Deploy an existing Azure Functions application using infrastructure as code.
HTTP Functions as Callbacks: Mix JavaScript or TypeScript functions with your infrastructure definition to produce strongly-typed, self-contained, serverless HTTP endpoints.
Cloud Event Handling: Leverage a variety of event sources available to Azure Functions with lightweight event handlers.
Data Flows with Function Bindings: Take advantage of function bindings—declarative connectors to Azure services.

Our Azure Functions pearls are:

Function App Deployment

Deploy a Function App written in .NET or any other supported runtime
Configure Functions to run on an Elastic Premium Plan

HTTP Functions as Callbacks

Define Node.js Functions as inline callbacks
Implement REST APIs as multiple Functions
“Warm” the Functions to avoid Cold Starts

Cloud Event Handling

Process events from Azure Event Hub
Subscribe to Blob creation with Azure Event Grid
Run a Function every time an Azure resource is modified

Data Flows with Function Bindings

Push a message to a Storage Queue with an output binding
Pull a Storage Table row with an input binding

Function App Deployment

Azure Functions can be written in many languages, and Pulumi supports whatever choice you make. You can take any existing serverless application and deploy it using infrastructure-as-code.

1. Deploy a .NET Function App

[ Runnable Example ]

Many Function Apps are .NET applications created with native tooling like Visual Studio or the Functions CLI. Pulumi can simply deploy such an application in only a few lines of JavaScript:

const dotnetApp = new azure.appservice.ArchiveFunctionApp("http-dotnet", {
 resourceGroupName: resourceGroup.name,
 archive: new pulumi.asset.FileArchive("./app/bin/Debug/netcoreapp2.1/publish"),
 appSettings: { runtime: ".NET" },
});

There are only four things required:

the Function App name (“http-dotnet”)
the resource group it belongs to
the path to the compiled .NET assemblies, and
the desired runtime

Pulumi takes care of the rest for you. It handles the following tasks:

Creating a Storage Account and a Blob Container
Zipping up the binaries and uploading them to the blob container
Calculating a SAS token
Preparing a Consumption Plan and a Function App using this Consumption Plan
Configuring the required application settings, including a reference to the zip archive with the SAS token

While a few values are required, you are not restricted to the default behavior and can change any setting.

2. Run Functions using an Elastic Premium Plan

While the Consumption Plan is the ultimate serverless option, there are other ways to host Azure Functions. Azure also offers the Premium Plan: a combination of the power and guarantees of a fixed App Service Plan with the elasticity of Consumption.

If you want to take advantage of a Premium Plan, go ahead and define it as a Pulumi resource, then link to it in the Function App definition:

const premiumPlan = new azure.appservice.Plan("my-premium", {
 resourceGroupName: resourceGroup.name,
 sku: {
 tier: "Premium",
 size: "EP1",
 },
 maximumElasticWorkerCount: 20,
});

const javaApp = new azure.appservice.ArchiveFunctionApp("http-java", {
 resourceGroupName: resourceGroup.name,
 plan: premiumPlan,
 archive: new pulumi.asset.FileArchive("./java/target/functions/fabrikam"),
 appSettings: { runtime: "java" },
});

In this example, I deployed a Java application. The Premium Plan has a couple of configuration knobs: the instance size and the maximum scale-out limit.

HTTP Functions as Callbacks

Node.js is another runtime supported by Azure Functions. Like before, you can use the ArchiveFunctionApp class to deploy the application from an external folder. However, Pulumi’s Node.js SDK provides a way to mix the code of your functions directly into your infrastructure definition.

3. Define Node.js Functions as Inline Callbacks

[ Runnable Example ]

A TypeScript or a JavaScript function becomes an Azure Function deployed to the cloud:

const greeting = new azure.appservice.HttpEventSubscription('greeting', {
 resourceGroupName: resourceGroup.name,
 callback: async (context, req) => {
 return {
 status: 200,
 body: `Hello ${req.query['name'] || 'World'}!`,
 };
 }
});

export const url = greeting.url;

You are free to use any NPM module inside the callback, and the dependencies will be automatically packaged into the deployment artifact. Alternatively, you can extract the callback function into a separate file or package and import it from your infrastructure code.

While mixing infrastructure and application code in the same file may seem counterintuitive, it provides many benefits:

Combined code binaries (data plane) and infrastructure (control plane) as a single unit of deployment
Eliminate the need for boilerplate configuration like host.json and function.json files
Robust typing out-of-the-box: For instance, you can flawlessly “dot into” the content and req object above.

You can read more about the motivation in Serverless as Simple Callbacks with Pulumi and Azure Functions.

The previous example deployed a Function App with a single Function. However, Azure supports applications with multiple Functions bundled together.

4. REST APIs as Multiple Functions

It’s common to use Azure Functions for implementing RESTful APIs. As an API may consist of multiple endpoints, we may need to combine several HTTP Functions into a single deployment unit.

To achieve that, we define an HttpFunction object per Azure Function, each with its callback and settings. Then, we pass an array of these objects into a MultiCallbackFunctionApp constructor. Each Function definition may have a specific route and HTTP methods to handle:

const get = new azure.appservice.HttpFunction("Read", {
 route: "items",
 methods: ["GET"],
 callback: async (context, request) => {
 const items = await repository.list();
 return { status: 200, body: items };
 },
});

const post = new azure.appservice.HttpFunction("Add", {
 route: "items",
 methods: ["POST"],
 callback: async (context, request) => {
 const id = await repository.add(request.body);
 return { status: 201, body: { id } };
 },
});

const app = new azure.appservice.MultiCallbackFunctionApp("multi-app", {
 resourceGroupName: resourceGroup.name,
 functions: [get, post],
});

You can combine as many Functions as you want, including functions of different types, as shown in the next example.

5. Function “Warming” with a Timer Function

[ Runnable Example ]

Scheduled jobs are another frequent use case for serverless functions. It’s possible to define a cron expression and get the code executed at designated intervals.

The Consumption Plan disposes a worker if no Function runs in about 20 minutes. After disposal, the next execution will cause a cold start, and the response latency, will increase.

In order to avoid this disposal, we can combine a target HTTP Function with a Timer Function. The body of the Timer Function is empty, since its sole purpose is to trigger the Function App and keep the worker “warm”:

const warmer = new azure.appservice.TimerFunction("warmer", {
 schedule: "0 */5 * * * *",
 callback: async () => {},
});

const http = new azure.appservice.HttpFunction("hello", {
 callback: async (context, req) => {
 return {
 status: 200,
 body: "Hello World!",
 };
 }
});

const app = new azure.appservice.MultiCallbackFunctionApp("always-warm-app", {
 resourceGroupName: resourceGroup.name,
 functions: [http, warmer],
});

It’s easy to imagine a custom component WarmedFunctionApp which appends a standard Timer Function to an array of Functions passed to its constructor.

Cloud Event Handling

While HTTP is a widespread use case, Azure Functions support many other trigger types too. The previous post featured Storage Queues and ServiceBus Topics. Pulumi supports Timers, Events Hubs, Event Grid, Storage Blobs, Service Bus Queues, and Cosmos DB Change Feed events, too! Let’s see how that looks using Azure Event Hubs.

6. Process Events from Azure Event Hubs

[ Runnable Example ]

Azure Event Hubs is a fully-managed log-based messaging service comparable to Apache Kafka. In contrast to a self-hosted Kafka cluster, it only takes a few lines of JavaScript to create an Event Hub and start processing events:

const eventHub = new eventhub.EventHub("my-hub", {
 resourceGroupName: resourceGroup.name,
 namespaceName: namespace.name,
 partitionCount: 2,
 messageRetention: 7,
});

eventHub.onEvent("MyHubEvent", async (context, msg) => {
 console.log("Event Hub message: " + JSON.stringify(msg));
});

Every time a new event comes in, be it once per hour or a thousand times a second, the Function is executed. Azure manages the scale-out for you.

[ Runnable Example ]

Azure Event Grid is another trigger type for Azure Functions. It is a dispatcher service for distributing events from many other Azure services as well as external data sources.

A classic example is subscribing to events from Azure Blob Storage. The Event Grid subscription connects to a given Storage Account and provides several handy options to filter the event stream. The following example subscribes to all JPG files created in any container of the account:

const storageAccount = new azure.storage.Account("eventgridsa", {
 resourceGroupName: resourceGroup.name,
 accountReplicationType: "LRS",
 accountTier: "Standard",
 accountKind: "StorageV2",
});

azure.eventgrid.events.onGridBlobCreated("OnNewBlob", {
 storageAccount,
 subjectFilter: {
 caseSensitive: false,
 subjectEndsWith: ".jpg",
 },
 callback: async (context, event) => {
 context.log(`Subject: ${event.subject}`);
 context.log(`File size: ${event.data.contentLength}`);
 },
});

The event object is strongly typed: The snippet above logs the file size, but there are many other properties at your disposal. Code completion makes the discovery process painless.

It’s worth mentioning that Pulumi does much of the work behind the scenes here, allowing you to focus on the important parts of the task at hand. In particular, Pulumi retrieves the appropriate secret key from Azure Functions ARM API and creates an Event Grid subscription which points to a specific webhook containing that key.

8. Respond to Resource-level Events

[ Runnable Example ]

Here is a good illustration of the power of Event Grid. A callback function gets triggered for each change to any resource belonging to the target Resource Group:

const resourceGroup = new azure.core.ResourceGroup("eventgrid-rg");

eventgrid.events.onResourceGroupEvent("OnResourceChange", {
 resourceGroupName: resourceGroup.name,
 callback: async (context, event) => {
 context.log(`Subject: ${event.subject}`);
 context.log(`Event Type: ${event.eventType}`);
 context.log(`Data: ${JSON.stringify(event.data)}`);
 },
});

This simple piece of code is an easy launching point for many automation, auditing, and governance scenarios.

Data Flows with Function Bindings

Azure Functions come with a powerful system of bindings. So far, we only saw examples of using event sources as trigger bindings. However, Azure also supports a powerful set of so called “input” and “output” bindings.

9. Output Bindings

[ Runnable Example ]

Output bindings enable developers to easily forward the data from an Azure Function to an arbitrary destination in a declarative manner. For instance, if a queue handler needs to send a message to another queue, we don’t have to use cloud SDKs. Instead, we can return the message-to-be-sent from the callback and wire it to the output queue. Here is a quick example:

const incoming = new azure.storage.Queue("queue-in", {
 storageAccountName: storageAccount.name,
});

const outgoing = new azure.storage.Queue("queue-out", {
 storageAccountName: storageAccount.name,
});

incoming.onEvent("NewMessage", {
 outputs: [outgoing.output("queueOut")],
 callback: async (context, person) => {
 return {
 queueOut: `${person.name} logged into the system`,
 };
 },
});

Two elements play together here:

The outputs property defines an output binding with the name queueOut and the destination to outgoing
The queueOut property of the resulting object contains the output message

Note that the binding name must match the output property.

10. Input Bindings

[ Runnable Example ]

Input bindings pull extra bits of information and pass them as input parameters to the callback. The exact usage depends on the trigger and binding types and might be tricky to get right with JSON configuration files. Here is one example of wiring done in a Pulumi program:

const values = new azure.storage.Table("values", {
 storageAccountName: storageAccount.name,
});

const getFunc = new azure.appservice.HttpEventSubscription('get-value', {
 resourceGroupName: resourceGroup.name,
 route: "{key}",
 inputs: [
 values.input("entry", { partitionKey: "lookup", rowKey: "{key}" }),
 ],
 callback: async (context, request, entry) => {
 return {
 status: 200,
 body: entry.value,
 };
 },
});

There are three crucial bits here:

The route property of this HTTP Function contains a template parameter key. The runtime extracts the actual key value from the HTTP request.
The inputs option contains a reference to a Storage Table with a hardcoded partitionKey and a rowKey bound to the key template parameter. At execution time, a row is retrieved based on the combination of the keys. The entry, if found, is passed to the callback.
The callback has three input parameters, while all previous examples had two. The third parameter contains the retrieved row.

It’s possible to have multiple input and output bindings, and any combination of those.

Wrapping Up

In this post, we’ve seen some of the exciting things you can do with Azure Functions in Pulumi. Developers use serverless functions as a glue between managed cloud services. Pulumi offers a compelling way to define the links between these pieces of cloud infrastructure in a simple and expressive way.

For a streamlined Pulumi walkthrough, including language runtime installation and cloud configuration, see the Azure Quickstart, check more examples at Pulumi Azure GitHub, and join the Pulumi Community Slack.

Multicloud Kubernetes: Running Apps Across EKS, AKS, and GKE

Mike Metral — Wed, 14 Aug 2019 00:00:00 +0000

Kubernetes clusters from the managed platforms of AWS Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and GCP Google Kubernetes Engine (GKE) all vary in configuration, management, and resource properties. This variance creates unnecessary complexity in cluster provisioning and application deployments, as well as for CI/CD and testing.

Additionally, if you wanted to deploy the same app across multiple clusters for specific use cases or test scenarios across providers, subtleties such as LoadBalancer outputs and cluster connection settings can be a nuisance to manage.

In this post, we’ll see how to use Pulumi to deploy the kuard app across EKS, AKS, GKE and a local Kubernetes cluster, such as Docker Desktop or a self-managed cluster. We’ll spin up the clusters in each provider, launch the app, and manage both cluster and app using the TypeScript programming language.

View the full example and code.

![](multicloud.png)

Cluster Provisioning

Provisioning Kubernetes clusters and their IaaS resources is made simple through Pulumi’s various SDKs for the cloud providers:

Crosswalk for AWS further allows us to leverage the Pulumi libraries of common infrastructure for AWS to simplify cloud resource instantiation and management while gaining best-practices as defaults. Check out the pulumi/awsx SDK to get started.

For local clusters such as those that are self-managed, or provisioned by a tool like Docker Desktop, Pulumi can still deploy workloads to these these systems given that the pulumi/kubernetes workload SDK only requires a valid kubeconfig file. For more information on Pulumi’s Kubernetes support, check out the Kubernetes reference page.

We will use the cloud SDKs to provision the managed Kubernetes clusters. Given that we’re working with real code, we are afforded developer benefits such as: code linting, type checking, IDE hints and completion, abstractions and inheritance.

Leveraging these development features creates the opportunity to encapsulate the finer-grained details and settings, and expose the capability to create clusters as simple as the following code:

Workload Deployment

Once the clusters are provisioned, we can leverage the pulumi/kubernetes SDK to manage the Kubernetes workloads that will be deployed into the clusters.

The pulumi/kubernetes SDK uses the official Kubernetes client-go library to interact with Kubernetes. Therefore, Pulumi can work pretty much anywhere kubectl works, even if Pulumi was not used to create the cluster.

Summary

As shown in the code samples, it becomes relatively easy to provision and manage Kubernetes clusters across multiple clouds, as well as deploy workloads to the cluster regardless if they are managed by a cloud provider, or self-managed.

The various SDKS allow you to leverage industry standard best-practices and defaults, in addition to allowing you to further configure and customize how your clusters and apps are managed.

Testing apps across various providers in this form allows you to abstract away the details of provider specific implementations, and focus on how your app operates in the various contexts.

Learn More

If you’d like to learn about Pulumi and how to manage your infrastructure and Kubernetes multi-cloud capabilities through code, get started today. Pulumi is open source and free to use.

For further examples on how to use Pulumi to create Kubernetes clusters, or deploy workloads to a cluster, check out the rest of the Kubernetes tutorials.

As always, you can check out our code on GitHub, follow us on Twitter, subscribe to our YouTube channel, or join our Community Slack channel if you have any questions, need support, or just want to say hello.

If you’d like to chat with our team, or get hands-on assistance with migrating your existing configuration code to Pulumi, please don’t hesitate to drop us a line.

We also encourage you to watch Pulumi team member Levi Blackstone demo this post in an episode of the Kubernetes Community Meeting.

7 Ways to Deal with Application Secrets in Azure

Mikhail Shilkov — Fri, 26 Jul 2019 00:00:00 +0000

Every non-trivial application relies on configuration values that may depend on the current execution environment. Some of these values contain sensitive information that shouldn’t be shared publicly. In general, the fewer parties that have access to those secret values, the safer the application will be—in fact, in an ideal world, no one would be granted direct access to those secrets.

Examples of secret configuration values include:

A connection string to a message bus or a database
A SAS Token to an Azure Storage account
An access key for a third-party service

There’s no one universal way to manage secrets, as a lot depends on the context in which they are used. In this article, I go through seven ways to use secret values in a .NET Core application running in Azure. I start with naively hard-coded strings and build up from there to more secure options.

While the concepts are universally applicable, my code samples focus on a .NET application running in Azure App Service and configured with Pulumi. Consider them best practices for managing client secrets in Azure.

1. Hard-Coded Application Secrets

Whenever you want to try a new API requiring a secret access token, it’s natural to copy-paste that secret into your code and run it—simply to make sure that the setup works.

For example, you are testing integration with a payment service:

var apiKey = "payment-service-key";
var paymentService = new PaymentService(apiKey);

or you want to start sending messages to an Azure Storage Queue:

var connectionString = "DefaultEndpointsProtocol=https;AccountName=account-name;AccountKey=account-key";
var storageAccount = CloudStorageAccount.Parse(connectionString);
var queueClient = storageAccount.CreateCloudQueueClient();

Both snippets are fine for a Hello-World application with a lifespan of two hours. However, I would strongly discourage doing so in any code that can potentially be checked into a source control system, even for a 10-minute experiment. Don’t copy-paste secrets into files which are part of a git repository. One accidental git commit & git push—and the secrets are compromised.

Avoid the “Secrets as Code” practice: there are bots scanning your GitHub repository for those.

2. Configuration Files

Traditionally, putting secrets in a configuration file is considered more secure. For classic .NET applications, this would be an app.config or a web.config file. The idea is that the values on a developer machine are different from the values in the production environment. Non-sensitive development settings are kept on disk and maybe in source control, while the real secrets are only injected by a deployment script or a CI/CD system, so they are not exposed publicly.

In the .NET Core world, a configuration is usually stored in an appsettings.json file:

{
 "MyConfig": {
 "PaymentApiKey": "payment-service-key",
 "StorageConnectionString": "DefaultEndpointsProtocol=https;AccountName=account-name;AccountKey=account-key"
 }
}

which is then mapped to a plain C# object in code:

public class MyConfig
{
 public string PaymentApiKey { get; set; }
 public string StorageConnectionString { get; set; }
}

With some configuration not shown here, the properties are filled at startup time and can be used in the code as a plain object:

var apiKey = config.PaymentApiKey;
var paymentService = new PaymentService(apiKey);
// ...

var connectionString = config.StorageConnectionString;
var storageAccount = CloudStorageAccount.Parse(connectionString);
var queueClient = storageAccount.CreateCloudQueueClient();

In my experience, such setup still poses substantial risks. appsettings.production.json may still be accidentally checked into the source control. Developers tend to use real cloud resources for their local and test environments, which do contain sensitive information that can be exploited when leaked.

On top of that, it doesn’t feel right to mix configuration—how many threads to run, or how big the message batches should be—with secret connection strings and API keys in the same file. These are separate kinds of configuration, and they warrant different workflows.

3. Environment Variables and Application Settings

One alternative approach is to read the secret values from environment variables. .NET Core configuration system can parse environment variables instead of, or in addition to the settings files. Likewise, one could read such values with a one-liner in C#:

var apiKey = Environment.GetEnvironmentVariable("PAYMENT_API_KEY");
// ...

var connectionString = Environment.GetEnvironmentVariable("STORAGE_CONNECTION_STRING");
// ...

Your CI/CD system should inject those values as part of the deployment pipeline.

The App Service gives you the ability to set environment variables via Application Settings. Here is a snippet of a Pulumi program that passes both secret values to appSettings:

const cfg = new pulumi.Config();
const paymentApiKey = cfg.requireSecret("paymentApiKey");

const storageAccount = new azure.storage.Account("storage", {
 resourceGroupName: resourceGroup.name,
 accountReplicationType: "LRS",
 accountTier: "Standard",
});

const app = new azure.appservice.AppService("app", {
 resourceGroupName: resourceGroup.name,
 appServicePlanId: appServicePlan.id,
 appSettings: {
 "PAYMENT_API_KEY": paymentApiKey,
 "STORAGE_CONNECTION_STRING": storageAccount.primaryConnectionString,
 },
});

The Storage connection string is produced by the Pulumi program directly, so it doesn’t have to be placed anywhere outside the program itself.

The payment service key is provided by a third party, so its encrypted value is stored in Pulumi configuration. Read Managing Secrets with Pulumi to learn about security options available for secrets in Pulumi config.

4. Azure Key Vault

In the previous example, both secrets end up in Application Settings. Every person with sufficient permissions may go to the App Service and see them in clear text. While this can be restricted, it’s a good idea to grant full read access to the application developers and operators of the App Service to give them the full picture when troubleshooting issues.

In some cases, compliance to a certain standard may require the use of a certified key management service offering enhanced security for sensitive secrets.

Azure has a dedicated service for storing secrets, Azure Key Vault. You can create and populate a Key Vault with all the secrets from the same Pulumi program:

const vault = new azure.keyvault.KeyVault("vault", {
 resourceGroupName: resourceGroup.name,
 sku: {
 name: "standard",
 },
 tenantId: tenantId,
 accessPolicies: [{
 tenantId,
 // The current principal has to be granted permissions to Key Vault so that it can actually add and then remove
 // secrets to/from the Key Vault. Otherwise, 'pulumi up' and 'pulumi destroy' operations will fail.
 objectId: currentPrincipal,
 secretPermissions: ["delete", "get", "list", "set"],
 }],
});

const secret = new azure.keyvault.Secret("paymentApiKey", {
 keyVaultId: vault.id,
 value: paymentApiKey,
});

Additionally, one or many Service Principals (SP) should be configured to access the Key Vault. One SP which has been granted secret management access deploys the infrastructure by running the Pulumi program. That’s why the snippet above assigns an access policy to currentPrincipal.

Another SP is used by the application itself to read the secret values. The Client ID and Client Secret parameters are placed in the application configuration. Finally, .NET Core configuration gets hooked to the Key Vault at startup:

builder.AddAzureKeyVault(
 $"https://{config["azureKeyVault:vault"]}.vault.azure.net/",
 config["azureKeyVault:clientId"],
 config["azureKeyVault:clientSecret"]
);

This solution is not entirely satisfying though, since we’ve traded storing the secrets for storing SP credentials. Is that a big enough win? Luckily, it’s easy to get rid of those credentials with Managed identities.

5. Accessing Key Vault with Managed Identities

With Managed identities, Azure takes care of creating a Service Principal, passing the credentials, rotating secrets, and so on. Enabling a managed identity on App Service is just an extra option:

const app = new azure.appservice.AppService("app", {
 resourceGroupName: resourceGroup.name,
 appServicePlanId: appServicePlan.id,
 // A system-assigned managed identity
 identity: {
 type: "SystemAssigned",
 },
});

On top of that, the managed principal must be granted access to the Key Vault:

const principalId = app.identity.apply(id => id.principalId);

// Grant App Service access to KV secrets
new azure.keyvault.AccessPolicy("app-policy", {
 keyVaultId: vault.id,
 tenantId: tenantId,
 objectId: principalId,
 secretPermissions: ["get"],
});

Now, the configuration block in the .NET Core app doesn’t need to retrieve any secrets. AzureServiceTokenProvider helps with the authentication process:

var azureServiceTokenProvider = new AzureServiceTokenProvider();
var keyVaultClient = new KeyVaultClient(
 new KeyVaultClient.AuthenticationCallback(
 azureServiceTokenProvider.KeyVaultTokenCallback));
builder.AddAzureKeyVault(
 keyVaultEndpoint, keyVaultClient, new DefaultKeyVaultSecretManager());

That’s quite a bit of a boilerplate, but there is a way to get rid of it.

6. Accessing Key Vault from Application Settings

App Service has a neat feature of integrating its Application Settings with Key Vault. It allows us to combine #3 and #5’s approaches and get the best of both:

// Produce a URI of the KV secret defined above
const secretUri = pulumi.interpolate`${secret.vaultUri}secrets/${secret.name}/${secret.version}`;

const app = new azure.appservice.AppService("app", {
 resourceGroupName: resourceGroup.name,
 appServicePlanId: appServicePlan.id,
 // A system-assigned managed identity
 identity: {
 type: "SystemAssigned",
 },
 appSettings: {
 // The setting points directly to the KV setting
 "PAYMENT_API_KEY": pulumi.interpolate`@Microsoft.KeyVault(SecretUri=${secretUri})`,
 }
});

With that, the API key is loaded into the App Service environment variable without its value being publicly exposed anywhere!

7. Role-Based Access Control

What is the most secure way to deal with secrets? Have no secrets. The Storage Account connection string is a great example when it’s possible to avoid storing and reading the sensitive value altogether.

Role-Based Access Control (RBAC) of Azure Active Directory (AAD) is a great tool to manage permissions in a declarative way. Let’s assume our application only needs to send messages to one Storage Queue. Instead of storing a full connection string with an access token, the connection string should point to the account, and the identity behind the App Service should be granted write permissions to the required Storage Queue:

const permission = new azure.role.Assignment("send", {
 principalId,
 scope: pulumi.interpolate`${storageAccount.id}/queueServices/default/queues/${queue.name}`,
 roleDefinitionName: "Storage Queue Data Message Sender",
});

We can put the queue URL into Application Settings because there’s nothing secret in it:

const queueUri = pulumi.interpolate`${storageAccount.primaryQueueEndpoint}${queue.name}`;

const app = new azure.appservice.AppService("app", {
 resourceGroupName: resourceGroup.name,
 appServicePlanId: appServicePlan.id,
 identity: {
 type: "SystemAssigned"
 },
 appSettings: {
 "STORAGE_QUEUE_URL": queueUri,
 },

It takes a bit of C# boilerplate to send a message with role-based authorization:

var provider = new AzureServiceTokenProvider();
string accessToken = await provider.GetAccessTokenAsync("https://storage.azure.com/");
var tokenCredential = new TokenCredential(accessToken);
var storageCredentials = new StorageCredentials(tokenCredential);
var url = Environment.GetEnvironmentVariable("StorageBlobUrl");
var queue = new CloudQueue(new Uri(url), storageCredentials);
queue.AddMessage(new CloudQueueMessage("Hello"));

Let’s hope another quality-of-life improvement is on the way.

Role of Infrastructure as Code

While security practices may vary depending on application requirements, Pulumi plays an essential role in the appropriate setup of service configuration and environment:

It links an output of one resource to another one’s input, avoiding the need to store the values.
It provides a built-in mechanism to manage external secrets.
It is a great way to take advantage of Azure features like Managed identities and RBAC in a cohesive way.

Infrastructure as Code helps make your applications secure and reliable. Refer to the full example of using Key Vault, Managed identities, RBAC with App Service and Pulumi.

Globally-distributed Serverless App in 100 Lines of Code

Mikhail Shilkov — Tue, 02 Jul 2019 00:00:00 +0000

Pulumi is excellent at connecting multiple cloud components into a cohesive application. In my previous post, I introduced the way to mix JavaScript or TypeScript serverless functions directly into the cloud infrastructure programs.

Today, I will build a serverless application with both the data store and the HTTP endpoint located close to end users to ensure prompt response time. The entire application runs on top of managed Azure services and is defined as a single Pulumi program in TypeScript.

Baseline

I’m going to build a URL shortener: a simple HTTP endpoint which accepts a shortcode in the URL and then redirects a user to the full URL associated with the given short code.

I start simple and make a non-distributed version of the application first. It consists of two main components: a Cosmos DB container to store URL mappings and two Azure Functions to handle HTTP requests:

Let’s define this infrastructure in a Pulumi program.

Cosmos DB Collection

Arguably, Cosmos DB is overkill in such a simple scenario: we just need a key-value store, so Table Storage would suffice. However, Cosmos DB comes handy at the multi-region setup later on.

Next to a standard resource group definition, I create a Cosmos DB account with location set to a single region and Session consistency level:

import * as pulumi from "@pulumi/pulumi";
import * as azure from "@pulumi/azure";
import { CosmosClient } from "@azure/cosmos";

const location = "westus"; // To be changed to multiple configurable locations

let resourceGroup = new azure.core.ResourceGroup("UrlShorterner", {
 location,
});

let cosmosdb = new azure.cosmosdb.Account("UrlStore", {
 resourceGroupName: resourceGroup.name,
 location,
 geoLocations: [{ location, failoverPriority: 0 }],
 offerType: "Standard",
 consistencyPolicy: {
 consistencyLevel: "Session",
 maxIntervalInSeconds: 5,
 maxStalenessPrefix: 100,
 },
});

Cosmos DB has a hierarchical structure of Accounts, Databases, and Containers. Let’s define a database and a SQL collection to store our URL mappings:

const database = new azure.cosmosdb.SqlDatabase("Database", {
 resourceGroupName: resourceGroup.name,
 accountName: account.name,
});

const collection = new azure.cosmosdb.SqlContainer("Urls", {
 resourceGroupName: resourceGroup.name,
 accountName: account.name,
 databaseName: database.name,
});

Function App

Serverless Azure Functions are going to handle the HTTP layer in my application. I use the technique of serverless functions as callbacks to define Azure Functions inline inside my Pulumi program:

const fn = new azure.appservice.HttpEventSubscription("GetUrl", {
 resourceGroup,
 location,
 route: "{key}",
 callback: async (_, request: azure.appservice.HttpRequest) => {
 const endpoint = cosmosdb.endpoint.get();
 const masterKey = cosmosdb.primaryMasterKey.get();

 const client = new CosmosClient(
 { endpoint, key, connectionPolicy: { preferredLocations: [location] } });
 const container = client.database(database.name.get()).container(collection.name.get());

 const key = request.params['key'];
 try {
 const response = await container.item(key.toString()).read();
 return {
 status: 301,
 headers: { "location": response.body.url },
 body: '',
 };
 } catch (e) {
 return { status: 404, body: 'Short URL not found' }


});

export const url = fn.url;

I supply the template {key} as route parameter so that the function accepts wildcard URLs and extract the wildcard value as a key parameter available inside the request object. Then, I use the received key to look up the full URL. The URL is returned to the client as a header of the 301 Redirect response. 404 Not Found is returned in case the requested document does not exist—the naughty Cosmos SDK throws an error in this scenario.

Note how the Cosmos DB parameters endpoint and primaryMasterKey are used directly inside the function. There is no need to manage the keys manually or explicitly put them into application settings: the generated keys are injected into the code at the time of deployment. In practice, a better idea is to store the key in a KeyVault and read it via application settings, but I’ll leave this for a separate article.

A function to add a URL to the database looks quite similar to the above:

const fn = new azure.appservice.HttpEventSubscription("AddUrl", {
 resourceGroup,
 methods: ["POST"],
 callback: async (_, request: azure.appservice.HttpRequest) => {
 const endpoint = cosmosdb.endpoint.get();
 const masterKey = cosmosdb.primaryMasterKey.get();

 const client = new CosmosClient(
 { endpoint, key, connectionPolicy: { preferredLocations: [primaryLocation] } });
 const container = client.database(database.name.get()).container(collection.name.get());

 await container.items.create(request.body);
 return { status: 200, body: 'Short URL saved' };

});
export const addEndpoint = fn.url;

The key differences are:

Using POST as the accepted HTTP method
Creating a new item in Cosmos DB
Using request.body as the payload to save

I might need to add some validation in a real application—skipped for now.

Trying It Out

Now, when a user navigates to an address like https://geturl-xyz.azurewebsites.net/api/URLKEY, they get redirected to the full URL associated with the key. The URL is not quite short yet, but we could make it so with a custom domain configuration.

Presumably, we expect our URL shortener to be popular around the world. Therefore, one key aspect is to make sure that the service responds fast and enables a smooth user experience. Let’s measure the response time of our first version from different spots around the world:

Location	Response time
San Francisco	133 ms
New York	272 ms
London	383 ms
Frankfurt	420 ms
Tel-Aviv	470 ms
Hong-Kong	437 ms
Brisbane	449 ms

The further we get from the West US region, the slower the responses become.

How can we do better?

Bring Compute and Data Closer to Users

It’s hard to beat the speed of light, so if we want to respond fast, we need to bring both code and data close to any target user.

Luckily, the most involved aspect of that—the data distribution—can be handled by Cosmos DB multi-region accounts. We need to take care of deploying the code in multiple locations and routing the traffic to the nearest one. Here is the plan:

I don’t care too much about the latency of Add URL function, so I left it out of the picture.

Configuring the locations

The above picture shows three Azure regions, but since I’m using a general-purpose programming language, I can handle any number of locations in the same way. Actually, I put the list of target regions in Pulumi config file and read it at execution time:

const config = new pulumi.Config();
const locations = config.require("locations").split(',');
const primaryLocation = locations[0];

The order of regions defines the priority.

Multi-region Cosmos DB Account

Since locations is a simple array, I can map this array to produce the array of geoLocations to be set for my Cosmos DB:

let cosmosdb = new azure.cosmosdb.Account("url-cosmos", {
 location: primaryLocation,
 geoLocations: locations.map((location, failoverPriority) => ({
 location,
 failoverPriority
 })),
 /* ... other properties stay the same ... */

Right here, the full power of a programming language at my fingertips!

Multi-region Serverless App

Azure Traffic Manager is a DNS-based traffic load balancer that enables you to distribute traffic optimally to services across global Azure regions while providing high availability and responsiveness.

Sounds like what I need for my global application! Let’s define a Traffic Manager profile:

const profile = new azure.trafficmanager.Profile("UrlShortEndpoint", {
 resourceGroupName: resourceGroup.name,
 trafficRoutingMethod: 'Performance',
 dnsConfigs: [{
 relativeName: "shorturls",
 ttl: 60,
 }],
 monitorConfigs: [{
 protocol: 'HTTP',
 port: 80,
 path: '/api/ping',
 }]
});

I set the routing method to Performance:

Select Performance when you have endpoints in different geographic locations and you want end users to use the “closest” endpoint in terms of the lowest network latency.

Now, I need to create a Function App in each of the target regions. That’s easy to achieve with a for..of loop:

for (const location of locations) {
 const fn = new azure.appservice.HttpEventSubscription(`GetUrl-${location}`, {
 resourceGroup,
 location,
 route: "{key}",
 callback: /* ... the function stays the same ... */
 });
}

Finally, I set up an Endpoint for each Function App to bind them to the Traffic Manager. I do so in the same loop as above:

for (const location of locations) {
 const fn = new azure.appservice.HttpEventSubscription(`GetUrl-${location}`, {
 /* ... function definition as shown above ... */
 });

 const app = fn.functionApp;

 new azure.trafficmanager.Endpoint(`tme${location}`, {
 resourceGroupName: resourceGroup.name,
 profileName: profile.name,
 type: 'azureEndpoints',
 targetResourceId: app.id,
 target: app.defaultHostname,
 endpointLocation: app.location,
 });
}

I assign the properties of each Function App to the corresponding Endpoint with a simple object initializer expression.

Everything is in place. I can export the Traffic Manager endpoint:

export const endpoint = pulumi.interpolate `http://${profile.fqdn}/api/{key}`;

Time to re-run the latency tests.

Results

I deployed the distributed infrastructure to five Azure regions: West US, East US, West Europe, East Asia, and Australia East. The results are shown in the table below, next to the values from the initial run:

Location	Single region	Multiple regions
San Francisco	133 ms	140 ms
New York	272 ms	152 ms
London	383 ms	150 ms
Frankfurt	420 ms	130 ms
Tel-Aviv	470 ms	307 ms
Hong-Kong	437 ms	149 ms
Brisbane	449 ms	529 ms

We got a much smoother distribution of response time. There’s no region close enough to Tel-Aviv, so its latency is still high-ish. I checked Brisbane, and the traffic was somehow directed to the East US region, so the latency hasn’t improved at all. For today, I guess I’ll stick to the hypothesis “Australian internet is slow” and advise to always test your target scenarios without trusting the providers blindly.

More importantly, I walked you through a scenario of developing an end-to-end application with Pulumi. I highlighted the power of leveraging familiar techniques coming from the TypeScript realm. You can find the full code in Pulumi examples and more on Cosmos DB in the Azure Provider.

Cloud brings superpowers to developer’s hands. You just need to use those efficiently.

Hosting a Static Website on Azure with Pulumi

Mikhail Shilkov — Thu, 27 Jun 2019 00:00:00 +0000

Static websites are back in the mainstream these days. Website generators like Jekyll, Hugo, or Gatsby, make it fairly easy to combine templates and markdown pages to produce static HTML files. Static assets are the simplest thing to serve and cache, so the whole setup ends up being fast and cost-efficient.

Many platforms offer services to host such static websites. This post explains the steps to create the infrastructure to do so on Microsoft Azure.

Setting up the infrastructure to serve a static website doesn’t sound like it would be all that difficult, but when you consider HTTPS certificates, content distribution networks, and attaching it to a custom domain, integrating all the components can be quite daunting.

Fortunately, this is a task where Pulumi shines. Pulumi’s code-centric approach not only makes configuring cloud resources easier to do and maintain, but it also eliminates the pain of integrating multiple services.

Overview

Our goal is to create a static website with a custom domain – I’ll use an imaginary demo.pulumi.com for this article. In 2019, my website has to support HTTPS, so we need to create a custom TLS certificate too.

The final solution consists of several Azure services:

Static files will be stored in a Blob Container inside a Storage Account
The Storage Account will have Static Website feature enabled to have some basic URL rewrite rules
We’ll put an Azure CDN Endpoint in front of the container to support the custom domain over TLS
Azure CDN will self-manage the TLS certificate
Our custom DNS provider will have the rule to point to the CDN endpoint (that’s a manual step)

The diagram below outlines the interaction of these components:

Let’s break down how to configure each component using Pulumi.

Resource Group

Let’s start a new Pulumi program, import the Pulumi packages, and define a new resource group:

import * as pulumi from "@pulumi/pulumi";
import * as azure from "@pulumi/azure";

const resourceGroup = new azure.core.ResourceGroup("demo-rg", {
 location: azure.WestEurope,
});

Storage Account

The Storage Account will contain our static website’s assets:

const storageAccount = new azure.storage.Account("demopulumi", {
 resourceGroupName: resourceGroup.name,
 accountReplicationType: "LRS",
 accountTier: "Standard",
 accountKind: "StorageV2",
});

The only trick here is to make sure that the account kind is V2; otherwise, it won’t support the static website feature.

Static Website Hosting in Azure Storage

Any storage container could be exposed as a web endpoint. However, that’s not flexible enough. The URL would always include the container name and the exact file name, so the user would have to ask for https://demo.pulumi.com/containername/index.html instead of simply https://demo.pulumi.com/.

Enabling Static Website Hosting in Azure Storage improves this experience. A dedicated container $web gets automatically created, which also has special treatment for index and 404 documents.

The bad news is that Static Website Hosting is not a part of Azure Resource Manager API, and therefore, it’s not available out-of-the-box in ARM templates, Terraform, or Pulumi. We can enable this feature with Azure CLI, so the solution is to create a dynamic Pulumi resource which enables Pulumi experience while delegating the work to the CLI. You can find the full source code for the dynamic resource in this example, but the usage is quite trivial:

const staticWebsite = new StorageStaticWebsite("demopulumi-static",
 { accountName: storageAccount.name },
 { parent: storageAccount });

// Web endpoint to the website
export const staticEndpoint = staticWebsite.endpoint;

The last line exports the static website endpoint. It will look something like https://demopulumi01234abc.z6.web.core.windows.net/—no custom domain yet, but already functional—once we deploy some static files in there.

Static Files

Now, it’s time to upload the static files to the $web Blob Container.

For this demo, I’ve created a folder wwwroot with two files in it: index.html and 404.html. I can upload those files with the following Pulumi snippet:

["index.html", "404.html"].map(name =>
 new azure.storage.Blob(name, {
 name,
 resourceGroupName: resourceGroup.name,
 storageAccountName: storageAccount.name,
 storageContainerName: staticWebsite.webContainerName,
 type: "block",
 source: `./wwwroot/${name}`,
 contentType: "text/html",
 })
);

In practice, your static website might contain hundreds or thousands of files. At that point, you might want to split the file upload operation from Pulumi and do it as a separate step in your CI/CD pipeline.

Azure CDN

To make the static website files available over our custom domain and HTTPS, we need to create an Azure CDN Endpoint and to point it to the storage account:

const cdn = new azure.cdn.Profile("demo-cdn", {
 resourceGroupName: resourceGroup.name,
 sku: "Standard_Microsoft",
});

const endpoint = new azure.cdn.Endpoint("demo-cdn-ep", {
 name: "demopulumi",
 resourceGroupName: resourceGroup.name,
 profileName: cdn.name,
 isHttpAllowed: true,
 isHttpsAllowed: true,
 originHostHeader: staticWebsite.hostName,
 origins: [{
 name: "blobstorage",
 hostName: staticWebsite.hostName,
 }],
});

// CDN endpoint to the website. Allow it some time after the deployment to get ready.
export const cdnEndpoint = pulumi.interpolate`https://${endpoint.hostName}/`;

I specified an explicit name for the CDN Endpoint: demopulumi. This name has to be globally unique because it is a part of the endpoint URL https://demopulumi.azureedge.net. Please pick a custom name before running the program.

I pointed the CDN origin to the static website name with staticWebsite.hostName. As usual, it’s easy to link resources in Pulumi code!

You might need to wait a few minutes before your content is visible as the CDN configuration is not immediately executed. I’ve set isHttpAllowed to true because HTTP is available sooner than HTTPS; feel free to switch it off for your production configuration.

Configure a Domain DNS Rule

You’ve probably registered your domain with some third-party provider. Follow the instructions of your provider to configure a CNAME rule for the website’s DNS. For a custom domain demo.pulumi.com, the CNAME entry demo would be linked to the endpoint demopulumi.azureedge.net.

CNAME entries don’t support “naked” domains like pulumi.com. If you want to set up a top-level domain to be served from the static Azure website, you’d have to use an Alias DNS record, which isn’t supported by some DNS providers. Please check with your provider for available options.

The following step assumes that a CNAME record is configured; otherwise, it would fail with a validation error.

Custom Domain and TLS

The final step is to point our custom domain to the CDN endpoint and provision a TLS certificate to enable HTTPS support. Once again, these operations are not parts of the ARM API surface, so another dynamic resource was created to support them.

The usage is quite straightforward, just make sure to use your own domain in the following snippet:

const customDomain = new CDNCustomDomainResource("cdn-custom-domain", {
 resourceGroupName: resourceGroup.name,
 // Ensure that there is a CNAME record for demo pointing.pulumi.com to demopulumi.azureedge.net.
 // You would do that in your domain registrar's portal.
 customDomainHostName: "demo.pulumi.com",
 profileName: cdn.name,
 endpointName: endpoint.name,
 // This will enable HTTPS through Azure's one-click automated certificate deployment.
 // The certificate is fully managed by Azure from provisioning to automatic renewal
 // at no additional cost to you.
 httpsEnabled: true,
}, { parent: endpoint });

Bring It Live!

And we are done! Run pulumi up and make sure that all resources get created successfully.

Start testing with staticEndpoint—it’s the first one to become available. cdnEndpoint might return some 404’s at first, be patient. Then, try your custom domain with HTTP. Finally, the TLS certificate takes quite a while to be registered, so come back in an hour or so to test HTTPS.

While a “static website” may sound simple, we went through a rather complicated process to wire all the components together. Some Azure services and features are more straightforward to automate than others, but in the end, we combined all of them into one cohesive Pulumi program to host a static website, served over HTTPS and from a worldwide CDN. That’s the power of a general-purpose programming language applied to the task of sophisticated infrastructure automation. Once the reusable components are in place, reliable and reproducible deployments become a reality.

Create AKS Clusters with Monitoring and Logging

Nishi Davidson — Wed, 08 May 2019 00:00:00 +0000

Pulumi-Azure open source package can be used to create Azure Kubernetes Service (AKS) clusters with AD service principals tied to the cluster. Monitoring and logging can also be enabled by default in simple steps with Pulumi for core AKS components. This article will show you how to write this as a simple example using Pulumi SDKs.

Prerequisites

Install pulumi CLI and set up your Azure credentials
Initialize a new Pulumi project from available templates. We use ****azure-typescript**** template here to install all dependencies and save the configuration.

Step 1: Export required configurations for the AKS stack

import * as azure from "@pulumi/azure";
import * as azuread from "@pulumi/azuread";
import * as k8s from "@pulumi/kubernetes";
import * as pulumi from "@pulumi/pulumi";

// Step 1: Parse and export configuration variables for the AKS stack.
const config = new pulumi.Config();
const password = config.require("password");
const location = config.get("location") || "East US";
const nodeCount = config.getNumber("nodeCount") || 2;
const nodeSize = config.get("nodeSize") || "Standard_D2_v2";
const sshPublicKey = config.require("sshPublicKey");

const resourceGroup = new azure.core.ResourceGroup("aks", { location });
const loganalytics = new azure.operationalinsights.AnalyticsWorkspace("aksloganalytics", {
 resourceGroupName: resourceGroup.name,
 location: resourceGroup.location,
 sku: "PerGB2018",
 retentionInDays: 30,
});

Step 2: Create the AD Service principal for the AKS cluster

When you register an Azure AD application in the Azure portal, two objects are created in your Azure AD tenant: a) An application object, and b) A service principal object. To access resources that are secured by an Azure AD tenant, the entity that requires access must be represented by a security principal that defines the access policy and permissions for the user/application in the Azure AD tenant. This is true for both users (user principal) and applications (service principal). This enables core features such as authentication of the user/application during sign-in, and authorization during resource access.

In our example we create the Service principal which is a required in the successful creation of the AKS cluster. If you see that the Service Principal Id was not found: “Service principal clientID: xxxxx not found”, simply re-run pulumi updateto proceed.

// Step 2: Create the AD service principal for the k8s cluster.
const adApp = new azuread.Application("aks");
const adSp = new azuread.ServicePrincipal("aksSp", { applicationId: adApp.applicationId });
const adSpPassword = new azuread.ServicePrincipalPassword("aksSpPassword", {
 servicePrincipalId: adSp.id,
 value: password,
 endDate: "2099-01-01T00:00:00Z",
});

Step 3: Create the AKS cluster

Now let’s add the logic to create the AKS cluster with the Service principal.

// Step 3: This step creates an AKS cluster.
const k8sCluster = new azure.containerservice.KubernetesCluster("aksCluster", {
 resourceGroupName: resourceGroup.name,
 location: location,
 defaultNodePool: {
 name: "aksagentpool",
 nodeCount: nodeCount,
 vmSize: nodeSize,
 },
 dnsPrefix: `${pulumi.getStack()}-kube`,
 linuxProfile: {
 adminUsername: "aksuser",
 sshKey: { keyData: sshPublicKey},
 },
 servicePrincipal: {
 clientId: applicationId,
 clientSecret: adSpPassword.value,
 },
 addonProfile: {
 omsAgent: {
 enabled: true,
 logAnalyticsWorkspaceId: loganalytics.id,
 },
 },
});

// Expose a k8s provider instance using our custom cluster instance.
const k8sProvider = new k8s.Provider("aksK8s", {
 kubeconfig: k8sCluster.kubeConfigRaw,
});

// Export the kubeconfig
export const kubeconfig = k8sCluster.kubeConfigRaw;

Step 4: Enable default monitoring and logging for the AKS cluster

Log queries are used to retrieve any log data from Azure Monitor. Whether you’re analyzing data in the portal, or configuring an alert rule to be notified of a particular condition, you will use a query to specify the data you want.

We will now enable monitoring and logging by default for the cluster and run pulumi up

// Step 4: Enables the Monitoring Diagonostic control plane component logs and AllMetrics
const azMonitoringDiagnostic = new azure.monitoring.DiagnosticSetting("aks", {
 logAnalyticsWorkspaceId: loganalytics.id,
 targetResourceId: k8sCluster.id,
 logs: [{
 category: "kube-apiserver",
 enabled : true,

 retentionPolicy: {
 enabled: true,
 },
 }],
 metrics: [{
 category: "AllMetrics",

 retentionPolicy: {
 enabled: true,
 },
 }],
});

If you run pulumi up with the entire index.ts file as defined here you will see an AKS cluster get created with monitoring and logging enabled.

Step 5: Check if everything worked

a) Check with Pulumi CLI and kubectl

$ pulumi stack output kubeconfig > kubeconfig.yaml
$ kubectl config current-context
akscluster1321f898

b) Check Pulumi Service Console for the resource creation on the stack you just initialized: d-nishi/azure-mean/dev.

c) Check your Azure portal for the cluster-id and to find all the metrics (Insights) and logs (Logs) show up as follows:

Summary

We discussed how to set up AKS clusters with monitoring and logging in simple steps with Pulumi packages. You can find the complete pulumi code for our example here. For more examples visit our GitHub examples repo.

If you want to additionally look at how to integrate Azure DevOps with Pulumi, check out our other post CI/CD made easy with Pulumi and Azure Pipelines.

Serverless as Simple Callbacks with Azure Functions

Mikhail Shilkov — Tue, 07 May 2019 00:00:00 +0000

Today’s guest post is from Mikhail Shilkov, a Microsoft Azure MVP and early Pulumi user and contributor - enjoy!

Serverless compute services, like Azure Functions, offer an amazing power to application developers to leverage: highly available, automatically scaled, low-ceremony, pay-per-value functions created in several lines of code.

So, what’s the simplest way to take a Node.js function and deploy it to Azure cloud as an HTTP endpoint? How about this little tutorial:

1. Create a new Pulumi program:

$ pulumi new azure-typescript

2. Define an HTTP endpoint in `index.ts`:

import * as azure from '@pulumi/azure';

const resourceGroup = new azure.core.ResourceGroup('example', { location: 'West US' });

const greeting = new azure.appservice.HttpEventSubscription('greeting', {
 resourceGroup,
 callback: async (context, req) => {
 return {
 status: 200,
 body: `Hello ${req.query['name'] || 'World'}!`
 };
 }
});

export const url = greeting.url;

3. Deploy:

$ pulumi up
 
Updating:
   Type
 + pulumi:pulumi:Stack
 + ├─ azure:appservice:HttpEventSubscription
 + │ ├─ azure:storage:Account
 + │ ├─ azure:appservice:Plan
 + │ ├─ azure:storage:Container
 + │ ├─ azure:storage:ZipBlob
 + │ └─ azure:appservice:FunctionApp
 + └─ azure:core:ResourceGroup
 
Outputs:
   url: "https://greetingc21a23fe.azurewebsites.net/api/greeting"
Resources:
   + 8 created

4. Access your function via HTTP:

$ curl https://greetingc21a23fe.azurewebsites.net/api/greeting?name=Pulumi
Hello Pulumi!

With 12 lines of code and two CLI commands, I’ve created all Azure resources required to host a serverless function without an explicit configuration of Azure services. Okay, I had to define a location for my resource group, but that could also be accomplished via pulumi config.

Pulumi compiled my TypeScript function, serialized it to a JavaScript file, created the bindings in a function.json file, hosting configuration in a host.json file, uploaded all these assets to Blob Storage, and configured a Consumption Plan and a Function App to run my function. An automated and reproducible deployment in less than two minutes.

Beyond Hello-World

The power of Node.js comes from the richness of its library ecosystem. There’s an NPM package for everything, so you definitely want to use those.

Serverless-function-as-callback imports dependencies in a transparent way. Install the NPM packages of your choice and use them inside the callback:

import * as moment from 'moment';

const greeting = new azure.appservice.HttpEventSubscription('greeting', {
 resourceGroup,
  callback: async (context, req) => {
 return {
 status: 200,
 body: `Hello ${req.query['name'] || 'World'} at ${moment().format('LLLL')}!`
 };
 }
});

The packages get zipped up inside the deployment artifact automatically so that the Function App can find them at the startup. So there’s no need to manually figure out how to produce the archive, get it uploaded, and maintain it as your libraries get updated.

Stay tuned for another blog post with a full implementation of a serverless URL shortener application deployed into multiple Azure regions for fast response time and improved resiliency.

Not Only HTTP

Your application might not be a bunch of HTTP functions. You probably want to leverage queues for asynchronous message passing. How about defining a callback on the queue object itself:

const storageAccount = new azure.storage.Account("storage", {
   resourceGroupName: resourceGroup.name,
   location: resourceGroup.location,
   accountReplicationType: "LRS",
   accountTier: "Standard",
});

const queue = new azure.storage.Queue("myqueue", {
  resourceGroupName: resourceGroup.name,
  storageAccountName: storageAccount.name
});

queue.onEvent("newMessage", async (context, msg) => {
   // code to process 'msg' however you want here
   console.log("Message received: " + msg.toString());
});

Alternatively, define a ServiceBus topic and immediately subscribe to the messages:

import * as servicebus from "@pulumi/azure/eventhub";

const namespace = new servicebus.Namespace("test", {
   resourceGroupName: resourceGroup.name,
   sku: "standard",
});

const topic = new servicebus.Topic("mytopic", {
   resourceGroupName: resourceGroup.name,
   namespaceName: namespace.name,
});

export const subscription = topic.onEvent("mysubscription", async (context, msg) => {
   console.log("Received: " + msg.toString());
});

In addition, get notified when a new PNG image is uploaded to a Blob Container:

const storageContainer = new azure.storage.Container("images-container", {
  resourceGroupName: resourceGroup.name,
  storageAccountName: storageAccount.name,
  name: "images",
});

storageContainer.onBlobEvent("newImage", {
   callback: async (context, blob) => {
       console.log("File size: " + context.bindingData.properties.length);
   },
   filterSuffix: ".png",
});

In all these examples, you get a fully configured Function App on Consumption Plan ramped up and bound to the trigger of choice. Your callback runs in the cloud handling every event with no manual work of hooking these different components together.

Using a general-purpose language like TypeScript provides one consistent approach to defining and delivering serverless applications and infrastructure as one cohesive application.

We strive to make cloud development as simple as everyday JavaScript development that made the language so successful. A lot is happening behind the scenes, but the code still looks like “normal code”. Composition of cloud resources should be as straightforward as hooking up components in any traditional application.

Looking Ahead

Pulumi serverless programming model for Azure Functions is just ramping up. There is only a handful of trigger types supported right now, and some configuration parameters are not exposed yet.

So, today is the perfect time to chime in and join the discussion! Help us answer the questions:

Is this programming model beneficial to your scenarios?
Which trigger types do you want to be supported?
How should we package multiple functions into Function App(s)?
Do you need input and output bindings to be supported, and if yes, in which shape?

Feel free to create an issue on GitHub, tag us on Twitter, or join our community Slack channel.

Happy serverless programming!

Level up your Azure Platform as a Service Applications

Mikhail Shilkov — Mon, 06 May 2019 00:00:00 +0000

Today’s guest post is from Mikhail Shilkov, a Microsoft Azure MVP and early Pulumi user and contributor - enjoy!

Today I want to guide you through the process of developing Pulumi programs to leverage Azure Platform-as-a-Service (PaaS) services. My language of choice is TypeScript—a powerful and expressive typed language, which is very familiar to many Azure users.

Azure Platform as a Service

Azure consists of dozens of cloud services, from VMs to Kubernetes to Serverless. In my experience, a lot of customers choose Azure for its strong portfolio of PaaS-level services.

Azure App Service is a well-established managed compute offering to run web applications, RESTful APIs, or background workers. Azure SQL Database is a fully managed service to run relational databases with features like high availability and backups available out-of-the-box. Enriched by services like Azure DevOps for CI/CD and Application Insights for APM, PaaS is a powerful way to get the benefits of the cloud without the need to fully re-architect software solutions.

The power of relying on PaaS is evidenced by significant customer adoption. App Service is among the most popular compute services in Azure:

If you use automation (ARM, scripts, TF, …) to define and deploy Azure infrastructure, which services are your primary target? Vote & RT!

– Mikhail Shilkov (@MikhailShilkov) April 23, 2019

Nonetheless, PaaS services pose different challenges to application developers. In particular, the usage of multiple cloud services demands an investment in infrastructure automation. That’s where Pulumi comes to the rescue.

A Sample Application

For this walkthrough, I took an existing application from Azure Samples GitHub: .NET Core MVC sample for Azure App Service. Predictably enough, it’s a Todo List application, and this time it is a web app built with ASP.NET Core, Entity Framework Core and a SQL database. Build an ASP.NET Core and SQL Database app in Azure App Service describes how to deploy such application to Azure App Service by means of clicking buttons in the Azure portal.

“Friends don’t let friends right-click publish”

Instead, I suggest relying on infrastructure as code. I built a Pulumi program and integrated it into a fully automated build and deployment pipeline in Azure DevOps.

Here is a sketch of the solution:

Let’s get started building together!

Solution Structure

The following snippet shows the essential elements of the solution:

infra # Cloud infrastructure definition goes here
   index.ts # Pulumi program in TypeScript
src
   Controllers #
   Models # ASP.NET Core web app
   Views # /
   Data # EF Core Data Context
   wwwroot # Static assets (JavaScript/CSS/Images)
azure-pipelines.yml # Azure DevOps pipeline definition

As a first step, I cloned the Todo List app into the src folder. There’s nothing specific to Pulumi here: it’s just an ASP.NET Core app. It could be your application instead.

Note: You can find the full code of the application, infrastructure definition, and deployment pipeline in Pulumi Examples repository.

Bootstrapping a Pulumi Program

The Pulumi development experience is powered by the Pulumi CLI. After installing the CLI, I jump into an empty infra folder and run pulumi new azure-typescript accepting all the default answers. The CLI bootstraps a skeleton of a TypeScript NodeJS application. The code looks like this:

import * as pulumi from "@pulumi/pulumi";
import * as azure from "@pulumi/azure";

// Create an Azure Resource Group
const resourceGroup = new azure.core.ResourceGroup("resourceGroup", {
    location: "WestUS",
});

// Create an Azure resource (Storage Account)
const account = new azure.storage.Account("storage", {
    resourceGroupName: resourceGroup.name,
    location: resourceGroup.location,
    accountTier: "Standard",
    accountReplicationType: "LRS",
});

// Export the connection string for the storage account
export const connectionString = account.primaryConnectionString;

The infrastructure pieces are defined by instantiating objects of appropriate types: ResourceGroup and Account in this example.

Stacks

If an application is developed to run and evolve for months and years, it’s smart to invest in practices like Continuous Integration and Deployment (CI/CD) and Infrastructure as Code (IaC). It’s quite likely that such an application will run in multiple environments: production, staging, development, and so on.

Pulumi comes with a handy concept of stacks— isolated, independently configurable instances of a Pulumi program. A separate stack can be designated for each deployment environment.

We can take the notion of the stack into the program and apply the stack name to definitions of infrastructure resources:

// Use first 10 characters of the stackname as prefix for resource names
const prefix = pulumi.getStack().substring(0, 9);
 
const resourceGroup = new azure.core.ResourceGroup(`${prefix}-rg`, {
    location: "WestUS",
});
 
const resourceGroupArgs = {
    resourceGroupName: resourceGroup.name,
    location: resourceGroup.location,
};
 
// Storage Account name must be lowercase and cannot have any dash characters
const storageAccountName = `${prefix.toLowerCase().replace(/-/g, "")}sa`;
const storageAccount = new azure.storage.Account(storageAccountName, {
    ...resourceGroupArgs,
 
    accountKind: "StorageV2",
    accountTier: "Standard",
    accountReplicationType: "LRS",
});

Note how I use the power of the general purpose programming language to

Interact with the environment by reading the stack name
Encode custom rules for resource naming
Work around the shortcomings of the cloud, namely, the restricted set of characters to use in Storage Accounts
Extract the value resourceGroupArgs to reuse the same definition for upcoming resources.

As a result, the stacks production and dev will be deployed to separate resource groups with clean and consistent naming throughout the resources.

Deploying the Application to App Service

Now, it’s time to define the infrastructure to host my ASP.NET Core app. There are three pieces of the puzzle to fit together.

1. App Service Plan

An App Service Plan defines the pricing tier, instance size and other parameters related to performance, scalability, and cost of the hosted application. My definition is relatively straightforward:

const appServicePlan = new azure.appservice.Plan(`${prefix}-asp`, {
    ...resourceGroupArgs,
 
    kind: "App",
 
    sku: {
        tier: "Basic",
        size: "B1",
    },
});

In a more advanced scenario, I could provision different performance tiers based on the target environment identified by the stack name.

2. Deployment Artifact

App Service is a mature Azure service with a long history, so it has numerous options for deployment methods. Arguably, the newest Run from Package is the most friendly way to practice Infrastructure as Code automation.

Essentially, I prepare a zip file with the published .NET Core assemblies and upload it to Azure Blob Storage:

const storageContainer = new azure.storage.Container(`${prefix}-c`, {
    resourceGroupName: resourceGroup.name,
    storageAccountName: storageAccount.name,
    containerAccessType: "private",
});
 
const blob = new azure.storage.ZipBlob(`${prefix}-b`, {
    resourceGroupName: resourceGroup.name,
    storageAccountName: storageAccount.name,
    storageContainerName: storageContainer.name,
    type: "block",
 
    content: new pulumi.asset.FileArchive("../src/bin/Debug/netcoreapp2.1/publish.zip")
});

3. App Service

Now, I can define an App Service and instruct it to use this package to run the website. I do so by linking its application settings to the shared access signature of the blob:

const codeBlobUrl = signedBlobReadUrl(blob, storageAccount, storageContainer);
 
const app = new azure.appservice.AppService(`${prefix}-as`, {
    ...resourceGroupArgs,
    appServicePlanId: appServicePlan.id,
 
    appSettings: {
        "WEBSITE_RUN_FROM_PACKAGE": codeBlobUrl,
    },
});

At startup, App Service downloads the zip and mounts it as a local read-only disk to store the application binaries.

Adding a SQL Database

The application host is now defined, but I also need a relational database to store and query Todo Items. Staying true to the PaaS path, I’m using Azure SQL Database service.

Reading Configuration Parameters

Setting up a SQL Server requires a couple of parameter values that might change between execution environments, for instance, a username and a password for the connection string. Pulumi provides a way to configure the program’s parameters per stack.

The configuration itself will happen in my CI/CD pipeline. For now, I can query the values with pulumi.Config helper tool:

// Get the username and the password to use for SQL from config.
const config = new pulumi.Config();
const username = config.require("sqlUsername");
const pwd = config.require("sqlPassword");

Azure SQL Server and Database

I’m all set to code the SQL infrastructure. Two resources need to be defined:

const sqlServer = new azure.sql.SqlServer(`${prefix}-sql`, {
    ...resourceGroupArgs,
 
    administratorLogin: username,
    administratorLoginPassword: pwd,
    version: "12.0",
});
 
const database = new azure.sql.Database(`${prefix}-db`, {
    ...resourceGroupArgs,
    serverName: sqlServer.name,
    requestedServiceObjectiveName: "S0"
});

Note that requestedServiceObjectiveName defines the performance tier and the price of the Azure SQL Database.

Wiring App Service to the Database

By default, Azure SQL Database is configured to deny any incoming connections for security reasons. One approach is to allow access to all Azure services. However, a more secure method is to white-list the Outbound IPs of the App Service:

const firewallRules = app.outboundIpAddresses.apply(
    ips => ips.split(',').map(
        ip => new azure.sql.FirewallRule(`FR${ip}`, {
            endIpAddress: ip,
            resourceGroupName: resourceGroup.name,
            serverName: sqlServer.name,
            startIpAddress: ip,
        })
    ));

Note that the actual IPs of the service are unknown at the time of writing the program. Nonetheless, the combination of apply, split, and map functions enables me to wire the runtime value of IPs to the proper set of firewall rules.

Additional firewall rules may be implemented to allow administrative access from outside the App Service.

Finally, our ASP.NET Core application expects a connection string with MyDbConnection. To create one, I join the database server and the database name to produce the connection string and add it to the App Service configuration:

const app = new azure.appservice.AppService(`${prefix}-as`, {
    // ... other parameters as defined above
 
    connectionStrings: [{
        name: "MyDbConnection",
        value:
            pulumi.all([sqlServer.name, database.name]).apply(([server, db]) =>
                `Server=tcp:${server}.database.windows.net;initial catalog=${db};user ID=${username};password=${pwd};Min Pool Size=0;Max Pool Size=30;Persist Security Info=true;`),
        type: "SQLAzure"
    }]
});

Collecting Metrics with Application Insights

Application Insights is an Application Performance Management (APM) service to be used for collecting metrics from cloud applications.

After adding Application Insights NuGet packages into my ASP.NET solution, I can go ahead and define the App Insights resource and link it to the App Service with an instrumentation key:

const appInsights = new azure.appinsights.Insights(`${prefix}-ai`, {
    ...resourceGroupArgs,
 
    applicationType: "Web"
});
 
const app = new azure.appservice.AppService(`${prefix}-as`, {
    // ... other parameters as defined above
 
    appSettings: {
        "ApplicationInsights:InstrumentationKey": appInsights.instrumentationKey,
        // ... other settings as defined above
    },
});

Continuous Deployment with Azure DevOps

While Pulumi CLI works great during development; a production deployment should rather be executed in a CI/CD pipeline. This time I’m using Azure DevOps – a managed CI/CD service to build, test, and deploy cloud applications.

In particular, I defined an Azure Pipeline consisting of three steps:

Build & Publish the .NET Core application;
Restore NPM packages for the infrastructure program;
Provision the cloud infrastructure with Pulumi.

Build & Publish the .NET Application

The first step utilizes a built-in task which triggers the .NET Core CLI to build the source code in the src folder and publish the assemblies as a zip file.

steps:
- task: DotNetCoreCLI@2
 inputs:
   command: 'publish'
   projects: 'src'
 displayName: 'Build and publish the ASP.NET Core app'

Restore NPM packages for the infrastructure program

The second step is a simple npm install step to restore the NodeJS dependencies:

 - task: Npm@1
   inputs:
      command: 'install'
      workingDir: 'infra'
   displayName: 'NPM install packages'

Install Pulumi and Run Infrastructure Code

There is a Pulumi task available in Azure Marketplace: Pulumi Azure Pipelines Task. After installing it to your organization, you should be able to utilize a simple task like this:

 - task: Pulumi@0
   inputs:
      azureSubscription: 'Your Azure Subscription(aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee)'
      command: 'up'
      args: '--yes'
      cwd: 'infra'
      stack: 'dev'
   displayName: 'Install pulumi and run infra code'
   name: pulumi

Alternatively, if you can’t install third-party tasks from Azure Marketplace, you can call the Pulumi CLI from a custom shell script, see this pipeline definition.

When everything is wired correctly, I see this screen in Azure DevOps:

The newly created resource group contains six resources:

The application is up and running:

The telemetry is flowing into Application Insights:

You can find the full code of the application, infrastructure definition, and deployment pipeline in Pulumi Examples repository.

Pulumi ❤️ Azure PaaS

Azure App Service and friends are a great way to deploy web applications and APIs without worrying about the nitty-gritty details of the underlying hardware.

Writing a TypeScript program to compose an application out of the cloud building blocks feels like a breeze to me. I can reuse all my skills and stay productive by defining cloud resources as code in a familiar language.

You can get going with these resources:

Pulumi enables developers to define cloud infrastructure using general purpose programming languages. Pulumi works with multiple cloud providers and has first-class support for all services in Microsoft Azure.

CI/CD Made Easy with Pulumi and Azure Pipelines

Praneet Loke — Mon, 06 May 2019 00:00:00 +0000

Azure DevOps is very popular among teams that want a single place to manage their development pipelines, Git repositories, builds, releases, and test plans. Pulumi’s open-source tools are a great choice for developers and operators deploying infrastructure as code on Azure. With these two tools at hand, adopting CI and CD for your Azure infrastructure is just a few steps away for you and your teams.

To make it easy to use Pulumi with Azure, we are announcing an open-source task extension for Azure Pipelines! The task extension will manage the installation of the Pulumi CLI, and run the Pulumi commands you specify against your stack.

You can install the task extension directly from the Visual Studio Marketplace. Click the “Get It Free” button to install the extension into your Azure DevOps organization. If you do not have the permissions to add it to your organization, please contact your org admin to have the extension installed. The source code for the open source task extension can be found on GitHub.

To use the Pulumi task extension in Azure Pipelines, there are two options. The full example is in the source repo. For contrast, without this task extension, here’s how you would achieve the same, but with scripts.

OPTION 1: Using the Classic Editor Console

Pasted below is a typical view of the Editor User Interface. Click on the "+" button next to the job. As visible in the screenshot, the job is called “Agent job 1”. The agent pool you choose does not matter. The Pulumi task can run on both Linux as well as Windows images.

Search for the Pulumi task by typing in the filter input on the right. Click the Add button.

Fill in the required information. You can learn about creating service connections for Azure here.

If you want to understand all the commands available with the Pulumi CLI, click on the information icon (i) next to Pulumi Command, and click on the help link to go to our quick reference page.

Option 2: Using a YAML File

Here’s an example of the Pulumi task extension defined in YAML configuration.

- task: Pulumi@0
 inputs:
 azureSubscription: '<your-service-connection-name>'
 command: "up"
 args: "--yes --skip-preview"
 cwd: "./"
 # Replace this with your org's name.
 stack: "<org-name>/pulumi-az-pipelines-task-example/dev"

Moving to Production

Once you’ve configured your Pulumi task extensions for your Azure Pipelines, you can now more easily integrate Pulumi into your CI/CD pipeline, and take advantage of previews to infrastructure changes in pull requests, push-to-deploy, and ultimately removing the friction for your DevOps.

As always, we’d love to hear what you think. Say 👋 in the Pulumi Community Slack or drop us a line.

Want to learn more? Check out this post from Mikhail Shilkov for a detailed look at deploying applications on Azure with Pulumi. Also, keep an eye on our blog posts this week for more posts about Azure.