DEV Community: Tony Pujals

Create a blog with Deno 2 and Fresh

Tony Pujals — Mon, 07 Oct 2024 14:13:18 +0000

Fresh is the most popular web framework built on Deno. With the imminent Deno 2.0 launch, now is a great time to take a look at it. I give an updated dive into how to build a simple blog engine with it, based on Andy Jiang's original example.

Full details are here at the GitHub repo and this walkthrough.

Deploying a Fresh app to Cloud Run is straightforward, but want zero-config, managed deployments that are optimized on Google Cloud CDN infrastructure? Stay tuned for updates coming soon for deploying Fresh on Firebase App Hosting with deep integration for the latest Gemini API generative AI models and Data Connect.

Built-in TypeScript Support with Node.js

Tony Pujals — Tue, 24 Sep 2024 20:53:27 +0000

Node.js 22.6.0 adds a new option for lightweight TypeScript support.

What's nice about this is that it lets you maintain a simple JavaScript-type of workflow (no explicit intermediate transpilation step to generate JavaScript files from TypeScript source code) while coding in TypeScript for the benefits of static typing.

Deno and Bun.js already provide a native TypeScript experience so that you can skip the explicit transpiling step. But if you're using or plan to use Node.js 22.6.0 or later, you can also take advantage of this feature.

With the --experimental-strip-types option, you can skip the transpilation step and directly run your .ts files. But Node.js doesn't do any actual type checking — if you want those static typing benefits previously mentioned, that's the job of a type checking tool, like the TypeScript compiler (tsc).

I wrote a post on my personal blog that goes into more depth and walks through using the feature, while also supporting type checking and linting support as a developer dependency for coding.

https://codesnip.sh/posts/built-in-typescript-support-with-nodejs

Building Standalone Executables With Node.js

Tony Pujals — Tue, 24 Sep 2024 20:34:25 +0000

Node.js has experimental support for building a single executable application, or SEA, which is what the team calls a standalone executable that can be distributed to supported platforms.

The way the feature works is that a single blob is injected into the node binary for a supported platform. This single blob can be a JavaScript file, including multi-file JavaScript source that has been bundled with a tool like Webpack. If the blob is present, then the node binary will execute the script in the blob.

The recipe for building a SEA is spelled out in the docs.

Unfortunately, the developer experience is not yet on par with Deno or Bun.js. I wrote a build script to streamline building a SEA for Linux and Darwin targets and smooth out the experience. I also took a stab at the Windows target, although it's not tested.

The rest of the details are on my personal blog here:
https://codesnip.sh/posts/building-standalone-nodejs-executables

The script demonstrates using Webpack for bundling. I plan to also add esbuild and swc support, but you can just use the project as a starting point for your own project.

Command-Line Tools with Go: Piping Data

Tony Pujals — Tue, 24 Sep 2024 20:21:30 +0000

Unix is well-known for advocating the philosophy that commands should do one thing and do it well.

Sophisticated data processing and transformation operations can often be performed using the shell pipe operator to chain commands together so that the output of one becomes the input of another, manipulating and transforming data to achieve a desired result.

For example:

# Sort file names.
ls | sort

# Count files.
ls -l | count -l

# Print out unique file extensions.
#  1. List all files that have extensions
#  2. Transform the data (discard everything but extensions)
#  3. Sort the list (data must be sorted to identify duplicates)
#  4. Filter out duplicates
#  5. Browse the results
ls *.* | sed 's/.*\.//' | sort | uniq | less

With Go, programmers can create efficient and performant commands for processing data. We'll touch on this with the following snippets.

Add line numbers to output

The essence of a command that can be used in a pipe operation is that it reads from stdin and writes to stdout.

add-line-numbers.go

package main

import (
    "bufio"
    "fmt"
    "os"
)

