Geekly Articles each Day

djangoプロジェクトのサーバーへのアップロードを自動化します

djangoプロジェクトをレイアウトするためにVDSを構成するのは非常に面倒で、何かを忘れるのは簡単です（毎日これを行うため）。 このプロセスが自動化されていると、はるかに優れています。少ない労力で、適切に構成されたプロジェクトとそれを操作するための一連のコマンドを取得できます。

このプロセスにはさまざまなアプローチがあります。Python固有（ fabric 、 buildout ）または非固有（ puppet 、 Chef 、シェルスクリプトセットなど）です。

ファブリックアプローチ-ローカルで実行されるスクリプトはsshをサーバーに送信し、そこでコマンドを実行します。 このアプローチは非常に簡単で、デバッグが簡単です。これは良いことです（ハブで確認してください）。 django-fab-deployと呼ばれる自転車が、さまざまなファブリックチームから徐々に現れました。 これは、Debian LennyまたはSqueeze用にサーバーを構成し、その後、最小限の労力でそこにdjangoプロジェクトを展開し、将来これらのプロジェクトを管理できるファブリックスクリプトのセットです。

Debianのリリースに伴い、Squeezeはdjango-fab-deployをより真剣に受け止め、いくつかの粗さを修正しました。今、このプロジェクトについて話す時が来たと思います。 プロジェクトにはドキュメントがあり、叙情的な余談の簡潔な改作があります。


一般原則：

サーバー側：

展開方法を選択するための主な基準は安定性/信頼性であり、ここではapache + mod_wsgi + nginxの束が現在比類のないものです。 ubuntuのサポートを追加するのは難しいことではないと思いますが、ubuntのサポートは今のところないので、なぜそれについて話すのでしょう（私自身はUbuntuを使用しません）。

プロジェクトはバージョン管理システムで適切に保持されます（mercurialは現在サポートされています ）。 プロジェクトがVCSにない場合に備えて、tar.gzをロード/アンパックするセミプラグがあります。 動作しますが、実稼働モードではテストしませんでした（必要はありませんでした）。また、いくつかの機能が表示される可能性があります。

展開を自動化する


サーバーをデプロイする基本的な方法を以下に説明します。何らかの理由で機能しない場合でも、それは恐ろしいことではありません。django-fab-deployは単なるスクリプトのセットです。 それらは部分的に使用したり、覗き見したり、パッチを送信したり、記事を読んだりするのに役立ちます。

クリーンなDebianサーバーがあることを前提としています（後で「クリーン」にすることはできません。詳細は後ほど説明します）。ルートへの公開キーを使用してsshアクセスを構成しました。

OpenVZでVPSを使用しないでください。 VIRTはRSSの代わりにそれらに制限されているため、OpenVZのソフトウェア（Apacheとmysql + innodbを含む）はxen / kvmの場合よりもはるかに多くのメモリを消費します（10倍-はい簡単です）。

プロジェクトの準備

Djangoプロジェクトは、 'local_settings.py'である種のトリックを頻繁に使用しますが、バージョン管理システムにあり、リポジトリには、pip依存関係を持つファイルと、Webサーバーの設定を持つフォルダーがあります。 Django-fab-deployは、実際、これ以外のものを必要としません。 詳細。

1. django-fab-deployとその依存関係をインストールします。

 pip install django-fab-deploy
 pip install jinja2
 pip install -e git + git：//github.com/bitprophet/fabric.git#egg=Fabric-dev

django-fab-deployはFabric 0.9.xでは機能しません。Fabricはgithubからインストールする必要があります。

2.プロジェクトのルートにfabfile.pyファイルを作成します。 このファイルには、サーバー設定を構成する1つ以上の関数が含まれている必要があります。 まあ、なぜなら これは通常のファブリックスクリプトであり、他の（プロジェクト固有の）コマンドがある場合があります。 例：

# my_project/fabfile.py from fab_deploy import * def my_site(): env.hosts = ['my_site@example.com'] env.conf = dict( DB_PASSWORD = 'password', PROCESSES = 2, # ,    Debian Squeeze;     'lenny' # OS = 'squeeze', # ,         (  - 'hg') # VCS = 'none', ) update_env() my_site()


