Flask - это удобная микросхема Python для разработки веб-приложений и API. Это определенно мой инструмент, который я предпочитаю при разработке небольших веб-приложений. Иногда я даже использую его для более крупных проектов из-за свободы и гибкости, которые он дает с точки зрения пакетов / плагинов.
Часто, помимо среды разработки, приложения, над которыми мы работаем, придется развертывать в производственной среде. Место, где они общедоступны и открыты для широкой публики. Для этой среды потребуются собственные конфигурации, такие как базы данных, секретные ключи, почтовые серверы и т. Д. В некоторых случаях ваш проект может даже иметь больше сред, таких как тестирование и постановка. Количество имеющихся у вас сред не имеет значения (если вы все делаете правильно), поскольку вам потребуются разные наборы конфигураций для каждой среды. Я надеюсь, что вы не хотите запускать тесты в своей производственной базе данных!
Метод новичка
Для начала давайте создадим простое приложение-флягу с одной страницей и зададим конфигурации:
from flask import Flask
app = Flask(__name__)
app.config['APP_ROOT'] = os.path.dirname(os.path.abspath(__file__))
app.config['MONGO_URI'] = "mongo_uri"
app.config['SECRET_KEY'] = "secret_key"
@app.route("/")
def index():
return "Welcome Home!", 200
if __name__ == "__main__":
app.run()
Мы сохраним простые представления, поскольку в этой статье мы сосредоточимся на конфигурациях приложений. В этом примере приложение имеет одну страницу, которая возвращает текст «Добро пожаловать домой!» в браузер пользователя вместе с кодом состояния ОК. Однако обратите внимание на 2 строки кода после инициализации объекта приложения.
Это конфигурации приложения. Это переменные, которые мы устанавливаем для использования в нашем приложении. чтобы получить доступ к этим значениям, просто укажите на них ссылку с помощью app.config [key]. Этот пример достаточно прост, и его может хватить для простого приложения, работающего в одной среде. Однако это не самый надежный или масштабируемый метод работы с конфигурациями Flask.
Плюсы
Начнем с плюсов этого метода:
- Этот метод является очень быстрым способом настройки наших приложений, сохраняя при этом весь код в одном файле.
- Сохраняет простоту нашего приложения, если мы планируем запускать его только в одной среде (что крайне редко для неэкспериментальных проектов, поскольку нам потребуются как минимум среды разработки и производства).
Вот и все. Это метод, которому обучают в большинстве руководств по Flask для начинающих, и я лично не вижу в нем особого смысла после этого.
Минусы
- Если у вас много значений конфигурации приложения, файл может быстро стать слишком длинным.
- Если у вас несколько сред, вам придется вручную настраивать конфигурации приложений для каждой среды с каждым выпуском. Очень быстро это может превратиться в кошмар.
- Помимо первого пункта, вы более склонны к ошибкам при обновлении значений конфигурации приложения между средами.
- Если есть какие-либо конфигурации, которые вы хотите сохранить в секрете (например, из общедоступного репозитория), вам будет сложно сделать это с помощью этого метода (хотя вы можете использовать переменные среды, но это тема для другой статьи).
Как видите, минусы намного перевешивают плюсы, и мы можем указать еще много минусов, но я оставлю все как есть, потому что я уверен, что это доказано. При этом этот метод не является устойчивым для крупных проектов или проектов, которые, как ожидается, будут выполняться в нескольких средах.
Лучшие методы
Итак, как мы можем лучше организовать конфигурации нашего приложения, чтобы избежать ошибок, перечисленных выше? Что ж, вот для чего эта статья! Я собираюсь описать два моих любимых метода организации конфигураций.
1. Файлы конфигурации
Первый способ - использовать файлы конфигурации. В этом методе у нас будет несколько файлов конфигурации, по одному для каждой среды. Они будут содержать конфигурации для этой конкретной среды.
Это должен быть файл .cfg, и его содержимое будет следующим:
MONGO_URI = "environment_mongo_uri" SECRET_KEY = "environment_secret_key"
После того, как вы создали все соответствующие файлы для соответствующих сред, вы можете импортировать их в свое приложение, заменив строки app.config на:
app.config.from_pyfile('production.cfg')
app.config.from_pyfile('development.cfg')
Обратите внимание, что в этом примере файлы загружаются в указанном порядке, поэтому, если есть переменная, определенная как в production.cfg, так и в development.cfg, значение development.cfg переопределит значение, указанное в production.cfg.
Это означает, что с помощью этого метода мы должны удалить строку, импортирующую файл разработки, прежде чем отправлять код в производство. Это кажется достаточно простым и лучшим способом организации файлов, чем метод для новичков, но, как вы, вероятно, уже знаете, это все равно будет утомительно, если существует более двух сред, о которых нужно беспокоиться. Также требуется отдельный файл для каждой среды.
Умный способ работы с несколькими средами - заключить импорт конфигурации в блок try / except, а затем игнорировать файлы, относящиеся к среде, из системы контроля версий. Итак, в приведенном выше примере мы бы сделали следующее:
app.config.from_pyfile('production.cfg')
try:
app.config.from_pyfile('development.cfg')
except FileNotFoundError:
pass
Затем мы игнорируем файл development.cfg в системе контроля версий. Это избавляет от необходимости вручную удалять / комментировать строку, читающую файл. В производственной среде файл не будет найден, и приложение продолжит работу.
2. Объекты конфигурации
Другой способ обработки конфигураций - использование классов. Здесь мы создаем базовый класс, определяющий общие конфигурации, а затем создаем классы, которые наследуются от этого базового класса для каждой из наших сред. В идеале мы бы сделали это в отдельном модуле. Содержимое файла может быть следующим:
class BaseConfig(object):
DEBUG = False
MONGO_URI = "mongo_uri"
class DevelopmentConfig(BaseConfig):
DEBUG = True
MONGO_URI = "development_mongo_uri"
class TestingConfig(BaseConfig):
DEBUG = True
MONGO_URI = "testing_mongo_uri"
class ProductionConfig(BaseConfig):
MONGO_URI = "production_mongo_uri"
Как вы можете видеть в приведенном выше примере, мы можем создать столько классов, сколько нам нужно, в зависимости от количества имеющихся у нас сред. Чтобы использовать приведенные выше конфигурации, мы просто используем следующую строку кода:
app.config.from_object('configmodule.ProductionConfig')
Вышеупомянутая строка загрузит производственную конфигурацию. Замените ProductionConfig на соответствующий класс для конкретной среды. Вы также можете создать экземпляр объекта и передать его app.config.from_object ()
Заключение
Это несколько способов обработки конфигураций во Flask, которые делают работу с несколькими средами намного менее утомительной. Это не ЕДИНСТВЕННЫЕ методы, есть еще один очень удобный метод: использование переменных среды. Однако, как я уже говорил ранее, это тема, которую я затрону в другой статье. Обязательно попробуйте их в своем следующем проекте или даже в текущем. Реорганизовать никогда не поздно!
Вы можете ознакомиться с официальной документацией Flask относительно обработки конфигурации здесь.
Если вас интересует больше моего контента, посетите мой личный блог. Если вы заинтересованы в получении моих услуг, посетите мой личный сайт и свяжитесь со мной.
