Archive for the '開発環境' Category

【AWS】Route53を使ってS3のドメインを指定する

AWSを使用しているなら分かりやすさを重視するためにS3のエンドポイントにわかりやすいFQDNをつけてAWSのDNSであるRoute53に登録してみたが下記のようなエラーが出た。


  <Code>NoSuchBucket</Code>
  <Message>The specified bucket does not exist</Message>
  <BucketName>*************</BucketName>
  <RequestId>*******</RequestId>
  <HostId>...</HostId>

エンドポイントに直接アクセスすれば、画像は表示されるのにRote53を経由した場合だとBucketがねぇよ!って怒られる。。。

なんでだろと思ってリファレンスを見ていると、どうやらS3のバケット名とキーの命名規則について

『バケットでは英数字が基本ではあるが、DNS(.s3.amazonaws.com)としても使われる』

なんと!
バケット名と指定するFQDNを同じにしなければいけないとは。。。

バケット名とFQSNを同じにするとRoute53経由で見れるようになりました!!

ちゃんと読めばわかるけど、意外にはまりそうなポイントでした。

参考
http://blog.suz-lab.com/2009/09/amazon-s3.html

http://blog.serverworks.co.jp/tech/2012/08/10/best-practices-for-using-amazon-s3/

デーモン起動・終了時実行の環境変数(パス)の違いに注意

最近、サーバの自動構築にあたり、
サーバ起動時のスクリプトをChefと組み合わせて書いているのですが、そこで問題が。。。

rootユーザでシェルスクリプトをがりがり書いて、sh ~~~で実行確認。
その後サーバの起動時にスクリプトが実行するように/etc/init.d以下に起動スクリプトを作成し、
chkconfig onでサーバを再起動してみると

スクリプトが動いていない

環境変数が違う

調べてみると両者実行時に、環境変数が違うために
コマンドやそれらの設定などが読み込まれずエラーとなるとのこと

rootユーザでのshコマンド実行時とデーモン起動終了時のスクリプトの環境変数の違いについては
以下の記事がすごく参考になりました。

デーモンの起動・終了にはserviceコマンドを利用しよう

そのため、起動スクリプトを記載し確認する際には、
service コマンドを利用して実行しながら確認する必要があります。

serviceコマンドで実行すると、デーモン起動・終了時のスクリプト実行時の環境変数と
同じ環境変数で実行してくれるためいちいちサーバを再起動しなくても確認することはできます。

同じrootで実行してるのなら環境変数も同じにしてくれたらいいのに。。。

CentOSにRedmineを入れてみた

個人的にサービスを友人同士で行いたく、そのプロジェクト管理のためにRedmineを導入してみました!

導入にあたり下記のサイトが非常に役に立ったので共有しておきます。

Redmine 2.2をCentOS 6.3にインストールする手順

つまずいたのは、Rubyのインストール

rootユーザでずっと行なっていたが、rubyのインストール確認でなぜかruby -vと打っても動かず,,,
gemコマンドも使えない状態だったが、一般ユーザに戻って実行すると動かすことが出来た。

rootユーザじゃ使えないのかな!?

でもこれでプロジェクト管理がしやすくなった!

設定系は下記参照!
Redmineのトラッカーやチケットの設定をする

行った設定
・ユーザの追加
・初期はadmin/adminでログインできるためそのユーザの削除
・管理->ロールと管理 で一般ユーザの権限付与
・トラッカーの設定
開発
分析
課題
要望
調査
障害
アイディア

・チケットステータス
新規
作業・担当中
レビュー待ち
フィードバック
終了
却下

・列挙項目のチケット優先度



急いで
すぐに

これでひと通り設定は終了!
メールサーバが入っていないのでメール投げれないのが残念,,,

それにしても、Jenkinsにブログサービス、RedmineにMySQLとその他Webサービス!
1つのサーバに乗せすぎな気もするなぁ...(笑)

【勉強会】第7回Jenkins勉強会 Oracle 青山センター

2013年1月28日(月)にOracle 青山センターで行われた「第7回Jenkins勉強会」に参加してきた時のメモです。

http://connpass.com/event/1690/

今回の勉強会では、組み込み系が中心でC/C++のプロジェクトでJenkinsを利用している方などの発表でした。基本的には組み込み系であってもWeb系であっても裏側の構成は同じであるが組み込み系ならではの作りや注意点などのお話がありました。

最近作っているプラグインの紹介

Jenkinsのうみの親である川口さんの発表で現在開発中のプラグインについてお話されました。

データベースプラグイン

