Change Dockerize installation method.

[Squirrel18]

Hello, everyone!

I would like to understand/propose a change in the Dockerfile for openedx, specifically regarding Dockerize.

Background:

For one of our Open edX installations, we are required to use Docker Business accounts that restrict the use (pull) of unofficial or unverified images by Docker. This makes the build of openedx images impossible unless the restriction is lifted which for some enterprise users of OpenedX is not possible. Not only this is a problem for us at the moment, but I see it as a barrier for enterprise customers, as operators will not be able to build OpenedX images unless they use unapproved workflows.

P.S.: Tutor images (and most Open edX images) are also subject to the above restriction, but I think that's a topic for another conversation, however has verifying Tutor/Open edX images ever been considered? Just a question.

Proposal:

Firstly, I would like to know if Dockerize is necessary for the openedx image and Tutor, as it is only used in init jobs: https://github.com/overhangio/tutor/blob/main/tutor/templates/jobs/init/lms.sh#L1 https://github.com/overhangio/tutor/blob/main/tutor/templates/jobs/init/cms.sh#L1 and apart from that, I believe it is not used elsewhere and for most installations, Dockerize will only be useful when running init jobs (probably only once for each installation). I do not have any specific proposal to replace Dockerize, but I believe it is part of the debate to consider it.

The main proposal is to install Dockerize using the binaries instead of the image:

RUN mkdir -p /openedx/dockerize/bin && \
    
curl -sfL https://github.com/powerman/dockerize/releases/download/v0.24.0/dockerize-`uname -s`-`uname -m` | install /dev/stdin /openedx/dockerize/bin/dockerize

ENV PATH=/openedx/dockerize/bin:${PATH}

This will revert this change: #913 which, as I understand it, was introduced as an improvement, although I am not sure what the actual improvement is in optimising this particular step.

Installing Dockerize using the binaries will not cause any restrictions on Docker business accounts and will not change the way Tutor currently runs init jobs or builds the openedx image.

Alternatives.

1. As I mentioned in the background section, one alternative is to remove the restriction on the Docker business accounts, but for most large enterprises, this is a decision that must go through many layers of bureaucracy and cybersecurity practices, making it nearly impossible to choose this alternative.
2. Perhaps completely removing the use of Dockerize, but my initial proposal is to change the way it is installed, although I think it is important to consider this point.
3. Leave it as is. As I mentioned, I believe this will create a barrier for some enterprise installations that have very strict restrictions and workflows, so I believe that reducing this small barrier will benefit some current and future installations.

Please, let me know if you need more information. I appreciate any insight on this, thanks in advance!.