env.hostsに注意してください。 トリックがあります：プロジェクト名をユーザー（my_site）として指定します（Pythonで正しい変数名にする必要があります-ダッシュやスペースは使用しません）。 そのようなユーザーがいなくても構いません。django-fab-deployはそれを作成して、後でsshアクセスを設定できます。 いずれにせよ、プロジェクトごとに別々のユーザーを用意することをお勧めします。

Env.confは、いくつかの規則を適用して物事を単純化します。 たとえば、デフォルトでは、データベースの名前（DB_NAME）はプロジェクトのインスタンスの名前（INSTANCE_NAME）と一致します。これは、env.hostsのユーザーと一致します。

ここで何をどのように構成するかについて詳しくは、 fabfile api documentationを参照してください。

3. Webサーバーなどの構成テンプレートを作成します。

  django-fab-deploy config_templates

config_templatesフォルダーがプロジェクトのルートに表示されます。構成テンプレートがあります。 プロジェクトは異なり、多くの場合、設定を編集する必要があります-少なくとも流readに読んでください。

{{}}で囲まれた変数は、設定テンプレートで使用できます（ここでのテンプレートエンジンはjinja2です）。 これらの変数は、サーバーにテンプレートをレイアウトするときにenv.conf辞書の値に置き換えられます。

4.プロジェクトルートにconfig.server.pyを作成します。 このファイルは、サーバー上のconfig.pyファイルになります。 例：

 # my_project/config.server.py DEBUG = False DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': '{{ DB_NAME }}', 'USER': '{{ DB_USER }}', 'PASSWORD': '{{ DB_PASSWORD }}', 'HOST': '', 'PORT': '', 'OPTIONS': { "init_command": "SET storage_engine=INNODB" }, } }


開発用のローカル設定でconfig.pyも作成します。 config.pyをsettings.pyにインポートします。
 # Django settings for my_project project. # ... from config import * # ...

トリックはよく知られており、多くの場合config.pyはlocal_settings.pyとも呼ばれます。 このファイルは、VCSで無視されるように追加する必要があります（VCSを使用する場合）。

ご覧のとおり、config.server.pyは（config_templatesフォルダーのファイルのような）テンプレートでもあり、env.confの変数もそれに置き換えられます。

5.プロジェクトのルートに「reqs」フォルダーを作成します。 このようなフォルダーの例は、プロジェクトルートから次のコマンドを実行することで取得できます。

  django-fab-deploy example_reqs

このフォルダーには、pip依存関係を持つテキストファイルがあります。 1つのファイルには特別な意味があります：reqs / all.txt。 これは依存関係を持つメインファイルであり、そこからのすべてのパッケージは展開中にインストールされます。 そこで、すべての依存関係を単純にリストするか、（より良い）「-r」オプションを使用して依存関係を持つ他のファイルを接続できます。

django-fab-deploy generate_reqsコマンドもあります。このコマンドは、1つのall.txtファイルでreqsフォルダーを作成し、ローカル環境にインストールされているすべてのpythonパッケージを一覧表示します（pip freezeが示す内容）。

ステップ1〜5が完了すると、プロジェクトは次のようになります。

 my_project
     ...
     config_templates 
         ...
    要求             
         all.txt      
         ...     

     fabfile.py      
     config.py      
     config.server.py 
     settings.py
     manage.py

その場合、プロジェクトの準備は完了です。

サーバーの準備

1. env.hostsで存在しないユーザーが指定された場合、それを作成し、キーによる手動または次のようにsshアクセスを設定します（公開キーのあるファイルが必要です）。

  fab create_linux_account： "/ home / kmike / .ssh / id_rsa.pub"

sshが機能していることを確認します。

  ssh my_site@example.com

2.データベースをセットアップします。 データベースがすでに手動で構成されている場合（たとえば、プロジェクトが既に機能している場合）、何もする必要はありません。 django-fab-deployは、mysqlをインストールし、プロジェクト用の空のデータベースを作成する方法を認識します。

 fab mysql_install
 fab mysql_create_db