func main() {

    // Buffered input that splits input on lines.
    input := bufio.NewScanner(os.Stdin)

    // Buffered output.
    output := bufio.NewWriter(os.Stdout)

    lineNo := 0

    // Scan until EOF (no more input).
    for input.Scan() {
        text := input.Text()
        lineNo++
        s := fmt.Sprintf("%03d %s\n", lineNo, text)

        // It would be simpler to just use fmt.Println,
        // but want to emphasize piping stdin to stdout
        // explicitly.
        // Intentionally ignoring return values.
        _, _ = output.WriteString(s)

    }

    // Always explicitly flush remaining buffered output.
    _ = output.Flush()
}

This example reads a line at a time from stdin and writes it back out to stdout with each line prefixed with the line number. Here, we use the program file itself as the input to generate numbered output.

$ cat add-line-numbers.go | go run add-line-numbers.go
001 package main
002 
003 import (
004     "bufio"
005     "fmt"
006     "os"
007 )
008 
009 func main() {
010 
011     // Buffered input that splits input on lines.
012     input := bufio.NewScanner(os.Stdin)
013 
014     // Buffered output.
015     output := bufio.NewWriter(os.Stdout)
016 
017     lineNo := 0
018 
019     // Scan until EOF (no more input).
020     for input.Scan() {
021         text := input.Text()
022         lineNo++
023         s := fmt.Sprintf("%03d %s\n", lineNo, text)
024 
025         // It would be simpler to just use fmt.Println,
026         // but want to emphasize piping stdin to stdout
027         // explicitly.
028         // Intentionally ignoring return values.
029         _, _ = output.WriteString(s)
030 
031     }
032 
033     // Always explicitly flush remaining buffered output.
034     _ = output.Flush()
035 
036 }

Base64 encode input

This example reads a line at a time from stdin, base64 encodes it, and writes it back out to stdout.

package main

import (
    "bufio"
    "encoding/base64"
    "os"
)

func main() {

    // Buffered input that splits input on lines.
    input := bufio.NewScanner(os.Stdin)

    // Base64 Encoder/writer.
    encoder := base64.NewEncoder(
        base64.StdEncoding,
        os.Stdout)

    // Scan until EOF (no more input).
    for input.Scan() {
        bytes := input.Bytes()
        _, _ = encoder.Write(bytes)
        _, _ = encoder.Write([]byte{'\n'})
    }

    // Close the encoder and ensure it flushes remaining output
    _ = encoder.Close()
}

Since the scanner splits on newline characters (\n) without returning them, it's necessary to explicitly write a newline after writing each line.

$ cat base64-encode.go | go run base64-encode.go
cGFja2FnZSBtYWluCgppbXBvcnQgKAoJImJ1ZmlvIgoJImVuY29kaW5nL2Jhc2U2NCIKCSJvcyIKKQoKZnVuYyBtYWluKCkgewoKCS8vIEJ1ZmZlcmVkIGlucHV0IHRoYXQgc3BsaXRzIGlucHV0IG9uIGxpbmVzLgoJaW5wdXQgOj0gYnVmaW8uTmV3U2Nhbm5lcihvcy5TdGRpbikKCgkvLyBCYXNlNjQgRW5jb2Rlci93cml0ZXIuCgllbmNvZGVyIDo9IGJhc2U2NC5OZXdFbmNvZGVyKAoJCWJhc2U2NC5TdGRFbmNvZGluZywKCQlvcy5TdGRvdXQpCgoJLy8gU2NhbiB1bnRpbCBFT0YgKG5vIG1vcmUgaW5wdXQpLgoJZm9yIGlucHV0LlNjYW4oKSB7CgkJYnl0ZXMgOj0gaW5wdXQuQnl0ZXMoKQoJCV8sIF8gPSBlbmNvZGVyLldyaXRlKGJ5dGVzKQoJCV8sIF8gPSBlbmNvZGVyLldyaXRlKFtdYnl0ZXsnXG4nfSkKCX0KCgkvLyBDbG9zZSB0aGUgZW5jb2RlciBhbmQgZW5zdXJlIGl0IGZsdXNoZXMgcmVtYWluaW5nIG91dHB1dAoJXyA9IGVuY29kZXIuQ2xvc2UoKQp9Cg==

