HashiCorp Developer AI Private beta now available Sign up today
Waypoint
Waypoint Home

Enabling On-Demand Runners Using Kubernetes

Warning

This content is part of the legacy version of Waypoint that is no longer actively maintained. For additional information on the new vision of Waypoint, check out this blog post and the HCP Waypoint documentation.

A Waypoint runner executes each build, deployment, and release operation that Waypoint performs. The runner accepts jobs from the server, executes the necessary operations, and then either waits for additional jobs to be queued or exits. Runners that are long-lived and execute many jobs over time are known as static runners, while those that are created per-job and exit upon completion are known as on-demand runners (ODRs).

On-demand runners overview process

On-demand runners are ephemeral, short-lived container instances that exist only for as long as they are needed to complete the operations assigned to them. A few key benefits of on-demand runners over static runners are that they can perform container builds without privileged access, offer more isolation between operations, and allow Waypoint to scale further dynamically.

In this tutorial, you will install static runners into Kubernetes and use runner profiles that allow those static runners to create on-demand runners for executing Waypoint operations in response to changes you will make to a remote Git repository.

Scenario and runner overview

There are two Kubernetes clusters that you will create as part of this tutorial: the first will contain the Waypoint server and be a default app deployment environment while the second will be an environment specific to a team and their desire to restrict Waypoint operations to their own isolated cluster.

A static runner in each cluster that is registered with the Waypoint server is responsible for managing the on-demand runners in their respective cluster.

Tip

The following commands are examples - you do not need to run any of them.

The runner configuration that is part of the installation process includes key-value labels that describe or identify the runner. These labels are user-generated strings and can be attributes such as cluster location, environment level, or other identifying values.

Example helm install command with runner label
$ helm install --set 'runner.agentArgs={-label=environment=staging}' waypoint hashicorp/waypoint

A runner profile uses these labels to target specific runners during the execution of the Waypoint operations through the -target-runner-label flag.

Targeting a runner with a runner profile
$ waypoint runner profile set \
  -name=staging-runner \
  -plugin-type=kubernetes \
  -target-runner-label=environment=staging

Once the runners are set up, you can target a runner by adding the runner block with a profile name to the waypoint.hcl file.

Example waypoint.hcl snippet with runner block
runner {
  profile = "staging-runner"
}

project = "example-project"

app "example-nodejs" {...}

The on-demand runners in this tutorial use the Kubernetes task plugin. ODR functionality is plugin-based so additional cloud providers or environment plugins can be created by users in the event that a plugin is not already available. Waypoint currently supports several plugins including Kubernetes, HashiCorp Nomad, AWS ECS, and Docker by default.

Prerequisites

For this tutorial, you will need:

Note

This tutorial creates AWS resources that may not qualify as part of the AWS free tier. Be sure to follow the Cleanup process at the end so you don't incur any additional unnecessary charges.

Set up the container registry

This tutorial uses DockerHub as the image registry but you can use other registry services. The visibility of the DockerHub repository is public so that the Waypoint runners in Kubernetes can pull these images without additional authentication.

Create the access token

Create a new DockerHub access token by navigating to the security settings page and clicking on the blue New Access Token button. Type waypoint in the Access Token Description field, select Read, Write, Delete from the Access permissions dropdown, and click Generate.

Creating a new access token on DockerHub

Copy the token value and export it as a local environment variable.

$ export DOCKERHUB_TOKEN=

Click on the Copy and Close button to close the dialog box.

Export your DockerHub username as a local environment variable.

$ export DOCKERHUB_USER=

Clone the example repository

The example repository includes the Terraform configuration to create the two Kubernetes clusters and the supporting infrastructure including networking and IAM resources. It also contains an example NodeJS application from the Waypoint examples repository located in the app directory.

Clone the example repository.

$ git clone https://github.com/hashicorp/learn-waypoint-odr.git

Change into the learn-waypoint-odr directory.

$ cd learn-waypoint-odr

Create infrastructure

First, initialize your Terraform configuration.

