Pulumi Blog: Kat Cosgrove

Serverless Arch Templates

Kat Cosgrove — Mon, 07 Nov 2022 00:00:00 +0000

Whether you’re building a new application or moving an existing application over from another provider, the basic framework of your infrastructure probably isn’t something you want to worry about if you don’t have to. The cloud is complicated enough as it is. With Architecture Templates, Pulumi takes on some of the work involved in deploying your application to the cloud provider of your choice. Let’s take a tour of the new Serverless Templates for AWS, GCP, and Azure!

Serverless on any Cloud, in any Language

If you need a serverless application, whether that’s AWS Lambda, Google Cloud Functions, or Azure Functions, one of these templates can give you the starting point you need in any language Pulumi supports. Each template deploys a serverless function for you, with all necessary permissions to make it publicly available. While each of them does deploy a small sample function, these are designed to be extensible; we give you all the necessary tools to begin building your own application, without having to fuss around standing up the infrastructure yourself.

Generating the necessary starter code happens with a single CLI command, regardless of which cloud and language you choose:

AWS

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-aws-typescript

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-aws-python

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-aws-go

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-aws-csharp

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-aws-yaml

GCP

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-gcp-typescript

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-gcp-python

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-gcp-go

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-gcp-csharp

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-gcp-yaml

Azure

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-azure-typescript

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-azure-python

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-azure-go

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-azure-csharp

$ mkdir my-serverless-app && cd my-serverless-app
$ pulumi new serverless-azure-yaml

Pulumi to the Cloud

Each of these commands will generate some boilerplate for you, and includes defaults you can accept or modify (such as the name of the project, or the application directory). Run pulumi up from this directory, ensuring that you’ve connected the Pulumi CLI to your preferred cloud provider, and your starting point is online, ready for you to sub in your own application code. For the purposes of this demonstration, I’ve accepted the defaults. I’ve also left the provided application and function code in place. Let’s examine what Pulumi creates for us here, using Python for AWS, Go for GCP, and Typescript for Azure.

import json
import pulumi
import pulumi_aws as aws
import pulumi_aws_apigateway as apigateway

# An execution role to use for the Lambda function
role = aws.iam.Role("role",
 assume_role_policy=json.dumps({
 "Version": "2012-10-17",
 "Statement": [{
 "Action": "sts:AssumeRole",
 "Effect": "Allow",
 "Principal": {
 "Service": "lambda.amazonaws.com",
 },
 }],
 }),
 managed_policy_arns=[aws.iam.ManagedPolicy.AWS_LAMBDA_BASIC_EXECUTION_ROLE])

# A Lambda function to invoke
fn = aws.lambda_.Function("fn",
 runtime="python3.9",
 handler="handler.handler",
 role=role.arn,
 code=pulumi.FileArchive("./function"))

# A REST API to route requests to HTML content and the Lambda function
api = apigateway.RestAPI("api",
 routes=[
 apigateway.RouteArgs(path="/", local_path="www"),
 apigateway.RouteArgs(path="/date", method=apigateway.Method.GET, event_handler=fn)
 ])

# The URL at which the REST API will be served.
pulumi.export("url", api.url)

Here Pulumi has provided an IAM execution role to use for the Lambda function, the Lambda function itself, and a REST API gateway to handle request routing. The Lambda function is pointed at an included ./function directory, which contains a Python function that returns the latest datetime. This can be replaced with your own code, or you can change the directory the Pulumi code is pointed at to your own. Similarly, the API gateway is pointed at a www directory containing a simple website to display the current datetime, ready to be replaced with your own content.

package main

import (
 "fmt"

 "github.com/pulumi/pulumi-gcp/sdk/v6/go/gcp/cloudfunctions"
 "github.com/pulumi/pulumi-gcp/sdk/v6/go/gcp/storage"
 synced "github.com/pulumi/pulumi-synced-folder/sdk/go/synced-folder"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi/config"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {

 // Import the program's configuration settings.
 cfg := config.New(ctx, "")
 sitePath := "./www"
 if param := cfg.Get("sitePath"); param != "" {
 sitePath = param
 }
 appPath := "./app"
 if param := cfg.Get("appPath"); param != "" {
 appPath = param
 }
 indexDocument := "index.html"
 if param := cfg.Get("indexDocument"); param != "" {
 indexDocument = param
 }
 errorDocument := "error.html"
 if param := cfg.Get("errorDocument"); param != "" {
 errorDocument = param
 }

 // Create a storage bucket and configure it as a website.
 siteBucket, err := storage.NewBucket(ctx, "site-bucket", &storage.BucketArgs{
 Location: pulumi.String("US"),
 Website: &storage.BucketWebsiteArgs{
 MainPageSuffix: pulumi.String(indexDocument),
 NotFoundPage: pulumi.String(errorDocument),
 },
 })
 if err != nil {
 return err
 }

 // Create an IAM binding to allow public read access to the bucket.
 _, err = storage.NewBucketIAMBinding(ctx, "site-bucket-iam-binding", &storage.BucketIAMBindingArgs{
 Bucket: siteBucket.Name,
 Role: pulumi.String("roles/storage.objectViewer"),
 Members: pulumi.StringArray{
 pulumi.String("allUsers"),
 },
 })
 if err != nil {
 return err
 }

 // Use a synced folder to manage the files of the website.
 _, err = synced.NewGoogleCloudFolder(ctx, "synced-folder", &synced.GoogleCloudFolderArgs{
 Path: pulumi.String(sitePath),
 BucketName: siteBucket.Name,
 })
 if err != nil {
 return err
 }

 // Create another storage bucket for the serverless app.
 appBucket, err := storage.NewBucket(ctx, "app-bucket", &storage.BucketArgs{
 Location: pulumi.String("US"),
 })
 if err != nil {
 return err
 }

 // Upload the serverless app to the storage bucket.
 appArchive, err := storage.NewBucketObject(ctx, "app-archive", &storage.BucketObjectArgs{
 Bucket: appBucket.Name,
 Source: pulumi.NewFileArchive(appPath),
 })
 if err != nil {
 return err
 }

 // Create a Cloud Function that returns some data.
 dataFunction, err := cloudfunctions.NewFunction(ctx, "data-function", &cloudfunctions.FunctionArgs{
 SourceArchiveBucket: appBucket.Name,
 SourceArchiveObject: appArchive.Name,
 Runtime: pulumi.String("go116"),
 EntryPoint: pulumi.String("Data"),
 TriggerHttp: pulumi.Bool(true),
 })
 if err != nil {
 return err
 }

 // Create an IAM member to invoke the function.
 _, err = cloudfunctions.NewFunctionIamMember(ctx, "data-function-invoker", &cloudfunctions.FunctionIamMemberArgs{
 Project: dataFunction.Project,
 Region: dataFunction.Region,
 CloudFunction: dataFunction.Name,
 Role: pulumi.String("roles/cloudfunctions.invoker"),
 Member: pulumi.String("allUsers"),
 })
 if err != nil {
 return err
 }

 // Create a JSON configuration file for the website.
 _, err = storage.NewBucketObject(ctx, "site-config", &storage.BucketObjectArgs{
 Name: pulumi.String("config.json"),
 Bucket: siteBucket.Name,
 ContentType: pulumi.String("application/json"),
 Source: dataFunction.HttpsTriggerUrl.ApplyT(func(url string) pulumi.AssetOrArchiveOutput {
 config := fmt.Sprintf(`{ "api": "%s" }`, url)
 return pulumi.NewStringAsset(config).ToAssetOrArchiveOutput()
 }).(pulumi.AssetOrArchiveOutput),
 })
 if err != nil {
 return err
 }

 // Export the URLs of the website and serverless endpoint.
 ctx.Export("siteURL", pulumi.Sprintf("https://storage.googleapis.com/%s/index.html", siteBucket.Name))
 ctx.Export("apiURL", dataFunction.HttpsTriggerUrl)

 return nil
 })
}

Here Pulumi is defining your application’s initial configuration values, including the directories it should be checking for your serverless application code and the index and error pages for the website it stands up. It then creates two storage buckets, each with appropriate IAM roles for access, one containing your serverless function and another configured to act like a website. We also have the Cloud Function declaration itself, and all configurations necessary for it, followed by exporting the URL for you.

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

// Import the program's configuration settings.
const config = new pulumi.Config();
const sitePath = config.get("sitePath") || "./www";
const appPath = config.get("appPath") || "./app";
const indexDocument = config.get("indexDocument") || "index.html";
const errorDocument = config.get("errorDocument") || "error.html";

// Create a resource group for the website.
const resourceGroup = new azure.resources.ResourceGroup("resource-group", {});

// Create a blob storage account.
const account = new azure.storage.StorageAccount("account", {
 resourceGroupName: resourceGroup.name,
 kind: azure.storage.Kind.StorageV2,
 sku: {
 name: azure.storage.SkuName.Standard_LRS,
 },
});

// Create a storage container for the pages of the website.
const website = new azure.storage.StorageAccountStaticWebsite("website", {
 accountName: account.name,
 resourceGroupName: resourceGroup.name,
 indexDocument: indexDocument,
 error404Document: errorDocument,
});

// Use a synced folder to manage the files of the website.
const syncedFolder = new synced.AzureBlobFolder("synced-folder", {
 path: sitePath,
 resourceGroupName: resourceGroup.name,
 storageAccountName: account.name,
 containerName: website.containerName,
});

// Create a storage container for the serverless app.
const appContainer = new azure.storage.BlobContainer("app-container", {
 accountName: account.name,
 resourceGroupName: resourceGroup.name,
 publicAccess: azure.storage.PublicAccess.None,
});

// Upload the serverless app to the storage container.
const appBlob = new azure.storage.Blob("app-blob", {
 accountName: account.name,
 resourceGroupName: resourceGroup.name,
 containerName: appContainer.name,
 source: new pulumi.asset.FileArchive(appPath),
});

// Create a shared access signature to give the Function App access to the code.
const signature = azure.storage.listStorageAccountServiceSASOutput({
 resourceGroupName: resourceGroup.name,
 accountName: account.name,
 protocols: azure.storage.HttpProtocol.Https,
 sharedAccessStartTime: "2022-01-01",
 sharedAccessExpiryTime: "2030-01-01",
 resource: azure.storage.SignedResource.C,
 permissions: azure.storage.Permissions.R,
 contentType: "application/json",
 cacheControl: "max-age=5",
 contentDisposition: "inline",
 contentEncoding: "deflate",
 canonicalizedResource: pulumi.interpolate`/blob/${account.name}/${appContainer.name}`,
});

// Create an App Service plan for the Function App.
const plan = new azure.web.AppServicePlan("plan", {
 resourceGroupName: resourceGroup.name,
 sku: {
 name: "Y1",
 tier: "Dynamic",
 },
});