You can confirm the text was correctly encoded by piping the encoded result to the system base64 command (Linux and MacOS) to decode it:

$ cat base64-encode.go | go run base64-encode.go | base64 -D
package main

import (
    "bufio"
    "encoding/base64"
    "os"
)

func main() {

    // Buffered input that splits input on lines.
    input := bufio.NewScanner(os.Stdin)

    // Base64 Encoder/writer.
    encoder := base64.NewEncoder(
        base64.StdEncoding,
        os.Stdout)

    // Scan until EOF (no more input).
    for input.Scan() {
        bytes := input.Bytes()
        _, _ = encoder.Write(bytes)
        _, _ = encoder.Write([]byte{'\n'})
    }

    // Close the encoder and ensure it flushes remaining output
    _ = encoder.Close()
}

This post is an excerpt from a short, introductory guide I wrote on standard library features of Go that are useful for creating command line tools: Go for CLI Apps and Tools.

Cloud Run - basic logging for your TypeScript app

Tony Pujals — Fri, 01 Dec 2023 23:21:45 +0000

In the previous article, you deployed your TypeScript app to Cloud Run.

Cloud Run will capture basic logs based on what you print to stdout and stderr, generally what you write using console.log and console.error.

After deploying the app, you can use a new gcloud command that's currently in beta to read or even tail your logs.

First, ensure you've got beta support:

gcloud components install beta

Or, if you already had it installed, but just want to update:

gcloud components update

Now you can read your logs:

gcloud beta run services logs read [SERVICE] \
  --project=[PROJECT] \
  --region=[REGION] \
  --limit=10

You should see something like this:

You can also tail your logs:

gcloud beta run services logs tail blogdemo --project javascript-demos

And, of course, now every time you send a request, you'll see a log entry print to your terminal, similar to this:

For the project that you generated in the previous article, update the logs and logs:tail scripts in package.json with the values you used for deploy:

[SERVICE] - the name of your service
[PROJECT] - your cloud project ID
[REGION] - the region you deployed to

Then you can run either npm logs or npm logs:tail.

In the next article, you'll see how you can get more value out of your logs using structured logging, which among other things, will help you correlate logs by HTTP request.

Cloud Run - TypeScript boilerplate for getting started

Tony Pujals — Fri, 01 Dec 2023 22:27:57 +0000

My goal for this article is to help you get started writing TypeScript apps that you can deploy to Cloud Run.

Because Google Cloud documentation is tailored primarily for JavaScript, it's not necessarily clear to developers that you can write TypeScript and deploy from source code to Cloud Run as long as you your package.json has the following two run scripts:

build
start

So if you just want to add a tsconfig.json, use tsc in the build script to transform TypeScript to JavaScript, and indicate which JavaScript file to run in your start script, then all you need to do to deploy a public service from your source is run the following:

gcloud run deploy [SERVICE] \
  --project [PROJECT] \
  --region [REGION] \
  --allow-unauthenticated \
  --source .

But I'd like to help you more than that. I've created a repo (cloud-run-app) that contains boilerplate for a starter project.

You don't need to clone the repo. You can generate a new app on your machine with the following command:

npx create-cloud-run-app [PATH]

If path isn't specified, it defaults to the current working directory (.)
The directory under PATH must be empty

The goal for this generator is to give you a bit of opinionated structure, but not too much:

Your TypeScript code goes under src
Your tests (*.test.ts) can go under src or test
Your generated output goes under dist

I use Express and Jest, but only enough to give you something to start with. You can substitute these out for your favorite web and test framework.

In fact, Express is the only one of two dependencies (the other is a cloud logging library). All the other dependencies are devDependencies and they are there to provide you with comprehensive compiling, testing, linting, and formatting support.

This is arguably the real value of using this boilerplate, since configuring the integration of TypeScript, editorconfig, eslint, prettier, and Jest so that everything plays well together is a bit challenging.

For me, it's been a cumulative effort over various projects this past year, but if I had to pin down the effort, I feel that it took days or even a week of toil banging at configuration.

