Using caddy as entrypoint

[ebati]

You can use caddy command as ENTRYPOINT and give default options in CMD that would simplify running with other options and also remove duplicate caddy (one for image name one for executable name) in examples.

[hairyhenderson]

@ebati you are correct. Is this a request to do that, or is there a use-case that you need to enable with this?

Setting ENTRYPOINTs can be a bit tricky to deal with unless there's a good entrypoint script written to handle all the different ways an image could be called. It's important (especially in an official image) that users be able to just do something like docker run caddy /bin/sh to troubleshoot or explore.

I did have an entrypoint script at some point (in #8, though some of the history is lost), but there were some difficulties in getting it to work with all cases. We discussed the specifics and for now it seemed a fair tradeoff to just accept the repetition of the word caddy in the command 😉

That being said, I wouldn't be opposed to accepting a PR that includes a well-written entrypoint script that:

• accepts all Caddy subcommands and flags correctly (this'd probably need some changes to the caddy command itself to be able to report what subcommands it supports)
  • this would likely need a PR to be supplied to the main caddy repo, and of course @mholt would need to be on board - it's a fairly niche usage for this one specific script!
• allows users to run arbitrary other commands (like /bin/sh, or just sh, or ls, or whatever...)
• forks the process (with exec)

[mholt]

I'm not super inclined to change the command package to accommodate a niche use case at this point, but if there's a compelling reason to, we can definitely consider it as long as it's backwards-compatible.

(this'd probably need some changes to the caddy command itself to be able to report what subcommands it supports)

caddy help

[francislavoie]

I think it would be reasonably simple to have a caddy help --commands that spits out a (tab?) delimited list of the supported commands (to make scripting easier)

[mholt]

Probably newline-delimited. Does it need the command descriptions too?

[francislavoie]

IMO no, we only need to know the words that need to be allowed to pass through to the caddy command, and anything else gets executed as-is in the container. Anything extra would just make it a bit more tedious to parse (not really that hard, bash is powerful, but simplicity is ideal here IMO)

[hairyhenderson]

So @francislavoie and I are chatting about this in Slack and it may be possible to accomplish this in a way similar to how traefik does it.

Basically it depends on caddy <subcommand> --help exiting with a different code depending on whether the subcommand is valid or not.

In Caddy's case, we get a 2 when help is printed, so it'd require a slightly different script. But I think it's probably worth it...

Note that it does involve slightly more execution time though. 🤷‍♂️

[ebati]

I must be missing some point but ...

Can't we just give caddy command as ENTRYPOINT ["caddy"] and add CMD ["run", "--config", "/etc/caddy/Caddyfile", "--adapter", "caddyfile"] (which are the current default parameters). If someone wants to run any other command they need to change entrypoint by docker run --entrypoint /bin/sh caddy. If they want to change options they can give the arguments, for example to get the help message docker run caddy help

By the way, I don't want to waste your time, if this requires a complex script, we can just close this issue as this is not something important. 😄

[francislavoie]

Having to override the entrypoint like that isn't as nice I'd say.

[ebati]

You are right, use case with override is not nice. But I think most people will use this image without changing entrypoint, as this is a single purpose image.

[hairyhenderson]

By the way, I don't want to waste your time, if this requires a complex script, we can just close this issue as this is not something important. 😄

This absolutely isn't a waste of time! While it might seem like it's not very important, you're not the only one to want this, so it is IMO worth exploring.

But I think most people will use this image without changing entrypoint, as this is a single purpose image.

It's important that we support a better user experience with this image, since it's an official Docker image. It needs to behave similarly to other official images, which quite often have entrypoint scripts.

And regardless of those reasons, the current image behaves a certain way, and I think it's most crucial that we not break current users.

[serverwentdown]

Official reference: https://github.com/docker-library/official-images#consistency

[hairyhenderson]

Thanks for the link @serverwentdown

[rugk]

Official reference: https://github.com/docker-library/official-images#consistency

So if I read that correctly, this supports the argument that ENTRYPOINT should be used, should not it?

[serverwentdown]

@rugk I would say that by Docker recommendations, the caddy docker image ships with a shell and therefore the entrypoint shouldn't be caddy (point 3).

And since no initialisation is necessary before running caddy in the caddy docker image, an entrypoint script is not very necessary (point 2).

So I'd think better to keep it simple with no ✨magic✨ entrypoint involved.

But, traefik's entrypoint is a neat solution!

[rugk]

Oh yeah, you're right, then it is indeed "If the startup process does not need arguments" (point 1) and the thing is fine as it is…

I wodner what exactly the use case of the OP was here. Even with CMD you should be able to run caddy as docker run official-image --arg1 --arg2 (as the guide says), so what is the actual problem here, …?

---

Ah also looking at traefik now again and yeah, that's sleek…