.目標:
 => 全てのデータをXMLで保存するスタイル
 でも,全てをXMLで保存するのは無理がある

 ・起動速度を向上させる
  ファイルサイズが大きくなりがちなデータ
  テストデータの実行時間履歴
  ファイル指紋(トラッキングに)
  コードカバレッジレポート

 Coreの方でDBに保存する
 ・プラグインでもDB
 Audit to Databaseプラグイン
 Jenkowプラグイン(ワークフローなどをJenkinsに入れてしまう)

 標準UI部品を提供
  再利用可能なGUI付きの部品を提供
  DBコネクタプラグインの提供

 テストのデータとかは大きくなっちゃうけどXMLを廃止するのは考えていませんよ!
 DBプラグインのCore部分が出来たので、みなさん使ってくださいよ!

レシピプラグイン

 Jenkinsで使っているプラグインの一部を取り出してそのまま取り出せるような仕組みにしているプラグイン

 背景:
  新しいプラグインを作ったけどどうやって使い方を説明したらいいかわからない!とか1からユーザに設定をさせるのは面倒だ!
 
 「Export Recipe」 ここから公開できる

 インストール ImportRecipe コミュニティーのレシピのカタログからプラグインを選べることが出来インストールできる
  新規プラグインを作るときに、足りていないプラグインの情報なども表示してくれる

 今後プラグインアップデートセンター的なイメージの場を提供して行きたい

遠隔ターミナル・プラグイン

 ターミナルアクセスを追加する
  ローカルでは動いていてもJenkins上では動かないときにJenkinsのせいにする場合がある
そんな時に、Jenkins上のバッチ処理のデバッグや対話的なスクリプト環境で簡単に試せる場を提供する

 「Interactive Terminal」
  ビルドと同じ環境で走っているターミナル
   これはスレーブで走っている

 ブラウザで出来るターミナル環境があるが
ssh にはバーチャルホストがないが、ssh.configに記入することで出来る
sshでジョブ名.localhostで入れる

 Jenkinsは,基本スレーブで動いている
 Jenkinsのリリース番号が500の大台に乗った!!

質問による解凍

☆画像の比較テストは半端な数になる
 ・500MBくらいの成果物が出てくる
 ・でかすぎてJenkinsのバックアップが取らなくなってきてる
   外部のサーバに閉まってリダイレクト出来るようにして欲しいとかの要望はある
 ・クーロンの代わりにJenkinsを使う機会が多い
  アイノードを食いつくっている 1分に1ジョブ回している

『組み込み業界よくあるJenkins環境構築例』

TechMatrixの天久さんによるお話で、品質に関わる製品を販売されていることからお客様方でのJenkins構築例などを紹介や自社内での導入事例といった内容でした。

静的テスト

・xUnitフレームワークを使ったテスト
 ツールのベンダー
  テストツールの実行環境にJenkinsをおすすめしている
  Jenkinsとテストツールを組み合わせた環境を構築したりしている
  既存の環境に導入することもある

組み込み業界でのJenkins

 みんなどうやっているのか知りたいという人が多い
 エンタープライズ系の話が多く組み込み系がないのがないという声が多い

 組み込みであっても一般的な環境がほとんど...
  利用プラグイン:Cpptest Plugin Jtest

 マスターが1つから
  スレーブでビルドを複数
  スレーブでテストをづく数(静的テストや単体テスト)

 ・どこが組み込みっぽいの?
  ※ビルドがクロスコンパイル
  違う環境でコンパイルを通すことで多様な環境に対応

  

静的テストだけではなく単体テスト

 開発者の人がテストを作ってやっているわけだが...
 ・シミュレーターで実施
 ・単体テストをホスト環境で行う(実際の開発環境でする)
  ⇒シミュレーターがない場合や実機で実施する場合には手間が掛かり過ぎる場合などにホスト環境で実施

 ブランチのマージやモジュールの作成は手動で行なっている

 クラウド上に環境開発を置くのが主流になっているが...
  組み込みのお客さんはコードを外に出すのはためらいがある
  AmazonEC2などに置く事例も

 まだやっていないこと
  Jenkinsから実機での単体テストの自動化
  ソースコードレビュー
   Gerritなど...

質問による回答

・自動での実機テストで構想はあるのかどうか?
・どういう理由で実機テストが拒まれているのか?
  用意するのが大変
  パフォーマンスの問題(実行速度や転送速度)重たくなりがち

 モバイルの人たちも苦労している
  AndroidはJenkinsで管理
  スレーブにiPhoneをつなげてチェックするなど

 Androidのテスト環境は進んでいるらしいが..

『キャノンにおけるJenkinsへの取り組み』

キャノン株式会社 デジタルシステム開発本部 ソフトウェア検証室の馬場さんのお話で社内にJenkinsを導入するまでに苦労したことや実際の構築内容をお話されました。