// Create the Function App.
const functionApp = new azure.web.WebApp("function-app", {
 resourceGroupName: resourceGroup.name,
 serverFarmId: plan.id,
 kind: "FunctionApp",
 siteConfig: {
 appSettings: [
 {
 name: "FUNCTIONS_WORKER_RUNTIME",
 value: "node",
 },
 {
 name: "WEBSITE_NODE_DEFAULT_VERSION",
 value: "~14",
 },
 {
 name: "FUNCTIONS_EXTENSION_VERSION",
 value: "~3",
 },
 {
 name: "WEBSITE_RUN_FROM_PACKAGE",
 value: pulumi.all([account.name, appContainer.name, appBlob.name, signature])
 .apply(([accountName, containerName, blobName, signature]) => `https://${accountName}.blob.core.windows.net/${containerName}/${blobName}?${signature.serviceSasToken}`),
 },
 ],
 cors: {
 allowedOrigins: [
 "*"
 ],
 },
 },
});

// Create a JSON configuration file for the website.
const configFile = new azure.storage.Blob("config.json", {
 source: functionApp.defaultHostName
 .apply(host => new pulumi.asset.StringAsset(JSON.stringify({ api: `https://${host}/api` }))),
 contentType: "application/json",
 accountName: account.name,
 resourceGroupName: resourceGroup.name,
 containerName: website.containerName,
});

// Export the URLs of the website and serverless endpoint.
export const siteURL = account.primaryEndpoints.apply(primaryEndpoints => primaryEndpoints.web);
export const apiURL = pulumi.interpolate`https://${functionApp.defaultHostName}/api`;

Here, Pulumi first defines the configuration options for your project, including the directories to look at for your application code and your website, as well as what the index and error documents should be. It then goes on to set up your blob storage account and containers for your website and serverless function, before uploading the serverless function itself with all permissions and configurations necessary to operate.

Extending Templates

In addition to the Pulumi code above, each template includes a simple website that utilizes a provided serverless function to display the current time and date, constantly updating. With only two CLI commands, you have deployed the core infrastructure necessary to get your serverless application online in the cloud, without writing a single line of code yourself.

From here, you’re ready to drop in your own application code. Pulumi has already handled the boring work for you, complying with best practices from the beginning so you only have to worry about building your own application, not how to get the infrastructure online!

Pulumi Architecture Templates exist for a variety of applications and common use-cases, including containerized applications and kubernetes, with more being added over time. Keep an eye out for new additions and ways to make engineering for the cloud less painful!

Announcing KubeCrash Fall 2022 — the KubeCon Detroit Warm-up

Kat Cosgrove — Fri, 23 Sep 2022 10:19:23 -0500

100% Virtual. 100% Free. 100% Open Source. Arrive in style and up to date on the biggest trends for KubeCon + CloudNativeCon North America this October in Detroit, Michigan! KubeCrash is a fully-virtual two-day event curated by the coolest companies in cloud native, providing you with a practical, hands-on learning opportunity in the run-up to the conference. All for free! Held October 5 and 6 in both Americas and European time zones, you’ll emerge with new development skills and conversation starters for KubeCon. Take a peek at the program and register online!

The Importance of Open Source

Your DevOps team drives the technology and tooling choices that build production. The benefits of open source mean that even in enterprise-grade environments, they increasingly choose an open-source tool over a closed-source option. Large communities of maintainers and other users, great documentation, and personalized support make open source an extremely appealing choice.

This means that open source software has become the backbone of any modern tech stack. That rapidly-increasing reliance on open source means that any development team needs the skills to understand and effectively utilize these tools to remain on top. The KubeCrash event is tailor-made for this, with sessions and hands-on workshops for SREs, developers, platform engineers, and security engineers hosted by the maintainers of some of the most popular open source tools in the cloud native landscape.

About KubeCrash

Our inaugural KubeCrash event, held alongside KubeCon + CloudNativeCon Europe, was a resounding success. This year, we’re making it even better with feedback from all of you! KubeCrash Fall will be held before KubeCon, with two half-day events held in different timezones to accommodate everyone. You’ll be able to interact with speakers and other participants live, no matter where you are! One event will be held from 3pm to 6pm Central European Time, and the next will be held from 9am to 12pm US Pacific Time. KubeCrash is a collaborative effort by seven different open source companies in the cloud native space, all of us coming together to bring you high-quality crash courses on cloud native technologies before KubeCon. We aren’t here to sell you anything or make you sit through pitches; you’ll get content on Pulumi, and also other cool open source projects like Goldilocks, cert-manager, Linkerd, CockroachDB, and Polaris. Check out our last event for an idea of what you’ll see!

The KubeCrash Program

Show up ready to learn straight from the people who build and maintain the most popular and critical tooling in the ecosystem. From keynotes by Cheryl Hung to overviews of CNCF projects by their maintainers, to hands-on workshops and an end-user case study, there’s something for you no matter where you are in your cloud native journey.

Day 1: Wednesday, October 5 (European and East Americas-friendly timezone)

3 to 6 pm CET | 9 am to 12 pm EST | 8 to 11 am CST

Keynote: to be announced

Lighting talk: Intro to the CNCF Cloud Native Maturity Model by Danielle Cook, Co-chair CNCF Cartografos Group

Whose cert is it anyway? How to build TLS trust using cert-manager by Ashley Davis, cert-manager team

Going Straight to the Edge by Dinesh Majrekar and Mark Boost, founders of Civo Emissary-ingress session

Hands-on workshop: Service mesh observability with Linkerd by Flynn, Linkerd team and Emissary-ingress maintainer

Day 2: Thursday, October 6 (Americas-friendly timezone)

12 to 3 pm EST | 11 am to 2 pm CST | 9 am to 12 pm PST

Keynote: TBS by Cheryl Hung, Engineering Manager, Apple

Lighting talk: The CNCF Cloud Native Glossary: Trusted. Simple. Community-driven by Catherine Paganini, Cloud Native Glossary Maintainer

Getting Started with Kubernetes Guardrails with Polaris by Andy Suderman Creator and Maintainer of Goldilocks and Stevie Caldwell, Creator of GoNoGo

Hands-on Workshop with Aaron Friel of Pulumi: Program the Cloud with Six Pearls in Six Languages using Pulumi

Check out the program page for more details.

Join us on October 5 and 6

Join us on October 5 and 6 for a specifically curated set of sessions, each led by a project maintainer, from projects covering modern cloud native security to improving the developer experience. It will be live, interactive, and fun. Register today!

Introducing KubeCrash: Cloud Native Crash Courses

Kat Cosgrove — Fri, 08 Apr 2022 00:00:00 +0000

Can’t make it to Valencia for KubeCon this year? Timezone doesn’t work for the virtual conference either? We can’t fix time, but if you’re feeling left out and still want some of that sweet cloud native content, you can still join us for KubeCrash, a new event hosting live crash courses and sessions on cloud native tech. Come hang out and learn directly from the maintainers of cloud native open source projects!

About KubeCrash

Five open source companies have teamed up to bring you top-notch, KubeCon-grade crash courses on cloud native tech. No vendor pitches, just awesome open source content on projects such as Linkerd, cert-manager, CockroachDB, Pulumi, Polaris, and Goldilocks.

With Kubernetes becoming the new standard for cloud-hosted application development, DevOps teams are driving the technology choices for enterprise-grade cloud native tooling. Freely available open source solutions are often the primary source for these tooling decisions.

KubeCrash provides a half-day knowledge sharing and virtual learning environment for developers, reliability engineers, cloud security specialists, and platform engineers. Learn directly from the maintainers of some of the most popular open source projects in this series of focused talks and workshops.

The KubeCrash program

Come prepared for a schedule packed with great content and actionable insights directly from the teams that maintain some of the ecosystem’s most popular open source projects. The program will cover the latest learnings on implementing scalable zero-trust, scanning workloads for improved cloud native security, using service mesh to ensure high availability across multi-cluster infrastructure, and delivering “serverless” for multi-cloud deployments.

Program overview

Using cert-manager to enable zero-trust identities for intra-pod communication — Jake Sanders, cert-manager maintainer

Modern cloud native architectures require the network to be considered untrustworthy and this is why internal workloads are rapidly driving the use of mTLS and private PKI. This workshop from Jetstack will demonstrate how to use cert-manager to issue, manage and rotate mTLS certs, allowing users to have strongly attested and verified Machine Identities between Kubernetes pods. All without the workload private keys leaving node memory! Think of this session as a precursor to implementing a service mesh solution, using cert-manager to establish zero trust environments, perhaps defined by trust domains, and enforce security for pod to pod traffic.

Multi-cluster failover using Linkerd — Eliza Weisman, Linkerd maintainer

Failover across clusters is a great way to improve the overall uptime and reliability of Kubernetes applications. While whole-cluster failover can be accomplished at the global ingress layer, failing over individual services is a little more difficult. During this session, Linkerd maintainer Eliza Weisman will walk you through how to use Linkerd, the CNCF graduated service mesh, to enable traffic failover for individual services across clusters. Attendees will learn how to combine service mesh metrics, traffic shifting, and cross-cluster communication in a cohesive and automated way using pure open source, while preserving fundamental security guarantees such as mutual TLS.

Optimizing and Securing Kubernetes Workloads with Polaris and Goldilocks — Rachel Sweeney, Fairwinds and Andy Suderman, Polaris and Goldilocks maintainer

Learn how to scan your Kubernetes workloads to improve your resource utilization and security using open source tools Polaris and Goldilocks. You will watch Andy Suderman, Director of R&D and Technology, and Rachel Sweeney, SRE at Fairwinds, as they show how to correctly configure your clusters based on Kubernetes’ best practices for security and efficiency.

Using Kubernetes to deliver a “serverless” service — Lisa-Marie Namphy and Jim Walker, Cockroach Labs

In this talk, Cockroach Labs team members will share how they leverage Kubernetes to deliver a “serverless” experience. Serverless promises to change the way we consume software. It allows us to potentially pay for what we use only and help drive down operational costs by minimizing resource consumption. Architecting for serverless requires a unique look at app logic and how it is deployed—a combination of the logical and physical worlds. An architectural pattern has emerged where we can scale ephemeral compute separate from services that need to persist.

Multi-cloud, single deploy: cloud engineering with Kubernetes and Pulumi — Aaron Friel and Guinevere Saenger, Pulumi

Business constraints and customer requests often require to stand up new Kubernetes environments across multiple cloud providers. This growing complexity in computing infrastructure will incur greater operational costs for organizations when coordinating across multiple teams. Pulumi engineers Aaron Friel and Guinevere Saenger will demonstrate standing up Kubernetes clusters, deploying applications, and automating ops tasks by building a CLI using the Pulumi Automation API. These tools empower every engineer—from application developers to site reliability engineers—to be a cloud engineer.