$ terraform init

Apply the configuration to create the Kubernetes clusters and supporting infrastructure. This process will take a few minutes to complete.

Tip

Resources will be created in the us-east-2 region by default. If you would like to create them in another region, update the aws_region and availability_zones variables in the variables.tf file.

$ terraform apply
# ...
Plan: 53 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

# ...
module.secondary_kubernetes.aws_eks_addon.ebs_csi_addon: Creation complete after 1m16s [id=wp-odr-secondary:aws-ebs-csi-driver]
module.primary_kubernetes.aws_eks_addon.ebs_csi_addon: Still creating... [1m10s elapsed]
module.primary_kubernetes.aws_eks_addon.ebs_csi_addon: Creation complete after 1m17s [id=wp-odr-primary:aws-ebs-csi-driver]

Apply complete! Resources: 53 added, 0 changed, 0 destroyed.

Update your local kubeconfig file with the primary EKS cluster information.

$ aws eks update-kubeconfig \
  --region $(terraform output -raw region) \
  --name $(terraform output -raw primary_cluster_name) \
  --alias primary

Added new context primary to ~/.kube/config

Then, update your local kubeconfig file with the secondary EKS cluster information.

$ aws eks update-kubeconfig \
  --region $(terraform output -raw region) \
  --name $(terraform output -raw secondary_cluster_name) \
  --alias secondary

Added new context secondary to ~/.kube/config

Install Waypoint

Install server in primary cluster

Install the Waypoint server and runner into the primary cluster.

$ waypoint server install -platform=kubernetes -k8s-context=primary -accept-tos
✓ Service "waypoint" is ready
✓ Server bootstrap complete!
✓ Waypoint server installed with Helm!
✓ Configured server connection
✓ Successfully connected to Waypoint server in Kubernetes!
✓ Server installed and configured!
✓ Runner "static" installed
✓ Waypoint runner installed with Helm!
✓ Runner "static" adopted successfully.
Waypoint server successfully installed and configured!

The CLI has been configured to connect to the server automatically. This
connection information is saved in the CLI context named "install-1666292159".
Use the "waypoint context" CLI to manage CLI contexts.

The server has been configured to advertise the following address for
entrypoint communications. This must be a reachable address for all your
deployments. If this is incorrect, manually set it using the CLI command
"waypoint server config-set".

To launch and authenticate into the Web UI, run:
waypoint ui -authenticate

Advertise Address: ae032cf056de041839dc9a7f5e0cba8a-1096492474.us-east-2.elb.amazonaws.com:9701
Web UI Address: https://ae032cf056de041839dc9a7f5e0cba8a-1096492474.us-east-2.elb.amazonaws.com:9702

Authenticate to the Waypoint UI.

Note

Your browser may warn you that the site is not secure, this is because Waypoint uses a self-signed certificate by default but TLS is still enabled.

$ waypoint ui -authenticate
» Creating invite token
This invite token will be exchanged for an authentication
token that your browser stores.

» Opening browser

Install runner in primary cluster

Runners can be installed with either the waypoint runner install CLI command or Helm.

With the waypoint runner install method, Waypoint automatically adopts the runner and creates a runner profile for it. You can skip this automatic adoption and profile creation by including the -skip-adopt flag but you will then need to manually adopt the runner and create a profile.

The Helm install requires additional configuration steps to adopt the runner, set up the runner profile, and modify the runner service account in Kubernetes.

Tip

We recommend installing runners with waypoint runner install as it simplifies the process and does not require the Helm CLI.

Get the hostname of the primary cluster from the kubectl output and save it as an environment variable.

$ export WP_PRIMARY_ADDR=$(kubectl get services waypoint-ui --context=primary --output jsonpath='{.status.loadBalancer.ingress[0].hostname}'):9701

Install the runner by providing the server cookie and hostname of the primary cluster. Note the runner label being added with the -label flag as well as the -k8s-context flag specifying the context for the primary cluster.

