Pull to refresh

Comments 35

"Негодующий комментарий про крон в 2023 году и systemd-таймеры"

Благодарю. Подскажите, а чем крон плох? Я в статье обозначил, что не являюсь DevOps специалистом, нашел решение которое работает. Вполне может быть оно и не самое корректное. Статей много по настройки systemd-таймер , а пока разницы между ними плюсы/минусы не уловил.

systemd-таймеры это не про DevOps, а про владение Linux'ом.

Крон просто запускает скрипт. Таймер же оперирует сервисом, у которого есть собственные логи, состояние и понятные способы управления.


Самый простой пример — что произойдёт со скриптом, если он не закончит выполняться до следующего запуска задания в кроне? Хорошо, если несколько экземпляров допустимы. А если нет? Как в рамках крона это контролировать?

У человека простой скрипт, он решил свою проблему и его устроило решение.

Если бы он столкнулся бы с проблемами, он бы пошёл исследовать проблему и методы её решения.

Опять же, резидентный сервис и ad-hoc скрипт - разные сценарии.
Тут нужно очень четко формулировать ограничения, чтобы понимать, какие средства будут наилучшими в этих условиях. Зависит от контекста.

Именно поэтому я оформил свой первый комментарий в ироническом стиле, а не начал холиварить и сомневаться в профпригодности автора.

Может быть я конечно не так гуглил. В процессе сложилось впечатление, что не хватает обзорной статьи, которая хотя бы показывала связь между сложностью сервиса и инструментов для их запуска на сервере. Очень много информации про докер. Спасибо всем кто оставил комментарии, теперь у меня есть понимание, что вариантов запустить мой простой скрипт есть несколько и можно вполне обойтись без докера.

Связь тут скорее не со сложностью, а с контекстом. В соседних ветках народ может сколько угодно улюлюкать насчёт того, что ради одного скрипта с обвязкой городить контейнеры не стоит, но если, например, вам нужно этот скрипт разложить по нескольким серверам, администрируемым не вами, синхронно обновлять и мочь без проблем проводить диагностику в случае каких-то проблем — лично я бы потратил бы сначала немного времени и докеризировал.

По идее, если прямо в скрипте загнать вызов первой функции в бесконечный цикл и после вызова прописать time.sleep(N) и проследить, чтоб после отработки итерации в памяти ничего лишнего не оставалось, то и крон не понадобится. Но если скрипт упадет, его никто не поднимет. Отсюда уже можно посмотреть на создание юнитов systemd. На истину не претендую, просто был подобный кейс, решал вот так.

Вам успехов в начинаниях)

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

Амазон лямбды могут запускатся по таймеру, думаю аналогичные сервисы от других клауд провайдеров тоже так умеют это не рокет сайнс.

Я не понимаю что с хабром, одни статьи про Пайтон и qa

А просто так, без докера, питон не запустить?

Какой же ты хакер без ноутбука девопс без докера? ;)

А, понял, то есть дело опять в смузи и цветных носках)

Нет, автор же не скрывает, что нагуглил, то и сделал. Попался рецепт с докером - он его применил.

Только в этом случае самолёт из соломы полетел ;) Скорее забили гвоздь микроскопом.
То ли ещё будет, когда chatgpt пойдёт в массы ;). Он же будет подсказывать самые трендовые решения.

Почитав мнение коллег, понимаю, что действительно забил гвоздь микроскопом. Есть более простые рецепты. Осталось найти хитрую книгу/статью, откуда можно понять, что если написал просто скрипт смысла в докере нет, можно попробовать так. А вот если в твоем сервисе есть функции такие-то... то тут поможет докер и прочие инструменты.

А тут просто здравый смысл. Докер полезен если очень хитрая конфигурация, или надо одно и тоже раздавать на разные машины или разными людям. А что-то сделать на одном сервере для себя - точно нет. Отлаживать внутри докера неудобно. Туда пихают что-то готовое как правило

Если подскажите или скинете ссылку на реализацию буду признателен.

Ловите

sudo apt-get install python3

И вам не нужен докер)))

Набираем «crontab –e»

... и получаем в глаз, если ты не админ localhost. Это статья про man 5 crontab?

Я не являюсь DevOps специалистом, можете пояснить? Не совсем понимаю, что не так с «crontab –e»

При чем тут девопс-то? Устройство крона никакого отношения к девопс не имеет.

Я не зря про localhost упомянул. Когда начинаются странные вещи, то администратору хоста очень весело ползать по всем пользовательским кронам в том числе

у каждого пользователя на хосте - свой кронтаб. Не вижу проблемы :)

Я не зря про localhost упомянул. Когда начинаются странные вещи, то администратору хоста очень весело ползать по всем пользовательским кронам в том числе

Ну тут тоже вопрос - администратор хоста отвечает за ОС хоста (дистрибутив Линукс) или отвечает за всё на хосте, включая приклад? Если шкодничают юзвери, а крайний всегда админ - ну тогда грустно, полностью согласен.

Хм... весь смысл docker - закинуть контейнер на сервер и не думать, что там на самóм сервере ещё необходимо для его корректной работы. Так зачем, если уж мы с docker связались (что для данной задачи тоже overkill, но Бог с ним), настраивать crontab на самóм сервере, а не внутри docker-контейнера?.. Настроили crontab внутри контейнера, запустили его один раз - всё.

я не проще какую-нить библиотеку типа schedule использовать в самом питоне ?

Sign up to leave a comment.

Articles