Join us on May 17

If you’re staying in the Americas (or are up for a late-night session) this KubeCon, join us on Tuesday, May 17th starting at 9 am PST/10 am CST/12 pm EST. Enjoy a specifically curated set of sessions, each led by a project maintainer from projects covering modern cloud native security to improving the developer experience. Register today!

Deploying Lambda Function URLs

Kat Cosgrove — Wed, 06 Apr 2022 13:00:03 -0700

Since its introduction in 2014, the AWS Lambda service has steadily grown from ‘functions as a service’ to a powerful serverless platform that enables cloud engineers to run code without provisioning or managing underlying infrastructure.

In the past 18 months, the platform has expanded to include support for persistent storage using Amazon Elastic File System (EFS) as well as container-based functions. More recently, the team added support for AWS Graviton2 processors - improving the price performance of AWS Lambda functions.

Today, the AWS team announced AWS Lambda Function URLs - HTTPS endpoint support for your Lambda functions. This means that once you’ve added and configured a function URL, you can invoke your Lambda function from a webapp, curl, Postman, or whatever HTTP client you prefer. It’s also our first feature to take full advantage of the new AWS Cloud Control API for same-day feature support.

Why Use Function URLs for AWS Lambda?

Embedding URL support into Lambda functions is a big productivity boost compared to alternative methods such as configuring Amazon API Gateway to provide an HTTPS endpoint for your Lambda functions. Here are some common use cases for configuring, monitoring, and observing your function URLs:

Easy-to-configure monitoring

Since AWS Lambda is integrated with AWS CloudTrail, you can view recent events in event history or deliver CloudTrail events to an Amazon S3 bucket. For each request to AWS Lambda authorized via IAM, you can track useful information such as the IP address and the user/role or the requestor. Aggregated metrics are also sent to Amazon CloudWatch - enabling you to track the number of requests to each URL, errors by status code (4xx and 5xx), and function latency.

Simplified throttling

You can configure reserved concurrency to prevent abuse of your function or avoid overloading down-stream resources. By setting reserved concurrency to zero, you can even disable your URL completely.

Simple access controls

By default, Lambda URLs use AWS Identity and Access Management (IAM) for authorization, but you can also disable IAM authentication - enabling your function code to handle auth however you like. Function URLs also support Cross Origin Resource Sharing configuration options.

In short, Lambda Function URLs give you an easier way to configure, deploy and manage an HTTPS endpoint for your functions than setting up a full API Gateway. If you need more advanced options such as per-client throttling, then it’s worth exploring API Gateway features for managing endpoints for your Lambda functions.

Example: Setting up an AWS Lambda Function URL

Ready to try out Function URLs for yourself? A function URL can be applied to any function alias from the AWS Console, CLI, or other Lambda API – including from your Pulumi programs! Let’s see what that looks like:

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as awsnative from "@pulumi/aws-native";
import {local} from "@pulumi/command";

const lambdaRole = new awsnative.iam.Role("lambdaRole", {
 assumeRolePolicyDocument: {
 Version: "2012-10-17",
 Statement: [
 {
 Action: "sts:AssumeRole",
 Principal: {
 Service: "lambda.amazonaws.com",
 },
 Effect: "Allow",
 Sid: "",
 },
 ],
 },
});

const lambdaRoleAttachment = new aws.iam.RolePolicyAttachment(
 "lambdaRoleAttachment",
 {
 role: pulumi.interpolate`${lambdaRole.roleName}`,
 policyArn: aws.iam.ManagedPolicy.AWSLambdaBasicExecutionRole,
 }
);

const helloFunction = new awsnative.lambda.Function("helloFunction", {
 role: lambdaRole.arn,
 runtime: "nodejs14.x",
 handler: "index.handler",
 code: {
 zipFile: `exports.handler = function(event, context, callback){ callback(null, {"response": "Hello "}); };`,
 },
});

const lambdaUrl = new awsnative.lambda.Url("test", {
 targetFunctionArn: helloFunction.arn,
 authType: awsnative.lambda.UrlAuthType.None,
});

const awsCommand = new local.Command("aws-command", {
 create: pulumi.interpolate`aws lambda add-permission --function-name ${helloFunction.functionName} --action lambda:InvokeFunctionUrl --principal '*' --function-url-auth-type NONE --statement-id FunctionURLAllowPublicAccess`
}, {deleteBeforeReplace: true, dependsOn: [helloFunction]})

export const url = lambdaUrl.functionUrl;

import json
import pulumi
import pulumi_aws as aws
import pulumi_aws_native as aws_native
from pulumi_command import local

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

lambda_role_attachment = aws.iam.RolePolicyAttachment("lambda_role_attachment",
 role=pulumi.Output.concat(
 lambda_role.role_name),
 policy_arn="arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole",
 )

hello_function = aws_native.lambda_.Function("test",
 runtime="nodejs14.x",
 role=lambda_role.arn,
 handler="index.handler",
 code=aws_native.lambda_.FunctionCodeArgs(
 zip_file="exports.handler = function(event, context, callback){ callback(null, {'response': 'Hello'}); };",
 ),
 )

lambda_url = aws_native.lambda_.Url("test",
 target_function_arn=hello_function.arn,
 auth_type=aws_native.lambda_.UrlAuthType.NONE
 )

add_permissions = local.Command("add_permissions",
 create=pulumi.Output.concat("aws lambda add-permission --function-name ",hello_function.function_name, " --action lambda:InvokeFunctionUrl --principal '*' --function-url-auth-type NONE --statement-id FunctionURLAllowPublicAccess"),
 opts=pulumi.ResourceOptions(delete_before_replace=True)
)

pulumi.export("url", lambda_url.function_url)

using System.Collections.Generic;
using System.Text.Json;
using Pulumi;
using Aws = Pulumi.Aws;
using AwsNative = Pulumi.AwsNative;
using Local = Pulumi.Command.Local;

class MyStack : Stack
{
 public MyStack()
 {
 var lambdaRole = new AwsNative.IAM.Role("lambdaRole", new AwsNative.IAM.RoleArgs
 {
 AssumeRolePolicyDocument = JsonSerializer.Serialize(new Dictionary<string, object?>
 {
 { "Version", "2012-10-17" },
 { "Statement", new[]
 {
 new Dictionary<string, object?>
 {
 { "Action", "sts:AssumeRole" },
 { "Effect", "Allow" },
 { "Sid", "" },
 { "Principal", new Dictionary<string, object?>
 {
 { "Service", "lambda.amazonaws.com" },
 } },
 },
 }
 },
 }),
 });

 var lambdaRoleAttachment = new Aws.Iam.RolePolicyAttachment("lambdaRoleAttachment", new Aws.Iam.RolePolicyAttachmentArgs
 {
 Role = Pulumi.Output.Format($"{lambdaRole.RoleName}"),
 PolicyArn = Aws.Iam.ManagedPolicy.AWSLambdaBasicExecutionRole.ToString()
 });

 var helloFunction = new AwsNative.Lambda.Function("hellofunction", new AwsNative.Lambda.FunctionArgs
 {
 Role = lambdaRole.Arn,
 Runtime = "nodejs14.x",
 Handler = "index.handler",
 Code = new AwsNative.Lambda.Inputs.FunctionCodeArgs
 {
 ZipFile = "exports.handler = function(event, context, callback){ callback(null, {\"response\": \"Hello \"}); };"
 }
 });

 var lambdaUrl = new AwsNative.Lambda.Url("test", new AwsNative.Lambda.UrlArgs
 {
 TargetFunctionArn = helloFunction.Arn,
 AuthType = AwsNative.Lambda.UrlAuthType.None
 });

 var localCommand = new Local.Command("addPermissions", new Local.CommandArgs
 {
 Create = Output.Format($"aws lambda add-permission --function-name {helloFunction.FunctionName} --action lambda:InvokeFunctionUrl --principal '*' --function-url-auth-type NONE --statement-id FunctionURLAllowPublicAccess")
 }, new CustomResourceOptions {
 DeleteBeforeReplace = true,
 DependsOn = new InputList<Resource> {
 helloFunction
 }
 });

 this.Url = lambdaUrl.FunctionUrl;
 }

 [Output]
 public Output<string> Url { get; set; }
}

package main

import (
 "encoding/json"

 "github.com/pulumi/pulumi-aws-native/sdk/go/aws/iam"
 "github.com/pulumi/pulumi-aws-native/sdk/go/aws/lambda"
 awsiam "github.com/pulumi/pulumi-aws/sdk/v5/go/aws/iam"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {

 lambdaAssumeRolePolicy, err := json.Marshal(map[string]interface{}{
 "Version": "2012-10-17",
 "Statement": []map[string]interface{}{
 map[string]interface{}{
 "Action": "sts:AssumeRole",
 "Effect": "Allow",
 "Sid": "",
 "Principal": map[string]interface{}{
 "Service": "lambda.amazonaws.com",
 },
 },
 }})
 if err != nil {
 return err
 }

 lambdaRole, err := iam.NewRole(ctx, "lambdaRole", &iam.RoleArgs{
 AssumeRolePolicyDocument: pulumi.String(lambdaAssumeRolePolicy),
 })
 if err != nil {
 return err
 }

 _, err = awsiam.NewRolePolicyAttachment(ctx, "lambdaRoleAttachment", &awsiam.RolePolicyAttachmentArgs{
 Role: lambdaRole.RoleName,
 PolicyArn: awsiam.ManagedPolicyAWSLambdaBasicExecutionRole,
 })
 if err != nil {
 return err
 }

 helloFunction, err := lambda.NewFunction(ctx, "helloFunction", &lambda.FunctionArgs{
 Role: lambdaRole.Arn,
 Runtime: pulumi.String("nodejs14.x"),
 Handler: pulumi.String("index.handler"),
 Code: &lambda.FunctionCodeArgs{
 ZipFile: pulumi.String("exports.handler = function(event, context, callback){ callback(null, {\"response\": \"Hello \"}); };"),
 },
 })
 if err != nil {
 return err
 }

 url, err := lambda.NewUrl(ctx, "test", &lambda.UrlArgs{
 TargetFunctionArn: helloFunction.Arn,
 AuthType: lambda.UrlAuthTypeNone,
 })

 // Export the name of the bucket
 ctx.Export("url", url.FunctionUrl)
 return nil
 })
}

In the above code, we’re doing a couple of things:

Creating a role for the Lambda function to use and assigning an AWS managed policy to it
Creating a Lambda function and configuring a function URL for it

3. Using the Pulumi Command package to run a command with the AWS CLI to add invoke permissions to the Lambda function

Using Pulumi to do this brings your infrastructure into a format much more familiar for most developers. This approach will work for any of the modern programming languages Pulumi supports.

