Уникальный id запуска Django?

Question

[Владимир Куц]

Такой вопрос - может кто сталкивался... Мне нужно на каждый запуск django-проекта создавать некий уникальный идентификатор старта проекта, доступный глобально для проекта, уникальный именно для данного события старта, и создавался он как можно на более раннем этапе, так как происходят некие инициализации, которые используют данный уникальный идентификатор, и был доступен весь период жизни проекта до перестарта/перезапуска. В процессе работы он должен быть неизменным.
Новый запуск/перезапуск проекта должен приводить к изменению данного идентификатора.
Пробовал что-то вроде:

thread_local_storage = threading.local()

...

global thread_local_storage

running_instance_uid = getattr(thread_local_storage, 'running_instance_uid', None)
if not running_instance_uid:
    thread_local_storage.running_instance_uid = str(uuid4())

Но не подошло - идентификатор меняется после старта.
Пока приходит в голову - просто создавать/изменять метку в файле перед запуском проекта на django, и ее читать.
Но может есть способ изящнее..

Comments

[Roman K]

Вопрос больше в том, где он должен быть общий. На все треды внутри процесса, на все процессы внутри машины, на все машины внутри кластера или на все кластеры?

Чем дальше думать, тем более нерешаемая задача получается. Например, у gunicorn есть опция requests=N, которая перезапускает воркера (тред в случае gthread и процесс в случае sync). Новый воркер — это новый ID или всё ещё прежний? Или, например, k8s, когда перебрасывает контейнер спустя сутки после выкатки (по сути — выключает на одной ноде и спинапит на другой) — это всё ещё старый ID или уже новый? А если не перебрасывает, а просто рестартует, потому что сеть лаганула и хэлсчеки пропали?

Хотя нет, вопрос скорее в том, зачем изначально это понадобилось, возможно всё намного проще, а вопрос — всего лишь задача XY и, например, можно задачу решить просто тем, что при билде образа, класть файл .releaseid внутрь с short sha коммита (что конечно далеко не ID запуска [хотя что вообще такое этот ID запуска? может быть, revision в терминах helm?], но, возможно, именно хэш состояния кодовой базы подойдёт лучше [например для sentry release])

[Владимир Куц]

Roman K, грубо говоря - мне нужно сделать уникальный айди на процесс запуска проекта. Сколько потом тредов запустится или на каких кластерах он потом поднимется - должен браться один уникальный айди. Мы стартанули проект - получили новый айди - все...
Впрочем - я этот вопрос решил - запуском прелоад-скрипта перед стартом проекта.
Просто думал что есть уже что-то встроенное и мне не придется придумывать велосипед.

Answer 1

[Сергей П]

А где вы размещали этот код? Он выполняется дважды?
Ваш проект весь в одном процессе стартует? Может быть поднимается несколько инстансов джанги.
Если несколько инстансов, то такой идентификатор можно хранить только в БД, а перед стартом удалять его извне скриптом.
Можете совсем перед запуском проекта вписаь в БД внешним скриптом новый UID и его же сохранить в переменных среды окружения процессов всех инстансов. Кстати, в таком случае и в БД можно не хранить тот уид. Просто перед запуском в баш-скрипте всем процессам переавать его и все.

Comments

[Владимир Куц]

Да - в том-то и дело что uwsgi запускает несколько инстансов, и айдишники запущенных инстансов конфликтуют меж собой.

[Сергей П]

Владимир Куц, а чем вас не устраивает трюк с переменными среды окружения?
Я так понимаю uwsgi клонирует свое окружение для дочерних процессов. Ну вот сделайте при запуске переменную с UUID и она раздастся всем дочерним процессам, а в джанго сделайте удобную функцию получения значения из переменной окружения, можно даже закешировать значение в модуле settings, чтобы не заниматься повторно десерализацией.

[Владимир Куц]

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

[Владимир Куц]

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

[Сергей П]

Владимир Куц, ну тогда в manage.py внедрите кусочек кода, который будет детектить команду runserver и добавлять переменную среды окружения.
Если и это не поможет, то придётся-таки разбираться как устроен CI\CD и что он там дёргает при запуске.

[Владимир Куц]

Сергей Паньков, да - спасибо за мысли по реализации. Для себя решил что после скрипта миграции добавлю прелоад-скрипт, который собственно будет эту переменную в БД создавать. Типа так:

python manage.py runscript preload

preload.py

import uuid
from django.apps import apps


def run():
    apps.get_model('common.GlobalSettings').objects.update_or_create(
        name='global_uid',
        defaults={'value':str(uuid.uuid4())}
    )