Вадим

В данном случае это оправдано.
Кали по сути дебиан, только знающие люди собрали для вас нужные инструменты, ну и это отраслевой стандарт.

Есть два варианта:
1. Экранировать обратным слешем проблемные символы (кавычки и обратный слеш):

multiline = '''
report_number=$(head -n 1 "/root/cron_job_enumerator.txt" | tr -d \'\\n\')
'''
print(multiline)

2. использовать префикс строк r, который не дает обрабатывать содержимое строки, заставляет воспринимать ее как есть (тогда отдельные символы экранировать не надо):

multiline = r'''
report_number=$(head -n 1 "/root/cron_job_enumerator.txt" | tr -d '\n')
'''
print(multiline)

Добавь заголовки запроса, в качестве реферера поставь тот же URL.
Как это сделать, читай в доках requests.

Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
Объективно есть 2 причины пилить. Первое - организационная. Команда по какой-то причине не хочет
или не может поддерживать приложение. Или там что-то с бизнесом. Слияние. Поглощение. Передача
проекта другой команде в поддержку. Тогда берут и ставят задачу раздела отвественностей.
Конвей про это писал еще.

И второе - это баланс нагрузки и децентрализация. Про failover тут еще даже речи нет. Это
тяжелая тема и распилить монолит так чтобы его части были отказоустойчивы очень трудно. Более
того в случае синхронных взаимодействий между частями микросервисов может быть даже падение
перформанса. Да. Теоретики которые там пишут восторженные отзывы - совершенно игнорируют
накладные на RPC. И не упоминают что в монолите цена RPC была равна нулю. Иногда RPC заменяют
на MQ - но это новая архитектура и это надо полностью переделывать бизнес.

И что делать с базой данных? Это тот еще вопрос. Я почти готов спорить что вы базу пилить не будете.
И что в результате будет? Иммитация микро-сервисов? Где слабая связность?

Тоесть если у вас нет таких кричащих ситуаций что оргазниация требует или нужно баланс
нагрузки как-то разнести - то тебе вообще-вообще нет смысла ходить ни в какие микросервисы.

Но имеет смысл сделать модуляризацию монолита. Например что там...

application
- sales
- hiring
- userprofiles

Тоже очень полезно для управления сложностью. И пускай себе будет монолит зато будет сильный
контроль за изменениями.

В крон на 00:00 добавляете запуск

/usr/bin/sleep $((`/usr/bin/od -An -N2 -t u2 /dev/random` % 3600)) && ваша_задача

Директория app находится на два уровня выше директории php в которой размещён Dockerfile - поменяй путь в директиве COPY
И WORKDIR /app создаёт директорию и делает её текущей, так что должно быть COPY ../../app .

PS
Никогда не используй Alpine образы ни для чего - этот дистрибутив оптимизирован для встраевыемых устройств с единицами мегабайт оперативной памяти и процессором с одним ядром, там вместо libc использован суррогат musl с неэффективным на б̀ольших объёмах памяти аллокатором, к тому же она не так сильно распростронена, как libc, что увеличивает вероятность столкнуться с чем нибудь вроде segmentation fault. К тому же часть пакетов в собранном виде отсутствует из-за чего во время установки происходит их сборка, что занимает значительное время, да и образ в итоге получается очень большим (компилятор то никто не умеет настраивать)

Используй debian-slim и PHP устанавливай из Sury репозитория - установка произойдёт очень быстро, а итоговый образ будет компактным (если, конечно, не забывать стирать списки пакетов и кеши на том же слое, где они были созданы)

PPS

# Remove Cache
RUN rm -rf /var/cache/apk/*

Удалять что либо на следующем слое бесполезно - там Copy on Write файловай система и всё что было на предыдущем слое создано там и останется

Лучше брать такой, который продается с предустановленным линуксом. Геймерский для ваших целей точно не нужен. С большей долей вероятности нормально работать будет ноут попроще, из корпоративного сегмента. Типа HP ProBook, например. Проблемы обычно возникают с драйверами для экзотических устройств, так что чем меньше экзотических устройств - тем меньше проблем.

Приложение же состоит из одного файлика index.php и выводит текст "Hello World!".

php не умеет выводить текст в браузер. Это значит что в первом докерфайле уже устанавливается какой-то веб сервер, возможно httpd

можно конечно просто установку nginx-а в первый докерфайл перенести, но надо разобраьтся как его состыковать с php-fpm.

А еще проще найти готовый. связка nginx с php достаточно стандартная сборка, уверен есть официальный образ, еще и не один от разных вендоров.