Exception: ERROR: failed to launch: determine start command: when there is no default process a command is required

[thangchung]

Hi admin,

I have managed to run pack build northwind-rs -e SQLX_OFFLINE=true -b docker.io/paketocommunity/rust command to build up the docker image using buildpacks. My pack version is 0.18.0+git-e00ee4a.build-2328, and I run it on Windows 10 OS.

It could run successfully and I could have the Docker image with the name northwind-rs, but when I tried to run it by docker then it throws the exception ERROR: failed to launch: determine start command: when there is no default process a command is required.

Could you guys let me know how can we overcome this exception?

My sample code is at https://github.com/thangchung/northwind-rs

By default, the present version of the buildpack lifecycle expects a process called web to exist. That is the default and what will run. You can either change the process name in your Procfile to be called web or you can change the default using the --default-process <name> argument to pack build. If you change the argument, <name> needs to match the process name in your Procfile.

So if your Procfile is:

task: run-command --my-arg 1 --my-arg 2

Then task is the name you'd passed to --default-process. Similarly, if you rename task to web then you don't need the argument because web is the default.

You can read more about launch processes and how they work here: https://buildpacks.io/docs/app-developer-guide/run-an-app/

Hope that helps!

[thangchung]

Thanks, @dmikusa for your reply.

In the rust app, I have run with the command cargo run --bin api when I run it in the development. So I don't know how to point --default-process <name> argument to pack build when I run it. I guess because of the --bin api make it couldn't find the web process to run

...
   Compiling actix-web-prom v0.5.1
   Compiling actix-files v0.5.0
   Compiling sqlx-macros v0.5.2
   Compiling hyper-tls v0.5.0
   Compiling reqwest v0.11.3
   Compiling sqlx v0.5.2
   Compiling northwind-rs v0.1.0 (/workspace)
    Finished release [optimized] target(s) in 7m 32s
  Installing /layers/paketo-community_cargo-install/rust-bin/bin/api
   Installed package `northwind-rs v0.1.0 (/workspace)` (executable `api`)
      Completed in 7m33.118s

===> EXPORTING
Adding layer 'paketo-community/cargo-install:rust-bin'
Adding 1/1 app layer(s)
Adding layer 'launcher'
Adding layer 'config'
Adding label 'io.buildpacks.lifecycle.metadata'
Adding label 'io.buildpacks.build.metadata'
Adding label 'io.buildpacks.project.metadata'
Warning: default process type 'web' not present in list []
Saving vietnamdevsgroup/northwind-rs...
*** Images (f601b4fc0af3):
      vietnamdevsgroup/northwind-rs
Adding cache layer 'paketo-community/rust-dist:rust'
Adding cache layer 'paketo-community/cargo-install:rust-cargo'
Successfully built image vietnamdevsgroup/northwind-rs

When I inspect my image after built, I didn't see any Processes Type, see the image below

Could you help to shed the light on my case? Thank you very much

[dmikusa]

Right now the Rust buildpack doesn't know how to detect what command to run. It's kind of complicated, so for the initial MVP we decided to just leave that up to the user (side note, there is an issue where I hope to explore auto-detection more).

At any rate, what you need to do is include a Procfile with your app. The Procfile contains the command that you want to run (you can actually put in multiple commands, like if your project produces multiple binaries or you have a secondary worker process). Anyway, when you pack build with a Procfile in the root of your project, the buildpacks will automatically set the process types on your image.

There's more on Procfile's here.

I have run with the command cargo run --bin api when I run it in the development. So I don't know how to point --default-process argument to pack build when I run it. I guess because of the --bin api make it couldn't find the web process to run

If you run locally with cargo run --bin api, then the command you want to set in your Procfile is api. The contents of your Procfile could look like this:

web: api

The buildpack when it runs builds your project and installs the binary, api in this case, on the PATH. Thus running apiwill execute your binary. Side note, you can'tcargo runin aProcfilebecausecargo` & the Rust compile chain are not present in the launch image (i.e. what you end up running). This is for security reasons & to keep image size small.

Hope that helps!

[dmikusa]

Anything else I can do to help on this one?

[thangchung]

I've managed to build it successfully with your suggestions. Thank you for that.

But the size of the docker image is quite big, it's near 7.2 GB. Look at below

I have .dockerignore file at root project, but it might not effect

.env
.dockerignore
spec.yaml
target/
deploy/
tests/
Dockerfile
scripts/
migrations/

Do we have any way to make it smaller?

[dmikusa]

Fantastic! Glad to hear it built for you.

In terms of the image size, that sounds very high. The Rust buildpack puts very little into the resulting launch image, basically just your binaries. So the image size should be the builder's run image size + your binaries. The default builder uses the paketo base image, which is around 140M.

My suggestion would be to use dive and look at the image to see what's in it. Then you can work on stripping that out. Let me know what you find as well.

You are correct in that pack will not skip files based on the .dockerignore (or any other ignore file). It looks for a project.toml file, which among other things can contain either a list of files to include or a list to exclude. See the docs for that here -> https://buildpacks.io/docs/app-developer-guide/using-project-descriptor/.

[thangchung]

Thanks for your help!

I've found the problem that causes it after use dive as you suggested

target folder at the root project occupied around 6.5 GB

I created the project.toml at the root project to ignore it

[build]
exclude = [
    "target"
]

And after running the pack build command again, the size of the image down to 706 MB

It comes up with me a little concern that why don't we ignore the target folder by default? It's always auto-generated after we build the solution on the local machine.

[dmikusa]

It comes up with me a little concern that why don't we ignore the target folder by default? It's always auto-generated after we build the solution on the local machine.

The pack cli is a generic tool for all languages, so it cannot skip anything besides what you tell it to skip.

I do think the buildpack can help to some degree. It can make sure that the target directory doesn't end up inside your launch image (I'll add an issue for that). It will generally be faster though if pack doesn't have to copy the target directory into the container, as target tends to be multiple GB and copying all those files takes time.

I'm going to close this one out. If you have more questions or feedback, please feel free to open another issue. Thanks!