We’ve named the Lambda function helloFunction, selected a runtime of nodeJS, and given it a tiny bit of code to run – a single function that, when called, returns “Hello.” Next, we’re giving it a function URL with no authorization and exporting the URL.

Run pulumi up and this is what we get:

 Type Name Status
+ pulumi:pulumi:Stack functions-dev
+ └─ aws-native:lambda:Url test created
Outputs:
+ url: "https://ppxrysls1a.lambda-url.eu-south-1.on.aws/"

You’ll also need to run the following command to add the required permission to allow the Lambda function to be run. If you don’t have the AWS CLI installed, there are instructions on our getting started docs:

aws lambda add-permission --function-name $(pulumi stack output functionName) --action lambda:InvokeFunctionUrl --principal '*' --function-url-auth-type NONE --statement-id FunctionURLAllowPublicAccess

Our function has a public endpoint! Hit it with curl (or just visit that URL in a browser) to make sure it works:

# curl $(pulumi stack output url)
{"response":"Hello "}

Success! A Lambda was created and a function URL was configured for it in just a few lines of code. The function URL allows us to invoke that Lambda from anywhere. Pretty neat!

Conclusion

AWS Lambda functions are an incredibly easy and powerful way to stand up serverless capabilities which is why they are easily one of the most popular resources deployed by Pulumi users today. With the addition of Lambda Function URLs, end-users no longer need to set up an Amazon API Gateway to provide an HTTPS endpoint for their functions - further simplifying deployments. You can learn more about Lambda Function URLs by reading the AWS and Pulumi documentation:

Pulumi API Documentation

Configuring URLs

Invoking URLs

Payload format

Cloud Systems: Deploying to Amazon ECS

Kat Cosgrove — Tue, 28 Dec 2021 14:52:42 +0000

Cloud engineering is taking over software development. In a lot of ways, this is great; it allows us to build and deploy more complicated applications with less difficulty, and maintaining those applications becomes less troublesome too. We can release smaller updates more quickly than ever, ensuring that we can stay on top of feature requests and security issues. That said, the rise of cloud engineering has also introduced a lot of complexity in the form of dozens of services even within just one cloud provider. Figuring out where to start can be tough, so let’s take a practical tour! In this series, I’ll walk you through building a personal website and deploying it using modern cloud engineering practices.

Elastic Container Service

In the previous tutorial, we extended our personal website to use the Flask web framework, add server-side routing, and package everything up into a Docker container. It’s still only running locally, though, and we want to deploy it. To do that, today we’ll be learning to use Pulumi to deploy to Amazon’s Elastic Container Service. If you completed part two of this series, we’ll be picking up right where we left off. If you’re just now joining me, you can get the completed code by forking and cloning this repository.

Prerequisites:

Configuring Amazon ECS

Amazon’s ECS (Elastic Container Service) is a tool used for container orchestration. It allows you to deploy containerized applications into a cluster, defined as tasks. We’re going to use Pulumi to define all of the necessary rules and settings to do this in a secure manner, then create our infrastructure and deploy the containerized website.

First, run pulumi new python -y to start a new Pulumi project if you don’t already have one for this tutorial. From now on, we’ll be working within __main__.py

import json
import base64
import pulumi
import pulumi_aws as aws
import pulumi_docker as docker

First, we have our imports. We’re working with both AWS and Docker, so we need both of those Pulumi providers. Launch the virtual environment set up for you by Pulumi with source venv/bin/activate and run pip3 install pulumi-aws pulumi-docker to get both. If you want to make sure your dependencies are saved for later, you can run pip3 freeze > requirements.txt .

app_cluster = aws.ecs.Cluster("app-cluster")

app_vpc = aws.ec2.Vpc("app-vpc",
 cidr_block="172.31.0.0/16",
 enable_dns_hostnames=True)

app_vpc_subnet = aws.ec2.Subnet("app-vpc-subnet",
 cidr_block="172.31.32.0/20",
 vpc_id=app_vpc.id)

In this codeblock, we’re first creating our ECS cluster and naming it app-cluster. Then create a VPC (Virtual Private Cloud), and a subnet for it. VPCs are like miniature local networks, with subnets providing the addressing within that mini network. Using a VPC means you can wire up your system as you like it without worrying about how that network setup might collide with other AWS resources, since you define how that network can connect outward. If you’ve ever used Docker networking, you’ll be familiar with the idea that an internal network is different than the external interface.

It is possible to use the default VPC here rather than defining one, but AWS networking is complex, so it’s worth knowing that it is possible to define a custom VPC.

app_gateway = aws.ec2.InternetGateway("app-gateway",
 vpc_id=app_vpc.id)

app_routetable = aws.ec2.RouteTable("app-routetable",
 routes=[
 aws.ec2.RouteTableRouteArgs(
 cidr_block="0.0.0.0/0",
 gateway_id=app_gateway.id,
 )
 ],
 vpc_id=app_vpc.id)

app_routetable_association = aws.ec2.MainRouteTableAssociation("app_routetable_association",
 route_table_id=app_routetable.id,
 vpc_id=app_vpc.id)

Next, we need a gateway and a route table. The gateway’s job is to provide a target in that route table we just created and associated with our VPC. This allows our VPC to communicate with the public internet.

app_security_group = aws.ec2.SecurityGroup("security-group",
 vpc_id=app_vpc.id,
 description="Enables HTTP access",
 ingress=[aws.ec2.SecurityGroupIngressArgs(
 protocol='tcp',
 from_port=80,
 to_port=80,
 cidr_blocks=['0.0.0.0/0'],
 )],
 egress=[aws.ec2.SecurityGroupEgressArgs(
 protocol='-1',
 from_port=0,
 to_port=0,
 cidr_blocks=['0.0.0.0/0'],
 )])

Just about everything you do in AWS requires a security group. The purpose of a security group is to control traffic, both inbound and outbound. This one enables HTTP access.

# Creating an IAM role used by Fargate to execute all our services
app_exec_role = aws.iam.Role("app-exec-role",
 assume_role_policy="""{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Action": "sts:AssumeRole",
 "Principal": {
 "Service": "ecs-tasks.amazonaws.com"
 },
 "Effect": "Allow",
 "Sid": ""
 }]
 }""")

# Attaching execution permissions to the exec role
exec_policy_attachment = aws.iam.RolePolicyAttachment("app-exec-policy", role=app_exec_role.name,
 policy_arn="arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy")

# Creating an IAM role used by Fargate to manage tasks
app_task_role = aws.iam.Role("app-task-role",
 assume_role_policy="""{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Action": "sts:AssumeRole",
 "Principal": {
 "Service": "ecs-tasks.amazonaws.com"
 },
 "Effect": "Allow",
 "Sid": ""
 }]
 }""")

# Attaching execution permissions to the task role
task_policy_attachment = aws.iam.RolePolicyAttachment("app-access-policy", role=app_task_role.name,
 policy_arn=aws.iam.ManagedPolicy.AMAZON_ECS_FULL_ACCESS)

We’re going to be using AWS Fargate to actually run our container. Fargate is a serverless compute platform designed for running containers without requiring you to provision and manage clusters of EC2 (Elastic Compute Cloud) instances. Since our website is containerized and very small, it’s perfect for us. Services also require IAM roles, and in this case, we need to allow Fargate to execute our services and manage our tasks, so we create new roles for both and apply execution permissions to them.

In the context of Fargate, a task is a collection of containers, and a task definition tells AWS what needs to be running all at once in order to make an application run. The task definitions will be written later onm but first we need to define policies. It’s important that these policies be created first, or the task definitions won’t create correctly later on.

# Creating storage space to upload a docker image of our app to
app_ecr_repo = aws.ecr.Repository("app-ecr-repo",
 image_tag_mutability="MUTABLE")

# Attaching an application life cycle policy to the storage
app_lifecycle_policy = aws.ecr.LifecyclePolicy("app-lifecycle-policy",
 repository=app_ecr_repo.name,
 policy="""{
 "rules": [
 {
 "rulePriority": 10,
 "description": "Remove untagged images",
 "selection": {
 "tagStatus": "untagged",
 "countType": "imageCountMoreThan",
 "countNumber": 1
 },
 "action": {
 "type": "expire"
 }
 }
 ]
 }""")

The last thing we need to do for our infrastructure before we can start deploying to it is create a repository on Amazon ECR (Elastic Container Registry) where our Docker image will live, then attach an application lifecycle policy to that repository. This makes sure that we expire and remove any untagged images in the repository, keeping things from getting clogged up.

Deploying a Dockerized Flask Application to ECS

We’re now ready to deploy our website and wire all of this up!

flask_targetgroup = aws.lb.TargetGroup("flask-targetgroup",
 port=80,
 protocol="TCP",
 target_type="ip",
 vpc_id=app_vpc.id)

flask_balancer = aws.lb.LoadBalancer("flask-balancer",
 load_balancer_type="network",
 internal=False,
 security_groups=[],
 subnets=[app_vpc_subnet.id])

flask_listener = aws.lb.Listener("flask-listener",
 load_balancer_arn=flask_balancer.arn,
 port=80,
 protocol="TCP",
 default_actions=[aws.lb.ListenerDefaultActionArgs(
 type="forward",
 target_group_arn=flask_targetgroup.arn
 )])

First, we need to make it possible for our Flask application to communicate with the internet. That requires three pieces of configuration: a target group for port 80, a load balancer to spread out incoming requests and make sure our website doesn’t get overwhelmed as easily, and a listener to forward public traffic to the defined target group. The target group is directed at the endpoint for the VPC we created earlier, defining the port as it is unknown until runtime.

def get_registry_info(rid):
 creds = aws.ecr.get_credentials(registry_id=rid)
 decoded = base64.b64decode(creds.authorization_token).decode()
 parts = decoded.split(':')
 if len(parts) != 2:
 raise Exception("Invalid credentials")
 return docker.ImageRegistry(creds.proxy_endpoint, parts[0], parts[1])

app_registry = app_ecr_repo.registry_id.apply(get_registry_info)

flask_image = docker.Image("flask-dockerimage",
 image_name=app_ecr_repo.repository_url,
 build="./website",
 skip_push=False,
 registry=app_registry
)

A small helper function is required here. It’s grabbing some of our AWS credentials, specifically an authorization token, so that we can talk to the registry. Next, we build the Docker image for our website and push it to the repository we created in Amazon ECR earlier. Remember, the Dockerfile is in ./website.

flask_task_definition = aws.ecs.TaskDefinition("flask-task-definition",
 family="frontend-task-definition-family",
 cpu="256",
 memory="512",
 network_mode="awsvpc",
 requires_compatibilities=["FARGATE"],
 execution_role_arn=app_exec_role.arn,
 task_role_arn=app_task_role.arn,
 container_definitions=pulumi.Output.all(flask_image.image_name).apply(lambda args: json.dumps([{
 "name": "flask-container",
 "image": args[0],
 "memory": 512,
 "essential": True,
 "portMappings": [{
 "containerPort": 80,
 "hostPort": 80,
 "protocol": "tcp"
 }],
 }])))

