Serve public traffic with ALB

Instances have private IPv6 addresses only, so the internet can’t reach them directly. --http-port is the quickest way to attach an ALB to a workload: it declares the port your container serves HTTP on and creates an HTTPProxy for the workload. Datum terminates TLS at the ALB, sends each request to the nearest location with a healthy Instance, and connects to your Instances over plain HTTP on your private network.

Compute is in preview, and the v1alpha API can change.

Before you begin

Select a project, install the compute plugin, and get access to Compute. For more information, see Compute commands.
Make sure that you have permission to create networking resources in the project, in addition to compute resources. The Network Admin role includes the permissions that publishing needs. The Gateway Admin role alone isn’t enough.
Make sure that your app serves plain HTTP, not HTTPS, on the port that you publish, and listens on IPv6.

Attach an ALB with datumctl

To attach an ALB to a workload, run datumctl compute deploy with --http-port:

datumctl compute deploy WORKLOAD_NAME \
  --image=IMAGE \
  --location=LOCATION \
  --http-port=PORT

Replace the following:

WORKLOAD_NAME: the name of your workload.
IMAGE: the full image reference, including the registry host.
LOCATION: one or more locations, separated by commas.
PORT: the port that your container serves HTTP on, such as 8080.

--http-port works when you create a workload and when you update one that you deployed with flags.

A flag-based datumctl compute deploy replaces the workload’s whole template and placements with what the flags describe. It keeps environment variables, ConfigMap and Secret imports, volumes, and labels. It removes registry credentials, custom commands, and extra placements that you set in a manifest, and it sets the Instance count to the --min value, which defaults to 1. To publish a workload that you manage with a manifest, see Publish a workload you manage with manifests.

The command declares the port on the container, waits for the rollout, and then prints the publishing progress and the ALB’s hostname as the last line of output:

Publishing...
  Backends     2 healthy across us-central-1, us-east-1
  Edge         programmed
  Certificate  issued

  https://stark-raven-b7k2m.datumproxy.net

Your hostname is different. A new hostname can take a few minutes to resolve. If a request fails with a name resolution error, wait and try again. If you press Control+C while the command publishes, publishing continues in the background. If your app speaks HTTP/2, such as a gRPC server, also add --http2 to the command, and serve HTTP/2 without TLS (h2c) on PORT. Without the flag, Datum connects to your Instances over HTTP/1.1, which most apps expect. gRPC needs HTTP/2 on every connection, so with the flag, Datum connects to your Instances over HTTP/2 too. Clients connect to the ALB hostname on port 443, such as grpcurl stark-raven-b7k2m.datumproxy.net:443 list. Later deploys keep the setting, and --http2=false turns it off.

Find your workload’s ALB hostname

To see the ALB hostname of every workload in your project, run the following command:

datumctl compute workloads

The hostname is in the URL column. To see the hostname and the health of the Instances behind it in each location, run the following command:

datumctl compute workloads describe WORKLOAD_NAME

In the Cloud Portal, a workload’s Overview tab shows its hostname, and a topology of the ALB in front of the workload and its Instances in each location, with live traffic, error rate, and latency.

A workload Overview tab showing Serving normally, and a topology diagram linking the load balancer, with traffic, errors, p99 latency, and hostname, to the workload, with 6 of 6 Instances ready across 3 locations — A published workload: its ALB, the workload, and its Instances in each location

If you have jq installed, you can read the hostname in a script. Run the following command:

datumctl compute workloads -o json | jq -r '.[] | select(.name=="WORKLOAD_NAME") | .url'

Replace WORKLOAD_NAME with the name of your workload.

Change or remove the ALB

The ALB keeps its hostname when you redeploy the workload. If you run datumctl compute deploy without --http-port, the workload keeps its current port and the ALB keeps its hostname. To change or remove the ALB, do one of the following:

To serve on a different port, run datumctl compute deploy again with the new --http-port value. The hostname stays the same.
To stop serving the workload publicly, run datumctl compute deploy with --no-http. This removes the ALB, and the hostname stops responding.

Datum generates the hostname when it creates the ALB. If you remove the ALB and publish again, the workload gets a new hostname. datumctl compute destroy removes the workload’s ALB along with the workload and its Instances. A plain datumctl delete workload deletes the workload and its Instances, but leaves the ALB in place. For more information, see Delete a workload.

Use a custom domain

You can serve a published workload on your own domain, such as api.example.com, in addition to its generated hostname. The ALB is an HTTPProxy resource named after the workload. For more on custom hostnames, TLS, and WAF protection, see ALB. To add a custom domain, follow these steps:

Add and verify your domain in Datum. For more information, see Domains.
To open the workload’s HTTPProxy for editing, run the following command:
datumctl edit httpproxy WORKLOAD_NAME
Replace WORKLOAD_NAME with the name of your workload.
Add your hostname to spec.hostnames, and then save and close the file:
spec: hostnames: - api.example.com
Point your hostname at the workload’s generated hostname with a CNAME record. If Datum hosts your DNS, see Point a domain at a load balancer.

datumctl compute deploy keeps custom hostnames when it updates a workload. datumctl compute destroy removes the ALB, including its custom hostnames, but keeps your domain resources.

Publish a workload you manage with manifests

A workload manifest can’t declare an ALB, and datumctl compute deploy -f doesn’t create or remove one. To attach an ALB to a manifest-managed workload, follow these steps:

Create the workload with datumctl compute deploy and --http-port, as described in Attach an ALB with datumctl. The command saves the workload to workload.yaml in the current directory.
Rename workload.yaml, and make your changes in the renamed file. Keep the container port that you published.
To apply later changes, run datumctl compute deploy -f FILE, where FILE is the path to your manifest. The workload keeps its ALB.

Limitations

In addition to the limitations that apply to all of Compute, the ALB has the following limitations:

Clients always connect over HTTPS. Datum connects to your Instances over plain HTTP, and TLS between Datum and your Instances isn’t supported.
datumctl compute deploy attaches one ALB to each workload, on one port.
With --http2, WebSocket connections also reach your Instances over HTTP/2, and most servers accept WebSockets only over HTTP/1.1. To serve WebSockets alongside gRPC, serve them on a separate port through a network service.

What’s next

To run in more locations so that more users reach a nearby Instance, see Placement and scaling.
To learn more about HTTPProxy routing and options, see Application Load Balancer.
To learn how Instances connect privately, see Traffic and connecting.

Introduction

Explore

Serve public traffic with ALB

Before you begin

Attach an ALB with datumctl

Find your workload’s ALB hostname

Change or remove the ALB

Use a custom domain

Publish a workload you manage with manifests

Limitations

What’s next

​Before you begin

​Attach an ALB with datumctl

​Find your workload’s ALB hostname

​Change or remove the ALB

​Use a custom domain

​Publish a workload you manage with manifests

​Limitations

​What’s next

Before you begin

Attach an ALB with datumctl

Find your workload’s ALB hostname

Change or remove the ALB

Use a custom domain

Publish a workload you manage with manifests

Limitations

What’s next