intra-martが推進する · ghe, jenkins master, jenkins agent はec2 上に構築...

Copyright © 2017 NTT DATA INTRAMART CORPORATION

NTTデータイントラマート

開発本部

阿久沢拓也

intra-martが推進する

DevOpsの取り組み2017


目次

2

これまでのintra-mart開発環境と課題

新しいintra-mart開発環境の概要

各サービス・ツールの活用&運用方法

環境移行についての苦労話

345

1 DevOpsとは？

2

6 今後の展望


3

DevOpsとは？1


DevOpsとは？

4

オライリー主催の「Velocity 2009」イベントにおける

Flickrのエンジニアによるプレゼンが初出

“開発と運用が協力すれば1日に10回

デプロイができる”出典：https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-

cooperation-at-flickr/

開発と運用の協力により

迅速かつ確実な価値提供を目指すための改善活動

Development Operations


DevOpsを実現するには？

5

開発と運用の対立

開発：新しい機能を追加したい

運用：安定したサービスを提供したい

開発と運用の対立を防ぐにはツールの活用、組織文化の

両面の改善が必要

最近では、開発＆運用手法や自動化、計測といった

様々な観点からDevOpsに取り組む流れが起きている


intra-martにおけるDevOpsとは？

6

intra-martはパッケージベンダなので、一般的なシステム

開発、及び運用とは少し異なるが…

どんどん機能追加したい

品質が悪いとこちらの開発に支障が出る

常に万全な開発環境を利用したい

開発環境を保持するための対応時間や費用を抑えたい

開発者A

開発者B

開発環境管理者

対立



7

開発者

ビルドサーバ開発用リポジトリ

お客様

開発成果物をビルド

ビルド成果物をデプロイ

資材を利用して開発

最新環境の構築

フィードバック

リリース

試験環境



8

開発者

ビルドサーバ開発用リポジトリ

お客様

開発成果物をビルド

ビルド成果物をデプロイ

資材を利用して開発

最新環境の構築

フィードバック

リリース

試験環境

この開発サイクルにおける効率や品質の改善、および開発環境の安定運用への取り組みが

intra-martにおけるDevOps


これまでのIM開発環境と課題2

9


これまでのintra-mart開発環境

10

コミット Polling

ビルド＆テスト

デプロイ

開発用リポジトリ

On-premise

開発者 SVNJenkins


これまでのintra-mart開発環境

11

コミット Polling

ビルド＆テスト

デプロイ


On-premise

開発者 SVNJenkins

動作しない不完全なコードがコミットされる

レビューしにくい、されない

ビルド環境の秘伝のタレ化

障害発生時の対応負担大

ローカルではビルドできたのにビルドサーバでは失敗


これまでの課題

12

ソースコード管理


レビューをもらうためにSVNにコミットする必要がある

気軽にリモートにコミットできない

レビューがしづらい・レビュー漏れがある

並行開発がしづらい（シーズン間、作業者間）

ビルドサーバ


開発者のローカルビルド環境と差異がある

単一のサーバでジョブが実行されるため、

ジョブの同時実行数に制限あり


これまでの課題

13

開発環境の運用

ビルドサーバ乱立によって管理担当者が不明確

ディスクサイズの拡張などの手間

障害発生時のダメージや対応コスト


新しいintra-mart開発環境の概要3

14


新しいintra-mart開発環境

15

On-premise

ECS

ECRECS Cluster

EC2 EC2r3.large t2.mediuml

・Tokyoリージョンで稼働・AZは1つ

(∵ビルド環境のため)

M4.large

開発者 GHE Jenkins Master

Jenkins Agent

Jenkins Agent

Jenkins Agent



新しいintra-mart開発環境

16

On-premise

ECS

ECRECS Cluster

EC2 EC2r3.large t2.mediuml

・Tokyoリージョンで稼働・AZは1つ

(∵ビルド環境のため)

M4.large

