Unable to find process about rust

[dmikusa]

Do I have to pass the binary path in the docker run command? I don't think I am supposed to do that - since that would be the ENTRYPOINT in the image built?

No. You should be able to docker run <img> and it'll work. You may want -it if you want the process to log to STDOUT/STDERR. If you do that and depending on your app, you may need to add --init as well because Rust won't handle signal propagation by default (you know you need --init if docker stop hangs).

A few other buildpacks tips, not Rust specific:

1. If you docker run <img> <arg>... you can pass arguments to your process. They'll be passed to your Rust app using std:env::args().
2. If you docker run --entrypoint <process-type> <img> you can run an alternative process type. For example, if you have two entries in your Procfile, say web: webserver and task: some-task, you could run docker run --entrypoint task <img> and it would execute your task process.
3. If you docker run --entrypoint launcher <img> bash, you can get a shell in the container and the launcher will set up the environment exactly like it would for your application. This can be helpful or troubleshooting.
4. If you docker run --entrypoint bash <img> you can also get a shell, but the launcher will not run so the env will be vanilla and have none of the buildpack specific env variables set up (i.e. nothing on $PATH). Less helpful for troubleshooting, but can occasionally be useful if there are launcher problems.

[dmikusa]

Thanks for reaching out!

So right now, we don't have the functionality to automatically detect the commands that you might want to run from a Rust app. There is an issue open for that though, so we will be able to do that soon.

In the meantime, what you need to do is to add a Procfile to the root of your application (i.e. the directory from which you run pack build or point to with -p argument). The Procfile is a simple text file with the format process-name: process-command (you can have as many lines like that as you want).

web: my-rust-web-app

TIP: the command can be anything on $PATH or anything you specify a full path to. Your rust apps are installed into /workspace which is also be on the $PATH, so you can reference just the app name or /workspace/app-name, your choice.

The buildpack will read this Procfile and use it to set up the process types. By default when you docker run, the launcher will look for a process type called web, so it's recommended you add one named web to your Procfile. Alternatively, you can add the --default-process <name> argument to pack build and it will set whatever process type name you want to be the default, like if you're not building a web app and you want to call it task.

---

Side note: pack build docker.io/abc/rust-webserver-app -b docker.io/paketocommunity/rust -B docker.io/abc/rust-builder --network=host --trust-builder --publish

You don't need to set both the builder and the composite buildpack. One is sufficient, whichever one you prefer. The composite buildpack is convenient because you don't need to build anything, we publish images for that. The builder can be convenient if you need a little extra control, or if you're building a lot of different Rust apps as you can set that to be the default builder used by pack and then you don't need either -b or -B. Neither is better just your preference.

Hope that helps!

[Shashankft9]

Hey, thanks for the detailed reply, I tried to follow the steps you mentioned, created a Procfile which looks like this:

web: webserver

and then, ran the pack build command, and this time it does pick up the process:

Paketo Procfile Buildpack 4.3.1
  https://github.com/paketo-buildpacks/procfile
  Process types:
    web: webserver

but still when I do docker run <image-name>, it fails with the same error. Although when I go inside the image with docker run -it <image-name> /bin/bash, I can find the binary in workspace/bin (but I see this binary even when there is no process detected).
Am I missing something?
Also, while building, there is one more warning, I am not sure if its actionable?

         Compiling webserver v0.1.0 (/workspace)
          Finished release [optimized] target(s) in 1m 13s
        Installing /layers/paketo-community_cargo/Cargo/bin/webserver
         Installed package `webserver v0.1.0 (/workspace)` (executable `webserver`)
      warning: be sure to add `/layers/paketo-community_cargo/Cargo/bin` to your PATH to be able to run the installed binaries

I tried changing the Procfile to use web: /workspace/bin/webserver or web: /workspace/webserver, but none of them are working.

Do I have to pass the binary path in the docker run command? I don't think I am supposed to do that - since that would be the ENTRYPOINT in the image built?

[dmikusa]

Although when I go inside the image with docker run -it /bin/bash, I can find the binary in workspace/bin (but I see this binary even when there is no process detected).

Sorry, my fault. The path where the binary is installed should be /workspace/bin/, so /workspace/bin/webserver in your case.

I think I was also confusing myself in thinking that /workspace/bin is added to the path. Again, apologize. I think that was something I had thought about or planned to do. Would that be helpful? Do you want me to add an issue to make sure it's on the PATH?

tl-dr; web: /workspace/bin/webserver is what you want in your Procfile. What happens when you set that, then pack build, then docker run? Can you attach the full output of both? I can take a look and see if anything jumps out as problematic.

As an FYI, I just did that with my test app and it was OK.

[Shashankft9]

Hey, so its working now, I guess in my testing I might not have given /workspace/bin/webserver correctly in the Procfile or I might not have pulled the latest image, I did it again now and its working - thanks a lot!
(I think pulling the latest image was really the fault here, because I was manually checking if the image is there in my machine and then pulling, and just now realised that the images are build with a timestamp of 41 years ago, so they were just in the bottom, I just the read the reason why its done and it makes sense).