社内共通のデジタルシステム開発への導入

 社内共通のデジタルシステム開発に限定してJenkins導入の実施
  800名のうち約半分がソフトウェア屋さん

  2010年:Jenkinsの導入
  2011年:本部内向けにセミナー実施などして広めていった
  2012年:内製のプラグイン開発など

 SummaryReportプラグインについてなど

Jenkinsの環境について

 概ねチームごとにマスターを分散
  他のチームの影響を受けない受けない方が良い
   実行時のセキュリティー面を考慮
  ※うちも今1つのサーバ上で動いているけど分けたほうが良いんじゃないかな?本格的にテストを導入するなら

 基本的にマスターでビルド禁止(組み込み系の場合)
  マスターの構成は柔軟にしておく
  テスト実行環境に専念するため

 最近は、マスターを同じサーバに入れておく
  テスト環境はスレーブとして違う場所に

 ・LDAP?
 ・KVMベースのVMプール?

プラグインについて

・SummaryReportプラグイン
 ビルド全体のテスト結果のサマリー
  =>詳細は、デフォルトで吐き出す情報

 ツール×レポートの種類
  単体テスト エラー検出(メモリーリーク) コードカバレッジ 静的チェック コードメトリクス

 カスタムレポートプラグイン 

・Lcovの設定
 各種レポートのサマリーを表示

 htmlPubliシャブ
 ダッシュボードビュー
 履歴レポート

テスト結果の表示

 テスト結果として
  テスト成功数
  テスト成功数
  行カバレッジ
  行に対するステップ

 1つのジョブだけでなく複数のジョブのテスト結果をまとめて閲覧できるようにしている

 クリーンビルド?
  カスタムワークスペースの利用がけっこう多い
   成果物の受け渡しが足りていない

 テストファーストではなくてもテストセカンドで
  ※コードと同時にテストを書く
  ※テストラストにだけはならないように!

質問に対する回答

・事業部に展開できていない理由
  宣伝できていない部分も有るが....
  チームの数が多い
  事業部はある製品に人が多い

・テストやビルドが回っている感はあったが入れる前と後でなんか変わったことはあったか?
 Jenkins入れる前は内製のツールが合ったが情報がないしGUIが難しかった...
  Jenkinsは情報があるからユーザが自分から調べて出来る 
  興味が湧いてモチベーションが上がっていた

・環境を作るのに大変だったこと
 CentOSでマスター環境を用意
  Jenkinsの設定とworkspaceの設定など
  rsyncで実施

・Jenkinsボートはいつ公開されるの?
 ライセンスだけでも使えるようになればいいのになぁー^^
  財務の関係で厳しいw

『Jenkinsを使うようになったきっかけとEclipseでの簡単にビルド』

@atottoさんによる発表で、Jenkinsの便利なプラグインについてやEclipseでビルドを実行するお話でした。

発表資料:http://www.slideshare.net/atotto/jenkins-study720130128

1開発のお話...

 C++のビルド&テスト
 Sphinxで快適ドキュメントビルド(ドキュメント自動化)
 ☆Twitterにある

 ビルド作業が手作業であった
  Jenkins入れるなら開発の初期でやったほうが良いよ!

 Jenkins = すごいCrontab
 Eclipse CDT
  C++のためのEclipse

 Java => AntとかMaven
 C++ => Makefile
  でも面倒...

 コマンドラインでプロジェクトをビルで出来る
  Eclipse CDT のHeadless Buildを使えば出来る

  http://htn.to/iyFo9q に書かれている

 ビルドマシンにはEclipseさんとJenkinsが入っているイメージ!!
 google testのコードを入れてそれもビルド&テスト実行
 カバレッジ計測は、gcovで行なっている

使っているプラグイン

・TO DO管理
 Task Scanner
  コード中にTODOタグを集計
   TODOタグをコードに埋め込むと表示されるようにしている

・ログ解析
 Warnings Plugin
  警告解析や自分で定義して解決できる

困っていること

 テストの完全自動化
  製品に組み込む(実機ベースになってしまうところ)
  シリアル通信

  WebインターフェイスはSeleniumの使用

 今後やりたいことお
  eXtreme Feedback Device
   楽しい開発を進めて行きたい

  RaspberryPi
   Jenkins + RaspberryPi + ?を使ってやりたい

以上、エンタープライズ系のお話が中心でしたがWeb系にも活かせるお話が盛りたくさんでした。
と同時に、自分にはまだまだ難しいと感じたため、もっとJenkinsについての勉強やそもそもテストの書き方について勉強していこうと感じることが出来た勉強会になりました。

まとめWiki:https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=65670538

【勉強会】ゲーム開発におけるScrum実践例

2012年10月17日にGMOで行われた、アプリ制作勉強会の参加メモです。


アプリ制作勉強会

http://atnd.org/events/32706

株式会社ゲームポットの佐藤 洋三 (さとうようぞう)さんが「ゲーム開発におけるScrum実践例」という題名でお話されました。

