The entrypoint script checks for the existence of `docker-entrypoint.d` in the CWD, but then run the scripts in `/docker-entrypoint.d`.
This causes the scripts to either not run at all or fail if an inheriting image changes the `WORKDIR`.
This fix makes sure the directory is always expected in the filesystem root.
As we are now installing uwsgi via pip these plugins are shipped as part
of the code and there's no need to load the plugin, otherwise you get
these alarming (but harmless) messages:
open("./http_plugin.so"): No such file or directory [core/utils.c line
3721]
!!! UNABLE to
load uWSGI plugin: Error loading shared library ./http_plugin.so: No
such file or directory !!!
open("./python_plugin.so"): No such file or directory [core/utils.c line
3721]
!!! UNABLE to
load uWSGI plugin: Error loading shared library ./python_plugin.so: No
such file or directory !!!
open("./gevent_plugin.so"): No such file or directory [core/utils.c line
3721]
!!! UNABLE to
load uWSGI plugin: Error loading shared library ./gevent_plugin.so: No
such file or directory !!!
The current way requires an `extra_scripts.sh` file to be present in on
children images.
With this approach a new folder `/docker-entrypoint.d` is created when
an image extends this one. The children image can then copy any shell or
python file that they want executed at the start of container in that
directory.
For instance consider the following setup:
```
cloud-mysite
├── .env
├── docker-entrypoint.d
│ └── 00_setup_validation.sh
│ └── 01_check_users.py
└── Dockerfile
```
The `Dockerfile` will look like:
```
FROM keitaro/ckan:2.8.1
[...]
COPY docker-entrypoint.d/* /docker-entrypoint.d/
```
The files will be executed in alphabetical order.
Shahar Evron
Konstantin Sivakov
Dragan Bocevski
Marko Bocevski
amercader
Pance Ribarski
Petar Efnushev
Marko Bocevski
Petar Efnushev