薔薇

バラって何？

薔薇です。

ひとつのサーバ上おなじのアプリケーションを複数バージョンに動かす簡易のデプロイ環境です。

何ができる

複数バージョンのウェブサービスをDockerコンテナとして同時に動いて、リバースプロキシのNginxで特定のhttp headerを判断し、適当なコンテナにアクセスを振り分けること。

テストにも、A/Bテストにも、さらにgray deployも使えると思います。

アーキテクチャは下記の図のようです：

キーポイントはNginxです、とりわけproxy_pass、mapなどの仕組み。

例えば、これはNginx設定ファイルの一部です：

{{upstream}}

location /{
  add_header u $u;
  proxy_pass http://backend_$u;
}

baraでは動的に複数のupstreamを作成し、mapの構造通じて、$uの値を求めて、該当するバックエンドにアクセスを委託します。

詳しいはソースコードをご確認ください。MITライセンスで配布されています。

使い方

以下、簡単な使いかたを(主にDev環境で)イメージして説明します。

事前設定事項

まずは、設定ファイルとして、下記のいくつのファイルを実際の環境にあわせて設定してください。

Docker Daemon

config/initializers/docker.rbを編集し、Dockerへの接続情報を設定します。

Nginx Server

config/initializers/nginx.rbを編集し、Nginxの設定ファイル場所とnginx実行ファイル場所を設定します。

.envをを生成

.envにはDocker用証明書の格納場所、SMTPの設定とTokenなどを設定します。

cp .env.example .env
vi .env
source .env

Rails を起動します

簡単に言えば、開発環境でrake db:migrateにしてからrails s -b 0.0.0.0 で良いでしょうか。

production環境なら：

RAILS_ENV=production rake assets:precompile
RAILS_ENV=production rake db:migrate
RAILS_ENV=production rails s -b 0.0.0.0

Nginx設定ファイルテンプレート

まずは、Nginxサーバ用の設定ファイルのテンプレートを用意します。

実際のNginxの設定ファイルは、デフォルト(緑の「Active」ラベルが付いている項目)になっているテンプレートに基づいて作成されます。

また、テンプレートに{{upstream}}というプレースホルダが書けます。書くと、Nginxの設定ファイルを生成する場合、実際に動いてるDockerコンテナをベースにupstreamを動的に作成します。

テンプレートを編集する例：

レンプレード一覧：

Docker イメージ管理

baraは簡易なイメージ管理機能が備えています、dokcer pull、docker rmi、docker inspectなど該当するコンマンド。

イメージ一覧：

イメージをプルする：

コンテナをデプロイする

コンテナをプロイする画面：

今の段階で設定できる項目は少ないです。ただコンテナ名、CMDに渡すパラメーテのみです。

パラメータは行ごと（改行で）に分けられます。

コンテナデ一覧画面にては、コンテナを停止、起動また削除することができます。

Nginx設定ファイルを作成

Nginxサービス画面では、Nginx設定ファイルの生成、編集とNginxサーバの再起動(nginx -s reloadまたはservice nginx restart)などができます。

Nginx設定ファイルの生成は、デフォルトのテンプレートに基づいて、動いてるDockerコンテナ情報取得して作成されます。

中に：

  map $http_v, $u{
    ~aaa aaa;
    default default;
  }

$http_vはHTTP Headerのvを表すもの、その値に対し、$uに値を与えます。ブラウザにて設定したHTTP header vから、適当な$uを見つけ出し、バックエンドとして使われます。

もし作成した設定ファイルに不備があたら、その場で編集することもできます。

設定ファイルが整えたら、Nginxサーバを再起動します。

ModHeaderでアクセスしたいコンテナを指定します

指定したコンテナのアプリケーションにアクセスするのは、ModHeaderを利用しHTTP Headerを設定することで実現できます。

下記の図のように、v headerを適当な値を指定すれば、その名に一致するコンテナをNginxが振り分けます。

それにNginxの設定ファイルにもしadd_header u $u;を追加すれば、ブラウザにてどのバックエンドが使われたのもはっきりわかっています。

制限事項

今はテスト環境で実際に使っています。ただ制限事項もいくつあります。使えるかどうか、多分これらの要因は決め手ではないでしょうか？

Volumeが使えない
-Pをしています
一つのサーバ上にしか動けない
Nginx設定ファイルは一つしか預けられない。

自分はStateless主義なので、-vが使わないです。

-Pは、全てのポートをホストに公開しています、でも普通の場合、一つのアプリが公開するポートは一つのはずです。これでも問題ない。

また第3点、今の段階では、うちにはその要求はないです。

第4点はややこしいです。ちょっとした複雑のアプリケーションは、Nginxの設定来るはいくつの設定ファイル分散化されています、その様なケースでは、今のbaraまだ対応できません。