資料:http://www.slideshare.net/yoozoosato/20121017gmo-your

Scrumを取り入れるにあたって

・Scrumを目的に開発を行うのは良くない
・ゲーム開発を楽しくすることが目的でScrumは手段

Scrumとは?

 半分以上が知っているけど知っているけど未挑戦の人が多い

・Scrumの概要
 Scrum=フレームワーク
 創造的に価値を生み出すもの
 スプリントというキーワードが重要
 小さいサイクルで遊べるから状況変化に凄く強い!!

  例:2012年5月にあったところ
   消費者庁がコンプガチャはまずいと言い出した
   4月からコンプガチャを作ると決めてあのイベントを迎えたら・・・大変

   「状況に変化できるのは凄く大切」

 動くもの遊べるものが積み上がっていく
 ※紙のドキュメントで楽しさが伝わるならそれは小説とかでも良い
 ※実際に遊んでみないと楽しさなんてわからない

ゲームポットでのScrumの役割

・[PO(プロダクトオーナー)]
  ちゃんと動いている人はほとんどいなかった
  プロデューサーにPOになってもらいたい願望
  POを明示的に立てないままプロジェクトを立ててそんなに上手くいかなかった
  ※POを立ててその人にPOのしごとをしてくださいというのは結構大変

  POの役割の表
  ・やることが多い
  ・全責任を追わなければならない = 情熱が凄く大切
  ・部署またぎなどをするとちょっとやりずらいところも...

・[開発チーム]
  2〜6人で編成
   通常3人未満は良くないと書かれている
   ※人と人との相互作用が少なくなってしまうから
   しかし,ゲームポッドでは2人でもやっている
   プログラマ+デザイナで行なっている

・[SM(スクラムマスター)]
  3名のスクラムマスターがいる
  1つのプロジェクトに1人は必ずいる!(掛け持ちで発生している)
  
  スクラムマスター兼任の問題
  ・Scrumの会議が大変になる
  ・オーバーヘッドが大変
  ・佐藤さんは3つを兼任 15分の朝会×3回が
  ・スプリントの計画が結構たいへん
  ・兼任する際はスプリントの開始をずらす
  ※スプリント計画ミーティングが被らないようにする

ゲームポットでのプロダクトバックログ

・プロダクトバックログ (スクラムマスターが持ち主)
 「〜〜として〜〜が欲しい」という受け入れ条件を記述する
 
 Q.管理方法で一番管理しやすかったのは?
  ※色々なツールを使ってみた
  ・GoogleDocsで行えると複数人で作業が出来るから効率が良い
  ・「PIVOTAL TRACKER」 1人なら無償だがグループだと有償

 A.結論

 紙最強!!

 ・1枚の紙にやりたいことリストを描いているだけ
 ・印刷して裁断するのもあり!

計画のお話

 全体の計画をたてる = プロダクトバックログ
 「プランニングポーカーをメイン」に「Tシャツサイズ」をたまに利用

 ・初日にスプリントの計画 約2〜4時間くらいかかる
  ※プロジェクトの開始時期をずらさないとScrumマスターは大変

 ・プランニングポーカーは,相対的に見積る
  ビルの図の説明がわかりやすい!!

 見積もることが大切ではない

 ズレを話し合い、認識を合わせることが目的

 ・簡単に行いたい時はTシャツサイズ
  S M L XLでサイズで見積もる
  しかし,ざっくりとなので,時間見積が難しい

 ・タスク分割
  ストーリーに対して
  ・仕様を決める
  ・テーブルの作成・設計
  ・ロジック実装
  ・演出
  ・見積りは時間単位で出す(h)

デイリースクラムについて

 2〜6人のチームで行い常温を維持するため行う
 「共有する内容」
 ・昨日やったこと
 ・今日やること
 ・困っていること
 ・バーンダウンチャート

 デイリースクラムは、

  開発同士の間で情報共有することが目的

 スクラムマスターへの報告を上げてもらうミーティングではない

 ※デイリースクラムでは、問題対私達のという形で向き合う図が良い!!
 ・ホワイトボードに向きあって問題に対して議論しようという考えかた  
 ・朝会の時はホワイトボードに向かって行う
 
※バーンダウンチャート
 .見積りの全ての時間が縦軸 日付
 ・なんで失敗したかを考えるのもスクラムマスターの仕事

振り返りについて

 スプリント(ゲームポットでは2週間)が終わると...
 ・早い段階で振り返り
 ・KPT(KeepProblemTry)を使って行う

 Wikiか付箋に描いている
 ・Keep   : 今回のスプリントで良かったこと
 ・Problem : 今回のスプリントでの問題点
 ・Try   : 今までやってないけど挑戦したいこと

質問