$ waypoint runner install \
  -id=primary-cluster-runner \
  -k8s-context=primary \
  -server-addr=${WP_PRIMARY_ADDR} \
  -server-tls-skip-verify \
  -- -label=cluster=primary

✓ Finished connecting to: ae032cf056de041839dc9a7f5e0cba8a-1096492474.us-east-2.elb.amazonaws.com:9701
✓ Runner "primary-cluster-runner" installed successfully to kubernetes
✓ Runner profile "kubernetes-PRIMARY-CLUSTER-RUNNER" created successfully.
✓ Waypoint runner installed with Helm!
✓ Runner "primary-cluster-runner" adopted successfully.

Verify that the runner exists.

Tip

The runner with the static ID is automatically installed during the Waypoint server installation process.

$ waypoint runner list
            ID           |  STATE  |  KIND  |      LABELS      | LAST REGISTERED
-------------------------+---------+--------+------------------+------------------
  static                 | adopted | remote |                  | 2 minutes ago
  primary-cluster-runner | adopted | remote | cluster:primary  | 47 seconds ago

Verify that the runner profile exists for the new runner.

$ waypoint runner profile list
Runner profiles
                NAME                | PLUGIN TYPE |                 OCI URL                 |         TARGET RUNNER         | DEFAULT
------------------------------------+-------------+-----------------------------------------+-------------------------------+----------
  01GFVBZ23B2HMQSB37NG0D2295        | kubernetes  | docker.io/hashicorp/waypoint-odr:latest | *                             | yes
  kubernetes-PRIMARY-CLUSTER-RUNNER | kubernetes  | hashicorp/waypoint-odr:latest           | labels: {"cluster":"primary"} |

Install runner in secondary cluster

The installation process for the runner in the secondary cluster is the same as the one for the runner in the primary cluster.

Note

Make sure you have followed the steps from the Install runner in primary cluster section above before continuing with the secondary cluster runner installation.

Install the runner.

$ waypoint runner install \
  -id=secondary-cluster-runner \
  -k8s-context=secondary \
  -server-addr=${WP_PRIMARY_ADDR} \
  -server-tls-skip-verify \
  -- -label=cluster=secondary

✓ Finished connecting to: ae032cf056de041839dc9a7f5e0cba8a-1096492474.us-east-2.elb.amazonaws.com:9701
✓ Runner "secondary-cluster-runner" installed successfully to kubernetes
✓ Runner profile "kubernetes-SECONDARY-CLUSTER-RUNNER" created successfully.
✓ Waypoint runner installed with Helm!
✓ Runner "secondary-cluster-runner" adopted successfully.

Verify that the runner exists.

$ waypoint runner list
             ID            |  STATE  |  KIND  |       LABELS       | LAST REGISTERED
---------------------------+---------+--------+--------------------+------------------
  static                   | adopted | remote |                    | 3 minutes ago
  secondary-cluster-runner | adopted | remote | cluster:secondary  | 29 seconds ago
  primary-cluster-runner   | adopted | remote | cluster:primary    | 2 minutes ago

Verify that the runner profile exists for the new runner.

$ waypoint runner profile list
Runner profiles
                 NAME                 | PLUGIN TYPE |                 OCI URL                 |          TARGET RUNNER          |
DEFAULT
--------------------------------------+-------------+-----------------------------------------+---------------------------------+------
  01GFVBZ23B2HMQSB37NG0D2295          | kubernetes  | docker.io/hashicorp/waypoint-odr:latest | *                               | yes  kubernetes-PRIMARY-CLUSTER-RUNNER   | kubernetes  | hashicorp/waypoint-odr:latest           | labels: {"cluster":"primary"}   |  kubernetes-SECONDARY-CLUSTER-RUNNER | kubernetes  | hashicorp/waypoint-odr:latest           | labels: {"cluster":"secondary"} |

Prepare the project repository

Create a new, empty public Git repository on a hosted Git platform like GitHub, GitLab, or Bitbucket. For this tutorial, the repository is public but Waypoint does support basic password and SSH authentication if you want to use a private repository.