mysqlが既にサーバーにインストールされている場合、mysql_installは何もしません。 mysqlがインストールされていない場合はインストールされ、mysql rootユーザーのパスワードはenv.conf ['DB_PASSWORD']に設定されます。

mysql_create_dbは、env.conf ['DB_NAME']という空のデータベースを作成します（この例では、これはenv.hostsからのユーザー名になります）。

mysqlを使用していない場合、またはmysqlユーザーがrootでない場合、すべてを手作業で行うことをお勧めします。 さらに良いことに、自動化（このためのファブリックスクリプトを記述）して、パッチをdjango-fab-deployに送信します。

3.すべて、サーバーの準備ができました。 指を交差させて、プロジェクトのルートからコマンドを実行できます。

  fab full_deploy

すべてが正しく行われた場合、サイトは獲得するはずです。

このコマンド：

ソースコードは〜/ src / <INSTANCE_NAME>にあり、virtualenvは〜/ envs / <INSTANCE_NAME>に配置されます。

django-fab-deployは、Apacheとnginxのデフォルトサイトを無効にし、Apachevsky ports.confをコマンドします（Apacheはポート80をリッスンしなくなります）。 Apacheの他のサイトがサーバー上で実行されていた場合、このためアクセスできなくなります。 nginxだけが突き出ていれば、すべてがうまくいくはずです-django-fab-deployはサーバーに対してトリッキーなことは何もしません。

サーバー管理


サーバーに変更をアップロードして適用する： fab push

別の例（依存関係の更新と移行中のprodサーバーへの変更のアップロード）： fab prod push:pip_update,migrate

Webサーバー設定の更新： fab setup_web_server
fab update_django_config設定の更新（config.server.py）： fab update_django_config

コマンドの完全なリストは、ドキュメントに記載されています。 より高いレベルが必要な場合（スピリット-fabの再デプロイを開始し、すべてがすぐに更新され、コード、設定、依存関係、および移行が完了しました）-fabコマンドを基本コマンドのラッパーとして簡単に記述できます。 プッシュコマンドの実行が多すぎる場合（たとえば、デフォルトでテストを実行する場合）、コードを見て、fabfile.pyにより適切なバージョンを記述してください。 このような実験が有用で成功していると思われる場合は、 バグトラッカーでチケットを開いてください。

アナログ


django-fab-deployに最も近いアナログはwovenです。 どうやら、また素晴らしいこと。 WovenはUbuntuに焦点を当てており、Debianはdjango-fab-deployのUbuntuとほぼ同じようにサポートされています。「マイナーな変更でも動作するようですが、確実に誰も知りません。」 私たちはほぼ同時にすべてのことを始めました。最初はクラスで何らかのゲームがあり、それからすべてが単純化されました。 彼らはさらに遠ざかりました。 一方、django-fab-deployはソースコードの数倍小さく、小さくてシンプルであり、そのまま残ります。

多くの人が同様のプロジェクトをしています。 私は最近github / bitbucketを検索しましたが、djangopackagesに11のアナログ（洗練度の異なる）が追加されました。比較版はこちらでご覧いただけます： djangopackages.com/grids/g/deployment

参照資料


最新のドキュメントは常にpackages.python.org/django-fab-deployにあります。
ソースコードとバグトラッカーを含むリポジトリ： bitbucket.org/kmike/django-fab-deploy

接続：使用、修正、コメント、提案、すべてを改善する方法などを記述します。

この記事の説明はバージョン0.4を参照しており、古くなっている可能性があります。 可能であればドキュメントを読んでください。

django-fab-deployを使用する必要はありません。0から独自のスクリプトを記述し、ウーブン、ビルドアウトなどを使用できます。 しかし、すべてを0で書く前に、もちろん、「宿題」をして、既存のプロジェクトがどのように実装されているかを見る方が良いです。

主なアドバイスは、最も簡単なプロジェクトであっても、サーバーのセットアップと変更のアップロードのプロセスを何らかの方法で自動化することです。これは、手動構成よりも複雑ではなく、将来何回も報われます。

Source: https://habr.com/ru/post/J113636/

More articles:


All Articles