・機能とデザインは密接な関係があるが,タスクとして分割する際にはどのように行なっているのか?

・なぜバーンダウンチャートがおかしくなったのか?
 ※自分たちもScrumを行なっているが、タスクに分解して時間の見積りはするがあまり時間の管理が出来ていないのが現状

・通常3人未満は良くないと言われていが2人で開発を進めていて不都合などはないのか?

.プログラマ+デザイナで行なっている どういう感じで開発を行なっているのか?

・KPTのやり方は、どのように行なっている?
 ※みんなで付箋に書いて1人ずつ発表してそれをまとめるという形式をとっている

以上

自分たちもScrumで開発を行なっていたので、凄くためになるお話でした。

詳しくは、佐藤 洋三 (さとうようぞう)さん発表のスライドを御覧ください。

資料:http://www.slideshare.net/yoozoosato/20121017gmo-your

継続的インテグレーションのススメ Jenkinsでテスト結果を表示

前回のお話でJenkinsとGitHubによる継続的インテグレーションの開発環境の設定を行いました。

GitHubとJenkins連動 自動デプロイ 開発環境設定編

今回は、継続的インテグレーションを行うにあたり実際にJenkinsでテストを実行した際に
「どんなテスト結果を表示してくれるのか?」ということをご紹介したいと思います。

現在FuelPHPを用いて開発を行なっているためここでのテストの実行にはPHPUnitを使用して行っています。

JenkinsとPHPUnitでテスト実行

ちなみに余談ですが, Jenkinsってイギリス人の執事をイメージした名前だそうです。
プロジェクトに優秀な執事がいるような思いが込められてこの名前が付けられたと言われています。

参考:Jenkinsで始める継続的インテグレーション

Jenkinsはイギリス人の執事

では、JenkinsというよりはPHPのUnitテストでどんなレポートを表示してくれるのか?

たくさんあるのですが、大きく5つ紹介します。

  1. テスト結果の表示
  2. コードカバレッジの表示
  3. バグになりそうな箇所や実装上の問題・無駄を検出
  4. 冗長化したコードを自動で検出しコードの最適化
  5. ドキュメントの自動生成

大きくこれら5つについての説明とJenkinsで表示した際の表示内容を見て行きましょう。

テストの結果の表示

テストの結果は、その名の通り成功したテストや失敗したテストの一覧を表示してくれます。

テスト結果の推移

失敗

コードカバレッジの表示

コードカバレッジとは、作成したテストがテスト対象コードのうちどのくらいテストしているかを表している率のことを言います。
コードカバレッジが高いほどテストコードがしっかり書かれていて、品質の良いコードを保つことが出来ています。

コードカバレッジ全体

ちなみにコードカバレッジの表示では、カバレッジ率の表示だけではなく、テストがされている行とされていない行を視覚的に分かりやすく表示することができます。
テストの状況は、テストが実施されたファイル、クラス、行数と細かく表示されます

テストの状況をファイル別に表示

テストがされた行とされていない行
テストがされている行は緑色、されていない行は赤色で塗られています。

テストがされた行とされていない行

バグになりそうな箇所や実装上の問題を検出

3のバグになりそうな箇所や実装上の問題を検出については、独自のルールを取り入れることも出来、反していれば警告を表示するといった設定も行うことができます。下記の例では使われていない変数があるため 「UnusedLocalVariable」 と表示されています。

PMD警告

使っていない変数

独自のルールの詳しい設定などについては次回以降の記事で紹介します。

冗長化したコードを自動で検出しコードの最適化

4の冗長化したコードを自動で検出しコードの最適化については、フォルダ内の各ファイルの重複度合いがグラフで表示されます。
そのため共通化出来るところなどが視覚化されコードの最適化につなげることができます。

ドキュメントの自動生成

5のドキュメントの自動生成については、作成しているクラスのリファレンスを自動で生成してくれるものになります。

検索も可能であり、正しいフォーマットで記述することにより作成したメソッドの説明や引数などの情報をリファレンスとしてまとめてくれます。

自動生成されたPHPDocumenter

このように、PHPUnitで用意されている機能をJenkinsで実行するこによりテストの結果を見やすく表現してくれます。

これらは品質の良いコードを保つきっかけになり、品質の良いサービス作りへの第一歩であると思います。

