Patch in docker-entrypoint.sh

[erickhgm]

Hi,

I think it would be very useful to have a patch in the docker-entrypoint.sh file.

Something like this:

#!/bin/sh -e
export DJANGO_SETTINGS_MODULE=$SERVICE_VARIANT.envs.$SETTINGS

{{ patch(“docker-entrypoint”) }}

exec “$@”

I can do a PR with you agree @regis.
Is there a tutorial to help in the project setup and steps/rules to contribute?

[regis]

Hey @erickhgm,
Thanks for the proposal, I’m totally up for it. May I suggest that you name the patch “edx-platform-docker-entrypoint” “openedx-dockerfile-entrypoint”? Also, maybe wait for this PR to be merged such that you can easily document this patch.

[erickhgm]

Right, it’s ok for me.
I will take a look at this PR, I didn’t know this change was happening.

[regis]

Wait, actually: I’m currently in the process of getting rid of the edx-platform entrypoint altogether. Is it ok for you to define your custom entrypoints elsewhere? For instance:

1. As docker-compose.yml arguments.
2. By implementing one of the existing openedx-dockerfile-* patches.

[erickhgm]

Yeah, I’m able to use it, but I need to understand how things will work in v1 to adapt it.

If the line with ENTRYPOINT [“docker-entrypoint.sh”] won’t exist anymore, prolably I will keep the entrypoint using a patch, put all commands in docker-compose command/arguments doesn’t look very nice.

Don’t worry, when the v1 is available I will check and see if my needs have been met. If I have a contribution I let you know.

[erickhgm]

Hello @regis, the Plugins v1 was a great upgrade!
I’m analyzing all the changes to understand and upgrade my Open edX instance.

But continuing with the question about the docker-entrypoint.sh …

I was taking a look at the commit get rid of the openedx Docker entrypoint and I liked it!
Removing the DJANGO_SETTINGS_MODULE from the docker-entrypoint.sh was good, when I first tried to run a command in LMS/CMS container instance I spent a time finding the reason ./manage.py commands weren’t working. But in the end, I noticed that I need to set the DJANGO_SETTINGS_MODULE environment variable.

However, I think would be useful if we keep the docker-entrypoint.sh but without the line below.

export DJANGO_SETTINGS_MODULE=$SERVICE_VARIANT.envs.$SETTINGS

Motivation
In my case, I need to run a script before the CMD command (before Open edX start):

# Run a custom script
./my-script.sh

# Start Open edX
CMD uwsgi \
    --static-map /static=/openedx/staticfiles/ \
    --static-map /media=/openedx/media/ \
    --http 0.0.0.0:8000 \
    --thunder-lock \
    --single-interpreter \
    --enable-threads \
    --processes=${UWSGI_WORKERS:-2} \
    --buffer-size=8192 \
    --wsgi-file $SERVICE_VARIANT/wsgi.py

With this will be easy to add any script or code before Open edX starts and as we don’t have the DJANGO_SETTINGS_MODULE being set there, this won’t be a problem like before.

Something like this:

#!/bin/sh -e
{{ patch(“openedx-dockerfile-entrypoint”) }}
exec “$@”

What do you think?

[regis]

I think that if you need to modify the “production” stage of the openedx Docker image then you need to insert a {{ patch(...) }} statement at the very bottom of the Dockerfile. Would you like to open a PR?

(note that it’s better to have that patch after the CMD statement, because it allows you to override it. CMD statements may be placed anywhere in the Dockerfile, but only the last one is taken into account)

EDIT: it looks like someone is already working on adding a patch in the Dockerfile: feat: configurable uwsgi buffer-size by danielrudn · Pull Request #612 · overhangio/tutor · GitHub

[erickhgm]

Sorry, maybe my example wasn’t very clear …

I don’t want to overwrite the CMD in Dockerfile or modify some stage, I need to execute a script at runtime (container initialization).

Using this path in the PR is possible as well but it would be a little different.

I would have to do something like this:

plugin content

COPY --chown=app:app ./custom/bin/docker-entrypoint.sh /openedx/bin
COPY --chown=app:app ./custom/bin/my-script.sh /openedx/bin
ENTRYPOINT ["docker-entrypoint.sh"]

docker-entrypoint.sh content

#!/bin/sh -e
my-script.sh
exec “$@”

Note: I could use only one script direct in the docker entrypoint, but in this way would be more organized if I need do/run more than a task.

For example:

#!/bin/sh -e
my-script-1.sh
my-script-2.sh
my-script-3.sh
exec “$@”

[regis]

What you are describing seems totally doable without any further change to Tutor core itself, outside from merging that PR. It used to be impossible with the v0 plugin API, because you could not render plugin files to arbitrary folders. But now, with the plugin v1 API you can render your docker-entrypoint.sh right next to the openedx Dockerfile.

Do you understand what I mean?

[erickhgm]

Yes, I understand, but I’m not able to visualize how to achieve this result.
I still have v0 in my mind …

@regis Can you show me an example?