Couldn't find a Waypoint deployment with this URL

Waypoint
1

I’ve spun up Waypoint locally (Mac) using Docker as the Waypoint Server. Using some of the examples from https://github.com/hashicorp/waypoint-examples/tree/main/docker

Deployments run fine with no errors, but the waypoint.run address comes back with:

image

Anyone else have that issue?

2

This is similar to this recent Github Issue. I was able to get the Ruby example working for me just now.

One thing I suggest is using either waypoint logs or if you want even more control, doing a docker ps and then a docker logs example-ruby-01EMS7EBCY3RSCG59MVQYG4BEZ where your container ID will be different. In that case you can see whether the Entrypoint can connect to the URL service. Example logs looks like url.agent messages. Note that after connecting successfully, the app starts up and binds to the port:

2020-10-16T17:31:13.175Z [INFO]  url: url service enabled, configuring: addr=https://control.hzn.network service_port=3000 labels=service=example-ruby,waypoint/workspace=default,env=dev,waypoint.hashicorp.com/app=example-ruby,waypoint.hashicorp.com/project=example-ruby,waypoint.hashicorp.com/workspace=default,:deployment=v2,:deployment-order=01ems7eb7v4kyr5fzqx26hb4tf
2020-10-16T17:31:13.189Z [DEBUG] url: discovering hubs
2020-10-16T17:31:13.189Z [DEBUG] url: refreshing data
2020-10-16T17:31:13.606Z [DEBUG] url.agent: connecting to hub: addr=54.189.206.215:443
2020-10-16T17:31:13.607Z [DEBUG] url.agent: connecting to hub: addr=52.34.190.10:443
2020-10-16T17:31:34.203Z [DEBUG] url.agent: connection latency: latency=20.5443788s
2020-10-16T17:31:34.204Z [DEBUG] url.agent: connected successfully: status=connected latency=20.5443788s skew=43.896763ms
2020-10-16T17:31:34.204Z [DEBUG] url.agent: connected to hub: addr=52.34.190.10:443
2020-10-16T17:31:34.204Z [INFO]  starting child process: args=[/cnb/lifecycle/launcher] cmd=/cnb/lifecycle/launcher
2020-10-16T17:31:34.204Z [DEBUG] log: connecting to log stream
2020-10-16T17:31:34.204Z [TRACE] log: log stream connected
[14] Puma starting in cluster mode...
[14] * Version 5.0.2 (ruby 2.6.6-p146), codename: Spoony Bard
[14] * Min threads: 5, max threads: 5
[14] * Environment: production
[14] * Process workers: 2
[14] * Preloading application
2020-10-16T17:31:34.643Z [TRACE] log: sending line: line="[14] Puma starting in cluster mode..."
2020-10-16T17:31:34.643Z [TRACE] log: sending line: line="[14] * Version 5.0.2 (ruby 2.6.6-p146), codename: Spoony Bard"
2020-10-16T17:31:34.643Z [TRACE] log: sending line: line="[14] * Min threads: 5, max threads: 5"
2020-10-16T17:31:34.644Z [TRACE] log: sending line: line="[14] * Environment: production"
2020-10-16T17:31:34.644Z [TRACE] log: sending line: line="[14] * Process workers: 2"
2020-10-16T17:31:34.644Z [TRACE] log: sending line: line="[14] * Preloading application"
2020-10-16T17:31:35.353Z [DEBUG] url.agent: connection latency: latency=21.6793388s
2020-10-16T17:31:35.353Z [DEBUG] url.agent: connected successfully: status=connected latency=21.6793388s skew=43.698856ms
2020-10-16T17:31:35.353Z [DEBUG] url.agent: connected to hub: addr=54.189.206.215:443
2020-10-16T17:31:35.676Z [TRACE] url.agent: stream accepted: id=2 lz4=true
2020-10-16T17:31:35.706Z [INFO]  url.agent: request started: method=GET path=/favicon.ico
2020-10-16T17:31:35.709Z [ERROR] url.agent: error in service handler: error="Get "http://:3000/favicon.ico": dial tcp :3000: connect: connection refused"
[14] * Listening on http://0.0.0.0:3000
3

I spaced on looking in the Github issues. I’m not seeing any errors on my end, but I’ll keep looking. Thanks again!

4

I ran into this too, but all worky now. FWIW waypoint logs didn’t seem to work for me either while the entrypoint service was down.

5

Yes sorry about this, there was an outage with the Waypoint URL service which has now been fixed. Coupled to this there was an issue where your application would not start when the Waypoint URL service could not be contacted.

We have applied a fix to the URL service and continue to monitor it: https://status.hashicorp.com/

We have also fixed the issue in the entrypoint which means it is no longer dependent on the URL service to start:

Kind regards,

Nic

2 Likes
6

Well, I think I found my issue. My work is blocking either the URL Service or something else. It seems to stop right at the “refreshing data”:

[TRACE] requesting version info from server
[INFO]  server version info: version=v0.1.2 api_min=1 api_current=1 entrypoint_min=1 entrypoint_current=1
[INFO]  negotiated entrypoint protocol version: version=1
[DEBUG] config: registering instance, requesting config
[TRACE] config: config stream connected, waiting for first config
[TRACE] config: first config received
[INFO]  url: url service enabled, configuring: addr=https://control.hzn.network service_port=8080 labels=service=example-python,env=dev,waypoint/workspace=default,waypoint.hashicorp.com/app=example-python,waypoint.hashicorp.com/project=example-python,waypoint.hashicorp.com/workspace=default,:deployment=v4,:deployment-order=01emtnqkw90read2k0hdzx79rk
[DEBUG] url: discovering hubs
[DEBUG] url: refreshing data

When I’m off VPN I can see more logs showing it connecting to a “hub”:

[DEBUG] url.agent: connecting to hub: addr=54.184.95.88:443
[DEBUG] url.agent: connecting to hub: addr=52.32.54.223:443
[DEBUG] url.agent: connecting to hub: addr=54.189.206.215:443
[DEBUG] url.agent: connecting to hub: addr=52.34.190.10:443
[DEBUG] url.agent: connection latency: latency=24.4308ms
[DEBUG] url.agent: connected successfully: status=connected latency=24.4308ms skew=-5.268773ms
[DEBUG] url.agent: connection latency: latency=62.9914ms

Would anyone know if the “hub” is https://control.hzn.network or is it something else we need to put into our firewall allow list?

7

The agent talks to the control PLUS individual hubs (IP addresses) that it may return.

8

I’m still getting this error when using --platform=kubernetes with the Docker for Desktop for macOS setup, even with Waypoint 0.1.3.

Everything works fine if Waypoint is installed with --platform=docker and everything else being identical.

BTW, with --platform=kubernetes only Waypoint runs as a kube app; waypoint up still deployes the app itself using docker and not using kubernetes. Is that intentional?

9

Yes, if your waypoint file says to deploy to Docker. This works in the case that the K8S installation is exposed to Docker, for example (network reachable).

This sounds like networking issues reaching out of the Docker image to the Waypoint server. There needs to be a route between your workload and the server.

10

Thanks, that explains it perfectly!