Pulumi Blog: Digitalocean

Deploy MERN Stack on DigitalOcean with Pulumi [Guide]

Christian Nunciato — Fri, 11 Mar 2022 00:00:00 +0000

As a developer, I get lots of ideas for web apps—little things, mostly: nifty ways to keep track of my kids’ allowances, habit trackers, shopping lists. Most of them, however, never see the light of day, and not just because I’m lazy; I also tend to get hung up trying to decide what to use for the technology stack.

And as a JavaScript developer, I certainly have options—too many, in fact, and that’s part of the problem. Having roughly a hundred and fifty million libraries and frameworks to choose from is definitely better than having none, but at the same time, all that choice can make the actual choosing rather difficult. Which is why, when I just want to get something done, I’ll often reach for a combination of tools known as the MERN stack.

MERN-stack apps are three-tier web apps built with MongoDB, Express, React, and Node.js. You can read all about them in the MongoDB docs, but the gist is that they allow you use one language—JavaScript (or TypeScript, if you like)—to manage all three layers of the application stack: the front end as a single-page app built statically with React, the back end as a REST API managed with Express, and the database as a collection of JSON-like documents with MongoDB. MERN might not always the right tool for the job, but for the kinds of apps I tend to find myself building, it generally works out pretty well.

Still, once I’m finished building my app, I’m often faced with a whole other problem: figuring out how to get the app off of my laptop and onto the web.

The cloud hasn’t made this an easy task for developers. Choosing a cloud provider, deciding which resources to use (and how to use them), setting up networking, debugging permissions, navigating billing, and all the rest, can be overwhelming—and that’s before you’ve given a single thought to anything having to do with automation or infrastructure as code. What we want, I think, is to be able to focus on our apps, and when we’re ready to ship, push our code to a repository and wait patiently for a URL to emerge that we can paste into a browser and have everything just work.

Which is why I was so delighted when I discovered DigitalOcean’s App Platform.

If you’ve used DigitalOcean before, you know it’s all about making infrastructure more accessible to developers. What you may not know, though, or at least I didn’t myself until recently, is that you can do a lot more with DigitalOcean than just virtual machines. A fairly new, fully-managed platform service (think Heroku), App Platform gives you a set of high-level abstractions built to align with the tiers of a typical web application, which means you can focus on what you care about most—your app—and leave the infrastructure and its management to someone else. It’s a compelling option for anyone looking to deploy and manage any web application (MERN or otherwise), and as you’ll see, with Pulumi and a little bit of code, you can easily do so without ever having to leave the comfort of your IDE.

So let’s build ourselves a MERN app and deploy it on DigitalOcean with Pulumi. Given the goal is to focus primarily on the infrastructure and how to code it, we’ll start with a pre-baked web application (a simple grocery list), and we’ll map its tiers to App Platform constructs and wire everything up with Pulumi.

First steps: setting up

The code for this walkthrough is available as a template repository on GitHub, so if you want to follow along (and you should!), you should grab a copy of your own to work with by forking the repository or creating a new one from the template. Once you’ve done that, you should also:

Clone the repository to your local machine.
Install Pulumi and Node.js.
Sign into DigitalOcean and obtain a personal access token with read-write permissions.
Grant DigitalOcean access to your GitHub repository by visiting the Apps page, choosing Create App, and following the steps to install DigitalOcean’s GitHub app.
Optionally, if you’d like to develop the application locally as well, install and configure MongoDB Community Edition.

One thing to note: Since we’ll be provisioning real DigitalOcean resources, there’s a chance you could incur a slight cost for what you use. However, as we’ll be using the least expensive plan settings available, and tearing everything down when we’re through, that cost shouldn’t amount to more than a few pennies or so.

Let’s get started.

Cloning and inspecting the repository

Once you’ve cloned your copy of the template repository and navigated to the root, you’ll see a couple of files and folders that look something like this:

├── frontend
├── backend
└── package.json