開発者 GHE Jenkins Master

Jenkins Agent

Jenkins Agent

Jenkins Agentソースコード管理にGitHub EnterPrise を採用

Jenkins のジョブは Agent のDockerコンテナで分散実行

開発環境の大部分をAWS上に構築



Jenkins MasterGHE開発者

ビルドの流れ

17


On-premise

ECS

ECRECS Cluster

①ソースコードをpush

② Hook

⑤ビルド&テスト

③ Jenkinsジョブ実行

⑥デプロイ

Jenkins Agent

④ DockerイメージをPull

Jenkins Agent

Jenkins Agent


改善された点

18

ソースコード管理


→ Gitフローの採用により、気軽にコミットが可能

並行開発がしづらい（シーズン間、作業者間）

→ Gitフローの採用により、並行開発を可能に

レビューがしづらい・レビュー漏れがある

→ GHEのプルリクエスト機能、Status Check機能の

活用によって解消


改善された点

19

ビルドサーバ


→ ビルドジョブ、ビルド環境のコード化で可視化

開発者のローカルビルド環境と差異がある

→ Dockerによる構築で共通のビルド環境を利用可能

単一のサーバでジョブが実行されるため、

ジョブの同時実行数に制限あり

→ ECSの活用によるスケーラブルなビルド環境を実現


改善された点

20

開発環境の運用

ビルドサーバ乱立によって管理担当者が不明確

→ スケーラブルなビルド環境の実現による一元化

ディスクサイズの拡張などの手間

→ EC2の利用によって簡単にリソースの変更が可能

障害発生時のダメージや対応コスト

→ EC2やDockerの活用で、簡単かつ迅速な復旧が可能


リリースの流れ

21

社内リポジトリ

On-premise

S3

ダウンロードライブラリドキュメントアーカイブ

ドキュメントライブラリ

出荷メディア用サーバ

リリース担当者

①リリースジョブ実行

②リリース資材取得

③リリース

公開リポジトリ


その他の取り組み

22

チケットによる要件管理

サポートチームや他本部との情報共有

GHEと連携し、要件に対する修正箇所を確認可能

開発リポジトリの更新時に自動でテスト環境構築

CUIでwarファイルを作成し、Dockerでセットアップを実行

常に最新環境で動作確認が行える

セキュリティへの取り組み

脆弱性診断ツールによるチェックを要件の終了条件としている

脆弱性情報を監視してIMBox（社内SNS）に自動投稿


その他の取り組み

23

Jenkinsジョブの状況をモニタリング

社内に設置されているモニタに表示

ジョブのキュー情報やエラー情報を共有


各サービス・ツールの活用&運用方法4

24


主要ツール・サービス

25

AWS

EC2

ECS/ECR

GitHub Enterprise(GHE)

Jenkins

Docker


Amazon Elastic Compute Cloud (EC2)

26

EC2とは

安全かつスケーラブルな仮想サーバの用意を素早く行える

AWSのサービス

使用時間、データ転送量の従量課金制で、初期費用はなし


Amazon Elastic Compute Cloud (EC2)

27

GHE, Jenkins Master, Jenkins Agent は EC2 上に構築

必要に応じてディスク容量等のリソース追加が容易に実施可能

リリース間近になるとJenkinsのメモリ増強を行っている


Amazon EC2 Container Service(ECS)

28

ECSとは

AWSが提供するスケーラブルかつ高性能なDocker管理サービス

EC2のクラスターを作成し、Dockerコンテナを利用した

サービスを効率的に配置、実行できる

実行数などによる条件で、Auto Scallingが可能

Amazon EC2 Container Registry(ECR)の利用で

Dockerイメージの管理が可能


Amazon EC2 Container Service(ECS)

29

Jenkins のジョブ実行に利用

プラグインの利用で簡単に連携可能

詳細は後ほど


GitHub Enterprise

30

GitHub Enterpriseとは

