scor2k

Раз уж вы все равно делаете свой велосипед, сделайте так, чтобы приложение, которое вы запускаете, было запущено постоянно на хосте и имело какой-нибудь порт опубликованным. Дальше - проще. Из Cron-а стучитесь на этот порт curl'ом с нужной периодичностью, а обработчик из приложения уже будет запускать вашу задачу.

Не совсем по теме, конечно, но скажу. Зачем Вам 1400 шардов для единого инстанса эластика, особенно при размерах индекса от 5 до 500мб? По рекомендациям производителя, размер шарда, при котором требуется шардирование (прошу прощения за тавтологию), около 50Гб... Опять же, для 4Гб 300 индексов это прям очень не слабо, т.к. эластик держит много информации в памяти. Оптимизируйте или дайте ему больше ресурсов.

А что Вы пытаетесь POST'ом на index.html отправить? Как вы это обрабатывать собираетесь?

Возможно я не прав, так как реального опыта реализации указанной вами схемы у меня нет, но в случае с Jenkins, надо для начала убедится что он поддерживает такой режим работы. Основная проблема работы в кластере - это отсутствие нативной поддержки ))

P.S. Буду рад ошибиться и подожду ответа )

Как вариант, не гонять через RabbitMQ весь запрашиваемый и отправляемый объем данных, а отправлять только идентификатор. Сами данные хранить в базе.

Вы определитесь куда хотите развиваться-то... devops это одно, контейнеризация - другое.

DevOps - это автоматизация сборки и доставки приложений. Изучайте какую-нибудь CI среду, например gitlab популярен последнее время. Для CD тоже что-нибудь типа ansible можно. Вряд ли вы сразу не Kube пойдете...

По контейнерам все же docker будет в приоритете, ставьте виртуалку (а лучше поднимите её на одном из физических серверов) и вперед. Опять же, в гитлабе есть свой registry, хотя, правильней, поднять отдельно.

В любом случае - невозможно взять и сразу все начать делать. Выберите цель, разбейте на задачи и изучайте. Удачи.

Если только начинаете - посмотрите в сторону docker-compose. Опять же - наличие .env файлов с возможностью наследования позволит вам запускать ваши сервисы на разных средах (тест, прод), а если решитесь использовать service discovery (лучше решить сразу, потом будет сложно переехать) - то часть конфигов будут динамическими.

P.S. От Kubernetes у вас будет взрыв головного мозга на старте (имхо), а от docker-compose до swarm сможете дойти, если потребуется.

У Вас же в логах все написано - ядро не поддерживает параметры, требуемые докером. Попробуйте обновить ядро для начала.

Вместо ADD можете попробовать использовать COPY.
Ну и как вам уже написали, правильней собирать сначала docker image, а потом делать рестарт... в идеале вообще использовать docker-compose для управления проектом.

Что-то мне подсказывает что выбор технологии тут не особо корректный. Я бы посмотрел в сторону терминального Linux-сервера (кластера серверов).

Для начала проверьте с хоста доступ до БД. Вам писали выше что порт 3306 должен быть доступен на localhost. Если доступ с паролем вашего docker-compose работает, тогда смотрите настройки сервиса `app`, возможно вы там используете не правильные данные для подключения.

Ну и для сервиса `app` добавьте параметр

links:
 - "database"

Я бы написал какой-нибудь start-скрипт в docker, который бы скачивал ваше python-приложение с фиксированного места при старте.

Судя по этому топику - нет.