Pulumi Blog: Architecture as Code Series

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.

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.