分散型バージョン管理システムである「Git」を利用した

共有ウェブサービス「GitHub」のクローズド版

「ブランチ」を利用した資材の並行管理が容易に可能


GitHub Enterprise

31

Git flow × Pull request で開発

Master

Release

Develop

Feature

Feature

Feature

時間


GitHub Enterprise

32


Master

Release

Develop

Feature

Feature

Feature

時間

製品としてリリースするためのブランチ

結合試験期間にDevelopブランチから作成されるブランチ基本的に結合バグの修正のみ行われる

開発用の最新ブランチ開発用リポジトリはこのブランチから作成される

機能追加やバグ修正を行う作業用ブランチ基本的にpushはこのブランチにのみ行われるプルリクエストを通してDevelopブランチにマージされる


GitHub Enterprise

33


Master

Release

Develop

Feature

Feature

Feature

時間

作業ブランチ作成


GitHub Enterprise

34


Master

Release

Develop

Feature

Feature

Feature

時間

並行して別の作業ブランチ作成が可能


GitHub Enterprise

35


Master

Release

Develop

Feature

Feature

Feature

時間

他ブランチに影響なくコミットが可能

他ブランチに影響なくコミットが可能


GitHub Enterprise

36


Master

Release

Develop

Feature

Feature

Feature

時間

プルリクエストを通じてマージ



GitHub Enterprise

37


Master

Release

Develop

Feature

Feature

Feature

時間

結合試験フェーズ開始

並行して次期シーズンの修正が可能


GitHub Enterprise

38


Master

Release

Develop

Feature

Feature

Feature

時間

結合バグの修正



GitHub Enterprise

39


Master

Release

Develop

Feature

Feature

Feature

時間

リリース

結合バグ修正のマージ


GitHub Enterprise

40


Masterブランチ

製品としてリリースするためのブランチ

Releaseブランチ

結合試験期間にDevelopブランチから作成されるブランチ

基本的に結合バグの修正のみ行われる

Developブランチ ←要件チケットにはこの情報が連携される

開発用の最新ブランチ

開発用リポジトリはこのブランチから作成される

Featureブランチ

機能追加やバグ修正を行う作業用ブランチ

基本的にpushはこのブランチにのみ行われる

プルリクエストを通してDevelopブランチにマージされる


GitHub Enterprise

41


基本的に開発者は作業用ブランチで作業を行う

他者に影響がないので、リモートへのコミットが気軽に可能

作業ブランチで十分な確認をしてからDevelopブランチへ

マージすることで、開発リポジトリの品質を保持

フェーズごとにブランチを分けることで、

次期シーズン対応を並行して行うことが可能

プルリクエストを通すことによる、レビュー文化の定着

作業ブランチ以外への直接コミットはプロテクトで禁止

後述の仕組みによるレビュー漏れの抑止

レビューが前提なので、他開発チームの資材修正も気軽に可能


GitHub Enterprise

42

レビュー、チェッククリアの必須化

GHEにコミットをするだけで以下をJenkinsで自動実行

ビルド＆ユニットテスト

Lint系ツール、内製チェックツールによるチェック

プルリクエスト時に Status Check 機能でマージ条件を確認

ユニットテスト&ビルドが成功しているか？

チェックツールの指摘を解消しているか？

レビューは完了しているか？


GitHub Enterprise

43

GHE の Status Check機能

このボタンを押すとマージが実行される


GitHub Enterprise

44

レビューの有無を確認

ビルド、テストの成功を確認

チェックツールの通過を確認

GHE の Status Check機能

条件をクリアしていないとマージをブロック


GitHub Enterprise

45

レビュー、必須条件チェックの必須化

レビューはGHE上で実施

修正行ごとにコメントがつけられるため、レビューしやすい&見やすい


Jenkins

46

Jenkinsとは

オープンソースの継続的インテグレーション(CI)ツール

様々なイベントをトリガーにして、ビルド等の処理を