We need a task definition for the Flask instance. AWS Fargate will be managing this for us, using the roles we defined earlier. We’re also handing it a container definition, including the image name and a little bit of information about it, like the container and host ports.

flask_service = aws.ecs.Service("flask-service",
 cluster=app_cluster.arn,
 desired_count=1,
 launch_type="FARGATE",
 task_definition=flask_task_definition.arn,
 wait_for_steady_state=False,
 network_configuration=aws.ecs.ServiceNetworkConfigurationArgs(
 assign_public_ip=True,
 subnets=[app_vpc_subnet.id],
 security_groups=[app_security_group.id]
 ),
 load_balancers=[aws.ecs.ServiceLoadBalancerArgs(
 target_group_arn=flask_targetgroup.arn,
 container_name="flask-container",
 container_port=80,
 )],
 opts=pulumi.ResourceOptions(depends_on=[flask_listener]),
)

Finally, we actually launch our website. We need to create a new service definition and hand it all of the resources we created earlier, beginning with the ECS cluster itself. It has the task definition, our network configurations, and our load balancers, and we make sure that this particular piece of code isn’t executed until the listener we created to watch for traffic is online.

As a shortcut to finding our website, export the DNS name of our load balancer as an output from Pulumi as the last part of the program:

pulumi.export("app-url", flask_balancer.dns_name)

We’re ready to go! Set your AWS region in your terminal:

pulumi config set aws:region us-west-2

Then run pulumi up to watch it go! This time, we’re going to see way more services created than before.

 Type Name Status Info
 + pulumi:pulumi:Stack part-three-dev created
 + ├─ docker:image:Image flask-dockerimage created
 + ├─ aws:ec2:Vpc app-vpc created
 + ├─ aws:ecs:Cluster app-cluster created
 + ├─ aws:iam:Role app-exec-role created
 + ├─ aws:iam:Role app-task-role created
 + ├─ aws:ecr:Repository app-ecr-repo created
 + ├─ aws:iam:RolePolicyAttachment app-exec-policy created
 + ├─ aws:iam:RolePolicyAttachment app-access-policy created
 + ├─ aws:ecr:LifecyclePolicy app-lifecycle-policy created
 + ├─ aws:ec2:Subnet app-vpc-subnet created
 + ├─ aws:ec2:InternetGateway app-gateway created
 + ├─ aws:ec2:SecurityGroup security-group created
 + ├─ aws:lb:TargetGroup flask-targetgroup created
 + ├─ aws:ecs:TaskDefinition flask-task-definition created
 + ├─ aws:lb:LoadBalancer flask-balancer created
 + ├─ aws:ec2:RouteTable app-routetable created
 + ├─ aws:ec2:MainRouteTableAssociation app_routetable_association created
 + ├─ aws:lb:Listener flask-listener created
 + └─ aws:ecs:Service flask-service created

Outputs:
 app-url: "flask-balancer-a90d260-057e5a40e0267b63.elb.us-west-2.amazonaws.com"

Resources:
 + 20 created

Duration: 3m36s

Pulumi has created 20 resources for you, and helpfully returned the DNS address of your load balancer. I’ve snipped out the diagnostics section of this output for the sake of keeping things brief, but you will also see the step-by-step process Docker goes through building and running your image. Go to that URL after a couple of minutes, and your website is online!

We now have a functional, multi-page website with server-side routing, packaged up into a Docker container and deployed to a fully-configured AWS ECS cluster in just a couple hundred lines of Python, all without leaving the same repository our website is stored in. What if we want to be able to scale really large, though? Some resiliency would be nice. Stay tuned for the next blog for an introduction to Kubernetes, where we’ll learn to deploy our website to Amazon’s Elastic Kubernetes Service!

Cloud Systems: Containerizing a Website

Kat Cosgrove — Mon, 27 Dec 2021 12:26:10 -0800

In part one of this series, we built a personal website and deployed it to AWS S3. That works perfectly well for a static, single-page application with minimal interactivity, but if you want server-side routing or database interactivity, things have to get a little bit more complicated. In part two of this series, we’ll be adding a couple more pages to our personal website, adding server-side routing, and containerizing it with Docker.

Containers

So, what’s a container and why would you want to use one? You can think of a container here the exact same way you think of containers on a shipping barge. On that barge is a bunch of shipping containers, and inside each shipping container is a bunch of packages. The barge itself is your computer (or your cloud environment), and the shipping containers house your applications.

It may also help to think of them as smaller, more lightweight incarnations of virtual machines. While a virtual machine virtualizes the machine’s physical hardware through the use of a hypervisor, a container virtualizes only the operating system. A virtual machine is usually several gigabytes in size, whereas a container is usually less than a gigabyte. The small size and speed of deployment as compared to a traditional virtual machine has given rise to the popularity of designing applications as collections of microservices (several single-purpose services running in containers that, when working together, make up your complete application) instead of monoliths (all of your application code and services running as a single unit, often within a single file).

Deploying your application using containers allows you to package your application code alongside everything required to run it, including its dependencies and an operating system. You know how sometimes you hand code off to someone else, but it doesn’t run for them, so you go “Well, it works on my machine,” and just shrug? Using a container is pretty similar to just deploying your machine. The most popular container engine today is Docker, so that’s what we’ll be using today.

Prerequisites:

Docker
Python3

Before we go into containerizing and deploying our website, let’s make it a little bit more useful. For this, we’re going to be using Flask, a lightweight web framework for Python. Fork and clone this GitHub repository to get the full sample code for part two of this series.

Expanding the Website

Our file structure gets more complicated now that we are building a more dynamic website with server-side routing and throwing it into a Docker container. You will have something like this:

container-tutorial
├── Pulumi.yaml
├── requirements.txt
├── __main__.py
└── website
├── Dockerfile
├── requirements.txt
└── app
├── server.py
├── static
│ ├── normalize.css
│ ├── style.css
│ └── background.jpg
└── templates
├── base.html
├── index.html
├── portfolio.html
└── about.html

Everything contained within the app directory is the website itself. We now have server-side routing, and a few different pages. To run it locally and see what the new website looks like, pip3 install flask to install the Flask web framework and then run python3 server.py from the app directory. Flask will return an IP address where your website is running; navigate there in your browser and click around a bit!

server.py

from flask import Flask, render_template

app = Flask(__name__)

@app.route("/")
def home():
 return render_template("index.html")

@app.route("/about")
def about():
 return render_template("about.html")

@app.route('/portfolio')
def portfolio():
 return render_template("portfolio.html")


if __name__ == '__main__':
 app.run(host='0.0.0.0', port=80, debug=True)

Where before our entire website was made up of a single HTML file, we now have several, and we’re using Flask to handle the routing between them. In this server file, three routs are defined: home, about, and portfolio. Flask handles serving these up for us, and associating a route with a particular HTML file. This way, we get a nice www.mywebsite.com/about URL instead of something like www.mywebsite.com/about.html. Building a website this way also means we have the ability to apply some logic to each of these routes, such as adding database interaction, user login, and passing conditional variables from the server to the templates that will be rendering each page. We aren’t doing any of that yet, but we will!

At the bottom, we’re binding the Flask application to 0.0.0.0:80. You can change that to any other unoccupied local IP address and port you like.

Templating

Flask can make use of a templating engine called Jinja2 to make adding pages to your website a bit less repetitive. You start with one template, in this case called base.html, that contains any HTML you want to exist on every single page.

base.html

<!DOCTYPE html>
<html>
<head>
 <meta charset="utf-8">
 <title>Hello world!</title>
 <link rel="stylesheet" href={{ url_for('static', filename='style.css') }}>
 <link rel="stylesheet" href={{ url_for('static', filename='normalize.css') }}>
</head>
<body>
 <header>
 <div class="logo"><i class="fas fa-cat"></i></div>
 <nav>
 <ul>
 <li {% if request.path == url_for('home') %} class="active" {% endif %}>
 <a href="{{ url_for('home') }}">Home</a>
 </li>
 <li {% if request.path == url_for('about') %} class="active" {% endif %}>
 <a href="{{ url_for('about') }}">About</a>
 </li>
 <li {% if request.path == url_for('portfolio') %} class="active" {% endif %}>
 <a href="{{ url_for('portfolio') }}">Portfolio</a>
 </li>
 </ul>
 </nav>
 <ul class="social">
 <li><a href="http://github.com/katcosgrove" target="_blank"><i class="fab fa-github-alt"></i></a></li>
 <li><a href="http://twitter.com/Dixie3Flatline" target="_blank"><i class="fab fa-twitter"></i></a></li>
 <li><a href="http://linkedin.com/in/katcosgrove" target="_blank"><i class="fab fa-linkedin-in"></i></a></li>
 </ul>
 </header>
{% block content %}{% endblock %}
</body>
<script src="https://kit.fontawesome.com/b4747495ea.js" crossorigin="anonymous"></script>
</html>

This file includes some metadata, stylesheets, the header, navigation, and any Javascript we want to link in. All of the content in this file will exist on every page. Below the header, in the body, you’ll see {% block content %} {% endblock %}. That’s where additional, page-specific content will be added.

index.html

{% extends 'base.html' %}

{% block content %}

<div class="content">
 <h1>Your Name</h1>
 <h3>Job Title at Company</h3>
</div>

{% endblock %}

This is all that exists in our index.html now. The first directive tells Jinja2 that this bit of HTML goes in the base.html template, and the remaining two wrap the content we want to insert. The same thing is happening in about.html and portfolio.html. Neat, right? Jinja2 is not unique to Flask, so you can use this templating engine with another web framework if you prefer.

While we could deploy this as-is, it’s a bit unwieldy. Let’s wrap it up into a container.

Dockerizing our Website

In the website directory, we have something called a Dockerfile. Dockerfiles tell the Docker engine what to do with your application, how your container should behave with respect to the wider internet or other containers, and what needs to be done inside of the container for your application to run. Ours looks like this:

FROM ubuntu:20.04

COPY app /app

WORKDIR /app

EXPOSE 80

RUN apt-get update && \
 apt install -y gcc python3-dev python3-pip python-markupsafe

COPY requirements.txt /app

RUN pip3 install -r requirements.txt

ENTRYPOINT [ "python3" ]

CMD [ "server.py" ]

This Dockerfile says that our container should be running ubuntu:20.04 as its operating system. It will pull the Ubuntu image from Docker Hub, their public image registry, though you can pull from another registry here as well. The COPY directive moves our website’s files (the app directory) into the container. We then set our working directory for all future commands run inside of the container to /app to reduce the amount of typing we have to do later on, update Ubuntu, and install some dependencies using both apt and from the requirements.txt file we also copy over. Lastly, an entrypoint and command to actually start our application are defined. There is a slightly less verbose way to start the application, but this way of defining an ENTRYPOINT and CMD is fairly common, so it’s worth seeing here.