Side note: I'm totally open to any suggestions if you see ways to improve the configuration. Although you can leave comments below, it would be even better to open an issue or start a discussion in the repo.

Go ahead and inspect the generated package.json (or run npm run-script), but you these are the main scripts to be aware of:

build
test | test:watch
deploy

Trying it out

First run npm test to verify the very simple integration smoke tests pass.

Then, if you haven't already gotten set up with a Google Cloud project so you can deploy to Cloud Run, go see the previous article: Cloud Run - getting started checklist.

Once you have a cloud project, update the .cloudconfig file in your generated project.

Note: if you want to update .cloudconfig, but not accidentally commit it, then make a copy and call it cloudconfig. This is automatically ignored by .gitignore. Going forward, I'll assume you did this and just refer to cloudconfig.

You'll need to set the following variables:

SERVICE - with the name for your service
PROJECT - with your cloud project ID
REGION - with the region to deploy to

After updating cloudconfig, source the variables into your bash environment:

source cloudconfig

Then run:

npm run deploy

Answer yes to any prompts about enabling APIs and creating a repo in the project to store the app container image.

You should see output similar to this:

The last line of output contains the service URL. Go ahead and open the link in a browser. You should see an "ok" response.

Congratulations, you have a starter project configured for TypeScript that you can deploy to Cloud Run.

In the next article, add cloud logging support.

Cloud Run - getting started checklist

Tony Pujals — Fri, 01 Dec 2023 22:26:55 +0000

To get started developing for Cloud Run, you need to take of a number of administrative steps first.

I've edited the original article to move the Recap to the top and rename it to Checklist. This is all you need. The rest of the article is here to provide you with extra detail if it's your first time running through the checklist.

Checklist

Sign in with a Google account
Create a billing account

Set up your machine

Install the Google Cloud CLI

Set up a cloud project

Log in at the terminal:

gcloud auth login
Create a project

gcloud projects create PROJECT_ID
Link the project to a billing account

gcloud billing projects link PROJECT_ID --billing-account ACCOUNT_ID
Delete the project when no longer needed

gcloud projects delete PROJECT_ID

Checklist walkthrough

The Cloud Run Documentation is the ultimate source of truth, but I created this article as a checklist to help developers who are new to the platform get set up for a following series of Cloud Run blog posts that will refer to this as a prerequisite.

Sign up for GCP
Set up your machine
Set up a cloud project

Sign up for GCP

To use GCP, you'll need to sign up:

Sign in with a Google account
Create a billing account

Sign in with a Google account

Go to Google Cloud Platform, click Get started for free, and sign in with a Google account. If you don't already have a Google account, then click Create account and follow the prompts.

When you activate a GCP account, you get access to both of the following:

Currently, the Free Trial provides $300 of Cloud Billing credits to pay for resources for ninety days while you explore GCP.

The Free Tier provides access to GCP products for free beyond the free trial as long as you stay below the Free Tier usage limits.

For more details, see Google Cloud Free Program.

Create a billing account

If you use the free trial, Google creates a billing account for you and applies the free credits to your account.

Once the free trial period ends, you can continue to use the free tier, but you're required to set up a billing account to cover any costs that exceed free tier usage limits.

If you need to create a billing account, go to Billing in the console.

Set up your machine

The gcloud CLI is a useful tool that is available online in the Cloud Shell terminal, but since most developers like to work with editors on their own machines, I highly encourage you to install the Google Cloud CLI on your own machine as well.

Set up a cloud project

A cloud project refers to the set of cloud infrastructure (compute, databases and other storage, load balancers, etc.), resources (container images, secrets, static assets, etc.), and security controls for your application (or collection of related applications).

When you create a new cloud project, follow these steps:

Log in at the terminal
Create a project
Link the project to a billing account
Delete the project when finished

Log in at the terminal

gcloud auth login

Create a GCP project

If you already have a specific GCP project to use, you can skip this.

Once you're logged in, you can create a new GCP project using the gcloud projects create command.

This is the command to create a project called project-foo:

