こんばんにちは。今週ブログを担当するnishikawaです。早いものでアスタミューゼに入社してからもう10ヶ月が経過しました。本当に時間が経つのは早いなぁと驚いております。

さて、今回はタイトルにも書きましたが弊社のサービスの一つである転職ナビで利用しているバッチをデプロイしたときに感じたコードの管理と構成の管理の話を数回に分けてしたいと思います。

転職ナビは求人票を掲載するためのアプリケーションと、データを色んなアプリケーション間で授受したり、メールを送信するなど裏で色んな作業をしてくれるためのバッチ群に大きく分かれます。

で、後者は大小さまざまなものが存在し、ひしめき合いながら日々の作業を行なってくれているのです。

そんなバッチさん、大体はScalaで作成されているものが多く本番の環境にはデプロイ時に生成したjarファイルが配置されているのですが、それをさらにbashスクリプトでラップするというよくあるパターンで構成されています。

これが本番環境およびステージング環境に配置されているわけですが、このプロダクトの管理方法、いくつか問題があるなぁと色々開発していて感じました。それは・・・

アプリケーションの設定ファイルが配置する環境ごとに違うものを作成しなければいけない（というか作成されているw）
スクリプトも複数環境分用意しなければいけない（というかされているww）
挙句jenkinsなどのCIツールでプロダクトのデプロイを考えたときにデプロイスクリプトも複数作って用意しなければならない（というかされているwww）

とういことになり管理が煩雑になりがちです。この状態が続くと設定ファイルの反映漏れや配置ミスが発生しデプロイしたけど動かないという問題や一応動いているけど本番環境とステージング環境で差異が出るなど運用面でよくないことが起こります。

そこで、これらの問題を解決するために実際にやってみたことや、それに対する考察していきたいと思います。

やったこと: 構成管理用のフレームワークを使用してみる

まず実際に私が半年ぐらいでやってみた構成を書いてみます。

バッチさんの紹介

お名前	求人票データの取り込みバッチ
おところ	転職ナビ保有の本番バッチサーバおよびステージングサーバ
種別	Scala製
特技	特定ディレクトリに配置された求人票（CSVファイル）をデータベースに投入するよ！

構成（Before）

今回の「求人票データの取り込みバッチ」の開発プロジェクトのディレクトリ構成は以下です。

joboffer-csv-import-batch
├── csvroot
│   ├── astamuse
│   │   └── csv
│   └── ＜提携先ごとの求人票配置ディレクトリ＞
├── joboffer-csv-import-batch.iml
├── pom.xml
├── project
├── shell
│   ├── local
│   │   ├── CsvImportForAstamuse.sh
│   │   └── ＜各提携先の実行スクリプト（ローカル用）＞
│   ├── production
│   │   ├── CsvImportForAstamuse.sh
│   │   └── ＜各提携先の実行スクリプト（本番用）＞
│   └── staging
│       ├── CsvImportForAstamuse.sh
│       └── ＜各提携先の実行スクリプト（ステージング用）＞
├── src
│   ├── main
│   │   ├── resources
│   │   │   ├── application.conf
│   │   │   ├── application_production.conf
│   │   │   ├── application_staging.conf
│   │   │   ├── logback-production.xml
│   │   │   ├── logback-staging.xml
│   │   │   └── logback.xml
│   │   └── scala
│   │       └── ＜ソースコード群＞
│   └── test
│       └── ＜テストコード群＞
└── target

以上を見て分かる通り、スクリプトも設定ファイルも本番用、ステージング用、ローカル試験用で別れているのが分かります。そして、これらが配置後は以下のようになります。

joboffer-csv-import-batch
├── CsvImportForAstamuse.sh
├── ＜提携先ごとのスクリプト＞
├── csvroot
│   ├── astamuse
│   │   ├── csv
│   │   └── old_csv
│   └── ＜提携先ごとの求人票配置ディレクトリ＞
├── joboffer-csv-import-batch.jar
└── logs

で、この構成を実現するために以下の手順でデプロイを行います。

■ローカルで実施

ビルド用のワークディレクトリを作成する
gitリポジトリから資材をダウンロードしてくる
設定ファイルをコピーする
ビルドする

■リモートで実施

デプロイ先のディレクトリを全て作成する
スクリプトをコピーする
ビルドされたjarファイルをコピーする

さて、上のデプロイ手順、一つずつ手でやっていたらとても面倒です。弊社ではjenkinsを利用してこれらの作業をやっているのですが、使用しているのはpythonスクリプトです。そのため、jenkinsで利用するスクリプトも本番環境用とステージング環境用で分かれております。

構成（After）

そこで、構成管理用フレームワークを利用し先に述べたデプロイの手順を実施します。以下は私が作った定義ファイル群とそのディレクトリ構成です。（chefが使えないのでAnsibleです。Chefファンの皆様ごめんなさい。

joboffer-csv-import-batch/
├── host_vars
│   ├── hosts
│   ├── localhost.yml
│   ├── prd-tennavi-bch01.yml
│   └── stg-tennavi-bch01.yml
├── roles
│   ├── create_package
│   │   ├── files
│   │   │   └── conf
│   │   │       ├── application.conf
│   │   │       └── logback.xml
│   │   ├── tasks
│   │   │   └── main.yml
│   ├── deploy_package
│   │   ├── files
│   │   │   └── shells
│   │   │       ├── CsvImportForAstamuse.sh
│   │   │       └── ＜提携先ごとのスクリプト群＞
│   │   └── tasks
│   │       └── main.yml
│   └── get_repository
│       └── tasks
│           └── main.yml
├── site_create_package.yml
├── site_local.yml
├── site_prd.yml
└── site_stg.yml

これを利用するためにとった開発プロジェクトの構成が以下になります。

joboffer-csv-import-batch
├── joboffer-csv-import-batch.iml
├── pom.xml
├── project
├── src
│   ├── main
│   │   ├── resources
│   │   │   ├── application.conf
│   │   │   └── logback.xml
│   │   └── scala
│   │       └── ＜ソースコード群＞
│   └── test
│       └── ＜テストコード群＞
└── target

結果

いかがでしょうか？テコ入れをする前の構成に比べてディレクトリがすっきりしていることと思います。ここで注目していただきたいのは本番やステージングにアップロードするための設定が環境ごとに存在しないということです。これで設定漏れが最小限に防げると思います。当たり前といえば当たり前の構成ですが、構成管理用のフレームワークがなかった頃は、この構成にするためには手順書をたくさん書かないといけなかったので、それがコードだけで管理できるというのがどれほど素晴らしいか理解していただけるかと思います。

以上で、ある程度の煩雑さは解消されました。しかしまだこの構成でも煩雑さは残ります。これについては次回以降、考察を行っていきたいと思います。それではまた今度。