Jenkinsでやってみてよかったこと・やめておいた方が良かったこと

第8回大阪Jenkins勉強会 LT(2016/12/10)

くんすと (kunst1080)

目次

● コンテキストの共有○ 自己紹介 １分くらい

○ 設計・開発・運用しているシステムの構成 １分くらい

● Jenkinsでやってみてよかったこと・やめておいたほうがよかったこと○ 事例1～9 1０分くらい

コンテキストの共有

自己紹介

● くんすと (@kunst1080)○ クラスタ: #シェル芸 #lovelive #lovelive_sunshine○ L3以上のレイヤがとくい

● おしごと○ ジャンル: 受託系のSE?　(会社全体ではほぼSES)

■ 数年前まで : 某情シスの協力会社 → (並行期間) → 最近: 製造業の顧客と組んでSaaSを提供

○ プロダクト : 町工場のための納期管理システム

■ PlayFramework + Java + MySQL■ エンドユーザはまだ数社。まだまだこれから！

○ 体制

■ お客様(営業・企画 ) <- うちのボス (営業・企画・要件 ) <- 自分(要件・設計・開発・運用 )■ 最近後輩が入ってきた！ ※が、頻繁にSI案件へドナドナされる…

● L2以下のレイヤがとくい

開発サーバ (Ubuntu)

コンテナ

設計・開発・運用しているシステムの構成

テスト環境

Compute(CentOS)

RDB(MySQL) ObjectStorage

本番環境

Compute(CentOS)

RDB(MySQL) ObjectStorage

ﾘﾊﾞﾌﾟﾛ・LB ﾘﾊﾞﾌﾟﾛ・LB

Jenkinsでやってみてよかったこと・やめておいたほうがよかったこと

Jenkinsを普段の開発で使っている中で出てきたグッドノウハウ・バッドノウハウを共有します

事例1: ビルド・テスト

● Gitのwebhookを使って起動

○ GitBucketプラグインに移行中ですが

うまくいくときといかないときがある……

● Git-Flowを採用しています

○ featureブランチにpushしたら

■ テスト・ビルド

○ develop・masterブランチにpushしたら

■ テスト・ビルド・テスト環境へデプロイ

● 手動ビルド、手動テスト

○ tagを指定して実行

■ 切り戻しのときに使用

普通に良いです。

※開発サーバが弱く並列実行しにくいことが玉に

瑕

事例2: デプロイ

● テスト環境へは自動実行

○ ビルドの後続ジョブとして

● 本番環境へは手動でボタンを押してデプロイ

○ 月に1～2回程度なので大した負担ではなく

● ジョブの内容はシェルスクリプトの実行

○ scpでzipを転送

○ sshでリモートのzipを展開

これで運用していますがどことなく正しくない感じが

する。デプロイ専用のツールなど使ったほうがいい

のかな？

事例3: ビルド・テスト後のドキュメント生成

特に、SchemeSpyを使ったDB定義書が非常に見

やすくてよいです。

● テスト後

○ JUnitテストレポートの集計

○ Checkstyleの実行・レポート集計

● ビルド後

○ Javadocの生成・保存

○ DB定義書の生成 (SchemeSpy)○ クラス図などのドキュメント生成(Doxygen)○ ソースコードのステップ数カウント

■ Jenkinsの機能で

■ ※規模の肥大化の目安

※SchemeSpyでできたもの

事例4: 起動・停止・再起動

何か専用のツールを使ったほうが良さそう。

何かありますかね？

● APサーバの

○ 起動

○ 停止

○ 再起動

● sshでリモートの起動・停止のシェルスクリプ

トを叩いています。

事例5: APサーバの死活管理

運用監視ツールの導入をサボって Jenkinsでやっ

ています。後悔しかない。

早くzabbix導入したい。

● curlコマンドを使ってAPサーバの死活管理を

しています。

● 死んでいたら前述の起動ジョブが走ります。

● ログを溜め込みすぎると設定画面すら開か

なくなって運用を続けられなくなるので注意 ()

事例6: DBのバックアップ

RDBのサービスでもバックアップは取られています

がそっちはタイミングを厳密に指定できないっぽい

ので…

● 毎日、mysqldumpによるバックアップを取得

しています。

● 31日でローテーション

● 臨時作業をするときは、直前にジョブ実行ボ

タンを押して臨時実行。

事例7: DB情報のコピー

調査のときに活躍してます。

● 前の項目で取得したバックアップを、 mysqlコマンドに流し込んでテスト DBにインポート

● 調査やテストの時などに使用。

● 1ヶ月以内の任意の日付の状態を確認できる

ので便利。

事例8: 本番DBと開発DBのスキーマ比較

頻繁に列を足したり項目長を変えたりしてるので、

そんなときに実際の差分をちゃんと確認できるので

便利です。

本番作業後の確認にも使えます。イチオシ！

● 本番DBのスキーマ情報と開発DBのスキー

マ情報をmysqldumpコマンドで取得し、diffしています。

● diff結果はConsole Outputで確認。

差分があるとビルドエラー。　差分が無くなるとビルド成功。

※scheme diff

事例9: 特定のコマンドの実行

● free, jstat, ps でリソース確認

● セッション数を確認する SQLクエリを発行

● iPhoneからサーバの状態を確認したり、

サーバ状態の記録を取るために無理やり作

りました。

zabbixでやれ

ありがとうございました。