Create an environment variable named MY_REPO_URL and set the value to the URL of your public git repository.

$ export MY_REPO_URL=

Change to the app directory of the example repository.

$ cd app

Initialize a new git project.

$ git init
Initialized empty Git repository in ~/learn-waypoint-odr/app/.git/

Create and switch to a new branch named main.

$ git checkout -b main
Switched to a new branch 'main'

Add your new public Git repository as the remote repository URL.

$ git remote add origin $MY_REPO_URL

Add the runner block to the waypoint.hcl file inside the app block and save the file.

waypoint.hcl
1 2 3 4 5 6 7 8 9 10111213project = "nodejs-example"

app "nodejs-example" {
  runner {
    profile = "kubernetes-PRIMARY-CLUSTER-RUNNER"
  }

  labels = {
    "service" = "example-nodejs",
    "env"     = "dev"
  }
# …
}

Add and commit all of the files in the directory.

$ git add . && git commit -m "Initial commit with updated waypoint file."
[main (root-commit) 2b337a2] Initial commit with updated waypoint file.
 11 files changed, 727 insertions(+)
 create mode 100644 index.js
 create mode 100644 package.json
 create mode 100644 public/hashi.svg
 create mode 100644 public/language.svg
 create mode 100644 public/logo.svg
 create mode 100644 public/pattern-br.svg
 create mode 100644 public/pattern-tl.svg
 create mode 100644 public/stylesheets/main.css
 create mode 100644 views/pages/index.ejs
 create mode 100644 views/partials/header.ejs
 create mode 100644 waypoint.hcl

Finally, push the contents to the main branch of your repository.

$ git push -u origin main
Enumerating objects: 18, done.
Counting objects: 100% (18/18), done.
Delta compression using up to 12 threads
Compressing objects: 100% (15/15), done.
Writing objects: 100% (18/18), 8.81 KiB | 2.94 MiB/s, done.
Total 18 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), done.
To https://github.com/hashicorp/waypoint-odr-example.git
 * [new branch]      main -> main
Branch 'main' set up to track remote branch 'main' from 'origin'.

Note

If your repository has a README or other template file, you may encounter an error that instructs you to fetch updates first. Run a git fetch to retrieve and merge the files locally or add the --force flag to the git push command if you want to overwrite any remote files.

Create project with runner profile

Create the Waypoint project.

$ waypoint project apply nodejs-example
✓ Project "nodejs-example" created

Add configurations for image name, registry username, and registry password at the Waypoint project level. Note that the -runner flag is added to make these available as environment variables to on-demand runners used by the project.

Tip

These waypoint config set commands will not print any output when they complete.

Set the image name.

$ waypoint config set -runner -project=nodejs-example REGISTRY_IMAGENAME=wp-nodejs

Then, set your registry username.

$ waypoint config set -runner -project=nodejs-example REGISTRY_USERNAME=${DOCKERHUB_USER}

Finally, set your registry password.

$ waypoint config set -runner -project=nodejs-example REGISTRY_PASSWORD=${DOCKERHUB_TOKEN}

Warning

These values are stored in the Waypoint server. Setting the registry configurations here are done so for development and illustration purposes.

View the configurations for the runners used by the project.

$ waypoint config get -runner -project=nodejs-example
   SCOPE  |        NAME        |                VALUE                 | WORKSPACE | LABELS
----------+--------------------+--------------------------------------+-----------+---------
  project | REGISTRY_IMAGENAME | wp-nodejs                            |           |
  project | REGISTRY_PASSWORD  | [REDACTED]                           |           |
  project | REGISTRY_USERNAME  | [DOCKERHUB_USER]                     |           |

Modify the Waypoint project to add a reference to the Git repository and enable GitOps.

$ waypoint project apply \
  -data-source=git \
  -git-url=${MY_REPO_URL} \
  -git-ref=main \
  -poll \
  nodejs-example

✓ Project "nodejs-example" created