gcloud projects create project-foo

There are a few things to keep in mind when choosing a project ID. The project ID must:

Be globally unique within Google Cloud.
Be 6 to 30 characters long.
Only contain lowercase letters, numbers, and hyphens.
Start with a letter and must not end with a hyphen.
Not be or have ever been in use.
Not contain restricted strings.

See the Before you begin section for Google Cloud's Resource Manager if you want to see more details and further restrictions.

Link the project to a billing account

If you're using an existing project that already has billing linked to it, you can skip this.

Once you've created the project, you must link it to a billing account. You can find your billing account ID on your billing accounts page.

gcloud billing projects link my-amazing-project --billing-account 0X0X0X-0X0X0X-0X0X0X

Delete the project when no longer needed

If you're creating a test project, you'll want to remember to delete it when you're finished. Deleting a project will terminate or release resources associated with it so they no longer incur any potential usage fees.

Using the example project (project-foo) created previously:

gcloud projects delete project-foo

Caution!

It should go without saying that you want to be really sure you want to delete a project. A deleted project immediately becomes unusable, although it can be restored within a 30-day recovery period. See Restoring a project if you need to stop the delete process.

In the next article, get started generating the TypeScript boilerplate and deploy to Cloud Run.

Create and deploy an Express API to Cloud Run

Tony Pujals — Wed, 04 Jan 2023 19:24:57 +0000

Overview

In this article, I'm going to walk you through quickly generating either a basic starter Express API app or a simple example Express API app and deploying it to Cloud Run.

Prerequisites

See the prerequisites for using run, a lightweight CLI for creating and deploying Cloud Run apps here.

Create the app

Choose either express-api or example-express-api when asked to choose a project template. The example version demonstrates using various Express methods for a mock database.



run create

Selecting a template

When finished

You can run the app locally, if you want.

Deploy the app

To deploy to Cloud Run, enter:



run deploy

Since this is the first deployment, you'll be presented with a series of prompts. Your settings will be saved to a a local configuration file (run.yaml).

Note: In the current version of run, only the new project option works.

Test the app

When the deployment is finished, the run will print the URL for accessing the app.

If you chose example-express-api, the README includes instructions about testing the API using curl commands in a test script.

View app logs

To get the link to view the logs web page, enter:



run logs

Wrapping up

