докер не шедулер

да чего вы спорите - это просто не решенная пока что проблема :))

Нельзя просто так взять и задублировать кучу контейнеров внутри которых шедулер.

да чего вы спорите - это просто не решенная пока что проблема :))

я не понимаю почему докер должен решать вообше эту проблему

да чего вы спорите - это просто не решенная пока что проблема :))

так мы в поисках :)

Нельзя просто так взять и задублировать кучу контейнеров внутри которых шедулер.

потому что это не проблема докера, а проблема твоего приложения

я не понимаю почему докер должен решать вообше эту проблему

боже упаси

я не понимаю почему докер должен решать вообше эту проблему

я же написал из всех зол выбрал дженкинс :)

Это задача твоего приложения уметь определять условия в которых что-то не может запуститься

И как конкретно ты будешь это делать — к докеру вообще никакого отношения не имеет

Потому что это уровень приложения

я не понимаю почему докер должен решать вообше эту проблему

он не должен, но он здесь прямо завязан. Взять самое популярное php приложение. PHP и все его кишки настроены в контейнере и у тебя два варианта: 1. Наследоваться от имаджа с пхп для твоего проекта и в него шедулер процессов 2. Как я описал... через докер (кружение) только пуск задач, а сам шедулер за контйнером

чёт, alpine какой-то каличный, поставил gcc, пробую собрать простейший main.c, выдает ошибки линковки с crti.o

я недвано кидал неплохой дебиан-бейзд https://hub.docker.com/r/tklx/base/ вообще оч люблю виртуалки от этих ребят. Но и контейнер вроде ничо

Я буквально на днях собирал в алпине мезос из сырцов - норм всё собирается. Хз чо за проблемы с простейшим файлом у вас..

я недвано кидал неплохой дебиан-бейзд https://hub.docker.com/r/tklx/base/ вообще оч люблю виртуалки от этих ребят. Но и контейнер вроде ничо

А как в дебьяне, поставить сборочные пакеты, а потом, после сборки их удалить одной строкой? Типа как это в alpine делается?

не хочу замусоривать конечный образ

А как в дебьяне, поставить сборочные пакеты, а потом, после сборки их удалить одной строкой? Типа как это в alpine делается?

точно так же

один в один

А как в дебьяне, поставить сборочные пакеты, а потом, после сборки их удалить одной строкой? Типа как это в alpine делается?

в apt можно маркировать пакеты при установке

А как в дебьяне, поставить сборочные пакеты, а потом, после сборки их удалить одной строкой? Типа как это в alpine делается?

RUN apt install blabla && build && apt purge blabla

на докер хабе масса примеров с убунтой

RUN apt install blabla && build && apt purge blabla

&& apt autoremove -y

&& apt autoremove -y

да

а если этот blablabla потянет сотню зависимостей, они тоже удалятся?

докер то тут причем

это вот сделает autoremove

божешьмой

он не должен, но он здесь прямо завязан. Взять самое популярное php приложение. PHP и все его кишки настроены в контейнере и у тебя два варианта: 1. Наследоваться от имаджа с пхп для твоего проекта и в него шедулер процессов 2. Как я описал... через докер (кружение) только пуск задач, а сам шедулер за контйнером

Да, ты наследуешь и делаешь свой шедулер

Вариант 2 это попытка натянуть слона на глобус

А если у меня 50 контейнеров, которые собирают статистику и кладут в свою базу (или обрабатывают на лету)

Потому что докер это не уровень приложения, это уровень инфраструктуры. Твоё приложение в иделе не должно знать про докер ровным счётом нихуя.

Да, ты наследуешь и делаешь свой шедулер

а почему свой? Уже готовые есть - cron и его аналоги

почему бы ими всеми через отдельный контейнер с кроном не управлять?

По поводу шедулеров, считаю, что если шедулинг какой-то задачи является неотъемлемой частью сервиса, то надо пихать крон внутрь и не морочить голову и запускать всё через supervisor

....

пипец

почему бы ими всеми через отдельный контейнер с кроном не управлять?

Потому что это не собачье дело докера вообще?

