1

私の問題/問題

私たちは、github でホストしているオープンソース プロジェクトに取り組んでいます。プロジェクトは Django で記述されているため、settings.py ファイルに設定があります。サブスクリプションが安すぎるからではなく、意図的にオープンソースにしたいからです。

とにかく、私たちもこのコードを自分で実行したいので、db パスワードなどのすべての機密データを含む site_settings.py を用意します。誰もが見られるように github でこれをしたくないので、これは .gitignore ファイルにあります.

通常、リポジトリのクローンを作成し、このファイルをローカルおよびサーバーに追加します。このようにして、すべての個人設定が保持され、機密データが git に保存されることはありません。

問題は、heroku が通常のサーバーのように動作しない (分散ファイル システムで動作する) ため、サーバー上でのファイルの作成をサポートしていない Heroku でコードを実行する必要があることです。

もちろん、私自身も考えましたが、これが正しいアプローチかどうかはわかりません。私は Heroku と Git の両方が初めてであることを覚えておいてください。以下は私の現在の解決策です：

これを修正する方法に関する私の現在の考え

次の 2 つのリモコンがあります。

  • 起源 == Github
  • heroku == ヘロク

すべての開発ブランチと機能ブランチを除外して、(Heroku と Github の) 両方のマスター ブランチだけを気にする必要があります。

私の考えは、ブランチをローカルで次のようにセットアップすることでした。

  • マスター -> リモート/オリジン/マスター
  • heroku -> リモート/heroku/master

マスター ブランチでは、site_settings.py を .gitignore に配置するため、Github にコミットするときに git はそれを無視します。すべての dev ブランチなどについても同様です。新しいリリースができるまで、すべての変更をマスター ブランチに収集します。

heroku ブランチで .gitignore ファイルを編集して site_settings.py を無視しないようにしたので、heroku ブランチにプッシュすると Heroku にコミットされます。

新しいリリースができたら、heroku ブランチに切り替えて、次のように master を heroku にマージします。

git checkout heroku
git pull
git merge master

マージからのマージ競合を整理したら、Heroku にコミットし、新しいリリースを稼働させます.. =D

私の質問

これを解決するのに私の考えは受け入れられますか (このように .gitignore でも機能しますか?)、そうでない場合は、可能な限りクリーン/最善の方法でこれを解決するにはどうすればよいですか? さらに情報が必要な場合は、お気軽にお問い合わせください:)

4

2 に答える 2

1

まず、設定をファイルに保存するのは間違った方法なので、やらないでください。

12factor アプリから:

アプリの構成は、デプロイ (ステージング、運用、開発環境など) によって異なる可能性があるすべてのものです。これも：

  • データベース、Memcached、およびその他のバッキング サービスへのリソース ハンドル
  • Amazon S3 や Twitter などの外部サービスへの認証情報
  • デプロイの正規ホスト名などのデプロイごとの値

アプリは、構成を定数としてコードに保存することがあります。これは、構成をコードから厳密に分離する必要がある 12 要素に違反しています。構成はデプロイ間で大幅に異なりますが、コードはそうではありません。

アプリのすべての構成がコードから正しく取り除かれているかどうかのリトマス テストは、資格情報を損なうことなく、いつでもコードベースをオープン ソースにできるかどうかです。

この「config」の定義には、Rails の config/routes.rb などの内部アプリケーション構成や、Spring でのコード モジュールの接続方法は含まれないことに注意してください。このタイプの構成はデプロイ間で変化しないため、コードで行うのが最適です。

config に対するもう 1 つのアプローチは、Rails の config/database.yml など、リビジョン管理にチェックインされていない構成ファイルを使用することです。これは、コード リポジトリにチェックインされる定数を使用する場合よりも大幅に改善されますが、まだ弱点があります。設定ファイルを誤ってリポジトリにチェックインするのは簡単です。構成ファイルはさまざまな場所やさまざまな形式に散在する傾向があり、すべての構成を 1 か所で確認して管理することは困難です。さらに、これらの形式は言語またはフレームワークに固有である傾向があります。

Twelve-Factor アプリは、構成を環境変数 (多くの場合、env vars または env に短縮されます) に保存します。環境変数は、コードを変更することなく、デプロイ間で簡単に変更できます。構成ファイルとは異なり、誤ってコード リポジトリにチェックインされる可能性はほとんどありません。また、カスタム構成ファイルや Java システム プロパティなどの他の構成メカニズムとは異なり、言語や OS に依存しない標準です。

構成管理のもう 1 つの側面は、グループ化です。アプリケーションは、Rails の開発、テスト、運用環境など、特定のデプロイにちなんで名付けられた名前付きグループ (多くの場合「環境」と呼ばれる) に設定をバッチ処理することがあります。この方法はきれいにスケーリングしません。アプリのデプロイがさらに作成されると、staging や qa などの新しい環境名が必要になります。プロジェクトがさらに成長するにつれて、開発者は joes-staging などの独自の特別な環境を追加する可能性があり、その結果、構成の組み合わせが爆発的に増加し、アプリの展開の管理が非常に脆弱になります。

Twelve-Factor アプリでは、環境変数は詳細なコントロールであり、それぞれが他の環境変数と完全に直交しています。それらは「環境」としてグループ化されることはなく、デプロイごとに個別に管理されます。これは、アプリがその存続期間中に自然により多くのデプロイに拡張されるにつれて、スムーズにスケールアップするモデルです。

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 を参照してください。

于 2012-04-03T13:33:51.057 に答える
0

Herokuでは、設定ファイルと変数の複雑なgitベースのデプロイメントを開発するのではなく、すべての機密事項に環境変数を使用します。そうすれば、それらをコードに保持する必要はありません。詳細については、データベースのドキュメントと環境変数のドキュメントを参照してください。これらすべてをそこに入れてから、os.getenv() Pythonのドキュメントを介してアクセスしてください。

heroku cliツールを使用して、アプリの環境変数を確認するには、次のようにします。

 heroku run env

すべての変数を出力します。新しい変数（S3キーなど）を追加するには、次を使用します。

heroku config:add VAR_NAME=value
于 2012-04-03T13:30:23.940 に答える