To see this run locally, we first need to build and tag the image. From the same directory as your Dockerfile, run the following command:

docker build --tag container-tutorial:latest .

We are calling the docker CLI, telling it we want to build a container, and indicating that we want to tag it at the same time. The tag isn’t strictly necessary for the container to run, but it does make the container easier to identify and interact with. We’re also assigning it a version of latest. Note the trailing dot at the end of the command, which is the part of the command that indicates the location of the Dockerfile we want to build.

Run docker images to see a list of all images you have built. Something like this should be in the list:

cloud-systems latest 0ce569ac0360 10 days ago 408MB

Now the container is built, we need to run it and forward the container’s port to a local port so we can see our site.

docker run -d -p 80:80 container-tutorial

There’s a lot going on in that command, so let’s take a closer look. the -d flag is short for --detach, and it tells the Docker engine that we want to print the container’s ID and run it in the background. The -p flag is short for --publish, and it tells the Docker engine to publish the container’s port to the host. In this case, port 80.

Run docker ps to get a list of all running containers, and you’ll see something like this:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f95362faf3cd container-tutorial "python3 server.py" 7 days ago Up 7 days 0.0.0.0:80->80/tcp, :::80->80/tcp affectionate_jackson

That’s our website! You can see the container ID, the image tag, the commands that ran for it to start the application, its host, the container port, and the port it forwarded to. Go to localhost in your browser, and the website is up!

We’re hosting this locally, though. It’s not accessible by the wider internet, and even if it was, our machines would be dealing with all of the traffic. There’s nothing in place to distribute traffic or restrict access. Worry not, cloud services exist for that, too. In the next in this series, we’ll take our containerized website and deploy it to AWS Elastic Container Service, complete with AWS networking configuration, IAM roles, and AWS Fargate!

Cloud Systems: Static Sites and AWS S3

Kat Cosgrove — Wed, 15 Dec 2021 00:00:00 +0000

The simplest website you can build is a static site. That means no web server, just HTML, CSS, and maybe some front-end JavaScript. Static sites can still be beautiful and interactive though, and for many people, they’re more than enough.

Amazon S3 (Simple Storage Service) is an AWS service that provides cloud storage for files, stored as objects in buckets. You can think of it like an external harddrive: plug it into your computer, and you have more storage space for your files, photos, and movies that you can unplug at will and move to another computer. An S3 bucket behaves very similarly in that you can throw just about anything in it, from data lakes to images to logs, and connect it to an application. This also means that you can use it to host a static website! Let’s look at how.

Prerequisites:

An AWS account
Pulumi account
Pulumi installed and configured for AWS
Python3
NodeJS (optional if you want to preview the site locally)

There are a lot of ways to provision an S3 bucket and set its permissions, but for this I’m going to use Pulumi, an Infrastructure as Code tool that allows you to provision, configure, and deploy a variety of cloud services and tools programmatically, without learning a new language. That way, we can stay in our code, and the syntax will be more familiar for developers. It also saves us the headache of going through the AWS Console. All of the code for this, both the website and the infrastructure code, can be found in the GitHub repository for the series, although I’ll be walking you through everything here too.

Building a Static Site

Create a new directory called s3-tutorial and navigate into it. From there, run pulumi new python -y to create a new Pulumi project using Python. You’ll see Pulumi create a few files for you, but the one we’ll be touching is __main__.py.

Before we move on, we need to build out our website. Create a subdirectory and call it website. In that directory, add index.html, style.css, and normalize.css.

This one is built using only HTML and CSS, plus one background image file. Replace the name and bio with your own, as well as the social links in the header.

index.html

<!DOCTYPE html>
<html>
<head>
 <meta charset="utf-8">
 <title>Hello world!</title>
 <link rel="stylesheet" href="style.css">
 <link rel="stylesheet" href="normalize.css">
</head>
<body>
 <header>
 <div class="logo"><i class="fas fa-cat"></i></div>
 <ul class="social">
 <li><a href="http://github.com/katcosgrove" target="_blank"><i class="fab fa-github-alt"></i></a></li>
 <li><a href="http://twitter.com/Dixie3Flatline" target="_blank"><i class="fab fa-twitter"></i></a></li>
 <li><a href="http://linkedin.com/in/katcosgrove" target="_blank"><i class="fab fa-linkedin-in"></i></a></li>
 </ul>
 </header>
<div class="banner">
 <h1>Your Name</h1>
 <h3>Job Title at Company</h3>
 <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam blandit tristique arcu, sed commodo ligula. Ut ullamcorper velit non luctus mollis. Sed placerat quam sed tellus aliquam, ac eleifend quam lacinia. Praesent bibendum velit at metus auctor, vitae feugiat quam luctus. Morbi eu imperdiet metus, et tincidunt tellus. Aliquam non ullamcorper justo. Cras ornare nulla vel pellentesque vulputate. Mauris in elit neque. Aliquam tempor aliquam libero, elementum luctus nisl imperdiet sit amet. Praesent urna ante, scelerisque non tellus mollis, laoreet sodales felis.</p>
</div>
</body>
<script src="https://kit.fontawesome.com/b4747495ea.js" crossorigin="anonymous"></script>
</html>

style.css

@import url('https://fonts.googleapis.com/css?family=News+Cycle|Teko&display=swap');

ul {
 list-style-type: none;
}

ul li {
 display: inline-block;
}

a {
 color: white;
 -webkit-transition: color .5s ease-out;
 transition: color .5s ease-out;
 text-decoration: none;
}

a:hover, a:active {
 color: rgb(255, 157, 112);
}

header {
 background-color: rgba(0, 0, 0, .8);
 height: 80px;
 position: absolute;
 top: 0;
 width: 100%;
}

header li {
 color: white;
}

.active a {
 color: rgb(255, 157, 112);
}

.social {
 position: absolute;
 right: 50px;
 top: -5px;
 font-size: 30px;
}

.social li {
 margin: 0 5px 0 5px;
}

.logo {
 position: absolute;
 left: 10px;
 margin-left: 20px;
 font-size: 60px;
 color: white;
}

body {
 background: url('./background.jpg');
 background-size: cover;
 background-repeat: no-repeat;
}

.banner {
 width: 60vw;
 font-family: Teko;
 font-size: 2vw;
 text-align: center;
 margin-top: 15vw;
 margin-left: 20vw;
}

.banner p {
 font-family: News Cycle;
}

Your normalize.css can be copied from this repository, and the expected background.jpg can be downloaded from this repository.

To see what this looks like before we deploy it, we’re going to use a tool called live-server. This isn’t a real, functional webserver, but it’s a useful tool during development for static websites. It will reload automatically when a change is detected, so you don’t have to wait for deploys.

Install it with this:

npm install -g live-server

And run it from the same directory as your index.html file:

live-server

Your browser should automatically open to localhost:8080, but if it doesn’t, navigate there yourself and you’ll see your website.

Configuring an S3 Bucket

It’s time to deploy this thing to S3. From your project’s root, run source venv/bin/activate to make sure we’re in a virtual environment, and run pip3 install pulumi-aws. From now on, we’ll be working in __main__.py

For imports, we need the following:

import json
import mimetypes
import os

from pulumi import export, FileAsset
from pulumi_aws import s3

We’re going to be reading files from the operating system and working with JSON, so we need the first three packages from the standard Python library. We’re also going to be using Pulumi. You will already have the pulumi package installed, but we also need the AWS provider, which we just installed.

web_bucket = s3.Bucket('s3-website-bucket',
 website=s3.BucketWebsiteArgs(
 index_document="index.html",
 ))

Here, we are instantiating an s3 Bucket object and assigning it to the web_bucket variable. S3 buckets are capable of hosting websites, but we have to tell the bucket that’s what it’s going to be doing and what it should expect the index document to be called. Ours is just called index.html.

content_dir = "website"
for file in os.listdir(content_dir):
 filepath = os.path.join(content_dir, file)
 mime_type, _ = mimetypes.guess_type(filepath)
 obj = s3.BucketObject(file,
 bucket=web_bucket.id,
 source=FileAsset(filepath),
 content_type=mime_type)

This codeblock defines our content directory (the website folder containing your site files, from earlier) and reads each of them in, before creating using the Pulumi AWS module to create an S3 bucket object for that file. We are also including a little bit of metadata for each file.

def public_read_policy_for_bucket(bucket_name):
 return json.dumps({
 "Version": "2012-10-17",
 "Statement": [{
 "Effect": "Allow",
 "Principal": "*",
 "Action": [
 "s3:GetObject"
 ],
 "Resource": [
 f"arn:aws:s3:::{bucket_name}/*",
 ]
 }]
 })

This function sets some permissions for our bucket. Since this should be publicly-accessible, we need to allow anyone the ability to read the files.

bucket_name = web_bucket.id
bucket_policy = s3.BucketPolicy("bucket-policy",
 bucket=bucket_name,
 policy=bucket_name.apply(public_read_policy_for_bucket))

Now we assign the ID of our bucket as the bucket’s name, then create a policy for it that includes its name and the policy we defined in the previous step. We’re almost done!

export('bucket_name', web_bucket.id)
export('website_url', web_bucket.website_endpoint)

These last two lines are using Pulumi to export some data for us to interact with. The first is the ID of the bucket so we know which one we’re working with, and the second is the website endpoint created by S3 once the bucket is online, so we know where to go to see our site!

Deploying

All that’s left to do is deploy! From your project’s root directory, define the AWS region you want to work in by running pulumi config set aws:region us-west-2, then run pulumi up!

Pulumi will first give you an overview of the expected changes and ask if you want to perform the update. In my case, it looks like this:

 Type Name Plan
 + pulumi:pulumi:Stack static-site-s3-dev create
 + ├─ aws:s3:Bucket s3-website-bucket create
 + ├─ aws:s3:BucketObject index.html create
 + ├─ aws:s3:BucketObject style.css create
 + ├─ aws:s3:BucketObject normalize.css create
 + ├─ aws:s3:BucketObject background.jpg create
 + └─ aws:s3:BucketPolicy bucket-policy create

Resources:
 + 7 to create

Do you want to perform this update? [Use arrows to move, enter to select, type to filter]
> yes
 no
 details

If everything goes smoothly, you’ll see more feedback from Pulumi showing each resource that was created:

 Type Name Status
 + pulumi:pulumi:Stack static-site-s3-dev created
 + ├─ aws:s3:Bucket s3-website-bucket created
 + ├─ aws:s3:BucketObject index.html created
 + ├─ aws:s3:BucketObject style.css created
 + ├─ aws:s3:BucketObject normalize.css created
 + ├─ aws:s3:BucketObject background.jpg created
 + └─ aws:s3:BucketPolicy bucket-policy created