По поводу шедулеров, считаю, что если шедулинг какой-то задачи является неотъемлемой частью сервиса, то надо пихать крон внутрь и не морочить голову и запускать всё через supervisor

шедулеры в chronos надо пихать

почему не собачье дело?

я это залью на другой серв и там всё будет работать также

почему не собачье дело?

потому что это не докеру надо что-то шедулить, а приложению

смысл в этом, не?

Нет?

Не в этом?

приложение не знает про другие сервисы

оно просто умеет брать данные и делать дела с ними

Любая попытка завязать сервис внутри докера на сам докер — провальна.

И это явный признак того, что вы контейнеры неправильно готовите.

не на сам докер, а на управление другими докер контейнерами

@dd_bb увы

@dd_bb увы

пипец ваще!

я в шоке

я так то соглсен что приложение ничего не должно знать о совем окружении

перемнные окружения прочитала и в днс сходило

и пошло работать

да, именно

однако это не совсем так давай по правде

почему не совсем так?

потому что возможны варианты когда приложение приходится затачивать под докер

да, важное уточнение, я не дергаю docker exec из контейнера, я дергаю метод запуска через http (которые единый у всех сервисов со статой)

например просто взять и запилить приложение которое бы нормально жрало конфиг не только из переменных окружения уже задачка

ибо вдруг внезапно появляется сервисдискавери

например просто взять и запилить приложение которое бы нормально жрало конфиг не только из переменных окружения уже задачка

etcd?

ибо вдруг внезапно появляется сервисдискавери

а не надо делать то, чего сейчас не надо делать

когда ВНЕЗАПНО появится, тогда и переделаешь на discovery

сам по себе сервисдискавери уже добавляет факт того что оно немног оненативно для привычных монилитов

предварительная оптимизация — корень всех проблем

ERROR: S client not available

получается что в приложение вдруг появляется кусок кода по чтению сервисдискавери

и?

или даже вдруг внезапно сессионность в нем

и это приводит к тому что преиложение все еще можно запустить без докера

но уже сложнее

ты сейчас не совсем о той проблеме

каждая следующая итерация действий в докере приводит к большей заточке на докер

если у тебя докер единственное окружение, понятно что приложение будет постепенно к докеру прибиваться. это неизбежно

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

я тут про другую проблему: тут в чяте решили что тянуть бизнес-логику из приложения в докер это охуительная идея.

эта как ?

простите я вас не с самого начала читаю

Что мол докер должен там что-то знать про то что хочет приложение, шедулить там какие-то фоновые задачи и ещё что-то

Или что можно сделать контейнер с кроном, который будет запускать другие контейнеры

ахуительная идея.

с удовольствием посмотрю на шедулинг на кроне

я тут про другую проблему: тут в чяте решили что тянуть бизнес-логику из приложения в докер это охуительная идея.

да ничего не решили - человек описал свой юэкейс с кроном, но не описал что именно в этом кроне он гоняет

у меня как раз есть кукуруза

да ничего не решили - человек описал свой юэкейс с кроном, но не описал что именно в этом кроне он гоняет

когда у нас возникла задача обрабатывать фоновые задачи, мы просто сделали свой шедулер на уровне приложения и сделали отдельный entrypoint который запускает этот шедулер

крон это пиздато в односерверной среде.

со всеми проверками

но уже очень так себе когда микросервисы

там крон надо менять на слово таймеры

там крон надо менять на слово таймеры

на слово «уровень приложения»

не факт :)

когда у нас возникла задача обрабатывать фоновые задачи, мы просто сделали свой шедулер на уровне приложения и сделали отдельный entrypoint который запускает этот шедулер

я тоже так раньше думал, пока появление двух одинаковыф кронов не привело к прблемам

я приводил пример же :)

после вынесли в единое место

#docker-compose.yml .... alerta_cron: image: my_django_server:latest restart: always command: /heartbeat.sh .... #/heartbeat.sh #!/bin/sh sleep 60 python manage.py comnand_name

вот так

и забыли про крон вообще

и не говори что это плохо

вот так

так это и есть уровень приложения!