I think I was also confusing myself in thinking that /workspace/bin is added to the path. Again, apologize. I think that was something I had thought about or planned to do. Would that be helpful? Do you want me to add an issue to make sure it's on the PATH?

I can probably put some time and try to fix that (I believe the change will have to be done somewhere in https://github.com/paketo-community/cargo ?), also add some details about Procfile in the Readme for the time being (until this feature is added paketo-community/cargo#29) if you'd want that?

Thanks for the detailed docker run commands, really helpful - appreciated!

Side note: pack build docker.io/abc/rust-webserver-app -b docker.io/paketocommunity/rust -B docker.io/abc/rust-builder --network=host --trust-builder --publish
You don't need to set both the builder and the composite buildpack. One is sufficient, whichever one you prefer. The composite buildpack is convenient because you don't need to build anything, we publish images for that. The builder can be convenient if you need a little extra control, or if you're building a lot of different Rust apps as you can set that to be the default builder used by pack and then you don't need either -b or -B. Neither is better just your preference.

I got that if I define a builder, then defining a buildpack is not really needed unless there is some custom buildpack I need, but when I only put a buildpack (composite in this case) wouldn't the pack build command still need a builder image for stack images? Or you meant that I should define the default builder using pack config and then just use the buildpack in the pack build command- because it gives me this error when I do it:

[root@k8s-master01 check-rust]# pack build docker.io/abc/rust-app-test -b docker.io/paketocommunity/rust-builder --network=host --trust-builder --publish
Please select a default builder with:

        pack config default-builder <builder-image>

Suggested builders:
        Google:                gcr.io/buildpacks/builder:v1      Ubuntu 18 base image with buildpacks for .NET, Go, Java, Node.js, and Python
        Heroku:                heroku/buildpacks:18              Base builder for Heroku-18 stack, based on ubuntu:18.04 base image        
        Heroku:                heroku/buildpacks:20              Base builder for Heroku-20 stack, based on ubuntu:20.04 base image        
        Paketo Buildpacks:     paketobuildpacks/builder:base     Ubuntu bionic base image with buildpacks for Java, .NET Core, NodeJS, Go, Python, Ruby, NGINX and Procfile
        Paketo Buildpacks:     paketobuildpacks/builder:full     Ubuntu bionic base image with buildpacks for Java, .NET Core, NodeJS, Go, Python, PHP, Ruby, Apache HTTPD, NGINX and Procfile
        Paketo Buildpacks:     paketobuildpacks/builder:tiny     Tiny base image (bionic build image, distroless-like run image) with buildpacks for Java Native Image and Go

Tip: Learn more about a specific builder with:
        pack builder inspect <builder-image>

Or perhaps you meant instead of creating a custom builder, i can use a generic builder like gcr.io/paketo-buildpacks/builder:base as default.

[dmikusa]

I can probably put some time and try to fix that (I believe the change will have to be done somewhere in https://github.com/paketo-community/cargo ?),

That would be fantastic! I created an issue here: paketo-community/cargo#113

I'll add a few helpful notes to that issue.

also add some details about Procfile in the Readme for the time being (until this feature is added paketo-community/cargo#29) if you'd want that?

Done. README updates, I appreciate the feedback.

I got that if I define a builder, then defining a buildpack is not really needed unless there is some custom buildpack I need, but when I only put a buildpack (composite in this case) wouldn't the pack build command still need a builder image for stack images? Or you meant that I should define the default builder using pack config and then just use the buildpack in the pack build command- because it gives me this error when I do it:
Or perhaps you meant instead of creating a custom builder, i can use a generic builder like gcr.io/paketo-buildpacks/builder:base as default.

Yes, sorry I should have clarified. You're correct. You do need a builder. The builder provides the build image, run image, and set of default buildpacks.

What happens when you set the -b argument to pack build is that pack will create an on-demand builder. It takes the build and run images from the specified builder or the default builder and pairs them with only the buildpacks you specify. This new dynamic builder is then used to process your application. Given this, if you are going to use the -b flag & a composite buildpack, all you really need out of a builder is a build and run image.

Because the Rust buildpack works with all three of the Paketo builders' build & run images (although tiny presently requires you to compile with MUSL libc, not GNU libc), you can simply set one of those as the default builder. Then you no longer need to specify a builder with every pack build command, just the composite Rust buildpack.

You're seeing the error you mentioned because you do not have a default builder set. If you run pack config default-builder paketobuildpacks/builder:base, that will set base to be the default. Base is a good mix of size and functionality, but you can pick a different stack if you prefer. You can run pack builder suggest to get a list of common stacks. I will say that I have only tested the Rust buildpack with the Paketo stacks, but it's possible it will work with other stacks or even a custom stack.

[Shashankft9]

I will have a look at the issue, and thanks for updating README, very helpful!