プログラマブログ

by wacul

menu
  • プログラマ
  • Web制作のテストサーバー運用を自動化した話

2014.09.23Web制作のテストサーバー運用を自動化した話

テストサーバー運用意外と手間かかる問題

ワカルでは、自社サービスを行うかたわら、お客様のWebサイト改善のお手伝いを行っています。 外部のミーティングでお客様にサイトなどの制作物を見ていただくなどのシーンも多く、認証付きで公開できるテストサーバーを運用しています。
しかし、プロジェクトごとにテストサーバーを構成するのはなかなかのコストでした。

そこでワカルでは、GitHubリポジトリと連携し、

  • テスト環境の自動デプロイ
  • テストサーバーの追加の自動化

といったことを行っています。

今回は自動化していった手順をご紹介したいと思います。
流行りの仮想化とかとはまた違う地道なお話です。

利用したサービス、ミドルウェア

利用した環境は以下のとおりです。

  • ソースコード管理: github
  • インフラ: Amazon EC2, Route53, ELB
  • ミドルウェア関係: Apache, PHP, MySQL
  • 自動化スクリプト: Fabric (python)

最新ソースが反映されるサーバーを構築する

まずは手で効率化していくところから、徐々に自動化していきました。

Apacheの設定ファイルをプロジェクトごとに書く

弊社のお客様向け制作物のほとんどは、一般的なPHPの構成か、HTMLだけの静的サイトなため、単一のApache/PHPのサーバー上に、複数のVirtuslHostで環境を構築することにしました。

Route53(DNSサーバ) で、特定のサブドメイン以下へのアクセスをワイルドカードで全てテストサーバーへ受け付けるように設定しておきます。( 例えば、 *.test.hoge.com )
こうしておくと、URLもプロジェクト名をドメインに含められるため、わかりやすくなります。例:

1
2
3
http://project-a.test.hoge.com
http://project-b.test.hoge.com
http://project-c.test.hoge.com

プロジェクトごとに、Apacheの設定ファイルを作り、Apacheの設定からインクルードするようにしました。

設定ファイルの例

/data/vhconf.d/project-a.conf
1
2
3
4
5
6
7
8
9
10
11
<VirtualHost *:80>
DocumentRoot /data/repos/project-a
ServerName http://project-a.test.hoge.com
<Directory />
  AuthType Basic
  AuthName "Secret Zone"
  AuthUserFile /data/work/project-a.htpasswd
  Require valid-user
  AllowOverride All
</Directory>
</VirtualHost>
http.conf
1
Include /data/vhconf.d/*.conf

githubと連携して、コンテンツを自動反映する

github には、Web hookという仕組みがあります。 参考
これを利用し、フックを受け付けるサーバーを立てておき、リポジトリへPushされたタイミングでテストサーバー上でPullし、コンテンツが自動的に反映されるようにしました。

テスト環境自体の構築も自動化したい!

上記までで、テストサーバーを公開し、特定のリポジトリへの最新のコードを自動で反映できるようになりました。
しかし、この作業を手動でやるのはとてもめんどくさく、ミスも起こりやすいです。自動化したいですね!

最終的に運用されているのは、以下の図のようなものです。

図

テストサーバー構成管理用のリポジトリを作り、各サイトの設定ファイル(json形式)をコミットするようにし、この設定用のリポジトリ自体も、githubのフックに登録し、以下の処理を行うようにしました。

  • 設定ファイルの一覧を読み込み、テストサーバー上の構成を作り直す
    • Apache設定ファイル・htpasswdファイルの生成
    • githubからソースコードのclone
    • githubのWebhookにテストサーバーを追加
    • Apacheの再起動

設定ファイルの例:

repos/abc.json
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
{
  "name": "ABC社Webサイト",           // 名前(表示、識別用)
  "repositoryName": "abc",            // githubリポジトリの名前
  "branches": [{                      // テストサーバーを構築したいbranchを配列で指定
    "name": "master",                 // branch名
    "sites": [{                       // このブランチの中でたてたいサイトを配列で指定
      "documentRoot": "html",         // リポジトリの中でサーバーのルートにするディレクトリ
      "subDomain": "hoge",            // 使用したいサブドメイン この場合は hoge.abc.testserver.jp
      "basicAuth" : true,             // basic認証の利用
      "auths": [{                     // 認証用のパスワードを配列で指定
         "user": "abc",               // basic認証 ユーザー名
         "password": "abcpassword"    // basic認証 パスワード
       }]
     }]
  },{
    "name": "develop",                // 以下2つめのブランチ
    "sites": [{
      "documentRoot": "html",
      "subDomain": "dev",
      "basicAuth" : false,
      "auths": []
    }]
  }]
}

これで、2,3分で新しいテストサーバーを構成できるようになりました!

現状の構成の課題点と、今後改善したい点

1年ほど運用して、特に大きな問題はなく運用できていますが、現時点で改善したいと思っている点が幾つかあります。

  • すべて共通のApache/PHP環境を使っているので、お客様のサーバーにあわせた微妙な構成の違いを検証できない (現時点では、.htaccessで設定できることのみ対応している)
  • DBが必要な場合などは、手動で構成が必要
  • 上記設定ファイルを書けるのは、なんだかんだでプログラマだけなので、依頼がくる。Webのインターフェイスとかつけて、だれでも触れるようにしたい。
  • サーバーの再構成を全てのテスト環境に対して行うので重い (実装上の手抜きの問題)

現在、これらの問題を解決するために、Dockerを使って、各テスト環境をコンテナに閉じ込めて管理する方向で改善を考えています。はやりのイミュータブルインフラストラクチャってやつですね。

まとめ

今回はワカルで行っているWeb制作時のテスト環境構築の自動化についてご紹介しました。
管理のような仕事をどんどん効率化して減らしていかないといけません。こういった自動化がうまくはまると、プログラマ冥利に尽きるというやつですね!

この記事を書いた人tutuming

株式会社ワカルの技術責任者です。フロントエンドからバックエンドまで、ひと通りやってます。最近の興味はチームづくりと、パンづくりです。

waculでは、プログラマを募集しています。

現在はプロダクトとして、課題発見から改善提案まで自動で行うWeb改善プラットフォーム「AIアナリスト」を開発中です。

waculの採用情報へ

ページトップへ