Waypoint will begin the initial build, deploy, and release operations for the project and then each time a change to the repository is made. These initial operations will happen on the primary cluster as the waypoint.hcl file contains the kubernetes-PRIMARY-CLUSTER-RUNNER profile.

Verify that the application is running on the correct cluster by listing the pods in the primary cluster. The application pod will take some time to deploy and change to the running state. Note the pod with the application name and v1 - in this case nodejs-example-v1-94f77f4dd-w4pf7.

$ kubectl get pods --context=primary
NAME                                             READY   STATUS      RESTARTS   AGE
nodejs-example-v1-94f77f4dd-w4pf7                1/1     Running     0          36s
waypoint-primary-cluster-runner-runner-0         1/1     Running     0          6m47s
waypoint-server-0                                1/1     Running     0          9m45s
waypoint-static-runner-0                         1/1     Running     0          8m5s
[...]

Modify repository code

Open the views/pages/index.ejs file, add a new H2 heading with text, and save the file.

views/pages/index.ejs
<!DOCTYPE html>
<html>
  <head>
    <% include ../partials/header.ejs %>
  </head>

  <body>
    <div class="container">
     ##…
      <section class="content">
        ##…
        <h1>This Node.js app was deployed with Waypoint.</h1>
        <h2>Hello from the secondary cluster!</h2>
##…
      </section>
      ##…
    </div>
  </body>
</html>

Open the waypoint.hcl file, update the runner profile to use the one for the secondary cluster runner, and save the file.

app/waypoint.hcl
app "nodejs-example" {
  runner {
    profile = "kubernetes-SECONDARY-CLUSTER-RUNNER"
  }
  labels = {
    "service" = "example-nodejs",
    "env"     = "dev"
  }
  # ...
}

Add and commit the updated files.

$ git add . && git commit -m "Updated the app main page and runner profile."
[main 8333d1f] Updated the app main page and runner profile.
 2 files changed, 3 insertions(+), 2 deletions(-)

Then, push the contents to the main branch of your public repository.

$ git push -u origin main
Enumerating objects: 11, done.
Counting objects: 100% (11/11), done.
Delta compression using up to 12 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 560 bytes | 560.00 KiB/s, done.
Total 6 (delta 3), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
To https://github.com/hashicorp/waypoint-odr-example.git
   4eb5b74..8333d1f  main -> main

Waypoint will detect the changes made to the repository and run the build, deploy, and release operations. This may take some time. Once complete, view the updated app from the deployments page in the Waypoint UI by clicking on the gray button with the waypoint.run generated URL. You can also use the Kubernetes load balancer release URL by clicking the blue button in the top right of the page.

nodejs-example deployments page in the Waypoint UI with deployment URL buttons highlighted

Example nodejs-example application running on the secondary cluster

Verify that the application is running on the correct cluster by listing the pods in the secondary cluster. Note the pod with the application name and v2 - in this case nodejs-example-v2-ffc77446d-t69sv.

$ kubectl get pods --context=secondary
NAME                                             READY   STATUS      RESTARTS   AGE
nodejs-example-v2-ffc77446d-t69sv                1/1     Running     0          96s
waypoint-secondary-cluster-runner-runner-0       1/1     Running     0          118m
[...]

Trigger the remote runner locally

You can trigger projects with a remote Git configuration from your local machine with the Waypoint CLI by adding -local=false to the waypoint up command.

Warning

When running waypoint up locally, the CLI will read the runner profile from the local waypoint.hcl file, not the one in the remote Git repository. However if you want to change any of your app configurations, they must be committed into the remote Git repository, as Waypoint will read app configurations from the remote waypoint.hcl file.

Update the runner profile in waypoint.hcl to use the runner in the primary cluster and save the file.

app/waypoint.hcl
app "nodejs-example" {
  runner {
    profile = "kubernetes-PRIMARY-CLUSTER-RUNNER"
  }

  labels = {
    "service" = "example-nodejs",
    "env"     = "dev"
  }
  # ...
}

Then run waypoint up with the -local=false flag.

Tip

