Pulumi Blog: Sophia Parafina

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.

How to Test Infrastructure with Pulumi

Sophia Parafina — Fri, 23 Jul 2021 00:00:00 +0000

In the Testing Practices for Cloud Engineering article we discussed how to apply software testing methodologies to cloud engineering. We also examined testing regimes starting from the testing pyramid to the trophy and honeycomb models of testing better suited to distributed and cloud architectures. These testing regimes include three types of tests suited for cloud architectures:

unit tests for testing methods and functions within a service
property tests for validating specified service outputs
integration tests to ensure that resources interact as specified

In this article, we’ll do a deep dive into each of these testing methods.

Cloud engineering testing differs from application testing because multiple dependencies between components can have high latency. Let’s examine these dependencies using an example application composed of an application layer, a database layer, and a network layer. We can visualize these dependencies with Pulumi’s resource graph.The graph is constructed from the inputs needed to create a resource.

The resource graph for the application layer shows many dependencies. The application deploys containers in AWS Fargate, which are instantiated with an application service that requires a service definition with many inputs.

Unit tests are ideal for validating inputs and ensuring that cloud resources are created. Let’s look at a simple example with just two resources, an EC2 instance running a web server and a SecurityGroup policy.

We can use mocks to test if the webserver has a name tag. First, we’ll create the mocks and import the infrastructure that uses the mocks.

import unittest
import pulumi

class MyMocks(pulumi.runtime.Mocks):
 def new_resource(self, args: pulumi.runtime.MockResourceArgs):
 outputs = args.inputs
 if args.type == "aws:ec2/instance:Instance":
 outputs = {
 **args.inputs,
 "publicIp": "203.0.113.12",
 "publicDns": "ec2-203-0-113-12.compute-1.amazonaws.com",
 }
 return [args.name + '_id', outputs]
 def call(self, args: pulumi.runtime.MockCallArgs):
 if args.token == "aws:ec2/getAmi:getAmi":
 return {
 "architecture": "x86_64",
 "id": "ami-0eb1f3cdeeb8eed2a",
 }
 return {}

pulumi.runtime.set_mocks(MyMocks())

# Now actually import the code that creates resources, and then test it.
import infra

We can write a test that checks if the web server has tags and specifically a name tag. First, here’s the code that creates the web server instance:

server = ec2.Instance('web-server-www',
 instance_type="t2.micro",
 vpc_security_group_ids=[ group.id ], # reference the group object above
 # Comment out to fail a test:
 tags={'Name': 'webserver'}, # name tag
 # Uncomment to fail a test:
 #user_data=user_data) # start a simple web server
 ami=ami_id)

Using Python’s unittest framework, the test looks like this:

@pulumi.runtime.test
def test_server_tags():
 def check_tags(args):
 urn, tags = args
 assert tags, f'server {urn} must have tags'
 assert 'Name' in tags, 'server {urn} must have a name tag'

 return pulumi.Output.all(infra.server.urn, infra.server.tags).apply(check_tags)

The test has two assertions: one for tags on the server urn and another if the instance has a Name tag. When we call the test, we pass the server urn and tags. Note that we did not instantiate an EC2 instance and used a mock. This is why it can run unit tests frequently with quick results.

Validating cloud resource properties in tests

In addition to unit tests, we want to test the properties of a cloud resource. For example, we want to restrict access to a resource by creating a policy that limits ingress. For this use case, we need a property test to ensure the exact values required by a policy. The resource graph from our simple example shows that a SecurityGroupRule sets ingress to the web server. We can test if port 22 is open, which would enable logging into the server via ssh.

group = ec2.SecurityGroup('web-secgrp', ingress=[
 { "protocol": "tcp", "from_port": 22, "to_port": 22, "cidr_blocks": ["0.0.0.0/0"] },
 { "protocol": "tcp", "from_port": 80, "to_port": 80, "cidr_blocks": ["0.0.0.0/0"] },
])

The code that tests for an open port 22 for any rule that includes from_port and cidr_blocks in the resource definition.

# Test if port 22 for ssh is exposed.
@pulumi.runtime.test
def test_security_group_rules():
 def check_security_group_rules(args):
 urn, ingress = args
 ssh_open = any([rule['from_port'] == 22 and any([block == "0.0.0.0/0" for block in rule['cidr_blocks']]) for rule in ingress])
 assert ssh_open == False, f'security group {urn} exposes port 22 to the Internet (CIDR 0.0.0.0/0)'

 # Return the results of the unit tests.
 return pulumi.Output.all(infra.group.urn, infra.group.ingress).apply(check_security_group_rules)

Because web-secgrp has port 22 open to all IP addresses, we can expect it to fail this test. You can find the complete example for the unit and property tests on Pulumi’s example Github repository.

Integration testing

Integration testing requires deploying resources in either a test environment or an ephemeral environment. In this integration testing example, we’ll deploy a single resource using Pulumi’s Automation API. Spinning up ephemeral environments for integration testing is an excellent use for the Automation API, which provides a programmatic interface for building infrastructure without a CLI or web-based console.

In this simple example, we’ll use Automation API to create an S3 bucket and perform a set of tests that include:

verifying the bucket name and AWS region
upload a test file
delete the file
delete the stack with the bucket

The following code sets up the Pulumi stack and S3 bucket with Automation API. It’s interesting to note that the tests don’t import the Pulumi AWS SDK and uses a combination of Python’s built-in unittest framework and Amazon’s boto3 Python library. This illustrates the extensibility and flexibility of infrastructure as code by letting developers choose the tools and SDKs.

import os
import unittest

import boto3
from pulumi.x import automation as auto

from resource_s3 import BUCKET_NAME, OUTPUT_KEY_BUCKET_NAME, OUTPUT_KEY_REGION


class TestS3(unittest.TestCase):

 @classmethod
 def setUpClass(cls) -> None:
 cls.STACK_NAME = 'staging'
 cls.REGION_NAME = 'eu-north-1'
 cls.WORK_DIR = os.path.join(os.path.dirname(__file__))
 cls.FILE_NAME = 'bucket.txt'

 cls.stack = auto.create_or_select_stack(stack_name=cls.STACK_NAME, work_dir=cls.WORK_DIR)
 cls.stack.set_config("aws:region", auto.ConfigValue(value=cls.REGION_NAME))
 cls.stack.up(on_output=print)
 cls.outputs = cls.stack.outputs()
 cls.s3 = boto3.resource('s3')

The TestS3 class has a second @classmethod decorator for the tests; for example, the following code uploads a file and checks to see if the file is stored in the bucket.

 def test_s3_create_permission(self):
 output_bucket_name = self.outputs.get(OUTPUT_KEY_BUCKET_NAME).value
 created_response = self.s3.Bucket(output_bucket_name).put_object(Key=self.FILE_NAME, Body='Hi')
 self.assertEqual(created_response.key, self.FILE_NAME)

When we run the test, it creates the stack and resource, runs the tests, and tears down the infrastructure. This process can be part of a CI/CD pipeline to run an automated integration test as part of the build process. The complete example for integration testing is available on Github.

Infrastructure testing strategy: final thoughts

Although distributed infrastructure presents some unique challenges because of its asynchronous nature, we can perform efficient and automated testing. Whether it is unit and property testing that uses mocks and stubs or integration testing that requires deployed resources, infrastructure as code lets you use familiar testing frameworks and SDKs. Moreover, Pulumi’s Automation API makes it simple to create stacks and spin up ephemeral infrastructure for integration testing. Learn more about infrastructure testing with Pulumi’s Testing User Guide and get hands-on with our testing examples.

Testing Practices for Cloud Engineering

Sophia Parafina — Tue, 22 Jun 2021 00:00:00 +0000

Cloud engineering brings industry-standard software development practices to building, deploying, and managing cloud infrastructure. Testing is a common practice for evaluating software to ensure that it meets requirements. Similarly, infrastructure testing checks for missing requirements, bugs, and errors; it also ensures security, reliability, and performance. Testing uses manual or automated tools to identify bugs that can cause unexpected infrastructure behavior.

There are many benefits to infrastructure testing, including:

reduced costs to fix bugs when caught early in the development lifecycle,
discovering security risks and problems earlier,
delivering a quality product that creates customer satisfaction through a great user experience

Testing shifts left the risk inherent with distributed architectures composed of many resources. Ultimately, testing increases release velocity, reliability, and confidence in your application.

This article is the first in a two-part series about testing infrastructure. The terminology for testing can be confusing because of broad definitions that overlap. This article will narrow those definitions that originated from application testing and apply them to infrastructure and cloud engineering. Let’s take a look at the different types of testing used with infrastructure as code.

Functional testing vs. non-functional testing

With infrastructure as code we want to test if parts of the system work as required or how parts interact with each other; this is functional testing. We will also want to test how the system behaves concerning performance, security, reliability, usability, and compliance. In general, these tests are called non-functional tests because they test the system’s behavior as a whole rather than by its parts.

In functional testing, unit tests typically test a single function or class. They are low-level tests that can be executed quickly and at low costs. Integration tests are functional tests that validate how components interact with each other, i.e.; it checks the interaction between software components. Non-functional tests are frequently performance tests, which evaluate the behavior of the system.

Mike Kohn proposed the testing pyramid that shows the different layers of testing and the amount of testing for each layer.

In their original form, unit tests comprise most tests, with integration or service tests as the middle layer of the pyramid. At the top of the pyramid are end-to-end or UI tests, which indicate performing non-functional tests sparingly.

However, pushback against this model was proposed in 1999 at the height of popularity for Xtreme Programming (XP). Alternative models include Kent Dodd’s Testing Trophy

and Spotify Lab’s Testing Honeycomb.

As you can see, both models suggest that the majority of tests should be integration tests. These models responded to the change from monolithic architectures prevalent when Dodd proposed the Testing Pyramid to the shift to microservices and distributed architectures that make up modern applications.

For deploying modern applications with cloud engineering, we propose an alternate model called the testing rocket. Static testing is inherent in cloud engineering because of the software toolchains, such as IDEs, that perform static checking. Both unit and integration testing are equally important to ensure that infrastructure is deployed and managed reliably. End-to-end tests for performance and scalability should be performed less frequently because of complexity and costs.

Cloud engineering testing

Cloud engineering applies software testing principles to infrastructure where we focus on functional testing. We use three types of functional tests with infrastructure: unit tests, integration tests, and property tests (sometimes called functional tests). We’ll examine each type of test in detail.

Static tests

Infrastructure templating languages such as YAML or JSON have limited static validation capabilities; primarily, they are limited to linting: validating and formatting the code. Pulumi’s approach of deploying infrastructure with programming languages lets you use built-in tools in IDEs that perform static tests, highlight errors in your code, and offer other features such as code completion, enumerations, and syntax checking. Pulumi’s preview also performs static checking before deploying a resource.

Unit tests

Unit tests for applications test the smallest piece of code, which are often methods and functions of classes or modules. They are commonly written by the programmer and run quickly.

With infrastructure, the smallest unit is often the cloud resource. Because cloud resources haven’t been created by the time you run unit tests, you can’t write a test to evaluate infrastructure behavior. For example, you can’t make HTTP requests to endpoints because there’s no web server to serve them.

Pulumi’s cloud engineering approach enables unit testing by replacing all external dependencies with mock objects that replicate the behavior in a specified way. This enables you to write fast unit tests that run in memory without any out-of-process calls. They provide rapid feedback loops during development, making them suitable for Test-Driven Development (TDD).

As with applications, unit tests for infrastructure in Pulumi are authored with the same language used to declare infrastructure. This means you can use familiar test and mock frameworks such as PyTest for Python or Mocha for Node.js. Using a framework ensures configuration is correct before provisioning and that the resulting infrastructure has the specified properties. In addition, team standards and security guidelines are enforced.

Property tests

Another type of test is property tests, which are sometimes called “functional tests.” Property tests evaluate the business requirements of an application by verifying the output of an action without examining the code that’s executed. Property tests, like integration tests, require components to interact. However, property tests require that the component return a specified value, while integration tests verify that the function works as required. For example, a property test would require a value, such as the count of rows returned, and an integration test would only require that rows are returned.

Property tests in cloud engineering and Pulumi use Policy as Code to set guardrails and enforce compliance for cloud resources. In addition to authoring company-wide policies, It also enables another type of infrastructure testing where a policy becomes a property that a test can evaluate and assert. Property tests run before and after infrastructure provisioning and have access to all input and output values of all cloud resources instantiated in a Pulumi program. Unlike unit testing, property tests can evaluate real values from the cloud provider and not mocked values.

Finally, there are several ways to run property tests against any cloud environment. They can be configured as a persistent stack for acceptance testing, or as an ephemeral cloud environment created by a pull request, or a combination of both.

Integration tests

Integration tests validate whether services or modules in an application work as specified. Unlike unit tests, they use actual dependencies instead of mock objects, and they provide less precise feedback than unit or property tests. Because integration uses actual dependencies, they require that services be complete and functioning. Tests are run in a strict order to ensure that modules or services are instantiated before the test. Developers are less likely to write and run integration tests, leaving it to SRE experts in specialties such as chaos engineering and pipeline automation to write tests run in a CI/CD system.

In cloud engineering, an infrastructure integration test uses infrastructure deployed in an ephemeral environment. As an example, we can use the Pulumi CLI to deploy the ephemeral environment as a stack that builds a dependency graph based on inputs and outputs that ensures the required resources are instantiated and available before the integration test.

Once the resources are deployed, the integration test retrieves the stack outputs, which is often a public IP address or resource name. The test can be as complex as a suite of application-level tests between the various services or components or as simple as a health check that expects an HTTP 200 status return from an endpoint. The primary advantage of integration tests is that they use the same cloud infrastructure used in production to return actual values.

However, there are two areas of concern. First, deploying ephemeral infrastructure takes time to create the resources. The impact is that integration tests are not performed as frequently as unit tests raising the possibility of finding bugs later rather than sooner. Secondly, there is a cost to deploying ephemeral infrastructure, and you can easily overrun your testing budget if performed frequently.

Distributed architectures have become the norm for cloud-based applications. For example, microservices are composed of individual services interacting with each other. Because of the interaction between stand-alone services, we can see why both the trophy model and the honeycomb model of testing prioritize integration testing despite these concerns.

Summary

Testing is an integral part of cloud engineering. With its origins in software engineering, we can use the same methodologies to build reliable infrastructure. We’ve presented three types of tests for infrastructure deployed with programming languages. When we use a programming language for infrastructure deployment, we can take advantage of the software toolchain to perform static tests not possible with templating languages. We can also perform unit tests and property tests without deploying infrastructure by using mocks and policies. Finally, we can build ephemeral infrastructure to perform integration tests at the application level. We’ll look at specific examples for performing unit, property, and integration tests in the follow-up article. Stay tuned.

Refactoring Infrastructure as Code

Sophia Parafina — Tue, 01 Jun 2021 00:00:00 +0000

The central principle of cloud engineering is adopting software engineering practices. Refactoring is a technique for making changes to code that improve maintainability, enhance performance, scalability, and security without changing its external behavior. In devops, refactoring often occurs with modern applications; however, we can apply those same techniques to cloud infrastructure with infrastructure as code.

Refactoring results in many advantages. First and foremost, the code is more readable and easier to understand for other team members –this aids in maintainability and well-organized code, providing a solid foundation for future releases. Overall, if done well, refactoring reduces complexity which makes future changes more efficient.

The topic of refactoring is a broad topic covering many different techniques. Many references, such as Martin Fowler’s Refactoring, cover refactoring in depth. In this article, we examine standard practices used with infrastructure as code.

Infrastructure is different

A major difference between refactoring application and infrastructure code is that resources, such as databases persist. Typically, if you change the name, type, or parent path of a resource, it is deleted and a new resource is created. Other infrastructure as code solutions tie a file or module to a resource’s identity. An advantage of Pulumi is that moving a resource across file boundaries does not recreate the resource because a resource’s identity is based on its object ID, irrespective of its file location.

In cases where an object’s ID changes – due to a rename, reparenting to a new component, or otherwise – Pulumi provides aliases. An Alias accepts a list of identifiers that can include old Alias objects or old resource URNs. When a resource is annotated with an alias, Pulumi can connect the old to the new object state, and the resource can be updated in place.

A similar situation occurs with component resources, i.e., a logical grouping of related resources such as VPC with subnets pre-configured. When you change a parent resource of a component resource, the identity of the component resource also changes. Pulumi provides a parent option to tie a child resource to the parent resource. The combination of alias and parent arguments to resources lets you refactor infrastructure while preserving existing resources.

Let’s examine how to apply refactoring to infrastructure.

Test-Driven Development

Test-driven development (TDD) is a common technique used for code refactoring. TDD breaks down refactoring into three steps:

Red: consider the required behavior and what needs to be coded
Green: get the code to pass a test for that behavior
Refactor: review the code for improvements and implement as needed.

In a previous blog post, Ringo de Smeti used TDD to refactor Cumundi’s code for provisioning repositories by customer. Ringo created a ComponentResource subclass which moved individual resources into a customer resource class.

// Pulumi custom resource representing a customer project
export class Project extends pulumi.ComponentResource {
 constructor(name: string, args: ProjectArgs, opts: pulumi.CustomResourceOptions = {}) {
 super('customer:Project', name, {}, opts);

 var customerId = name.replace(/([a-zA-Z])(?=[A-Z])/g, '$1-').toLowerCase();
 var serviceId = name.replace(/([a-zA-Z])(?=[A-Z])/g, '$1').toLowerCase();

 const gitlabProject = new gitlab.Project(name,
 {
 name: customerId,
 description: pulumi.interpolate`${args.customer} code`,
 namespaceId: args.gitlabNamespace,
 visibilityLevel: "private",
 defaultBranch: "master",
 pipelinesEnabled: true,
 issuesEnabled: false,
 wikiEnabled: false,
 snippetsEnabled: false,
 containerRegistryEnabled: false,
 mergeRequestsEnabled: false,
 mergeMethod: "ff",
 onlyAllowMergeIfPipelineSucceeds: true,
 sharedRunnersEnabled: true
 }
 )

Calling the Project class creates a new customer.

const firstCustomer = new customer.Project("FirstCustomer",
 {
 customer: 'First Customer',
 needsGoogleInfra: false,
 gitlabNamespace: gitlabNamespace
 }
)

const secondCustomerProject = new customer.Project('SecondCustomer',
 {
 customer: 'Second Customer',
 needsGoogleInfra: true,
 gitlabNamespace: gitlabNamespace
 }
)

By using TDD, Ringo reduced code duplication, resulting in a clean and efficient codebase.

Refactoring by Abstraction: Pull-Up/Push-Down

The Pull-Up/Push-Down method is used frequently to reduce duplicate code. It does this by abstracting methods into classes to implement inheritance and extraction. The Pull-Up method uses a superclass to consolidate similar methods, whereas Push-Down moves methods from a superclass into subclasses.

The Pull-Up method in this example deploys the Kubernetes Guest Book. The simple version is a port of the original YAML and the component version, shown below, creates a service class that creates both the service and deployment.

export class ServiceDeployment extends pulumi.ComponentResource {
 public readonly deployment: k8s.apps.v1.Deployment;
 public readonly service: k8s.core.v1.Service;
 public readonly ipAddress?: pulumi.Output<string>;

 constructor(name: string, args: ServiceDeploymentArgs, opts?: pulumi.ComponentResourceOptions) {
 super("k8sjs:service:ServiceDeployment", name, {}, opts);

 const labels = { app: name };
 const container: k8stypes.core.v1.Container = {
 name,
 image: args.image,
 resources: args.resources || { requests: { cpu: "100m", memory: "100Mi" } },
 env: [{ name: "GET_HOSTS_FROM", value: "dns" }],
 ports: args.ports && args.ports.map(p => ({ containerPort: p })),
 };
 this.deployment = new k8s.apps.v1.Deployment(name, {
 spec: {
 selector: { matchLabels: labels },
 replicas: args.replicas || 1,
 template: {
 metadata: { labels: labels },
 spec: { containers: [ container ] },
 },
 },
 }, { parent: this });

 this.service = new k8s.core.v1.Service(name, {
 metadata: {
 name: name,
 labels: this.deployment.metadata.labels,
 },
 spec: {
 ports: args.ports && args.ports.map(p => ({ port: p, targetPort: p })),
 selector: this.deployment.spec.template.metadata.labels,
 // Minikube does not implement services of type `LoadBalancer`; require the user to specify if we're
 // running on minikube, and if so, create only services of type ClusterIP.
 type: args.allocateIpAddress ? (args.isMinikube ? "ClusterIP" : "LoadBalancer") : undefined,
 },
 }, { parent: this });

 if (args.allocateIpAddress) {
 this.ipAddress = args.isMinikube ?
 this.service.spec.clusterIP :
 this.service.status.loadBalancer.ingress[0].ip;
 }
 }
}

With infrastructure as code, you can use your IDE to refactor.

Composing

Composing is another refactoring method for reducing duplicate code. The most common way to use composing is through extraction and inline methods.

Extraction consolidates code by creating a new method and replacing duplicate methods with a call to the new method. For example, when we create services, we often export information about the service, such as IP address or hostname, as shown in the example below.

export const publicIp = server.publicIp;
export const publicHostName = server.publicDns;

We can create a function that exports the information about a service and call it as needed.

function public_server_info(server) {
 export const publicIp = server.publicIp;
export const publicHostName = server.publicDns;
}

public_server_info(server);

Inline refactoring reduces unnecessary methods by finding all calls to the method and replacing them with the content of the method. In this policy as code example, we can refactor two methods into a single method.

export function requireEbsVolumesOnEc2Instances(name: string): ResourceValidationPolicy {
 // TODO: Check if EBS volumes are marked for deletion.
 return {
 name: name,
 description: "EBS volumes should be attached to all EC2 instances",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(aws.ec2.Instance, (instance, args, reportViolation) => {
 if (instance.ebsBlockDevices !== undefined) {
 reportViolation("EC2 Instance should have EBS volumes attached.");
 }
 if (instance.ebsBlockDevices.length === 0) {
 reportViolation("EC2 Instance should have EBS volumes attached.");
 }

 }),
 };
}

The function can be simplified to the following:

export function requireEbsVolumesOnEc2Instances(name: string): ResourceValidationPolicy {
 // TODO: Check if EBS volumes are marked for deletion.
 return {
 name: name,
 description: "EBS volumes should be attached to all EC2 instances",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(aws.ec2.Instance, (instance, args, reportViolation) => {
 if (instance.ebsBlockDevices !== undefined && instance.ebsBlockDevices.length === 0) {
 reportViolation("EC2 Instance should have EBS volumes attached.");
 }
 }),
 };
}

Simplifying Method Calls

Simplifying method calls makes them easier to understand by clarifying the logic for interaction between classes. One way to simplify code is to add, remove, or introduce new parameters with explicit methods and method calls.

Roles in AWS are typically stored as JSON documents. In the example below, we create the role by passing in a string.

lambda_role = iam.Role('lambdaRole',
 assume_role_policy="""{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Action": "sts:AssumeRole",
 "Principal": {
 "Service": "lambda.amazonaws.com"
 },
 "Effect": "Allow",
 "Sid": ""
 }
 ]
 }"""
)

sfn_role = iam.Role('sfnRole',
 assume_role_policy="""{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Service": "states.%s.amazonaws.com"
 },
 "Action": "sts:AssumeRole"
 }
 ]
 }""" % config.region
)

You can write a function called create_role and pass in the name and policy as JSON to create many roles.

const lambda_role_document = JSON.parse('{"Version": "2012-10-17","Statement": [{"Action": "sts:AssumeRole","Principal": {"Service": "lambda.amazonaws.com"},"Effect": "Allow","Sid": ""}]}')

function create_role(role :string, policy :JSON) {
 const newrole = new aws.iam.Role(role,{
 assumeRolePolicy: JSON.stringify(policy),
 })
 return role;
}

const lambdaRole = create_role("my_lambdarole",lambda_role_document);

Moving Features

Moving features creates new classes and moves functionality between old and new classes. A utility class may not have some methods you need, but you can’t add those methods to that class. The solution is to create a new class with the methods you need.

In this example, we extend a class and add new methods that configure an EC2 instance post-provisioning.

export class Provisioner<T, U> extends pulumi.dynamic.Resource {
 dep: pulumi.Output<T>;
 result: pulumi.Output<U>;
 constructor(name: string, props: ProvisionerProperties<T, U>, opts?: pulumi.CustomResourceOptions) {
 const provider: pulumi.dynamic.ResourceProvider = {
 diff: async (id: pulumi.ID, olds: State<T, U>, news: State<T, U>) => {
 let replace = false;
 let replacementProperties = [];
 if (JSON.stringify(olds.dep) !== JSON.stringify(news.dep)) {
 replace = true;
 replacementProperties.push("dep");
 }
 // Only trigger replacement due to the `changeToken` property, IFF
 // the changeToken still has a value in the new inputs, and it doesn't
 // match with the old value. If, say, the user decides to no longer specify
 // the changeToken in the new inputs, then we don't trigger a replacement.
 if (news.changeToken && olds.changeToken !== news.changeToken) {
 replace = true;
 replacementProperties.push("changeToken");
 }
 return {
 changes: replace,
 replaces: replace ? replacementProperties : undefined,
 deleteBeforeReplace: true,
 };
 },
 create: async (inputs: State<T, U>) => {
 const result = await props.onCreate(inputs.dep);
 if (result !== undefined) {
 inputs.result = result;
 }
 return { id: uuid.v4(), outs: inputs };
 },
 };
 super(provider, name, { dep: props.dep, changeToken: props.changeToken, result: null }, opts);
 }
}

Preparatory Refactoring

Preparatory refactoring occurs when adding a new feature to a release. It is typically part of a software update instead of a separate refactoring process. Preparatory refactoring reduces future technical debt.

Conclusion

Writing clean and efficient code is part of cloud engineering, and we can achieve this by using well-established refactoring methods used by application developers. Pulumi has many easy-to-understand examples in Node.js, Python, Go, and .Net. Because the examples are written explicitly to make them understandable, some could use refactoring. What code samples can you find in the Pulumi Github repository that could use some refactoring?

Cloud Engineering: The Future Is Now

Sophia Parafina — Thu, 29 Apr 2021 00:00:00 +0000

Thank you for joining the PulumiUP event. We had a stellar set of speakers and panelists discussing the future of DevOps and how Cloud Engineering is providing the tools and processes that enable faster delivery, the right mix of architecture, and foster collaboration among teams in an organization. Here are some of the highlights and takeaways from our speakers.

Putting Cloud Engineering in Practice

Our speakers all commented on how the cloud is speeding up development. Applications are dynamic, and your infrastructure should also be dynamic, according to Adrian Cockcroft, VP of Sustainability Architecture at Amazon. The future of infrastructure is a mixture of lightweight, scalable services combined with event-driven architecture. Furthermore, composing infrastructure should take advantage of well-architected frameworks such as those published by AWS and Liberty Mutual.

Underscoring this, Justin Fitzhugh, VP of Cloud Engineering at Snowflake, cited the need to disaggregate compute and storage to scale independently. Moreover, Snowflake needed to scale across three public clouds with self-managed infrastructure. In Snowflake’s experience, scaling with manual processes was not a viable option. They codified actions by following the software engineering process of code commits, tests, CI processes, and a CD pipeline for execution.

Keith Redmond, VP of SaaS Engineering at Fernergo share a perspective from the financial services industry. He reiterated the need for a deployment framework that bridged dev and ops teams and an automated build and release process to maintain integrity and reliability. He noted that this required a change in culture from teams handing off tasks to each other without input from the other to a completely integrated team where all actions with infrastructure begin with a code commit. The culture shift to an engineering-managed process also changed hiring patterns from operators and system administrators with some coding skills to software engineers interested in infrastructure.

In the current cloud engineering landscape, we will continue to see movement towards heterogeneous architectures, an increase in the use of software engineering methodologies to deploy infrastructure, and more automation for building and deploying in the cloud. This segues into the future of cloud engineering with a focus on tooling, process, and teams.

The Future of Cloud Engineering

The cloud engineering panel included Justin Fitzhugh, Dana Lawson, VP of Engineering at GitHub, Charity Majors, CTO at Honeycomb, and was moderated by Kat Cosgrove, Developer Advocate at JFrog. The session, titled “Your Peers,” discussed the future of cloud engineering.

When planning for the future of modern cloud applications, the panel agreed that the industry would continue to iterate and evolve away from domain specific languages, DSLs, and towards software engineering practices for infrastructure. They also agreed that while Go would be the most popular language for Infrastructure as Code, Ruby and JavaScript will also continue to be key languages.

Cloud engineering personas will change as new technologies such as the Internet of Things, availability of 5G, orchestration, edge computing, and future network APIs roll out. Cloud engineers should continue to focus on containers and what goes into applications. Knowing the entire lifecycle of their application from development to production is a must for cloud engineers. It underlies the concept of a single persona that can use services to compose development and services. Ultimately, the job of the cloud engineer is to reduce complexity and reduce friction in the pipeline by using patterns as needed and building platforms and tools consistently.

The panel discussed the reality of testing in production. Charity Majors highlighted that you have no choice, whether you admit it or not; there will always be known unknowns because devs or operators cannot test everything. Software will always have bugs, but the problem can be managed by having more ways to separate problems and test them in a small and controlled way. Testing in production begins with observability, starting with usual tools such as strace and other enhanced toolsets to inspect your code. Also, feature flags and deployment models help find bugs and limit their impact when applications go into production.

Finally, the panel looked backward at the impact and legacy of devops. The panel agreed that devops brought both sides to the table. Operations learned about code and applications while developers learned about infrastructure. Practitioners are software engineers, but each with a different focus. Implementing infrastructure is similar to creating a new feature. However, there is a concern for losing deep systems knowledge, and software engineers are unlikely to have a deep understanding of networking, system administration, or storage. The solution is to train people cross-functionally, i.e., software engineers on systems and operators on coding and application. Teamwork is the key to breaking down operational and knowledge silos in an organization.

Summary

Thank you for attending PulumiUP! Your response to the Pulumi 3.0 release was overwhelming. If you didn’t have the chance to catch PulumiUP on launch day, you can watch the entire event.

Pulumi Interstellar

Zack Chase — Thu, 01 Apr 2021 00:00:00 +0000

Earth is just the beginning. We are putting down the foundations of space so our children can build their future. At Pulumi, we are committed to making life multi-planetary. We are excited to announce Pulumi Interstellar, a collection of resource providers that will help us reach the future of a space-faring and multi-planet species.

For our first offering of space related resource providers, we have aligned closely with the current priorities in the space industry today:

Getting to New Planets
Making Planets Habitable

We believe that solving those two areas for our customers will enable people to build the future they imagine, on the planets they desire to inhabit. One challenging aspect of achieving our goals is that each new planet represents a different operational environment.

One might think the right solution for provisioning and managing resources in space would be a proprietary domain-specific language designed from the ground up to operate in these new environments. However 10 out of 10 leading rocket scientists confirm that the heterogeneous diversity of existing programming languages allows us to move faster and with less frustration.

In the following sections we will take a closer look at the two main areas defined above and how you too can begin building the future in a familiar programming language like JavaScript, TypeScript, Python, Go, or .NET.

Rockets As Code

Rockets are the first step to making humans a multi-planet species, they enable you and your resources to travel to new planets. Today, we are extremely excited to introduce the Pulumi Rocket Provider, which allows users to configure rocket fuel requirements, initiation sequences, configure deployment payloads, reserve seats, and much more.

In the initial release of the Rocket Provider we are happy to enable two key use cases: Resource Deployment and Planetary Travel.

Resource Deployment

import * as tyrell from "@pulumi/tyrell"

const engineId = tyrell.rocket.getEngine({
 owners: ["420"],
 mostRecent: true,
 filters: [{name: "SuperDraco", values: ["tyrell/engines/super-draco-15.03-*"]}],
});

const spaceship = new tyrell.spaceship.Instance("Edward Isreal", {
 instanceType: tyrell.spaceship.InstanceTypes.interplanetary,
 engine: engineId,
 capability: "kuiper_belt",
}];

from pulumi_tyrell import rocket, spaceship

engine_id = rocket.getEngine(
 owners=["420"],
 most_recent=true,
 filters="""[
 {name: "SuperDraco", values: ["tyrell/engines/super-draco-15.03-*"]}
 ]""",
)

spaceship = spaceship.Instance("Edward Isreal",
 instanceType=spaceship.instance_types.interplanetary,
 engine=engineId,
 capability="kuiper_belt"
)

using Pulumi;
using Tyrell = Pulumi.Tyrell;

class MyStack : Stack
{
 public MyStack()
 {
 var engineId = new Tyrell.Rocket.GetEngine(new Tyrell.Rocket.GetEngineArgs
 {
 Owners =
 {
 "420",
 }
 MostRecent = true,
 Filters = {
 { "name": "SuperDraco", "values": ["tyrell/engines/super-draco-15.03-*"] },
 }
 });

 var spaceship = new Tyrell.Spaceship.Instance("", new Tyrell.Spaceship.InstanceArgs{
 InstanceType = Tyrell.Spaceship.InstanceTypes.Interplanetary,
 EngineId = engineId,
 Capability = "kuiper_belt",
 });
 }

}

package main

import (
 "github.com/pulumi/pulumi-tyrell/sdk/v3/go"
 "github.com/pulumi/pulumi/sdk/v2/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 engineId, err := tyrell.Rocket.GetEngine(&tyrell.Rocket.GetEngineArgs{
 Owners: []string{"420"},
 MostRecent: true,
 Filters: []RocketEngineFilter{
 RocketEngineFilter{
 Name: "SuperDraco",
 Values: []string{"tyrell/engines/super-draco-15.03-*"},
 },
 },
 })
 if err != nil {
 return err
 }

 spaceship, err := tyrell.Spaceship.Instance("Edward Isreal", &tyrell.Spaceship.InstanceArgs{
 InstanceType: tyrell.Spaceship.InstanceTypes.Interplanetary,
 EngineId: engineId,
 Capability: "kuiper_belt",
 })
 if err != nil {
 return err
 }

 return nil
 })
}

On Day 1 you can deploy resources via reusable rockets. By declaring a payload on your Rocket, you tell Pulumi to deliver the payload to the location specified. Resource Deployments will be particularly useful when configuring a new planet in the initial stages, as you can deploy new resources and terraforming equipment in a consistent, repeatable, and scalable manner.

Once the rocket arrives at its destination, Pulumi’s Space AI Assistant, nicknamed IRWIN, will take control to ensure your resources are deployed efficiently and correctly. By using Resource Deployments you can ensure your infrastructure and workloads are up and running before arriving on your new planet.

Planetary Travel

const config = pulumi.Config();
const passengers = config.require("passengers");

const seats = tyrell.tyrell.PassengerGroup("Robinsons", {
 spaceshipId: spaceship.then(it => it.id),
 seats: passengers,
 departure: "Luna",
 destination: "Mars",
 berth: "Colonist",
}];

config = pulumi.Config()
passengers = config.require("passengers")

seats = tyrell.tyrell.PassengerGroup("Robinsons",
 spaceshipId=spaceship.id,
 seats=passengers,
 departure="Luna",
 destination="Mars",
 berth="Colonist",
)

var config = Pulumi.Config();
var passengers = config.require("passengers");

var seats = new Tyrell.Tyrell.PassengerGroup("Robinsons", new Tyrell.Tyrell.PassengerGroupArgs
{
 SpaceshipId = spaceship.id,
 Seats = passengers,
 Departure = "Luna",
 Destination = "Mars",
 Berth = "Colonist",
});

config := pulumi.Config()
passengers := config.require("passengers")

seats, err := tyrell.PassengerGroup("Robinsons", &tyrell.PassengerGroupArgs{
 SpaceshipId: spaceship.id,
 Seats: passengers,
 Departure: "Luna",
 Destination: "Mars",
 Berth: "Colonist",
})

Once a planet is habitable and configured to your specifications, you will need a way to travel to your new home. Simply adding a seats argument to any Rocket will reserve those seats (as they eventually become available).

When your program completes deployment, you will receive a reservation confirmation via the email you used to register for the Pulumi Service. If you are an open source user, you will need to provide a valid email address via the --confirmation-email flag to receive your confirmation email.

Terraforming As Code

One of the most challenging obstacles preventing humans from becoming a multi-planet species is that Earth is the only planet in the known solar system that supports life. While there are many options for making other planets liveable, the team at Pulumi believes in the two step model towards habitability.

First, we need to provision dome-based communities in a repeatable and scalable manner. Once we have established our dome communities, we can then terraform any planet using the latest technology, i.e., nuclear missiles.

Dome-Based Communities

import * as weyland from "@pulumi/weyland-yutani"

const domeId = weyland.dome.getDome({
 owners: ["099720109477"],
 mostRecent: true,
 filters: [{ name: "name", values: ["weyland-yutanu/terraforming/acheron-*"] }],
}).then(it => it.id);

const terradome = weyland.dome,Instance("Hadley's Hope", {
 instanceType: weyland.dome.InstanceType.LV_246,
 dome: domeId,
 type: "atmospheric-processor",
}];

from pulumi_weyland_yutani import dome

dome = dome.get_dome(
 owners=["099720109477"],
 most_recent=true,
 filters="""[
 {name: "BasicDome", values: ["weyland-yutanu/terraforming/acheron-*"]}
 ]""",
)

terradome = dome.Instance("Hadley's Hope",
 instance_type=dome.instance_type.lv_246,
 dome=dome.id,
 type="atmospheric-processor",
)

using Pulumi;
using WeylandYutani = Pulumi.WeylandYutani;

class MyStack : Stack
{
 public MyStack()
 {
 var dome = new WeylandYutani.Dome.GetDome(new WeylandYutani.Dome.GetDomeArgs
 {
 Owners =
 {
 "099720109477",
 }
 MostRecent = true,
 Filters = {
 { "name": "BasicDome", "values": ["weyland-yutanu/terraforming/acheron-*"] },
 }
 });

 var terradome = new WeylandYutani.Dome.Instance("Hadley's Hope", new Weyland.Yutani.Dome.InstanceArgs
 {
 InstanceType = Weyland.Dome.InstanceType.LV_246,
 Dome = dome.Id,
 Type = "atmospheric-processor",
 });
 }

}

package main

import (
 "github.com/pulumi/pulumi-weyland-yutani/sdk/v3/go"
 "github.com/pulumi/pulumi/sdk/v2/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 dome, err := weyland.Dome.GetDome(&weyland.Dome.GetDomeArgs{
 Owners: []string{"099720109477"},
 MostRecent: true,
 Filters: []RocketEngineFilter{
 RocketEngineFilter{
 Name: "BasicDome",
 Values: []string{"weyland-yutanu/terraforming/acheron-*"},
 },
 },
 })
 if err != nil {
 return err
 }

 terradome, err := weyland.Dome.Instance("", &weyland.Dome.InstanceArgs{
 InstanceType: weyland.Dome.InstanceType.LV_246,
 Dome: dome.Id,
 Type: "atmospheric-processor",
 })
 if err != nil {
 return err
 }

 return nil
 })
}

The first step to establish humanity on other planets is to provision dome-based communities and build critical infrastructure and resources while we work to terraform the planet. Out of the box, Pulumi provides boilerplate communities that are flexible and resilient enough to support any use case.

Nuclear Terraforming

While we will not be able to support nuclear terraforming on Day 1, we are working extremely diligently to ensure our customers have access to state of the art terraforming techniques. We hope to bring a preview of Nuclear Terraforming to customers in early Q3 of 2022. Be on the lookout for monthly updates as we develop this new groundbreaking technology.

How To Get Started

Getting started is as simple as getting started with any other Pulumi resource provider, you just need to download the package with your preferred language’s package manager, configure the provider, and then start building. All space resources are billed via Dogecoin, so you will need to provide a wallet address in your provider’s arguments.

$ pulumi config set --secret doge DilB3JrTyGm55FiMyRlhM7NZmfj0J9QVX

Don’t worry, we’ll encrypt your wallet address. Your Dogecoin wallet will go straight to your provider and Pulumi never receives or handles your secrets.

Summary

Today is one of the most exciting days in Pulumi’s short history and we are incredibly excited to partner with our customers and leading space companies to make our multi-planetary dreams a reality. We cannot wait to see what you’ll build!

*{padding:0;margin:0;overflow:hidden}html,body{height:100%}img{position:absolute;width:100%;top:0;bottom:0;margin:auto}" >

Keeping Your Secrets Secret

Sophia Parafina — Tue, 23 Mar 2021 00:00:00 +0000

Companies that have suffered data breaches are, unfortunately, frequently in the news. A data breach is when information that should be private, such as credit card numbers or even trade secrets, is stolen. These thefts can be because of an actual cyber-attack, but they can also be due to simple carelessness, such as disposing of computer equipment without taking proper precautions.

As an example, Bitcoin miners have perpetrated many data breaches. Suppose you accidentally push a dotfile with an aws_access_key_ID to GitHub. Bitcoin miners have a host of tools that automatically scrape GitHub for exactly that sort of information. Once they have your AWS credentials, they lock you out, spin up machines and start mining. This isn’t as common as it once was since cloud providers are better at detecting these sorts of incursions, but you can see how catastrophic (and costly) such a data breach can be.

Of course, you can protect yourself and your company. In this blog post, we’re going to give a quick rundown of some actions you can take to make sure your secrets stay secret.

What Is a Secret?

We’re going to define secrets as small, critical pieces of information. They’re no larger than a few KBs, and they’re necessary to run your infrastructure. If they’re leaked, your infrastructure is compromised and bad things can happen. Some examples of secrets are passwords, API keys, and SSH keys.

Remove All Plaintext Secrets

Step one is to search through your existing codebase and remove any secrets that are in plaintext. A simple approach is to manually grep or search through your files, looking for words such as username and password. However, there are also tools available that will comb through your Git history and commits, looking for sensitive information. Many of these tools are open source.

Build detection into your CI/CD pipeline

Making secrets detection a part of your CI/CD pipeline is a great way to ensure you’re not pushing confidential information to a public repo. There are tools that integrate into your automated workflow. You can configure those tools to stop the pipeline if they detect secrets such as keys or passwords.

Don’t Forget about Git Commits

It’s easy to forget that Git commits can contain sensitive information. For example, someone might talk about a security issue and how they fixed it. Instead, give a link to your ticketing system and document the problem there.

Encrypt and Manage Your Secrets

After you’ve stripped out your plaintext secrets from your codebase, you still need to to store and manage them securely. Encrypting secrets rather than storing them as plaintext is a good start.

Manual encryption

There are command-line tools for encrypting secrets, such as GPG (also called GnuPG) and PGP, which stands for Pretty Good Privacy. These are free, but many people find them difficult to use, and standard security practices such as rotating your keys can be challenging to implement.

Secret servers

There are many servers that store secrets securely available on the market. Secret servers encrypt your secrets and usually have many other features that encourage best security practices, such as access control lists and the ability to audit who’s accessing your keys.

Cloud-provided services

Given that many companies have their infrastructure in the cloud, it makes sense to consider using the secrets services that your cloud provider offers. To mention a few, Google Cloud has Secret Manager, AWS has the AWS Secrets Manager, which relies on the AWS Key Management Service (KMS), and Microsoft Azure has Key Vault. These services have many built-in capabilities that enable you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle.

Have a Plan

Mistakes happen and, even if you’re careful, leaks can occur. It’s important to have a plan already in place if you’ve detected a data breach. Here are some of the things you should do.

Reset passwords and create new keys.
Monitor your systems to find anomalies and unusual usage.
Destroy as many machines as you can and spin up new instances with new credentials.
Keep track of what you’ve done so that you can have a meaningful post-mortem once you’ve put out the fires.

If you haven’t done so already, consider installing intrusion-detection systems. There are many on the market, including open-source tools. There’s no single answer for what to do when leaks happen, but it’s important that all the stakeholders get together and put a process in place.

Practice makes perfect

Once you have a plan, consider staging a data breach and follow that plan to see how well it works. For example, you might simulate a spoofing attack or have someone “steal” a laptop and see how much damage they can do.

Move Security to the Left

Security should be as much a part of your workflow as any other phase of the development process. Just as you start testing your code early to find bugs, you should test early to find security problems. Security shouldn’t come at the end of the development cycle when you think you’re production-ready. Just as with any other problem, security issues are much easier to fix early in development.

Learn More

Pulumi takes security risks seriously. That’s why our platform is secure by default. It protects all secret data using Pulumi’s built-in secret storage, a secret store that “just works.” We also support all the major cloud-provided secret services. Want to learn more? Visit pulumi.com or get started for free today.

Data Science in the Cloud

Sophia Parafina — Thu, 18 Mar 2021 00:00:00 +0000

Data science has advanced because tools like Jupyter Notebook hide complexity by running high level code for the specific problem they are trying to solve. Increasing the level of abstraction lets a data scientist be more productive by reducing the effort to try multiple approaches to near zero, which encourages experimentation and better results.

Data scientists typically work locally, but they often store data for analyses and models in the cloud. There are clear advantages to using cloud resources for these tasks:

Data scientists generally don’t want to manage their storage and databases.
They need to be able to store large data sets cheaply.
They need large capacity swings available on-demand.

SDKs like AWS’ Python library, boto3, can create resources, but they still require domain expertise to manage and properly architect a solution. The Pulumi Automation API improves on raw SDKs by providing high-level abstractions for creating and managing cloud services, letting data scientists concentrate on analyses and models without being well-versed in cloud APIs.

How Pulumi Automation API Improves on Cloud SDKs

Pick any cloud provider, and you will find a cloud SDK in various languages, for example AWS SDKs, Azure SDKs, and Google Cloud SDKs. These SDKs directly access cloud resources, letting data scientists provision resources as required. The drawback to using these libraries is that the data scientist is also responsible for providing resources reliably and securely and performing modeling and analysis.

Pulumi reduces the burden of creating and maintaining repeatable and robust deployments by providing the latest language runtimes, concurrency management, support for diffing updates, and maintaining state with robust checkpoints. Your infrastructure will always be in a well-defined and recoverable state.

Automation API takes this one step further by providing an API overlay to Pulumi’s Infrastructure as Code engine. A data scientist can build infrastructure programmatically within Jupyter to automate building and creating infrastructure as functions and call them as needed. Let’s take a look at an example using a Jupyter notebook.

Infrastructure as a function

As a data scientist, you might want to share data, charts, or graphs with remote team members and make them available through a shared website. You want to keep iterating on your model but don’t want to update the site manually, or worse, let it get out of date.

This example is a simple overview of Automation API that demonstrates a basic deployment of a static website from within a Jupyter notebook. This example uses an inline program to define infrastructure within a function alongside your other code. The function called s3_static_site creates an s3 bucket, sets it up as a basic static website, and exports the URL. This is the equivalent of creating a Pulumi stack using the CLI.

We’ve added code to the example to upload files written to the www directory. Every time you want to update the website, you can write a file to the directory and call the function to upload it to the s3 bucket. Pulumi maintains state, so it will only upload new files when the function is called.

from pulumi_aws import s3

def s3_static_site():
 # Create a bucket and expose a website index document
 site_bucket = s3.Bucket("s3-website-bucket", website=s3.BucketWebsiteArgs(index_document="index.html"))
 index_content = """
 <html>
 <head><title>Hello S3</title><meta charset="UTF-8"></head>
 <body>
 <p>Hello, world!</p>
 <p>Made with ❤️ with <a href="https://pulumi.com">Pulumi</a></p>
 </body>
 </html>
 """

 # Write our index.html into the site bucket
 s3.BucketObject("index",
 bucket=site_bucket.id, # reference to the s3.Bucket object
 content=index_content,
 key="index.html", # set the key of the object
 content_type="text/html; charset=utf-8") # set the MIME type of the file

 # Set the access policy for the bucket so all objects are readable
 s3.BucketPolicy("bucket-policy", bucket=site_bucket.id, policy={
 "Version": "2012-10-17",
 "Statement": {
 "Effect": "Allow",
 "Principal": "*",
 "Action": ["s3:GetObject"],
 # Policy refers to bucket explicitly
 "Resource": [pulumi.Output.concat("arn:aws:s3:::", site_bucket.id, "/*")]
 },
 })

 # Export the website URL
 pulumi.export("website_url", site_bucket.website_endpoint)

We can write additional functions to deploy and destroy the S3 static website. We deploy the stack by calling the deploy_project function and pass it the s3_static_site function, the Pulumi AWS plugin, and the AWS region.

s3_site = deploy_project("my_first_project",
 s3_static_site,
 plugins=[("aws", "v3.23.0")],
 config={"aws:region": auto.ConfigValue(value="us-west-2")})

You can view the resources that the function created in two ways. The standard method is to open the AWS console to see your resources.

You can also view them with the Pulumi Service as a resource graph.

The Pulumi Service also displays updates to the static site and the changes made.

Now that the static site has been deployed, we want to get the site URL. The s3_static_site function exports the website url. Pulumi returns the s3_site as an object with outputs that we use to retrieve the URL. There are several ways to check if the site is working, but a simple way is to open the URL in a web browser.

import webbrowser

outputs = s3_site.outputs()

webbrowser.open(url)

Data Science Your Way

In this simple example, we demonstrated how to create a static website from an S3 bucket, write content into the bucket, and set the access policy as a Python function. We called the function, which created a stack for the website. The stack is returned as a Python object with the site URL as an output. You can manage the site and view updates using the Pulumi Service.

Because it’s code, you can create a separate module containing all the functions to create your infrastructure, import it into your notebooks, and reuse it. Pulumi lets you perform analysis and build models within a familiar environment while reducing the burden of managing infrastructure. You can find the complete example on GitHub including a Jupyter notebook for database migration.

Be sure to watch our video that explains the code in greater detail.

Empower Your Team with Policy as Code

Sophia Parafina — Mon, 08 Mar 2021 18:12:25 -0700

Policies set the guardrails for your applications and infrastructure. They define many aspects of how your company manages its applications and infrastructure. Security, safe use of resources, and compliance with external standards are just a few examples of what a policy can define.

Historically, policies were written and enforced by compliance and security teams who set down the rules as text documents. More recently, teams often use a cloud provider’s GUI to set policies. Both of these approaches are error-prone and far too slow to keep up with complex, rapidly changing infrastructure and automated systems. They also can’t take advantage of the accepted best practices for software development.

Instead, just as you define infrastructure as code, so too should you define policies as code.

What Do You Gain with Policy as Code?

The short answer to this question is that you can apply software engineering principles and approaches to your policies, just as you do with your applications and with infrastructure as code. Here are some of the specific benefits:

Clarity

Policies written as code are unambiguous pieces of logic. They can be read both by humans and by machines. There’s no way to misinterpret them, which is a real problem with text documents.

Version control

When policies are described as code, they can be checked into source control, versioned, and code-reviewed. They become a part of your automated pipelines.

Testing

As any critical system grows in complexity, people can start to feel nervous about making changes. When policies are written as code, they can be tested, just as you test your applications and infrastructure. You can integrate your policies into your automated testing system as easily as any other code you write.

Familiar tools such as IDEs

When policy is code, you can use familiar tools, such as the IDEs you use to write other pieces of code to develop new policies, refactor existing policies, and catch errors early.

Automation

As we mentioned, policy as code can be sent through your automated CI/CD pipelines for fast testing and deployment. For most companies, their infrastructure has become too large and complex to use manual procedures such as documents and GUIs to make changes.

Common Use Cases

Policies can encompass many areas. Here are just a few.

Authorization control. You can implement fine-grained access control for applications. For example, a service can make an API call to a policy engine to determine whether a request is authorized or not.
Infrastructure provisioning. You can create policies that require tagging, provisioning certain types of resources, and secure network settings.
Kubernetes control. You can manage Kubernetes resources such as pods, namespaces, and nodes. You can ensure container images come from trusted registries.
Cost control. One way to control your cloud costs is to set policies based on pricing. You can calculate the cost of a resource ahead of time and create a policy limiting the amount you spend to deploy it. For an example of how tagging on AWS can control costs, take a look at Automatically Enforcing AWS Resource Tagging Policies.

There can be many other uses. Use your imagination. Another benefit of policy as code is that it makes experimentation easy.

Learn More

Ready to learn more? With Pulumi, you can create and manage infrastructure and policies with the languages and tools you already know. To help you implement policy as code, check out this CrossGuard, our product that uses policies to enforce gated deployments. With it, administrators can apply policies to particular stacks. Any violation will gate or block an update from proceeding. Give Pulumi a try and get started for free today.

Automate Your Infrastructure with Automation API and C#

Joshua Studt — Mon, 08 Mar 2021 00:00:00 +0000

Joshua Studt is a Solutions Architect at Financial Independence Group and a Pulumi Community member who contributed the C# package for Automation API.

Currently available in public preview, Pulumi’s Automation API enables you to provision your infrastructure programmatically using the Pulumi engine. Today, we are excited to announce C# support for Automation API, enabling .NET developers to automate infrastructure deployments, create complex orchestration workflows, build custom ops tooling, and build cloud frameworks. Read more about the Automation API here.

Using Automation API in .NET

The Pulumi.Automation NuGet package exposes a LocalWorkspace for creating and managing Pulumi Stacks, and a WorkspaceStack that is a programmatic representation of a Stack for updating, refreshing, previewing, and destroying cloud resources. The Automation API makes it trivial to run Pulumi programs inline:

var program = PulumiFn.Create(() =>
{
 var bucket = new Pulumi.Aws.S3.Bucket("s3-website-bucket");

 return new Dictionary<string, object?>
 {
 ["bucket_name"] = bucket.BucketName,
 };
});

var stackArgs = new InlineProgramArgs("projectName", "stackName", program);
using var stack = await LocalWorkspace.CreateOrSelectStackAsync(stackArgs);

await stack.Workspace.InstallPluginAsync("aws", "v3.30.1");
var result = await stack.UpAsync();
var bucketName = result.Outputs["bucket_name"];

You can use your existing Pulumi projects and invoke them from the Automation API:

var stackArgs = new LocalProgramArgs("stackName", "C:\path\to\pulumi\project\dir");
using var stack = await LocalWorkspace.CreateOrSelectStackAsync(stackArgs);

await stack.UpAsync();

Since the Automation API can be invoked and debugged like any other code, it enables you to put together complex deployment workflows such as a blue-green deployment model:

using var workspace = await LocalWorkspace.CreateAsync(new LocalWorkspaceOptions
{
 Program = PulumiFn.Create<ApplicationStack>(), // use your existing Pulumi.Stack implementation
 ProjectSettings = new ProjectSettings("projectName", ProjectRuntimeName.Dotnet),
});

// your "blue" production code is already running

var green = await WorkspaceStack.SelectAsync("green", workspace);
await green.UpAsync();

// do your cutover to "green" logic
// and then teardown "blue"

var blue = await WorkspaceStack.SelectAsync("blue", workspace);
await blue.DestroyAsync();

See full Automation API examples in C#. Let us know if you’re using Automation API on Twitter or in our Community Slack.

How to Build a Container Registry

Sophia Parafina — Tue, 16 Feb 2021 00:00:00 +0000

Whether you are working with Kubernetes or serverless, your application uses containers. If you use the Docker desktop client, images are pushed to Docker Hub by default. Pulling images from Docker Hub is convenient, but there are many reasons to store images in your own registry. For example, Docker Hub doesn’t guarantee to produce the same image on repeated pulls, i.e., your base image might have changed. It’s also possible to inadvertently expose secrets in an intermediate image used to build the image stored on Docker Hub. There is also the possibility of vulnerabilities in even official images. This article shows how to create a repository and how to build and push images to that repository

Container registry offerings

AWS provides the Elastic Container Registry (ECR), Azure has Container Registry, and Google has it’s Container Registry. Each provider has associated services unique to their offering, but all support Docker or OCI compliant images.

Build it

Let’s examine how to create a registry with the provider of your choice. In these examples, we create a registry, build a Docker image, and push the image to the registry. The application used for the image is NGINX.

Choose your cloud provider to learn how to build a registry.

In this example, we create an ECR repository configured to scan an image’s Operating System components. Scanning for vulnerabilities in an application is currently out of scope. We also set a policy for the repository that controls the actions allowed and a lifecycle policy that expires an image after a set time.

With Pulumi, it’s possible to build an image locally using Docker and push it to your repository. To push the image, we obtain the credentials required to push from the registry. Finally, we export the credentials and the URL for the registry. Read more about ECR in the API Reference.

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

// Create a repository and configure to scan the image on push
const repo = new aws.ecr.Repository("myrepository", {
 imageScanningConfiguration: {
 scanOnPush: true
 },
 imageTagMutability: "MUTABLE",
});

// Set a use policy for the repository
const repositoryPolicy = new aws.ecr.RepositoryPolicy("myrepositorypolicy", {
 repository: repo.id,
 policy: JSON.stringify({
 Version: "2012-10-17",
 Statement: [{
 Sid: "new policy",
 Effect: "Allow",
 Principal: "*",
 Action: [
 "ecr:GetDownloadUrlForLayer",
 "ecr:BatchGetImage",
 "ecr:BatchCheckLayerAvailability",
 "ecr:PutImage",
 "ecr:InitiateLayerUpload",
 "ecr:UploadLayerPart",
 "ecr:CompleteLayerUpload",
 "ecr:DescribeRepositories",
 "ecr:GetRepositoryPolicy",
 "ecr:ListImages",
 "ecr:DeleteRepository",
 "ecr:BatchDeleteImage",
 "ecr:SetRepositoryPolicy",
 "ecr:DeleteRepositoryPolicy"
 ]
 }]
 })
});

// Set a policy to control the lifecycle of an image
const lifecyclePolicy = new aws.ecr.LifecyclePolicy("mylifecyclepolicy", {
 repository: repo.id,
 policy: JSON.stringify({
 rules: [{
 rulePriority: 1,
 description: "Expire images older than 14 days",
 selection: {
 tagStatus: "untagged",
 countType: "sinceImagePushed",
 countUnit: "days",
 countNumber: 14
 },
 action: {
 type: "expire"
 }
 }]
 })
});

// Get the repository credentials we use to push to the repository
const repoCreds = repo.registryId.apply(async (registryId) => {
 const credentials = await aws.ecr.getCredentials({
 registryId: registryId,
 });
 const decodedCredentials = Buffer.from(credentials.authorizationToken, "base64").toString();
 const [username, password] = decodedCredentials.split(":");
 return { server: credentials.proxyEndpoint, username, password };
});

// Create a new image and push to the repository
const image = new docker.Image("myapp", {
 imageName: repo.repositoryUrl,
 build: "./app",
 registry: repoCreds,
})

// Export credentials and URL to the repository
export const credentials = repoCreds;
export const repoEndpoint = repo.repositoryUrl;

In this example, we create an Azure Resource Group to contain the resources for the registry, such as the App Service that hosts the registry.

We instantiate a registry with the containerservice module and use the Image module in the Docker package to build and push the image to the registry. We export the registry URL and the username and password in case we should want to push or pull and image using the Docker CLI.

import * as azure from "@pulumi/azure";
import * as docker from "@pulumi/docker";
import * as pulumi from "@pulumi/pulumi";

// Create an Azure Resource Group
const resourceGroup = new azure.core.ResourceGroup("examples");

// Create a dedicated App Service Plan for Linux App Services
const plan = new azure.appservice.Plan("linux-apps", {
 resourceGroupName: resourceGroup.name,
 kind: "Linux",
 reserved: true,
 sku: {
 tier: "Basic",
 size: "B1",
 },
});

const repo = new azure.containerservice.Registry("myrepository", {
 resourceGroupName: resourceGroup.name,
 sku: "Basic",
 adminEnabled: true,
});

const myImage = new docker.Image("myapp", {
 imageName: pulumi.interpolate`${repo.loginServer}/${"myapp"}:v1.0.0`,
 build: {
 context: `./${"app"}`,
 },
 registry: {
 server: repo.loginServer,
 username: repo.adminUsername,
 password: repo.adminPassword,
 },
});

export const server = repo.loginServer;
export const username = repo.adminUsername;
export const password = repo.adminPassword;

In this example, we’ll use the configuration and credentials from the gcloud CLI to build an image and push it into the GCP registry. Make sure the GCP project is set and you are logged into GCP and Docker is configured to use the GCR,

$ gcloud init
$ gcloud auth login
$ gcloud auth configure-docker

We use the Image module in the Docker package to build and push the image to the registry. We export the registry URL and the username and password in case we should want to push or pull an image using the Docker CLI.

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

// Build and push image to gcr repository

const imageName = "myapp";

const myImage = new docker.Image(imageName, {
 imageName: pulumi.interpolate`gcr.io/${gcp.config.project}/${imageName}:latest`,
 build: {
 context: "./app",
 },
});

// Export the repository end point
export const repoEndpoint = pulumi.interpolate`gcr.io/${gcp.config.project}`;

Learn more

Container registries are just one of the many resources used for deploying modern applications. Implementations among cloud service providers differ by the functionality they offer and how they are deployed. The commonality among them is that they provide a secure place to store and retrieve Docker or OCI compliant container images. Explore how to create and manage resources for the cloud service provider of your choice with Pulumi. Great places to start are:

Automate Your Infrastructure with Automation API and Python

Sophia Parafina — Tue, 09 Feb 2021 00:00:00 +0000

General-purpose languages enable Infrastructure as Software – bringing tested toolchains and best practices to building infrastructure, e.g., languages, IDEs, testing, debugging, componentization, packaging, and versioning. Available in public preview, Pulumi’s Automation API is a robust programmatic layer on top of Pulumi’s infrastructure engine. It exposes Pulumi programs and stacks as strongly-typed and composable building blocks. Automation API allows you to embed the Pulumi engine inside your software projects so you can build software automation around entire infrastructure provisioning processes that normally require humans to operate.

Today, we are excited to announce Python support for this powerful feature, opening up a world of possibilities for Python developers.

Enabling Cloud Engineering

The Automation API is a subpackage in Pulumi’s language-specific SDKs that provides a programmable interface for creating and managing Stacks and performing infrastructure updates, refresh, previews, and destroy. You can define a Pulumi program as a function within your codebase and use methods to get and set configuration parameters programmatically. The Automation API uses a gRPC interface to execute programs that control and communicate with the core Pulumi engine.

To use Automation API, install the Pulumi CLI, which bundles and distributes the core engine. Today it’s available for Python, TypeScript/JavaScript and Go, with support for C# under active development.

Automation Use Cases

Let’s look at two use cases where Pulumi customers are applying the Automation API:

Platform APIs

Deploying infrastructure with shell scripts for online services creates operational challenges with observability and reliability, especially for SaaS scenarios. Automation API is just another package and can be instrumented, profiled, and monitored with your existing APM tools like Honeycomb, Prometheus, and Datadog.

Automation API runs inside your favorite frameworks and interacts with your other packages precisely as you’d expect. We can define custom declarative infrastructure and expose it to end-users behind a familiar REST interface, as in this example, that creates an S3 website with a POST request.

# an HTTP handler to create instances of our declarative infra
# each request creates an S3-backed static website with dynamic content from the POST body
@app.route("/sites", methods=["POST"])
def create_handler():
 """creates new sites"""
 stack_name = request.json.get('id')
 content = request.json.get('content')
 try:
 def pulumi_program():
 return create_pulumi_program(content)
 # create a new stack, generating our pulumi program on the fly from the POST body
 stack = auto.create_stack(stack_name=stack_name,
 project_name=project_name,
 program=pulumi_program)
 stack.set_config("aws:region", auto.ConfigValue("us-west-2"))
 # deploy the stack, tailing the logs to stdout
 up_res = stack.up(on_output=print)
 return jsonify(id=stack_name, url=up_res.outputs['website_url'].value)
 except auto.StackAlreadyExistsError:
 return make_response(f"stack '{stack_name}' already exists", 409)
 except Exception as exn:
 return make_response(str(exn), 500)

The handlers work with your favorite HTTP frameworks, including flask:

import Flask

# install necessary plugins once upon boot
ensure_plugins()

# initialize our Flask app
app = Flask(__name__)

# set up our routes
@app.route("/sites", methods=["POST"])
def create_handler():
 ...

@app.route("/sites", methods=["GET"])
def list_handler():
 ...

@app.route("/sites/<string:id>", methods=["GET"])
def get_handler(id: str):
 ...

@app.route("/sites/<string:id>", methods=["UPDATE"])
def update_handler(id: str):
 ...

@app.route("/sites/<string:id>", methods=["DELETE"])
def delete_handler(id: str):
 ...

Check out the full Pulumi over HTTP example in Python.

Complex Workflow Orchestration

The Automation API executes just like any other code in your application, meaning that a single process can deploy infrastructure and manage related activities such as database migrations and blue/green deployments.

In this example, we define an AWS RDS database:

cluster_instance = aws.rds.ClusterInstance(
 "db_instance",
 cluster_identifier=cluster.cluster_identifier,
 instance_class=aws.rds.InstanceType.T3_SMALL,
 engine=aws.rds.EngineType.AURORA_MYSQL,
 engine_version="5.7.mysql_aurora.2.03.2",
 publicly_accessible=True,
 db_subnet_group_name=subnet_group.name
)

pulumi.export("host", cluster.endpoint)
pulumi.export("db_name", db_name)
pulumi.export("db_user", db_user)
pulumi.export("db_pass", db_pass)

With Automation API, we can perform database migrations and preload rows in the same program:

# create (or select if one already exists) a stack that uses our inline program
stack = auto.create_or_select_stack(stack_name=stack_name,
 project_name=project_name,
 program=pulumi_program)

up_res = stack.up(on_output=print)
print(f"db host url: {up_res.outputs['host'].value}")

print("configuring db...")
with connect(
 host=up_res.outputs['host'].value,
 user=up_res.outputs['db_user'].value,
 password=up_res.outputs['db_pass'].value,
 database=up_res.outputs['db_name'].value) as connection:
 print("db configured!")

 # make sure the table exists
 print("creating table...")
 create_table_query = """CREATE TABLE IF NOT EXISTS hello_pulumi(
 id int(9) NOT NULL PRIMARY KEY,
 color varchar(14) NOT NULL);
 """
 with connection.cursor() as cursor:
 cursor.execute(create_table_query)
 connection.commit()

See the full database deployment and migration Automation API program in Python.

Automation API Resources

To get started with Automation API check out these links and watch our video.

Automation API is still in alpha. We maintain a list of known issues. Please file more as you find them!

🏭 🏭 🏭 Happy automating! 🏭 🏭 🏭

Building a Development Environment for Cloud Engineering

Sophia Parafina — Wed, 03 Feb 2021 00:00:00 +0000

Starting can be daunting. Before you take your first step, there’s a lot to consider, but you can prepare your development environment ahead of time to make your first steps in cloud engineering smooth and productive. In this article, we’ll cover how to set up your development environment to work across cloud providers, multiple languages, and different operating systems.

Building your toolbox

You might have heard of the French culinary term “mise-en-place,” which means laying out all the ingredients and cookware before starting to cook. That’s what we’re going to do here; layout all the accounts, authorizations, and software that you need to be a successful cloud engineer. We are going to need the following:

A package manager: Every operating system has a package manager for installing software. Unlike binary installers, a package manager lets you manage all software packages, including updates. Package managers can help resolve dependencies, saving you from frustration.
Cloud provider accounts: You can choose to set up one or multiple accounts. The important thing is how to configure credentials in your development environment,
Programming languages: You can choose one or many, but they all have different versions and dependencies.
Code editor: This is personal preference but make sure that it can perform code completion, error checking, and use enums. These features can be the difference between hitting Tab and searching through online documentation for a function.
Pulumi: You can install Pulumi with a package manager and configure

Decisions

Before proceeding, you need to answer three questions:

Which operating system to use for building cloud resources: macOS, Windows, or Linux?
Which cloud provider are you using? This guide covers AWS, Azure, and Google Cloud.
Which programming language will you use? Pulumi supports Node.js (JavaScript and Typescript), Python 3.7 or higher, Golang, and .NET (C#, F#, and VB).

Once you’ve made these choices, you can follow this guide in a choose-your-own-adventure style.

Package manager

Let’s start with the package manager. We’ll use it to install and manage all the software we need, including cloud provider CLIs, programming languages, editors, and Pulumi. Choose your operating system below.

Homebrew is the most popular package manager for macOS. The Command Line Tools (CLT) for XCode is required to install and build Homebrew. Install the XCode Tools first, then install Homebrew from the command line.

$ xcode-select --install
$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

If you are uncomfortable with downloading and running an online shell script (with good reason), Homebrew provides an alternate installation method.

Chocolatey is a popular package manager for Windows. It should be installed using an administrative shell.

Make sure that Get-ExecutionPolicy is not restricted.

> Get-ExecutionPolicy

If the command returns Restricted, we can use Bypass to install Chocolatey with the following command:

> Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

To check if it’s installed type:

> choco

Linux distributions include a package manager, apt for Debian based distributions or yum for Red Hat-based Linux systems. However, they are primarily used for application and system management.

Homebrew is a popular package manager for utilities, Software Development Kits, and programming tools. Install Homebrew from the command line.

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

To add Homebrew to your PATH and your bash shell profile script (~/.profile on Debian or ~/.bash_profile on Red Hat), follow the Next steps instructions to install and configure brew. To check if it’s installed, install a package;

$ brew install hello

Setting up a cloud account

The first task is signing up for an account. Once you have that out of the way, the next steps are installing the CLI and configuring your credentials.

macOS

We’ll use brew to install AWS CLI version 2 and verify if it’s installed by checking the version.

$ brew update && brew install awscli
$ aws --version

The next step is to create and download your AWS access keys and configure your environment to make them available to both the AWS CLI. To create your access keys, follow these directions for programmatic access.

Pulumi uses the AWS SDK to authenticate requests. Your AWS access keys are never sent to pulumi.com.

To configure the AWS CLI with your credentials, use aws configure:

$ aws configure
AWS Access Key ID [None]: <YOUR_ACCESS_KEY_ID>
AWS Secret Access Key [None]: <YOUR_SECRET_ACCESS_KEY>
Default region name [None]:
Default output format [None]:

This creates a ~/.aws/credentials file used by the AWS CLI to authenticate requests.

We’ll use brew to install Azure CLI and check if it’s installed.

$ brew update && brew install azure-cli
$ az --version

To log into Azure, run the `login` command, which opens a browser to log into [Azure](https://login.microsoftonline.com/common/oauth2/authorize).

```bash
$ az login
The default web browser has been opened at https://login.microsoftonline.com/common/oauth2/authorize. Please continue the login in the web browser. If no web browser is available or if the web browser fails to open, use device code flow with `az login --use-device-code`.
You have logged in. Now let us find all the subscriptions to which you have access...

The Azure client is authenticated and ready to use.

Pulumi uses the Azure SDK to authenticate requests. Your AWS access keys are never sent to pulumi.com.

We’ll use brew to install the Google Cloud SDK and CLI.

$ brew update && brew install --cask google-cloud-sdk
Update done!
==> Source [/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/completion.bash.inc] in your profile to enable shell command completion for gcloud.
==> Source [/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.bash.inc] in your profile to add the Google Cloud SDK command line tools to your $PATH.

Add the gcloud SDK to $PATH in you ~/.bash_profile

source /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/completion.bash.inc
source /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.bash.inc

Open a new shell or source ~/.profile for Debian or ~/.bash_profile for Red Hat and check to see if it’s installed and pathed.

$ source ~/.bash_profile
$ gcloud version
Google Cloud SDK 325.0.0
bq 2.0.64
core 2021.01.22
gsutil 4.58

Authenticate using the gcloud CLI.

gcloud init

Pulumi uses the Google Cloud SDK to authenticate requests. Your AWS access keys are never sent to pulumi.com.

Windows

We’ll use chocolatey to install AWS CLI version 2 and check if it’s installed. Open a cmd Command Prompt as Administrator:

> choco install awscli
> aws --version

The install adds the AWS CLI client to the $PATH, so either open a new cmd window or use the refreshenv command to update the window’s environment variables and use the AWS CLI.

Pulumi uses the AWS SDK to authenticate requests. Your AWS access keys are never sent to pulumi.com.

To configure the AWS CLI with your credentials, use aws configure:

> aws configure
AWS Access Key ID [None]: <YOUR_ACCESS_KEY_ID>
AWS Secret Access Key [None]: <YOUR_SECRET_ACCESS_KEY>
Default region name [None]:
Default output format [None]:

This will create the ~/.aws/credentials file used by the AWS CLI to authenticate requests.

We’ll use chocolatey to install Azure CLI and check if it’s installed. Open a cmd Command Prompt as Administrator:

> choco install azure-cli

The Azure CLI client was added to the path, so either open a new cmd window or use the refreshenv command to update the window’s environment variables. To log into Azure, run the login command, which opens a browser to log into Azure.

> refreshenv
> az login

The Azure client will open a browser window and prompt you to sign-in to your account. Once signed-in, the Azure CLI is authenticated and ready to use.

Pulumi uses the Azure SDK to authenticate requests. Your AWS access keys are never sent to pulumi.com.

We’ll use chocolatey to install the Google Cloud SDK and CLI.

> choco install gcloudsdk --ignore-checksums

The gcloud CLI was added to the path, so either open a new cmd window or use the refreshenv command to update the window’s environment variables. Check to see if gcloud CLI is installed and pathed correctly.

> refreshenv
> gcloud version
Google Cloud SDK 325.0.0
bq 2.0.64
core 2021.01.22
gsutil 4.58

Authenticate using the gcloud CLI

> gcloud init
Welcome! This command will take you through the configuration of gcloud.

Your current configuration has been set to: [default]

You can skip diagnostics next time by using the following flag:
 gcloud init --skip-diagnostics

Network diagnostic detects and fixes local network connection issues.
Checking network connection...done.
Reachability Check passed.
Network diagnostic passed (1/1 checks passed).

You must log in to continue. Would you like to log in (Y/n)? Y

Your browser has been opened to visit:
 https://accounts.google.com/o/oauth2/...

A browser window will open to authenticate your client.

Pulumi uses the Google Cloud SDK to authenticate requests. Your AWS access keys are never sent to pulumi.com.

Linux

We’ll use brew to install AWS CLI version 2 and check if it’s installed.

$ brew update && brew install awscli
$ aws --version

Pulumi uses the AWS SDK to authenticate requests. Your AWS access keys are never sent to pulumi.com.

To configure the AWS CLI with your credentials, use aws configure:

$ aws configure
AWS Access Key ID [None]: <YOUR_ACCESS_KEY_ID>
AWS Secret Access Key [None]: <YOUR_SECRET_ACCESS_KEY>
Default region name [None]:
Default output format [None]:

This will create the ~/.aws/credentials file used by the AWS CLI to authenticate requests.

We’ll use brew to install Azure CLI and check if it’s installed.

$ brew update && brew install azure-cli
$ az --version

To log into Azure, run the `login` command, which opens a browser to log into [Azure](https://login.microsoftonline.com/common/oauth2/authorize).

```bash
$ az login
The default web browser has been opened at https://login.microsoftonline.com/common/oauth2/authorize. Please continue the login in the web browser. If no web browser is available or if the web browser fails to open, use device code flow with `az login --use-device-code`.
You have logged in. Now let us find all the subscriptions to which you have access...

The Azure client is authenticated and ready to use.

Pulumi uses the Azure SDK to authenticate requests. Your AWS access keys are never sent to pulumi.com.

We’ll use brew to install the Google Cloud SDK and CLI.

$ brew update && brew install --cask google-cloud-sdk

Update done!

==> Source [/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/completion.bash.inc] in your profile to enable shell command completion for gcloud.
==> Source [/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.bash.inc] in your profile to add the Google Cloud SDK command line tools to your $PATH.

Add the gcloud SDK to $PATH to your ~/.bash_profile or ~/.profile.

source /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/completion.bash.inc
source /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.bash.inc

Open a new shell or source ~/.profile for Debian or ~/.bash_profile for Red Hat and check to see if it’s installed and pathed.

$ source ~/.bash_profile
$ gcloud version
Google Cloud SDK 325.0.0
bq 2.0.64
core 2021.01.22
gsutil 4.58

Authenticate using the gcloud CLI

gcloud init

Pulumi uses the Google Cloud SDK to authenticate requests. Your AWS access keys are never sent to pulumi.com.

Choose a Programming Language

Pulumi supports Node.js (JavaScript and Typescript), Python 3, Golang, and .NET Core (C#, VB, and F#) languages.

Node.js

Use brew to install Node.js for JavaScript and Typescript.

$ brew install node

Use chocolatey to install Node.js for JavaScript and Typescript.

> choco install nodejs

Use brew to install Node.js for JavaScript and Typescript.

$ brew install node

Python

MacOS includes Python; however, versions shipped before December 2019 have Python 2.7 installed, which is deprecated. Pulumi requires Python 3.7 or higher. Use brew to install Python, which installs it at /usr/bin/local/python3.

$ brew install python

In macOS versions with Python 2 installed, calling python uses the 2.7 binary. To ensure that you will always use Python 3, you can add an alias to your .bash_profile.

alias python=/usr/local/bin/python3

It is a best practice to create a virtual environment and activate it for a Python project. Pulumi creates a new venv environment when you start a new Project with pulumi new.

You can install Python in several ways, including typing ‘python` in the command prompt, which brings up the Microsoft Store application. In this article, we’ll continue using chocolatey to install Python 3.

> choco install python --pre

It is a best practice to create a virtual environment and activate it for a Python project. Pulumi creates a new venv environment when you start a new Project with pulumi new.

Use brew to install Python3.

$ brew install python

Use python3 to call Python, but you can add an alias to your .bash_profile or .profile to use just python to run scripts.

alias python=/usr/local/bin/python3

It is a best practice to create a virtual environment and activate it for a Python project. Pulumi creates a new venv environment when you start a new Project with pulumi new.

Golang

Use brew to install golang.

$ brew install golang

It is a best practice to create a local programming environment and set GOPATH as an environment variable, although it is not required for golang versions after 1.8. Pulumi creates a new local environment and go.mod to work with modules each time you start a new Project with pulumi new.

Use chocolatey to install golang.

> choco install golang

It is a best practice to create a local programming environment and set GOPATH as an environment variable, although it is not required for golang versions after 1.16. Pulumi creates a new local environment and go.mod to work with modules each time you start a new Project with pulumi new.

Use brew to install golang.

$ brew install golang

.NET

Install .NET with brew, Pulumi requires .NET Core 3.1 or higher.

$ brew install dotnet

Install .NET with chocolatey. Pulumi requires .NET Core 3.1 or higher.

> choco install dotnet-sdk

Install .NET with brew, Pulumi requires .NET Core 3.1 or higher.

$ brew install dotnet

Get a code editor

While knowing how to use vim or similar text editors is a worthwhile skill, you should use a modern code editor. Here’s a non-exhaustive list why you should use a code editor.

Quickly navigating to a type
Autocompletion when you can’t remember the names of all members by heart
Automatic code generation
Refactoring
Organise imports
Warnings as you type.
Hovering over something to see the docs
Keeping a view of files, errors/warnings/console/unit-tests and source code on the screen
Running unit tests from the same window
Integrated debugging
Integrated source control
Navigating to where a compile-time error or run-time exception occurred directly from the error details.

You can use an IDE (Integrated Development Environment) such as Microsoft Visual Studio, Xcode, or any one of JetBrains’ language-specific IDEs. Alternatively, you can use a lightweight solution with many of the features of an IDE. Popular code editors include Visual Studio Code, Sublime Text, and Atom.

You can install some editors with brew.

$ brew install --cask visual-studio-code
$ brew install --cask sublime-text
$ brew install --cask atom
$ brew install --cask pycharm-ce
$ brew install --cask goland

Install Pulumi

macOS Ventura (13) or later is required.

Homebrew

You can install Pulumi through the Homebrew package manager:

$ brew install pulumi/tap/pulumi

This will install the pulumi CLI to the usual place (often /usr/local/bin/pulumi) and add it to your path.

Subsequent updates can be installed in the usual way:

$ brew upgrade pulumi

Installation Script

To install, run our installation script:

$ curl -fsSL https://get.pulumi.com | sh

This will install the pulumi CLI to ~/.pulumi/bin and add it to your path. When it can’t automatically add pulumi to your path, you will be prompted to add it manually. See How to permanently set $PATH on Unix for guidance.

Windows 8 and 10 are supported.

Chocolatey

You can install Pulumi using elevated permissions through the Chocolatey package manager:

> choco install pulumi

This will install the pulumi CLI to the usual place (often $($env:ChocolateyInstall)\lib\pulumi) and generate the shims (usually $($env:ChocolateyInstall)\bin) to add Pulumi your path.

Subsequent updates can be installed in the usual way:

> choco upgrade pulumi

Verifying your Installation

After installing Pulumi, verify everything is in working order by running the pulumi CLI:

$ pulumi version
v3.255.0

$ pulumi version
v3.255.0

> pulumi version
v3.255.0

Next steps

Congratulations! You have a fully configured environment, and you’re ready to jump into cloud engineering. You can maintain your development environment using the package manager to add or update your toolset. Your code editor provides a modern development platform that takes advantage of all the advances in software engineering. Your coding experience will be more productive and less frustrating.

What are the next steps? Begin with Pulumi’s Getting Started. You can skip the configuration sections and jump straight into your first project. Once you’re done with your first project, try out example projects on Github. You can start with simple projects using the pulumi CLI, such as deploying a web server on AWS with python.

$ pulumi new https://github.com/pulumi/examples/tree/master/aws-py-webserver

This command will download the project from Github, create a virtual environment and activate it, and download all the python package dependencies. You’re ready to go and deploy with pulumi up. Want more? How about deploying Kubernetes on Azure with python?

$ pulumi new https://github.com/pulumi/examples/tree/master/azure-py-aks

You can use the examples as a starting point for building your cloud infrastructure and add resources documented on Pulumi’s Registry and Guides.

Reduce Cloud Costs with EC2 ARM Instances

Sophia Parafina — Tue, 26 Jan 2021 00:00:00 +0000

Whether you’re migrating to the cloud or have existing infrastructure, cloud spend can be a significant barrier to your success. Too small of a budget could prevent your organization from meeting your performance metrics. You can use different strategies to reduce cloud spend, such as using Spot Instances, which cost less than On-Demand Instances or scaling your infrastructure based on peak usage times.

With the addition of Graviton2 based EC2 Instances, AWS offers an on-demand alternative for decreasing cloud spend. Both Amazon and independent testing demonstrated that the general-purpose M6g instance delivered up to a 40% gain of price/performance compared to Intel m5.large instances. In addition to the M6g general-purpose instance, AWS offers instances general-purpose burstable (T4g), compute-optimized (C6g), and memory-optimized (R6g) EC2 instances.

Deploying Infrastructure with ARM

Building infrastructure with ARM instances is straightforward. You can reuse code and substitute ARM instances and containers for Intel-based components. Check out this example that deploys a VPC with EC2 container instances. To get started, you can clone the repository with the Pulumi CLI.

$ pulumi new https://github.com/pulumi/examples/tree/master/aws-py-ecs-instances-autoapi/py-ecs-instance

This command will walk you through creating a new Pulumi project.

Enter a value or leave blank to accept the (default), and press <ENTER>.
Press ^C at any time to quit.

project name: (aws-py-ecs-instances-autoapi)
project description: (A container running in AWS ECS Container Instance, using Python infrastructure as code)
Created project 'aws-py-ecs-instances-autoapi'

Please enter your desired stack name.
To create a stack in an organization, use the format <org-name>/<stack-name> (e.g. `acmecorp/dev`).
stack name: (dev)
Created stack 'dev'

Creating virtual environment...
Finished creating virtual environment
Updating pip, setuptools, and wheel in virtual environment...
…
Successfully installed arpeggio-1.10.1 attrs-20.3.0 dill-0.3.3 grpcio-1.35.0 parver-0.3.1 protobuf-3.14.0 pulumi-2.18.1 pulumi-aws-3.24.0 pyyaml-5.4.1 semver-2.13.0 six-1.15.0
Finished installing dependencies
Your new project is ready to go! ✨

To perform an initial deployment, run 'pulumi up'

Because this example is written in Python, the CLI will automatically configure your virtual environment and install the Python packages listed in requirements.txt. You can now edit main.py to use the M6g instance and an ARM version of the nginx container. Dockerhub has many ARM images for popular applications, as well as for base images. We’ll use the arm64v8/nginx image in this example.

Edit this parts of main.py to use an ARM AMI

# Find an "ECS optimized" AMI to use for the EC2 container instances.
ecs_instance_ami = aws.get_ami(
 most_recent="true",
 owners=["amazon"],
 filters=[
 {
 "name": "name",
 "values": ["amzn2-ami-ecs-hvm-*-arm64-*"]
 }
 ]
)

and this part to specify the instance type:

# create launch configuration
launch_config = aws.ec2.LaunchConfiguration(
 "launch-config",
 image_id=ecs_instance_ami.id,
 instance_type="m6g.medium",
 iam_instance_profile=ecs_instance_profile.name, # needed to give instance authority to join the ECS cluster.
 user_data=user_data, # Required so instance knows to connect to the cluster created below.
)

Finally, replace the image with the ARM image from Dockerhub:

# Task definition for creating our containers.
task_def = aws.ecs.TaskDefinition(
 "my-app",
 family="ec2-task-definition",
 cpu="256",
 memory="512",
 network_mode="awsvpc",
 requires_compatibilities=["EC2"],
 execution_role_arn=task_execution_role.arn, # Needed so it has permission to launch tasks on the cluster.
 container_definitions=json.dumps([{
 "name": "my-app",
 "image": "arm64v8/nginx", # a simple nginx example
 "portMappings": [{
 "containerPort": 80,
 "hostPort": 80,
 "protocol": "tcp"
 }]
 }]),
 opts=pulumi.ResourceOptions(depends_on=[cluster])
)

Save your changes, and we’re ready to go to the next step.

Before spinning up our example, we need to set the AWS region we want to use and the autoscalingGroupSize to limit the number of instances.

$ pulumi config set aws:region us-west-2
$ pulumi config set cfg:autoscalingGroupSize 1

Once those are configured, run pulumi up to bring up your infrastructure. You’ll see similar output, including the URL for your deployment.

View Live: https://app.pulumi.com/spara/aws-py-ecs-instances-autoapi/dev/updates/1

 Type Name Status
 + pulumi:pulumi:Stack aws-py-ecs-instances-autoapi-dev created
 + ├─ aws:iam:Role task-execution-role created
 + ├─ aws:ec2:SecurityGroup nginx-sg created
 + ├─ aws:iam:Role ecs-instance-role created
 + ├─ aws:lb:TargetGroup app-tg created
 + ├─ aws:iam:RolePolicyAttachment task-excution-policy-attach created
 + ├─ aws:iam:RolePolicyAttachment ecs-instance-policy-attach created
 + ├─ aws:iam:InstanceProfile ecs-iam-instance-profile created
 + ├─ aws:ec2:LaunchConfiguration launch-config created
 + ├─ aws:lb:LoadBalancer load-balancer created
 + ├─ aws:autoscaling:Group auto-scaling created
 + ├─ aws:ecs:CapacityProvider capacity-provider created
 + ├─ aws:ecs:Cluster cluster created
 + ├─ aws:ecs:TaskDefinition my-app created
 + ├─ aws:lb:Listener web created
 + └─ aws:ecs:Service my-task-runner created

Outputs:
 NOTE: "You may have to wait a minute for AWS to spin up the service. So if the URL throws a 503 error, try again after a bit."
 app_url: "http://load-balancer-7aedaa4-1557043631.us-west-2.elb.amazonaws.com"

Resources:
 + 16 created

Duration: 2m30s

What’s Next?

Before jumping to the next thing, let’s review what we’ve done. Using infrastructure as code enables changing your infrastructure as new technology becomes available. You can experiment rapidly to see if this configuration can meet your performance metrics and remain within your cloud spend budget. Blue/green deployment is straightforward because you are just swapping components on a known and proven infrastructure. These are just some of the advantages of using infrastructure as code.

So what is the next step? In a future article, well demonstrate how to build your own ARM-based container images using Docker’s buildx CLI plugin. Until then, you can learn more about Pulumi and infrastructure as code with our Getting Started tutorials.

CI/CD Pipelines for Kubernetes Apps with Pulumi & Codefresh

Sophia Parafina — Tue, 19 Jan 2021 00:00:00 +0000

Delivering modern applications is complicated and requires the coordination of many moving parts. Applications are frequently updated to implement new features and improve security and performance, translating to a better user experience for your customers. To further complicate matters, infrastructure must also be deployed and maintained simultaneously with applications to avoid conflicts or dependencies.

Containerized applications deployed on Kubernetes are particularly susceptible to a misalignment between developers who frequently push changes and operators who want to maintain a stable architecture. Continuous Integration builds and tests software and delivers it as packages. Continuous Delivery or Deployment deploys applications on infrastructure. Let’s take a look at how we can accomplish CI/CD for both applications and infrastructure.

Join us for a CI/CD with Kubernetes technical session on January 21st.

CI/CD and Pipelines

CD is sometimes called Continuous Delivery or Continuous Deployment. These have the same results, i.e., deploying software artifacts to production. However, Continuous Deployment is an automated process that deploys artifacts without human intervention. Continuous Delivery occurs when a person decides when to deploy an application. The reason could be a business decision, such as coordinating the release with a marketing campaign or having a final check by an engineer before release.

Continuous integration is an automated process that begins with a code push to a repository. From there, the code can be built and tested, and eventually released as an artifact. Your organization determines the CI process, and it can include manual testing of the code to catch corner cases.

A pipeline is the deployable unit path for CI/CD. A pipeline starts when code is committed to a repository like GitHub. The next step is a notification to a build system, such as Codefresh. The build system compiles the code and runs unit tests. If your code passes the unit tests, integration tests are the next step. If your code passes both unit and integration tests, the images will be created and pushed into a registry service in the case of containers. This is the simplest example of a pipeline, but you can do many more things such as security scans, check modules for CVEs (Common Vulnerabilities and Exploits), send Slack notifications, and run quality checks. A pipeline can be fully automated or have checkpoints that require approval before resuming.

Codefresh is a modern CI/CD platform specifically created for Kubernetes and containers. A pipeline in Codefresh is composed of a series of steps, where every step is a Docker container. This means that creating a pipeline is as easy as collecting your favorite Docker images from any public or private Registry. Integration with Pulumi is trivial as Pulumi is already offered in the form of a public image.

On the deployment front, Codefresh has native integration for Kubernetes, container registries, and Git providers. This means you can set up your cluster once in a central configuration and then make it available to all your pipelines by name. Codefresh is cloud-agnostic on all fronts. All major Git providers are supported, and deployment can happen on any compliant Kubernetes cluster.

Every Codefresh account comes with a built-in graphical dashboard that allows you to inspect your Kubernetes cluster not only on the service/pod level but also on the application (i.e., Helm releases). This means that with Codefresh, you don’t need to use multiple unrelated applications to understand if your deployment was successful.

A deployment that starts from a Git commit can be monitored with Codefresh from beginning to end, following all pipeline stages from application compilation/packaging to security scanning and infrastructure deployment.

See our dedicated documentation page on how to use Pulumi and Codefresh together.

Building Modern Infrastructure

Just like your application code, you can build your infrastructure with a CI/CD pipeline. Pulumi lets developers write infrastructure using their favorite language, such as Typescript, Python, or go. Developers can take advantage of abstractions, code reuse, refactoring, favorite development environments, and testing tools.

In addition to supporting multiple languages, you can build infrastructure on any cloud such as AWS, Azure, Google Cloud, and Kubernetes and take full advantage of their service offerings. Choose your toolchain and frameworks, and you’re set to deploy infrastructure on any major cloud provider and even hybrid and on-premises environments.

By leveraging infrastructure as code combined with software development practices, engineers can achieve greater productivity while enabling their development teams to be more “self-serve” with appropriate policies and guardrails in place. Pulumi brings cloud security engineering to the infrastructure and development teams. Using one common workflow that spans any cloud environment, whether public, private, or hybrid, security teams can enforce policies that accomplish cloud governance projects of all kinds — security, compliance, cost control, and more.

To see how infrastructure as code simplifies infrastructure deployment, let’s look at an example for deploying Kubernetes with python on AWS. The full example is available on Github.

The code breaks up the Kubernetes deployment into python modules:

vpc.py creates an AWS Virtual Private Cloud containing the cluster, security group, and networking.
iam.py creates roles for the cluster, and the nodegroup and policy attachments
utils.py creates a kubeconfig file that can be used with kubectl to manage Kubernetes

The main program (main.py) creates the Kubernetes cluster by calling the modules to deploy a cluster and a nodegroup with the policies applied. Using modules, we can make changes to the vpc, networking, roles, and policies and customize it to our application. In a CI/CD, all these changes would be pushed through a pipeline before deployment.

Although this example is written in Python for AWS, there are similar examples in other languages and cloud providers in Pulumi Examples.

Putting it Together

This article described how we could build both applications and infrastructure with CI/CD pipelines. To learn more about how Codefresh and Pulumi can automate Kubernetes deployments join us for a technical session on January 21st.

Automation API: Supercharged Cloud Tooling

Sophia Parafina — Thu, 14 Jan 2021 00:00:00 +0000

“Why use a programming language to build and maintain infrastructure?” is a question we hear frequently. There are apparent advantages such as using a mature and well-known language across a team, enabling cloud engineers to use software development best practices, and an ecosystem of tools for building robust systems.

Infrastructure as code enables you to build tools and environments to automate routine tasks, letting cloud engineers concentrate on efficiency and resilience. In this article, we’ll take a look at how Pulumi’s Automation API lets you build custom ops tooling that improves your workflow.

What is the Automation API?

Automation API is a programming interface overlaid on the Pulumi engine for deploying infrastructure. Instead of using the Pulumi CLI to deploy infrastructure, you can directly call the engine to run code from your chosen language. With the Automation API, your Pulumi programs and stacks are strongly-typed and composable infrastructure building blocks. You can fully embed Pulumi inside your software projects, which means your code can power a wide range of cloud automation projects without the Pulumi CLI and a reduced human-in-the-loop footprint.

This alpha release of Automation API currently supports Node.js, Go and Python. .NET (C#) will be released soon.

Cleaning Up

To demonstrate how Automation API enables you to build tools, let’s tackle the common problem of unused virtual machines in the cloud. Companies spent an estimated $11 billion on idle resources in 2020, according to ParkMyCloud. Merely shutting down unused resources can significantly decrease costs for any organization.

We can use the Automation API to build a specialized CLI tool for creating and managing virtual machines. We wrote vmgr to demonstrate provisioning temporary virtual machines that expire after a user-specified amount of time. The complete example is available on Github. The vmgrCLI is a tool for provisioning temporary development virtual machines in Azure. Let’s take a look at this project.

An advantage of using a programming language is that you can use common software packages in your code. In the vmgr example, we use Cobra, a library for CLI applications used in Go projects Kubernetes, Hugo, and Github CLI. Instead of writing CLI boilerplate code with arguments, we can use Cobra with Automation API. VMs are provisioned as Stacks and their state is held by the Pulumi service. The cleanup job queries the Pulumi Service for stacks older than specified and removes them along with any child resources.

‘vmgr’ takes two commands:

vmgr add: creates a new VM web server with a public IP. These web servers share a resource group and virtual network that is referenced from a shared stack.
vmgr cron : scans all VM stacks for stacks that are older than the specified expiration. This command will continue to retry deletion even if it sees failures and will typically succeed in deleting the VM and public IP on the second try.

To delete VMs older than 5 minutes:

$ vmgr cron 5m

To delete VMs older than five days.

$vmgr cron 5d

vmgr is a tool you can give to developers that they can use immediately with the added benefit of reducing costs by removing unused instances. Automation API enables building tools that speed up the inner dev loop for application developers and reduces the operation team’s burden to clean up unused instances.

Automate All the Things

Cloud engineering will automate many tasks that are currently performed by operators. Using infrastructure as code and SDKs such as Automation API, we can build self-service tools that improve the inner dev loop for application developers and let operators perform higher-level tasks such as maintenance and infrastructure monitoring. This simple example demonstrates the effective use of infrastructure as code by importing other software libraries to build a specialized tool that is not possible with DSLs or YAML.

Automation API is currently in preview and will be part of the Pulumi 3.0 GA release, including additional language support. To get started with Automation API, try out the examples and documentation for node.js and go. If you are looking for a more complex example, check out ploy, a CLI tool that builds Docker images and deploys them on Kubernetes.

Upcoming Workshops and Events

Sophia Parafina — Tue, 12 Jan 2021 00:00:00 +0000

It’s a new year and it’s time to level up your cloud engineering skills. Pulumi is there to get you started on your cloud engineering journey with workshops and technical sessions.

CI/CD Pipelines for Kubernetes Apps with Pulumi & Codefresh

To kickoff the year we start with a technical session that demonstrates how to continuously deliver both applications and provision infrastructure using Codefresh CI/CD. This session will demonstrate:

The basics of CI/CD using Codefresh.
How to declare cloud resources using Pulumi and your favorite programming languages.
How to define a simple pipeline for Kubernetes deployments.
Practical tests to ensure infrastructure reliability as part of your pipeline.

Taught by Pulumi and Codefresh engineers, you’ll receive a thorough understanding of CI/CD and infrastructure as code best practices.

Intro to Pulumi

If you’re new to infrastructure as code, this workshop is for you. You will learn the fundamentals of Infrastructure as Code through a series of guided exercises using Pulumi’s Cloud Engineering platform. The workshop covers setting up Pulumi, an infrastructure as code platform that uses programming languages to provision modern cloud infrastructure.

This workshop is designed to help users completely new to Pulumi become familiar with the core concepts needed to be effective with the Pulumi Infrastructure as Code platform. We will guide through the Pulumi platform with diagrams and a series of hands on exercises to help you understand the building blocks available in Pulumi.

The workshop will cover the following topics.

What is Pulumi?
How to install Pulumi
Configuring your development environment
Choose your Pulumi language
An introduction to the Pulumi state & the Pulumi Service
An introduction to Pulumi config
Storing sensitive data in Pulumi securely
Provision your first resources
Understanding stacks
An introduction to the Pulumi programming model

We have multiple workshops scheduled from January to March. Register for one today.

Jan 26: Intro to Pulumi, 9 AM PST Feb 9: Intro to Pulumi, 9 AM PST Feb 23: Intro to Pulumi, 9 AM PST March 9: Intro to Pulumi, 9 AM PST

Deploying Microservices with Pulumi and AWS Lambda

This serverless workshop demonstrates how Pulumi can accelerate provisioning of cloud infrastructure. The workshop shows how to build a set of microservices utilizing AWS’s newest Lambda features. Attendees will be guided through the process of provisioning a set of Lambda resources in AWS and see real time examples of how Pulumi’s innovative programming model helps turbocharge cloud engineering.

If you’re an active Pulumi user and building serverless applications this hands-on workshop is for you. You will learn:

How to provision a Lambda function in AWS.
How to provision infrastructure such as DynamoDB & API Gateway to support your microservice applications.
How to take advantage of the newest Lambda features.

Building a Kubernetes Platform in Amazon EKS with Pulumi

Kubernetes is one of the major cloud technologies and in this hands-on workshop, we’ll examine how Pulumi works with Kubernetes through real-world examples of managing Amazon EKS clusters. We’ll focus on building a user-friendly Kubernetes platform, installing software that makes Kubernetes easy to use for application developers.

Attendees will be guided through the process of provisioning an Amazon EKS cluster and installing platform friendly software such as the aws load balancer controller. We’ll cover the following:

How-to provision a production-ready Amazon EKS cluster with key features enabled using Pulumi
Provisioning the aws-load-balancer-controller to automate ingress creation
Install an example application to show the end-to-end user experience for users.

Get a solid foundation for provisioning Kubernetes clusters and applications by signing up.

re:Invent 2020 EKS Feature Releases

Sophia Parafina — Mon, 07 Dec 2020 00:00:00 +0000

Amazon announced several Elastic Kubernetes Service feature releases and updates during the first week of AWS re:Invent 2020. If we look at all the announcements as a whole, we can see the Kubernetes ecosystem maturing to make deployments and management easier for organizations. Let’s take a look at how they can benefit your use of EKS.

Amazon EKS Distro

First and foremost is the release of Amazon EKS Distro, also called EKS Anywhere. This is the same Kubernetes distro available to Amazon EKS customers on AWS as an open-source project. You can take advantage of a fully supported Kubernetes distribution built from open source with version aligned dependency updates and Common Vulnerabilities and Exposures (CVE) patches. Notifications for patches are sent from Amazon Simple Notification Service (SNS) with support for backported patches. Read more about EKS Distro here.

You can create a cluster using kubeadm, kops, or tools such as Pulumi. Learn more about creating infrastructure with EKS Distro and Pulumi on our blog.

Logging support for AWS Fargate

Amazon EKS pods running on AWS Fargate can now forward container logs to various AWS services, including Cloudwatch, S3, Elasticsearch, and Kinesis, to enable log storage and analytics. EKS with Fargate includes a native log router, eliminating the need for a sidecar. You can use ConfigMap to send routers to the service of your choice. Read more about it on the AWS blog post.

Simplified install and management for Kubernetes CNI plugin

Amazon EKS now supports installation and management of the VPC CNI. The AWS VPC CNI provides integrated AWS Virtual Private Cloud (VPC) networking for Kubernetes clusters. You can use AWS VPC networking and security best practices for building Kubernetes clusters that include VPC routing policies and security groups for network traffic isolation.

You can install and manage the CNI plugin with the Amazon EKS console, CLI, and API. Previously, you needed to install and maintain it manually after a Kubernetes upgrade. Amazon EKS lets you install, manage, and through the EKS console, CLI, and API, where it is validated by AWS and can be deployed and updated. To learn more, read the announcement.

EC2 Spot Instances in managed node groups

Spot Instances are deeply discounted On-Demand EC2 instances. EKS now supports using Spot Instances with EKS managed node groups. If you are running batch process such as ETL with Apache Spark or stateless endpoint, Spot Instances are a cost-effective way for managing surge requests in EKS.

Previously, to use Spot Instances, you had to manually configure EC2 Auto Scaling groups and upgrade the Spot nodes to the current version of Kubernetes. You can now set capacity type as SPOT and the EC2 instance types when creating a managed node group. The managed node group will provision and manage Spot nodes automatically according to best practices. You can create the node group through the EKS console, the EKS API, and eksctl. To learn more about configuring EKS node groups with Spot Instance, read the blog.

Want some hands-on training with EKS? Join our workshop on Thursday, December 10th where you will create a production-ready EKS cluster, install add-ons to prepare your cluster for developers, and finally ship an application to your cluster. Register Now

Orchestrating Cloud Workflows with Automation API

Sophia Parafina — Thu, 19 Nov 2020 00:00:00 +0000

There are many moving parts when deploying infrastructure and applications. Playbooks are step-by-step maps that standardize how infrastructure and applications are deployed across your organization. Typically playbooks describe every action to build and deploy, requiring an operator to complete each step before moving on to the next. It’s a process that can be tedious and prone to human error.

What if you could encapsulate a playbook into a single action? This is the promise of declarative infrastructure. You declare the desired state of your infrastructure and the infrastructure as code engine builds the infrastructure. However, you must still deploy the application and perform maintenance, and this is where you hit the limits of templating languages and where programming languages excel. In this hands-on article, we’ll demonstrate how to use Pulumi’s Automation API to create a program that builds infrastructure, installs an application, and can perform application maintenance.

Starting Point

Pulumi’s Automation API has a set of examples to get you started. These examples are sketches that demonstrate what is possible with Automation API. We’ll start with the database migration example in Node.js, described as:

“This example provisions an AWS Aurora SQL database and executes a database “migration” using the resulting connection info. This migration creates a table, inserts a few rows of data, and reads the data to verify the setup. This is all done in a single inline Pulumi program.”

We’ll expand on this example and add the following:

show how to retrieve a password from AWS Secrets Manager
add functions for database backup, mysqlcheck, optimize, and analyze

Let’s get started by cloning the repository and open the index.ts.

$ git clone https://github.com/pulumi/automation-api-examples.git
$ cd ./automation-api-examples/nodejs/databaseMigration-ts/

Program overview

Several pieces comprise the program; the first is the program’s main scope, where we can pass values from the functions that make up the script. The next part is the pulumiProgram function that declares the infrastructure.

const run = async () => {
 // This is our pulumi program in "inline function" form
 const pulumiProgram = async () => {

To deploy the infrastructure, we use the Automation API to instantiate the resources and create a stack. Like a Pulumi program invoked by the CLI, we need to provide a stack and project name and the inline program’s name that declares the infrastructure.

 // Create our stack
 const args: InlineProgramArgs = {
 stackName: "dev",
 projectName: "databaseMigration",
 program: pulumiProgram
 };

 // create (or select if one already exists) a stack that uses our inline program
 const stack = await LocalWorkspace.createOrSelectStack(args);

Once the infrastructure is created, we can call provisioning functions, such as createdb, maintenance functions, or other functions to manage the database.

Adding arguments for new commands

First, we’ll add the arguments for database creation, mysqlcheck, optimize, and analyze. These arguments call the functions that build the infrastructure, create and populate the database, and perform maintenance.

const process = require('process');

const args = process.argv.slice(2);
let destroy = false;
let createdb =false;
let backup = false;
let mysqlcheck = false;
let optimize = false;
let analyze = false;

if (args.length > 0 && args[0]) {
 destroy = args[0] === "destroy";
 createdb = args[0] === "createdb";
 backup = args[0] === "backup";
 mysqlcheck = args[0] === "mysqlcheck";
 optimize = args[0] === "optimize";
 analyze = args[0] === "analyze";
}

Declare infrastructure

The all the code used to create the infrastructure (a VPC, a security group, and an RDS, provision the database, and maintain the database is in an inline program, which is a function that we can call using Node.js instead of the Pulumi CLI.

Let’s break down the infrastructure piece by piece, starting with setting up configuration variables for the database. In the original code, the database name, admin name, and admin password were hardcoded into the program. We would never do that in practice and get the database, admin name, and secret name from a configuration file and a secrets provider’s password. We’ll keep those properties in the program for simplicity, but in our improved program, we’ll retrieve the password from the AWS Secrets Manager. We set the password using the aws CLI.

$ aws secretsmanager create-secret --name dbpass --secret-string hellosql

We retrieve the secret with a function that retrieves it as a Pulumi output and returns it as a string type, which is the type that Aurora MySQL requires for the masterpassword property. This is a little complicated because we use the secret name to retrieve the secret properties with getSecret, which returns the secret ARN. Then, we use the ARN to retrieve the password with getSecretVersion. Note that the function is wrapped in async/await because we will need the password before creating the database.

async function getSecret(name: string) {
 const secret = await aws.secretsmanager.getSecret({name: name});
 const sm = aws.secretsmanager.getSecretVersion( {secretId: secret.arn});
 return (await sm).secretString;
 }

The next part creates the VPC, the subnet, a security group for access, and the Aurora database cluster. Aside from calling the getSecret function, this part of the program remains unchanged. Note that the function returns several parameters that are available to other functions in the same scope.

 // setup infrastructure
 const vpc = awsx.ec2.Vpc.getDefault();
 const subnetGroup = new aws.rds.SubnetGroup("dbsubnet", {
 subnetIds: vpc.publicSubnetIds,
 });

 // make a public SG for our cluster for the migration
 const securityGroup = new awsx.ec2.SecurityGroup("publicGroup", {
 egress: [
 {
 protocol: "-1",
 fromPort: 0,
 toPort: 0,
 cidrBlocks: ["0.0.0.0/0"],
 }
 ],
 ingress: [
 {
 protocol: "-1",
 fromPort: 0,
 toPort: 0,
 cidrBlocks: ["0.0.0.0/0"],
 }
 ]
 });

 // provision our db
 const cluster = new aws.rds.Cluster("db", {
 engine: "aurora-mysql",
 engineVersion: "5.7.mysql_aurora.2.03.2",
 databaseName: dbUser,
 masterUsername: dbName,
 masterPassword: getSecret("dbpass"),
 skipFinalSnapshot: true,
 dbSubnetGroupName: subnetGroup.name,
 vpcSecurityGroupIds: [securityGroup.id],
 });

 const clusterInstance = new aws.rds.ClusterInstance("dbInstance", {
 clusterIdentifier: cluster.clusterIdentifier,
 instanceClass: "db.t3.small",
 engine: "aurora-mysql",
 engineVersion: "5.7.mysql_aurora.2.03.2",
 publiclyAccessible: true,
 dbSubnetGroupName: subnetGroup.name,
 });

 return {
 host: pulumi.interpolate`${cluster.endpoint}`,
 dbName,
 dbUser,
 dbPass: getSecret("dbpass"),
 };
 };

Creating the stack

If you’re not familiar with the Pulumi programming model, a stack is an instantiation of the infrastructure resources declared in the code. We start with calling the createOrSelectStack method from the LocalWorkSpace import. This method takes three arguments: a stack name, a project name, and the program to call, which is the pulumiProgram function, that creates the infrastructure. The stack installs the required plugins, sets the AWS region, and creates the infrastructure. We can also destroy the stack if we use the destroy argument, e.g., yarn start destroy. .

 // Create our stack
 const args: InlineProgramArgs = {
 stackName: "dev",
 projectName: "databaseMigration",
 program: pulumiProgram
 };

 // create (or select if one already exists) a stack that uses our inline program
 const stack = await LocalWorkspace.createOrSelectStack(args);

 console.info("successfully initialized stack");
 console.info("installing plugins...");
 await stack.workspace.installPlugin("aws", "v3.6.1");
 console.info("plugins installed");
 console.info("setting up config");
 await stack.setConfig("aws:region", { value: "us-west-2" });
 console.info("config set");
 console.info("refreshing stack...");
 await stack.refresh({ onOutput: console.info });
 console.info("refresh complete");

 if (destroy) {
 console.info("destroying stack...");
 await stack.destroy({ onOutput: console.info });
 console.info("stack destroy complete");
 process.exit(0);
 }

 console.info("updating stack...");
 const upRes = await stack.up({ onOutput: console.info });
 console.log(`update summary: \n${JSON.stringify(upRes.summary.resourceChanges, null, 4)}`);
 console.log(`db host url: ${upRes.outputs.host.value}`);
 console.info("configuring db...");

Adding a table and data

Once our infrastructure is up, we can add a table and insert data with SQL statements. First, we need to create a connection object to talk to the database. The upRes variable is set to the stack, so the outputs it returns are available to the program’s main scope.

 // establish mysql client
 const connection = mysql.createConnection({
 host: upRes.outputs.host.value,
 user: upRes.outputs.dbUser.value,
 password: upRes.outputs.dbPass.value,
 database: upRes.outputs.dbName.value
 });

In the original program, the table and data are created as part of the inline program. We wrap this in a function that is called by yarn, e.g., yarn start createdb.

 // create table and populate it
 if (createdb) {
 connection.connect();
 console.log("creating table...")

 // make sure the table exists
 connection.query(`
 CREATE TABLE IF NOT EXISTS hello_pulumi(
 id int(9) NOT NULL,
 color varchar(14) NOT NULL,
 PRIMARY KEY(id)
 );
 `, function (error, results, fields) {
 if (error) throw error;
 console.log("table created!")
 console.log('Result: ', JSON.stringify(results));
 console.log("seeding initial data...")
 });

 // seed the table with some data to start
 connection.query(`
 INSERT IGNORE INTO hello_pulumi (id, color)
 VALUES
 (1, 'Purple'),
 (2, 'Violet'),
 (3, 'Plum');
 `, function (error, results, fields) {
 if (error) throw error;
 console.log("rows inserted!")
 console.log('Result: ', JSON.stringify(results));
 console.log("querying to veryify data...")
 });


 // read the data back
 connection.query(`SELECT COUNT(*) FROM hello_pulumi;`, function (error, results, fields) {
 if (error) throw error;
 console.log('Result: ', JSON.stringify(results));
 console.log("database, tables, and rows successfuly configured!")
 });

 connection.end();
 }

Adding maintenance features

The createdb function establishes the pattern for adding other MySQL operations. The pattern is to connect to the database, send a SQL query, and return the results and errors if any. These functions take the table name as input. To use these commands, we can run the program with yarn, as before:

$ yarn start <command> hello_pulumi

The program parses the arguments and sets the command and table name in the main scope. The additional MySQL operations are:

checktable: CHECK TABLE,
analyze: ANALYZE TABLE
optimize: OPTIMIZE TABLE.

We created the hello_pulumi table with the createdb function, but we can leave it as a future exercise to make a generic table creation and list table functions.

 // MySQL command to check tables for integrity errors
 if (checktable) {
 connection.connect();
 console.log("checking table...")
 if (tableName) {
 connection.query(`CHECK TABLE ${tableName};`, function (error, results, fields) {
 if (error) throw error;
 console.log('Result: ', JSON.stringify(results));
 console.log("table checked for integrity errors!")});
 } else {
 console.log("Error: Table not specified.");
 console.log("Try: yarn start checktable {table name}");
 }

 connection.end();
 }

 // MySQL command to rebuild index for slow database response
 if (analyze) {
 connection.connect();
 console.log(" analyze table...")
 if (tableName) {
 connection.query(`ANALYZE TABLE ${tableName};`, function (error, results, fields) {
 if (error) throw error;
 console.log('Result: ', JSON.stringify(results));
 console.log("table index rebuilt!")});
 } else {
 console.log("Error: Table not specified.");
 console.log("Try: yarn start analyze {table name}");
 }

 connection.end();
 }

 // MySQL command to reclaim space and rebuild tables and indices
 if (optimize) {
 connection.connect();
 console.log(" optimize table...")
 if (tableName) {
 connection.query(`OPTIMIZE TABLE ${tableName};`, function (error, results, fields) {
 if (error) throw error;
 console.log('Result: ', JSON.stringify(results));
 console.log("table space reclaimed, table and index rebuilt!")});
 } else {
 console.log("Error: Table not specified.");
 console.log("Try: yarn start analyze {table name}");
 }

 connection.end();
 }

Summary

So what have we accomplished? Most importantly, we can turn a playbook into code. Encapsulating your workflow with code means that you have modern software tools such as an IDE with code completion, hints, type checking, debugging, and versioning available to you. In addition to declaring infrastructure, you can also provision it with applications and data. Because it’s code, you can extend it as we have done by adding maintenance functions, something not possible with a markup language. Finally, you don’t have to use a proprietary CLI to deploy infrastructure and apps. Automation API lets you do all these things and much more.

You can download our improved program as a gist to replace the one included in the example.

Automation API is currently in alpha and available in Typescript and Go. Check out these resources to learn more.

Build Self-Service Cloud Infrastructure with Automation API

Sophia Parafina — Tue, 10 Nov 2020 00:00:00 +0000

If you could create infrastructure without using a cloud provider’s console, a CLI, or a templating engine, what would you build? Pulumi’s Automation API lets you create declarative infrastructure defined by your best practices and expose it behind a REST, gRPC, or custom API.

So just what is Automation API? Think of it as Pulumi’s infrastructure as code engine as an SDK. Instead of writing code and using the CLI to declare infrastructure, you can directly tell the engine to build your infrastructure. This means that you’re using the same declarative IaC tooling with the predictability, robustness, safety, and desired state management, except it has a new programmatic surface area. Imagine building an application that creates infrastructure via a REST interface. Get ready, because that’s what we’re going to do.

Self-service Cloud Infrastructure

Automation API is just another package that runs inside your favorite frameworks and works with other packages. You can create methods or functions to create infrastructure that you can call from other frameworks. One Automation API use case is a self-service infrastructure. You can create declarative infrastructure and expose it behind a REST interface. Your infrastructure is also backed by a JSON state file managed by the Pulumi SaaS that allows you to create and update them dynamically.

This example demonstrates how to create infrastructure with Automation API and the Express Node.js framework. To keep this example simple, we’ll deploy the REST API locally. To deploy the code in the cloud, for example, in a virtual machine, we’ll need to create an instance profile to store AWS credentials. Deploying Automation API is beyond this article’s scope, so we’ll use localhost as the server’s endpoint. We’ll cover deploying Automation API in the cloud in subsequent articles.

Infrastructure as a function

We use an inline Pulumi program that doesn’t require a separate package with index.ts and Pulumi.yaml files, although they can be authored in an index.ts file or imported from another package. The example deploys an AWS S3 website with the context and deployment automation defined in a function. Functions can be components, in this case, a static S3 website. However, they can be more complex, such as a Kubernetes cluster with accompanying containers and AWS resources.

const projectName = "pulumi_over_http";

const createPulumiProgram = (content: string) => async () => {
 // Create a bucket and expose a website index document
 const siteBucket = new s3.Bucket("s3-website-bucket", {
 website: {
 indexDocument: "index.html",
 },
 });

This part of the function lets users write content.

 // Our HTML is defined based on what the caller sends.
 const indexContent = content;

 // write our index.html into the site bucket
 let object = new s3.BucketObject("index", {
 bucket: siteBucket,
 content: indexContent,
 contentType: "text/html; charset=utf-8",
 key: "index.html"
 });

To make the contents accessible, we create and set a policy for the S3 bucket.

 // Create an S3 Bucket Policy to allow public read of all objects in bucket
 function publicReadPolicyForBucket(bucketName): PolicyDocument {
 return {
 Version: "2012-10-17",
 Statement: [{
 Effect: "Allow",
 Principal: "*",
 Action: [
 "s3:GetObject"
 ],
 Resource: [
 `arn:aws:s3:::${bucketName}/*` // policy refers to bucket name explicitly
 ]
 }]
 };
 }

 // Set the access policy for the bucket so all objects are readable
 let bucketPolicy = new s3.BucketPolicy("bucketPolicy", {
 bucket: siteBucket.bucket, // refer to the bucket created earlier
 policy: siteBucket.bucket.apply(publicReadPolicyForBucket) // use output property `siteBucket.bucket`
 });

 return {
 websiteUrl: siteBucket.websiteEndpoint,
 };
};

Building the REST API

We use the Express RequestHandler callback to create the S3 static website buckets by creating the stack locally. Calling this handler creates a new bucket which represents an individual site. It’s important to note that one of the advantages of using code is the ability to detect and handle error scenarios, which is necessary for online infrastructure or when embedding it in other complex software.

// creates new sites
const createHandler: express.RequestHandler = async (req, res) => {
 const stackName = req.body.id;
 const content = req.body.content as string;
 try {
 // create a new stack
 const stack = await LocalWorkspace.createStack({
 stackName,
 projectName,
 // generate our pulumi program on the fly from the POST body
 program: createPulumiProgram(content),
 });
 await stack.setConfig("aws:region", { value: "us-west-2" });
 // deploy the stack, tailing the logs to console
 const upRes = await stack.up({ onOutput: console.info });
 res.json({ id: stackName, url: upRes.outputs.websiteUrl.value });
 } catch (e) {
 if (e instanceof StackAlreadyExistsError) {
 res.status(409).send(`stack "${stackName}" already exists`);
 } else {
 res.status(500).send(e);
 }
 }
};

These callbacks implement the range of REST API requests for a bucket which includes adding content with a POST request, updating content with a PUT request, getting site content and a list of sites with GET requests, and deleting a site/bucket with a DELETE request.

// lists all sites
const listHandler: express.RequestHandler = async (req, res) => {
 try {
 // set up a workspace with only enough information for the list stack operations
 const ws = await LocalWorkspace.create({ projectSettings: { name: projectName, runtime: "nodejs" } });
 const stacks = await ws.listStacks();
 res.json({ ids: stacks.map(s => s.name) });
 } catch (e) {
 res.status(500).send(e);
 }
};
// gets info about a specific site
const getHandler: express.RequestHandler = async (req, res) => {
 const stackName = req.params.id;
 try {
 // select the existing stack
 const stack = await LocalWorkspace.selectStack({
 stackName,
 projectName,
 // don't need a program just to get outputs
 program: async () => { },
 });
 const outs = await stack.outputs();
 res.json({ id: stackName, url: outs.websiteUrl.value });
 } catch (e) {
 if (e instanceof StackNotFoundError) {
 res.status(404).send(`stack "${stackName}" does not exist`);
 } else {
 res.status(500).send(e);
 }
 }
};
// updates the content for an existing site
const updateHandler: express.RequestHandler = async (req, res) => {
 const stackName = req.params.id;
 const content = req.body.content as string;
 try {
 // select the existing stack
 const stack = await LocalWorkspace.selectStack({
 stackName,
 projectName,
 // generate our pulumi program on the fly from the POST body
 program: createPulumiProgram(content),
 });
 await stack.setConfig("aws:region", { value: "us-west-2" });
 // deploy the stack, tailing the logs to console
 const upRes = await stack.up({ onOutput: console.info });
 res.json({ id: stackName, url: upRes.outputs.websiteUrl.value });
 } catch (e) {
 if (e instanceof StackNotFoundError) {
 res.status(404).send(`stack "${stackName}" does not exist`);
 } else if (e instanceof ConcurrentUpdateError) {
 res.status(409).send(`stack "${stackName}" already has update in progress`)
 } else {
 res.status(500).send(e);
 }
 }
};
// deletes a site
const deleteHandler: express.RequestHandler = async (req, res) => {
 const stackName = req.params.id;
 try {
 // select the existing stack
 const stack = await LocalWorkspace.selectStack({
 stackName,
 projectName,
 // don't need a program for destroy
 program: async () => { },
 });
 // deploy the stack, tailing the logs to console
 await stack.destroy({ onOutput: console.info });
 await stack.workspace.removeStack(stackName);
 res.status(200).end();
 } catch (e) {
 if (e instanceof StackNotFoundError) {
 res.status(404).send(`stack "${stackName}" does not exist`);
 } else if (e instanceof ConcurrentUpdateError) {
 res.status(409).send(`stack "${stackName}" already has update in progress`)
 } else {
 res.status(500).send(e);
 }
 }
};
const ensurePlugins = async () => {
 const ws = await LocalWorkspace.create({});
 await ws.installPlugin("aws", "v3.2.1");
};

// install necessary plugins once upon boot
ensurePlugins();

// configure express
const app = express();
app.use(express.json());

Creating routes in Express to the callbacks is straightforward and requires mapping the route to the appropriate callback.

// setup our RESTful routes for our Site resource
app.post("/sites", createHandler);
app.get("/sites", listHandler);
app.get("/sites/:id", getHandler);
app.put("/sites/:id", updateHandler);
app.delete("/sites/:id", deleteHandler);

// start our http server
app.listen(1337, () => console.info("server running on :1337"));

Trying it out

The complete example is available on GitHub, along with other examples in both Nodejs and go. To run the TypeScript example, run:

$ yarn install
$ yarn start

Let’s test it by sending requests to the server on http://localhost:1337.

If you use Postman, you can import a Postman Collection to send requests to the server.

First let’s create our first website which returns the website path (id) and the URL of the static website.

$ curl --header "Content-Type: application/json" --request POST --data '{"id":"hello","content":"hello world\n"}' http://localhost:1337/sites
$ {"id":"hello","url":"s3-website-bucket-db5dae8.s3-website-us-west-2.amazonaws.com"}

We can view the content then update it, then view it again.

$ curl s3-website-bucket-db5dae8.s3-website-us-west-2.amazonaws.com
$ curl --header "Content-Type: application/json" --request PUT --data '{"id":"hello","content":"hello updated world!\n"}' http://localhost:1337/sites/hello
$ curl s3-website-bucket-db5dae8.s3-website-us-west-2.amazonaws.com

Once we’re done, we can delete the website.

$ curl --header "Content-Type: application/json" --request DELETE http://localhost:1337/sites/hello

Pulling it all together

So what can you do with this? We used a static website in this example so that results are immediately available. However, this application does basic CRUD operations, which are the basis of many applications. For example, an application could send photos to a bucket or send data to a database application.

Automation API enables building your custom cloud platforms. This example has shown us how to take our customized unit of infrastructure and expose it to our broader team via a REST interface that we define and control. This interface is familiar to developers and feels more comfortable than using IaC directly. Today, we expose a static website, but tomorrow it could be a Kubernetes application platform with all of our networking and security best practices.

Automation API lets you build and explore new implementation patterns with cloud resources. Check out the other things you can build with Automation API.

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.

Policy as Code for Any Cloud Provider

Sophia Parafina — Tue, 27 Oct 2020 00:00:00 +0000

Policies protect your infrastructure by controlling access, set limits that reduce the blast radius of an incident, and manage infrastructure operations. Policies are commonly created through a form on a cloud provider’s administrative console, making replicating or versioning the policy more difficult. With Policy as Code, you can apply software engineering practices such as automated testing, deployment, and version control when creating policies.

CrossGuard is Pulumi’s Policy as Code solution that lets you create, verify, apply, and enforce policies. Policies are standalone packages that can be run against any Pulumi stack. That means your policies are language agnostic and work with any language supported by Pulumi. Policy Packages are policy bundles that evaluate every resource in your stack, whether deployed in AWS, Azure, Google Cloud, or Kubernetes.

The key features of CrossGuard are:

Policy SDK for coding custom policies using TypeScript/JavaScript or Python
Validating infrastructure before deployment by verifying it locally
Policy Packs for enforcing best practices for security, reliability, and cost
Validating all the infrastructure deployed by an organization.

Whether you create policies for a single project or across your organization, CrossGuard enforces best practices for cost, compliance, security, and team practices.

Parts of a policy

A policy is made up of the following parts:

a name
a description
an enforcement level
a resource validation
a message to report the violation

Policies enforce a specific logic. In the example above, Kubernetes can’t expose services to the Internet. We accomplish this by not allowing a spec to create LoadBalancer when a service is declared. Policies are checked during pulumi preview and during pulumi update to enforce defined restrictions.

There are two types of policies, a ResourceValidationPolicy that validates a particular resource in a stack, and a StackValidationPolicy that validates the stack as a whole. When CrossGuard calls a ResourceValidationPolicy, it checks each resource in the stack. These checks are before a resource is created and blocks any resources that fail the policy logic.

A StackValidationPolicy is run against the entire stack, requiring all the resources to be created and registered. Resources that fail validation will be blocked from being created or modified during pulumi up. Out of compliance resources will fail during preview or update, and we recommend running pulumi preview to catch these resources. Stack validation policies inspect multiple resources at once. This lets you validate resources dependent on other resources, such as a database that requires persistent storage.

Now that we understand how CrossGuard works. let’s look at examples for several cloud providers and Kubernetes.

Examples

The following examples are a common scenario showing how to prevent access to data in AWS, Azure, Google Cloud Platform, and Kubernetes using either TypeScript or Python to create policies. You can try out any of these policies by creating a new directory and running pulumi policy new, e.g.:

$ mkdir az-python-storage-policy && cd az-python-storage-policy
$ pulumi policy new azure-python

AWS

import * as aws from "@pulumi/aws";
import { PolicyPack, ReportViolation, validateResourceOfType } from "@pulumi/policy";

new PolicyPack("policy-pack-typescript", {
 policies: [{
 name: "s3-no-public-read",
 description: "Prohibits setting the publicRead or publicReadWrite permission on AWS S3 buckets.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(aws.s3.Bucket, (bucket, args, reportViolation) => {
 if (bucket.acl === "public-read" || bucket.acl === "public-read-write") {
 reportViolation(
 "You cannot set public-read or public-read-write on an S3 bucket. " +
 "Read more about ACLs here: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html");
 }
 }),
 }],
});

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def s3_no_public_read_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "aws:s3/bucket:Bucket" and "acl" in args.props:
 acl = args.props["acl"]
 if acl == "public-read" or acl == "public-read-write":
 report_violation(
 "You cannot set public-read or public-read-write on an S3 bucket. " +
 "Read more about ACLs here: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html")

s3_no_public_read = ResourceValidationPolicy(
 name="s3-no-public-read",
 description="Prohibits setting the publicRead or publicReadWrite permission on AWS S3 buckets.",
 validate=s3_no_public_read_validator,
)

PolicyPack(
 name="aws-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 s3_no_public_read,
 ],
)

Azure

import * as azure from "@pulumi/azure";
import { PolicyPack, validateResourceOfType } from "@pulumi/policy";

new PolicyPack("azure-typescript", {
 policies: [{
 name: "storage-container-no-public-read",
 description: "Prohibits setting the public permission on Azure Storage Blob Containers.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(azure.storage.Container, (container, args, reportViolation) => {
 if (container.containerAccessType === "blob" || container.containerAccessType === "container") {
 reportViolation(
 "Azure Storage Container must not have blob or container access set. " +
 "Read more about read access here: " +
 "https://docs.microsoft.com/en-us/azure/storage/blobs/storage-manage-access-to-resources");
 }
 }),
 }],
});

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def storage_container_no_public_read_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "azure:storage/container:Container" and "containerAccessType" in args.props:
 access_type = args.props["containerAccessType"]
 if access_type == "blob" or access_type == "container":
 report_violation(
 "Azure Storage Container must not have blob or container access set. " +
 "Read more about read access here: " +
 "https://docs.microsoft.com/en-us/azure/storage/blobs/storage-manage-access-to-resources")

storage_container_no_public_read = ResourceValidationPolicy(
 name="storage-container-no-public-read",
 description="Prohibits setting the public permission on Azure Storage Blob Containers.",
 validate=storage_container_no_public_read_validator,
)

PolicyPack(
 name="azure-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 storage_container_no_public_read,
 ],
)

Google Cloud

import * as gcp from "@pulumi/gcp";
import { PolicyPack, validateResourceOfType } from "@pulumi/policy";

new PolicyPack("gcp-typescript", {
 policies: [{
 name: "storage-bucket-no-public-read",
 description: "Prohibits setting the publicRead or publicReadWrite permission on GCP Storage buckets.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(gcp.storage.BucketACL, (acl, args, reportViolation) => {
 if (acl.predefinedAcl === "public-read" || acl.predefinedAcl === "public-read-write") {
 reportViolation("Storage buckets acl cannot be set to public-read or public-read-write.");
 }
 }),
 }],
});

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def storage_bucket_no_public_read_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "gcp:storage/bucketACL:BucketACL" and "predefinedAcl" in args.props:
 acl = args.props["predefinedAcl"]
 if acl == "public-read" or acl == "public-read-write":
 report_violation("Storage buckets acl cannot be set to public-read or public-read-write.")

storage_bucket_no_public_read = ResourceValidationPolicy(
 name="storage-bucket-no-public-read",
 description="Prohibits setting the publicRead or publicReadWrite permission on GCP Storage buckets.",
 validate=storage_bucket_no_public_read_validator,
)

PolicyPack(
 name="gcp-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 storage_bucket_no_public_read,
 ],
)

Kubernetes

import * as k8s from "@pulumi/kubernetes";
import { PolicyPack, validateResourceOfType } from "@pulumi/policy";

new PolicyPack("kubernetes-typescript", {
 policies: [{
 name: "no-public-services",
 description: "Kubernetes Services should be cluster-private.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(k8s.core.v1.Service, (svc, args, reportViolation) => {
 if (svc.spec && svc.spec.type === "LoadBalancer") {
 reportViolation("Kubernetes Services cannot be of type LoadBalancer, which are exposed to " +
 "anything that can reach the Kubernetes cluster. This likely including the " +
 "public Internet.");
 }
 }),
 }],
});

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def no_public_services_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "kubernetes:core/v1:Service" and "spec" in args.props:
 spec = args.props["spec"]
 if "type" in spec and spec["type"] == "LoadBalancer":
 report_violation(
 "Kubernetes Services cannot be of type LoadBalancer, which are exposed to " +
 "anything that can reach the Kubernetes cluster. This likely including the " +
 "public Internet.")

no_public_services = ResourceValidationPolicy(
 name="no-public-services",
 description="Kubernetes Services should be cluster-private.",
 validate=no_public_services_validator,
)

PolicyPack(
 name="kubernetes-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 no_public_services,
 ],
)

All Clouds and all resources

Policy as Code is a powerful tool for protecting and managing your infrastructure. As you can see, Pulumi supports policies for all resources on all clouds. We have examples and articles to get you started with Policy as Code.

Avoiding Kubernetes Anti-Patterns

Sophia Parafina — Tue, 29 Sep 2020 00:00:00 +0000

In software development, an anti-pattern is defined as an apparent solution that has unintended or negative consequences. The other side of anti-patterns is that they also offer solutions. Let’s look at container and Kubernetes anti-patterns and how to avoid them with infrastructure as code.

Hardcoding configuration in containers

Containers are immutable, and a single image can be used throughout the software lifecycle, i.e., from dev, to test, and to production. However, developers frequently use an image built using artifacts and configurations unique to a stage in the software lifecycle. The result is that the image in dev or test is not the same as the image deployed in production.

Best practice uses ConfigMaps, a Kubernetes native resource that doesn’t require integration. Because configuration is decoupled from the application, building the image at each stage is not necessary. Furthermore, ConfigMaps let you update when the application is running because the configuration is available during runtime.

Let’s look at an example where NginX is configured as a reverse-proxy that sends traffic to pulumi.github.io. The configuration is contained in a file, default.conf. Changing the file registers as a change in the ConfigMap’s data triggering a rollout of the NginX Deployment. If we change .node.server and .serve.location.proxy_set_header to google.com, NginX will redirect requests to google.com. When we run pulumi up, the preview shows it will explicitly trigger a rollout in the Deployment by replacing the ConfigMap. In contrast, kubectl will update the ConfigMap, but changes are not automatically applied to running containers.

ConfigMap

upstream node {
server pulumi.github.io;
}
server {
listen 80;
server_name _;
root /usr/share/nginx/html;
location / {
proxy_set_header X-Real-IP \$remote_addr;
proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
proxy_set_header Host pulumi.github.io;
proxy_pass http://node;
proxy_redirect off;
port_in_redirect off;
}
}

Deployment

import * as k8s from "@pulumi/kubernetes";
import * as pulumi from "@pulumi/pulumi";
import * as fs from "fs";

const config = new pulumi.Config();

const appName = "nginx";
const appLabels = { app: appName };

// nginx Configuration data to proxy traffic to `pulumi.github.io`. Read from
// `default.conf` file.
const nginxConfig = new k8s.core.v1.ConfigMap(appName, {
 metadata: { labels: appLabels },
 data: { "default.conf": fs.readFileSync("default.conf").toString() },
});
const nginxConfigName = nginxConfig.metadata.name;

// Deploy 1 nginx replica, mounting the configuration data into the nginx
// container.
const nginx = new k8s.apps.v1.Deployment(appName, {
 metadata: { labels: appLabels },
 spec: {
 replicas: 1,
 template: {
 metadata: { labels: appLabels },
 spec: {
 containers: [
 {
 image: "nginx:1.13.6-alpine",
 name: "nginx",
 volumeMounts: [{ name: "nginx-configs", mountPath: "/etc/nginx/conf.d" }],
 },
 ],
 volumes: [{ name: "nginx-configs", configMap: { name: nginxConfigName } }],
 },
 },
 },
});

Applications shouldn’t crash because a dependency isn’t ready.

Kubernetes starts all services concurrently, letting containers crash and restart until all the resources have started. We can control restarts with a Retry pattern, which include:

Cancel the service and don’t allow repeated attempts.
Retry immediately for a specified number of times
Retry with a delay

Like Kubernetes, Pulumi attempts to start all services concurrently but understands resource dependencies that can prevent a resource from starting. It does this through resource inputs, i.e., properties needed to start a resource, and outputs, properties from resources that are inputs to other resources. Suppose an output of one resource is provided as an input to another. In that case, the engine records the dependency between resources as part of the state and uses this information when scheduling operations.

Outputs behave like promises because outputs are not fully known until the infrastructure resource has completed provisioning, which happens asynchronously. Outputs are also how Pulumi tracks dependencies between resources. Outputs, therefore, represent two things:

The eventual raw value of the output
The dependency on the source(s) of the output value

Pulumi automatically captures dependencies when you pass an output from one resource as input to another, ensuring that physical infrastructure resources are not created or updated until all their dependencies are available and up-to-date. Pulumi understands the dependencies between resources, which maximizes parallelism and ensures correct ordering. When you run the pulumi up command, Pulumi computes the desired state, compares it to the current infrastructure (if any), displays the delta, and lets you confirm and carry out the changes.

By default, if a resource must be replaced, Pulumi will attempt to create a new copy of the resource before destroying the old one. This is helpful because it allows updates to infrastructure to happen without downtime.

Naked Pods are prohibited

Pods not bound to a ReplicaSet or Deployment will not be rescheduled in the event of a node failure. A Deployment with a ReplicaSet ensures that the specified number of Pods is always available and a strategy to replace Pods (such as RollingUpdate) is preferable to creating Pods directly.

Pulumi’s policy as code solution, Crossguard, lets you create a policy that checks if there are naked Pods. Learn more about Crossguard.

const policies = new PolicyPack("best-practices", {
 policies: [
 {
 name: "pods-are-prohibited",
 description: "Checks that Kubernetes Pods are not being used directly.",
 enforcementLevel: "mandatory",
 validateResource: validateResourceOfType(k8s.core.v1.Pod, (_, __, reportViolation) => {
 reportViolation("Kubernetes Pods should not be used directly. " +
 "Instead, you may want to use a Deployment, ReplicaSet or Job.");
 }),
 }
 ],
});

Deploying pods without set memory and CPU limits

Although it’s best practice not to deploy Pods directly, we can still set resource limits for memory and CPU. If limits are not set, containers can use all available memory or CPU resources leading to unstable environments and possible node crashes. By setting resource limits, the kube-scheduler can determine which Node to create a Pod and efficiently use cluster resources.

In this example, we create a ResourceQuota with the label namespace. When we create a deployment or replicaset, we can define a label selector, namespace: appsNamespaceName to enforce the quota.

import * as k8s from "@pulumi/kubernetes";

// Create a resource quota in the apps namespace.
const quotaAppNamespace = new k8s.core.v1.ResourceQuota("apps", {
 metadata: {namespace: appsNamespaceName},
 spec: {
 hard: {
 cpu: "20",
 memory: "1Gi",
 pods: "10",
 replicationcontrollers: "20",
 resourcequotas: "1",
 services: "5",
 },
 }
},{
 provider: cluster.provider
});

Don’t pull the latest tag in containers in production

Another best practice is to pin the version of an image by its tag. When a Pod crashes, Kubernetes pulls down the latest version of an image by default if the tag is not specified when a Pod is restarted. This can cause the application to crash if a Pod is no longer available because the image has changed. For example, an application may need to connect to a database, but if the most recent database image changes the authentication method, the application won’t be able to connect.

We can use policy as code to check resource properties such as the image tag. The example policy below checks every image in a Deployment to ensure that it does not have a latest tag.

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, (resource, _, reportViolation) => {
 resource.spec?.template?.spec?.containers.forEach(it => {
 if (it?.image?.endsWith(":latest")) {
 reportViolation("Image version should not be 'latest'.");
 }
 });
 }),
 },
 ],
});

Mixing both production and non-production workloads in the same cluster

Namespaces in Kubernetes support multiple environments on the same cluster. Each namespace is, in effect, a virtual cluster within the physical cluster. While there are operational gains and cost advantages by mixing multiple environments in the same cluster, mixing other environments with production can impact application performance and security by either competition for resources or by increasing the production attack surface because it’s not isolated from other environments.

Your production environment should be rock solid and separate from other environments. One way to separate environments is to tag resources such as clusters and use policy to enforce that the cluster is only used for production.

The example script below shows how to tag a resource when it’s created.

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

const foo = new aws.ecs.cluster("foo", {
 tags: {
 "environment:production",
 },
})

The following policy validates if a resource is tagged ‘production.’

import * as policy from "@pulumi/policy";
import { isTaggable } from "../lib/taggable";

const requiredTags = ["environment"];

new policy.PolicyPack("aws-tags-policies", {
 policies: [{
 name: "check-production-tags",
 description: "Ensure required tags are present on all production resources.",
 configSchema: {
 properties: {
 requiredTags: {
 type: "array",
 items: { type: "string" },
 },
 },
 },
 validateResource: (args, reportViolation) => {
 if (requiredTags && isTaggable(args.type)) {
 const ts = args.props[tags];
 for (const rt of requiredTags) {
 if (rt != "production" || !ts[rt]) {
 reportViolation(`Only production resources are allowed.`);
 }
 }
 }
 },
 }],
});

interface AwsTagsPolicyConfig {
 requiredTags?: string[];
}

Read more about tagging resources on the Pulumi blog.

Automate Best Practices

Infrastructure as code provides fine-grained control over resources and helps you avoid Kubernetes and container anti-patterns. The ability to programmatically tag resources and associate policies is just one way to implement best practices. In addition, Pulumi’s deployment engine is designed to handle asynchronous deployment patterns and concurrently create services efficiently and reduces thrashing from restarts.

Learn how to manage Kubernetes with code with these resources:

Kubernetes Tutorials Crosswalk for Kubernetes Crossguard - Policy as Code

Getting Started With Kubernetes: Day 2

Sophia Parafina — Mon, 10 Aug 2020 00:00:00 +0000

Your application made it out of the dev stage, passed the testing stage, and arrived in production. As a developer, you might think that it’s an ops problem now. However, DevOps is a collaborative effort between developers and operators to build and maintain applications using shared techniques and processes, often called “Day 2” activities.

Day 2 tasks fall into three categories. The first category is managing cluster components. It involves managing nodes, users and groups, ingress and egress, networking, storage, and operators. The second category is changing cluster components, including setting optimal resource quota, reclaiming unneeded resources, scaling, tuning and updating clusters, and managing CRDs. The third category of tasks is cluster monitoring and logging, which involves collecting and analyzing metrics, and monitoring the health of the cluster.

Although this subject is much deeper than we can cover in a single article, let’s take a look at how infrastructure as code can simplify some of these tasks.

Managing secrets

In addition to managing users and groups, managing secrets such as credentials is an important task. The Pulumi CLI lets you rotate the secrets provider for a stack. This is particularly important when people leave an organization or if you want to change to a different secrets provider, e.g., from Vault to AWS KMS. Also, we can copy secrets from one stack to another. A frequent use of this capability is to copy database account credentials from one stack to another. You can read more about managing secrets and the using the CLI to rotate providers on the Pulumi blog.

Updating clusters

When you first deploy an application in production, you make assumptions about the configuration. However, as the number of users increases or features are added, the cluster configuration will change. Moving to larger machines that can support more nodes is common; however, we want to make that change without disrupting the service. To accomplish the update, we want to create the new larger node group, migrate the application, and decommission the preceding node group. Pulumi shows you how to do this in a tutorial. A more descriptive blog post walks you through the project source code.

In addition to zero downtime cluster migrations, we can also control scaling. The following tutorial shows how to stage an application rollout from dev to testing controlled by performance collecting metrics. In this tutorial, we move a three replica canary to a ten replica staging deployment. Replicas are added based on a P90 response time, i.e., 90% of requests are processed within 2.75 seconds. The example uses Prometheus to collect the response times and a utility class to perform the health check. Check out the complete code on Github.

Pulumi also lets you keep an eye on your Kubernetes resources in real-time with Pulumi watch. Results are updated live as you make changes like adding replicas or exposing an application with a load balancer.

Monitoring

There are many logging and monitoring solutions available for Kubernetes. In the previous section, we used Prometheus for generating metrics. Pulumi supports logging and monitoring tools to assist with cluster and application management.

Kubernetes Cluster Services provide logging and monitoring at the cluster level or a subset of apps and workloads. Check out our tutorials for setting up logging and monitoring for Kubernetes on AWS, Azure, and GCP. The tutorial also shows how to configure DataDog to log and monitor applications. The example code is on Github.

Summary

Maintaining a Kubernetes cluster and modern applications can be varied and complex. However, infrastructure as code lets developers and operators use a common language to manage the cluster and resources. Pulumi has a rich toolset to help you accomplish Day 2 tasks, whether managing cluster components such as secrets, changing cluster components to scale applications, or logging and monitoring your cluster and resources.

Each article in this series is intended to be independent of each other. However, we build upon concepts introduced in previous articles.

Getting Started With Kubernetes: Networking

Sophia Parafina — Thu, 30 Jul 2020 00:00:00 +0000

In previous installments, we examined how to deploy applications. However, we only touched on how applications talk to each other inside and outside the cluster. Whether you are building a modern application or modernizing a legacy application, understanding how resources and components talk to each other is essential. In this installment, we’ll examine networking in Kubernetes.

Networking in a distributed environment can be complicated. Let’s use a hypothetical example of a web application deployed as microservices in Kubernetes. Containers must be able to communicate with each other; for example, we have a Java app running on Tomcat served by Nginx for the application’s frontend.

Pods must be able to connect to other pods. In our example, the frontend sends requests to a REST API connected to a database deployed as a StatefulSet in another Pod. Kubernetes assigns each Pod an IP address, which lets them send requests to each other.

However, as Pods are destroyed and created, the IP addresses will change. Kubernetes uses the Service object as an abstraction to define a logical set of Pods, labels and selectors to access them.

Our web application also needs to be available outside the cluster. We’ll examine how traffic receives and responds to requests outside the cluster.

Container to container networking

A Pod is a logical host, and each Pod is assigned a network namespace, which is a logical networking stack that provides isolation between network devices. Containers in a Pod have the same IP address assigned to the Pod’s networking namespace, which means that containers within a Pod can communicate using localhost. In our example application, the nginx container at port 80 is a reverse proxy for the Java application at port 8080. At this point, neither the Java application nor the reverse proxy is available outside the cluster. We could define a nodePort, a LoadBalancer, or Ingress to expose the pod outside of the cluster, but we’ll address that later.

What does this look like in code?

// Create the frontend Pod.
const pod = new k8s.core.v1.Pod("frontend", {
 spec: {
 restartPolicy: "OnFailure",
 containers: [
 {
 name: "nginx",
 image: "nginx",
 resources: {requests: {cpu: "50m", memory: "50Mi"}},
 ports: [{ containerPort: 80 }],
 },
 {
 name: "webapp",
 image: "java_app",
 resources: {requests: {cpu: "50m", memory: "50Mi"}},
 ports: [{ containerPort: 8080 }],
 command: [ "catalina.sh", "run"],
 }
 ],
 }
}, { provider: provider });

Pod to Pod networking

In our the web application example, the REST microservice and the database are deployed in separate pods. The frontend pod sends requests to the REST microservice, which sends requests to the database and returns data to the frontend application.

Pods can communicate with any Pod on any Node without a NAT (Network Address Translation). Pod to Pod networking is accomplished through a virtual ethernet device on the Node. Each Pod connects to a virtual ethernet device (called vethx) that acts as a tunnel between the Pod and the Node. A network bridge (called cbr0) connects the Pod’s network stack to the Node’s network by creating a single aggregate network from multiple networks.

A Pod can communicate with Pods on different Nodes. If the Pod isn’t found on the Node, the network bridge goes to the cluster level to map the IP address ranges to nodes. Once the Pod with the matching address range is found, the request is sent to the target Pod. In our example, the webapp sends a request to the database (10.0.20.1) on another node.

Pod to Service networking

Pods are ephemeral, Kubernetes add or destroy pods when scaling up or down, applications crash, and runtimes reboot. Pod IP addresses are dynamic; Services are built to ensure that network traffic reaches the correct Pod by managing the state of Pods.

Kubernetes assigns a virtual IP address called a clusterIP when a Service is created. Multiple Pods can be associated with a service, and Kubernetes load-balances requests to Pods associated with a Service. Kubernetes keeps track of changing IP addresses through these three methods: iptables, IPVS, and DNS.

Let’s take a look at iptables, which is a common case. Each node has a kube-proxy which maintains a table of IP addresses for nodes. The table keeps track of how to reach Pods inside or outside your cluster. Kube-proxy watches for the addition and removal of Service and Endpoint objects, which are the list of addresses (IP and port) of endpoints that implement a Service.

Iptables use fewer system resources because traffic is handled by Linux netfilter, a packet filtering framework inside the Linux kernel. This means that routing traffic doesn’t require switching between the user space where Kubernetes is running and makes use of the host system’s kernel network stack, which also makes it more reliable.

In iptables mode, if the first Pod selected fails to respond, the connection fails. You can use readiness probes to tell kube-proxy which pods are healthy as in this example.

There are other methods of Pod to Service networking, such as:

userspace with kube-proxy.
IP Virtual Server (IPVS), an in-cluster load balancer that uses more efficient hash tables that scale better than iptables.
DNS running as a Kubernetes service

We’ve reviewed how packets are routed between Pods and Services, but how does this work in practice? A Service is a logical collection of pods with a policy that defines access among them. Pods are grouped into a Service with labels and selectors. In our web application example, we can label Pods with “webapp” and declare the service’s selector.

Below is an example of how to create a service with code.

const frontendLabels = { app: "frontend" };
const frontendDeployment = new k8s.apps.v1.Deployment("frontend", {
 spec: {
 selector: { matchLabels: frontendLabels },
 replicas: 3,
 template: {
 metadata: { labels: frontendLabels },
 spec: {
 containers: [
 {
 name: "nginx",
 image: "nginx",
 resources: { requests: { cpu: "100m", memory: "100Mi" } },
 env: [{ name: "GET_HOSTS_FROM", value: "env" }],
 ports: [{ containerPort: 80 }],
 },
 {
 name: "webapp",
 image: "java_app",
 resources: { requests: { cpu: "100m", memory: "100Mi" } },
 env: [{ name: "GET_HOSTS_FROM", value: "env" }],
 ports: [{ containerPort: 8080 }],
 },

 ],
 },
 },
 },
});
const frontendService = new k8s.core.v1.Service("frontend", {
 metadata: {
 labels: frontendDeployment.metadata.labels,
 name: "frontend",
 },
 spec: {
 type: LoadBalancer,
 ports: [{ port: 80 },{ port:8080 }],
 selector: frontendDeployment.spec.template.metadata.labels,
 },
});

Egress and Ingress

Egress is moving data and requests from the cluster to the Internet. Kubernetes can accomplish egress with an Internet gateway that routes packets from inside the cluster by performing network address translation (NAT). NAT maps a Node’s internal IP address to an external IP address on the public Internet.

However, Pods have their IP address that virtual machines or Nodes can’t reach. If we trace a packet’s route, it starts from the Pod’s namespace and connects to root namespace of the Node via veth to the network bridge, cbr0. Iptables replaces the source IP of the Pod to the Node Ip address to get from the Node to the gateway. Changing the source IP is called a source NAT (SNAT), and it lets the packet travel from the Node to the Internet gateway.

Ingress is the process of routing Internet traffic to the Kubernetes cluster. There are two solutions for getting Internet traffic into your cluster: a Service LoadBalancer and an Ingress controller.

A Service load balancer is also called a Layer 4 LoadBalancer. The name refers to Layer 4, or the transport layer of the OSI network model. At Layer 4, the transport layer routes packets and resends them if they are not received. You can specify a LoadBalancer when creating a Service. The Service will advertise the IP address, and you can send traffic to LoadBalancer, which will route packets to the service.

Kubernetes can create a Service with an optional LoadBalancer. When the Service is created, it advertises the IP address for the load balancer. As an end-user, you can start directing traffic to the load balancer to begin communicating with your Service.

The load balancer is not aware of Pods or containers, so it sends packets to the Nodes in the cluster. The iptables rules in each Node will send the packets to Pod. The Pod’s response uses the Pod’s IP, but iptables rewrites the correct IP on the return with NAT.

The other way of routing packets to a pod from a gateway is with a Layer 7 Ingress Controller. Layer 7 is the application layer of the OSI network model. Layer 7 Ingress works on the HTTP/HTTPS portion of the network stack. Similar to a Layer 4 LoadBalancer, it is part of a Service. You must open a port in the Service with the NodePort Service type, and Kubernetes will allocate a port from a specified range. Traffic routed to the Node’s port will be sent to the service by iptables rules.

An Ingress object exposes a Node’s port to the Internet. An Ingress load balancer maps HTTP requests to Kubernetes Services. The Ingress method differs depending on how the Kubernetes provider implements it. HTTP load balancers, like Layer 4 network load balancers, only understand Node IPs (not Pod IPs), so traffic routing uses the internal load-balancing in iptables installed on each Node by kube-proxy.

Within an AWS environment, the ALB Ingress Controller provides Kubernetes Ingress using Amazon’s Layer 7 Application Load Balancer. The following diagram details the AWS components this controller creates. It also demonstrates the route Ingress traffic takes from the ALB to the Kubernetes cluster. This process is similar to a Layer 4 Load Balancer, but the significant difference is that the Application Load Balancer is HTTP aware and can perform host or path based routing.

Building on the previous example, we can expose the frontend by adding the following.

export const frontendIp: pulumi.Output<string>;
frontendIp = frontend.status.loadBalancer.ingress[0].ip;

Summary

The goal of this article is to provide an overview of the Kubernetes Networking model. The implementation of the Container Network Interface (CNI) varies from provider to provider. You can read more about CNI implementations on the Kubernetes documentation site.

Each article in this series is intended to be independent of each other. However, we build upon concepts introduced in previous articles.

Getting Started with Kubernetes: Stateful Applications

Sophia Parafina — Tue, 21 Jul 2020 00:00:00 +0000

This article is the fourth in a series using infrastructure as code to deploy applications with Kubernetes.

In the previous post, we examined different methods for deploying applications. We worked through examples of a boilerplate deployment, to one using ComponentResources to automate deployment further, and deploying with Helm charts. In this installment, we’ll look at how to deploy stateful applications, such as databases, in Kubernetes. Unlike stateless applications, stateful apps require persistent storage, which presents scaling and availability challenges.

Stateful vs. Stateless

Stateless applications don’t require information from a previous transaction because they are single request and response. For example, the “Hello World” example that we deployed in an earlier article is a stateless application. The critical thing to remember is that in Kubernetes, any container with that application in any pod can respond to that request. Stateful applications can read or store information about previous transactions, and a transaction is executed within the context of a previous extraction. Email is an example of a stateful application; an email can be unread or read, or it can be grouped according to keywords or by content. In stateless applications, access to storage must be coordinated, either by sending all requests to the same Pod, or by synchronizing across multiple Pods.

Stateful sets

Stateful sets are the Kubernetes workload object for managing stateful applications. They are a specialized type of Deployments, where the Pods maintain a persistent identity during updates and rescheduling.

You would use a StatefulSet for:

stable and unique network identifiers
stable and persistent storage
applications that require ordered deployment and scaling
applications that require ordered and rolling updates

When a StatefulSet is created, each Pod is assigned a unique and persistent identifier. Pods are named numerically starting from 0, e.g., pod-0, pod-1, pod-n. StatefulSets use a Headless Service resource, which sets the clusterIP property to none. Pods in a StatefulSet will have an IP address mapped directly to them instead of a virtual IP address. This lets other Pods in the cluster directly communicate to an application, as in database connections.

StatefulSets can control the order of starting and stopping Pods. Some applications require a resource to be available before the Pod can be marked healthy. A Pod in a StatefulSet can be mounted to a dedicated persistent volume by declaring a PersistentVolumeClaim. If a Pod in a StatefulSet shuts down, the StatefulSet Controller will relaunch a replacement Pod with the same network identifier and reattach it to the persistent Volume.

StatefulSets have two update strategies. The OnDelete strategy does not automatically update the Pods, and they must be manually deleted for the controller to create new Pods. Rolling updates automatically deletes and creates a replacement for Pods in a StatefulSet. It creates replacement in the same order as they are deleted, which is from the highest to the smallest numbered Pod. A replacement Pod must be ‘Running and Ready’ before it replaces the preceding Pod.

Example

Let’s see how this works in practice with a MariaDB deployment in Kubernetes. The example begins with defining the cluster configuration and the MariaDB configuration using a ConfigMap. We’ll skip over this and go straight to the StatefulSet.

Headless Service

In the previous section, we described the Headless Service. The key parts are setting the ClusterIP to "None", which allocates an IP address and port so that applications can establish a database connection.

Deployment

Let’s look at the StatefulSet, step-by-step. The spec matches the StatefulSet to the Headless Service using a selector that matches the labels. We assign it a service name, specify a single replica, and a RollingUpdate update strategy. Note that this is the default update strategy, but it’s a good practice to declare it.

Pod scheduling

The next section declares variables for MariaDB, such as the serviceAccountName and the securityContext. However, of interest is the podAntiAffinity parameter, which ensures that the Pod will not be deployed on a Node with a Pod with the labels ‘mariadb’ and ‘example’. The weight is set for the preferred rule, where a node with a higher weight is preferred. We prevent another instance from being deployed on the same host by setting topologyKey: "kubernetes.io/hostname".

Putting it all together, we’ve told the Kubernetes Scheduler never to co-locate two Pods that have the app labels “mariadb” and “example” in the same domain (or Node) defined by setting topologyKey:”kubernetes.io/hostname”. These parameters control Pod scheduling to ensure that if a Pod is replaced, the new Pod is addressable by other resources in the application.

Configure the MariaDB container

The following section configures the MariaDB container. We’ll skip the part of the container configuration and look at healthchecks that impact the Pod’s scheduling. The livenessProbe is useful for detecting if a long-running application, such as a database, is broken and cannot recover except by a restart. In this example, we call the mysql init script as a status check. If the container fails the livenessProbe, the Kubernetes scheduler will kill the Pod and replace it. A readinessProbe is similar to a livenessProbe; if the probe fails, Kubernetes won’t send traffic to the Pod. Unlike a livenessProbe, the Pod remains running and is not terminated and replaced by the scheduler. Probe field or settings are described in the Kubernetes documentation.

We also configure two volumeMounts. The first volumeMount sets the MariaDB data path to the data Volume. The second volumeMount mounts the MariaDB configMap that was defined earlier.

Create a Volume for storage

The final section of code creates a Persistent Volume using a volumeClaimTemplate. This object requests a PVC (PersistentVolumeClaim) from the storage class dynamically. We set the accessModes to “ReadWriteOnce”, which means the volume can be mounted as read-write by a single node. Other accessModes are “ReadOnlyMany”, where the volume can be mounted read-only by many nodes, and “ReadWriteMany”, where the volume can be mounted as read-write by many nodes. We also set the size of the Volume to 8 gigabytes.

To summarize, we deployed MariaDB using a StatefulSet by creating a headlessService which assigns a persistent IP address to the Pod instead of using clusterIP and nodePorts to route traffic to the application. We then defined Node Affinity/AntiAffinity to set rules on which nodes are selected by the scheduler for creating Pods. Next, we configured the container and set livenessProbes and readinessProbes to tell the Scheduler if a Pod needs to be terminated and restarted or not to route traffic to the Pod until it is ready. We also configure volumeMounts and volumes to store configuration information and data for MariaDB.

Conclusion

Stateful applications present additional challenges when deployed in Kubernetes. Many applications require a stateful resource, such as a database or a component that maintains a login and session id. Stateful applications route traffic to a stable and persistent resource. Kubernetes accomplishes this with StatefulSets, which creates resources with a persistent id and unique address. We can configure scheduling and replacement of Pods, to allow resources to continue using a persistent id and address. We can also configure containers with health checks to signal if a Pod should be terminated or if it should continue to receive requests. We can also control which Node can access a PersistentVolume with a volumeClaimTemplate, and in our example, we limit access to only one Node. Make sure to try out the complete example on Github.

In the next series installment, we’ll examine Kubernetes networking. Until then, you can learn more about Kubernetes with these resources:

Watch educational content on Pulumi TV
Learn more about Pulumi’s support for Kubernetes
Practice Kubernetes Tutorials using Pulumi

Build a Pulumi VS Code Devcontainer Environment

Sophia Parafina — Tue, 14 Jul 2020 00:00:00 +0000

One of the major advantages of using containers for development is reducing the need to install software and associated dependencies. Developers can start writing code without configuring a development environment that emulates production. The Visual Studio Code Remote - Containers extension lets you develop inside a container. If you want to use Pulumi’s infrastructure as code engine without installing the Pulumi CLI, this blog post is for you!

Pre-requisites

To set up your development environment, you’ll need Visual Studio Code, Docker Desktop, and the Remote - Containers extension.

Check to see if Docker is running:

$ docker --version
Docker version 19.03.8, build afacb8b

Check to see if the Remote - Containers is installed:

Click on the green icon in the Remote Status Bar to display the commands:

Building the Pulumi container

Now we can start!

Create a directory for your project.
```
$ mkdir my_devcontainer
$ cd my_devcontainer
```
Open the directory in VS Code.
Next, we’ll create the devcontainer configuration files. Click on the Remote Status button and select Add Development Container Configuration Files ….
Select the latest version for Alpine. We’ll replace the Dockerfile with the Pulumi Dockerfile.

VS Code will display a popup asking to build the container. Dismiss the popup, we will replace the Dockerfile with the Pulumi Dockerfile.

In your project directory, you’ll see a .devcontainer directory with a Dockerfile that builds the container and a devcontainer.json for configuring the container environment.

Dockerfile

For this example, we’ll use the standard Pulumi Dockerfile, which includes the SDK for all the supported languages. Download the Dockerfile and save it to the .devcontainer directory.

$ cd .devcontainer
$ curl "https://raw.githubusercontent.com/pulumi/pulumi/master/.devcontainer/Dockerfile" -o Dockerfile

Container configuration

Next, we’ll clean up the .devcontainer/devcontainer.json file and set up the necessary credentials.

First edit devcontainer.json as follows:

Replace the “name” field with Pulumi
Remove the “args” line
Replace the “remoteUser” value with user

Regardless of your cloud provider, you will have to provide your credentials to deploy resources. If you want to save your project to Github or another repository, you don’t want your credentials stored in the repository. There are several ways to do this securely. Using AWS as an example, you can export them inside the container, e.g.,

Linux/macOS:

export AWS_ACCESS_KEY_ID=AKIAI44QH8DHBEXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Windows:

SET AWS_ACCESS_KEY_ID=AKIAI44QH8DHBEXAMPLE
SET AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

The disadvantage of this method is that you will have to set these environment variables every time you start the devcontainer.

Use local environment variables

One alternative is to set the environment variables on your local machine and pass them to the container through the devcontainer.json file. This method requires that you have VS Code in your path and launch it from the shell.

Use CTRL+SHIFT+P or CMD+SHIFT+P to bring up the command palette and type Shell Command: Install ‘code’ command in PATH. You can set your credentials as environmental variables and launch the VS Code from the shell
```
$ export AWS_ACCESS_KEY_ID=AKIAI44QH8DHBEXAMPLE
$ export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
$ code .
```

Next, set your provider credentials on your machine and add the following to devcontainer.json.

"containerEnv": {
 "AWS_ACCESS_KEY_ID": "${localEnv:AWS_ACCESS_KEY_ID}",
 "AWS_SECRET_ACCESS_KEY": "${localEnv:AWS_SECRET_ACCESS_KEY}"
},

Use an .env file

Another alternative is to use a devcontainer.env file, which contains your credentials.

Create a file with your credentials.

AWS_ACCESS_KEY_ID=AKIAI44QH8DHBEXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Then add it to the devcontainer.json file.

"runArgs": ["--env-file","devcontainer.env"],

To prevent it from exposing your credentials on a public repository, add the file to .gitignore or similar for you repository, e.g.,
```
echo devcontainer.json > .gitignore
```

There are many more configuration options available, including mounts and remote configurations.

Try it out

Again, use the command palette to start the container. Use the Open Folder in Container… command, and select the project folder. If you’ve already got the folder open locally, you could also use the Reopen in Container command.

Check to see if your credentials are set. Open a terminal in VS Code if it isn’t already open.

$ user@973a612c1555:/workspaces/my_devcontainer# env | grep AWS
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
AWS_ACCESS_KEY_ID=AKIAI44QH8DHBEXAMPLE

Now we ready to use Pulumi in our VS Code development environment! Let’s try it out by creating an S3 bucket. First, we’ll make a directory for our project and use pulumi new to create a default project.

$ mkdir my_project
$ cd my_project
$ pulumi new aws-typescript

Follow the prompts, then run pulumi up to deploy.

$ pulumi up
Previewing update (dev):
 Type Name Plan
 + pulumi:pulumi:Stack my_project-dev create
 + └─ aws:s3:Bucket my-bucket create

Resources:
 + 2 to create

Do you want to perform this update? yes
Updating (dev):
 Type Name Status
 + pulumi:pulumi:Stack my_project-dev created
 + └─ aws:s3:Bucket my-bucket created

Outputs:
 bucketName: "my-bucket-cbdec06"

Resources:
 + 2 created

Duration: 31s

Permalink: https://app.pulumi.com/spara/my_project/dev/updates/1

You can CMD + click on the link to open a browser and display the status of your project on the Pulumi Service.

Build a Pulumi examples devcontainer

Pulumi has a repository of examples, and we can create a devcontainer from the repository so you can try them out.

Clone the repository, then follow the steps above to create and configure the Pulumi container image.
```
$ git clone https://github.com/pulumi/examples.git
```
Create the configuration files, add the Pulumi Docker file, and add your credentials.
Let’s deploy a Kubernetes cluster! With pulumi stack init, we can create a stack, but we will need to install the project dependencies and set configuration variables such as the region.
```
$ cd aws-ts-eks
$ pulumi stack init
$ npm install
$ pulumi config set aws:region us-west-2
$ pulumi up
```

Here’s the kubeconfig file’s output, which you can use with kubectl to manage the cluster.

Outputs:
 kubeconfig: {
 apiVersion : "v1"
 clusters : [
 [0]: {
 cluster: {
 certificate-authority-data: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01EY3hNVEl5TXpZMU9Wb1hEVE13TURjd09USXlNelkxT1Zvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTHFvCk9wTDBiQWo2TFFMNlh2anRsMFZ6TUN5WTJmYlo4cXEvNGd3bkJxcVI2RFV6Q1RwbkJmOHJVRjVrUXhBQXRUNysKTTFZblp5VEFBYndOZ3NIL3lObk5sMnFCQmRSQ0JZTVVlN1I2MVBxcGdabFZpN0JaNHRlek9DalRqeGV0SXlaMwoxRW9TdTNBYnhzTmh6dDVBTjVYZklnZlBuM3B2eEtwYTA1MEg3aWhFaUptSEl3M0Z5TVovUHpxY2JHczh3RHVCCk1jYjNzOHMwZDBIVExsb2dCL2svOVBLbGVpZDgyWFkxMEdBN0YxeFM2cFdZODkwQ1BwNXpWZ0pRWGhuRGR2S1gKVlFValdCTDZQYU14U0lBZEZQM1BZYk1FdXk5Vyt0c2lqc2VydThVNTVpUDlWSUdMdTZzdEdycTNuQUhtUk40UQpqeXRCRWd4RjN1R0dtZ0dMOStFQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFEcUtyVGVnZmhWbElNUklQNjFVZEtvaGtnS3MKblUyZjUvTHBzU3ozbmliUCt3Y2VpNktYL3RSNjAzTHhFMlVXUTlmR0ZycTBCMTlJR1JaK0VVQjl2Vy9JdWowTApVK2UwUUtWc01qd2dMWm4rS3IyN0VQNUNGay8vZEVCRUZqa01PMmNlTFFRaFcvUXFzSFhJb2ZjZ0UvZnJ3YzErCmQwdGROWmxJa3JRdzJwYnVhcVI0VmRlWlpVSitqbW8rdEo1SlZ5a2Rwa29JYml1ZEZ6Q0N5YVB1LzhJc09CTUsKcWtvTFpNazdBMzh5SWxDK2RCTnJwdkQvRTF5U1lhcXlDaE5CdVBkd1VqcWZaWmJmaWR5N050emd2VjMvUWFtWgpuZUJJcWs0c1AzSWU0TUN0QmV4bU9iSWowdVBLTnVCQ01UTStxSVI2UWdnYXdEbWxXcXE4V0ZiUlNJMD0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo="
 server : "https://3FE47B904E57AF9E16E0B7F00C7EEABA.yl4.us-west-2.eks.amazonaws.com"
 }
 name : "kubernetes"
 }
 ]
 contexts : [
 [0]: {
 context: {
 cluster: "kubernetes"
 user : "aws"
 }
 name : "aws"
 }
 ]
 current-context: "aws"
 kind : "Config"
 users : [
 [0]: {
 name: "aws"
 user: {
 exec: {
 apiVersion: "client.authentication.k8s.io/v1alpha1"
 args : [
 [0]: "eks"
 [1]: "get-token"
 [2]: "--cluster-name"
 [3]: "cluster-eksCluster-367b66b"
 ]
 command : "aws"
 }
 }
 }
 ]
 }

You can now try out any of our infrastructure as code examples with this devcontainer.

Conclusion

As you can see, we’ve built our development with VS Code and Docker. Using a Pulumi devcontainer lets you build and deploy infrastructure without installing Pulumi or any associated dependencies on your computer. Moreover, you can share your development environment by creating a repository. Give it a try and let us know what you’re building on Slack or Twitter.

Getting Started With Kubernetes: Advanced Deployment

Sophia Parafina — Thu, 09 Jul 2020 00:00:00 +0000

Welcome to the third article in a series using infrastructure as code to deploy applications with Kubernetes. In the previous post, we reviewed basic Kubernetes objects and abstractions used when deploying an application. We examined code examples across the cloud providers to show how to use infrastructure as code to deploy an application using Kubernetes objects. In this installment, we’ll progress from a simple deployment with just a single application container to a complex application with multiple containers and Pods.

This article reviews three types of application deployment scenarios with commonly used examples. The first scenario is a 12-factor microservices multi-tier application consisting of multiple frontend and backend services backed by databases and a messaging queue to handle requests. The second scenario takes the Kubernetes guestbook and turns the Service and Deployment into a single component, demonstrating another pattern for organizing your stack. The third scenario shows how to deploy a popular web application using a Helm, the package manager for Kubernetes.

In this article, we’ll assume that we already have a Kubernetes cluster available. You will have to set the context with kubectl to deploy the examples in this article. Because of Kubernetes’ OpenAPI, we can use the same Typescript application code on any compliant instance.

Sock Shop Microservices

We’ll use the Sock Shop microservices reference application. This is a polyglot application comprised of microservices written in Java, Go, and Node. This demo application adheres to the 12-factor app pattern by creating a microservice for each function. The application services will be deployed to pods, and they communicate with each other via REST calls over HTTP.

Let’s look at the Orders microservice, which is made up of a service worker and MongoDB for a backing service. Note that the code is organized by microservice with a separate Deployment and Service for each service and backing resource. The ordersDb configuration is straightforward, of note are the options in the container spec where we set securityContext and a emptyDir volume for storage. An emptyDir volume persists even if the container crashes, and the data in the volume is available if the container is restarted. The service definition for ordersDbService is also simple and opens port:27017 and ties the service back to the Deployment by the orders-db label.

const sockShopNs = new k8s.core.v1.Namespace("sock-shop", { metadata: { name: "sock-shop" } });

// --------------------------------------------------------------------------
// Orders microservice.
// --------------------------------------------------------------------------

const ordersDb = new k8s.apps.v1.Deployment("orders-db", {
 metadata: {
 name: "orders-db",
 labels: {
 name: "orders-db",
 },
 namespace: sockShopNs.metadata.name,
 },
 spec: {
 replicas: 1,
 template: {
 metadata: {
 labels: {
 name: "orders-db",
 },
 },
 spec: {
 containers: [
 {
 name: "orders-db",
 image: "mongo",
 ports: [
 {
 name: "mongo",
 containerPort: 27017,
 },
 ],
 securityContext: {
 capabilities: {
 drop: ["all"],
 add: ["CHOWN", "SETGID", "SETUID"],
 },
 readOnlyRootFilesystem: true,
 },
 volumeMounts: [
 {
 mountPath: "/tmp",
 name: "tmp-volume",
 },
 ],
 },
 ],
 volumes: [
 {
 name: "tmp-volume",
 emptyDir: {
 medium: "Memory",
 },
 },
 ],
 nodeSelector: {
 "beta.kubernetes.io/os": "linux",
 },
 },
 },
 },
});

const ordersDbService = new k8s.core.v1.Service("orders-db", {
 metadata: {
 name: "orders-db",
 labels: {
 name: "orders-db",
 },
 namespace: sockShopNs.metadata.name,
 },
 spec: {
 ports: [
 {
 port: 27017,
 targetPort: 27017,
 },
 ],
 selector: ordersDb.spec.template.metadata.labels,
 },
});

The orders Deployment is similar to the ordersDb Deployment, but it includes environmental variables, such as JAVA_OPTS to set heap memory size and garbage collection intervals, for the containerized application. The container runs as a non-root user and drops all capabilities that can run as a non-root user, except for NET_BIND_SERVICE, which lets the container bind to any port.

const orders = new k8s.apps.v1.Deployment("orders", {
 metadata: {
 name: "orders",
 labels: {
 name: "orders",
 },
 namespace: sockShopNs.metadata.name,
 },
 spec: {
 replicas: 1,
 template: {
 metadata: {
 labels: {
 name: "orders",
 },
 },
 spec: {
 containers: [
 {
 name: "orders",
 image: "weaveworksdemos/orders:0.4.7",
 env: [
 {
 name: "ZIPKIN",
 value: "zipkin.jaeger.svc.cluster.local",
 },
 {
 name: "JAVA_OPTS",
 value:
 "-Xms64m -Xmx128m -XX:PermSize=32m -XX:MaxPermSize=64m -XX:+UseG1GC -Djava.security.egd=file:/dev/urandom",
 },
 ],
 ports: [
 {
 containerPort: 80,
 },
 ],
 securityContext: {
 runAsNonRoot: true,
 runAsUser: 10001,
 capabilities: {
 drop: ["all"],
 add: ["NET_BIND_SERVICE"],
 },
 readOnlyRootFilesystem: true,
 },
 volumeMounts: [
 {
 mountPath: "/tmp",
 name: "tmp-volume",
 },
 ],
 },
 ],
 volumes: [
 {
 name: "tmp-volume",
 emptyDir: {
 medium: "Memory",
 },
 },
 ],
 nodeSelector: {
 "beta.kubernetes.io/os": "linux",
 },
 },
 },
 },
});

const ordersService = new k8s.core.v1.Service("orders", {
 metadata: {
 name: "orders",
 labels: {
 name: "orders",
 },
 namespace: sockShopNs.metadata.name,
 },
 spec: {
 ports: [
 {
 port: 80,
 targetPort: 80,
 },
 ],
 selector: orders.spec.template.metadata.labels,
 },
});

If we look at the orders-db deployment manifest, we can see that the code follows it closely. You can find the full Sock Shop code in the Pulumi examples repository.

Although we encapsulate the deployment in a single large script, we can improve that by creating components using classes to abstract the implementation details.

Deploying Guestbook as a Component

We can abstract objects, such as Deployments and Services, into components to create our resources. ComponentResource is Pulumi construct or resource that can aggregate other resources into a combined resource. Let’s take a look at how we implement the Guestbook with components.

The Kubernetes GuestBook is a canonical example of a stateless application. It consists of multiple PHP frontend services backed by Redis replicas and a lead Redis database to store guestbook entries. In the previous example, we created a Deployment and a Service for each microservice in the application. Although this is a valid pattern for deploying an application in Kubernetes, it doesn’t take full advantage of the capabilities of infrastructure as code.

When you examine index.ts, the main program, you’ll notice that it imports the k8sjs module. Note that each service is instantiated by calling the ServiceDeployment class and passing arguments such as the image, ports, and replicas. As you can see, this is a more efficient way to deploy services than coding individual Deployments and Services.

import * as pulumi from "@pulumi/pulumi";
import * as k8sjs from "./k8sjs";

const config = new pulumi.Config();

const redisLeader = new k8sjs.ServiceDeployment("redis-leader", {
 image: "redis",
 ports: [6379],
});

const redisReplica = new k8sjs.ServiceDeployment("redis-replica", {
 image: "pulumi/guestbook-redis-replica",
 ports: [6379],
});

const frontend = new k8sjs.ServiceDeployment("frontend", {
 replicas: 3,
 image: "pulumi/guestbook-php-redis",
 ports: [80],
 allocateIpAddress: true,
 isMinikube: config.getBoolean("isMinikube"),
});

export const frontendIp = frontend.ipAddress;

The ServiceDeployment class is defined in the k8sjs module using ComponentResource. We define deployment, service, and ipAddress as public read-only properties. The constructor takes three arguments:

name: The unique name of the resource.
args: Information passed to [initialize] method.
opts: A bag of options that control this resource’s behavior.

ServiceDeploymentArgs is the interface for the arguments used to initialize the method. Next, we instantiate the container using the container image property from the ServiceDeploymentArgs and configure resources, environmental variables, and ports. The deployment is instantiated with the properties you typically see in a deployment such labels, selectors, containers, and replicas. The same goes for Services. Finally, based on whether Kubernetes is running on cluster or Minikube, the ServiceDeployment class returns the clusterIP if it runs on Minikube or instantiates a load balancer if it is a cluster.

import * as k8s from "@pulumi/kubernetes";
import * as k8stypes from "@pulumi/kubernetes/types/input";
import * as pulumi from "@pulumi/pulumi";

/**
 * ServiceDeployment is an example abstraction that uses a class to fold together the common pattern of a
 * Kubernetes Deployment and its associated Service object.
 */
export class ServiceDeployment extends pulumi.ComponentResource {
 public readonly deployment: k8s.apps.v1.Deployment;
 public readonly service: k8s.core.v1.Service;
 public readonly ipAddress?: pulumi.Output<string>;

 constructor(name: string, args: ServiceDeploymentArgs, opts?: pulumi.ComponentResourceOptions) {
 super("k8sjs:service:ServiceDeployment", name, {}, opts);

 const labels = { app: name };
 const container: k8stypes.core.v1.Container = {
 name,
 image: args.image,
 resources: args.resources || { requests: { cpu: "100m", memory: "100Mi" } },
 env: [{ name: "GET_HOSTS_FROM", value: "dns" }],
 ports: args.ports && args.ports.map(p => ({ containerPort: p })),
 };
 this.deployment = new k8s.apps.v1.Deployment(name, {
 spec: {
 selector: { matchLabels: labels },
 replicas: args.replicas || 1,
 template: {
 metadata: { labels: labels },
 spec: { containers: [ container ] },
 },
 },
 }, { parent: this });

 this.service = new k8s.core.v1.Service(name, {
 metadata: {
 name: name,
 labels: this.deployment.metadata.labels,
 },
 spec: {
 ports: args.ports && args.ports.map(p => ({ port: p, targetPort: p })),
 selector: this.deployment.spec.template.metadata.labels,
 // Minikube does not implement services of type `LoadBalancer`; require the user to specify if we're
 // running on minikube, and if so, create only services of type ClusterIP.
 type: args.allocateIpAddress ? (args.isMinikube ? "ClusterIP" : "LoadBalancer") : undefined,
 },
 }, { parent: this });

 if (args.allocateIpAddress) {
 this.ipAddress = args.isMinikube ?
 this.service.spec.clusterIP :
 this.service.status.loadBalancer.ingress[0].ip;
 }
 }
}

export interface ServiceDeploymentArgs {
 image: string;
 resources?: k8stypes.core.v1.ResourceRequirements;
 replicas?: number;
 ports?: number[];
 allocateIpAddress?: boolean;
 isMinikube?: boolean;
}

As this example demonstrates, components let you build higher-level objects from smaller resources. Using a programming language alleviates writing tedious boilerplate code and results in a more efficient and compact deployment.

Helm Charts

Helm is described as the package manager for Kubernetes. Applications are packaged in charts, a collection of files that declare and configure Kubernetes resources for an application. Helm Hub is a repository for charts with over 1000 applications ready for deploying in Kubernetes.

The code below is from the Kubernetes Typescript Helm Chart example. Deploying a Helm chart is uncomplicated; all you need to do is instantiate a Helm Chart object and provide a name and the appropriate properties.

import * as k8s from "@pulumi/kubernetes";
import * as pulumi from "@pulumi/pulumi";

// Minikube does not implement services of type `LoadBalancer`; require the user to specify if we're
// running on minikube, and if so, create only services of type ClusterIP.
const config = new pulumi.Config();
if (config.require("isMinikube") === "true") {
 throw new Error("This example does not yet support minikube");
}

// Deploy the latest version of the stable/wordpress chart.
const wordpress = new k8s.helm.v2.Chart("wpdev", {
 repo: "stable",
 version: "2.1.3",
 chart: "wordpress",
});

// Export the public IP for Wordpress.
const frontend = wordpress.getResourceProperty("v1/Service", "wpdev-wordpress", "status");
export const frontendIp = frontend.apply(status => status.loadBalancer.ingress[0].ip);

Choosing how to deploy

Using a Helm chart to deploy an application is the simplest solution if it’s a standard application. If you are deploying your application, you might start with a boilerplate code defining Deployments, Services, and other objects in a prototype and later refactor it using Components. These methods aren’t exclusive; for example, you could use a Helm chart to deploy an ELK stack to gather metrics from your application and display them using Kibana. As an application becomes more complex, e.g., every function is a microservice, it becomes more unwieldy and difficult to manage. Infrastructure as code can help reduce that complexity through abstracting resources into higher-level objects, applying software development practices to infrastructure, and enabling robust and reliable deployments.

Conclusion

This article demonstrated three ways to deploy an application in Kubernetes. The applications we examined are primarily stateless with no persistent storage or volumes. In the next installment, we’ll examine stateful services that require persistent storage such as a database. Until the next post, learn more about Kubernetes with these resources.

Watch educational content on Pulumi TV
Learn more about Pulumi’s support for Kubernetes
Practice Kubernetes Tutorials using Pulumi

Getting Started With Kubernetes: Application Basics

Sophia Parafina — Tue, 30 Jun 2020 00:00:00 +0000

Welcome to the second article in a series using infrastructure as code to deploy applications with Kubernetes. The series walks you through building a Kubernetes cluster on cloud providers, deploying applications, and “Day 2” activities such as migrating Node groups. In the previous article, we showed how to create a Kubernetes cluster for AWS, Azure, and GCP. In this installment, we’ll learn how to deploy an application using Kubernetes objects.

Kubernetes has a rich feature set and it is important to keep in mind that Kubernetes is not merely a container orchestrator. It is designed to keep applications highly available and to scale on demand. It accomplishes this by running multiple instances of application containers and replacing them as needed.

There are many moving parts to Kubernetes, so let’s review the objects used to deploy applications in Kubernetes.

Pods

A Pod is where applications run, and it is the smallest unit of execution for Kubernetes. A Pod hosts one or more containers that make up a complete application. For example, a Pod can have a container running an entire LAMP stack for a web application, or it can run a container with NGINX that connects to a database running in another Pod.

Each Pod has an IP address and can address other Pods in the same network. In the previous article, we deployed clusters in a VPC. Pods deployed in a Kubernetes cluster can communicate with each other using TCP/IP, UDP, or SCTP. Containers within a Pod share the same IP address and port space, and can communicate via localhost or IPC, such as POSIX shared memory or SystemV semaphores.

Pods have a specific lifecycle. They are created, assigned a UID, scheduled to run on a Node, and run until they either fail or are terminated. When a Node dies, Pods are deleted and replaced onto other nodes. Pods have five distinct states or phases:

Pending The Pod has been scheduled for creation, but one or more containers have not been created.
Running The Pod has been created in the Node, all containers have been created, and at least one container is running.
Succeeded All the containers have been successfully terminated and will not be restarted.
Failed All containers have been terminated, but at least one container has exited with a failed non-zero status.
Unknown The state of the Pod was not returned, possibly due to a communication error.

When deploying an application, you can see the status of the Pods.

Services

A Service routes traffic to a logical set of Pods. For example, your application may deploy a web application, a data store for queued requests, and an RDBMS for customer data in separate Pods. A Service groups Pods using Labels and LabelSelectors. Labels are key/value pairs that you can use to identify objects meaningfully. Using the example above, the web application may be labeled tier : frontend and the database would be labeled tier : backend. Labels aren’t unique, and objects can have the same label. A LabelSelector identifies a set of objects and is a way to group objects.

Pod IPs are not exposed to traffic outside of the cluster. Applications require a Service to receive traffic, and by setting a ServiceSpec, they can be addressable by specifying a type:

ClusterIP (default) -The Service is only addressable from within the cluster.
NodePort - In addition to a ClusterIP, the Service is also available outside the cluster using <NodeIP>:<NodePort>.
LoadBalancer - In addition to a Cluster IP and Node Port, the Service is also assigned a load balancer to with a fixed, external IP that routes to the Service.
ExternalName - Uses a CNAME record to internally expose an external Service to Kubernetes within the cluster.

Volumes

Containers are ephemeral, and storage in a container is temporary as well. As soon as a container stops, any changes are lost. The lifecycle of a Kubernetes Volume is tied to a Pod, and the data in the volume is available across container restarts. If a Pod is terminated, then the data will also be lost.

Kubernetes supports many types of volumes, but of interest are PersistentVolumes, which persist beyond the lifecycle of a Pod. PersistentVolumes are a resource that has been provisioned by a Storage Class. To use a PersistentVolume, we have to declare a PersistentVolumeClaim (PVC) which allows a user to access abstract storage resources. We can declare parameters such as size, access (read/write), or volume expansion for a PVC. Applications that require a PVC are typically data stores or databases where data must be preserved outside the scope of the application in a Pod.

Namespaces

One of the advantages of Kubernetes is multi-tenancy or the ability to host many virtual clusters in the same physical cluster. Namespaces are used to organize application clusters by providing scope for names. To this end, Namespaces must be unique, cannot be nested inside another namespace, and resources can only belong to one namespace, if they are namespaced.

Namespaces are typically used where there are multiple teams or projects. For example, you may have an engineering and a marketing namespace. However, it’s more efficient to use labels if the applications are only slightly different than in grouping environments such as dev, test, and prod.

Controllers

Controllers manage the state of the cluster by making changes that move the cluster to the desired state. They watch resources making sure that objects, such as Pods, meet the spec for the declared state. The kube-controller-manager in the control plane has a built-in set of controllers. Let’s take a look at two commonly used controllers, Deployments and ReplicaSets.

A Deployment is a higher-level object that manages declarative updates for Pods and ReplicaSets. But first, let’s look at ReplicaSets, which are a set of Pods running the same application at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods. A ReplicaSet creates and deletes Pods as needed to meet the criteria of the declared state, and uses Labels and Selectors to determine which Pods to manage.

A Deployment is a higher-level abstraction that manages ReplicaSets by updating Pods. Deployments are commonly used instead of directly using ReplicaSets because the Deployment controller manages updates to the desired state at a controlled rate. For example, you can specify a rolling update to limit the downtime of an application.

Examples

Now that we have the basic Kubernetes objects, let’s see how they are used in a Kubernetes deployment across cloud providers.

In this example, we’ll deploy Nginx. We’ll skip the cluster creation, which we covered in the previous installment. We set name to helloworld and use it to set the Namespace for the application and the Label (appLabel). The Deployment uses these parameters in the metadata section.

The spec section of a Deployment specifies the desired state; in this example, we want one Replica, and the selector must match appLabel. The Deployment spec includes the application container and claims port 80 on the Pod. To make our deployment available outside the cluster, we create a LoadBalancer service that routes requests to the container. As with the Deployment, we add the Labels and Namespace to the metadata. The Service spec sets the type to LoadBalance and opens port 80 externally. Note that the selector uses appLabels to acquire the Pods from our Deployment.

...
const name = "helloworld";

// Create a Kubernetes Namespace
const ns = new k8s.core.v1.Namespace(name, {}, { provider: cluster.provider });

// Export the Namespace name
export const namespaceName = ns.metadata.name;

// Create a NGINX Deployment
const appLabels = { appClass: name };
const deployment = new k8s.apps.v1.Deployment(name,
 {
 metadata: {
 namespace: namespaceName,
 labels: appLabels,
 },
 spec: {
 replicas: 1,
 selector: { matchLabels: appLabels },
 template: {
 metadata: {
 labels: appLabels,
 },
 spec: {
 containers: [
 {
 name: name,
 image: "nginx:latest",
 ports: [{ name: "http", containerPort: 80 }],
 },
 ],
 },
 },
 },
 },
 {
 provider: cluster.provider,
 },
);

// Export the Deployment name
export const deploymentName = deployment.metadata.name;

// Create a LoadBalancer Service for the NGINX Deployment
const service = new k8s.core.v1.Service(name,
 {
 metadata: {
 labels: appLabels,
 namespace: namespaceName,
 },
 spec: {
 type: "LoadBalancer",
 ports: [{ port: 80, targetPort: "http" }],
 selector: appLabels,
 },
 },
 {
 provider: cluster.provider,
 },
);

// Export the Service name and public LoadBalancer Endpoint
export const serviceName = service.metadata.name;
export const serviceHostname = service.status.loadBalancer.ingress[0].hostname;

We can compare this deployment to a YAML manifest that accomplishes the same thing. The YAML deployment is similar to the one above written in code. A manifest for the service is also required to deploy the application. You can use kubectl to apply the manifests.

apiVersion: apps/v1
kind: Deployment
metadata:
 Labels:
 namespace: helloworld
 labels: appLabels
spec:
 replicas: 1
 selector:
 matchLabels: appLabels
 template:
 metadata:
 labels: appLabels
 spec:
 containers:
 - name: helloworld
 image: nginx:latest
 ports:
 - containerPort: 80

Although this is a simple example, you can see where using a programming language has advantages over editing YAML files, e.g., you can edit the name, namespace, and labels just once. The full example is available on GitHub for you to try.

In this example, we’ll deploy Nginx. We’ll skip the cluster creation which we covered in the previous installment. We set name to helloworld and use it to set the Namespace for the application and the Label (appLabel). The Deployment uses these parameters in the metadata section.

The spec section of a Deployment specifies the desired state; in this example, we want one Replica, and the selector must match the appLabel. The Deployment spec includes the application container and claims port:80 on the Pod. To make our deployment available outside the cluster, we create a LoadBalancer service that routes requests to the container. As with the Deployment, we add the Labels and Namespace to the metadata. The Service spec sets the type to LoadBalance and opens port 80 externally. Note that the selector uses appLabels to acquire the Pods from our Deployment.

...
const name = "helloworld";

// Create a Kubernetes Namespace
const ns = new k8s.core.v1.Namespace(name, {}, { provider: cluster.provider });

// Export the Namespace name
export const namespaceName = ns.metadata.name;

const deployment = new k8s.apps.v1.Deployment(name,
 {
 metadata: {
 namespace: namespaceName,
 labels: appLabels,
 },
 spec: {
 replicas: 1,
 selector: { matchLabels: appLabels },
 template: {
 metadata: {
 labels: appLabels,
 },
 spec: {
 containers: [
 {
 name: name,
 image: "nginx:latest",
 ports: [{ name: "http", containerPort: 80 }],
 },
 ],
 },
 },
 },
 },
 {
 provider: cluster.provider,
 },
);

// Export the Deployment name
export const deploymentName = deployment.metadata.name;

// Create nginx service
const service = new k8s.core.v1.Service(name,
 {
 metadata: {
 labels: appLabels,
 namespace: namespaceName,
 },
 spec: {
 type: "LoadBalancer",
 ports: [{ port: 80, targetPort: "http" }],
 selector: appLabels,
 },
 },
 {
 provider: cluster.provider,
 },
);

// Export the Service name and public LoadBalancer Endpoint
export const serviceName = service.metadata.name;
export const serviceHostname = service.status.loadBalancer.ingress[0].ip;

apiVersion: apps/v1
kind: Deployment
metadata:
 Labels:
 namespace: helloworld
 labels: appLabels
spec:
 replicas: 1
 selector:
 matchLabels: appLabels
 template:
 metadata:
 labels: appLabels
 spec:
 containers:
 - name: helloworld
 image: nginx:latest
 ports:
 - containerPort: 80

Although this is a simple example, you can see where using a programming language has advantages over editing YAML files, e.g., you can edit the name, namespace, and labels just once.

The spec section of a Deployment specifies the desired state; in this example, we want one Replica and the selector must match the appLabel. The Deployment spec includes the application container and claims port:80 on the Pod. To make our deployment available outside the cluster, we create a LoadBalancer service that routes requests to the container. As with the Deployment, we add the Labels and Namespace to the metadata. The Service spec sets the type to LoadBalance and opens port 80 externally. Note that the selector uses appLabels to acquire the Pods from our Deployment.

...
const name = "helloworld";

// Create a Kubernetes Namespace
const ns = new k8s.core.v1.Namespace(name, {}, { provider: clusterProvider });

// Export the Namespace name
export const namespaceName = ns.metadata.name;

// Create a NGINX Deployment
const appLabels = { appClass: name };
const deployment = new k8s.apps.v1.Deployment(name,
 {
 metadata: {
 namespace: namespaceName,
 labels: appLabels,
 },
 spec: {
 replicas: 1,
 selector: { matchLabels: appLabels },
 template: {
 metadata: {
 labels: appLabels,
 },
 spec: {
 containers: [
 {
 name: name,
 image: "nginx:latest",
 ports: [{ name: "http", containerPort: 80 }],
 },
 ],
 },
 },
 },
 },
 {
 provider: clusterProvider,
 },
);

// Export the Deployment name
export const deploymentName = deployment.metadata.name;

// Create a LoadBalancer Service for the NGINX Deployment
const service = new k8s.core.v1.Service(name,
 {
 metadata: {
 labels: appLabels,
 namespace: namespaceName,
 },
 spec: {
 type: "LoadBalancer",
 ports: [{ port: 80, targetPort: "http" }],
 selector: appLabels,
 },
 },
 {
 provider: clusterProvider,
 },
);

// Export the Service name and public LoadBalancer endpoint
export const serviceName = service.metadata.name;
export const servicePublicIP = service.status.loadBalancer.ingress[0].ip;

apiVersion: apps/v1
kind: Deployment
metadata:
 Labels:
 namespace: helloworld
 labels: appLabels
spec:
 replicas: 1
 selector:
 matchLabels: appLabels
 template:
 metadata:
 labels: appLabels
 spec:
 containers:
 - name: helloworld
 image: nginx:latest
 ports:
 - containerPort: 80

Conclusion

This article reviews the Kubernetes objects and abstractions used to deploy applications. Deploying an application using Pulumi’s infrastructure as code looks similar to YAML manifests in how Deployments and Services are configured. The advantage of using a programming language to deploy an application is that you have the full range of software development tools available to you, such as defining variables, code completion, error checking, and versioning. In contrast, maintaining a set of YAML manifests can be an error-prone exercise in copying and pasting.

This is the second in a series of articles on using infrastructure as code for Kubernetes. In the next article, we’ll examine a complex application deployment and a deployment using a Helm chart. Until the next post, learn more about Kubernetes with these resources.

Watch educational content on Pulumi TV
Learn more about Pulumi’s support for Kubernetes
Practice Kubernetes Tutorials using Pulumi

Getting Started With Kubernetes: Clusters and Nodes

Sophia Parafina — Tue, 23 Jun 2020 00:00:00 +0000

Containers solved the problem of moving software from one environment to another because they encapsulate all the software dependencies. However, an orchestration platform is needed to manage containers at scale. Kubernetes is a popular open-source solution that uses declarative configuration to specify the desired state of the application. Configuring and deploying an application on Kubernetes is often accomplished with YAML files to define the state and command line tools to manage and control the Kubernetes API. This article demonstrates how to use infrastructure as code to create basic Kubernetes objects and higher-level abstractions that build upon the basic objects.

This is the first article of a multi-part series covering deploying Kubernetes and applications using infrastructure as code. We’ll take a top-down approach starting from clusters to high-level abstractions such as deployments. This article aims to provide a step-by-step example of deploying an application in Kubernetes using infrastructure as code. For this example, we’ll use Typescript for the programming language and provide sample code for AWS, Azure, GCP, and Kubernetes.

Clusters and Nodes

A cluster is formed with a control plane and a collection of nodes, the smallest unit of computing in Kubernetes. A node can be either a physical or virtual that contains the necessary components to run containers. A cluster has one or more nodes designated to the control plane, which controls the worker nodes where the application containers are deployed. A control plane node has:

the Kube-APIServer, which provides communication to the cluster
a Kube-Controller-Manager that provides governance for the cluster
etcd, which is the cluster state database
Kube-Scheduler, which schedules worker nodes based on events in etcd

To create a cluster for Kubernetes on a cloud provider, we need to create a VPC that will host the nodes required to deploy the Kubernetes cluster. Each cloud provider requires configuration specific to their implementation, and we’ll cover their particular requirements.

We declare a VPC to host our Kubernetes cluster and specify a public subnet, which is the gateway for the Kube-APIServer. We create the Kubernetes cluster with the VPC we declared and the VPC’s default public subnets. The desiredCapacity parameter sets the desired number of EC2 t2.medium nodes. We also export the kubeconfig file which we can use with kubectl to communicate with our Kubernetes cluster.

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

// Create a VPC for our cluster.
const vpc = new awsx.ec2.Vpc("vpc", { subnets: [{ type: "public" }] });

// Create the EKS cluster itself and a deployment of the Kubernetes dashboard.
const cluster = new eks.Cluster("cluster", {
 vpcId: vpc.id,
 subnetIds: vpc.publicSubnetIds,
 instanceType: "t2.medium",
 desiredCapacity: 2,
 minSize: 1,
 maxSize: 2,
});

// Export the cluster's kubeconfig.
export const kubeconfig = cluster.kubeconfig;

You can try out the code by following the complete tutorial.

In this example, we store the configuration variables in the Pulumi..yaml file, e.g.,

$ pulumi config set password [value]
$ pulumi config set location [value]
$ pulumi config set nodeCount [value]
$ pulumi config set nodeSize [value]
$ pulumi config set sshPublicKey [value]

We retrieve the values with config.ts for use in our main program.

config.ts

import * as azure from "@pulumi/azure";
import * as pulumi from "@pulumi/pulumi";

// Parse and export configuration variables for this stack.
const config = new pulumi.Config();
export const password = config.require("password");
export const location = config.get("location") || azure.Locations.EastUS;
export const nodeCount = config.getNumber("nodeCount") || 2;
export const nodeSize = config.get("nodeSize") || "Standard_D2_v2";
export const sshPublicKey = config.require("sshPublicKey");
export const resourceGroup = new azure.core.ResourceGroup("aks", { location });

In Azure, we have to create a service principal, which is an identity for accessing Azure resources. Note that in this example, the service principal password is stored as a secret in the project config file. Azure allocates a VPC when creating a Kubernetes cluster based on the values set in the config file. For example, the default number of nodes is two and uses Standard_D2_v2 virtual machine if these are not set in the config file. We also export the kubeconfig file which we can use with kubectl to communicate with our Kubernetes cluster.

cluster.ts

import * as azure from "@pulumi/azure";
import * as azuread from "@pulumi/azuread";
import * as k8s from "@pulumi/kubernetes";
import * as pulumi from "@pulumi/pulumi";
import * as config from "./config";

// 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: config.password,
 endDate: "2099-01-01T00:00:00Z",
});

// Now allocate an AKS cluster.
export const k8sCluster = new azure.containerservice.KubernetesCluster("aksCluster", {
 resourceGroupName: config.resourceGroup.name,
 location: config.location,
 defaultNodePool: {
 name: "aksagentpool",
 nodeCount: config.nodeCount,
 vmSize: config.nodeSize,
 },
 dnsPrefix: `${pulumi.getStack()}-kube`,
 linuxProfile: {
 adminUsername: "aksuser",
 sshKey: {
 keyData: config.sshPublicKey,
 },
 },
 servicePrincipal: {
 clientId: adApp.applicationId,
 clientSecret: adSpPassword.value,
 },
});

// Expose a K8s provider instance using our custom cluster instance.
export const k8sProvider = new k8s.Provider("aksK8s", {
 kubeconfig: k8sCluster.kubeConfigRaw,
});

The code above is an abbreviated example of this AKS deployment on GitHub.

In this example, we store the configuration variables in the Pulumi..yaml file, e.g.,

$ pulumi config set password [value]
$ pulumi config set nodeCount [value]
$ pulumi config set nodeMachineType [value]
$ pulumi config set username [value]
$ pulumi config set masterVersion [value]

We retrieve the values with config.ts for use in our main program.

config.ts

import * as gcp from "@pulumi/gcp";
import { Config } from "@pulumi/pulumi";
import * as random from "@pulumi/random";

const config = new Config();

// nodeCount is the number of cluster nodes to provision. Defaults to 3 if unspecified.
export const nodeCount = config.getNumber("nodeCount") || 3;

// nodeMachineType is the machine type to use for cluster nodes. Defaults to n1-standard-1 if unspecified.
// See https://cloud.google.com/compute/docs/machine-types for more details on available machine types.
export const nodeMachineType = config.get("nodeMachineType") || "n1-standard-1";

// username is the admin username for the cluster.
export const username = config.get("username") || "admin";

// password is the password for the admin user in the cluster.
// If a password is not set, a strong random password will be generated.
export const password = config.get("password") || new random.RandomPassword(
 "password", { length: 20, special: true }).result;

// GKE master version
// Default to the latest available version.
export const masterVersion = config.get("masterVersion") ||
 gcp.container.getEngineVersions().then(it => it.latestMasterVersion);

We create the Kubernetes cluster using the variables we set in the configuration file. Note that for the nodes, we specify the oauthScopes, which are the Google API scopes available to all of the node VMs under the “default” service account. Because GKE uses gcloud to authenticate to the service, we have to create a kubeconfig file that uses gcloud. The kubeconfig file lets us communicate with our Kubernetes cluster.

import * as gcp from "@pulumi/gcp";
import * as k8s from "@pulumi/kubernetes";
import * as pulumi from "@pulumi/pulumi";
import { masterVersion, nodeCount, nodeMachineType, password, username } from "./config";

// Create the GKE cluster and export it.
export const k8sCluster = new gcp.container.Cluster("gke-cluster", {
 initialNodeCount: nodeCount,
 nodeVersion: masterVersion,
 minMasterVersion: masterVersion,
 masterAuth: { username, password },
 nodeConfig: {
 machineType: nodeMachineType,
 oauthScopes: [
 "https://www.googleapis.com/auth/compute",
 "https://www.googleapis.com/auth/devstorage.read_only",
 "https://www.googleapis.com/auth/logging.write",
 "https://www.googleapis.com/auth/monitoring",
 ],
 },
});

// Manufacture a GKE-style Kubeconfig. Note that this is slightly "different" because of the way GKE requires
// gcloud to be in the picture for cluster authentication (rather than using the client cert/key directly).
export const k8sConfig = pulumi.
 all([ k8sCluster.name, k8sCluster.endpoint, k8sCluster.masterAuth ]).
 apply(([ name, endpoint, auth ]) => {
 const context = `${gcp.config.project}_${gcp.config.zone}_${name}`;
 return `apiVersion: v1
clusters:
- cluster:
 certificate-authority-data: ${auth.clusterCaCertificate}
 server: https://${endpoint}
 name: ${context}
contexts:
- context:
 cluster: ${context}
 user: ${context}
 name: ${context}
current-context: ${context}
kind: Config
preferences: {}
users:
- name: ${context}
 user:
 auth-provider:
 config:
 cmd-args: config config-helper --format=json
 cmd-path: gcloud
 expiry-key: '{.credential.token_expiry}'
 token-key: '{.credential.access_token}'
 name: gcp
`;
 });

// Export a Kubernetes provider instance that uses our cluster from above.
export const k8sProvider = new k8s.Provider("gkeK8s", {
 kubeconfig: k8sConfig,
});

You can try out the code by following the complete tutorial.

Conclusion

This article covers how to set up a Kubernetes cluster on AWS, Azure, and GCP using Pulumi. Creating a cluster differs among cloud providers, but the process is generally the same. We defined configuration parameters such as node type, number of nodes, and passwords to instantiate the cluster then exported a kubeconfig file that we can use with kubectl.

This is the first in a series of articles on using infrastructure as code for Kubernetes. In the next article, we’ll cover basic Kubernetes objects such as pods, services, and volumes. We’ll also cover higher-level abstractions such as deployments and replicasets. Stay tuned! In the meantime, learn more about Pulumi:

Watch educational content on Pulumi TV
Learn more about Pulumi’s support for Kubernetes
Practice Kubernetes Tutorials using Pulumi

Policy as Code with Python

Sophia Parafina — Tue, 16 Jun 2020 00:00:00 +0000

Policy as Code for Python is now GA in Pulumi 2.0. Policies written in code let you test, automate deployment, and enable version control. Python is a popular scripting language used for machine learning and artificial intelligence, data science, web development, and devops. It’s an ideal language for developers and operators to use in common.

Devops benefits greatly from policy as code because policies can use software development practices and verify resources without deployments that are costly in time and money. Organizations can also gain significant benefits through cost savings, fine-grained control over infrastructure, efficient deployments, improved compliance, and better use of cloud provider native resources.

How Policy as Code Works

Policies enforce specific criteria for a resource or a set of resources (stacks). For example, a common policy is to ensure that storage is not publicly accessible over the Internet or that virtual machines must have a firewall. Policies are enforced as either advisory, which prints a warning message the resource violates the policy; or mandatory, which prevents a resource deployment if it violates the policy.

Pulumi supports two types of policies:

ResourceValidationPolicy validates inputs of individual resources in a stack before the resource is created or modified.
StackValidationPolicy validates outputs of all resources in the stack after all resources have been created or modified.

ResourceValidationPolicy and StackValidationPolicy validations run during previews and updates. During previews, resources aren’t created or modified, so the ResourceValidationPolicy and StackValidationPolicy validations see a preview of what’s going to happen (as best we can determine). With stack validation policies, the validation happens after resources have been created or modified. Modifications to resources can’t be prevented, but using mandatory enforcement results in a deployment failing (despite the modified resources). If you run pulumi preview before an update and use a mandatory StackValidationPolicy, you can catch the problems before a real deployment occurs.

The difference is described in this table:

	Resource Validation	Stack Validation
What does it check?	Individual resources	All resources in the stack
When is the check performed?	Before resources are created/modified	After all stack resources have been created/modified
What information is available?	Resource input properties	Resource output properties (Note: inputs are propagated to outputs during preview)

Now that we have the basics of policy as code let’s take a look at example policies written in Python.

Examples

Policies are validation functions that validate resources in a Pulumi stack. In the examples below, we define a function that takes ResourceValidationArgs and ReportViolation as arguments. The function checks to see what type of resource and its arguments, these are used to determine if the resource violates the policy. If the resource is not compliant, the function reports the violation, and because the enforcement level is mandatory, the resource will not be deployed.

If you’d like to try out one of the examples, you can create a policy with pulumi policy new and run locally against a Pulumi program, specify pulumi up --policy-pack <path-to-policy-pack>.

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def s3_no_public_read_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "aws:s3/bucket:Bucket" and "acl" in args.props:
 acl = args.props["acl"]
 if acl == "public-read" or acl == "public-read-write":
 report_violation(
 "You cannot set public-read or public-read-write on an S3 bucket. " +
 "Read more about ACLs here: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html")

s3_no_public_read = ResourceValidationPolicy(
 name="s3-no-public-read",
 description="Prohibits setting the publicRead or publicReadWrite permission on AWS S3 buckets.",
 validate=s3_no_public_read_validator,
)

PolicyPack(
 name="aws-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 s3_no_public_read,
 ],
)

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def storage_container_no_public_read_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "azure:storage/container:Container" and "containerAccessType" in args.props:
 access_type = args.props["containerAccessType"]
 if access_type == "blob" or access_type == "container":
 report_violation(
 "Azure Storage Container must not have blob or container access set. " +
 "Read more about read access here: " +
 "https://docs.microsoft.com/en-us/azure/storage/blobs/storage-manage-access-to-resources")

storage_container_no_public_read = ResourceValidationPolicy(
 name="storage-container-no-public-read",
 description="Prohibits setting the public permission on Azure Storage Blob Containers.",
 validate=storage_container_no_public_read_validator,
)

PolicyPack(
 name="azure-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 storage_container_no_public_read,
 ],
)

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def storage_bucket_no_public_read_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "gcp:storage/bucketACL:BucketACL" and "predefinedAcl" in args.props:
 acl = args.props["predefinedAcl"]
 if acl == "public-read" or acl == "public-read-write":
 report_violation("Storage buckets acl cannot be set to public-read or public-read-write.")

storage_bucket_no_public_read = ResourceValidationPolicy(
 name="storage-bucket-no-public-read",
 description="Prohibits setting the publicRead or publicReadWrite permission on GCP Storage buckets.",
 validate=storage_bucket_no_public_read_validator,
)

PolicyPack(
 name="gcp-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 storage_bucket_no_public_read,
 ],
)

from pulumi_policy import (
 EnforcementLevel,
 PolicyPack,
 ReportViolation,
 ResourceValidationArgs,
 ResourceValidationPolicy,
)

def no_public_services_validator(args: ResourceValidationArgs, report_violation: ReportViolation):
 if args.resource_type == "kubernetes:core/v1:Service" and "spec" in args.props:
 spec = args.props["spec"]
 if "type" in spec and spec["type"] == "LoadBalancer":
 report_violation(
 "Kubernetes Services cannot be of type LoadBalancer, which are exposed to " +
 "anything that can reach the Kubernetes cluster. This likely including the " +
 "public Internet.")

no_public_services = ResourceValidationPolicy(
 name="no-public-services",
 description="Kubernetes Services should be cluster-private.",
 validate=no_public_services_validator,
)

PolicyPack(
 name="kubernetes-python",
 enforcement_level=EnforcementLevel.MANDATORY,
 policies=[
 no_public_services,
 ],
)

Summary

Policy as Code is an important tool for building a secure and efficient cloud infrastructure. Pulumi lets you efficiently test resources before deployment and entire stacks when deployed. Learn more about what you can do with Policy as Code:

Building Jamstack Infrastructure With Pulumi

Sophia Parafina — Tue, 09 Jun 2020 00:00:00 +0000

A Jamstack is a modern architecture for building websites; JAM stands for JavaScript, APIs, and Markup. Jamstacks are deployed on a CDN, and content is stored on a cloud services provider. In addition to the speed and simplicity of deploying static content served from a CDN, there are other advantages such as maintaining content with git, modern build tools to generate the static content, automated builds, atomic deploys, and instant cache validation.

While build tools have simplified the process of creating content ready for deployment on a CDN, creating the infrastructure to serve the content remains complicated. You can use a cloud provider’s web interface or script the build using a CLI tool if you want to manage your infrastructure instead of using a hosted solution. The alternative is to use infrastructure as code tool to automate building and deploying cloud resources. This article demonstrates how to create a jamstack website and deploy it on AWS using Pulumi.

Creating Your Website with Hugo

There are many static site generators, but we’ll use Hugo to build the site for this example. We’ll use Docker to run Hugo in a container. If you have Docker installed, create a directory to hold the website and change into that directory.

$ mkdir hugo
$ cd hugo
$ docker run --rm -it -v $(pwd):/src klakegg/hugo:0.72.0-alpine shell

The docker run command will fetch the container (klakegg/hugo:0.72.0-alpine), map the current directory to the src directory in the container, and open a shell.

In the container command line, we will use hugo to create a new site called platypus.

$ hugo new site platypus
$ cd platypus

Next, we’ll customize the site with a theme. There are many themes available, but for this example, we’ll use the ananke theme. Download the theme to the container, unzip it, and rename the unzipped directory to ananke.

$ wget https://github.com/budparr/gohugo-theme-ananke/archive/master.zip
$ unzip master.zip
$ cp -rf gohugo-theme-ananke-master ./themes/ananke
$ rm -rf master.zip gohugo-theme-ananke-master/

Configure the site by editing the config.toml file with the following.

baseURL = "http://www.<your_domain>.com/"
languageCode = "en-us"
title = "Platypus"
theme = "ananke"

Use hugo to create a new markdown page in the posts directory.

$ hugo new posts/platypus.md

Now it’s time to add content to your site. You can use your favorite editor to write and edit content in your working directory on your machine instead of using the container shell. Edit the markdown file, below is an example page but feel free to add your content.

## Platypus of the Day

**This platypus is a cool critter!**

![platypus](https://static01.nyt.com/images/2017/08/01/science/29TB-PLATYPUS1/29TB-PLATYPUS1-superJumbo.jpg)

Finally, we can build the static site with Hugo in the container command line.

$ hugo -D

Hugo will create a public directory with the static website.

Building the Cloud Infrastructure

Configuring a static website can be complicated when using either the AWS web interfaces or the AWS CLI. To deploy a static website, we need to create and configure the following cloud resources.

Amazon S3 to store the website’s contents
Amazon CloudFront for the CDN serving content
Amazon Route53 to set up the DNS for the website
Amazon Certificate Manager for securing the site via HTTPS

Using Pulumi to deploy Infrastructure as Code, we can create and build our infrastructure using either TypeScript or Python. If you haven’t installed Pulumi and configured it to work with your AWS credentials, follow the Getting Started with AWS guide.

To get started building our infrastructure, we’ll download the Python example for setting up a static website with AWS. There are many examples on our GitHub repository, but we can clone just the AWS Static Website example using a sparse checkout which clones only the directory we specify,

$ cd hugo
$ mkdir aws-website
$ cd aws-website

$ git init
$ git remote add origin -f https://github.com/pulumi/examples/
$ git config core.sparseCheckout true
$ echo aws-ts-static-website >> .git/info/sparse-checkout
$ git pull origin master

$ cd hugo
$ mkdir aws-website
$ cd aws-website

$ git init
$ git remote add origin -f https://github.com/pulumi/examples/
$ git config core.sparseCheckout true
$ echo aws-py-static-website >> .git/info/sparse-checkout
$ git pull origin master

Your project directory should look like this:

./ hugo
|_ playtpus
|_ aws-<language>-static-website

Configuring and Deploying the Website

Now that we have a project to build the website, we will need to configure it so that it uses your domain name. Here are the steps to get it running.

Create a new stack or instance for testing:

$ cd aws-ts-static-website
$ pulumi stack init website-testing

$ cd aws-py-static-website
$ pulumi stack init website-testing

Set the AWS region, you can use any region:

$ pulumi config set aws:region us-east-1

Install dependencies for our Pulumi program.

$ npm install

$ python3 -m venv venv
$ source venv/bin/activate
$ pip3 install -r requirements.txt

Edit Pulumi.website-testing.yaml to set the configuration parameters. The first parameter is the targetDomain, which is the domain for the website (e.g., www.example.com). The parent domain must be a Route53 Hosted Zone in the same AWS account as where the Pulumi program is running. The second parameter is pathToWebsiteContents, the relative path to the website’s contents created in Hugo.
```
config:
aws:region: us-east-1
static-website:targetDomain: www.<your_domain>.com
static-website:pathToWebsiteContents: ../public
```

Run pulumi up to preview and deploy changes. After the preview is displayed, you will be prompted if you want to continue and deploy the website. When all the resources have been created, you will see a listing of the resources similar to this:

Updating (website-testing):
 Type Name Status
+ pulumi:pulumi:Stack static-website-website-testing created
+ ├─ pulumi:providers:aws east created
+ ├─ aws:acm:Certificate certificate created
+ ├─ aws:s3:Bucket contentBucket created
+ │ ├─ aws:s3:BucketObject posts/page/1/index.html created
...
+ ├─ aws:s3:Bucket requestLogs created
+ ├─ aws:route53:Record www.sophiaparafina.com-validation created
+ ├─ aws:acm:CertificateValidation certificateValidation created
+ ├─ aws:cloudfront:Distribution cdn created
+ └─ aws:route53:Record www.sophiaparafina.com created

Outputs:
 cloudfront_domain : "d1l27ffvw5kc32.cloudfront.net"
 content_bucket_url : "s3://www.your_domain.com"
 content_bucket_website_endpoint: "www.your_domain.com.s3-website-us-west-2.amazonaws.com"
 target_domain_endpoint : "https://www.your_domain.com/"

Resources:
 + 27 created

Duration: 4m15s

Permalink: https://app.pulumi.com/spara/static-website/website-testing/updates/12

The website has been deployed, and you can browse it with your domain URL. Since this is a test deployment, don’t forget to shut down and delete the cloud resources by running pulumi destroy.

Examine the Code

Let’s take a look at how the cloud resources are created, configured, and populated. First up is the S3 bucket where the static website is stored.

// contentBucket is the S3 bucket that the website's contents will be stored in.
const contentBucket = new aws.s3.Bucket("contentBucket",
 {
 bucket: config.targetDomain,
 acl: "public-read",
 // Configure S3 to serve bucket contents as a website. This way S3 will automatically convert
 // requests for "foo/" to "foo/index.html".
 website: {
 indexDocument: "index.html",
 errorDocument: "404.html",
 },
 });

# Create an S3 bucket configured as a website bucket.
content_bucket = pulumi_aws.s3.Bucket('contentBucket',
 bucket=target_domain,
 acl='public-read',
 website={
 'index_document': 'index.html',
 'error_document': '404.html'
 })

We add the website content by crawling the public directory and converting the files to S3 objects.

// crawlDirectory recursive crawls the provided directory, applying the provided function
// to every file it contains. Doesn't handle cycles from symlinks.
function crawlDirectory(dir: string, f: (_: string) => void) {
 const files = fs.readdirSync(dir);
 for (const file of files) {
 const filePath = `${dir}/${file}`;
 const stat = fs.statSync(filePath);
 if (stat.isDirectory()) {
 crawlDirectory(filePath, f);
 }
 if (stat.isFile()) {
 f(filePath);
 }
 }
}

// Sync the contents of the source directory with the S3 bucket, which will in-turn show up on the CDN.
const webContentsRootPath = path.join(process.cwd(), config.pathToWebsiteContents);
console.log("Syncing contents from local disk at", webContentsRootPath);
crawlDirectory(
 webContentsRootPath,
 (filePath: string) => {
 const relativeFilePath = filePath.replace(webContentsRootPath + "/", "");
 const contentFile = new aws.s3.BucketObject(
 relativeFilePath,
 {
 key: relativeFilePath,

 acl: "public-read",
 bucket: contentBucket,
 contentType: mime.getType(filePath) || undefined,
 source: new pulumi.asset.FileAsset(filePath),
 },
 {
 parent: contentBucket,
 });
 });

def crawl_directory(content_dir, f):
 """
 Crawl `content_dir` (including subdirectories) and apply the function `f` to each file.
 """
 for file in os.listdir(content_dir):
 filepath = os.path.join(content_dir, file)

 if os.path.isdir(filepath):
 crawl_directory(filepath, f)
 elif os.path.isfile(filepath):
 f(filepath)

web_contents_root_path = os.path.join(os.getcwd(), path_to_website_contents)
def bucket_object_converter(filepath):
 """
 Takes a file path and returns a bucket object managed by Pulumi
 """
 relative_path = filepath.replace(web_contents_root_path + '/', '')
 # Determine the mimetype using the `mimetypes` module.
 mime_type, _ = mimetypes.guess_type(filepath)
 content_file = pulumi_aws.s3.BucketObject(
 relative_path,
 key=relative_path,
 acl='public-read',
 bucket=content_bucket,
 content_type=mime_type,
 source=FileAsset(filepath),
 opts=ResourceOptions(parent=content_bucket)
 )

# Crawl the web content root path and convert the file paths to S3 object resources.
crawl_directory(web_contents_root_path, bucket_object_converter)

Now that we have our content in an S3 bucket, we turn to configure and create the CDN that serves the website. The first task is to create an SSL/TLS certificate based on the domain name hosted on Route 53 DNS if we didn’t specify the optional certificateArn config value of an existing certificate.

let certificateArn: pulumi.Input<string> = config.certificateArn!;

/**
 * Only provision a certificate (and related resources) if a certificateArn is _not_ provided via configuration.
 */
if (config.certificateArn === undefined) {

 const eastRegion = new aws.Provider("east", {
 profile: aws.config.profile,
 region: "us-east-1", // Per AWS, ACM certificate must be in the us-east-1 region.
 });

 const certificate = new aws.acm.Certificate("certificate", {
 domainName: config.targetDomain,
 validationMethod: "DNS",
 }, { provider: eastRegion });

if certificate_arn is None:
 # CloudFront is in us-east-1 and expects the ACM certificate to also be in us-east-1.
 # So, we create an east_region provider specifically for these operations.
 east_region = pulumi_aws.Provider('east', profile=pulumi_aws.config.profile, region='us-east-1')

 # Get a certificate for our website domain name.
 certificate = pulumi_aws.acm.Certificate('certificate',
 domain_name=target_domain, validation_method='DNS', opts=ResourceOptions(provider=east_region))

We also create a bucket to hold the CDN logs for the website.

// logsBucket is an S3 bucket that will contain the CDN's request logs.
const logsBucket = new aws.s3.Bucket("requestLogs",
 {
 bucket: `${config.targetDomain}-logs`,
 acl: "private",
 });

# Create a logs bucket for the CloudFront logs
logs_bucket = pulumi_aws.s3.Bucket('requestLogs', bucket=f'{target_domain}-logs', acl='private')

Now that we have an SSL/TLS certificate and a S3 bucket to store logs, we can create the CDN. In the CDN resource definition, origin sets the S3 bucket as the content source, the domain name, and the ports for serving content. We can also set the cache_behavior, the price class, access restrictions, the logging configuration, and other parameters.

// distributionArgs configures the CloudFront distribution. Relevant documentation:
// https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html
// https://www.terraform.io/docs/providers/aws/r/cloudfront_distribution.html
const distributionArgs: aws.cloudfront.DistributionArgs = {
 enabled: true,
 // Alternate aliases the CloudFront distribution can be reached at, in addition to https://xxxx.cloudfront.net.
 // Required if you want to access the distribution via config.targetDomain as well.
 aliases: [ config.targetDomain ],

 // We only specify one origin for this distribution, the S3 content bucket.
 origins: [
 {
 originId: contentBucket.arn,
 domainName: contentBucket.websiteEndpoint,
 customOriginConfig: {
 // Amazon S3 doesn't support HTTPS connections when using an S3 bucket configured as a website endpoint.
 // https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginProtocolPolicy
 originProtocolPolicy: "http-only",
 httpPort: 80,
 httpsPort: 443,
 originSslProtocols: ["TLSv1.2"],
 },
 },
 ],

 defaultRootObject: "index.html",

 // A CloudFront distribution can configure different cache behaviors based on the request path.
 // Here we just specify a single, default cache behavior which is just read-only requests to S3.
 defaultCacheBehavior: {
 targetOriginId: contentBucket.arn,

 viewerProtocolPolicy: "redirect-to-https",
 allowedMethods: ["GET", "HEAD", "OPTIONS"],
 cachedMethods: ["GET", "HEAD", "OPTIONS"],

 forwardedValues: {
 cookies: { forward: "none" },
 queryString: false,
 },

 minTtl: 0,
 defaultTtl: tenMinutes,
 maxTtl: tenMinutes,
 },

 // "All" is the most broad distribution, and also the most expensive.
 // "100" is the least broad, and also the least expensive.
 priceClass: "PriceClass_100",

 // You can customize error responses. When CloudFront receives an error from the origin (e.g. S3 or some other
 // web service) it can return a different error code, and return the response for a different resource.
 customErrorResponses: [
 { errorCode: 404, responseCode: 404, responsePagePath: "/404.html" },
 ],

 restrictions: {
 geoRestriction: {
 restrictionType: "none",
 },
 },

 viewerCertificate: {
 acmCertificateArn: certificateArn, // Per AWS, ACM certificate must be in the us-east-1 region.
 sslSupportMethod: "sni-only",
 },

 loggingConfig: {
 bucket: logsBucket.bucketDomainName,
 includeCookies: false,
 prefix: `${config.targetDomain}/`,
 },
};

const cdn = new aws.cloudfront.Distribution("cdn", distributionArgs);

# Create the CloudFront distribution
cdn = pulumi_aws.cloudfront.Distribution('cdn',
 enabled=True,
 aliases=[
 target_domain
 ],
 origins=[{
 'originId': content_bucket.arn,
 'domain_name': content_bucket.website_endpoint,
 'customOriginConfig': {
 'originProtocolPolicy': 'http-only',
 'httpPort': 80,
 'httpsPort': 443,
 'originSslProtocols': ['TLSv1.2'],
 }
 }],
 default_root_object='index.html',
 default_cache_behavior={
 'targetOriginId': content_bucket.arn,
 'viewerProtocolPolicy': 'redirect-to-https',
 'allowedMethods': ['GET', 'HEAD', 'OPTIONS'],
 'cachedMethods': ['GET', 'HEAD', 'OPTIONS'],
 'forwardedValues': {
 'cookies': { 'forward': 'none' },
 'queryString': False,
 },
 'minTtl': 0,
 'defaultTtl': TEN_MINUTES,
 'maxTtl': TEN_MINUTES,
 },
 # PriceClass_100 is the lowest cost tier (US/EU only).
 price_class= 'PriceClass_100',
 custom_error_responses=[{
 'errorCode': 404,
 'responseCode': 404,
 'responsePagePath': '/404.html'
 }],
 # Use the certificate we generated for this distribution.
 viewer_certificate={
 'acmCertificateArn': certificate_arn,
 'sslSupportMethod': 'sni-only',
 },
 restrictions={
 'geoRestriction': {
 'restrictionType': 'none'
 }
 },
 # Put access logs in the log bucket we created earlier.
 logging_config={
 'bucket': logs_bucket.bucket_domain_name,
 'includeCookies': False,
 'prefix': f'${target_domain}/',
 },
 # CloudFront typically takes 15 minutes to fully deploy a new distribution.
 # Skip waiting for that to complete.
 wait_for_deployment=False)

To complete the deployment, we set the alias_a_record to point the CDN to our domain name in Route 53.

// Creates a new Route53 DNS record pointing the domain to the CloudFront distribution.
function createAliasRecord(
 targetDomain: string, distribution: aws.cloudfront.Distribution): aws.route53.Record {
 const domainParts = getDomainAndSubdomain(targetDomain);
 const hostedZoneId = aws.route53.getZone({ name: domainParts.parentDomain }, { async: true }).then(zone => zone.zoneId);
 return new aws.route53.Record(
 targetDomain,
 {
 name: domainParts.subdomain,
 zoneId: hostedZoneId,
 type: "A",
 aliases: [
 {
 name: distribution.domainName,
 zoneId: distribution.hostedZoneId,
 evaluateTargetHealth: true,
 },
 ],
 });
}

const aRecord = createAliasRecord(config.targetDomain, cdn);

def create_alias_record(target_domain, distribution):
 """
 Create a Route 53 Alias A record from the target domain name to the CloudFront distribution.
 """
 subdomain, parent_domain = get_domain_and_subdomain(target_domain)
 hzid = pulumi_aws.route53.get_zone(name=parent_domain).id
 return pulumi_aws.route53.Record(target_domain,
 name=subdomain,
 zone_id=hzid,
 type='A',
 aliases=[
 {
 'name': distribution.domain_name,
 'zoneId': distribution.hosted_zone_id,
 'evaluateTargetHealth': True
 }
 ]
 )

alias_a_record = create_alias_record(target_domain, cdn)

In a single program, we’ve created all the cloud resources to deploy our content and served it via a CDN.

Conclusion

Building modern websites is evolving from provider-managed Content Management Systems or user-managed LAMP stacks. Static websites deployed in the cloud are popular because they separate content generation from the infrastructure that serves content. However, building and maintaining cloud infrastructure can be complicated and require multiple steps when using web client for configuration. A website using inexpensive storage such as S3 and serving content via Cloudfront can be deployed, versioned, and maintained using your favorite programming language. The Pulumi examples repository has many more code samples that demonstrate how to build and deploy cloud infrastructure across different cloud providers, using your favorite programming language.

Learn how to automate your cloud infrastructure with Pulumi’s Getting Started tutorials and User Guides, or join us on Slack if you have questions.

Winning with Pulumi Superpowers and Kubernetes

Levi Blackstone — Wed, 03 Jun 2020 00:00:00 +0000

You’ve containerized your application, and it’s running great on your desktop using Docker Compose or Swarm. But now it’s time to test it locally with minikube and then put it into production with Kubernetes. Manifests are a bit like Compose files - it’s just YAML, right?

It’s Dangerous to Go Alone. Take this

Recently, Pulumi engineer Levi Blackstone posted a Twitter thread on why he thinks Pulumi is the best way to build and deploy modern applications on Kubernetes. Levi might be a bit biased, but he makes solid points for using Pulumi with Kubernetes, whether you’re a developer or operator.

For Devs

First, let’s take a look at Kubernetes from a dev’s point of view.

Use the full Kubernetes API surface – Each of Pulumi’s Kubernetes SDKs (TypeScript, Python, .NET and Go) are generated from the OpenAPI spec. This is critical because it means that resource definitions in any language are a 1:1 match with the upstream API. In the example below, the deployment manifest on the left corresponds to the TypeScript on the right.

Conditional logic – Another significant drawback of YAML is the lack of conditional logic. It’s common to change parameters depending on the environment, but this usually calls for separate tools to template your YAML. With Pulumi, this logic can go right into your resource definitions. It’s common to develop your application locally using minikube, which doesn’t natively support LoadBalancer Services. On the other hand, many cloud deployments do use a LoadBalancer Service to route traffic. The example below shows how you can deploy to either environment without having to rewrite the manifest by using a configuration value.

var frontendServiceType string
if isMinikube {
 frontendServiceType = “ClusterIP”
} else {
 frontendServiceType = “LoadBalancer”
}

frontendService, err := corev1.NewService(ctx, “frontent”, &corev1.ServiceArgs{
 Metadata: &metav1.ObjectMetaArgs{
 Labels: frontendLabels,
 Name: pulumi.String(“frontend”),
 },
 Spec: &corev1.ServiceSpecArgs{
 Type: pulumi.String(frontendServiceType),
 Ports: corev1.ServicePortArray{
 corev1.ServicePortArg{
 Port: pulumi.Int(80),
 },
 },
 Selector: frontendLabels,
 },
})

Strongly typed resources – A tricky part about defining Kubernetes resources in YAML/JSON is the lack of typing. It’s hard to track typos, and you have to apply the resource to a cluster to get any feedback. Pulumi helps here by showing type information right in the SDK.

Readiness logic – Pulumi includes readiness logic to help you understand when your Kubernetes resources are ready. This makes it easy to integrate Kubernetes workflows into CI systems! Unlike kubectl apply, Pulumi doesn’t indicate success until all of the resources are ready to go. Let Pulumi worry about the bookkeeping so you can focus on more interesting matters.

Deprecation warnings – Pulumi warns you if you’re using Kubernetes resources with deprecated apiVersions, and gives you info about which versions remove them entirely. Don’t be caught by surprise when you upgrade your clusters!

For Operators

Pulumi is not just for developers; operators can leverage it to manage Kubernetes clusters, reuse existing YAML manifests and Helm charts, and conveniently manage common configurations like networking, storage, or RBAC. You can even export your Pulumi programs to YAML for portability.

Manage Kubernetes clusters – With Pulumi, you can manage every layer of your stack, from specifying a custom VPC to deploying Kubernetes clusters! Check out this example where we create clusters on AWS, AKS, and GKE, and then deploy an app to all of them.
Use existing YAML manifests – Many of us already have a pile of YAML Kubernetes definitions to manage. Manage these manifests directly; no conversion needed! Pulumi shows detailed previews and allows you to run arbitrary transformations on the YAML before it is applied.

def set_namespace(namespace):
 def f(obj):
 if "metadata" in obj:
 obj["metadata"]["namespace"] = namespace
 else:
 obj["metadata"] = {"namespace": namespace}
 return f

deployment = ConfigFile(
 "deployment",
 file_id="nginx-deployment.yaml",
 transformations=[set_namespace("test)],
)

Helm support – Pulumi lets you manage Helm charts similarly to our YAML support. It’s common for organizations to fork upstream charts to customize a few values, but this can often be avoided with the use of transformations in Pulumi.

Extension libraries – Our kubernetesx library makes it easier to manage Kubernetes resources by abstracting away a lot of the boilerplate. This dramatically cuts the amount of code you need to write, while still giving you access to the full API surface if you need it. Read about kubernetesx on our [blog] (/blog/introducing-kx).
YAML export – Pulumi lets you export YAML manifests from the resource definitions in your program. This can be useful for integrating with other systems that expect Kubernetes YAML.

Conclusion

If you’re just starting out with Kubernetes, Pulumi provides a great experience by letting you take advantage of conditional logic, strong typing, error checking, and full access to the Kubernetes API. When deploying infrastructure, you can avoid deploying deprecated versions and know precisely when your resources are ready.

You don’t have to start from scratch if you have existing YAML manifests and Helm charts. Pulumi gives you the flexibility to manage your stack in whatever way makes sense to you, on any cloud provider, including your own infrastructure. We make it easier to bridge the gap between developers and operators so you can put Kubernetes to work for your organization!

Learn how Pulumi can make your Kubernetes experience smoother and more efficient by working through tutorials or trying out our examples.

Pulumi Wins 2020 Gartner Cool Vendor Award

Sophia Parafina — Thu, 28 May 2020 00:00:00 +0000

Pulumi is honored to be named as one of only three vendors in the 2020 Gartner Cool Vendor for Agile and DevOps report, published on May 28th, 2020. Being recognized in this way is a strong validation of Pulumi’s impact thanks to our more modern approach to Infrastructure as Code and approaches to building cloud software. Vendors can only be selected once and in only one category making this an exclusive award.

What Makes a Cool Vendor

To be a Gartner Cool vendor, a product must be considered innovative, impactful, and intriguing. Vendors are scored on a scale of 1-10 across the following areas: technology, use of technology, business model, transformative nature, and newness. Vendor claims are rigorously verified by Gartner analysts who speak to customers to confirm that the technology works.

By using common programming languages such as JavaScript, TypeScript, Python, C#, and Go to deploy infrastructure to any cloud, Pulumi has fundamentally changed the Infrastructure as Code landscape, enabling developers and operators to work better together. The impact on organizations is immediate. Instead of copying YAML or using a DSL, companies can write code to deploy infrastructure using industry best practices for development such as unit and integration testing, versioning, and error correction in IDEs. Moreover, infrastructure can be abstracted into reusable components to standardize on best practices while shipping faster with confidence.

Cool Features

Here is what we think makes Pulumi stand out from the rest.

Open-source meets SaaS. We do everything in the open, and the entire platform is available on GitHub. The Individual Edition includes the core provisioning engine, language and cloud providers, testing, Policy as Code, secrets management, and over a dozen CI/CD integrations. You can use Pulumi entirely offline or our SaaS for state management and team collaboration. We see strong community growth, and in fact, our community members are sharing and reusing best practices of their own!.
Any cloud, any language. Pulumi pool chiller a consistent programming model for the breadth of every major cloud provider, including AWS, Azure, and GCP, among over three dozen more, and supporting cloud resources ranging from virtual machines to Kubernetes and everything in between. You have the freedom to choose your language and deploy on one cloud provider or any combination of providers.
Testing. Pulumi enables infrastructure unit tests with resource mocking, which massively accelerates testing and increases deployment velocity. You can perform integration testing by quickly spinning up an ephemeral environment with only the resources you need to test or test long-lived environments in your CI/CD pipelines.
Policy as Code. Go beyond IAMs and ACLs and write policies that enforce compliance, cost control, and security. You can even secure your software supply chain by requiring the latest cloud resource versions to ensure vulnerabilities have been patched. Pulumi’s policy engine is open source, and the Enterprise Edition SaaS offers advanced features for organization-wide controls.

And we like to think that our mascot, Pulumipus, is also pretty cool.

Although Pulumi is cool, we have hundreds of organizations worldwide that have decided to run their production infrastructure using Pulumi. Check out some select stories here.

Be one of the cool kids today by giving Pulumi a try today – it’s not just cool, but the future of Infrastructure as Code and, we think, the way all developers and operations teams will collaborate in the future.

Benefits of Policy as Code

Sophia Parafina — Wed, 27 May 2020 00:00:00 +0000

Writing infrastructure policy in a high-level programming language helps automate and enforce best practices. When policies are written with code, you can apply software development practices such as testing, automated deployment, and version control. Cloud providers typically offer a GUI to create policies, but creating policies is not easily repeatable, nor can you version policies. Moreover, policies must be tested against a live system, which means using an existing system or configuring and deploying an ephemeral version.

While the benefits of writing policies as code are evident for developers and operators, the organizational benefits are even more significant. Organizations can realize cost savings, improved compliance, efficient deployments, fine-grained control over infrastructure, and better use of cloud provider native resources. Let’s take a look at these benefits in-depth.

Controlling Costs

A sizeable monthly cloud bill due to unused resources left running or using over-sized instances for small tasks is an industry cliché. One way to control costs is to set policies based on pricing. With pricing data online, we can calculate the cost of a resource ahead of time and create a policy that limits the amount spent to deploy it. In a previous article, we provided an example policy that finds all the resources in a deployment and calculates the total monthly cost. The policy sets the monthly cost permitted and sends a warning if the deployment exceeds it.

But what about unused or abandoned resources? We can use a cloud provider’s resources to implement a watchdog function with a policy that cleans up unused resources. In this article, we show how to use a serverless function to find unused resources daily and shut them down. We implemented this system at Pulumi and reduced our operating costs by 64%.

We can use cloud provider native tools and practices in combination with policy to control costs. Using AWS as an example, Joe Duffy wrote an article on using tags for cost tracking, automation, and organization. If you are not familiar with tags, they are a simple key/value pair applied to a resource. Tags let you manage, search, and filter resources.

The article showed how you could use your favorite programming language to tag a resource to enable cost tracking by project, stack, and cost center. Joe then demonstrated how to use policy as code to enforce tagging of resources when they are created. The article also shows how to automatically tag resources and enables resources to pass the tagging policy.

Compliance

Policy as Code is a way to enforce infrastructure policies that prevent inadvertent access to resources such as databases and storage or to enforce cost policies.

Controlling access to resources is basic infrastructure security. Leaving services open to the internet is less of a problem in production, but what about development environments? Developers often have much leeway to deploy resources when build a new application; similarly, testing environments maybe less secure than production. Furthermore, development instances may remain inadvertently available long after they have been used for development.

Controlling ingress and egress to and from resources and not exposing them on the Internet is a best practice. Policies that run at the level of the organization can mitigate the likelihood of unauthorized access to resources or even data breaches. Regardless of the type of environment, whether its dev, test, production, Policy as Code can enforce best practice across the organization.

Another area of concern is securing your software supply chain. Although your infrastructure runs on a cloud provider, it is not exempt form vulnerabilities as shown by CVE-2020-8835 which allows container escape to get root privileges on the host node. On Google Cloud, nodes running on Ubuntu running Kubernetes 1.16 and 1.17 were affected. You can write a policy that checks the version of GKE and prevents those version from being deployed.

Validate Before or During Deployment

One of the shortcomings of using a cloud provider GUI to create policies is that they can only be tested on deployed resources. One solution is to implement an ephemeral environment for testing, but this incurs resource costs as wells as time spent deploying. A feature of Pulumi’s deployment engine is that it constructs a preview of the resource graph. When it creates the preview, it also tests if resources are compliant with the included policies. The policies are run before a resource is registered, and inputs (configuration parameters) are validated. Out-of-compliance resources are blocked from being created or modified by the policy.

There are cases where it is necessary to deploy a resource to test policy; for example, a resource property is required to provision another resource. For these instances, the Pulumi engine supports testing either the entire stack or selected resources. This is analogous to integration testing vs. unit testing. You can run policies against a stack as a whole, i.e., when all resources are registered and will not prevent resources that are out of compliance from being created.

In either case, your infrastructure is validated before it’s deployed, saving both time and money.

Best Practices as Policies

All cloud providers offer a set of best practices for deploying resources. Best practices can be implemented as policies, but instead of managing them as individual policies, wouldn’t it be more efficient to organized similar policies as a bundle? This is the idea behind Policy Packs. They provide a way to group similar policies based on how you manage your infrastructure. For example, you may have several policies for storage based on how they are tagged. Policy packs don’t restrict which policies you combine; you can have Kubernetes policies bundled with container registry policies. You create Policy Packs according to the requirements and needs of your organization.

You can apply a Policy Pack to a single stack of resources or across multiple stacks. A group of stacks that use the same Policy Pack is a Policy Group. Note that a stack can belong to multiple Policy Groups. A typical application of Policy Groups is to set policies for environments; for example, you might have a more permissive Policy Group for your development and staging environments and more restrictive one for production.

Policy as code enables you to deploy best practices as policies. Moreover, you can organize policies in bundles or Policy Packs based on your organizational requirements. This provides repeatable and fine-grained control over the resources you deploy. You can apply Policy Packs on individual resource stacks or across multiple stacks as Policy Groups, giving you granular control over how and which resources are deployed.

Working with Cloud Native Resources

Cloud providers have methods for managing access to resources such as IAM (Identity Access and Management) policies and ACL (Access Control Lists). This is one type of policy, but it doesn’t cover the full range of actions available for managing your infrastructure. Pulumi uses cloud provider APIs to build and maintain infrastructure. The Pulumi engine works with cloud provider resources in conjunction with Policy as Code.

In a previous article, we demonstrated how to use the IAM Access Analyzer in conjunction with Policy as Code. IAM Access Analyzer validates all resources per-region with a single analyzer. It creates a record for each problem identified and shows which policy is responsible for granting wider access to resources than would be best practice. Policy as Code applies policy packs to stacks of resources anytime infrastructure is deployed.

The IAM Access Analyzer works on deployed resources, so in the example, we have to deploy the infrastructure first before running the analyzer using a Pulumi program. When the scan of a resource is complete, it returns the detailed results that we can pass to the policy for validation. In this way, we can use cloud provider native tools in conjunction with Policy as Code to manage and protect our infrastructure.

Conclusion

We often talk about Policy as Code in terms of repeatability, versioning, and testing, which benefits developers and operators directly. The benefits extend beyond DevOps and into the success of an organization. Policy as Code provides the following organizational benefits:

means for automated cost control,
compliance to avoid downtime by securing resources,
validating infrastructure before creating resources (another cost-saving measure),
encoding best practices for resource stacks,
and working with cloud provider native resources to provide best of breed security and granular control.

Learn more about using programming languages for Policy as Code with our docs.

Managing AWS Credentials on CI/CD: Part 3

Chris Smith — Thu, 14 May 2020 00:00:00 +0000

This article is the third part of a series on best practices for securely managing AWS credentials on CI/CD. In this article, we cover the last leg of the continuous delivery process to update your AWS resources and how to store sensitive data using Pulumi securely.

Recap

In part 1, we created a dedicated IAM User with limited privileges. Then in part 2, we set up a simple, serverless Pulumi program that periodically rotated the User’s access keys and updated the CI/CD system.

In this final post, we will use those AWS credentials to update cloud resources as part of a CI/CD workflow using Pulumi.

We will cover AWS’s IAM Roles and how they can be used to safely manage the access Pulumi has to your AWS account. We will also cover how sensitive data in your stack is stored within the Pulumi Service.

Assuming IAM Roles for Performing Updates

In the previous post, we automatically create and rotate the AWS access keys for an IAM User. So it seems natural to think that we should just use that same AWS access key to gain access to AWS resources. However, using the access keys for an IAM User has a few major drawbacks.

First, those access keys are long-lived. If we didn’t create that Pulumi program to rotate them automatically, the key would last forever. (Meaning that a bad actor, perhaps elsewhere, or far in the future, could take advantage of a compromised key.) Second, that access key could be used to do anything that the IAM User could. So you cannot differentiate the set of capabilities based on the task at hand. (For example, if updating the Pulumi stack website/staging, we might need a different set of permissions than if we were updating the stack website/production.)

The preferred alternative to using IAM User access keys is to “assume” an IAM Role. An IAM Role is similar to an IAM User in that it grants a set of policies and permissions. However, unlike an IAM User, an IAM Role does not have a password, nor can it be added to a Group and inherit any policies. Also, the credentials for using an IAM Role are always short-lived. (Lasting no more than 12 hours, and likely much, much less.)

Instead, an IAM Role defines a set of capabilities that can be performed by any principal capable of assuming it. So in other words, you can exchange your limited access IAM User’s credentials for a specialized IAM Role. The IAM Role then can be specifically tailored to a specific— wait for it— role to perform.

Don’t worry if that doesn’t all make sense at first; let’s look at a concrete example.

Desired End State

In our situation, we want to create an IAM Role WebsiteStackUpdaterRole that grants permissions necessary for Pulumi to update the website/production stack. We will custom tailor this role to only grant access to the set of resources and operations we know the stack needs.

We also want to restrict who can assume the WebsiteStackUpdaterRole, so that only specific users/accounts can access it. e.g., the IAM User cicd-bot but not IAM User dwight-over-in-sales.

And just to show a more real-world example, we’ll do this using multiple AWS accounts, where the website/production stack’s resources are housed in a “production” AWS account, and the cicd-bot IAM User is defined in a bastion AWS account.

Creating the IAM Role

The following snippet creates an IAM Role resource using Pulumi. The most important input property of which is the assumeRolePolicy document, which defines who can assume this role.

This is a situation where Pulumi’s ability to declare the policy document in code is super-useful, as it makes it much easier to reference other resources (e.g., another AWS account’s ID) as well as supporting inline comments.

// IAM Role used by cicd-bot to update the website stack.
export const websiteStackUpdaterRole = new aws.iam.Role("WebsiteStackUpdaterRole", {
 name: "WebsiteStackUpdaterRole",
 description: "Broad access for updating Pulumi stacks in the 'production' AWS account.",
 maxSessionDuration: 30 * 60, // 30 minutes
 assumeRolePolicy: {
 Version: "2012-10-17",
 Statement: [
 {
 Effect: "Allow",
 Principal: {
 // We grant the "bastion account", which defines IAM Users the ability to assume this role.
 // The IAM Policies in that other AWS account will then determine which users, groups, etc.
 // will be able to use the `sts:AssumeRole` action on this IAM Role.
 "AWS": `arn:aws:iam::${awsAccountIds.bastionAccount}:root`,
 },
 // But as an additional precaution against misconfiguration in the bastion account, we add
 // some additional checks to determine who can access this policy.
 Condition: {
 "ForAllValues:StringEquals": {
 "aws:PrincipalTag/access-to-production": "true",
 "sts:ExternalId": [
 "contoso/website/production",
 "contoso/website/staging",
 ],
 },
 },
 Action: "sts:AssumeRole",
 },
 ],
 },
});

There’s a lot packed into that IAM Role’s configuration.

First, the “principal” (who can assume the role) references a specific AWS account. This is an example of how you can associate one AWS account with another. (And is best practice for isolating data between different departments, etc.) We’ll cover how to configure the AWS bastion account side to use this role later.

The next thing to call out is the use of the Condition element of the policy document. To assume the role, we require two checks to be performed.

That the principal assuming the role (e.g., IAM User) has the tag "access-to-production" with value "true." This way, we will reject any IAM User in the bastion account who isn’t tagged with "access-to-production" from assuming this role.
We also verify that the “external ID” (an optional parameter passed when assuming an IAM Role) matches a well-known Pulumi stack name. This way, we can double-check that the entity using the IAM Role is doing so to use a specific stack. (This is less of a security measure and more of a general hygiene type requirement.)

IAM Policy Document

Now we have an IAM Role; we need to attach a policy document that defines what permissions are granted.

This is the most important step since it defines precisely what the CI/CD bot can able to do.

If we define the policy too broadly, then it is a general risk. For example, what if a compromised NPM package in your Pulumi program did something nefarious. If the policy is defined too narrowly, then your pulumi up might fail because the necessary permissions weren’t available. When in doubt, err on the side of having a more restrictive policy.

It can be advantageous to have an identical “staging” and “production” instance of the same Pulumi stack, so you can detect any permission issues before you update the user-facing production stack.

It can take some time to winnow down the specific set of permissions necessary since that is ultimately specific to the Pulumi program. For example, if the stack governs the networking configuration, then you can simply not deny to the s3:* actions.

Unfortunately, Pulumi doesn’t currently support generating a reasonable IAM Policy document for your stack. For a good introduction to some of the “worst-case scenarios” that could arise from a misconfigured IAM Policy, see this blog post from BishopFox.

The following is a hypothetical IAM policy that restricts the operations performed to just those for the AWS CloudFront and S3 products. (Which might be sufficient for updating a CDN-based website hosted on AWS, but likely not much else.)

// Policy document defining the permissions granted to the WebsiteStackUpdaterRole.
export const websiteUpdaterPolicyDocument: aws.iam.PolicyDocument = {
 Version: "2012-10-17",
 Statement: [
 // Grant access to all AWS S3 actions, but scoped to just the specific S3 buckets
 // used for the given Pulumi stack.
 {
 Sid: "GrantS3Access",
 Effect: "Allow",
 Action: "s3:*",
 Resource: [
 // Content bucket.
 "arn:aws:s3:::website-bucket",
 "arn:aws:s3:::website-bucket/*",
 // S3 bucket which stores the access logs.
 "arn:aws:s3:::website-logs-bucket",
 "arn:aws:s3:::website-logs-bucket/*",
 ],
 },
 // Grant access to update a CloudFront distribution. For more information, see:
 // https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/access-control-managing-permissions.html
 {
 Sid: "GrantCloudFrontAccess",
 Effect: "Allow",
 Action: [
 "cloudfront:CreateDistribution",
 "cloudfront:DeleteDistribution",
 "cloudfront:GetDistribution",
 "cloudfront:GetDistributionConfig",
 "cloudfront:ListDistributions",
 "cloudfront:UpdateDistribution",
 "cloudfront:ListCloudFrontOriginAccessIdentities",
 ],
 // The specific CloudFront distribution used in the stack.
 Resource: "arn:aws:cloudfront::0123456789:distribution/A123B1CABWZZ",
 },
 ],
};

const websiteUpdaterPolicy = new aws.iam.Policy("WebsiteUpdaterRolePolicy", {
 name: "WebsiteUpdaterRolePolicy",
 description: "Policy granting the permissions needed for updating the website/production Pulumi stack",
 policy: websiteUpdaterPolicyDocument,
}, resourceOptions);

To actually associate the IAM Policy document with the new IAM Role, we need to create a PolicyAttachment associating the two.

const rolePolicyAttachment = new aws.iam.RolePolicyAttachment("WebsiteStackUpdaterRolePolicyAttachment", {
 role: websiteStackUpdaterRole,
 policyArn: websiteUpdaterPolicy.arn,
});

Reminder, we defined the IAM Role in our production AWS account, which allows any principal in the AWS bastion account (with the right tag, external ID) to assume that role. We then need to update the bastion account to grant the sts:AssumeRole action on that IAM Role so it can be used! That isn’t covered in this post.

Assuming the IAM Role

Finally! With everyone in place, we can now use the IAM Role.

The following is a set of commands you can run on your CI/CD worker to exchange the low-privilege IAM User credentials for the specific IAM Role we just created in the production AWS account. But there are many alternatives for programmatically assuming an IAM Role, such as using the AWS_PROFILE environment variable) or the assume-role tool.

# Use the AWS credentials passed to the CI system and available as environment variables.
# These are the low-privilege credentials that automatically get rotated.
aws configure set aws_access_key_id ${AWS_ACCESS_KEY_ID}
aws configure set aws_secret_access_key ${AWS_SECRET_ACCESS_KEY}
aws configure set region "${AWS_REGION:-us-west-2}"

# Assume the desired IAM Role. Note how we pass the stack name in the --external-id parameter,
# as required to assume the role.
readonly CREDS_JSON=$(aws sts assume-role \
 --role-arn "${ARN_OF_IAM_ROLE_TO_ASSUME}" \
 --role-session-name "<useful description of the context, such as CI/CD job ID>" \
 --external-id "${TARGET_STACK}")

# The `aws sts assume-role` command just returns a JSON blob. So we now tease out the actual
# access key and set the corresponding environment variables.
export AWS_ACCESS_KEY_ID=$(echo "${CREDS_JSON}" | jq ".Credentials.AccessKeyId" --raw-output)
export AWS_SECRET_ACCESS_KEY=$(echo "${CREDS_JSON}" | jq ".Credentials.SecretAccessKey" --raw-output)
export AWS_SESSION_TOKEN=$(echo "${CREDS_JSON}" | jq ".Credentials.SessionToken" --raw-output)

# If everything worked correctly, then running the get-caller-identity command will refer to
# the IAM Role and not our IAM User.
echo "Assumed AWS identity:"
aws sts get-caller-identity

Storing Sensitive Data using Pulumi

As a developer, the most critical security threat is access to your cloud account since that’s ultimately where your or your customer’s data is stored. But beyond that, there are places where Pulumi stores sensitive data.

Pulumi goes to great lengths to safeguard your data. Here we review where Pulumi interacts with your sensitive data and what you can do to safeguard it better.

Secrets in Configuration

A Pulumi stack can have configuration data associated with it, which allows you to parameterize cloud resources. For example, a machine-size configuration key might determine which class of virtual machine to use. A dev stack might only need a "t2.small" but your production instance might need something more powerful.

Configuration data is stored in a file like Pulumi.website-production.yaml should be checked in along with the source code for a stack, so that builds and stack updates are reproducible.

However, what if those configuration settings contain secrets? Like you need to store an API key to use a 3rd party API.

Pulumi supports encrypting sensitive configuration data. You just need to add the --secret flag.

# Securely add an API key to the stack's configuration.
pulumi config set api-key "hunter2" --secret

For stacks hosted on the Pulumi Service, the default is that your configuration data is encrypted using a key specific to your stack. (So the ciphertext stored in the Pulumi.yaml file is safe to check into your source tree, since it cannot be copied/decrypted for another stack.)

Secrets in Checkpoint Files

Pulumi keeps track of your cloud resources in a something called a checkpoint file, and that too might contain sensitive information. For example, a Pulumi resource might have a "password" output property.

Pulumi has support to mark that resource output as “secret” and make sure that it is encrypted within the checkpoint file. (So if you were to look at the checkpoint file contents via pulumi stack export, you would not be able to recover the data.

Just like for secret configuration values, the default for stacks hosted on the Pulumi Service is to encrypt this data using a key that Pulumi manages and is specific to your stack.

Custom Secrets Providers

We at Pulumi take great care in safeguarding your data, especially configuration or checkpoint data that is marked as sensitive. However, you might feel more comfortable if your stack’s data were encrypted using a key that you controlled. (So even if the data stored in the Pulumi Service were available, it would be useless without your specific key.)

If that’s the case, then you can use a configurable secrets provider, and swap out the default “Pulumi Service managed” encryption scheme for your own. (And we won’t take it personally, promise.)

When you create a new stack using pulumi stack init, you can optionally specify a --secrets-provider flag. That will determine where and how secrets get managed on your stack.

For example, to use your own KMS key for encrypting data, you can pass the secrets provider "awskms://alias/ExampleAlias?region=us-east-1". The Pulumi command-line will work and behave the same. Except that whenever it needs to encrypt or decrypt some data, it will refer to the custom provider.

As you would expect, if you do use a custom secrets provider and lose access to your encryption key, then there is no way to recover the encrypted data stored on your stack.

For more information on custom secret providers, see Peace of Mind with Cloud Secret Providers or Managing Secrets with Pulumi.

Wrapping Up

Securely managing any sensitive data is challenging to get right, especially if there are many moving parts, such as when coordinating access between your AWS account, CI/CD provider, and your Pulumi stack.

In this blog series, we walked through the best practices in creating, securing, and managing access to an AWS account using IAM Users and Roles. We then reviewed the specifics of where and how Pulumi stores sensitive data, in case you want to take more control over your data.

If you have any other questions, corrections, or other ideas you’d like to discuss about Pulumi, Continuous Delivery, or security, please join the conversation over on the Pulumi Community Slack.

Architecture as Code: Kubernetes

Sophia Parafina — Tue, 12 May 2020 00:00:00 +0000

This is the fifth and last installment of the Architecture as Code series. In previous articles, we examined how to create reusable components for the primary architectural patterns for cloud infrastructure. Starting with virtual machines, we examined how to create and configure VMs. In the follow-up article, we demonstrated how to create reusable components from resources that comprise a microservices architecture. After microservices, we looked at serverless architecture, which despite its name, also requires additional resources to deploy a function or application. In this article, we’ll look at deployment patterns for Kubernetes with a focus on multi-tenancy issues.

Architectural Patterns

Kubernetes is flexible about deploying and running applications. There are several patterns for Kubernetes. They range from a single large cluster consisting of many nodes to many clusters with a single application per cluster. Each pattern has benefits and costs, and which pattern you use is dependent on multiple factors.

A single large cluster made up of many nodes is a typical pattern for deploying Kubernetes. These deployments typically have three master nodes with associated resources such as authentication, logging, controllers, and load balancers shared across all workloads. This makes resource usage more efficient and cost-effective because there’s only a single cluster to administer. However, a single cluster is also a single point of failure. If your cluster runs multiple workloads, all those can be impacted. Another disadvantage is that applications are not isolated; they share cluster-wide resources such as DNS, which can allow the discovery of other services in the cluster.

Running multiple workloads on a single cluster is also referred to as soft multi-tenancy. Since all applications on the cluster share resources, collisions can occur among them. Collisions can be mitigated through resource limits and quotas, but it requires tuning the application deployment to prevent collisions. Kubernetes defines the upper limits of a cluster as 5000 nodes, 150,000 pods, and 300,000 containers based on two service level objectives:

Return 99% of all API calls in less than 1 second
Start 99% of pods within less than 5 seconds

Large numbers of nodes, pods, and containers can strain the Kubernetes control, making efficient scheduling and resource allocation more difficult.

At the other end of the spectrum is hard multi-tenancy, which uses multiple small Kubernetes clusters with only a single application deployed on each cluster. The primary advantage of this pattern is isolation; this is beneficial for both system security and operational tasks because it limits the blast radius to the workloads on the affected cluster. Another advantage is that each cluster has fewer users, which reduces the risk of misconfiguration. The most obvious disadvantage to hard multi-tenancy is that it requires more resources in the form of the overhead needed to run Kubernetes. Also, administering multiple clusters is more complicated than managing a single cluster; for example, you will need to configure authentication and set up RBAC for each cluster. Finally, it’s more expensive to run multiple clusters because of the requirement to run master nodes for each cluster, which can impact your total monthly bill.

There are variations between these two distinct patterns. Kubernetes is very flexible and can support deployments where a cluster has only a single application but has three environments: dev, test, prod. Alternatively, we can have an environment per cluster where dev, test, and prod are individual clusters and with multiple applications per cluster.

With Architecture as Code, we can extend these patterns to multi-cloud, where we have one application deployed across many cloud service providers.

Many Clouds with Kubernetes

One strategy to ensure an application maintains high availability is to distribute it among multiple cloud service providers. If one provider becomes unavailable, the application remains available on the other providers.

Let’s take a look at an example available on the Pulumi Github repository. The project is structured with code to deploy Kubernetes on AWS EKS, Azure AKS, and Google Cloud GKE as components. Also, we’re deploying the Kubernetes Up and Running Demo as a component.

Putting it all together, deploying our many cloud architecture looks like this:

import * as k8s from "@pulumi/kubernetes";
import * as pulumi from "@pulumi/pulumi";
import * as aks from "./aks";
import * as app from "./app";
import * as eks from "./eks";
import * as gke from "./gke";
import * as local from "./local";

// Create Kubernetes clusters.
// Note: Comment out lines for any cluster you don't want to deploy.
const aksCluster = new aks.AksCluster("multicloud", {});
const eksCluster = new eks.EksCluster("multicloud", {});
const gkeCluster = new gke.GkeCluster("multicloud", {});

// Create a list of named clusters where the demo app will be deployed.
interface Cluster {
 name: string;
 provider: k8s.Provider;
 staticAppIP?: pulumi.Output<string>;
}
const clusters: Cluster[] = [
 // Note: Comment out lines for any cluster you don't want to deploy.
 {name: "aks", provider: aksCluster.provider, staticAppIP: aksCluster.staticAppIP},
 {name: "eks", provider: eksCluster.provider},
 {name: "gke", provider: gkeCluster.provider},
 {name: "local", provider: local.provider},
];

// Export a list of URLs to access the demo app.
interface AppUrl {
 name: string;
 url: pulumi.Output<string>;
}
export const appUrls: AppUrl[] = [];

const kuardImageTag = "blue";

// Create the application on each of the selected clusters.
for (const cluster of clusters) {
 const instance = new app.DemoApp(cluster.name, {
 provider: cluster.provider,
 imageTag: kuardImageTag,
 staticAppIP: cluster.staticAppIP,
 });

 const instanceUrl: AppUrl = {name: cluster.name, url: instance.appUrl};
 appUrls = appUrls.concat(instanceUrl);
}

When Kubernetes and the application is deployed across the three cloud service providers, Pulumi returns the URLs for each instance.

Using this example, you can quickly build any of the Kubernetes architectural patterns that we’ve discussed. Note that there’s a local Kubernetes cluster defined, and you can use that to experiment with different patterns.

Conclusion

Deploying modern applications is complex. Any one of the architectures we’ve examined – virtual machines, microservices, serverless and Kubernetes – require deploying and configuring multiple resources. For many reasons, including security, compliance, and cost management, we want to reuse resources consistently. In a sense, architecture as code is the logical progression of the DevOps principle of “cattle not pets”. Infrastructure as code is the tool that enables this by bringing standard development practices, such as code review, CI/CD, and testing to infrastructure. Learn how to build reusable infrastructure components with Pulumi’s programming model, API reference for cloud service providers, and examples.

Want to know more? Listen to the New Stack Context podcast on the Pulumi 2.0 release and Architecture as Code.

Architecture as Code: Serverless

Sophia Parafina — Tue, 28 Apr 2020 00:00:00 +0000

In this fourth installment of Architecture as Code series, we’ll take a look at serverless, an architectural pattern that has quickly gained popularity among cloud practitioners. There are two reasons why serverless usage has proliferated: a cost-saving pay as you go model and elasticity that goes from zero to as many as needed to complete the task without managing servers.

Overview

Serverless is a pattern for building services without having to manage servers. You write a service and deploy it on infrastructure managed by a cloud service provider. Serverless apps can be either a simple function invoked by an event or an application in a container. They are typically ephemeral, where the application runs within a fixed time or until it completes the task. Managed implementations such as AWS Lambda and Fargate, Azure Functions, and Google Cloud Run and Cloud Functions charge for the service only when it’s invoked and create instances, or workers, based on demand.

Developers can write the application in any language that the service provider supports. That means developers can choose the language that best meets the needs of their application. For example, a compiled application may respond more quickly than a scripting language. Serverless applications can be either synchronous or asynchronous, depending on the task.

A common feature of serverless architecture is a REST interface which maps HTTP operations such as GET, PUT, POST, and DELETE to functions. A REST interface simplifies implementing REST interfaces for functions and applications. AWS offers API Gateway for building REST interfaces, while Azure and Google Cloud have out of the box solutions.

Let’s take a look at examples where we can apply Architecture as Code to serverless.

Reusing resources

While serverless simplifies and reduces management overhead for deploying functions and containers, ancillary services also need to be configured. For example, a production deployment requires creating clusters, security groups, load balancers, and IAM policies. The following Python script creates resources that can be imported into __main__.py, which deploys the function or container. It ensures that each serverless application uses a vetted set of resources that can be replicated for every deployment.

from pulumi import export, ResourceOptions
import pulumi_aws as aws
import json

# Create an ECS cluster to run a container-based service.
cluster = aws.ecs.Cluster('cluster')

# Read back the default VPC and public subnets, which we will use.
default_vpc = aws.ec2.get_vpc(default='true')
default_vpc_subnets = aws.ec2.get_subnet_ids(vpc_id=default_vpc.id)

# Create a SecurityGroup that permits HTTP ingress and unrestricted egress.
group = aws.ec2.SecurityGroup('web-secgrp',
 vpc_id=default_vpc.id,
 description='Enable HTTP access',
 ingress=[{
 'protocol': 'tcp',
 'from_port': 80,
 'to_port': 80,
 'cidr_blocks': ['0.0.0.0/0'],
 }],
 egress=[{
 'protocol': '-1',
 'from_port': 0,
 'to_port': 0,
 'cidr_blocks': ['0.0.0.0/0'],
 }]
)

# Create a load balancer to listen for HTTP traffic on port 80.
alb = aws.lb.LoadBalancer('app-lb',
 security_groups=[group.id],
 subnets=default_vpc_subnets.ids
)

atg = aws.lb.TargetGroup('app-tg',
 port=80,
 protocol='HTTP',
 target_type='ip',
 vpc_id=default_vpc.id
)

wl = aws.lb.Listener('web',
 load_balancer_arn=alb.arn,
 port=80,
 default_actions=[{
 'type': 'forward',
 'target_group_arn': atg.arn
 }]
)

# Create an IAM role that can be used by our service's task.
role = aws.iam.Role('task-exec-role',
 assume_role_policy=json.dumps({
 'Version': '2008-10-17',
 'Statement': [{
 'Sid': '',
 'Effect': 'Allow',
 'Principal': {
 'Service': 'ecs-tasks.amazonaws.com'
 },
 'Action': 'sts:AssumeRole',
 }]
 })
)

rpa = aws.iam.RolePolicyAttachment('task-exec-policy',
 role=role.name,
 policy_arn='arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy'
)

To learn more about creating reusable components, read about Pulumi’s programming model, which shows how to author components.

Polyglot applications

This example shows how to deploy multiple functions in Google Cloud Functions. Note that we have one function written in Python and another in Go. The code that deploys the function is written in python and creates a Bucket to hold the function code and deploys both functions in the same script.

from pulumi_gcp import storage, cloudfunctions
from pulumi import export, asset

bucket = storage.Bucket("bucket")

py_bucket_object = storage.BucketObject(
 "python-zip",
 bucket=bucket.name,
 source=asset.AssetArchive({
 ".": asset.FileArchive("./pythonfunc")
 }))

py_function = cloudfunctions.Function(
 "python-func",
 source_archive_bucket=bucket.name,
 runtime="python37",
 source_archive_object=py_bucket_object.name,
 entry_point="handler",
 trigger_http="true",
 available_memory_mb=128,
)

export("python_endpoint", py_function.https_trigger_url)

go_bucket_object = storage.BucketObject(
 "go-zip",
 bucket=bucket.name,
 source=asset.AssetArchive({
 ".": asset.FileArchive("./gofunc")
 }))

go_function = cloudfunctions.Function(
 "go-func",
 source_archive_bucket=bucket.name,
 runtime="go111",
 source_archive_object=go_bucket_object.name,
 entry_point="Handler",
 trigger_http="true",
 available_memory_mb=128,
)

export("go_endpoint", go_function.https_trigger_url)

The full example is available on Github.

Cold Starts

Despite the many advantages of serverless, one of the challenges of serverless is latency, more commonly known as “cold starts.” There are several ways to lessen the impact of cold starts, including:

Invoking a pool of workers - a process known as ‘warming’.
Provisioned concurrency - workers that are always warm and dedicated to a specific function.
Dynamic concurrency - workers configured to autoscale as needed.
Scheduled profile - warming is applied during peak use.
Autoscaling-based utilization - adds workers as service utilization increases.

Deploying infrastructure with code lets you implement these strategies based on your application requirements. The code snippet below is an example of provisioned concurrency; a fully worked example is available on Github.

// Read the config of whether to provision fixed concurrency for Lambda
const config = new pulumi.Config();
const provisionedConcurrentExecutions = config.getNumber("provisionedConcurrency");

// Create a Lambda function, using code from the `./app` folder.
const lambda = new aws.lambda.Function("mylambda", {
 runtime: aws.lambda.DotnetCore2d1Runtime,
 code: new pulumi.asset.AssetArchive({
 ".": new pulumi.asset.FileArchive(dotNetApplicationPublishFolder),
 }),
 timeout: 300,
 handler: dotNetApplicationEntryPoint,
 role: role.arn,
 publish: !!provisionedConcurrentExecutions, // Versioning required for provisioned concurrency
 environment: {
 variables: {
 "COUNTER_TABLE": counterTable.name,
 },
 },
}, { dependsOn: [policy] });

if (provisionedConcurrentExecutions) {
 const concurrency = new aws.lambda.ProvisionedConcurrencyConfig("concurrency", {
 functionName: lambda.name,
 qualifier: lambda.version,
 provisionedConcurrentExecutions,
 });
}

Conclusion

Serverless is an attractive alternative to architectures that require hands-on management of servers. Despite this, it does not relieve you of the tasks needed to create and manage the ancillary resources needed for a modern application in production. Architecture as code enables you to declare resources and reuse them to ensure a standard and reproducible infrastructure. Also, you can deploy multiple functions and applications with a single Pulumi project, saving time and effort required to deploy them individually. Finally, you can tune your deployment strategies to overcome cold-start issues.

Architecture as Code: Microservices

Sophia Parafina — Tue, 07 Apr 2020 00:00:00 +0000

This article is the third in a series about Architecture as Code. The first article provided an overview of virtual machines, microservices, serverless, and Kubernetes. The second one went in-depth on deploying virtual machines as reusable components. In this third installment, we’ll look at microservices and how to implement them as reusable components with Pulumi.

Microservices

Microservice architecture is based on the idea that each service represents an individual capability or function in an application. Services are independent of each other and can be deployed without service interruption. They communicate with each other via requests over HTTP typically through REST interfaces.

Each service is an application unto itself that must be written, configured, and deployed in coordination with other services that comprise the application. Cloud-based resources have made standing up microservices easier; however, we still need to configure each service. The advantage of using standard programming languages to deploy services is that we can further abstract resources into reusable components and apply testing methodologies to improve quality.

In the following sections, we’ll discuss how to organize an application as microservices using stacks in Pulumi and how to configure the stacks so they can talk to each other. Also, we’ll look at an example application and show how to create reusable components to build microservices.

Projects and Stacks

Pulumi is organized around Projects and Stacks. A Project specifies the runtime to use, which determines where to find the program to execute during deployment. A Stack is an independent instance of a Pulumi program used to denote different phases of development (such as development, staging, and production) or feature branches (such as new-feature-dev).

Monolithic stacks are a common way to structure a project. A single project defines the infrastructure and resources for an entire service. However, Pulumi also supports deploying microservices as individual stacks within a project. Because microservices represent a specific business capability, having stacks for each service allows teams to work independently of each other. Separate stacks can enforce security policies through Role-Based Access Control, and each service can be built and deployed independently of other components.

Microservices deployed as stacks communicate with each other through the StackReference resource, which makes stack exports such as networking, environmental variables, and even Kubernetes configuration available to stacks in the project. The StackReference constructor takes as input a string of the form <organization>/<project>/<stack>, and lets services access the outputs of that stack. The following section walks through a microservices example that deploys a database on AWS RDS, a REST application in AWS Fargate, and an AWS Application Load Balancer.

A Microservices Application Infrastructure

We’ll use the AWS Stack Reference example to illustrate how Pulumi uses Architecture as Code to create reusable components and deployment frameworks. We’ve previously blogged about this example and covered the code in some detail.

Let’s examine how it creates reusable components for building out resources. First up is the VPC class in the networking stack.

In the networking service, vpc.ts creates a TypeScript class that extends Pulumi ComponentResource. A ComponentResource abstracts one or more children that do not require custom create, read, update, and delete operations for provisioning. We can add the related resources to the correct parent to build out the class.

export class Vpc extends ComponentResource {
 vpc: aws.ec2.Vpc;
 privateZone: aws.route53.Zone;
 dhcpOptionSet: aws.ec2.VpcDhcpOptions;
 internetGateway: aws.ec2.InternetGateway;
 publicSubnets: aws.ec2.Subnet[] = [];
 privateSubnets: aws.ec2.Subnet[] = [];
 publicRouteTable: aws.ec2.RouteTable;
 privateRouteTables: aws.ec2.RouteTable[] = [];
 natGateways: aws.ec2.NatGateway[] = [];
 natElasticIpAddresses: aws.ec2.Eip[] = [];

 // ...

The resource needs an interface to set the name and parameters for our new VPC class.

export interface VpcArgs {
 description: string;
 baseTags: aws.Tags;

 baseCidr: string;
 availabilityZoneNames: string[];
 enableFlowLogs?: boolean;

 endpoints: {
 s3: boolean;
 dynamodb: boolean;
 };
}

Finally, we need to be able to peer VPCs so that the services can communicate with each other. We can take advantage of TypeScript’s member function to implement peering.

public configurePeering(args: PeerToArgs) {

 // …
}

We can reuse this pattern to build a reusable database component from RDS. Likewise, the REST application creates a service using a container deployed in Fargate and fronted by an ALB. You can replace the container with an updated application without interrupting the service.

Jumping In

We encourage you to try out deploying microservices with stacks. To download just the stack example from the examples repository we’ll use a git sparse checkout to only copy the aws-ts-stackreference-architecture directory.

$ mkdir microservices
$ cd microservices

$ git init
$ git remote add origin -f https://github.com/pulumi/examples/
$ git config core.sparseCheckout true
$ aws-ts-stackreference-architecture >> .git/info/sparse-checkout
$ git pull origin master

Follow the instructions to deploy the application. Experiment with the example by adding data to the database and adding your REST application as a container. Add a web client to submit requests and display them. Let us know if you have questions on Community Slack or send a tweet to show off your application.

To learn more about stacks, watch Mike Metral’s presentation on PulumiTV.

Architecture as Code: Virtual Machines

Sophia Parafina — Tue, 31 Mar 2020 00:00:00 +0000

In a previous article, we presented an overview of four infrastructure patterns for deploying modern applications. The article reviewed virtual machines, serverless, Kubernetes, and microservices. In this post, we’ll examine virtual machines in-depth.

The Minimum Virtual Machine

Whether you choose to build a virtual machine using VMWare or from a cloud service provider such as AWS, Azure, or Google Cloud Platform, they require three resources. First, the instance itself must be configured to meet application requirements. Second, network access for maintaining the instance and for applications. Finally, storage for application data.

Let’s start with the EC2 provisioner example, which is available on Github. Make an empty directory and clone the example in the directory using pulumi new.

$ mkdir virtual_machine && cd virtual_machine
$ pulumi new https://github.com/pulumi/examples/tree/master/aws-ts-ec2-provisioners

Follow the instructions in the README to create an OpenSSH keypair and set them as secrets, we’ll need them to log into and provision the VM. Let’s take a look at the code. The first part configures the VM with the OpenSSH keys that we stored as secrets in the Pulumi configuration file (Pulumi.dev.yaml).

The following part defines a security group that allows us to ssh via port 22 and receive requests on port 80.

// Create a new security group that permits SSH and web access.
const secgrp = new aws.ec2.SecurityGroup("secgrp", {
 description: "Foo",
 ingress: [
 { protocol: "tcp", fromPort: 22, toPort: 22, cidrBlocks: ["0.0.0.0/0"] },
 { protocol: "tcp", fromPort: 80, toPort: 80, cidrBlocks: ["0.0.0.0/0"] },
 ],
});

Note that the security group only allows ingress, if we want to update the VM or add software via a package manager such as yum, we need to define egress.

// Create a new security group that permits SSH and http/https access.
const secgrp = new aws.ec2.SecurityGroup("secgrp", {
 description: "Foo",
 ingress: [
 { protocol: "tcp", fromPort: 22, toPort: 22, cidrBlocks: ["0.0.0.0/0"] },
 { protocol: "tcp", fromPort: 80, toPort: 80, cidrBlocks: ["0.0.0.0/0"] },
 { protocol: "tcp", fromPort: 443, toPort: 443, cidrBlocks: ["0.0.0.0/0"] },
 ],
 egress: [
 { protocol: "tcp", fromPort: 80, toPort: 80, cidrBlocks: ["0.0.0.0/0"] },
 { protocol: "tcp", fromPort: 443, toPort: 443, cidrBlocks: ["0.0.0.0/0"] },
 ],
});

The code block below selects the AWS AMI and creates an EC2 instance with the OpenSSH keypair and security group with ingress and egress rules configured.

// Get the AMI.
const amiId = aws.getAmi({
 owners: ["amazon"],
 mostRecent: true,
 filters: [{
 name: "name",
 values: ["amzn2-ami-hvm-2.0.????????-x86_64-gp2"],
 }],
}, { async: true }).then(ami => ami.id);

// Create an EC2 server that we'll then provision stuff onto.
const size = "t2.micro";
if (!keyName) {
 const key = new aws.ec2.KeyPair("key", { publicKey });
 keyName = key.keyName;
}

const server = new aws.ec2.Instance("server", {
 instanceType: size,
 ami: amiId,
 keyName: keyName,
 vpcSecurityGroupIds: [ secgrp.id ],

});

Next, let’s add storage to our virtual machine using AWS Elastic Block Storage and attach it to our EC2 instance. Add the following code after the virtual machine is created. The code creates a 10 GB volume and attaches it to our virtual machine via the instanceId property.

// Add EBS storage.
const ebsvolume = new aws.ebs.Volume("vm", {
 availabilityZone: "us-west-2a",
 size: 10,
 tags: {
 Name: "vm_volume",
 },
});

// Attach storage to the virtual machine.
const ebsAtt = new aws.ec2.VolumeAttachment("ebsAtt", {
 deviceName: "/dev/sdh",
 instanceId: server.id,
 volumeId: ebsvolume.id,
});

Now we have a virtual machine that can receive HTTP and HTTPS requests and allows outbound network traffic so that we can update and install software via the package manager.

Provisioning with Dynamic Providers

Provisioning a VM when it’s created by running user-supplied scripts is relatively straightforward. For example, AWS EC2 instances have a userData parameter that allows you to specify an inline script that runs when the instance starts. But what if you need to copy and execute scripts on the virtual machine without replacing the instance?

This where you can use Pulumi’s dynamic provider to provision existing instances. Dynamic providers enable creating custom resource types, such as provisioners, within the source code of your Pulumi program. They let you execute arbitrary code during the deployment process. Dynamic provisioners run during resource provisioning, and enable adding custom logic to a deployment workflow during the create, read, update, or delete steps of a Pulumi program.

Let’s look at the code which creates a dynamic provisioner. In the code below, if Pulumi doesn’t find the resource, it creates the resource. However, if you run pulumi up again and the resource is already running, Pulumi uses the diff method to replace the resource.

// Provisioner lets a custom action run the first time a resource has been created. It takes as input
// a dependent property. Anytime its value changes, the resource is replaced and will re-run its logic.
export class Provisioner<T, U> extends pulumi.dynamic.Resource {
 dep: pulumi.Output<T>;
 result: pulumi.Output<U>;
 constructor(name: string, props: ProvisionerProperties<T, U>, opts?: pulumi.CustomResourceOptions) {
 const provider: pulumi.dynamic.ResourceProvider = {
 diff: async (id: pulumi.ID, olds: State<T, U>, news: State<T, U>) => {
 const replace = JSON.stringify(olds.dep) !== JSON.stringify(news.dep);
 return {
 changes: replace,
 replaces: replace ? ["dep"] : undefined,
 deleteBeforeReplace: true,
 };
 },
 create: async (inputs: State<T, U>) => {
 const result = await props.onCreate(inputs.dep);
 if (result !== undefined) {
 inputs.result = result;
 }
 return { id: uuid.v4(), outs: inputs };
 },
 };
 super(provider, name, { dep: props.dep, result: null }, opts);
 }
}

export interface ProvisionerProperties<T, U> {
 dep: pulumi.Input<T>;
 onCreate: (dep: pulumi.Unwrap<T>) => Promise<pulumi.Unwrap<U>>;
}

interface State<T, U> {
 dep: pulumi.Unwrap<T>;
 result: pulumi.Unwrap<U>;
}

This example creates two interfaces using the provisioner. The first is a copyFile function that lets us copy the configuration files to the virtual machine. The second interface is the runCommand function, which runs commands on the virtual machine. Underlying both functions is the ‘connToSsh2’ function that opens the ssh connection to copy files via scp and to execute commands. When you run pulumi up the example writes a small configuration file on the virtual machine then runs ‘cat’ to print the configuration file to stdout.

Installing PostgreSQL

Let’s modify the example to install and configure PostgreSQL. First, create a directory to hold the installation script and configuration files.

$ mkdir ./postgres

Add the following files to the postgres directory. The postgres.conf file is a bare-bones configuration file the allows PostgreSQL to allow connections from any IP address on port 5432. The pg_hba.conf file permits authentication for connections with a password.

# postgres.conf

# -----------------------------
# PostgreSQL configuration file
# -----------------------------
#

#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------

# - Connection Settings -

listen_addresses = '*' # what IP address(es) to listen on;
 # comma-separated list of addresses;
 # defaults to 'localhost'; use '*' for all
 # (change requires restart)
port = 5432 # (change requires restart)

# pg_hba.conf

# TYPE DATABASE USER ADDRESS METHOD

# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust

Finally, the postgres_install.sh is a bash script that installs Postgres with the yum package manager. It initializes the database, replaces the configuration scripts, and starts the database.

#!/bin/bash

# This script installs and configures PostgreSQL
sudo yum -y install postgresql postgresql-server postgresql-devel postgresql-contrib postgresql-docs
sudo postgresql-setup initdb

# Copy configuration files
sudo cp -f ./pg_hba.conf /var/lib/pgsql/data/pg_hba.conf
sudo cp -f ./postgresql.conf /var/lib/pgsql/data/postgresql.conf

# Start postgres
sudo service postgresql start

To provision the EC2 instance we’ll use the provisioner interface to copy the ./postgres directory to the instance. Next, we’ll make postgres_install.sh executable then run the script to install postgres and start it up.

// Copy a config file to our server.
const cpConf = new provisioners.CopyFile("postgres_conf", {
 conn,
 src: "./postgres/",
 dest: "./",
}, { dependsOn: server });

// Execute a basic command on our server.
const chmodInstall = new provisioners.RemoteExec("chmod-install", {
 conn,
 command: "chmod 755 postgres_install.sh ",
}, { dependsOn: cpConf });

// Execute a basic command on our server.
const installPgsql = new provisioners.RemoteExec("pg_install", {
 conn,
 command: "./postgres_install.sh ",
}, { dependsOn: chmodInstall });

export const publicIp = server.publicIp;
export const publicHostName = server.publicDns;

Note that the dependsOn parameter determines the sequence of deployment steps. This ensures that each part is available to the provisioner at that step. To deploy PostgreSQL on your virtual machine, run pulumi up. You can check the install by logging into the virtual machine and use psql to log into the database and list the tables.

$ ssh -i rsa ec2-user@$(pulumi stack output publicHostName)

# In the virtual machine
$ sudo su - postgres
-bash-4.2$ psql -U postgres
psql (9.2.24)
Type "help" for help.

postgres=# \dS
 pg_catalog | pg_aggregate | table | postgres
 pg_catalog | pg_am | table | postgres
 pg_catalog | pg_amop | table | postgres
 pg_catalog | pg_amproc | table | postgres
 pg_catalog | pg_attrdef | table | postgres
 pg_catalog | pg_attribute | table | postgres
 pg_catalog | pg_auth_members | table | postgres
 pg_catalog | pg_authid | table | postgres
...

postgres=# \q
-bash-4.2$ logout

Conclusion

We can deploy and configure virtual machines programmatically using scripts and a CLI. However, updating existing instances can be onerous because it would require logging into each instance to update them. With Pulumi, we can use a dynamic provider to create a provisioner that can provision and configure an existing virtual machine. In this post, we walked through how to create a virtual machine with storage, starting from an example on Github. We then installed PostgreSQL using a provisioner that copied configuration files, and an installation script then ran the script, all without creating a new virtual machine.

We have more virtual machine examples for other cloud providers. Check out:

In our next installment, we’ll go into detail about deploying applications on serverless infrastructure.

Managing AWS Credentials on CI/CD: Part 2

Chris Smith — Thu, 26 Mar 2020 00:00:00 +0000

This article is the second part of a series on best practices for securely managing AWS credentials on CI/CD. In this article, we go in-depth on providing AWS credentials securely to a 3rd party and introduce a Pulumi program to automate rotating access keys.

NOTE: These recommendations do not apply if you are running a CI/CD system within your AWS account, e.g., running a Jenkins server on EC2 or using AWS CodeDeploy. In those cases, please refer to AWS’s documentation for how to assume IAM Roles when running on an EC2 instance instead.

Provide IAM credentials to your CI/CD system

In the first post in our series, we created a dedicated IAM User to perform updates to AWS resources within your CI/CD system. The next step is to pass the AWS access keys for that user to your CI/CD system.

We need to take great caution. AWS’s documentation states, “Do not provide your access keys to a third party”.

Providing AWS access keys to any system is dangerous because of the risk that a bad actor could obtain those keys and do something nefarious. Even if your CI/CD service takes great care to protect your secrets, those AWS credentials could be inadvertently exposed in debugging output, system logs, or in some other way.

This is one of the main advantages of performing continuous deployment from within your AWS account. For example, running Jenkins on an EC2 instance you manage, or using the AWS CodeDeploy service. Because when performing a deployment from within an AWS compute environment, you can use built-in mechanisms to obtain credentials securely.

However, there are many reasons to use a hosted service for performing your CI/CD, such as developer productivity, ease of use, performance, or simply because you don’t want to recreate your existing deployment workflows.

Ultimately, it is essential to understand the risks involved and how to mitigate them.

Properly Storing Credentials

If you choose to provide your CI/CD with credentials, the most important thing is to mark them as secret. Your CI/CD provider typically has built-in support for handling “secure variables” or other sensitive information. As opposed to general, configuration data or environment variables.

User-supplied configuration values are typically write-only and only accessible by the CI/CD worker jobs at runtime. For example, Travis CI has encrypted environment variables or secure environment variables in CircleCI.

Please consult your CI/CD provider’s documentation for how to pass and store sensitive information appropriately.

Why not use a “secrets manager” service?

A common question when discussing is how to pass access keys to a CI/CD system securely:

Rather than giving your CI/CD provider AWS credentials, why not have your CI/CD system obtain credentials from a specialized “secrets manager” service?

In other words, if you choose not to trust your CI/CD system with this data, can you instead trust some other system dedicated for securely storing and retrieving sensitive information?

It sounds like a good idea on the surface but doesn’t seem to make your data any more secure.

Abstractly, the difference here is that the credentials are provided on-demand, rather than being available to the CI/CD job when it starts (and stored via the CI/CD provider). Instead, your CI/CD job would obtain credentials from the “secrets manager” only when needed.

There are some advantages to this approach, such as providing a clear audit trail for access and more control over the distribution of sensitive information.

However, the secrets provider system needs to be presented with some form of credentials. And those credentials need to be available to your CI/CD environment. So using a secrets manager leaves you in the same place you started, i.e., needing to provide sensitive data to your CI/CD provider.

Also, by adding a dependency on a secrets manager, you introduce additional risks. Not only do you need to be even more security-conscious about that secrets manager, but it also needs to be highly available. Any outage for that service would mean that you would be unable to perform deployments!

So it does not seem that using a secrets manager to dole out AWS credentials to your CI/CD system is a good practice to follow. Or, at the very least, makes some tradeoffs without fundamentally making your approach to CI/CD any more or less secure.

Instead, it is better to focus on other ways to reduce the risk if those AWS credentials do get exposed.

Automate Rotating and Revoking AWS Credentials

When providing credentials to a 3rd party, rather than hoping it will be 100% secure forever (which is impossible), we can make those credentials volatile. If we regularly invalidate and rotate the credentials supplied to the CI/CD system, we can dramatically reduce the impact of any accidental disclosure. Even if the IAM User’s credentials were leaked, by the time they were discovered and used, they would no longer be valid.

The AWS security blog describes how to rotate access keys for IAM Users, by using the following steps:

Create a second access key in addition to the one in use.
Update all your applications to use the new access key.
Change the state of the previous access key to inactive.
Verify everything is still working as expected.
Delete the inactive access key.

That all sounds simple enough, but it’s certainly tedious. And if you need to repeat the process across dozens, if not hundreds of different CI/CD pipelines, you need a better solution. Fortunately, Pulumi provides an excellent and extensible way for writing a serverless program to automate rotating credentials.

The next few sections describe a simple infrastructure application for automating AWS IAM credential rotation. You can see the full application on GitHub at chrsmith/pulumi-aws-travis-cicd-demo.

AWS Credential Rotator 9000

The affectionally titled AWS Credential Rotator 9000 is a simple, serverless Pulumi application for rotating AWS access keys.

It creates an AWS lambda function that’s triggered on a regular schedule, e.g., every 30 minutes, and performs the next step in the sequence for rotating access keys as outlined above.

First, it creates a new access key and pushes the new value out. On the next iteration, it marks the older access key as “inactive.” On the following iteration, the inactive key is deleted. The process repeats, generating a new key and removing the inactive key.

Periodically Invoking an AWS Lambda

The heart of the application is triggering it to execute on a fixed interval. Thankfully this is super-easy to do using Pulumi since it allows you to seamlessly blend your “cloud infrastructure” with “code” in a natural way. The user guide for Pulumi Crosswalk for AWS has more information on serverless eventing if you would like to learn more.

The following snippet is the core part of the credential rotator app. We define a function to handle the logic of key rotation in rotateIAMUserKeys. Then we create an AWS Lambda resource named lambda. Finally, the triggerSchedule resource invokes our lambda on a fixed schedule, thereby ensuring that the key rotation process goes on indefinitely. You can see the full code here.

async function rotateIAMUserKeys(iamUser: aws.iam.User, onNewCredentials: (key: string, secret: string) => Promise<void>) {
 ...
}

const lambda = new aws.lambda.CallbackFunction<aws.cloudwatch.EventRuleEvent, void>(
 "keyRotatorLambda",
 {
 callback: async (e) => {
 await rotateIAMUserKeys(userToRotate, async (newKey: string, newSecret: string) => {
 console.log("onNewCredentials callback called!");
 console.log(`A new AWS access key "${newKey}" has been created.`);
 });
 },

 role: lambdaRole,
 runtime: "nodejs10.x",
 });

const triggerSchedule = aws.cloudwatch.onSchedule(
 "keyRotatorScheduler", "rate(1 hour)", lambdaCallbackFn);

When writing reusable infrastructure components in Pulumi however, it is helpful to organize things into a custom resource.

For example, we can bundle together the AWS Lambda, CloudWatcn schedule, and the associated IAM policies into a single conceptual resource AccessKeyRotator. Bundling resources allows for the code reuse.

const rotator = new AccessKeyRotator("rotator", {
 interval: config.require("rate"),
 user: user,
 credentialPusher: demoTravisCIPusher,
})

Pushing Credentials

With the mechanics of updating an AWS access key out of the way, the next step is to notify dependent systems what the new access key should be. The key rotator app has a CredentialPusher abstraction to provide a pluggable way for you to send credentials to where they need to be. The example on GitHub only supports updating a Travis CI project (See credential-pusher-travis.ts.), but it could be easily extended to support other CI/CD systems.

The following snippet shows how the CredentialPusher is configured in the key rotator app. We load a Travis CI access token from the Pulumi stack’s configuration, and hard-code the specific set of projects and encrypted environment variables to store the new access key.

// A "credential pusher" is the component that pushes new AWS IAM credentials out to 3rd parties
// as the older ones get rotated. For demonstration purposes, this updates the Travis CI settings
// for the chrsmith/pulumi-aws-travis-cicd-demo repo. But you can imagine another implementation
// that pushes the new IAM credentials to GitLab CI, or updating multiple CI/CD pipelines.

const demoTravisCIPusher = new CredentialPusher(
 new TravisCIPusher(),
 {
 accessKey: config.require("travis-ci-token"),
 projects: [
 {
 project: "chrsmith/pulumi-aws-travis-cicd-demo",
 // In the Travis CI configuration for that GitHub repo, there are two
 // environment variables for storing the AWS credentials. So whenever the
 // AWS credentials get rotated, the job's configuration settings will be
 // updated to reflect the new values.
 accessKeyIDLocation: "AWS_ACCESS_KEY_ID",
 secretAccessKeyLocation: "AWS_SECRET_ACCESS_KEY",
 }
 ],
 });

Demo

To demonstrate the access keys rotation, we can examine the log files generated from AWS Lambda. These can be accessed from the command-line using the pulumi logs command.

Here’s a summary of the output for clarity:

 START RequestId: 9406913e-a9d0-46a4-b861-2efdee508b2b Version: $LATEST
 9406913e-a9d0-46a4-b861-2efdee508b2b INFO IAM User has 2 keys:
 9406913e-a9d0-46a4-b861-2efdee508b2b INFO - AKIASHIVKXX3QEQNZNX5 [Active] Tue Mar 24 2020 12:37:03 GMT+0000 (Coordinated Universal Time)
 9406913e-a9d0-46a4-b861-2efdee508b2b INFO - AKIASHIVKXX3SA2K3ME7 [Inactive] Tue Mar 24 2020 09:37:03 GMT+0000 (Coordinated Universal Time)
 9406913e-a9d0-46a4-b861-2efdee508b2b INFO Deleting older, inactive access key AKIASHIVKXX3SA2K3ME7 [Inactive]
 9406913e-a9d0-46a4-b861-2efdee508b2b INFO Key rotation step complete.
 END RequestId: 9406913e-a9d0-46a4-b861-2efdee508b2b

 START RequestId: 05644e4a-81a4-4197-8ad7-fc3517998270 Version: $LATEST
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO IAM User has 1 keys:
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO - AKIASHIVKXX3QEQNZNX5 [Active] Tue Mar 24 2020 12:37:03 GMT+0000 (Coordinated Universal Time)
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Created new key key AKIASHIVKXX3YX4IXRVH
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Pushing out the new key to 3rd party services...
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Pushing new credentials to Travis CI project 'chrsmith/pulumi-aws-travis-cicd-demo'
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Updating env var 'AWS_ACCESS_KEY_ID' (b246ab3b-c4cb-e76f-a6fc-50f4cbf451c0)
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Updated AWS access key ID. Got response code (200)
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Updating env var 'AWS_SECRET_ACCESS_KEY' (ba9ac4be-fbb3-4da9-c5b8-35a1afe9e02b)
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Updated AWS secret access key. Got response code (200)
 05644e4a-81a4-4197-8ad7-fc3517998270 INFO Key rotation step complete.
 END RequestId: 05644e4a-81a4-4197-8ad7-fc3517998270

 START RequestId: ca204959-32a7-44a8-ba20-738d139542ba Version: $LATEST
 ca204959-32a7-44a8-ba20-738d139542ba INFO IAM User has 2 keys:
 ca204959-32a7-44a8-ba20-738d139542ba INFO - AKIASHIVKXX3YX4IXRVH [Active] Tue Mar 24 2020 15:37:03 GMT+0000 (Coordinated Universal Time)
 ca204959-32a7-44a8-ba20-738d139542ba INFO - AKIASHIVKXX3QEQNZNX5 [Active] Tue Mar 24 2020 12:37:03 GMT+0000 (Coordinated Universal Time)
 ca204959-32a7-44a8-ba20-738d139542ba INFO Invalidating older access key AKIASHIVKXX3QEQNZNX5
 ca204959-32a7-44a8-ba20-738d139542ba INFO Key rotation step complete.
 END RequestId: ca204959-32a7-44a8-ba20-738d139542ba

 START RequestId: de753fb4-0720-4f4f-a7aa-ad6b9d4c8832 Version: $LATEST
 de753fb4-0720-4f4f-a7aa-ad6b9d4c8832 INFO IAM User has 2 keys:
 de753fb4-0720-4f4f-a7aa-ad6b9d4c8832 INFO - AKIASHIVKXX3YX4IXRVH [Active] Tue Mar 24 2020 15:37:03 GMT+0000 (Coordinated Universal Time)
 de753fb4-0720-4f4f-a7aa-ad6b9d4c8832 INFO - AKIASHIVKXX3QEQNZNX5 [Inactive] Tue Mar 24 2020 12:37:03 GMT+0000 (Coordinated Universal Time)
 de753fb4-0720-4f4f-a7aa-ad6b9d4c8832 INFO Deleting older, inactive access key AKIASHIVKXX3QEQNZNX5 [Inactive]
 de753fb4-0720-4f4f-a7aa-ad6b9d4c8832 INFO Key rotation step complete.
 END RequestId: de753fb4-0720-4f4f-a7aa-ad6b9d4c8832

As you can see, the AWS credentials for the IAM User are automatically updated every few hours. And whenever a new access key is created, the value is pushed out to the impacted Travis CI projects automatically.

Wrapping Up

In this post, we covered some of the things to consider when providing AWS credentials to your CI/CD system. (In short, be cautious and follow best practices.)

We then showed how relatively easy it is to stand up a Pulumi infrastructure application for automatically rotating AWS access keys and updating your CI/CD system. By rotating credentials, you can limit the impact if the value is inadvertently disclosed.

At this point, we’ve now given access keys to a CI/CD system for a low-privilege AWS IAM User account. But we still can’t do anything with it. The IAM User whose credentials we have given to the CI/CD system doesn’t have access to your production AWS account.

In the next post, we’ll go into the details about IAM Roles, and they can be used to securely and temporarily gain access to additional resources. This is how our low-privilege IAM User can access needed to update production data for your CI/CD pipelines.

Unit Testing Infrastructure

Sophia Parafina — Tue, 24 Mar 2020 00:00:00 +0000

We’re pleased to announce that unit testing with Node.js, Python, .NET, and Go is supported in recent releases. You can test resources before deploying your infrastructure using familiar tools and test frameworks. Check your resource configuration and responses without the wait of deploying them and speed up infrastructure development and production deployments.

Pulumi brings testing to Infrastructure as Code. Testing your infrastructure code will provide early bug notification, cleaner and more extensible code, and simplify refactoring. We implemented testing with these goals in mind.

Run code without the engine
Write tests using existing test tools and frameworks
Mock any dependencies

Here are examples in Python and Go to get you started.

Python

First we’ll set up an AWS EC2 instance as a web server to test.

import pulumi
from pulumi_aws import ec2

group = ec2.SecurityGroup('web-secgrp', ingress=[
 { "protocol": "tcp", "from_port": 22, "to_port": 22, "cidr_blocks": ["0.0.0.0/0"] },
 { "protocol": "tcp", "from_port": 80, "to_port": 80, "cidr_blocks": ["0.0.0.0/0"] },
])

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

server = ec2.Instance('web-server-www;',
 instance_type="t2.micro",
 security_groups=[ group.name ], # reference the group object above
 user_data=user_data, # start a simple web server
 ami="ami-c55673a0") # AMI for us-east-2 (Ohio)

pulumi.export('group', group)
pulumi.export('server', server)
pulumi.export('publicIp', server.public_ip)
pulumi.export('publicHostName', server.public_dns)

Using Python’s unittest framework we can test if the test service conforms to a configuration that restricts an exposed port 22 and use of user_data and enforces the use of tags and membership in a security group.

import unittest
import pulumi

# Create the mock.
class MyMocks(pulumi.runtime.Mocks):
 def call(self, token, args, provider):
 return {}

 def new_resource(self, type_, name, inputs, provider, id_):
 if type_ == 'aws:ec2/securityGroup:SecurityGroup':
 state = {
 'arn': 'arn:aws:ec2:us-west-2:123456789012:security-group/sg-12345678',
 'name': inputs['name'] if 'name' in inputs else name + '-sg',
 }
 return ['sg-12345678', dict(inputs, **state)]
 elif type_ == 'aws:ec2/instance:Instance':
 state = {
 'arn': 'arn:aws:ec2:us-west-2:123456789012:instance/i-1234567890abcdef0',
 'instanceState': 'running',
 'primaryNetworkInterfaceId': 'eni-12345678',
 'privateDns': 'ip-10-0-1-17.ec2.internal',
 'publicDns': 'ec2-203-0-113-12.compute-1.amazonaws.com',
 'publicIp': '203.0.113.12',
 }
 return ['i-1234567890abcdef0', dict(inputs, **state)]
 else:
 return ['', {}]

pulumi.runtime.set_mocks(MyMocks())

# Import the EC2 web server.
import infra

class InfraTests(unittest.TestCase):

 # Test if the service has tags and a name tag.
 @pulumi.runtime.test
 def test_server_tags(self):
 def check_tags(args):
 urn, tags = args
 self.assertIsNotNone(tags, f'server {urn} must have tags')
 self.assertIn('Name', tags, 'server {urn} must have a name tag')

 return pulumi.Output.all(infra.server.urn, infra.server.tags).apply(check_tags)

 # Test if the instance is configured with user_data.
 @pulumi.runtime.test
 def test_server_userdata(self):
 def check_user_data(args):
 urn, user_data = args
 self.assertFalse(user_data, f'illegal use of user_data on server {urn}')

 return pulumi.Output.all(infra.server.urn, infra.server.user_data).apply(check_user_data)

 # Test if service is a member of a security group.
 @pulumi.runtime.test
 def test_server_security_groups(self):
 def check_security_groups(args):
 urn, security_groups = args
 self.assertIsNotNone(security_groups, f'server {urn} does not specify security_groups')
 self.assertGreater(len(security_groups), 0, f'server {urn} does not specify security_groups')

 return pulumi.Output.all(infra.server.urn, infra.server.security_groups).apply(check_security_groups)

 # Test if port 22 for ssh is exposed.
 @pulumi.runtime.test
 def test_security_group_rules(self):
 def check_security_group_rules(args):
 urn, ingress = args
 ssh_open = any([rule['from_port'] == 22 and any([block == "0.0.0.0/0" for block in rule['cidr_blocks']]) for rule in ingress])
 self.assertFalse(ssh_open, f'security group {urn} exposes port 22 to the Internet (CIDR 0.0.0.0/0)')

 # Return the results of the unit tests.
 return pulumi.Output.all(infra.group.urn, infra.group.ingress).apply(check_security_group_rules)

Go

This is the same example, but written in Go using the stretchr framework for unit tests.

package main

import (
 "github.com/pulumi/pulumi-aws/sdk/v2/go/aws/ec2"
 "github.com/pulumi/pulumi/sdk/v2/go/pulumi"
)

type infrastructure struct {
 group *ec2.SecurityGroup
 server *ec2.Instance
}

func createInfrastructure(ctx *pulumi.Context) (*infrastructure, error) {
 group, err := ec2.NewSecurityGroup(ctx, "web-secgrp", &ec2.SecurityGroupArgs{
 Ingress: ec2.SecurityGroupIngressArray{
 ec2.SecurityGroupIngressArgs{
 Protocol: pulumi.String("tcp"),
 FromPort: pulumi.Int(22),
 ToPort: pulumi.Int(22),
 CidrBlocks: pulumi.StringArray{pulumi.String("0.0.0.0/0")},
 },
 ec2.SecurityGroupIngressArgs{
 Protocol: pulumi.String("tcp"),
 FromPort: pulumi.Int(80),
 ToPort: pulumi.Int(80),
 CidrBlocks: pulumi.StringArray{pulumi.String("0.0.0.0/0")},
 },
 },
 })
 if err != nil {
 return nil, err
 }

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

 server, err := ec2.NewInstance(ctx, "web-server-www", &ec2.InstanceArgs{
 InstanceType: pulumi.String("t2-micro"),
 SecurityGroups: pulumi.StringArray{group.ID()},
 Ami: pulumi.String("ami-c55673a0"),
 UserData: pulumi.String(userData),
 })
 if err != nil {
 return nil, err
 }

 return &infrastructure{
 group: group,
 server: server,
 }, nil
}

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {
 infra, err := createInfrastructure(ctx)
 if err != nil {
 return err
 }

 ctx.Export("group", infra.group.ID())
 ctx.Export("server", infra.server.ID())
 ctx.Export("publicIp", infra.server.PublicIp)
 ctx.Export("publicHostName", infra.server.PublicDns)
 return nil
 })
}

We implement the same tests used in the Python example.

package main

import (
 "fmt"
 "sync"
 "testing"

 "github.com/pulumi/pulumi-aws/sdk/v2/go/aws/ec2"
 "github.com/pulumi/pulumi/sdk/v2/go/common/resource"
 "github.com/pulumi/pulumi/sdk/v2/go/pulumi"
 "github.com/stretchr/testify/assert"
)

type mocks int

// Create the mock.
func (mocks) NewResource(typeToken, name string, inputs resource.PropertyMap, provider, id string) (string, resource.PropertyMap, error) {
 switch typeToken {
 case "aws:ec2/securityGroup:SecurityGroup":
 if _, ok := inputs["name"]; !ok {
 inputs["name"] = resource.NewStringProperty(name + "-sg")
 }
 inputs["arn"] = resource.NewStringProperty("arn:aws:ec2:us-west-2:123456789012:security-group/sg-12345678")
 return "sg-12345678", inputs, nil
 case "aws:ec2/instance:Instance":
 inputs["arn"] = resource.NewStringProperty("arn:aws:ec2:us-west-2:123456789012:instance/i-1234567890abcdef0")
 inputs["instanceState"] = resource.NewStringProperty("running")
 inputs["primaryNetworkInterfaceId"] = resource.NewStringProperty("eni-12345678")
 inputs["privateDns"] = resource.NewStringProperty("ip-10-0-1-17.ec2.internal")
 inputs["publicDns"] = resource.NewStringProperty("ec2-203-0-113-12.compute-1.amazonaws.com")
 inputs["publicIp"] = resource.NewStringProperty("203.0.113.12")
 return "i-1234567890abcdef0", inputs, nil
 default:
 return "", inputs, fmt.Errorf("unexpected resource type %v", typeToken)
 }
}

func (mocks) Call(token string, args resource.PropertyMap, provider string) (resource.PropertyMap, error) {
 return args, fmt.Errorf("unexpected function call %v", token)
}

// Applying unit tests.
func TestInfrastructure(t *testing.T) {
 err := pulumi.RunErr(func(ctx *pulumi.Context) error {
 infra, err := createInfrastructure(ctx)
 assert.NoError(t, err)

 var wg sync.WaitGroup
 wg.Add(4)

 // Test if the service has tags and a name tag.
 pulumi.All(infra.server.URN(), infra.server.Tags).ApplyT(func(all []interface{}) error {
 urn := all[0].(pulumi.URN)
 tags := all[1].(map[string]interface{})

 assert.Containsf(t, tags, "name", "missing a name tag on server %v", urn)
 wg.Done()
 return nil
 })

 // Test if the instance is configured with user_data.
 pulumi.All(infra.server.URN(), infra.server.UserData).ApplyT(func(all []interface{}) error {
 urn := all[0].(pulumi.URN)
 userData := all[1].(*string)

 assert.Nilf(t, userData, "illegal use of userData on server %v", urn)
 wg.Done()
 return nil
 })

 // Test if service is a member of a security group.
 pulumi.All(infra.server.URN(), infra.server.SecurityGroups).ApplyT(func(all []interface{}) error {
 urn := all[0].(pulumi.URN)
 securityGroups := all[1].([]string)

 assert.Greaterf(t, len(securityGroups), 0, "illegal security group spec on server %v", urn)
 wg.Done()
 return nil
 })

 // Test if port 22 for ssh is exposed.
 pulumi.All(infra.group.URN(), infra.group.Ingress).ApplyT(func(all []interface{}) error {
 urn := all[0].(pulumi.URN)
 ingress := all[1].([]ec2.SecurityGroupIngress)

 for _, i := range ingress {
 openToInternet := false
 for _, b := range i.CidrBlocks {
 if b == "0.0.0.0/0" {
 openToInternet = true
 break
 }
 }

 assert.Falsef(t, i.FromPort == 22 && openToInternet, "illegal SSH port 22 open to the Internet (CIDR 0.0.0.0/0) on group %v", urn)
 }

 wg.Done()
 return nil
 })

 wg.Wait()
 return nil
 }, pulumi.WithMocks("project", "stack", mocks(0)))
 assert.NoError(t, err)
}

Try it out today

We’ve released these features early so that you can try them out before the 2.0 release. To get you started, we’ve added full working examples on Github. With the 2.0 release we’ll have more documentation, examples, and blog posts. In the meantime, we would appreciate feedback on our Community Slack channel.

Architecture as Code

Sophia Parafina — Fri, 20 Mar 2020 00:00:00 +0000

Abstraction is key to building resilient systems because it encapsulates behavior and decouples code, letting each component perform its function independently. The same principles apply to infrastructure, where we want to declare behavior or state and not implementation details. As an industry, we’ve moved away from monolithic applications to distributed systems such as serverless, microservices, Kubernetes, and virtual machine deployments. In this article, we’ll take a closer look at the characteristics of these architectures and how Pulumi can abstract the components that comprise these systems.

Virtual Machines

Virtual machines arose from the need to use expensive hardware more efficiently. VMs are more efficient because they share the host server, decreasing the number of physical servers needed to run applications. A group of hosts can also be aggregated so that it behaves as a single virtual host with large memory and processing capabilities. Virtual machines can emulate other environments that have specific hardware requirements or capabilities that the host machine does not have, thus reducing the need for specific hardware or operating systems. Virtualization provides the host machine isolation from the guest virtual machines by limiting access to the host machine through an abstraction layer. Finally, virtualization has the added advantage of providing a fine degree of control over resources available to the virtual machine.

If virtual machines are part of your infrastructure, Pulumi lets you create virtual machines programmatically across cloud service providers. The JavaScript example below illustrates how to deploy a virtual machine on Google Cloud Platform. The script spins up a Debian based instance and creates a network with an open port 22 to let you configure and manage the machine as needed.

const gcp = require("@pulumi/gcp");
const fs = require("fs");

// Create a network
const network = new gcp.compute.Network("network");
const computeFirewall = new gcp.compute.Firewall("firewall", {
 network: network.id,
 allows: [{
 protocol: "tcp",
 ports: [ "22", "80" ],
 }],
});

// Read the configuration script
const startupScript = fs.readFileSync("config.sh", "utf-8")

// Create a Virtual Machine Instance.
const computeInstance = new gcp.compute.Instance("instance", {
 machineType: "f1-micro",
 zone: "us-central1-a",
 metadataStartupScript: startupScript,
 bootDisk: { initializeParams: { image: "debian-cloud/debian-9" } },
 networkInterfaces: [{
 network: network.id,
 // accessConfigs must include a single empty config to request an ephemeral IP.
 accessConfigs: [{}],
 }],
});

// Export the name and IP address of the Instance.
exports.instanceName = computeInstance.name;
exports.instanceIP = computeInstance.networkInterfaces.apply(ni => ni[0].accessConfigs[0].natIp);

This is the configuration script, config.sh, referenced in the code:

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

When the virtual machine is created, it reads the configuration file that creates a webserver. This a basic example, but it shows how to configure virtual machines programmatically, which is useful for scaling horizontally.

Serverless

Serverless is a computing architecture characterized by server-side logic running in stateless containers that are invoked by events. They are typically ephemeral (often are available for only one call), and managed by third-party cloud providers. Serverless is also called Functions as a Service, or FaaS, and well-known implementations include AWS Lambda and Fargate, Azure Functions, and Google Cloud Run and Cloud Functions.

A significant benefit of serverless is that it’s a polyglot platform that allows developers to choose languages optimized for a task. For example, scripting languages like JavaScript or Python may be more responsive than a language such as Java. Serverless functions can support both synchronous and asynchronous calls. There are use cases that require an immediate response such as processing a video stream and instances where returning the result immediately is not critical as in an ETL batch job.

A key part of serverless architecture is an API Gateway that provides logical routes for mapping standard HTTP operations such as GET, PUT, POST, and DELETE to functions. The gateway makes development easier since these are standard and well-known interfaces. In addition to an API Gateway, the serverless platform should provide REST endpoints that allow you to manage the deploy with a CLI, portal, or an automation script. Finally, serverless architecture is extensible and supports integration with event sources and resources from the cloud provider through webhooks and other mechanisms.

The following example illustrates how to deploy two functions using TypeScript, one written in Python and the other written in Go. You can find the full example in the Pulumi GitHub repository.

import * as gcp from "@pulumi/gcp";
import { asset } from "@pulumi/pulumi";

const bucket = new gcp.storage.Bucket("bucket");

// Google Cloud Function in Python

const bucketObjectPython = new gcp.storage.BucketObject("python-zip", {
 bucket: bucket.name,
 source: new asset.AssetArchive({
 ".": new asset.FileArchive("./pythonfunc"),
 }),
});

const functionPython = new gcp.cloudfunctions.Function("python-func", {
 sourceArchiveBucket: bucket.name,
 runtime: "python37",
 sourceArchiveObject: bucketObjectPython.name,
 entryPoint: "handler",
 triggerHttp: true,
 availableMemoryMb: 128,
});

export const pythonEndpoint = functionPython.httpsTriggerUrl;

// Google Cloud Function in Go

const bucketObjectGo = new gcp.storage.BucketObject("go-zip", {
 bucket: bucket.name,
 source: new asset.AssetArchive({
 ".": new asset.FileArchive("./gofunc"),
 }),
});

const functionGo = new gcp.cloudfunctions.Function("go-func", {
 sourceArchiveBucket: bucket.name,
 runtime: "go111",
 sourceArchiveObject: bucketObjectGo.name,
 entryPoint: "Handler",
 triggerHttp: true,
 availableMemoryMb: 128,
});

export const goEndpoint = functionGo.httpsTriggerUrl;

Kubernetes

Kubernetes is a container orchestration system for deploying, scaling, and managing your application. Applications use multiple containers that contain code and dependencies needed for the code to execute. Kubernetes runs on a cluster of nodes and containers are deployed in pods. Kubernetes manages the pods by replacing containers that fail and removing containers that don’t respond. It can also scale the number of containers as needed and load balance the network traffic. These are some of the features that Kubernetes provides:

Load balancing and traffic distribution across the cluster
Service discovery
Create and manage containers
Remove failed containers and reassign their resources to a new container
Mount storage systems such as local storage and storage on public cloud providers
Automated deployments based on different deploy methods such as canary or blue/green deployments
Automated rollbacks to last known good state
Secrets management

The following example is based on the Kubernetes Guestbook example. The difference between this implementation and the original application is that instead of using YAML to declare the infrastructure, it uses a component written in TypeScript to create the service deployment which is implemented as k8sjs.

import * as k8s from "@pulumi/kubernetes";
import * as k8stypes from "@pulumi/kubernetes/types/input";
import * as pulumi from "@pulumi/pulumi";

/**
 * ServiceDeployment is an example abstraction that uses a class to fold together the common pattern of a
 * Kubernetes Deployment and its associated Service object.
 */
export class ServiceDeployment extends pulumi.ComponentResource {
 public readonly deployment: k8s.apps.v1.Deployment;
 public readonly service: k8s.core.v1.Service;
 public readonly ipAddress?: pulumi.Output<string>;

 constructor(name: string, args: ServiceDeploymentArgs, opts?: pulumi.ComponentResourceOptions) {
 super("k8sjs:service:ServiceDeployment", name, {}, opts);

 const labels = { app: name };
 const container: k8stypes.core.v1.Container = {
 name,
 image: args.image,
 resources: args.resources || { requests: { cpu: "100m", memory: "100Mi" } },
 env: [{ name: "GET_HOSTS_FROM", value: "dns" }],
 ports: args.ports && args.ports.map(p => ({ containerPort: p })),
 };
 this.deployment = new k8s.apps.v1.Deployment(name, {
 spec: {
 selector: { matchLabels: labels },
 replicas: args.replicas || 1,
 template: {
 metadata: { labels: labels },
 spec: { containers: [ container ] },
 },
 },
 }, { parent: this });

 this.service = new k8s.core.v1.Service(name, {
 metadata: {
 labels: this.deployment.metadata.labels,
 },
 spec: {
 ports: args.ports && args.ports.map(p => ({ port: p, targetPort: p })),
 selector: this.deployment.spec.template.metadata.labels,
 // Minikube does not implement services of type `LoadBalancer`; require the user to specify if we're
 // running on minikube, and if so, create only services of type ClusterIP.
 type: args.allocateIpAddress ? (args.isMinikube ? "ClusterIP" : "LoadBalancer") : undefined,
 },
 }, { parent: this });

 if (args.allocateIpAddress) {
 this.ipAddress = args.isMinikube ?
 this.service.spec.apply(spec => spec.clusterIP) :
 this.service.status.apply(status => status.loadBalancer.ingress[0].ip);
 }
 }
}

export interface ServiceDeploymentArgs {
 image: string;
 resources?: k8stypes.core.v1.ResourceRequirements;
 replicas?: number;
 ports?: number[];
 allocateIpAddress?: boolean;
 isMinikube?: boolean;
}

The main program deploys an instance of Redis and the guestbook application using containers pulled from the Google Container Registry.

import * as pulumi from "@pulumi/pulumi";
import * as k8sjs from "./k8sjs";

const config = new pulumi.Config();

const redisMaster = new k8sjs.ServiceDeployment("redis-master", {
 image: "k8s.gcr.io/redis:e2e",
 ports: [6379],
});

const redisReplica = new k8sjs.ServiceDeployment("redis-replica", {
 image: "gcr.io/google_samples/gb-redisslave:v1",
 ports: [6379],
});

const frontend = new k8sjs.ServiceDeployment("frontend", {
 replicas: 3,
 image: "gcr.io/google-samples/gb-frontend:v4",
 ports: [80],
 allocateIpAddress: true,
 isMinikube: config.getBoolean("isMinikube"),
});

export const frontendIp = frontend.ipAddress;

The original example defines the Service and Deployment in YAML. In the example above, the YAML is abstracted in a reusable component written in a modern programming language. The complete example is available on GitHub. As you can see, the ability to reuse components gets us closer to implementing architecture as code.

Microservices

Microservices are based on the idea that components encapsulate a business capability. Services are independently deployable and communicate via web service requests, which has the advantage of redeploying only one or selected services and leaving the remaining components up and running. The 12-Factor app is the canonical pattern for microservices, which is summarized by:

Use declarative methods to configure and deploy applications.
Enforce maximum portability between environments by establishing a clean contract with the underlying operating system.
Deploy on modern cloud platforms that diminish the need for servers and the requisite system administration.
Establish continuous deployment by keeping development, testing, and production stages similar.
Use platforms with the ability to scale without significant changes to architecture, development, or tooling.

In addition to Kubernetes, there are other platforms for deploying container-based applications. AWS Elastic Container Service, Google Cloud Run, and Azure Container Service provide alternatives to Kubernetes for container orchestration. The following code snippet demonstrates deploying a container with a Ruby application in Google Cloud Run. Note that the image is built using a local Docker engine and pushed to the Google Cloud Repository. The code shows that you can also set memory limits and concurrency for the container. The full example is available on GitHub.

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

// Location to deploy Cloud Run services
const location = gcp.config.region || "us-central1";

// -------------------------------------- //
// Deploy a custom container to Cloud Run //
// -------------------------------------- //

// Build a Docker image from our sample Ruby app and put it to Google Container Registry.
// Note: Run `gcloud auth configure-docker` in your command line to configure auth to GCR.
const imageName = "ruby-app";
const myImage = new docker.Image(imageName, {
 imageName: pulumi.interpolate`gcr.io/${gcp.config.project}/${imageName}:v1.0.0`,
 build: {
 context: "./app",
 },
});

// Deploy to Cloud Run. Some extra parameters like concurrency and memory are set for illustration purpose.
const rubyService = new gcp.cloudrun.Service("ruby", {
 location,
 template: {
 spec: {
 containers: [{
 image: myImage.imageName,
 resources: {
 limits: {
 memory: "1Gi",
 },
 },
 }],
 containerConcurrency: 50,
 },
 },
});

// Open the service to public unrestricted access
const iamRuby = new gcp.cloudrun.IamMember("ruby-everyone", {
 service: rubyService.name,
 location,
 role: "roles/run.invoker",
 member: "allUsers",
});

// Export the URL
export const rubyUrl = rubyService.status.url;

Conclusion

We’ve covered the major infrastructure architectural patterns use for deploying modern applications. Whether you use Virtual Machines, Serverless, Kubernetes or Microservices with containers the goal is to create reusable components that abstract the configuration details and enable plug-and-play architecture. In subsequent articles, we’ll take an in-depth look at each pattern and how to implement them on major providers using modern languages.

Managing AWS Credentials on CI/CD: Part 1

Chris Smith — Thu, 12 Mar 2020 00:00:00 +0000

Continuous delivery requires providing highly sensitive credentials to your deployment pipeline. Understanding the risks, mitigations, and best practices for handling those credentials can be difficult. In this guide, we describe the best practices for providing AWS credentials to a CI/CD system and to securely automate updating your cloud infrastructure using Pulumi.

You’ve heard about Infrastructure as Code and decided to try your hand at using Pulumi to manage cloud infrastructure using familiar programming languages. Naturally, you’re curious and eager to start updating your cloud infrastructure in your CI/CD pipeline – but then panic hits… Is updating your cloud infrastructure secure? If you start doing cloud deployments in your CI/CD system, doesn’t that mean you need to give it your production credentials? Aren’t those the most sensitive things your company has?!?

Take a deep breath. It’s going to be OK. You can securely provide AWS credentials to your CI/CD system and practice continuous delivery. This is the first post in a series going in-depth on how to do just that.

The goal of this article series is to give you a clear understanding of AWS credential management and how that relates to using Pulumi within a CI/CD environment. Once you have the AWS credentials in-place, you can then follow our Continuous Delivery guide for configuring your specific CI/CD service, whether you want to use CircleCI, GitLab CI, or Travis CI.

NOTE: These recommendations do not apply if you are running your own CI/CD system within your AWS account, e.g., running a Jenkins server on EC2 or using AWS CodeDeploy. In those cases, please refer to AWS’s documentation for how to assume IAM Roles when running on an EC2 instance instead.

Overview

The recommendations in this series describe a general “one-size fits most” approach for credential management, which requires a minimal amount of work to configure and maintain. Depending on your specific environment, needs, and constraints, there may be a better alternative for your use case.

Create a dedicated IAM User for your CI/CD

The first step for securely automating CI/CD is to create a dedicated IAM User for use in your CI/CD pipelines. (Sometimes referred to as a “robot account.”)

The following code snippet shows how to create a new AWS IAM User using Pulumi. (The code is in TypeScript, but you could another language like Python, C#, or Go as well.)

const user = new aws.iam.User("cicdUser", {
 name: "cicd-bot",
 tags: {
 "purpose": "Account used to perform Pulumi stack updates on CI/CD.",
 }
});

By default, that IAM User doesn’t have permissions to do anything. The recommended best practice is to use groups to assign permissions to IAM Users. So next, we will create a “Pulumi Stack updaters” IAM Group, and add our robot account as a member.

const group = new aws.iam.Group("pulumiStackUpdaters", {
 name: "PulumiStackUpdaters",
});

const groupMembership = new aws.iam.GroupMembership("cicdUserMembership", {
 group: group.name,
 users: [ user.name ],
});

Group Permissions

The next part is where things start to get tricky. We now need to grant permissions to this IAM Group’s members so they can access various APIs and resources. (For example, if your Pulumi program will need to create or update EC2 instances, then you will need to provide AWS credentials that contain the ec2:StopInstances or ec2:StartInstances action.)

But rather than grant the newly created cicd-bot IAM User those permissions, we will instead only grant them access to the sts:AssumeRole action. This is an AWS API that allows an IAM User to gain temporary credentials that have a different set of permissions associated with them. (That is, the permissions associated with an IAM Role.)

We’ll go into more detail about the exact difference between an IAM User and an IAM Role in the next post in the series since it isn’t entirely obvious why one would be more secure than the other.

const currentAwsIdentity = aws.getCallerIdentity();

const groupPolicy = new aws.iam.GroupPolicy("pulumiStackUpdatersPolicy", {
 group: group.name,
 policy: {
 Version: "2012-10-17",
 Statement: [{
 Action: [
 // Allow anybody (i.e., members of the group) to call the sts:AssumeRole API.
 // This allows them to "assume the role" of a more permissive IAM Role
 // when they go to update a stack later.
 "sts:AssumeRole",
 ],
 Effect: "Allow",
 // This is the set of resources that the "sts:AssumeRole" operation could be
 // performed on, which is to say any IAM role in the current AWS account.
 Resource: pulumi.interpolate `arn:aws:iam::${currentAwsIdentity.accountId}:role/*`,
 Sid: ""
 }],
 },
});

That’s it for the first post in our series. We’ve taken the first step and created an IAM User specifically for performing updates to AWS resources using Pulumi.

In the next post, we will review over the security concerns when passing AWS credentials to your CI/CD provider, as well as show a Pulumi program that you can use to rotate the AWS credentials for a user automatically.