Outputs:
 bucket_name: "s3-website-bucket-89f0341"
 website_url: "s3-website-bucket-89f0341.s3-website-us-west-2.amazonaws.com"

Resources:
 + 7 created

Duration: 6s

Notice the Outputs section there. Those are the two things we exported at the very end of our __main__.py: the ID of the bucket, and the website URL. Click on the website URL, and you’ll see your personal site, deployed to AWS S3 and publicly accessible by anyone! If you don’t want to keep this up, run pulumi destroy to tear down all of these resources, and you’re done!

We’re not quite done yet, though—this site is a little slow, and it’s not very interactive. Maybe we want some kind of database associated with it, or the convenience of containers, or the scalability of Kubernetes. Stay tuned for the next tutorial in this series, where we’ll keep building on this website to introduce more modern cloud engineering tools until it looks like something you’d happily call production!

Kubecon NA 2021 Roundup

Kat Cosgrove — Mon, 08 Nov 2021 22:50:38 +0000

KubeCon North America 2021 is over, but the recordings are now online! Every talk you wanted to attend and couldn’t is available on YouTube, so here’s some highlights—cloud native trends, updates from projects and SIGs, and a few of my favorite talks!

SBOM is Coming: Why You Should Care and How You Can Help - Frederick Kautz & Allan Friedman

A major trend throughout the conference was supply chain security and software bill of materials (SBOMs). There were quite a few talks on these subjects, but Frederick Kautz and Allan Friedman give a great overview of exactly what an SBOM is, and why it’s important.

Notary: State of the Container Supply Chain - Justin Cormack, Docker & Steve Lasker, Microsoft

On supply chain security, Steve Lasker presents updates to Notary v2. It’s changed quite a bit since v1 and there are more changes on the horizon. With the rising concerns surrounding supply chain security, I expect Notary and tools like it to be increasingly important. No worries if you aren’t already familiar with Notary—Steve explains it well.

A Vulnerable Tale About Burnout - Julia Simon, CloudOps

Taking things to a more human place, burnout was a common theme this year. It’s something that we don’t talk about as much as we should, but close to two years of isolation is forcing us all to confront it in ways we may not have expected. This talk by Julia Simon is important to watch not just so that you can learn to recognize these problems in yourself, but so that you can recognize them in your peers.

PodSecurityPolicy Replacement: Past, Present, and Future - Tabitha Sable & Tim Allclair

PodSecurityPolicy (PSP) has been deprecated. Many of you may be relying on this, and deprecations frequently sound scary, but Tabitha Sable and Tim Allclair are here to soothe your fears. They go to great lengths explaining what PSP is, why it was deprecated, what exactly this means for people relying on it, and where we’re going next.

SIG Contributor Experience Deep Dive - Alison Dowdney, Weaveworks & Christoph Blecker, Red Hat

An open source project lives or dies by its contributors, both technical and non-technical. Kubernetes is huge and requires a lot of contributors to keep it growing, so we have SIG Contributor Experience to make sure they stay happy and the community stays healthy. Alison Dowdney and Christoph Blecker go into just how SIG Contributor Experience operates, plus updates. If you’re in a leadership position for an open source project, there are some lessons to be learned from this talk.

Kubernetes Exposed! Seven of Nine Hidden Secrets That Will Give You… Ian Coldwater & Brad Geesaman

No Kubecon is complete without Ian Coldwater, this time joined by Brad Geesaman (and, briefly, a second Ian Coldwater) to go into some not-so-obvious but oh-so-important pitfalls and hidden security concerns within Kubernetes. Even if you caught this talk live, it’s worth watching again to make sure you’re secured against these issues, or you might find a goose haunting your cluster.

Beyond Kubernetes Security - Ellen Körbes, Tilt & Tabitha Sable, Datadog

Finally, it would be remiss of me to not mention Ellen and Tabitha’s cinematic contribution to this year’s Kubecon North America. Beyond Kubernetes Security is the spiritual successor to their talk from the last Kubecon Europe, once again going into how some security concepts and exploits work in Kubernetes, but presented as a short film involving crime, time travel, breakups, and Ellen’s collection of old electronics.

The quality of the content was incredible across the board this year, whether the speakers were live or presenting virtually, forcing some difficult decisions around selecting my schedule for talks to attend and how many I could feasibly put in this blog before it got way too long. Fortunately, all of them are on the CNCF YouTube channel now, including talks from the various co-located events. Dig through!

Kubecon North America was simultaneously a strange and familiar event. It’s been nearly two years since most of us have been at a conference, and while that certainly made things awkward at times while we all readjusted to seeing other humans in the flesh, our slow return to something vaguely familiar seems to have been a success. I sincerely hope to see you all in person at the next Kubecon EU in Valencia.

Honk <3,

Kat

Cloud Engineering Summit Build Track

Kat Cosgrove — Thu, 16 Sep 2021 13:47:25 -0500

The Cloud Engineering Summit 2021 is coming up fast, and the speakers are out! To get you ready to attend, let’s take a look at the sessions for the Build track.

The Cloud Engineering Summit’s three tracks are built around three concepts: Build, Manage, and Deploy. I’m Kat Cosgrove, and I was responsible for selecting your speakers for the Build track! For us, that means building cloud applications and infrastructure with Modern Infrastructure as Code using general purpose programming languages. We embrace the fact that modern cloud applications have blurred the lines between the application and the infrastructure, and that success requires at least some level of proficiency in both. Whether you’re full stack or lean more towards one area, all cloud engineers apply a software engineering mindset and practices to building and testing applications and the underlying cloud infrastructure. This includes using standard programming languages, applying software principles such as reusability and abstractions and testing, and leveraging the rich ecosystem of software development tools.

Without further ado, let’s take a look at each of the talks I’ve selected for you!

Starting us off is the inimitable Kris Nóva with Infrastructure as Software. She’s going to be talking about why Turing complete config management is an antipattern, and why we should be putting the Dev back in DevOps. Nóva is an incredible speaker and engineer. Any talk she gives promises to be hot fire, so I wouldn’t miss this one.

Don’t like repeating yourself? Yeah, me neither. Fortunately, we have Sam Cogan to present his talk, Reuse, Don’t Repeat - Creating an Infrastructure as Code Module Library. Personally, I’m a huge fan of reusable modules for any purpose, when they’re built in such a way that it reduces overall toil and makes your codebase easier to understand. This talk should be useful for everyone.

Helping us ask and answer the right questions to make organizational and technological decisions is Joep Piscaer, presenting Kubernetes isn’t the answer, but what was the question again? I love Kubernetes, but it can be complex, and sometimes that complexity means it’s not the right solution for you (yet.) If you struggle with finding the right questions to ask about your tech needs, this talk could help.

I’m kind of nosy. I like knowing as much as possible about what’s going on inside of my applications and infrastructure. It’s hard to present all of that data in a way that’s easy to consume rather than overwhelming, though. Fortunately, we have Liz Fong-Jones to help out with her talk, What is OpenTelemetry? Don’t miss this one if you’re curious about a better way to gain insights into your distributed systems.

You’d think that when a particular tool is widely accepted as the industry standard for accomplishing a task, there’d be a wealth of information out there on how to accomplish most important tasks in an accessible, actionable way. Unfortunately, that’s not really the case. Fortunately, we have Steve Giguere presenting Hands-on: Taking a K8s Deployment from Default to Secure, wherein he’ll take us through securing an NGINX deployment!

Curious about how a big product gets built? Rahul Sharma is with us to talk about How AWS architects APIs for hyper scale. He won’t just be talking technology; we’ll also hear about the cultural changes required internally to launch a product, and how engagement with customers and partners helps shape the course of development.

Last but certainly not least is Heidi Waterhouse presenting The Future Should Be Uneven, a talk about personalization and accessibility in web design. Accessible design benefits us all, whether we actually need the accommodation or not. The sooner we all understand and embrace that, the better, so Heidi will walk us through some common accessibility settings that are really just good design for everyone.

Explore all of the rest of the great sessions, and don’t forget to register for the cloud engineering summit!

Snowflake Provider Launch

Kat Cosgrove — Wed, 15 Sep 2021 17:16:09 -0500

Snowflake support is here! Pulumi’s new Snowflake Provider gives you the ability to easily set up cloud storage and manage your connections to Snowflake, right alongside the rest of your code.

Pulumi is bringing management of your Snowflake resources into the same place as the rest of your infrastructure! Whether you’re already a big fan or you were just exploring the possibility of using Snowflake, Pulumi has you. For example, you can:

Set up storage in your cloud provider and add it to Snowflake as an external stage
Add storage and connect it to Snowpipe
Create a service user and push the key into the secrets manager of your choice
Rotate keys

You can check out the details in the official Snowflake Provider documentation , with references for Python, Go, TypeScript, and C#!

Kubernetes Fundamentals: Part Two

Kat Cosgrove — Thu, 02 Sep 2021 12:54:53 -0500

Kubernetes is everywhere now, but it’s primarily been the domain of people working on the ops side of infrastructure. What about devs, though? You benefit from knowing what Kubernetes is and how to use it, too—otherwise, we’re still putting teams in silos. In this blog, we’re going to build off part one by learning about managed Kubernetes services: what they are, when they’re useful, and how you can try deploying to one yourself, starting with Google’s Kubernetes Engine (GKE).

What is a managed Kubernetes service?

Essentially, a managed Kubernetes service just means that someone else is responsible for some of the work involved in standing up and maintaining Kubernetes. It varies from provider to provider, but services can be pretty bare-bones or include everything under the sun, handing you a pre-configured environment and a dedicated support team to help you.

What makes this option useful?

Kubernetes is very powerful, but also very complicated. The flexibility of the platform means that there’s a lot of configuration you have to do just to get off the ground, and a managed service takes some of that off your plate. Some configurations are abstracted away, and some decisions are made for you. Things you would otherwise have to set up yourself, like load balancing, monitoring, and updates, are covered by the vendor. It’s less effort to get started and less effort to maintain. Scaling is painless since you can just provision more resources. For most people, a managed service is flat-out more reliable.

Okay, I want to try it for myself.

First things first, we need Pulumi, Node.js, and npm installed.

We’re going to do this on Google Cloud Product (GCP), so you’ll also need the Google Cloud SDK set up. From there, log in with gcloud:

$ gcloud auth login
$ gcloud config set project <YOUR_GCP_PROJECT_HERE>
$ gcloud auth application-default login

Creating a Cluster with Google Kubernetes Engine

Next, we need a cluster. Start by creating a new directory, navigating into it, and initializing a new Pulumi project using TypeScript.

mkdir gke-hello-world && cd gke-hello-world && pulumi new typescript

We also need to install some dependencies, and set some required configuration values.