Waypoint reads the project name from the waypoint.hcl file present in the current directory if it is not explicitly set it with the -project global flag.

$ waypoint up -local=false
  Performing operation on "kubernetes" with runner profile "kubernetes-PRIMARY-CLUSTER-RUNNER"

» Cloning data from Git
  URL: https://github.com/hashicorp/waypoint-odr-example.git
  Ref: main

» Downloading from Git
  Git Commit: a14f273cf2bdf73c0bc82e264ad49b7cd53ef19d
   Timestamp: 2022-10-20 19:05:55 +0000 UTC
     Message: Updated the app main page and runner profile.


» Building nodejs-example...
â ¦ Running build v3
✓ Building Buildpack with kaniko...
✓ Repository is available and ready: [DOCKERHUB_USER]/wp-nodejs:a14f273cf2bdf73c0bc82e264ad49b7cd53ef19d
â ¦ Executing kaniko...
 │ Saving localhost:45599/[DOCKERHUB_USER]/wp-nodejs:a14f273cf2bdf73c0bc82e264ad49b7cd53
 │ ef19d...
 │ *** Images (sha256:00218e2c71a3a924d5d482ed1ee5d9c577b4a02e8ca508232050574d538ce
 │ cf5):
 │       localhost:45599/[DOCKERHUB_USER]/wp-nodejs:a14f273cf2bdf73c0bc82e264ad49b7cd53e
 │ f19d
 │ Adding cache layer 'heroku/nodejs-engine:dist'
 │ Adding cache layer 'heroku/nodejs-npm:toolbox'
 │ INFO[0043] Taking snapshot of full filesystem...
 │ INFO[0051] Skipping push to container registry due to --no-push flag
✓ Image pushed to '[DOCKERHUB_USER]/wp-nodejs:a14f273cf2bdf73c0bc82e264ad49b7cd53ef19d'
✓ Running push build v3

» Deploying nodejs-example...
✓ Running deploy v3
✓ Kubernetes client connected to https://172.20.0.1:443 with namespace default
✓ Creating deployment...
✓ Expected "http" port "3000" for app "nodejs-example-v3"
✓ Deployment successfully rolled out!

✓ Finished building report for Kubernetes platform
✓ Finished building report for Kubernetes deployment resource

» Releasing nodejs-example...
✓ Running release v3
✓ Kubernetes client connected to https://172.20.0.1:443 with namespace default
✓ Updating existing service...
✓ Service is ready!

» Pruning old deployments...
  Deployment: 01GFVCF2X5Y15XM442T8W48XAQ (v1)
✓ Running deployment destroy v1
✓ Kubernetes client connected to https://172.20.0.1:443 with namespace default
✓ Deployment deleted

» Pruning old releases...
  Release: 01GFVCG26VA64D5N4X4KD8TSN0 (v1)
✓ Running release destroy v1
✓ Kubernetes client connected to https://172.20.0.1:443 with namespace default
✓ Service deleted

✓ Finished building report for Kubernetes platform
✓ Finished building report for Kubernetes service resource

» Variables used:
       VARIABLE      |                     VALUE                     |   TYPE    | SOURCE
---------------------+-----------------------------------------------+-----------+---------
  registry_password  | 6fa1f8eae7859edbdf63eb262fa4fa94ab473b9cb9af5 | sensitive | env
                     | 1e0d0e6eb4f2a3153d0                           |           |
  registry_username  | [DOCKERHUB_USER]                              | string    | env
  registry_imagename | wp-nodejs                                     | string    | env


The deploy was successful! A Waypoint deployment URL is shown below. This
can be used internally to check your deployment and is not meant for external
traffic. You can manage this hostname using "waypoint hostname."

   Release URL: http://a9c79a5e043564586aefb882ce181e79-233775817.us-east-2.elb.amazonaws.com:3000
Deployment URL: https://promptly-wise-lizard--v3.waypoint.run

Verify that v3 of the application is running in the primary cluster.

