Как лучше всего хранить небольшой объем данных в BE (буквально 1 строка)?

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

Поскольку этот заголовок должен быть показан каждому пользователю на сайте, я не могу хранить его в локальном хранилище или в таблице пользователя. Кроме того, это одна строка сообщения на одной странице, поэтому создавать целую таблицу базы данных для этого кажется совершенно глупым. Поэтому, чтобы добиться этой функциональности, я добавил json-файл в BE, который просто содержит это сообщение, и представление, которое позволяет пользователям редактировать этот файл. Я также поместил этот файл в gitignore, потому что изменение данных в нем не должно отражаться в git.

Эта система пока работает нормально, но когда я переразвертываю систему с помощью Docker, этот файл удаляется и перестраивается, теряя первоначальное сообщение. Есть ли лучший способ хранить и обновлять эти данные? Или какой-нибудь способ не потерять мои данные при переразвертывании?

userdata.json

{
   message: "Holiday tomorrow, please report any issues by 3."
}

Чтение данных в Django View

try:
    if not os.path.exists(USERDATA_FILE):
        # Create the file with default structure if it doesn't exist
        with open(USERDATA_FILE, "w") as file:
            json.dump({"message": "Hello World!"}, file, indent=4)

        with open(USERDATA_FILE, "r") as file:
            data = json.load(file)
except Exception as e:
     print("Error in reading data")

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

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

В связи с этим, если вы когда-нибудь захотите запустить несколько копий своей системы, хранение баннера в единой базе данных упростит управление. Если вы развернули контейнер в Kubernetes, проблема сохраняемости становится сложнее (трудно получить хранилище, разделяемое между репликами контейнера); возможно, вы могли бы внедрить его с помощью ConfigMap, но для его обновления вам потребуется управление, специфичное для Kubernetes. Вы также можете представить себе развертывание приложения без контейнера, но на нескольких хостах для масштабирования или избыточности, и тогда вам пришлось бы вручную копировать файл баннера на каждый хост, если бы он не хранился где-то централизованно.

Также легко представить себе ситуации, когда один и тот же баннер показывается не каждому пользователю. Возможно, у вас несколько групп пользователей или несколько арендаторов используют приложение совместно. Если баннер хранится в таблице, то легко добавить переход в ALTER TABLE banner ADD COLUMN ..., чтобы добавить идентификатор группы или клиента, но с предлагаемым вами макетом файла будет сложнее отказаться от "показывать один и тот же баннер всем".

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

Вернуться на верх