The run command to delete the project when finished is not yet implemented. For now, use gcloud to delete the project using its ID (if you forget the project ID, it's stored in run.yaml).



gcloud projects delete PROJECT

If you run into any problems, check to see if there is an issue here and, if not, please create one.

References

I provide background on run in my last article.

If you prefer to use gcloud, see this article if you need help getting started. You'll still use run to create the app from a template.

Streamlining gcloud with a custom CLI for serverless JavaScript developers

Tony Pujals — Wed, 04 Jan 2023 17:33:17 +0000

Overview

In my previous article, I walked through using the Google Cloud CLI interactive shell for deploying serverless apps to Cloud Run.

As noted, gcloud provides comprehensive commands, but using it involves fairly detailed knowledge of a somewhat daunting number of steps that must be followed to set up project resources and deploy an app.

To simplify the experience for JavaScript developers, I created a lightweight CLI, called run, that streamlines those steps using a simple configuration file (run.yaml) to handle all the details. When you deploy, run will prompt for any missing configuration settings and save them for subsequent deployments.

In addition, the run CLI can also generate starter projects and examples to help you get up and running even faster.

To create and deploy an application, you run the following commands:



run login
run new
run deploy

This what using run looks like:

I plan to add more templates, examples, and support for integrations with other Google Cloud services.

Keep in mind that run is not a replacement for everything that gcloud can do. It's primary goal is only to make it easier for JavaScript developers to get up and running on Cloud Run.

Install it from npm:



npm install -g @subfuzion/run

# or

npx @subfuzion/run

See the repo for more details.

Give run a try and let me know what you think.

Getting started with the Google Cloud CLI interactive shell for serverless JavaScript developers

Tony Pujals — Mon, 31 Oct 2022 14:00:00 +0000

Overview

Aspiring JavaScript wizards might think conjuring serverless apps on Google Cloud with the CLI is an arcane art. But becoming an adept is easier than you think and you don't even need to attend a School of Witchcraft and Wizardry.

In this article, I'm going to show you what you need to know to deploy a single Cloud Run app from the command line – the stuff you'll need to do once, stuff you need to do for each project, and stuff you'll need to do for each app.

Stuff you need to do once
1. Sign up for a Google Account
2. Enable billing
3. Install the Google Cloud CLI
  - Enable gcloud interactive shell
Stuff you need to do for each project
1. Log in
2. Create your Google Cloud project
3. Link your project to a billing account
4. Configure your Google Cloud project
5. Enable Google Cloud service APIs
6. Create a Docker repo for your apps
Stuff you need to do for each app
1. Activate your project
2. Deploy your app
Try everything out with a demo
What's next?

This article will be part of a series on serverless development for JavaScript programmers, but the information here should be helpful for any developer who wants to get up and running with gcloud.

Stuff you need to do once

1. Sign up for a Google Account

You can sign up here.

Once you have an account, you'll have access to both

a Free Trial
a Free Tier

The Free Trial provides $300 of Cloud Billing credits to pay for resources for 90 days while you learn about Google Cloud.

The Free Tier provides access to Google Cloud products for free beyond the Free Trial as long as you stay below the Free Tier limits.

2. Enable billing

If you're using the Free Trial, Google creates a billing account for you and credits $300 to your account.

Once your Free Trial ends, you can continue to use the Free Tier, but you'll still need to enable a billing account.

3. Install the Google Cloud CLI

While you might find that using the Google Cloud online console or Cloud Shell environment meets your occasional needs, for maximum developer efficiency you will want to install the Google Cloud CLI (gcloud) on your own system where you already have your favorite editor or IDE and git set up.

Enable gcloud interactive shell

Once you have downloaded and extracted the archive to google-cloud-sdk directory and added it to your path, then you can then enable the gcloud interactive prompt. This feature is for bash, so you will either need to start a bash shell or else use gcloud without the interactive prompt.

This is a beta feature, so to enable it, enter the following command.

gcloud components install beta

The interactive prompt makes it easier to work with gcloud commands in your shell by providing menus for command completion along with contextual help.

Enter the following command.

gcloud beta interactive

Your shell should look something like this now:

Note the tips provided for command completion.

I like to use an alias for launching the interactive shell. You can create an alias (like gshell) with the alias command:

alias gshell="gcloud beta interactive"

Stuff you need to do for each project

In this context, a project specifically refers to the collection of cloud infrastructure and application resources you will provision and deploy on Google Cloud.

You can deploy multiple Cloud Run apps (services) as part of the same project.

1. Log in

You might have several accounts, or your login has expired, or this is your first login. In any case, you can login with the following command:

gcloud auth login

This will open a page using your web browser. Confirm that the page is a link under https://accounts.google.com/ and authorize the Google Cloud SDK to be able to access your Google account. After that, you can close the page. Back in your shell, you should see confirmation that you've logged in like this:

2. Create your Google Cloud project

If you already have a specific Google Cloud project to use, you can skip this section and go on to 3. Link your project to a billing account.

Once you're logged in, you can create or specify an existing Google Cloud project to use and configure locally.

gcloud projects create my-amazing-demo-1

Note: If you're creating a project as part of an organization, you'll need to know the Folder ID that your project should be under. Discussing organization accounts is beyond the scope of this article, but you can learn more here. The command to create the project has an option for providing the Folder ID: gcloud projects create [PROJECT_ID] --folder [FOLDER_ID].

3. Link your project to a billing account

Once you've created the project, you must link it to a billing account (see 2. Enable billing). You can find your billing account ID on your billing accounts page.

gcloud beta billing projects link my-amazing-demo-1 --billing-account 0X0X0X-0X0X0X-0X0X0X

As you might have noticed in the image above, I have my billing account ID saved in a shell variable.

4. Configure your Google Cloud project

Now you can configure settings for your current project so that you don't need to specify them as options each time you run a gcloud command.

Although you can set default settings, I highly recommend that you create named, project-specific configurations to make switching between projects easier. I also recommend that you give the configuration the same name as the project to help you remember the association when listing or switching configurations, as shown below.

Common settings for Cloud Run projects shown below include the project ID, run/region you want to deploy your app to, and artifacts/location (same thing as region) for your project's Docker repository (for storing the images for launching Cloud Run service containers for your apps).

gcloud config configurations create my-amazing-demo-1
gcloud config set account YOUR_ACCOUNT_EMAIL
gcloud config set project PROJECT_ID
gcloud config set run/region REGION
gcloud config set artifacts/location REGION

To view your current configuration values:

gcloud config list

To list all of your configurations:

gcloud config configurations list

5. Enable Google Cloud service APIs

You will need to enable a few common Google Cloud service APIs for your project to be able to build, store, and deploy Cloud Run apps.

To build Docker container images for your serverless apps, you need to enable Cloud Build.
To store the Docker container images you'll need to launch serverless app containers on Cloud Run, you need to enable Artifact Registry.
To launch and scale your serverless app containers, you need to enable Cloud Run.

These services all expose APIs that you will use through gcloud commands.

Enter the following commands:

gcloud services enable cloudbuild.googleapis.com
gcloud services enable artifactregistry.googleapis.com
gcloud services enable run.googleapis.com

In addition to these APIs, Google provides many other APIs for hosting your apps (such as Cloud Functions) or for being used programmatically to facilitate building your apps (Memorystore, Pub/Sub, etc.). Take a look at the API Library and the API Explorer.

6. Create a Docker repo for your apps

After the Artifact Registry API has been enabled, you create a project-specific Docker container repository. The benefits of doing this is that your container repository will be in the same physical region as your Cloud Run apps under the same security policies as the rest of your project.

The following command assumes you'll name your Docker container registry as docker-repo.

gcloud artifacts repositories create docker-repo --repository-format=docker

Stuff you need to do for each app

1. Activate your project

Confirm that you're using the right project configuration and if not, then activate (switch to) it.

You can confirm that you're using the right project with either of the following two commands.

List all configurations and indicate which one is active (IS_ACTIVE column):

gcloud config configurations list

List current settings and tell you the active configuration currently in use:

gcloud config list

If the configuration for the project you want to use is not currently active, then activate it with this command:

gcloud config configurations activate PROJECT

This assumes you're using the convention I recommended previously where your configuration has the same name as your Google Cloud project ID.

The interactive shell displays the active project as well:

2. Deploy your app

At this point you can finally deploy your app with a single command:

gcloud run deploy SERVICE_NAME --source=. --allow-unauthenticated

The --source=. option tells gcloud to deploy from the current directory.

The --allow-unauthenticated option tells gcloud to make your app URL publicly available when it deploys.

Try everything out with a demo

First, make sure you've taken care of all the stuff you need to do once.

Then, using your own shell, take care of the stuff you need to do for each app, as shown in the example below.

Note: Give your project a unique name and choose a region from one of these Cloud Run locations. Remember, you don't pay for anything during the free trial and even after that as long as your usage doesn't exceed the Cloud Run pricing rather generous quotas (CPU, memory, requests) for the free tier.

# Substitute with your own shell variable values
$ BILLING_ACCOUNT=0X0X0X-0X0X0X-0X0X0X
$ ACCOUNT=me@gmail.com
$ PROJECT=cloud-run-hello-app-demo
$ REGION=us-central1
$ SERVICE=hello

$ gcloud auth login
...

$ gcloud projects create $PROJECT
...

$ gcloud beta billing projects link $PROJECT --billing-account $BILLING_ACCOUNT
...

$ gcloud config configurations create $PROJECT
$ gcloud config set account $ACCOUNT
$ gcloud config set project $PROJECT
$ gcloud config set run/region $REGION
$ gcloud config set artifacts/location $REGION
....

$ gcloud services enable cloudbuild.googleapis.com
$ gcloud services enable artifactregistry.googleapis.com
$ gcloud services enable run.googleapis.com
...

$ gcloud artifacts repositories create docker-repo --repository-format=docker

Now deploy your server code. You can clone this repo for a simple demo:

https://github.com/subfuzion/cloud-run-hello-app-demo

$ git clone https://github.com/subfuzion/cloud-run-hello-app-demo.git
$ cd cloud-run-hello-app-demo

$ gcloud run deploy $SERVICE --source=. --allow-unauthenticated
This command is equivalent to running `gcloud builds submit --pack image=[IMAGE] .` and `gcloud run deploy hello --image [IMAGE]`

Building using Buildpacks and deploying container to Cloud Run service [hello] in project [cloud-run-hello-app-demo] region [us-central1]
✓ Building and deploying new service... Done.
  ✓ Uploading sources...
  ✓ Building Container... Logs are available at https://console.cloud.google.com/cloud-build/builds/d71d846a-782d-4161-bbfa-a3f289ae669a?project=243539805744].
  ✓ Creating Revision...
  ✓ Routing traffic...
  ✓ Setting IAM Policy...
Done.
Service [hello] revision [hello-00001-wek] has been deployed and is serving 100 percent of traffic.
Service URL: https://hello-5maonkvcja-uc.a.run.app

Presto! If all went well, your app is deployed at the Service URL, like shown above. If not, you'll need to investigate using the link to the build log shown instead.

What's next?

While deploying an app is easy, there's no denying that there's quite a bit of administrative effort involved up front to get to that point. Although we're focused on serverless apps, Google Cloud provides many different services for running your workloads at planet scale along with a robust security model for enforcing enterprise policies that does add complexity even for modest needs.

In the next article in this series, we're going to show you how you can wrap most of these steps in a Node.js command-line app that you can use for your projects to streamline the effort.

We'll accomplish this in two stages, first wrapping gcloud shell commands, and then refactoring to use the Node.js Cloud Client Library to invoke the necessary Google Cloud APIs directly. Once you see how this works, you'll be able to tailor the command-line app to suit your own specific needs as they evolve.

After that, we're going to continue on our journey as you delve into all kinds of mysterious but wonderfully powerful magic for running your serverless JavaScript full-stack and back-end apps.

There may be dragons!

If you found this article helpful, give it a like and bookmark it. If you have any questions or suggestions, let me know in the comments. Then give me a follow and get notified when I publish the next article in the series. Stay tuned!

DEV Community: Tony Pujals

Create a blog with Deno 2 and Fresh

Built-in TypeScript Support with Node.js

Building Standalone Executables With Node.js

Command-Line Tools with Go: Piping Data

Add line numbers to output

Base64 encode input

Cloud Run - basic logging for your TypeScript app

Next

Cloud Run - TypeScript boilerplate for getting started

Trying it out

Next

Cloud Run - getting started checklist

Checklist

Checklist walkthrough

Sign up for GCP

Sign in with a Google account

Create a billing account

Set up your machine

Set up a cloud project

Log in at the terminal

Create a GCP project

Link the project to a billing account

Delete the project when no longer needed

Next

Create and deploy an Express API to Cloud Run

Overview

Prerequisites

Create the app

Deploy the app

Test the app

View app logs

Wrapping up

References

Streamlining gcloud with a custom CLI for serverless JavaScript developers

Overview

Getting started with the Google Cloud CLI interactive shell for serverless JavaScript developers

Overview

Contents

Stuff you need to do once

1. Sign up for a Google Account

2. Enable billing

3. Install the Google Cloud CLI

Enable gcloud interactive shell

Stuff you need to do for each project

1. Log in

2. Create your Google Cloud project

3. Link your project to a billing account

4. Configure your Google Cloud project

5. Enable Google Cloud service APIs

6. Create a Docker repo for your apps

Stuff you need to do for each app

1. Activate your project

2. Deploy your app

Try everything out with a demo

What's next?