and then in my render.yaml I’ve specified dockerCommand: /home/start-gunicorn
the odd thing is that I have some echo commands in my entrypoint script, and I’m not seeing the output in the logs for my service. It seems as though my entrypoint script isn’t running. Another bit of evidence that supports this, is that my app depends on an environment variable that’s exported by my entrypoint script, and the app is crashing due to that environment variable being undefined.
And of course it works on my machine… when I run my container using docker run <my-image> /home/start-gunicorn (not overriding the entrypoint) it’s clear that the entrypoint script does run; I can see the output of the echo commands and the app doesn’t fail.
So maybe Render is overriding the entrypoint of Docker containers?
If so, I’d be curious why, and whether that could possibly change, and also I’d like to see this added to the documentation.
If not, then I’d love some suggestions as to some other reason why it seems as though my entrypoint script isn’t running.
This design is similar to using ENTRYPOINT or CMD in docker run, except Render doesn’t support appending arguments to ENTRYPOINT in Dockerfile.
You can add a feature request and we will prioritize it.
Thanks.
Thanks for confirming. At least I know I’m not crazy!
I’d be happy to create a feature request, but first I’d like to understand the rationale a bit behind the current behavior/design. I find it quite surprising and unintuitive, which is the reason for my hesitant/tentative tone in my top post.
To elaborate: I feel that any platform that supports Docker should support the full, complete, and unchanged semantics of Dockerfiles, with no changes, deviations, or qualifications. This is important because portability is one of the key value propositions of using Docker containers in the first place. For example, I recently created an ECS+Fargate service, and the “tasks” (container instances) started by service respect the ENTRYPOINT directive in my Dockerfiles, as I would expect; if I specify a command in an ECS “task definition” it only overrides the CMD directive in a Dockerfile. This is consistent with how the docker CLI works: if I execute docker run my-image <command> then the <command> only overrides the CMD directive, not the ENTRYPOINT directive. In other words, these two aspects of a Docker image are defined independently and are only useful when they can be set independently.
The downside of Render deviating from those semantics of Dockerfiles and the Docker CLI is that it’s one more thing I have to change in order to port a service to Render. (Once I even figure out what’s happening and what I have to change and why, see below.) This makes it harder to port a service to Render, and harder to make the case for doing so to my team members and peers across my org. And my impression is that this pattern of using the ENTRYPOINT directive to specify a non-default entrypoint for a container is not rare, unusual, or esoteric — I see it all over the place.
This seems so obvious to me that I’m sure I must be missing something — there must be some good reason that Render deviates from the standard semantics of these directives. So what am I missing? What’s the rationale behind the current behavior?
In the meantime, I suggest you update the docs to clarify this behavior. I’m using render.yaml so I never saw the copy in the UI you screenshotted. I searched your docs for “entrypoint” and got no hits. Specifically, I suggest you add this info to both the page on Docker and the page describing render.yaml in detail.