The frontend folder contains the React application, and its job is to render the list of groceries and give you something to interact with (to add items, check them off, delete them, and so on). The scaffolding for the app was generated with a tool called Vite, and all of its logic—form fields, click handlers, API calls, etc.—is contained in src/App.tsx.

The backend folder contains the Express application that defines the REST API. It sets up four API routes to handle the CRUD operations you’d expect in an app like this one:

GET /api/items fetches all items from the database and returns them as a JSON array.
POST /api/items accepts a new item and writes it to the database.
PUT /api/items/:id updates an existing item (to toggle its checked/unchecked status).
DELETE /api/items/:id deletes an item from the database.

The back end supports three configurable properties as well, all of which are exposed as optional environment variables:

BACKEND_SERVICE_PORT, which defaults to 8000
BACKEND_ROUTE_PREFIX, which defaults to /api
DATABASE_URL, which defaults to mongodb://127.0.0.1 for local development

Running the application locally (optional)

You don’t have to do this, but if you’d like to, here’s how. After installing MongoDB and starting the service (which should be listening by default on port 27107), you can install all front-end and back-end dependencies and start the development server:

$ npm install
$ npm start

With the development server running, you can browse to http://localhost:3000 and see the app:

The front-end and back-end dev servers are set up to compile your TypeScript to JavaScript automatically, and the front-end server is configured to proxy the back-end service (which runs at http://localhost:8000) at a root-relative path of /api. Proxying the API in this way lets you avoid having to wrestle with CORS-related issues, and as you’ll see when we deploy to DigitalOcean later, App Platform conveniently supports the same configuration out of the box.

Try adding a few items and marking them off, just to make sure everything’s working as expected. If you’ve got a MongoDB client installed as well—I generally use MongoDB Compass—you should be able to find the grocery-list database and see the items collection filling up with delicious foods:

Now let’s have a look at how to go about deploying this stuff.

Charting a course

Earlier I mentioned that every cloud provider handles application deployment a little differently, sometimes in multiple ways, and that’s true for DigitalOcean as well. You could deploy the front end as a DigitalOcean Space, or both the front end and back end (and even the database) as a DigitalOcean Droplet. But given the shape of this application, the best fit is really is App Platform, for several reasons.

One is that because App Platform apps are comprised of these high-level components—abstractions like static site, service, and database—it’s pretty much purpose-built for an application like this one, and DigitalOcean customizes the deployment of each component based on its type. Static websites are distributed and cached on DigitalOcean’s CDN, services are packaged and delivered as containers (with its Kubernetes platform), and databases are deployed as configurable managed services. All of this means you’re not only able to stay focused on the application itself, but you’re able to scale each one of these components up or down however you like, and even delegate your front-end and back-end build processes to DigitalOcean to be handled in response to commits on one or more external Git repositories.

App Platform apps can be configured in one of two ways: manually, by configuring their components individually in the DigitalOcean web console, or programmatically, in the form of an App Platform spec, a JSON document submitted over DigitalOcean’s REST API. In our case, we’ll indirectly go the latter route, using Pulumi with the DigitalOcean provider package to define an app spec comprised of three components:

A staticSite component mapped to the frontend folder
A service component mapped to the backend folder
A database component mapped to a managed MongoDB cluster (which we’ll also configure to be accessible only by the service component)

And once deployed, it’ll all be available at a single DigitalOcean-provided URL.

Let’s begin by creating new Pulumi project.

Creating the project

In the root of the repository, make a new folder called infra, change to it, then run pulumi new using the digitalocean project template:

$ mkdir infra && cd infra
$ pulumi new digitalocean-typescript

$ mkdir infra && cd infra
$ pulumi new digitalocean-python

At the prompts, use the following values:

For project name, use grocery-list
For description, use Deploying a MERN-stack app on DigitalOcean
For stack name, use dev, the default

When the command completes, you’ll have a new Pulumi stack, but you’ll still have a few things to configure. For one, the Pulumi DigitalOcean provider needs to be configured to communicate with DigitalOcean on your behalf (to provision your app and its various resources). For this, you can use the access token you obtained earlier from the DigitalOcean console, and you can apply it by setting a single environment variable:

$ export DIGITALOCEAN_TOKEN="your-access-token"

Also, since one of our goals is to have App Platform deploy automatically on every GitHub commit, you’ll need to tell DigitalOcean where to find the source code for your front- and back-end components. You could bake these settings right into the Pulumi program itself, but it’d be better to apply them as stack-specific configuration settings, as that’d let you deploy to different stacks later (say, in CI) based on the branch of the commit. Everyone does this a little differently, so for now, let’s configure the currently selected stack (which should be dev) to use the default branch of your GitHub repository:

$ pulumi config set repo "your-github-org/your-github-repo" # e.g., cnunciato/fullstack-pulumi-mern-digitalocean
$ pulumi config set branch "your-main-branch" # e.g., main

With these values in place, you’re ready to start writing the program.

App Platform also supports GitLab and other Git-based repositories as well. See the App Specification docs for details.

Writing the program

In your IDE of choice, open index.js index.ts main.py main.go Program.cs Program.fs Program.vb App.java Pulumi.yaml main.tf and replace the sample code with the following lines to import the Pulumi and DigitalOcean SDKs and the configuration values you just set, and add a line to specify the DigitalOcean region to deploy into:

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

// Our stack-specific configuration.
const config = new pulumi.Config();
const repo = config.require("repo");
const branch = config.require("branch");

// The DigitalOcean region to deploy into.
const region = digitalocean.Region.SFO3;

import pulumi
import pulumi_digitalocean as digitalocean

# Our stack-specific configuration.
config = pulumi.Config()
repo = config.require("repo")
branch = config.require("branch")

# The DigitalOcean region to deploy into.
region = digitalocean.Region.SFO3

Next, add a few lines to declare the managed MongoDB cluster. We’ll use just one node for now—additional replica nodes can easily be added later by increasing the nodeCount value—and go with the least expensive performance settings:

// ...

// Our MongoDB cluster (currently just one node).
const cluster = new digitalocean.DatabaseCluster("cluster", {
 engine: "mongodb",
 version: "5",
 region,
 size: digitalocean.DatabaseSlug.DB_1VPCU1GB,
 nodeCount: 1,
});

// The database we'll use for our grocery list.
const db = new digitalocean.DatabaseDb("db", {
 name: "grocery-list",
 clusterId: cluster.id,
});

# ...

# Our MongoDB cluster (currently just one node).
cluster = digitalocean.DatabaseCluster("cluster", digitalocean.DatabaseClusterArgs(
 engine = "mongodb",
 version = "5",
 region = region,
 size = digitalocean.DatabaseSlug.D_B_1_VPCU1_GB,
 node_count = 1
))

# The database we'll use for our grocery list.
db = digitalocean.DatabaseDb("db", digitalocean.DatabaseDbArgs(
 name = "grocery-list",
 cluster_id = cluster.id
))

Now for the App Platform spec itself. Notice the digitalocean.App resource takes just one argument, spec, which defines all three of the components of the app: static site, service, and database. Both the static site and the service are configured to use the same GitHub repository (the sourceDir properties indicate their folders within the repository), and both are configured (via the deployOnPush flag) to be rebuilt and redeployed by DigitalOcean on every commit.

The service has a few additional settings that you can use to manage its runtime behavior and deployment topology as well. As in development, we’ll configure the service to listen on port 8000 and be available at /api—the entire app will ultimately be proxied transparently by an App Platform load balancer—and it’ll be powered by just one container instance, again using the least expensive performance settings:

// ...

// The App Platform spec that defines our grocery list.
const app = new digitalocean.App("app", {
 spec: {
 name: "grocery-list",
 region: region,

 // The React front end.
 staticSites: [
 {
 name: "frontend",
 github: {
 repo,
 branch,
 deployOnPush: true,
 },
 sourceDir: "/frontend",
 buildCommand: "npm install && npm run build",
 outputDir: "/dist",
 }
 ],

 // The Express back end.
 services: [
 {
 name: "backend",
 github: {
 repo,
 branch,
 deployOnPush: true,
 },
 sourceDir: "/backend",
 buildCommand: "npm install && npm run build",
 runCommand: "npm start",
 httpPort: 8000,
 routes: [
 {
 path: "/api",
 preservePathPrefix: true,
 },
 ],
 instanceSizeSlug: "basic-xxs",
 instanceCount: 1,

 // To connect to MongoDB, the service needs a DATABASE_URL, which
 // is conveniently exposed as an environment variable thanks to its
 // membership in this app spec (below).
 envs: [
 {
 key: "DATABASE_URL",
 scope: "RUN_AND_BUILD_TIME",
 value: "${db.DATABASE_URL}",
 },
 ],
 },
 ],

 // Include the MongoDB cluster as an integrated App Platform component.
 databases: [
 {
 // The name `db` defines the prefix of the tokens used (above) to
 // read the environment variables exposed by the database cluster.
 name: "db",

 // MongoDB clusters are only available in "production" mode.
 // https://docs.digitalocean.com/products/app-platform/how-to/manage-databases/
 production: true,

 // A reference to the `DatabaseCluster` we declared above.
 clusterName: cluster.name,

 // The engine value must be uppercase, so we transform it with JS.
 engine: cluster.engine.apply(engine => engine.toUpperCase()),
 }
 ]
 },
});

# ...

# The App Platform spec that defines our grocery list.
app = digitalocean.App("app", digitalocean.AppArgs(
 spec = digitalocean.AppSpecArgs(
 name = "grocery-list",
 region = region,

 # The React front end.
 static_sites = [
 digitalocean.AppSpecStaticSiteArgs(
 name = "frontend",
 github = digitalocean.AppSpecJobGithubArgs(
 repo = repo,
 branch = branch,
 deploy_on_push = True
 ),
 source_dir = "/frontend",
 build_command = "npm install && npm run build",
 output_dir = "/dist"
 )
 ],

 # The Express back end.
 services = [
 digitalocean.AppSpecServiceArgs(
 name = "backend",
 github = digitalocean.AppSpecJobGithubArgs(
 repo = repo,
 branch = branch,
 deploy_on_push = True
 ),
 source_dir = "/backend",
 build_command = "npm install && npm run build",
 run_command = "npm start",
 http_port = 8000,
 routes = [
 digitalocean.AppSpecServiceRouteArgs(
 path = "/api",
 preserve_path_prefix = True
 )
 ],
 instance_size_slug = "basic-xxs",
 instance_count = 1,

 # To connect to MongoDB, the service needs a DATABASE_URL, which
 # is conveniently exposed as an environment variable because the
 # database belongs to the app (see below).
 envs = [
 digitalocean.AppSpecServiceEnvArgs(
 key = "DATABASE_URL",
 scope = "RUN_AND_BUILD_TIME",
 value = "${db.DATABASE_URL}"
 )
 ]
 )
 ],

 # Include the MongoDB cluster as an integrated App Platform component.
 databases = [
 digitalocean.AppSpecDatabaseArgs(
 # The `db` name defines the prefix of the tokens used (above) to
 # read the environment variables exposed by the database cluster.
 name = "db",

 # MongoDB clusters are only available in "production" mode.
 # https://docs.digitalocean.com/products/app-platform/concepts/database/
 production = True,

 # A reference to the managed cluster we declared above.
 cluster_name = cluster.name,

 # The engine value must be uppercase, so we transform it with Python.
 engine = cluster.engine.apply(lambda engine: engine.upper())
 )
 ]
 ),
))

Technically that’s all we need to configure the application—but it wouldn’t be a bad idea to add one last thing.

By default, managed MongoDB clusters are configured to be publicly accessible—which is great if you need to be able to connect one yourself, but not so great as a strategy for preventing internet miscreants from doing the same. You can fix this easily by adding a DatabaseFirewall resource to declare the app as a trusted source, thereby rejecting all inbound traffic originating from elsewhere:

// ...

// Adding a database firewall setting grants access solely to our app.
const trustedSource = new digitalocean.DatabaseFirewall("trusted-source", {
 clusterId: cluster.id,
 rules: [
 {
 type: "app",
 value: app.id,
 },
 ],
});

# ...

# Adding a database firewall setting restricts access solely to our app.
trusted_source = digitalocean.DatabaseFirewall("trusted-source", digitalocean.DatabaseFirewallArgs(
 cluster_id = cluster.id,
 rules = [
 digitalocean.DatabaseFirewallRuleArgs(
 type = "app",
 value = app.id
 )
 ],
))

And finally, add one last line to export the app URL, to be generated by DigitalOcean, as a Pulumi stack output:

// ...

// The DigitalOcean-assigned URL for our app.
export const { liveUrl } = app;

# ...

# The DigitalOcean-assigned URL for our app.
pulumi.export("liveUrl", app.live_url)

With that, you’re ready to deploy.

Deploying

Quickly, to recap, here’s what we’ve done so far:

We took a pre-baked MERN app configured to run on localhost.
We mapped the tiers of that app to their corresponding App Platform components.
We wrote a Pulumi program to codify that mapping as an App Platform spec and a managed MongoDB cluster to go along with it.

When you deploy this app in a moment with pulumi up, Pulumi will provision a new MongoDB cluster (which usually takes a few minutes), and then once that’s available, DigitalOcean will take our spec and use it to fetch the components of the app from GitHub at the specified branch and build them. From that point forward, any commit you make to that branch will trigger DigitalOcean to fetch, rebuild, and redeploy the app automatically.

Make sure you’ve installed the DigitalOcean GitHub app as described above—you should see it listed at https://github.com/settings/installations:

Now return to the command line and run pulumi up:

$ pulumi up

Previewing update (dev)

View Live: https://app.pulumi.com/cnunciato/grocery-list/dev/previews/605bf32a-95b1-4221-bc35-0e667b30f38a

 Type Name Plan
 + pulumi:pulumi:Stack grocery-list-dev create
 + ├─ digitalocean:index:DatabaseCluster cluster create
 + ├─ digitalocean:index:DatabaseDb db create
 + ├─ digitalocean:index:App app create
 + └─ digitalocean:index:DatabaseFirewall trusted-source create

Resources:
 + 5 to create

Do you want to perform this update?
> yes

Updating (dev)

View Live: https://app.pulumi.com/cnunciato/grocery-list/dev/updates/1

 Type Name Status
 pulumi:pulumi:Stack grocery-list-dev
 + ├─ digitalocean:index:App app created
 + └─ digitalocean:index:DatabaseFirewall trusted-source created

Outputs:
 + liveUrl: "https://grocery-list-fb9bd.ondigitalocean.app"

Resources:
 + 2 created
 3 unchanged

Duration: 2m30s

Again, it’ll probably take a few minutes to get everything spun up for the first time, but when the process completes, you’ll have a working app at the URL provided by DigitalOcean, emitted as a Pulumi stack output:

$ open $(pulumi stack output liveUrl)

$ open $(pulumi stack output live_url)

You should also be able to explore your shiny new grocery-list app in the DigitalOcean Console, with all three of its components (and their build-time and runtime logs!) now represented:

Now try making a commit to your repository (any commit will do, but ideally one to the frontend or backend folder), and watch as the app redeploys automatically:

And finally, try scaling the service by bumping the instanceCount from 1 to 2 in the code—or better, if you’re up for it, making that value configurable by stack:

 const config = new pulumi.Config();
 const repo = config.require("repo");
 const branch = config.require("branch");
+ const serviceInstanceCount = config.requireNumber("service_instance_count");
 ...
 services: [
 digitalocean.AppSpecServiceArgs(
 ...
+ instanceCount: serviceInstanceCount,

 config = pulumi.Config()
 repo = config.require("repo")
 branch = config.require("branch")
+ service_instance_count = config.requireNumber("service_instance_count");
 ...
 services: [
 digitalocean.AppSpecServiceArgs(
 ...
+ instance_count: service_instance_count,

Set the instance count with pulumi config:

$ pulumi config set service_instance_count 2

Then deploy the new app spec with a final pulumi up:

$ pulumi up

Updating (dev)

 Type Name Status Info
 pulumi:pulumi:Stack grocery-list-dev
 ~ └─ digitalocean:index:App app updated [diff: ~spec]

Outputs:
 liveUrl: "https://grocery-list-fb9bd.ondigitalocean.app"

Resources:
 ~ 1 updated
 4 unchanged

Duration: 1m27s

And when you’re finished experimenting, you can tear everything down in just a few seconds with a pulumi destroy:

$ pulumi destroy

Destroying (dev)

 Type Name Status
 - pulumi:pulumi:Stack grocery-list-dev deleted
 - ├─ digitalocean:index:DatabaseFirewall trusted-source deleted
 - ├─ digitalocean:index:DatabaseDb db deleted
 - ├─ digitalocean:index:App app deleted
 - └─ digitalocean:index:DatabaseCluster cluster deleted

Resources:
 - 5 deleted

Duration: 19s

Wrapping up, and next steps

Hopefully this gives you a sense of the kinds of things you can do with Pulumi and DigitalOcean—and I definitely encourage you to spend a little time with the App Platform docs to dig a bit deeper into some of these concepts and explore a few others we weren’t able to cover. You’ll find the full source for this walkthrough on GitHub, of course, with finished branch containing the completed Pulumi program for reference.

From here, you might think about:

Adding a digitalocean.DnsRecord to give your app a custom domain name.
Creating a second stack with pulumi stack init and adjusting the program to make the source branch configurable—a production stack, say, designed to deploy in response to commits to a release branch.
Using Pulumi’s GitHub Action to run previews and updates as part of a pull-request based workflow.

Happy coding!

Executing Remote Commands with Pulumi

David Flanagan — Thu, 03 Feb 2022 22:10:00 +0000

We recently announced in our release blog (66) a new package: Command. In this article, I want to show you a practical application of this that will allow us to deploy k3s to a DigitalOcean Kubernetes droplet. We’ll then leverage the Command package to run a remote command to fetch the kubeconfig, generated on the VM, and pull it down to create a Kubernetes provider to deploy nginx.

So, let’s get started by deploying our DigitalOcean droplet.

The first thing we’re going to do is generate an SSH key for the machine.

const sshKey = new tls.PrivateKey("sshKey", {
 algorithm: "RSA",
 rsaBits: 4096,
});

// Optional export of the key in-case you want to store it on disk.
export const privateKey = sshKey.privateKeyPem;

// Register the SSH key with DigitalOcean
const doSshkey = new digitalocean.SshKey("sshKey", {
 publicKey: sshKey.publicKeyOpenssh,
});

Then we’ll want to create a cloud-init configuration to pass to the droplet as user-data.

const cloudConfig = cloudinit.getConfig({
 gzip: false,
 base64Encode: false,
 parts: [
 {
 contentType: "text/x-shellscript",
 content: fs.readFileSync("../cloud-init/ensure-curl.sh", "utf8"),
 },
 {
 contentType: "text/x-shellscript",
 content: fs.readFileSync("../cloud-init/install-k3s.sh", "utf8"),
 },
 ],
});

There’s nothing terribly fancy about these scripts, but we’ll share them anyway 😃

This first one makes sure that curl is available on the machine.

#!/usr/bin/env sh
# ../cloud-init/ensure-curl.sh
DEBIAN_FRONTEND=noninteractive apt update && apt install --yes curl

This script will fetch the public IPv4 address from the DigitalOcean metadata service and pass that IP address through to k3s installer as the listen/bind address. This ensures that our Kubernetes provider in the Pulumi program can speak with the API server.

#!/usr/bin/env sh
# ../cloud-init/install-k3s.sh
PUBLIC_IP=$(curl -w "\n" http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
curl -sfL https://get.k3s.io | sh -s - --bind-address ${PUBLIC_IP}

Now that we have some user-data, we can create a droplet and pass it through.

const k3sVm = new digitalocean.Droplet(
 "k3s",
 {
 name: "k3s",
 image: "ubuntu-20-04-x64",
 region: "lon1",
 size: "s-1vcpu-1gb",
 sshKeys: [civoSshKey.id],
 userData: cloudConfig.then((c) => c.rendered),
 },
 {
 replaceOnChanges: ["diskImage", "script"],
 }
);

Now, for the fun bit. Previously, there’d be no way to get the kubeconfig from the VM. Meaning that we’d need to use static manifests to deploy our workloads to k3s. This would usually be done by adding more and more scripts to the user-data and rendering them with cloud-init. This approach is not bad, but we lose the rich interface that Pulumi provides for authoring our Kubernetes resources. With the Command package, we can now execute a command on our VM and pull down that kubeconfig to be used to create our provider.

const fetchKubeconfig = new command.remote.Command("fetch-kubeconfig", {
 connection: {
 host: k3sVm.ipv4Address,
 user: "root",
 privateKey: sshKey.privateKeyPem,
 },
 create:
 // First, we use `until` to monitor for the k3s.yaml (our kubeconfig) being created.
 // Then we sleep 10, just in-case the k3s server needs a moment to become healthy. Sorry?
 "until [ -f /etc/rancher/k3s/k3s.yaml ]; do sleep 5; done; cat /etc/rancher/k3s/k3s.yaml; sleep 10;",
});

The Command package makes the stdout of the command we run available in our program, so creating the Kubernetes provider is as simple as:

const kubernetesProvider = new kubernetes.Provider("k3s", {
 kubeconfig: fetchKubeconfig.stdout,
});

Now, for the final step - deploying nginx.

const nginx = new kubernetes.apps.v1.Deployment(
 "nginx",
 {
 spec: {
 selector: {
 matchLabels: {
 app: "nginx",
 },
 },
 template: {
 metadata: {
 labels: {
 app: "nginx",
 },
 },
 spec: {
 containers: [
 {
 name: "nginx",
 image: "nginx",
 },
 ],
 },
 },
 },
 },
 {
 provider: kubernetesProvider,
 }
);

Simple.

The Command package works for local and remote commands and the possibilities are endless.

Happy hacking!

Manage DigitalOcean Kubernetes Clusters and Workloads

Joe Duffy — Mon, 30 Sep 2019 00:00:00 +0000

We recently partnered with DigitalOcean to publish a new tutorial, How to Manage DigitalOcean and Kubernetes Infrastructure with Pulumi. This short tutorial walks you through provisioning a new DigitalOcean Kubernetes cluster, deploying an application to it, and then assigninging a stable domain name to your application’s load balancer — all in a handful of lines of infrastructure as code.

By using infrastructure as code to provision and update your infrastructure, it’s easy to create new environments, modify or scale existing ones, or automate your deployments using continuous delivery. This approach also ensures that deployments are reliable and repeatable, and can even standardize how you deploy code to different cloud providers, including DigitalOcean, AWS, Azure, GCP, and others.

We regularly talk to developers who appreciate the simplicity of working with DigitalOcean. This new tutorial spins up an entire, fully functioning managed Kubernetes environment in just 6 minutes, for instance, giving you more time to focus on application logic and less on your infrastructure configuration. In addition to managing Kubernetes clusters and applications, you can also provision Droplets, LoadBalancers, and any other DigitalOcean resource type, using a similar infrastructure as code approach. For more information on doing so, read Getting Started on DigitalOcean with Pulumi.

Finally, for more detailed information on all of the DigitalOcean resources supported, please consult the DigitalOcean API docs.

Most importantly, have fun getting up and running with DigitalOcean Kubernetes in just a few minutes!

Getting Started on DigitalOcean with Pulumi

Paul Stack — Thu, 18 Jul 2019 00:00:00 +0000

Pulumi recently added support for managing DigitalOcean resources. This article will show you how to deploy some load balanced Droplets on DigitalOcean using Pulumi.

To get started, let’s create a new Pulumi program written in TypeScript:

 $ mkdir infra && cd infra
 $ pulumi new typescript

Now we should install the latest Pulumi DigitalOcean provider:

 $ npm install @pulumi/digitalocean

At the top of our application, we can add the resource imports:

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

We can now start to build the infrastructure. To get started, we will declare two constants:

const dropletCount = 3;
const region = digitalocean.Regions.NYC3;

Now, let’s create our web servers. Since our Pulumi application is written in TypeScript, we can use a loop, as follows:

const dropletTypeTag = new digitalocean.Tag("demo-app");
const userData =
 `#!/bin/bash
 sudo apt-get update
 sudo apt-get install -y nginx`;

const droplets = [];
for (let i = 0; i < dropletCount; i++) {
 let nameTag = new digitalocean.Tag(`web-${i}`);

 droplets.push(new digitalocean.Droplet(`web-${i}`, {
 image: "ubuntu-18-04-x64",
 region: region,
 privateNetworking: true,
 size: digitalocean.DropletSlugs.Droplet512mb,
 tags: [nameTag.id, dropletTypeTag.id],
 userData: userData,
 }));
}

Let’s take a closer look at what we’ve programmed. First, we declared a dropletTypeTag; we’ll come back to what this tag signifies later. Next, we have a userData constant that we can pass to all the instances, so that we can see they are running a web server. Then, we are declaring a nameTag constant. This allows us to use the interpolation in the loop to ensure that each of our Droplets is tagged with the appropriate name. We can also see that the region constant is being used in the Droplet declaration and we are adding the meta-information back to the Droplets array for later use.

Our next piece of infrastructure is our load balancer. We are going to create a public load balancer that will accept connections on port 80 and forward those connections to the Droplets that are attached on port 80. The infrastructure block looks like this:

const lb = new digitalocean.LoadBalancer("public", {
 dropletTag: dropletTypeTag.name,
 forwardingRules: [{
 entryPort: 80,
 entryProtocol: digitalocean.Protocols.HTTP,
 targetPort: 80,
 targetProtocol: digitalocean.Protocols.HTTP,
 }],
 healthcheck: {
 port: 80,
 protocol: digitalocean.Protocols.TCP,
 },
 region: region,
});

export const endpoint = lb.ip;

The configuration is made up of an array of forwarding rules. Here, we forward traffic from the load balancer to the Droplets. Then we have a health check that makes sure that port 80 is actually available and we deploy the load balancer into the region that we declared as a constant earlier. The interesting thing about load balancers in DigitalOcean is that you can attach instances by Droplet tag without knowing the Droplet IDs. Here, we configure all Droplets that have the tag demo-app, in this region, to be attached to the load balancer.

Running this gives us:

Updating (dev):

 Type Name Status
 + pulumi:pulumi:Stack do-ref-architecture-dev created
 + ├─ digitalocean:index:Tag web-0 created
 + ├─ digitalocean:index:Tag web-1 created
 + ├─ digitalocean:index:Tag web-2 created
 + ├─ digitalocean:index:Tag demo-app created
 + ├─ digitalocean:index:Droplet web-0 created
 + ├─ digitalocean:index:Droplet web-1 created
 + ├─ digitalocean:index:LoadBalancer public created
 + └─ digitalocean:index:Droplet web-2 created

Outputs:
 endpoint: "45.55.120.64"

Resources:
 + 9 created

Duration: 3m5s

You should be able to take the endpoint address and put it into the browser or you should be able to curl it as follows:

curl "$(pulumi stack output endpoint)"

We are constantly working on ways to make Pulumi more productive to use with DigitalOcean. Pulumi is free and open source. You can get started with Pulumi today at https://www.pulumi.com.