Image has no entry point

[dsyer]

This used to work. Not sure what changed, but I don't think it was anything I did.

$ pack build dsyer/app --builder dsyer/builder --no-pull
$ docker run -p 8080:8080 dsyer/app
docker: Error response from daemon: No command specified.
See 'docker run --help'.
$ docker inspect dsyer/app
...
            "Entrypoint": null,
...

The image is fine apart from the entry point, so I can run it if I provide on manually, i.e. docker run dsyer/app /lifecycle/launcher web.

[nebhale]

Yeah, this definitely seems to be a regression. We'd talked about removing the defaulting of web, but the Entrypoint shouldn't have been removed.

[sclevine]

Are you using a base image that sets PACK_PROCESS_TYPE? Without that env var, no ENTRYPOINT will get set.

[ekcasey]

@sclevine I thought the entrypoint should always be the launcher regardless of PACK_PROCESS_TYPE. I think right now app images are inheriting that entrypoint from the stack run image https://github.com/buildpack/lifecycle/blob/master/images/run/Dockerfile#L14. Is this something we would want the exporter to do in the future? In either case, I think we should clarify the contract between the stack and the lifecycle.

@dsyer setting entrypoint on your stack run image should fix the issue.

[sclevine]

@ekcasey We're both half-right. The current stacks set the ENTRYPOINT of the run image, but the spec says that the exporter should do this: https://github.com/buildpack/spec/blob/master/buildpack.md#phase-4-export

I opened an issue against the spec here: buildpacks/spec#15

[dsyer]

setting entrypoint on your stack run image should fix the issue.

Do I know what the run image is?

UPDATE: Found it in ~/.pack/config.toml.

[sclevine]

Update from WG meeting on 2018-10-16:

We decided that the exporter should be responsible for adding the launcher to the run image and setting the ENTRYPOINT (during the export phase).

This is important to guarantee that the builder and launcher lifecycle components are always compatible for a given image.

Will follow up with a PR for buildpacks/spec#15.

[sclevine]

The pack CLI now handles this correctly.

[ekcasey]

@sclevine This work correctly on master of lifecycle but I believe we need to release new v3alpha2 images before pack will handle this correctly

[jicowan]

@sclevine I wrote a simple Python Tornado application. When I tried running the image that the buildpack created I got the following error:

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

The entrypoint is set to:

"Entrypoint": [
                "/lifecycle/launcher"
            ],

If I run:

docker run -it -d -p 8080:8888 tornado:v1.0 python main.py

then it works. Is this expected?

[sclevine]

This is the expected behavior when the buildpack doesn’t set a start command. What buildpack are you using? Python doesn’t have a widely adopted convention for an entry file, so Python buildpacks often don’t set a default command.

[jicowan]

Is there a way to tell whether the buildpack sets a start command? I see that a Dockerfile is not generated when you do a build. I'm using the Heroku buildpacks. I think it selected 18 if that makes sense.

[sclevine]

It’s the buildpack’s responsibility to warn you. @hone works at Heroku and might be able to direct your question to the right folks.

As a workaround, you could use docker inspect to examine the CMD property.

(We generate OCI images without using Dockerfiles at all. This lets us reuse arbitrary layers from previous builds and avoid downloading layers that only need to be reused at runtime. It also means we can build reproducible images in unprivileged containers.)