git множественные пульты: что делать с игнорируемыми / приватными файлами

Question

Моя проблема / проблема

Мы работаем над проектом с открытым исходным кодом, который мы разместили на github. Проект написан на Django, и поэтому у нас есть наши настройки в файле settings.py. У нас есть открытый исходный код не потому, что мы слишком дешевы для подписки, а потому, что мы намеренно хотим, чтобы это был открытый исходный код.

В любом случае, мы также хотим запустить этот код сами, поэтому у нас есть site_settings.py, который содержит все конфиденциальные данные, такие как пароль базы данных и т. Д. Так как мы не хотим, чтобы это было на github, чтобы все видели, это в Файл .gitignore.

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

Проблема в том, что теперь мы хотим запустить наш код на Heroku, который не поддерживает создание файлов на сервере, поскольку heroku не работает как обычный сервер (он работает с распределенной файловой системой).

Конечно, я думал об этом сам, но я не уверен, что это правильный подход. Пожалуйста, имейте в виду, что я новичок в Heroku и Git. Вот мое текущее решение:

Моя текущая идея о том, как это исправить

Есть два пульта:

• origin == Github
• heroku == Heroku

, исключая все ветки разработки и функций, у нас есть только две основные ветки (на Heroku и Github), о которых нужно беспокоиться.

Моя идея состояла в том, чтобы локально настроить ветви следующим образом:

• мастер -> пульты / источник / мастер
• героку -> пульты / героку / мастера

В ветке master мы помещаем site_settings.py в .gitignore, чтобы git игнорировал его при фиксации на Github, то же самое относится ко всем веткам dev и т. Д. Мы собираем все наши изменения в ветке master, пока не получим новый выпуск.

В ветке heroku мы отредактировали файл .gitignore, чтобы перестать игнорировать site_settings.py, поэтому он будет передан Heroku, как только мы отправим ветку heroku.

Как только у нас появляется новый релиз, мы переключаемся на ветку heroku и объединяем master в heroku следующим образом:

git checkout heroku
git pull
git merge master

Как только мы разобрались с конфликтами слияния из слияния, мы передаем Heroku, и у нас есть новый выпуск и запуск .. = D

Мой вопрос

Допустима ли моя идея для решения этой проблемы (будет ли она работать даже с .gitignore, как это?) И если нет, то как мы решим это самым чистым / наилучшим из возможных способов? Если вам нужна дополнительная информация, не стесняйтесь спрашивать:)

Answer 1

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

Из приложения 12factor :

Конфигурация приложения - это все, что может варьироваться в зависимости от развертывания (подготовка, производство, среда разработки и т. Д.).Сюда входят:

• Дескрипторы ресурсов для базы данных, Memcached и других вспомогательных служб
• Учетные данные для внешних служб, таких как Amazon S3 или Twitter
• Значения для развертываниянапример, каноническое имя хоста для развертывания

Приложения иногда сохраняют конфигурацию как константы в коде.Это нарушение двенадцатикратного фактора, которое требует строгого отделения конфига от кода.Конфигурация существенно различается в зависимости от развертывания, код - нет.

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

Обратите внимание, что это определение «config» не включает внутреннюю конфигурацию приложения, такую ​​как config / rout.rb в Rails, или то, как модули кода подключаются в Spring.Конфигурации этого типа не различаются между развертываниями, и поэтому лучше всего это делать в коде.

Другой подход к конфигурации - это использование файлов конфигурации, которые не проверяются в управлении версиями, таких как config / database.ymlв рельсах.Это огромное улучшение по сравнению с использованием констант, которые проверены в репо кода, но все еще имеют недостатки: легко по ошибке проверить в файле конфигурации репо;Существует тенденция разбрасывать конфигурационные файлы в разных местах и ​​разных форматах, что затрудняет просмотр и управление всей конфигурацией в одном месте.Кроме того, эти форматы, как правило, зависят от языка или структуры.

Приложение с двенадцатью факторами сохраняет конфигурацию в переменных среды (часто сокращается до env vars или env).Env vars легко переключать между развертываниями без изменения кода;в отличие от конфигурационных файлов, существует небольшая вероятность того, что они случайно попадут в репозиторий;и в отличие от пользовательских файлов конфигурации или других механизмов конфигурации, таких как Java System Properties, они являются независимым от языка и ОС стандартом.

Другим аспектом управления конфигурацией является группирование.Иногда приложения группируют конфигурацию в именованные группы (часто называемые «средами»), названные в честь определенных развертываний, таких как среды разработки, тестирования и производства в Rails.Этот метод не масштабируется чисто: по мере создания новых развертываний приложения необходимы новые имена среды, такие как staging или qa.По мере дальнейшего развития проекта разработчики могут добавлять свои собственные специальные среды, такие как joes-staging, что приводит к комбинаторному взрыву конфигурации, что делает управление развертыванием приложения очень хрупким.

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

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

import os
import sys
import urlparse

# Register database schemes in URLs.
urlparse.uses_netloc.append('postgres')
urlparse.uses_netloc.append('mysql')

try:

    # Check to make sure DATABASES is set in settings.py file.
    # If not default to {}

    if 'DATABASES' not in locals():
        DATABASES = {}

    if 'DATABASE_URL' in os.environ:
        url = urlparse.urlparse(os.environ['DATABASE_URL'])

        # Ensure default database exists.
        DATABASES['default'] = DATABASES.get('default', {})

        # Update with environment configuration.
        DATABASES['default'].update({
            'NAME': url.path[1:],
            'USER': url.username,
            'PASSWORD': url.password,
            'HOST': url.hostname,
            'PORT': url.port,
        })
        if url.scheme == 'postgres':
            DATABASES['default']['ENGINE'] = 'django.db.backends.postgresql_psycopg2'

        if url.scheme == 'mysql':
            DATABASES['default']['ENGINE'] = 'django.db.backends.mysql'
except Exception:
    print 'Unexpected error:', sys.exc_info()

Для получения дополнительной информации о конфигурационных переменных см. Здесь: https://devcenter.heroku.com/articles/config-vars

Answer 2

Вместо того чтобы разрабатывать сложное развертывание файлов настроек и переменных на основе git, в Heroku я бы использовал переменные окружения для всех ваших чувствительных вещей.Таким образом, вам не нужно хранить их в коде.См. документы базы данных и переменные среды docs для информации - поместите все эти вещи туда, а затем получите доступ через os.getenv() документы Python .

Чтобы увидеть переменные окружения для приложения, используйте инструмент heroku cli:

 heroku run env

Распечатает все переменные.Чтобы добавить новые переменные (например, клавиши S3 и т. Д.), Используйте:

heroku config:add VAR_NAME=value