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?

What (other) kinds of apps will Waypoint support?
#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!

#11

So, thinking this through there are a few bits to consider:

  1. Flexibility of liveness probes. This is pretty easy, we could expose exec or even the ability to just turn it off, not a big issue.
  2. Disable Service object. This isn’t a huge deal though it means effectively having no release functionality either because there is no Service object to pivot between.
  3. Probably manipulating one Deployment object for rollout, rather than creating a new one. Right now Kubernetes creates a new Deployment object for each waypoint deploy, to allow the release phase the ability to point between 2 independent sets. For your use case, I think you’d not want that and instead want just one Deployment object that gets manipulated on each waypoint deploy.

Does that all seem right?

#12

Yeah, I think that mostly sounds right.

For #3, the default deployment behavior is probably fine, even if HTTP traffic isn’t being routed there, especially if the rollout behavior is configurable.

I could see release process that does something like:

  1. Spin up a new deployment
  2. Check some metrics to make sure message ratios remain the same or that there’s not a spike in exceptions or error messages
  3. Continue with deploy or rollback depending on result of #2

That said, there are other projects that do this (Argo Rollouts, for example), so maybe that’s not really the responsibility of Waypoint.

1 Like