Ну всякое бывает в минорных релизах на самом деле, вот я оставлял версию без патч релиза, и напоролся на такое недавно https://github.com/python/cpython/issues/135171. Но в целом да, обычно такой подход работает (до тех пор, пока не происходит деградация, которая тебя затрагивает)
По python - нет никакого смысла брать образ slim для builder и потом ставить туда build-essentials, это просто расход энергии впустую. Лучше всего взять обычный образ для билдера, там установлены специально большинство нужных зависимостей для сборки, а для результирующего образа взять slim.
Ну и как опция - можно целиком стянуть готовый venv из билдера вместо установки из wheel, но это уже на любителя.
Если же ответ до устройства по каким‑то причинам не доходил (или колонка была перезагружена), клиент перезапрашивал информацию с других серверов каждые пять секунд до тех пор, пока не узнавал время.
Это простой алгоритм, но, если я правильно понимаю, RFC 4330, на который ссылается ntp.org, так делать не рекомендует.
1. A client MUST NOT under any conditions use a poll interval less than 15 seconds.
2. A client SHOULD increase the poll interval using exponential backoff as performance permits and especially if the server does not respond within a reasonable time.
Наверное введение экспоненциальной задержки уменьшило бы масштаб проблемы.
На самом деле не очень понятно, зачем понадобилось писать свой клиент, вместо использования какого-нибудь opensource, который точно соответствует RFC.
Есть протокол для взаимодействия с очередью, AMQP, он открытый. RabbitMQ - одна из реализаций очереди, и общение с ним происходит по этому протоколу. Есть несколько других реализаций очередей, совместимых с этим протоколом, продающихся как SaaS. Кроме того, в библиотеке kombu, которую использует Celery, есть возможность использовать некоторые реализации очередей с их нативными протоколами. Это в общих чертах, но конечно же везде есть свои нюансы
Все сильно зависит от конкретных людей. Но можно сделать так — помещаем код приложения и код деплоя в один репозиторий, и разработчики уже начинают править код деплоя в процессе работы над фичами, и наоборот. Конечно, не все на такое решаются, но подход рабочий при развитом code review. И без автотестов деплоя тут никуда.
Ну всякое бывает в минорных релизах на самом деле, вот я оставлял версию без патч релиза, и напоролся на такое недавно https://github.com/python/cpython/issues/135171. Но в целом да, обычно такой подход работает (до тех пор, пока не происходит деградация, которая тебя затрагивает)
По python - нет никакого смысла брать образ slim для builder и потом ставить туда build-essentials, это просто расход энергии впустую. Лучше всего взять обычный образ для билдера, там установлены специально большинство нужных зависимостей для сборки, а для результирующего образа взять slim.
Ну и как опция - можно целиком стянуть готовый venv из билдера вместо установки из wheel, но это уже на любителя.
А почему не стандартный формат, который может применять git? Тот, что получается командой git format-patch?
Cosystack не рассматривали?
Спасибо за статью, это весьма поучительный опыт.
Это простой алгоритм, но, если я правильно понимаю, RFC 4330, на который ссылается ntp.org, так делать не рекомендует.
Наверное введение экспоненциальной задержки уменьшило бы масштаб проблемы.
На самом деле не очень понятно, зачем понадобилось писать свой клиент, вместо использования какого-нибудь opensource, который точно соответствует RFC.
Есть протокол для взаимодействия с очередью, AMQP, он открытый. RabbitMQ - одна из реализаций очереди, и общение с ним происходит по этому протоколу. Есть несколько других реализаций очередей, совместимых с этим протоколом, продающихся как SaaS. Кроме того, в библиотеке kombu, которую использует Celery, есть возможность использовать некоторые реализации очередей с их нативными протоколами. Это в общих чертах, но конечно же везде есть свои нюансы