5

現在、3 つの linode サーバーがあります。

1: キャッシュサーバー (Ubuntu、ワニス)

2: アプリサーバー (Ubuntu、nginx、rabbitmq-server、python、php5-fpm、memcached)

3: DB サーバー (Ubuntu、postgresql + pg_bouncer)

アプリサーバーには複数のサイト (トップドメイン) があります。各サイトは、virtualenvwrapper で作成された仮想環境内にあります。トラフィックの多い大規模なサイトもあれば、トラフィックの少ない小規模なサイトもあります。

典型的なサイトは、python (django)、セロリ (beat、flower)、gunicorn で構成されています。

私の現在の開発パターンは、アプリ サーバーのステージング環境内で動作し、変更を git にコミットしています。その後、環境を本番環境に変更して を実行しgit pull、 を./manage.py migrate実行してプロセスを再起動しますsudo supervisorctl restart sitename:が、これには時間がかかります。もっと簡単な方法があるはずです！

したがって、docker はすべてを簡素化するのに役立つように思えますが、すべてのサイトと各サイト内のコンテナーを管理するための最善の方法を決定することはできません。

http://panamax.ioとhttps://github.com/progrium/dokkuを見ましたが、それらのいずれかが私のニーズに合っているかどうかはわかりません。

理想的には、ローカル マシンで各サイトの開発バージョンを実行し (cache-server、app-server、および db-server をエミュレート)、そこでコードを変更してテストします。変更が機能していることを確認したら、すべての面倒な作業を行い、変更を Linode サーバー (主にアプリケーション サーバーと考えます) に送信するコマンドを実行し、サーバー上ですべての移行とプロジェクトの再起動を行います。 .

これを達成する方法として、誰かが私を正しい方向に向けることができますか?

4

1 に答える 1

4

私は同じ問題に直面しました。私はこれが最善の答えであるとは主張していません。

Docker に関する実際のターンキー ソリューションはまだないようです。

また、'Django+Docker' チュートリアルのほとんどが 1 つの Django サイトに焦点を当てているため、Web サーバーとすべてを同じ Docker コンテナーにまとめていることにも不満を感じていました。サーバー上に複数のサイトがある場合、単一の Web サーバーを共有する必要があると思いますが、これはチュートリアルで提示されているよりもすぐに複雑になり、もはやあまり役に立ちません。

おおよそ私が思いついたのはこれです：

  • Figを使用して、コマンドライン オプションとして常に入力するのが面倒なコンテナーと複雑な Docker 構成を管理する
  • サイトは、uWSGI + Nginx 上の Django です (ただし、他のサイトを使用できない理由はありません)。
  • サイトごとに git リポジトリと、「サーバー」用の git リポジトリがあります。
  • db、nginx、および各サイトの個別のコンテナー
  • 各サイトコンテナには独自のuWSGIインスタンスがあります...構成の切り替えを行うので、uWSGIをスタンドアロンWebサーバーとして機能する「dev」コンテナ、またはuWSGIソケットがメインに公開されている「ライブ」コンテナを起動できますNginx コンテナーは、フロントサイド Web サーバーとして引き継ぎます。
  • 「dev」uWSGIサーバーがどれほど役立つかはまだわかりません。Django devサーバーを実行し、ローカルコードディレクトリをコンテナー内のボリュームとして共有するように切り替えて、編集してライブリロードを取得できるようにするかもしれません.
  • 「サーバー」リポジトリには、Nginx サーバー、ベース uWSGI アプリなどのすべての共有 Dockerfile があります。
  • 「サーバー」レポでは、デプロイを行うためのFabricタスクを作成しました (サーバー上のサーバーとサイト リポジトリのチェックアウト、Docker イメージのビルド、実行fig upなど)。

デプロイといえば、率直に言って、Docker Registry のアイデアにはあまり興味がありません。これは、新しいコンテナー バージョンをデプロイするたびに、数百メガバイトのイメージ ファイルをレジストリ サーバーにアップロードする必要があることを意味しているようです。その時点で接続帯域幅が制限されていて、非常に効率が悪いと思われる場合、これは最悪です。

そのため、これまでのところ、Git を介して新しいコードをデプロイし、新しいイメージをサーバー上に構築することにしました。私は Docker レジストリをまったく使用していません (ベース Ubuntu イメージ用のパブリック レジストリは別として)。これは Docker の慣習に少し反しているように見えるので、フィードバックをお待ちしています。

最初に行き詰まり、独自のソリューションを構築することを強くお勧めします。Dokku や Panamax など、うまくいくかもしれないしうまくいかないかもしれないソリューションを学ぶのに時間を費やさなければならない場合 (私はそれらのどれもまだ本当に準備ができているとは思いません)、Docker を直接学ぶのにその時間を費やすこともできます...そうすれば、ソリューションをさらに評価しやすくなります。

私は検索の早い段階で Dokku に取り組もうとしましたが、boot2docker と互換性がないため放棄しなければなりませんでした... つまり、OS X では、Docker を実行するために独自の VirtualBox vm をセットアップするという「楽しさ」に直面しています。デーモン。結局のところ、Dokku がどのように機能するのかに固執したいという確信が持てなかったとき、これを面倒にする価値はないように思えました。

于 2015-02-04T13:16:34.150 に答える