なんか、これらを見ると早くテストを書きたくなってきませんか(笑?

次回は、これらを表示するための設定について書いて行きたいと思います!!

GitHubとJenkins連動 自動デプロイ 開発環境設定編

前回の記事でGitHubとJenkinsを用いた自動デプロイ環境の概要をご説明しました。

GitHubやJenkinsと連携した開発環境作成でのrsyncとの出会い

今回は、その環境を実現するための設定手順を書いて行きたいと思います。

大きく4つの手順があります。

  1. Jenkinsのインストール
  2. Apacheの設定
  3. JenkinsとGitHubの連携
  4. 自動デプロイ設定

開発環境

・CentOS 6.2
・Apache がインストール済み

Jenkinsのインストール

まずは、Jenkinsのインストール
通常ならば、運用するサーバとJenkinsが動いているサーバを分けるべきですが、サーバコストの都合などで今回は同一サーバ上で動かすことにします。
ApacheサーバとJenkinsサーバが同じport80で待つことはできないので、jenkinsをport:8080で動かすことにします。

1台のサーバにApacheとJenkinsを起動

また、セキュリティ上必要最低限以外のportを開放したくないため、80番ポートのみ開放して内部的に8080に変換する方法をとります。仕組みとしては、port:80番で「あるURL」にアクセスが来た場合に、内部でport:8080に変換してアクセスするという方法です。この仕組みをリバースプロキシーと言います。

リバースプロキシでJenkinsにアクセス

まずは、この形を目指して設定していきます。
前置きが長くなりましたが、早速Jenkinsのインストール
Jenkinsは、yumでインストールしますが、まずはyumでインストール出来るようリポジトリに追加してから行います。

適当なフォルダ(通常 /tmpかな?)で


  sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins- ci.org/redhat/jenkins.repo sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key

を実行後


  sudo yum install jenkins

次にJenkinsを実行するにはJavaが必要であるため、JDKがインストールされていない場合はインストールします。


  sudo yum list \*java-1\* | grep open
  sudo yum install java-1.6.0-openjdk.x86_64
  sudo yum install java-1.6.0-openjdk-devel.x86_64

参考:http://kumagonjp2.blog.fc2.com/blog-entry-103.html

次に『http://ホスト名/jenkins』でアクセスするとJenkinsにアクセス出来るように設定します。
/etc/sysconfig/jenkinsファイルを編集しましょう!

vim /etc/sysconfig/jenkins

デフォルトでは、PORTは8080になっているので、prefixの設定のみ行う


  JENKINS_PORT="8080"

  JENKINS_ARGS="––prefix=/jenkins"

これでJenkins側の設定は終了です。

Apacheの設定

Apacheで起動する際には、バーチャルホストの設定を行ってください。(必須ではありません)
バーチャルホストについては、こちらを参考に...
http://www.atmarkit.co.jp/flinux/rensai/apache08/apache08a.html

Jenkinsにアクセスするためにリバースプロキシの設定を行います。

/etc/httpd/conf/httpd.conf/ か バーチャルホスト別にファイルを分けている場合はそのファイルに下記の内容を追記する


  <VirtualHost *:80>の中に記載
    ...省略...
    
    #jenkinsへアクセス出来るように
    ProxyRequests Off
    ProxyPreserveHost on
    ProxyPass /jenkins http://127.0.0.1:8080/jenkins
    ProxyPassReverse /jenkins http://127.0.0.1:8080/jenkins
    <Proxy http://localhost:8080/jenkins*>
        Order deny,allow
        Allow from all
    </proxy>
  </VirtualHost>

Apacheの再起動!


  sudo service httpd restart

jenkinsの起動


  sudo service jenkins start

注意
※Apacheの開放しているポートに8080が無いことを確認する
※もし8080を開放しているのであれば、コメントアウトする
/etc/httpd/conf/httpd.confの


  Listen 80
  #Listen 8080

これで『http://ホスト名/jenkins』にアクセスして、Jenkinsが開くかどうか確認する。

jenkinsTOPページ

ついでに...

jenkinsの常駐化


  sudo chkconfig jenkins on

リストに入ったことを確認


  /sbin/chkconfig --list | grep jenkins

これで、ApacheとJenkinsが同じサーバで動き始めました!!

Jenkins参考:http://blog.livedoor.jp/tattyamm/archives/4147336.html

〜2013/01/25 追記〜

上記設定では、~~URL~~/jenkinseでアクセス出来ないとの声が多数上がっています。
多分何かの記入漏れだと思いますので、解決し次第追記させて頂きます。

〜2013/01/28 追記〜

上記問題についてですが、ファイアーウォールで8080ポートが解放されていると上手くつながらないそうです。
一度、ファイアーウォール(iptables)で8080ポートを閉じてみて、試してみて下さい。

JenkinsとGitHubの連携

ここからは、自動デプロイ環境構築に向けて、GitHubとの連携を構築していきたいと思います。
前回のおさらいで今目指している形は以下の図の通りです。

理想の開発環境

JenkinsとGitHubの連携を行うために、jenkinsでgit pluginをインストールします。
Jenkinsの管理->プラグインの管理->利用可能で検索してインストール

JenkinsでGit pluginのインストール手順

次にGitHubへは鍵認証が必要であるため、Jenkinsユーザで鍵の認証設定を行います。
Jenkinsをインストールした際に、Jenkinsユーザが既に作成されており、
Jenkinsユーザのホームディレクトリは /var/lib/jenkinsにあります。

では、jenkinsユーザでsshキーの作成を行います


  cd /var/lib/jenkins
  cd .ssh (なければmkdir .ssh)
  sudo -u jenkins -H ssh-keygen -t rsa -C jenkins@hoge.com
  chmod 744 ../.ssh

※パーミッションなどの問題が合った場合、root権限で鍵を作成し/root/.ssh以下に出来た鍵を
/var/lib/jenkins/.sshに移動しchownで所有者をjenkinsに変えるという方法でも大丈夫です。

これで、公開鍵(id_rsa.pub)と秘密鍵(id_rsa)の設定は終了。

次に公開鍵をGitHubに登録します。
プロジェクトごとのキーに設定すると重複してエラーなど出るのでユーザのSSHKeyとして登録する

GitHubに公開鍵の登録

ここで、先ほど作成した公開鍵(id_rsa.pub)の中身を貼り付ける。Titleは好きな名前で良い。

次に大事なのは、GitHubにアクセスできるよう初期アクセスを行うことです。
以下のコマンドでGitHugにアクセス出来るかどうか確認を行なって下さい。


  sudo -u jenkins ssh -T git@github.com
  (メッセージが出たらyesと入力)

最後にJenkinsのgit情報の登録を行う


  sudo -u jenkins git config --global user.email "jenkins@hoge.com"
  sudo -u jenkins git config --global user.name "jenkins"

とりあえずuser.emailは適当で大丈夫です。

次にJenkinsでGitHubからコードを取得するという設定を行います。
そのために、まずは、自動デプロイしたいプロジェクトを作成します。

新規ジョブ作成でフリースタイル・プロジェクトのビルドを選択し、ジョブ名を入力してOKを押します

Jenkins新規ジョブの登録

すると、設定画面が出てくるので中段付近にある「ソースコード管理システム」でGitを選択します。
(この項目が出ていない場合は、Gitプラグインを正しくインストールして下さい)
ここのRepository URLに自動デプロイしたいリポジトリのアドレスを入力して下さい。

JenkinsにgitリポジトリのURLを登録

ここで入力するURLは、http://から始まるURLではなくgit@github.com:から始まるURLを入力して下さい。
これで保存を押して、Jenkinsの初期設定は終了です。

GitHubの設定

次にGitHubへpushしたタイミングで最新のコードをpullしてくる設定を行いたいと思います。
これには、フックという仕組みを利用します。

簡単に説明すると何かアクションが起きたタイミングで、なんらかの処理を行う仕組みのことを言います。
ここでは、GitHubへpushされたタイミングで、Jenkinsがコードをpullしてくるということを実装したいと思います。

フックの仕組み

ここでは、GitHubのService hooksという仕組みを使用します。
Service hooksの設定には、Jenkinsの「ビルドを実行」というところのURLが必要になるためこのURLをコピーしておきます。

ビルド実行URLコピー

右クリックでリンクアドレスをコピーします。

次にGitHubのページへ行き、自動デプロイしたいリポジトリのsettingからService hooksの設定を行います。

GitHub Service Hooksの設定

ここのWebHook URLs に先ほどコピーしたURLを貼り付けて保存します。

これで、GitHubへPushしたタイミングで先ほど入力したURL(ビルドの実行)が呼び出され
最新のコードがJenkinsへpullされるという仕組みの実装が出来ました。

自動デプロイ設定

最後にWebサーバで公開しているディレクトリに最新のコードをデプロイする設定を行います。
ここからは、先日の記事に書いたrsyncを使用します。
rsyncについては、以前の記事を参考に
GitHubやJenkinsと連携した開発環境作成でのrsyncとの出会い

Jenkinsのジョブの設定->ビルドのプルダウンメニューからシェルの実行を選択

Jenkinsシェルの実行

空欄に


    rsync -vr --delete --exclude ".git/" /var/lib/jenkins/jobs/ジョブ名/workspace/ 公開しているディレクトリへの絶対パス

上記設定で、GitHubへpushしたタイミングで自動デプロイが実行され、またテスト用に直接ファイルをサーバにあげてテスト実行後GitHubへPushしたタイミングで公開ディレクトリがGitHubの最新のコードの状態に保たれるという自分にとっての理想の開発環境を構築することが出来ました。

ちなみに別サーバでJenkinsを動かし、そのサーバからrsyncを利用する場合は


    sudo -u user名 rsync -rlptgvC -e "ssh -i 公開鍵名"  /var/lib/jenkins/jobs/Job名/workspace/* user名@IPアドレス:公開ディレクトリ絶対パス

ってな感じで行けるはず,,,

Jenkinsさんは、他にもブランチを切って作業している場合にはブランチの指定やテストが通った場合のみテスト環境へアップさせるなど色々と出来るため、もっと勉強して活用して行きたいと思います!!

ご意見ご指摘、ご感想などありましたらコメント欄へどしどしお書き下さい。
勉強させて頂きます。

長々とありがとうございました!!

参考サイト

GitHubやJenkinsと連携した開発環境作成でのrsyncとの出会い

社会人1年目のエンジニアにおいて開発環境の構築にはかなり時間がかかるもの。
わけの分からないエラーと戦ったり、他の人の環境では動いても自分の環境では動かないなどそういう経験がある人も多いのではないでしょうか?

今回は、GitHubやJenkinsと連携した開発環境を構築する上で出会ったrsyncコマンドとの出会いについてお話したいと思います。

まず、rsyncコマンドとは、ファイルなどのバックアップや同期を行うために使用されるコマンドで、変更分を検出して差分のみを転送することができ、cpコマンドと違って効率的なバックアップを行うことができます。また、ネットワーク経由でもバックアップや同期が行えたり、sshなどのリモートシェル経由でも利用が可能であるためとても便利なコマンドだそうです!

rsyncコマンドロゴ

このrsyncコマンドを知った瞬間、自分たちが構築したい環境を簡単に出来るではないか!と凄く感動しました!

まずは、使いたいと思った背景をご説明したいと思います。

目指すべく開発環境は、ソースコードをGitHubで管理し、継続的インテグレーションを導入するためにJenkinsを利用してサーバへ自動デプロイされる仕組みを構築することです。

理想の開発環境

上の図のようにローカル環境で実装し、ある機能が実装されるとcommitしてGitHubへpushします。
その後GitHubからJenkinsへデプロイされテストが実行されます。
テストが正しく通ればサーバへ反映されるという仕組みです。

しかし、ローカル環境だけではテストが出来ない場合もあるため、テストサーバへはFTPを使ってファイルをあげてサーバ上でもチェックが出来る環境を構築したいと考えていました。

テスト環境に直接ファイルをあげる

しかし、テスト環境にFTPでファイルをあげた際にずっとそのファイルが残り続けるのは良くないため、ローカルからGitHubへpushされJenkinsが動いた時には、サーバにあるコードは全てGitHubにcommitされている最新版へ戻すような設定を行いたいと思っていました。

デプロイ後gitHubの状態にする

それを実現するためにjenkinsでGitHubからとってきたファイルをコピーする方法やそもそもテストサーバのファイルもgitで管理しちゃおうなど色々考えました。

1:ファイルをコピーして同期
 jenkinsはテストを行う前にgitHubから最新版のデータをpullしてきます。その時には/var/lib/jenkins/以下にworkspaceというディレクトリが出来、そこにソースコードがpullされる仕組みになっています。そのファイルをサーバで設定されているドキュメントルート以下にコピーしようという考えです。

 しかし、コピーをするだけだと
 ・不必要なファイルは消えずに永遠に残ってしまう
 ・毎回変更がないファイルもコピーされるので処理が重くなる
 などの問題があったため断念....

2:テストサーバ側もgit管理してしまう
 git stashコマンドを使おうという考えです。git stashは,変更を一時的に退避させるコマンドであり実行するとcommitされたところまで状態を戻すことが出来ます。

git stash

しかし,この方法も本来のgit stashの使い方に則していなったり(感覚的に)、なんか気持ち悪いため断念....

他にも色々考えましたが,なかなかいい方法が思いつかない時に、先輩から「rsyncコマンドを使えば」 とアドバイスを頂いたのがrsyncとの初めての出会いです。

rsyncコマンドでは、コピー元ディレクトリとコピー先ディレクトリでの差分だけをコピーし、またコピー元ディレクトリになくてコピー先ディレクトリにあるファイルを削除するといったことも出来るため,まさに自分たちがやりたいと思っていたことを実現できる!魔法のコマンドです(笑)

いやぁrsyncコマンド最強ですね!!

使い方はこんな感じ

 rsync -avr --delete --stats pre/ next/ 

オプションの説明についてはこちらを参考にどうぞ:
はじめてrsyncを使う方が知っておきたい6つのルール

上記の例だとpreディレクトリ以下にあるファイルをnextディレクトリに同期させるコマンドになります。
–deleteオプションをつけることでnextディレクトリにはあってpreディレクトリにないファイルを削除することができます。

rsyncコマンドの説明

これをJenkinsに設定することによって目指すべく開発環境を構築することが出来ました!!
「rsync最強っす!!」

rsyncコマンドロゴ

次回は、これらの開発環境を整えるための手順を書いていきたいと思います。