Я бы предложил переосмыслить весь подход этого Dockerfile: вы не можете запустить демон Docker в Dockerfile и не можете запустить какой-либо фоновый процесс. Сценарий оболочки, который запускается на хосте, может быть лучше.
Запуск любого вида демона внутри Dockerfile в основном не работает; в конце каждой инструкции RUN
все запущенные процессы завершаются. Создание образа Docker не сохраняет никаких запущенных процессов, только конечная файловая система и метаданные, такие как CMD
по умолчанию для запуска при запуске контейнера. Поэтому, даже если docker-compose up
сработает, результаты этого не будут сохранены в вашем образе.
Запуск демона Docker внутри контейнера Docker затруднен и, как правило, не рекомендуется. (Совместное использование сокета Docker хоста имеет существенные последствия для безопасности, но является предпочтительным подходом.) В любом случае требуются некоторые дополнительные разрешения, которые опять-таки просто недоступны в Dockerfile.
Другой красный флажок для меня здесь это строка RUN git clone
. Из-за кеширования слоя Docker он с радостью скажет: «О, я уже RUN git clone
, поэтому мне не нужно повторять этот шаг», и вы не получите текущий код. Подача учетных данных для удаленных git репозиториев в Dockerfile также сложна. Я также рекомендовал бы запускать команды управления исходным кодом исключительно на хосте, а не в Dockerfile.
Стандартный подход здесь заключается в том, чтобы зафиксировать файл docker-compose.yml
в верхней части вашего хранилища, а также запустить git clone
и docker-compose up
прямо с хоста. Вы не можете использовать Dockerfile как инструмент автоматизации общего назначения.