npm install --save @pulumi/pulumi @pulumi/gcp @pulumi/kubernetes
pulumi config set gcp:project <YOUR_GCP_PROJECT_HERE>
pulumi config set gcp:zone us-west1-a // any valid GCP Zone here

Now, in index.ts, add the following code:

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

const name = "helloworld";

// Create a GKE cluster. We start with two nodes, each running an n1-standard-1 machine, which provides the best balance of price for performance ratio for the most common workloads. Replicas of our application will be distributed across these two nodes, ensuring that if one node goes down, our application remains up in the other node.

const engineVersion = gcp.container.getEngineVersions().then(v => v.latestMasterVersion);
const cluster = new gcp.container.Cluster(name, {
 initialNodeCount: 2,
 minMasterVersion: engineVersion,
 nodeVersion: engineVersion,
 nodeConfig: {
 machineType: "n1-standard-1",
 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"
 ],
 },
});

// Export the Cluster name
export const clusterName = cluster.name;

// 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 kubeconfig = pulumi.
 all([ cluster.name, cluster.endpoint, cluster.masterAuth ]).
 apply(([ name, endpoint, masterAuth ]) => {
 const context = `${gcp.config.project}_${gcp.config.zone}_${name}`;
 return `apiVersion: v1
clusters:
- cluster:
 certificate-authority-data: ${masterAuth.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
`;
 });

// Create a Kubernetes provider instance that uses our cluster from above.
const clusterProvider = new k8s.Provider(name, {
 kubeconfig: kubeconfig,
});

This code is the entrypoint for our program and is what’s setting up the cluster for us. We’re defining the resources we want, the kubeconfig that’ll be used to access the cluster, and also the Kubernetes provider so that we can deploy resources to it next.

Now just run pulumi up to preview the changes, select yes when prompted, and watch the cluster stand up! You’ll see some work happening in your terminal as well as in your Pulumi account, and when it’s all done, you can look at your GCP dashboard and see the cluster there, too.

But we should actually put something in the cluster, shouldn’t we?

A Deployment for the Cluster

Let’s work on that Kubernetes Provider. Using a Kubernetes Provider allows us to abstract away some of the specifics of operating a cluster on one cloud provider or another. That way, your experience from here on out is fairly consistent regardless of where you’re hosting this.

In the same index.ts file from before, add this to the end:

// Create a Kubernetes Namespace
const ns = new k8s.core.v1.Namespace(name, {}, { provider: clusterProvider });

// Export the Namespace name
export const namespaceName = ns.metadata.apply(m => m.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.apply(m => m.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.apply(m => m.name);
export const servicePublicIP = service.status.apply(s => s.loadBalancer.ingress[0].ip)

Here, we’re creating a namespace and adding an NGINX deployment with an accompanying LoadBalancer service and exporting everything we need to run it. Run pulumi up once again, double-check the preview, and select yes to update the deployment. Now everything’s up and running on a managed Kubernetes service that you didn’t have to stand up by hand, and won’t have to expend as much effort maintaining.

Talking to the Cluster

In case you’re curious, you can still interact with the cluster using kubectl when running on a managed provider, just like when you’re running everything locally. Run this command to have Pulumi export your kubeconfig with its secrets:

pulumi stack output kubeconfig --show-secrets > kubeconfig

Then just export it:

export KUBECONFIG=$PWD/kubeconfig

At that point, regular kubectl commands will work. If you followed along, make sure you run pulumi destroy to tear down this stack and all of its resources so you don’t run up a bill!

Coming Up Next

So, that was pretty quick. But I only talked about GKE. What about other cloud providers? Yeah, those work, too. And yes, it’s also fairly quick. Now that I’ve explained the basics of Kubernetes and what managed Kubernetes is, things will get more practical—tune in next time for deploying to EKS!

Kubernetes Fundamentals: Part One

Kat Cosgrove — Fri, 23 Jul 2021 12:54:53 -0500

Kubernetes is everywhere now, but it’s primarily been the domain of people working on the Ops side of infrastructure. What about devs, though? You benefit from knowing what Kubernetes is and how to use it, too – otherwise, we’re still putting teams in silos. In this tutorial, we’re going to define Kubernetes at a high level, talk about the anatomy of a cluster, and learn not just why you should care but how to try it for yourself. We’ll start with local deployments using YAML before getting a little help from infrastructure as code with Pulumi to stand up everything right inside our sample application in a programming language you’re already writing!

What is Kubernetes?

Kubernetes is a container orchestration tool. If we think of it in the context of an actual container ship, then Kubernetes is the person who determines how many shipping containers of particular goods go on the ship and where they should be in relation to each other. It makes deploying containerized workloads a bit less painful to maintain.

Anatomy of a Cluster

Let’s talk about what Kubernetes looks like. Inside a cluster, there is a master node responsible for the overall maintenance of the cluster and several worker nodes where our containers and other workloads live. There are other pieces here, but generally, that’s the high level. You end up with something that looks like a big box containing many smaller boxes, which, in turn, contain more boxes.

So, the master node takes care of the worker nodes, and the worker nodes house our containers, which may be running application code, or a database, or volume storage, or some other service. Instead of managing each of these individual components yourself, you tell Kubernetes how to manage them and let it deal with that for you.

Deployment

There are a few ways to do this. We can use kubectl in the terminal by pointing it at config files written in a format called YAML, or we can use an infrastructure as code tool like Pulumi to help. For now, we’ll use YAML and let kubectl handle it for us.

Kubernetes is useful because it scales your application without quite as much work. Below is an example of the deployment YAML for a small containerized demo application with two replicas. If you want to follow along with an application of your own, you will need Minikube and kubectl installed.

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
 name: demo-deployment
 labels:
 app: hello-kubernetes
spec:
 replicas: 2
 selector:
 matchLabels:
 app: hello-kubernetes
 template:
 metadata:
 labels:
 app: hello-kubernetes
 spec:
 containers:
 - name: flask
 image: dockerhub.io/katcosgrove/fake-container:latest
 ports:
 - containerPort: 5000

This deployment YAML describes what I want to happen:

the name of the pod and application,
the number of replicas I want,
the image to run,
and the port I need.

The Flask application uses port 5000, so the deployment spec does, too. The image isn’t real, but if it were, it would be in a repository called fake-container on my Dockerhub account.

If you were to deploy this with kubectl apply -f deployment.yaml and then run kubectl get pods, you would see the Deployment created two pods for our application.

What if you decide you need more replicas, though? Go back to your deployment configuration, bump the number of replicas to 5, and apply it again with kubectl apply -f deployment.yaml. Run kubectl get pods, and you’ll see three more pods coming online!

Exposing the Application

We probably want to SEE our app, though. The quick and dirty way to do that is port forwarding within the cluster, like this:

kubectl port-forward deployment/demo-deployment 5000:5000

Here, we’re using kubectl to forward the demo-deployment’s port 5000 to our local port 5000. If you go to localhost:5000 in a browser, you’ll see your application.

That’s not very convenient, though, and it doesn’t offer much in the way of customization or control. We need to add an ingress controller. NGINX-ingress is popular, and minikube already has an addon, but there are many other options.

Install it by running minikube addons enable ingress.

To confirm that the pods are up, run kubectl get pods -n kube-system and look for pods that start with “ingress-nginx”. Note that other Kubernetes environments will put these in the “ingress-nginx” namespace instead. Now let’s add a ClusterIP service. That’s what exposes your deployment within the cluster.

service.yaml

apiVersion: v1
kind: Service
metadata:
 name: demo-service
spec:
 ports:
 - port: 8080
 protocol: TCP
 targetPort: 5000
 selector:
 app: demo-deployment
 type: ClusterIP

Like always, we have metadata like a name, we tell it which ports to target (remember our Flask app is targeting port 5000), and we give the name of the deployment.

The last thing we need to do is define the ingress resource. It’s the final piece that allows our application to be this is what exposes your application to the outside world.

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: demo-ingress
spec:
 rules:
 - http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: demo-service
 port:
 Number: 8080

Like with all of our other config files, we’re giving it metadata and telling it what to target. In this case, it’s the service we defined and the service’s port.

As before, apply it with kubectl apply -f ingress.yaml

Now, if you run kubectl get ingress, you’ll get an IP address. Go there in a browser, and there’s your app, deployed on Kubernetes!

Python instead of YAML

Okay, but this all feels very Ops-centric still – we’re writing YAML, not a programming language, and I promised you a familiar programming language. Let’s use Pulumi to do it with Python instead.

Before, we had a ton of YAML, now infrastructure as code tools lets us cut a window from the Ops silo to the Dev silo, so we can share stuff, talk a bit more, and work together. You can stand up the infrastructure to deploy your application on Kubernetes right there in the application code! Fortunately, Pulumi has a bunch of different examples of how to do this.

First, you need Pulumi installed. Then, you need to configure Kubernetes for Pulumi. From here, we can deploy to Kubernetes without touching a shred of YAML directly.

Below is an example of the code required to deploy NGINX to Kubernetes, with two replicas, but this time, in more familiar Python instead of YAML.

import pulumi
from pulumi_kubernetes.apps.v1 import Deployment, DeploymentSpecArgs
from pulumi_kubernetes.core.v1 import ContainerArgs, ContainerPortArgs, PodSpecArgs, PodTemplateSpecArgs
from pulumi_kubernetes.meta.v1 import LabelSelectorArgs, ObjectMetaArgs

config = pulumi.Config()
nginxLabels = {"app": "nginx"}
nginxDeployment = Deployment(
 "nginx-deployment",
 spec=DeploymentSpecArgs(
 selector=LabelSelectorArgs(match_labels=nginxLabels),
 replicas=2 if config.get_int("replicas") is None else config.get_int("replicas"),
 template=PodTemplateSpecArgs(
 metadata=ObjectMetaArgs(labels=nginxLabels),
 spec=PodSpecArgs(
 containers=[ContainerArgs(
 name="nginx",
 image="nginx:1.7.9",
 ports=[ContainerPortArgs(container_port=80)],
 )],
 ),
 ),
 ))

pulumi.export("nginx", nginxDeployment.metadata.apply(lambda m: m.name))

In just 25 lines and one file, we’ve set up a deployment with two replicas of a containerized application and exposed it. It’s happening in a language you’re familiar with, and it can live right alongside your application code, rather than keeping everything in silos. If you want to increase the number of replicas, it requires no more effort than it did when using YAML.

Keeping the Dev team and the Ops team isolated from one another leads to misunderstandings, confusion, and a slower release cycle. At the very least, both parties need to understand each other, which means Devs need to learn a bit more about Kubernetes. Pulumi can help you speak Kubernetes in your favorite language.

This example is all local, though, and you might not be running Kubernetes on-prem. What if you want to abstract things away even further? Tune in next time for Kubernetes on cloud providers!