Support using the base image ENTRYPOINT and starting the application through CMD

[tmds]

Some base images (like those provided by Red Hat) have a container ENTRYPOINT that performs some initialization before running the CMD.

The current logic supports figuring out the ENTRYPOINT so it starts the .NET application.

Can the logic be extended so it is possible to choose to start the application using CMD?

cc @baronfel @richlander @omajid @aslicerh

[baronfel]

Definitely down for reworking this - the intent here was to simplify for most use cases, but we can definitely make this able to be more explicitly defined. I'm mostly concerned about end-user confusion about the purpose/difference between ENTRYPOINT and CMD. I'd want to make sure that we are super-clear on the happy-path. What kinds of scenarios would you like to be able to support?

[tmds]

I'm mostly concerned about end-user confusion about the purpose/difference between ENTRYPOINT and CMD. I'd want to make sure that we are super-clear on the happy-path. What kinds of scenarios would you like to be able to support?

When a container is running what gets executed is: ENTRYPOINT COMMAND. COMMAND is what the user specifies as podman run <COMMAND>, and defaults to the Dockerfile CMD.

Some images (like Red Hat .NET images), have an ENTRYPOINT script that does some initialization actions before executing COMMAND.

The SDK tooling currently always emits an ENTRYPOINT, which means it skips the entrypoint script from our base image.

This is a request to make it possible to emit a CMD instruction so the entrypoint script does not get skipped.

The default behavior of the SDK can still be to emit an ENTRYPOINT, and have an opt-in to emit a CMD instead. Or, if the tooling wants to be "smart": it can use a CMD when the base image has an ENTRYPOINT.

[tmds]

@baronfel I hope the difference between ENTRYPOINT and CMD are clear, and why sometimes CMD is preferred to ENTRYPOINT?

Using ENTRYPOINT by default is appropriate. The request here is: a toggle that opts-in to use CMD instead.

[baronfel]

Yep - all clear now. Thanks for following up! We'll have to think about what that signal would look like - would the presence of user-added ContainerCommand items be enough of a signal?

[tmds]

We should allow the tooling to figure out the command to start the app also when it is emitted as a CMD.

If I ignore backwards compat, I'd suggest something like:

<ContainerCommand> = command to launch the app
<ContainerCommandInstruction> = Entrypoint
<ContainerEntrypoint> = ContainerCommand when ContainerCommandInstruction == EntryPoint
<ContainerCmd> = ContainerCommand when ContainerCommandInstruction == Cmd

(The assignments show the default values.)

[baronfel]

Note to Chet: The Entrypoint/Command toggle is a property of each image, and could potentially be set during image inference. MS images would use Command, RedHat's for example use Entrypoint.

[tmds]

While making some contributions to the container tooling, I've learned the tooling is aware the base image has an entrypoint. It would make sense for the default behavior to be to emit a CMD instruction when there is an entrypoint, and an ENTRYPOINT when there isn't.

Proposal:

<ContainerAppCommand>
<ContainerAppCommandInstruction>

ContainerAppCommand defaults to the exec args required to start the .NET app.
ContainerAppCommandInstruction defaults to use an ENTRYPOINT when the base image has no entrypoint, and CMD when the base image has an entrypoint. It can be set explicitly to Entrypoint/Cmd to force a specific instruction.

@baronfel what do you think?

[baronfel]

This proposal seems good to me - we need to consider back-compat though. Existing ContainerEntrypointArgs items should be used as the default for the new ContainerAppCommand item group, and a message/warning should be emitted here describing the new item. Then as you say we should determine Entrypoint-vs-Command during base image inference.