3

サーバー上で Django アプリを整理するベスト プラクティスの方法を見つけ出すことに興味があります。

  • Django コードはどこに配置しますか? （古い）年鑑には /home/django/domains/somesitename.com/ と書かれていますが、 /opt/apps/somesitename/ に配置されているものも見ました。/opt/ のアイデアはグローバルではないため、より適切に聞こえると思いますが、以前に opt を見たことがありません。おそらく、アプリをサイト固有のデプロイヤー ユーザーのホーム ディレクトリに配置する方がよいかもしれません。

  • 1 人のグローバル デプロイヤー ユーザー、サイトごとに 1 人のユーザー、またはサイト環境ごとに 1 人のユーザー (sitenamelive、sitenamestaging など) を持つことをお勧めします。1サイトに1つと考えています。

  • 設定ファイルをどのようにバージョン管理しますか? 現在、ソース管理の最上位にある /etc/ フォルダーにそれらを配置しています。例: /etc/nginc/somesite-live.conf。

  • サーバーのプロビジョニングと展開をどのように行いますか? Python ベースの何かを期待して、何年も Chef と Puppet に抵抗してきました。Silver Lining はまだ準備ができていないようですが、Patchwork (https://github.com/fabric/patchwork/) には大きな期待を寄せています。現在、いくつかのカスタム Fabric スクリプトを使用して展開しているだけですが、「サーバー プロビジョニング」は bash スクリプトと、キーを追加してユーザーを作成するためのいくつかの手動手順によって処理されます。Silk Deployment (https://bitbucket.org/btubbs/silk-deployment) がセットアップに最も近いと思われるため、調査しようとしています。

ありがとう！

4

1 に答える 1

1

展開しているサイトの種類について、より多くの情報が必要になると思います。サイト間の関係に基づいて、プログラムと「法的」（ビジネス関係など）の両方に違いがあります。

  • サイトが異なる人によって「所有」されている場合、「サイト」ごとにシステム アカウントを持つと便利です。少数のクライアントを持つ Web デザイナーまたはプログラマーの場合は、分離することでメリットが得られる可能性があります。
  • フォーラム サイトやブログ サイトなど、サイトが関連している場合は、(当社のような) 単一の展開システムからメリットが得られる可能性があります。
  • ライブラリの場合、信頼できるソース (pypy、github など) でホストされている場合は、そこに残してそこからデプロイしても問題ないでしょう。稼働中または停止中の危険なホスト上にある場合は、コピーを取得して配置します。 git リポジトリの / thirdparty フォルダーにあります。

FABRIC ファブリックは素晴らしいです - そのセットアップと構成が適切であれば:

  • ここには、誰もサーバーにログオンする必要がないことを意味するポリシーがあります (これはほとんど真実です - 生の nginx ログ ファイルを見たい場合がありますが、それはまれです)。
  • 個々の機能ブロック (restart_nginx、restart_uwsgi など) があるようにファブリックを構成しましたが、
  • すべての小さなブロックを正しい順序で実行する高レベルの「ビジネス」関数 - すべてのサーバーを更新するには、単に「fab -i secretkey live deploy」と入力します - live は live サーバーの設定を設定し、ldeploy をデプロイします ( .ssh キーが正しく設定されている場合、-i はオプションです) 。
  • ライブ設定が使用されている場合、デプロイを実行する前に「よろしいですか」と尋ねる制御フラグもあります。

コードのレイアウト

したがって、コード ベースのレイアウトは次のようになります。

/         <-- folder containing readme file etc
/bin/     <-- folder containing nginx & uwsgi binaries (!)
/config/  <-- folder containing nginx config and pip list but also things like pep8 and pylint configs 
/fabric/  <-- folder containing fabric deployment
/logs/    <-- holding folder that nginx logs get written into (but not committed)
/src/     <-- actual source is in here!
/thirdparty/ <-- third party libs that we didn't trust the hosting of for pip

バイナリをリポジトリにロードするため、おそらく物議を醸す可能性がありますが、ボックスでnginxをアップグレードし、ロールバックしたい場合は、gitを操作するだけです. どのビルドに対して何が機能するかを知っています。

デプロイの仕組み:

すべてのソース コードは、プライベートな bitbucket リポジトリでホストされています (多くのリポジトリと少数のユーザーがいます。これが、github よりも bitbucket の方が適している理由です)。bitbucket 用の独自の ssh キーを持つ「サーバー」のユーザー アカウントがあります。

Deploy in fabric は、各サーバーで次のことを実行します。

  • irc ボットが irc チャネルで開始をアナウンス
  • gitプル
  • pip deploy (リポジトリの pip リストから)
  • syncdb
  • 南に移住
  • uwsgi再起動
  • セロリの再起動
  • irc ボットが irc チャネルに完了をアナウンスする
  • 可用性テストを開始する
  • 可用性テストの結果を発表 (およびレポートをプライベート ペーストビンに投稿)

「可用性テスト」 (ライブ サーバーに対する単体テストと考えてください) - 「テスト」アカウントのすべての Web ページと API をヒットし、ライブ統計に影響を与えずに正常なデータが返されることを確認します。

また、バックアップ git サービスも用意されているため、bitbucket がダウンした場合は適切にフォールオーバーします。また、「デプロイ」ブランチへのコミット時にデプロイを実行させるジェンキンス統合もあります。

怖いビット

クラウド コンピューティングを使用して高いスループットを期待しているため、ボックスは自動的に生成されます。git リポジトリなどのコピーを含むデフォルトのイメージがありますが、常に古くなっているため、それ自体に展開を行う起動スクリプトがあります。つまり、クラスターに追加された新しいボックスは自動的に最新の状態になります。

于 2012-06-21T14:51:59.513 に答える