$ kubectl get pods --context=primary
nodejs-example-v1-94f77f4dd-w4pf7                1/1     Running     0          3m30s
nodejs-example-v3-77777d7866-l4hcj               1/1     Running     0          48s
waypoint-primary-cluster-runner-runner-0         1/1     Running     0          13m
waypoint-server-0                                1/1     Running     0          16m
waypoint-static-runner-0                         1/1     Running     0          14m

Cleanup

There are two ways of cleaning up once you are finished with Waypoint. The first involves destroying the Waypoint project resources, then the runners and runner profiles, and finally the underlying infrastructure. The second involves using Terraform to destroy the infrastructure and, at the same time, all of the Waypoint project resources.

We recommend the first method as it helps you become more familiar with the resources involved in using Waypoint.

Delete the project and all of the resources associated with it. This includes deployents and releases.

$ waypoint project destroy
Do you really want to destroy project "nodejs-example" and its resources? Only 'yes' will be accepted to approve: yes

  Performing operation on "kubernetes" with runner profile "01GFVBZ23B2HMQSB37NG0D2295"

» Cloning data from Git
  URL: https://github.com/hashicorp/waypoint-odr-example.git
  Ref: main

» Downloading from Git
  Git Commit: a14f273cf2bdf73c0bc82e264ad49b7cd53ef19d
   Timestamp: 2022-10-20 19:05:55 +0000 UTC
     Message: Updated the app main page and runner profile.


» Destroying releases for application 'nodejs-example'...
✓ Running release destroy v3
✓ Kubernetes client connected to https://10.100.0.1:443 with namespace default
✓ Service deleted
✓ Running release destroy v2
✓ Kubernetes client connected to https://10.100.0.1:443 with namespace default
✓ Service deleted

» Destroying deployments for application 'nodejs-example'...
✓ Running deployment destroy v3
✓ Kubernetes client connected to https://10.100.0.1:443 with namespace default
✓ Deployment deleted
✓ Running deployment destroy v2
✓ Kubernetes client connected to https://10.100.0.1:443 with namespace default
✓ Deployment deleted
Project "nodejs-example" destroyed!

Uninstall the runners.

First, the runner in the primary cluster.

$ waypoint runner uninstall \
  -platform=kubernetes \
  -id=primary-cluster-runner \
  -k8s-context=primary

✓ Runner "primary-cluster-runner" uninstalled successfully
✓ Runner "primary-cluster-runner" forgotten on server
✓ Runner "primary-cluster-runner" uninstalled
✓ Persistent volume claims cleaned up

Then, the runner in the secondary cluster.

$ waypoint runner uninstall \
  -platform=kubernetes \
  -id=secondary-cluster-runner \
  -k8s-context=secondary

✓ Runner "secondary-cluster-runner" uninstalled successfully
✓ Runner "secondary-cluster-runner" forgotten on server
✓ Runner "secondary-cluster-runner" uninstalled
✓ Persistent volume claims cleaned up

Move back up to the root directory of the repository.

$ cd ../

Clean up your provisioned infrastructure. Respond yes to the prompt to confirm the operation.

$ terraform destroy
# ...
Plan: 0 to add, 0 to change, 53 to destroy.

Changes to Outputs:
  - primary_cluster_name   = "wp-odr-primary" -> null
  - region                 = "us-east-2" -> null
  - secondary_cluster_name = "wp-odr-secondary" -> null

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

# ...

Destroy complete! Resources: 0 added, 0 changed, 53 destroyed.

Note

The load balancers created by Kubernetes as part of the release operation are not managed by Terraform but there is a cleanup module that takes care of deleting them. In the event that it doesn’t work the first time, re-run terraform destroy. If that still does not work, you may need to navigate to the load balancers section of the AWS console and delete them manually.

Next Steps

In this tutorial, you installed static runners into separate Kubernetes clusters, created and associated runner profiles to them, and then used those profiles to get Waypoint to dynamically create and use on-demand runners when you made changes to your waypoint.hcl file from your remote Git repository.

For more information, check out the following resources.

Edit this page on GitHub