自動実行できる

豊富なプラグインで拡張が可能


Jenkins

47

GitHub Organization Folder Plugin を利用

リポジトリ内のJenkinsfileの存在を検知し、ジョブを自動で作成

GHEにPush時、自動でジョブが実行されるよう設定される


Jenkins

48

ビルド、テストの成功を確認

GHE の Status Check機能もこのプラグインによって実現


Jenkins

49

Pipeline(Jenkinsfile) を利用

ジョブ内容のコード化、GHEでの管理でバージョン管理が可能

ブランチによって処理を変更するなど、柔軟なジョブ内容を

設定することが可能

ブランチによってデプロイ先を変更するなどして活用


Jenkins

50

Amazon EC2 Container Service Plugin を利用し、

EC2,ECS を利用したDockerコンテナでビルド実行

スケーラブルなビルド環境を実現

閉じたコンテナ内でのビルドにより並列ビルドの影響排除

Dockerのポータビリティ性により、ローカル環境で再現可能

Jenkins Agent Jenkins Agent開発者ローカル


Docker

51

Dockerとは

軽量なコンテナ型の仮想環境ツール

起動が非常に速い

気軽に環境の起動、停止、破棄が可能

イメージの共有が容易

共通した開発環境を用意することが可能


Docker

52

GHE, Jenkins Master, Jenkins Agent を Dockerで構築

ビルド環境を更新した後の動作確認が容易に行える

環境のリストアが容易に行える

同一のイメージを利用することでローカルでビルドサーバの

環境を再現することが可能

Dockerfileを利用した環境構築のコード化

何が環境にインストールされているかを可視化

GHEで管理することで、バージョン管理が可能


まとめ

53

開発・リリースフローに適したGHE、Gitフローの導入で

開発効率・品質を向上

プルリクエストの活用によるレビュー文化の確立

Jenkinsジョブ、Dockerイメージのコード化で属人性排除

EC2の利用で、開発環境の運用負担を削減

ECSの利用で、スケーラブルなビルド環境を容易に実現


環境移行についての苦労話5

54



55

SVNに18万以上のコミット履歴が存在

全てを移行するのは非現実的な時間がかかる

git-svn では遅すぎるため、使用を断念

パッチを作れることを最低限として、リリースごとのコミット

のみ移行

Pythonで移行スクリプトを作成して自動化

SVNでの管理規約が定まっておらず、作業の自動化に苦労

移行後に失敗するテストが多発

テストの実行順序など、環境依存なテストケースがあったため

むしろここで気付くことができて良かったという説もあり



56

GHEとSVNの特性の違い

開発フローの練り直し

SVNで出来ていたことが確実に実現できるように移行を検討

ユースケースの洗い出しには特に力を入れた

開発フローに適したブランチ運用の検討

Jenkinsジョブ内で複数のリポジトリのチェックアウトが

必要な場合に困った

複数リポジトリをcloneするPythonスクリプトを作成し、

ジョブ内で利用して対応



57

新しい文化の導入

特にGitの導入による反発が大きかった

Gitの勉強会の実施

コマンドレベルの詳細な手順書の作成

KPT法による新しい環境についての振り返り実施


今後の展望6

58


今後の展望

59

脆弱性チェックをCI環境に組み込むことによって、

DevSecOpsを実現する

現状は開発者が脆弱性診断ツールを手動で実行している

ソースをコミットするだけで自動でチェックをかけたい

Jenkinsのビルド分析

現状、移行したばかりで分析・移行効果の測定ができていない

Elastic Search などを利用し、ジョブ結果を収集・分析を行い、

さらなる改善につなげていきたい


今後の展望

60

開発手順、規約の改善

開発本部内で、GHEやビルド環境についての振り返り実施結果

まだまだ改善の余地がたくさん

Keep Problem


61

Thank

You!

intra-martが推進する · ghe, jenkins master, jenkins agent はec2 上に構築...

Documents