Non-web workloads

Waypoint
#1

When I try to run a non-http workload with the default Go buildpack by putting a line like this in my Procfile:

work: bin/subscriber

I’m getting this error from the kubernetes pod:

ERROR: failed to launch: determine start command: ││ process type web was not found

Which makes sense, because I don’t have a web process.

It looks like I can start a different workload from the docker image locally by passing in the process name like this:

docker run my-image work

Is there a way to override the command somewhere in the waypoint config? Or a way to specify which process to run from the Procfile?

#2

I think the default build packs (we don’t maintain these, these are Cloud Native Buildpacks) expect a web process… I think. To use a purely non-web container with buildpacks it may require a custom buildpack. Someone who is more familiar with buildpacks may be able to respond.

If you use the plain Docker builder then it should work, although features such as the URL service won’t work but this makes sense.

#3

Do you have multiple processes you want to run? If it’s just the one process, then this example worked for me without listening to a web port. You shouldn’t need a Procfile if you only have one process type.

Another tip for playing with buildpacks, try using the pack CLI as shown here.

#4

Yeah, I can see how to get it working with a custom buildpack or just bringing my own Dockerfile, but was trying to see how far I could get with the off-the-shelf buildpack.

That said, if it’s not intended to work without a web process, that’s fine, just a little unexpected I guess? Given that the buildpack allows processes other than “web” as part of its API.

#5

Looking at the pack documentation (thank you, @jbayer!) , it seems like what I want to be able to do is set default-process in the Waypoint pack stanza.

Or, even easier, just specify the docker command to run after building the image to run a non-default process.

#6

Yes, I see what you mean. Right now the pack plugin variables are very limited. I created https://github.com/hashicorp/waypoint/issues/598 to track this.

#7

Excellent, thank you!!

#8

A few other challenges for non-HTTP workloads using Kubernetes:

  1. The liveness/readiness probes assume an HTTP endpoint, which you may not have if it’s not an HTTP workload.
  2. Waypoint creates a Service resource which you probably don’t want if you’re not exposing your workload over HTTP
1 Like
#9

Yup, we were laser focused on HTTP workloads for the 0.1 so we plan to start extending from there to non-web. Is the service that you’re deploying TCP based? Or is it not something that directly consumes client requests of any kind?

#10

@evanphx Yeah, so I’ve been working on systems composed out of services consuming messages off of NATS queues, so they don’t accept any TCP connections other than connecting to the broker.

It’s possible that I’d still do health checks through HTTP, especially if I’m already spinning up a prometheus endpoint or something, but I definitely wouldn’t need/want a kubernetes Service resource since I don’t intend to expose that at all.

Makes sense to focus on HTTP for now, though. Nice work on this!