Управление конфигурациями для разных сред - PullRequest
Новая
       37

Управление конфигурациями для разных сред

0 голосов
/ 30 мая 2018

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

Мы предложили несколько вариантов, но ни один из них, похоже, не удовлетворил нас:
- Отдельные файлы конфигурации (например, config.test, config.prod и т. Д.) И наличие файла, указывающего на выбранный (в~/env, например), или переменная среды, указывающая на нее.
- Использование одной БД для хранения всех конфигураций (вы запрашиваете ее в своей среде и получаете соответствующие значения конфигурации)
- Создание файлов конфигурации при развертывании(Использование системы CI / CD, например Atlassian Bamboo)

Какой вариант наиболее широко используется?Есть ли лучший способ?
Должен ли файл конфигурации храниться в репозитории git вместе с остальным кодом?Наши системы написаны на python (2.7 и 3)

Ответы [ 4 ]

0 голосов
/ 19 января 2019

В итоге мы использовали метод, подобный этому one .У нас был файл базовых настроек и файлы среды, которые просто импортировали все из базового файла base.py:

SAMPLE_CONFIG_VARIABLE = SAMPLE_CONFIG_VALUE

prod.py: 

from base.py import *

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

0 голосов
/ 31 мая 2018

Один из подходов заключается в написании «шаблона» для каждого типа файла конфигурации, где шаблон содержит в основном простой текст, но с несколькими заполнителями.Вот пример файла конфигурации шаблона с использованием обозначения ${foo} для обозначения заполнителя. 

serverName  = "${serverName}"
listenPort  = "${serverPort}"
logDir      = "/data/logs/${serverName}";
idleTimeout = "5 minutes";
workingDir  = "/tmp";

Если вы сделаете это для всех файлов конфигурации, используемых вашим приложением, то вы, вероятно, обнаружите, что выполнениеglobal-search-and-replace в файлах конфигурации шаблона со значениями для относительно небольшого количества заполнителей даст готовые к работе файлы конфигурации для конкретного развертывания.Если вы ищете простой способ выполнить глобальный поиск и замену для заполнителей в файлах шаблонов и вам удобнее работать с Java, то вы можете рассмотреть Apache Velocity .Но я думаю, что было бы тривиально разработать аналогичные функциональные возможности в Python.

0 голосов
/ 13 июня 2018

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

Вот пример , в котором используются argparse и переменные среды: 

def parse_args(argv=None):
    parser = ArgumentParser(description='Watch the raw data folder for new runs.',
                            formatter_class=ArgumentDefaultsHelpFormatter)
    parser.add_argument(
        '--kive_server',
        default=os.environ.get('MICALL_KIVE_SERVER', 'http://localhost:8000'),
        help='server to send runs to')
    parser.add_argument(
        '--kive_user',
        default=os.environ.get('MICALL_KIVE_USER', 'kive'),
        help='user name for Kive server')
    parser.add_argument(
        '--kive_password',
        default=SUPPRESS,
        help='password for Kive server (default not shown)')

    args = parser.parse_args(argv)
    if not hasattr(args, 'kive_password'):
        args.kive_password = os.environ.get('MICALL_KIVE_PASSWORD', 'kive')
    return args

Установка этих переменных среды может быть немного запутанной, особенно для системных служб.Если вы используете systemd, посмотрите на сервисный блок и будьте осторожны, используя EnvironmentFile вместо Environment для любых секретов.Environment значения могут быть просмотрены любым пользователем с помощью systemctl show.

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

Другой вариант - поместить параметры конфигурации в файл settings.py, и просто будьте осторожны, чтобы не передать этот файл в систему контроля версий.Я часто фиксирую файл settings_template.py, который пользователи могут копировать.

0 голосов
/ 30 мая 2018

Вы можете поместить все эти конфигурации в один файл конфигурации config.py. 

class Base():
    DEBUG = False
    TESTING = False

class DevelopmentConfig(Base):
    DEBUG = True
    DEVELOPMENT = True
    DATABASE_URI = "mysql+mysqldb://root:root@localhost/demo"

class TestingConfig(Base):
    DEBUG = False
    TESTING = True
    DATABASE_URI = "mysql+mysqldb://root:root@test_server_host_name/demo_test"

class ProductionConfig(Base):
    DEBUG = False
    TESTING = False
    DATABASE_URI = "mysql+mysqldb://root:root@prod_host_name/demo_prod"

в переменной среды набора оболочки, например

APP_SETTINGS = config.DevelopmentConfig

В вашем главном приложении app.py загрузите эту переменную среды (например, приложение flask) 

from flask import Flask
import os

app = Flask(__name__)
app.config.from_object(os.environ['APP_SETTINGS'])

Надеюсь, это может помочь

...