Я согласен с комментарием, в котором говорится, что вам нужно сделать скрипт script_runner. sh исполняемым скриптом, что, вероятно, стало причиной кода возврата 127. Тем не менее, я думаю, вы обнаружите, что он все равно не будет работать даже после того, как вы сделаете его исполняемым.
В момент выполнения RUN script_runner.sh test
сервер MySQL фактически не будет работать внутри Docker контейнер во время процесса сборки. Поэтому, если вы сделали сценарий исполняемым, я думаю, вы увидите, что он вернет ошибку типа «не удается подключиться к mysql sock». Вы должны запустить mysqld как часть вашей Docker сборки. Также помните, что сборка docker будет выполнять каждый оператор RUN самостоятельно и вносить изменения в слой диска после завершения этой команды. Если вы просто попытаетесь выдать RUN mysqld
(или аналогичный), либо процесс mysqld запустится и навсегда заблокируется (при условии, что он не демонизируется), либо (если вы скажете ему демонизировать), он запустится и, как только он переместится на заднем плане docker создаст слой диска и затем выполнит ваш script_runner.sh
, но mysql завершится.
Если вы хотите сделать это, у вас есть два варианта:
- Объедините два в один оператор RUN, такой как
RUN mysqld_safe && script_runner.sh
- Ваш скрипт_runner. sh Запустите mysqld, прежде чем он попытается выполнить mysql клиента.
В любом случае должен работать и, как мне кажется, в конечном итоге один и тот же слой изменений диска. Документы касаются этого в своих рекомендациях передового опыта (хотя здесь они пытаются минимизировать количество слоев по соображениям производительности):
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#minimize -the-количество-слоев