Agileツール適合化分科会（dev opsツール）

1Copyright (C) Masanori Kataoka All Rights Reserved.
DevOps(Development & Operation:
開発と運用の統合）支援ツール群
２０１５年１０月２７日
片岡雅憲
2015/10/28
1
Agileツール適合化分科会（第７回）資料

１．DevOpsが必要とされる背景
２．Agileの拡張としてのDevOps（CIからCDへ）
３．システム運用管理技術の構成
４．DevOpsに必要とされる機能
５．システム構成管理ツール１（Chef）
６．システム構成管理ツール２（Docker）
７．ソフトウェア構成管理ツール(Gradle)
８．システム運用・管理総合支援ツール（OSS ツール）
９．システム運用・管理総合支援ツール（商用ツール）
１０．まとめ
＜参考文献＞
＜内容＞

DevOps(Development & Operation)とは、開発(Development)と運
用(Operations)の融合を目的とする技術や活動を言う。この用語は２
００９年にJ.Allspaw氏等による発表（参考文献３））で初めて使われた。
近年DevOpsへの関心が高まってきた背景として、次があげられる。
１）インターネット特にクラウド技術をベースとしてITサービスの提供速
度が加速化されてきている。アジャイル開発で開発速度を上げても、
これをサービス開始に結び付けるのに４～６週間と時間が係るので
は遅すぎる。運用も含めた加速化が必要である。
２）開発チームは新機能を求め、運用チームは安定を求める。表1.1に
示す文化ギャップを埋めて、両者が連携することが必須である。
３）そのためには、考え方を変革するとともに、自動化ツール群を整備
していく必要がある。具体的には、開発中心で展開されてきたアジャ
イルを運用までカバーするように拡張していく。すなわち、CI
(Continuous Integration)からCD(Continuous Delivery) へと拡張
することが必要である。CDは、クラウド活用を前提として展開される。

４）システムの短期開発、短期更新が求められている一方で、システム
自体は複雑化している。複雑なシステムを開発、更新を大きくまとめ
てリリースすると、多数の要因の相互作用があって、作業は極めて
複雑化して混乱が避けられない。複雑なものを着実にこなすために
は、小さな（内部）リリースを繰り返し、一歩一歩進めながら着実に
目的とする（外部）リリースを達成することが大切である。このような
小さなリリースを短期間で繰り返すためには、高度に自動化された
DevOpsおよびCDが必須となる。
また、小さなリリースを短期間に繰り返すことは、顧客の信頼を得ら
れやすく、顧客からの優れたフィードバックを得られやすい。

項番課題説明
１速度の不一致新しいチャンスや脅威に対応する迅速な開発、安
定したリスクの少ない運用
２異なる評価尺度とインセンティブ
は異なる行動と同じ
開発チーム：コスト、時間、スコープ（機能）
運用チーム：システムの安定性、可用性
３組織間の不透明な壁異なる組織であり、情報、資産を共有していない
４機能要件と機能以外の要件開発チーム：機能要件が主たる関心
運用チーム：非機能要件（セキュリティ、性能等）
５異なる環境、異なるアプローチ情報、資産を別々に所有し、別個に保守している
６資産の共有がほぼ皆無同上
７互いに依存しない協力関係本来ならば共有すべきものを共有し、各々のチー
ム固有な作業に専念すべきである。情報共有によ
り作業の加速化を図るべきである。
表6.1 開発チームと運用チームの間の文化ギャップ（参考文献2））

従来、「アジャイル」とは、「アジャイル開発」を意味した。そこでは、
短期間での開発サイクルを繰り返す中で、ユーザーと開発者が連携
して、両者の間にある壁を取り除く努力が行われてきた。そして、それ
を支援するために自動化ツールを連携させてCI(Continuous
Integration)を実現してきた。
DevOpsでは、これを拡張して更に開発者と運用者の間の壁を取り
除き、サービスのリリースを迅速化することを目指している。そこで必
要度されるツールはＤｅｖＯｐｓツールとして整備されつつある。具体的
には、環境設定、配置作業（デプロイメント）ツール、運用状況監視・評
価ツール、テストツールなどが着々と整備されつつある。
CI とDevOpsを統合することにより、CD(Continuous Delivery)が実
現される（図2.1参照）。CI では主として機能面での情報をユーザーに
フィードバックしたが、CDでは運用を含めた非機能面での情報もユー
ザーにフードバックする。

要求定義
（ユーザー）
開発
（開発者）
運用
（運用者）
CI(Continuous Integration)
CD(Continuous Delivery)
DevOps(Development & Operation)
図2.1 アジャイルの拡張（CI からCDへ）
（注）現状では、CDとDevOpsという用語は必ずしも明確に区分されていない。
CD=DevOpsと捉えられている場合もあるので注意が必要である。

３．システム運用・管理技術の構成
システム運用・管理技術は以下にあげるような多様な技術から構成
されている。
１）システム構成管理技術
情報化の進展と共に、企業が取り扱う情報機器の数は膨大なもの
になってきている。各々の情報機器を個別に取り扱うのではなく、企
業全体、あるいはデータセンター全体としての統合管理が必須になっ
てきている。また、それを手作業で行うのではなく、管理作業の自動
化のための構成管理システムの活用が必要になってきている。
２）ソフトウェア構成管理技術
ソフトウェアの大規模化、複雑化に対応するためには、ソフトウェア
構成管理の自動化が必須である。ソフトウェア構成管理は、ソフト
ウェア資産の管理を包含する。ソフトウェア構成管理ツールは、
JenkinsなどのCIツールと連携して、単体テスト、機能テストまでの作
業の自動化を達成してきた。今後は、CDを実現するべく、リリーステ
ストまでの自動化に取り組んでいく必要がある。

３）性能管理、キャパシティ管理、サービスレベル管理
性能管理、キャパシティ管理、サービスレベル管理の３つの言葉は
極めて強い相互関係にありながら、その目的とするところが異なる。
a) 「性能管理」では、管理対象とするソフトウェアがある特定の機能を
実現するためにどれだけのITリソースと時間を使うかを管理する。逆
にまた、目標以内にITリソースと時間の使用量を収めるべく、ソフト
ウェアを改善することも性能管理に含まれる。性能管理の対象はソフ
トウェア全体であったり、それを構成する機能やモジュールであったり、
状況によって様々である。
b) 「キャパシティ管理」では、目的とするサービスを提供するためにど
れだけのリソースが必要かを管理する。ある条件の元でのサービス
単位に管理され、「性能管理」を包含している。
c) 「サービスレベル管理」は、提供されたサービスの質を管理する。目
標とするサービス品質を達成するためのソフトウェア品質管理（性能
管理を含む）とITリソースのキャパシティ管理を包含する。

４）セキュリティ管理
インターネットの普及と共に、セキュリティの脅威は猛威をふるい、
セキュリティ管理の重要性が増している。セキュリティ管理がカバー
する範囲は広く、アクセス管理、暗号化技術、ファイアーウォール、
ウィルス対策、等々、多様な技術から構成される。
５）運用操作の自動化
運用すべきシステムの規模が膨れ上がり、またシステムの数も増
加し、その後関係も複雑になっていく中で、運用操作を手動で行って
いくのは限界があり、また誤操作の危険にさらされている。運用操作
自体をコード化して自動運転を推進しなければならない。
６）運用データの収集・分析・警告通知
運用データを自動収集・分析して、分析結果を分かり易いグラフ形
式で表示する。分析結果が指定された閾値を超えた場合にはしかる
べき警告を通知する必要がある。

DevOpsにおいては、アジャイル開発に必要とされた自動化ツール
（CI実現のためのツール）機能は全て必要とされる。これに加えて、更
に次のような機能が必要とされる。
１）システム環境設定・管理ツール。システム環境としては、開発環境、
テスト環境、ステージング環境、本番環境がある。これらの環境を
効率よく設定し、その相互関係も含めて管理する。
当ツールを用いて、開発チームと運用チームの間の壁を取り払い、
システム環境を共有していくことが大切である。
２）ソフトウェアの継続的デリバリーのための配置作業(deployment)
支援ツール。これにより、開発と運用のためのリソースの配置
（deployment)プロセス及び変更プロセスを継続的に管理する。
３）テスト駆動型システム環境設定・管理。システム環境が設定・変更さ
れた場合にその妥当性を自動的に検証するためのツール。

４）サービスあるいはソフトウェア起動、停止、変更自動化ツール。これ
らを複雑なスクリプトを書いたり、オペレータの手作業で行うのではな
く、簡単なスクリプトにより作業モジュールを自動起動する形で実施
可能とする。
５）サービスあるいはソフトウェアの運用状況を監視、報告するツール。
定期的なレポートを図表形式で関係者に自動配布する。また、インシ
デントあるいはその兆候を速やかに関係者に報告する。
６）サービスの運用状況に応じて、システム全体の構成を総合的に制
御するいわゆる「オーケストレーション」機能(Orchestrator)。例えば
負荷が高くなった部分により多くのリソースを割り当てる、トラブルの
起きているサービスへの入力量を絞る、等の全体的な制御を行う。
７）サービスあるいはソフトウェアの運用状況に関する詳細データの
収集・分析を支援するツール。

５．システム構成管理ツール１(Chef)
情報化の進展と共に、企業が取り扱う情報機器の数は膨大なもの
になってきている。各々の情報機器を個別に取り扱うことが、作業的
に困難であり、また、管理を徹底することも出来ない。企業全体、ある
いはデータセンター全体としての統合管理が必須になってきている。
また、それを手作業で行うのではなく、管理作業の自動化のための
構成管理システムの活用が必要になってきている。
以下、本章では現代のシステム構成管理ツールの代表であるChef
を取り上げてその概説をする。Chefは、代表的なシステム構成管理
ツールであるが、しばしば「環境設定ツール」と呼ばれることが多いの
で以下ではそのように呼ぶこととする。

5.1 環境設定ツールの歴史（Chefが登場するまで）
OSSベースの環境設定ツールの歴史は次の通りである。
１） CFEngine ：オスロ大学のMark Burgess等の研究に基づいて
1993年に開発された環境設定ツールであり、OSSとして提供されて
いる。環境設定ツールの基礎を築きあげたシステムであり、現在も広
く活用されている。
２） puppet ： CFEngineの経験をもとに、使い易さを改良した環境設定
ツールである。2005年から、OSSとして提供されている。Rubyベー
スの独自のDSLにより多様な環境（S/W, H/W）を設定する。Google,
Twitter, Oracle等の多くの組織で使われている。
３）Chef：CFEngine, puppetを参考として更に改良を加えて使い易くし
ている。OSS版と商用版の両方がある。puppetと同様にRubyで記
述されているが、puppetが外部DSLであるのに対して内部DSLにな
っていて改良がし易くなっている。2009年から提供されているが、
DevOpsの流れに乗って、急速にコミュニティーを拡大している。

5.2 環境設定のスクリプト化
１）ITシステムの開発・運用では、次のような環境が必要とされる。
①開発環境 ②統合テスト環境
③ステージング環境 ④運用環境
２）これらの環境は相互に関連し、後工程に行くほど複雑になる。
３）環境設定の作業は複雑であり、手作業で行う場合には多くの工数
と時間がかかると同時に、誤りが入り込む可能性が高い。
４）上記の各種環境のうち、①②は開発チームが設定し、③④は運用
チームが設定するのが一般的であり、両チームの間では知識が共有
されていないことが少なくない。
５）これらの課題を解決するためには、環境設定に関するすべての作
業をスクリプト化して、標準化、自動化、共有化を図る必要がある。
そのための代表的なツールであるChefでは、このことを
”Infrastructure as Code”（コードによる環境の実現）と呼んでいる。

5.3 Infrastructure as Codeによる効果
Infrastructure as Code （コードによる環境の実現）により次のような
効果を期待出来る。
１）サーバーの台数が増えても、すでに作成済みのコードを再利用する
ことにより、容易に対応できる。
２）「コード＝手順書」となるので、コードを正しく保守していれば手順上
の操作誤りを排除できる。
３）コードで記述されているので、既存コード、あるいは外部で作成され
たコードを再利用できる。また、作成したコードを他者に再利用して
もらうことも出来る。

5.4 Chefの特徴
Chefは、米国Chef社（旧名：Opscode社）が開発、販売していて、
OSS版と商用版がある。日本では、2010年からクリエーションライン社
が商用版の販売やChef導入支援事業を行っている。
Chefを使った運用管理の仕組みを図5.1に示す。
１）運用管理者は専用ソフトを使って作業手順書（「クックブック」と呼
ぶ）を作成し、それをChefサーバーに登録する。
２）管理対象サーバー（ノードと呼ばれる）にインストールした専用ソフト
はChefサーバーに定期的に（時間指定可能）アクセスしてクックブッ
クを参照する。クックブックの内容とサーバーの設定が異なっている
場合、クックブックに合うように管理対象サーバー上で必要なコマンド
を実行する。こうした仕組みにより、管理対象サーバーを1台ずつ管
理する必要がなくなる。
３）クックブックは作業手順書に当たる。実際の作業や設定内容はクッ
クブック内の「レシピ」と呼ぶファイルに記述する。

5.4 Chefの特徴（続き）
４）クックブックやレシピは一から作ることができるが、他者が作ったも
のをそのまま使うこともできる。Chef社のWebサイトには、ユーザー
が作成したものを含めて２０１５年８月現在、約２，４００のクックブック
が登録されている。すなわち、クックブックを情報資産として流通、
再利用が出来る。
５）レシピに記した作業手順はアプリケーションのソースコードのように
管理でき、バージョン管理システムのGitやSubversionなどで扱うこと
が可能である。ある設定を適用しているサーバーを検索することなど
が容易になり、従来よりも開発担当者が運用の実態を把握し易くなる。
６）Chefとpuppetは、開発の経緯からして共通点も多いが、Chefは次
の点で勝っていると言われる。
①内部DSL形式になっていて、Rubyで容易に拡張できる
②RESTful APIを用いて、他のWebサーバーと自由に連携できる
③Chefサーバー自体をAPIでコントロールできる

図5.1 Chefを使ったシステム運用管理の仕組み（参考文献１）より転写）
（管理対象サーバーは定期的にChefサーバーから該当する「クックブック」（サーバー管理手順を記し
たプログラム）を参照し、クックブックの記述内容とサーバーの状態が違えば必要な管理コマンドを自
動的に実行する。管理者はChefサーバーにある「クックブック」をメンテナンスするだけでサーバー群
を一元管理できる）
5.4 Chefの特徴（続き）

5.5 Cookbook, Recipe, Resource
Cookbookの中には、各ノードの「あるべき状態」を記述したRecipeが
書かれている。Recipeは、Ruby言語をベースとしたDSL(Domain
Specific Language)で記述されている。このDSLは必要に応じて、
Rubyで変更・拡張が出来る。
Recipeは、複数のResourceの記述から構成されている。Resource
についての詳細な説明は、Chef の公式サイトにある文献９）に記述さ
れている。以下では、そのうちの主なものについて紹介する。
１）userとgroup
userは、文字通りそのノードのユーザーを定義し、groupはuserが
所属するグループを定義する。
２）package
そのノードで用いられるソフトウェアパッケージを定義する。
３）service
そのノードで用いられるサービスを定義する。

5.5 Cookbook, Recipe, Resource（続き）
４）template
設定ファイル等の外部ファイルを定義する。設定ファイルは、
Attribute を含み、これにより動的に決定される変数値を設定する。
５）git
git ファイルにRecipe情報等のデータを格納しておいて、ここから
データを取って来て利用する場合に定義する。基本的にRecipe情
報は、git 等の変更歴管理システムで管理することが望ましい。
６）cron
定期起動するバッチジョブを起動するためのcron リソースを記述
する。

5.6 Cookbookの信頼性を確保する
Chef は、図5.1 に示した仕掛けにより、多数のサーバーのシステム
構成を効率よく管理することが出来る。しかし、それと裏腹のリスクを
抱えている。もしも、Chef サーバーに誤った情報をセットすると、それ
は配下の全ノードに伝わってしまい、システム全体が影響を受けて大
変なことになる。したがって、Chef サーバーへの情報設定は慎重の上
にも慎重に行わなくてはならない。
Chef サーバーのCookbookの情報の妥当性を検証するツールとし
て、Foodcritic がある。Foodcritic は、表5.1 に示すルールに基づいて
Cookbookの妥当性を検証する。
Chef は、各ノードの属性情報を収集するためのOhai というツールを
同梱している。Ohai を用いて各ノードの情報を得て各リソースの情報
を設定している。また、ohai コマンドを用いれば各ノードの状態を知る
ことが出来る。

5.6 Cookbookの信頼性を確保する（続き）
No. ルールの内容
FC001 [廃止]ノードの属性にアクセスする際はシンボルでなく文字列を使う
FC002 不必要な文字列展開を避ける
FC003 Chef Server 固有の機能を使う前にChef Server で稼働しているかを調べる
FC004 サービスの開始と終了には、serviceリソースを使う
FC005 リソース宣言の反復を避ける
FC006 ファイルの権限のモードは、クオートするか完全に記述する
FC007 Recipeの依存関係をCookbookのメタデータで明確にする
FC008 生成されたCookbookのメタデータを更新する
FC009 リソースの属性が未定義である
FC010 検索の分布が不正である
FC011 README がMarkdownではない
FC012 READMEにはRdocではなくMarkdownを使う
表5.1-1 Foodcritic で定義されているルール（１）

FC013 一時ファイルのパスをハードコードせずにfile_cache_path を使う
FC014 長い ruby_block をライブラリにすることを検討する
FC015 Definition をLWRP にすることを検討する
FC016 LWRP がdefault アクションを宣言していない
FC017 LWRP が更新時に notify していない
FC018 LWRP が廃止された通知を使っている
FC019 ノードの属性に正しいマナーでアクセスする
FC020 [廃止]条件実行文字列がRubyのコードのように見える
FC021 Privider 中の条件が期待した動作をしていないかもしれない
FC022 ループ中の条件が期待した動作をしていないかもしれない
FC023 if ではなく条件付きアクションを使う
FC024 同等のプラットフォームの追加を検討する
表5.1-2 Foodcritic で定義されているルール（２）

FC025 コンパイル時に gem をインストールするには、chef_gem を使う
FC026 条件実行属性は文字列のみを含む
FC027 リソースが内部属性をセットしている
FC028 #platform? の使用方法が正しくない
FC029 Recipe のメタデータがCookbook名で始まっていない
FC030 Cookbook がデバッガーのブレークポイントを含んでいる
FC031 Cookbook にメタデータファイルがない
FC032 通知のタイミングが正しくない
FC033 Template が存在しない
FC034 未使用のTemplate 変数がある
FC035 [廃止]Template がノードの属性を直接使っている
FC037 不正な通知アクションがある
表5.1-3 Foodcritic で定義されているルール（３）

FC038 不正なリソースアクションがある
FC039 Node メソッドはキーではアクセスできない
FC040 git コマンドを実行するにはリソースを使う
FC041 curl やwget を実行するにはリソースを使う
FC042 require_recipe ではなく、include_recipe を使う
FC043 新しい通知の文法を使う
FC044 裸の属性キーを使わない
FC045 Cookbookの名前をメタデータで設定することを検討する
表5.1-4 Foodcritic で定義されているルール（４）

5.7 knifeコマンド
図5.1において、chef クライアント側からchef サーバーの持つ情報を
編集する手段としてknife コマンドがある。以下はknifeコマンドのサブ
コマンドである。
項番サブコマンド機能
１ bootstrap ノードの初期セットアップを行う
２ client クライアントの管理を行う
３ configure knife の初期設定を行う
４ cookbook cookbook の管理を行う
５ cookbook site cookbook 共有サイトと連携する
６ data bag Data Bag（共有データ）の管理を行う
７ delete Chef Server で管理されているオブジェクトを削除する
８ diff Chef Server で管理されているオブジェクトの差分を表示
９ download Chef Server からオブジェクトをダウンロードする
表5.2-1 knifeコマンドのサブコマンド一覧（１）

5.7 knifeコマンド（続き）
１０ environment Environment の管理を行う
１１ exec ノードでChef Server APIのやり取りをするスクリプトを実行する
１２ index rebuild Chef Server 上のインデックスを再生成する
１３ list Chef Server で管理されているオブジェクト一覧を表示する
１４ node ノードの管理を行う
１５ raw Chef Server API へREST リクエストを送る
１６ recipe list レシピを表示する
１７ role ロールの管理を行う
１８ search Chef Server に登録されているノード情報を検索する
１９ show Chef Server で管理されているオブジェクトを参照する
２０ ssh 複数のノードでコマンドを同時実行する
表5.2-2 knifeコマンドのサブコマンド一覧（２）

5.7 knifeコマンド（続き）
２１ status Chef Server に登録されているノードの状態を表示する
２２ tag タグの管理を行う
２３ upload Chef Server へオブジェクトをアップロードする
２４ user ユーザの管理を行う
表5.2-3 knifeコマンドのサブコマンド一覧（３）
（注）上表において、「ノード」とは、Chef Server による管理の対象とされている
サーバーを言う。また、「ロール」は、ノードをその役割分担で分類した「役割」
を示す。例えば、「Webサーバー」「DBサーバー」等の分担を示す。

6.1 コンテナ型配置作業支援ツール Docker
情報システムの運用を開始するための配置作業(Deployment)は、
複雑で誤りの入りやすい作業である。配置作業に当たっては、次のよ
うな依存関係を考慮しなくてはならない。
① 配置するソフトウェアは、多くのソフトウェア部品やライブラリに
依存しているのでこれを正しく設定する必要がある
② 他のサービスに依存している場合もある
③ OSの特定バージョンに依存している
④ 利用可能なメモリの最少量や特定のポートへのバインド等のリソ
ース上の制約がある
これらの依存関係と共に、さらに次の条件の達成が必要である。
⑤ 同一サーバーに共存する他のソフトウェアとの分離
⑥ このソフトウェアがセキュリティ上の問題を起こしても他のソフトウ
ェアに影響を与えないこと
⑦ アップグレード、ダウングレード、バックアップの容易性
６．システム構成管理ツール２(Docker)

6.1 コンテナ型配置作業支援ツールDocker（続き）
⑧ 再現性、例えば、テスト実行時とまったく同じ環境を運用時に
実現できること
⑨ リソースの制約が可能なこと。例えば、このソフトウェアが暴走し
ても他のソフトウェアに迷惑をかけないこと。
⑩ インストール、アンインストールが簡単であること
このように複雑な配置作業上の問題を着実に解決する仕掛けとして
VM(Virtual Machine：仮想マシン)がある。
VMは、配置作業上の課題を解決する有力な手段ではあるが、一般
的に有料であること、ＶＭ実現のためのオーバヘッドがかかること（実
行を遅くすること）、実行時の変更が出来ないこと（VMを止めなければ
ならないこと）という問題がある。
Dockerは、コンテナ型仮想化により、VMの持つこれらの問題点を解
決する手段として注目を集めている。

6.2 コンテナ型仮想化
VMは、図6.1に示すようにハイパーバイザー配下に実現される。すな
わち、ハードウェアやOSを含めてすべてが仮想化される。一方、コンテ
ナ型仮想化では、コンテナ管理ソフトウェアのもとに、複数のコンテナ
が動作して、このコンテナが仮想化を実現する。コンテナには、ミドルウ
ェア（および依存ライブラリ）とアプリケーションが含まれる。すなわち、
OS配下のすべてのソフトウェアがパッケージングされる。
コンテナ型仮想化では、仮想化の範囲が少ない（OSを仮想化の対象
としない）のでオーバーヘッドが少なくなる。したがって、配置作業が高
速で容易に出来る特徴を持っている。DockerはDocker社が提供する
コンテナ管理ソフトウェアであり、下記の機能を実現している。
① コンピューターリソースの隔離および制限
② 他のホスト、他のコンテナーとのネットワークの構成
③ ファイル／ディレクトリの世代と差分の管理
“Build, Ship and Run any app, anywhere”が標語である（図6.2)。

6.2 コンテナ型仮想化（続き）
図6.1 ハイパーバイザー型仮想化とコンテナ型仮想化

6.2 コンテナ型仮想化（続き）
図6.2 Docker社のホームページ
６．システム構成管理ツール(Docker)

6.3 Dockerを構成する技術
Dockerは、新しい技術を用いて実現されている訳ではない。Unix系
のOS(FreeBSD, Solaris等）で長い歴史を掛けて開発されてきて、
Linuxへと引き継がれてきた次の技術を用いて実現されている。
① Linux Namespaces：コンピューターリソースの隔離（ファイル
システム空間の区画化等）
② Linux cgroups：コンピューターリソースの制限
③ AUFS／Device Mapper Thin Provisioning：ファイル／ディレク
トリの差分管理（共通部分と変更差分を分離・統合化して管理）
④ Linux iptables：他のホスト、コンテナーとのネットワークを構成
コンテナ技術自身は、これまでにもGoogleのコンテナ技術、RedHat
のGear等で活用されてきた。Dockerはこれらの技術をうまくパッケー
ジング、標準化してベンダー非依存にしたことにおいて優れている。そ
して、Google, RedHat, Amazon を味方に引き入れて、彼らの支援を
取り付けたことも、成功の主要因と捉えられている。

6.4 Dockerによるメリット
Dockerはインフラ管理者、開発者に次のようなメリットをもたらす。
① アプリケーションを少ないリソースで効率良く実行できる
（VMで実行するよりも高速）
② Immutable Infrastructure（不変のインフラ構成）の実装。アプリ
の実行環境を使い捨てとし、環境を都度作り直すことにより構成
変更を行うことができ、アプリの実行環境をより管理し易くする。
③ Infrastructure as Codeの実践。Dockerはコンテナーの構成を
全て「Dockerfile」というテキストファイルに記述できる。
④ 既存の開発環境がDocker社の共通リポジトリDockerHubに登
録されており、これを再利用できる。また、開発環境と本番環境と
共通化出来る。Dockerでは、コンテナーの元となるDockerイメー
ジを異なるホスト間で共有出来る。
⑤ アプリ実行環境を高速にデプロイできる。Dockerは一般プロセス
で動き、VMでいうOSのブート処理が不要である。

6.5 Dockerを支える周辺技術
Dockerが普及するにつれて、Dockerをより使い易くするためのツー
ルが多数開発されている。主要なものとして次の３分野がある。
① コンテナ向け軽量OS
② Dockerコンテナ管理ツール
③ Docker機能強化ツール
１）コンテナ向け軽量OS
Docker コンテナは、Linux OS配下で稼働する。ここでは、Linuxは
VMシステムにおけるハイパーバイザーの役割を担う。したがって、
コンテナを動かすだけの機能があれば充分であって、その他のLinux
の機能は出来るだけ削ぎ落として、リソースの使用量を最小限にした
い。このようなDocker専用OSとして、CoreOS(CoreOS社）、
CentOS Atomic Hat(Red Hat社）,Snappy UbuntuCore(Canonical
UK社）がある。Snappy Ubuntu Coreは、IOT(Internet of Things)向
けの最軽量OSであり、Docker向けには専用アダプタが必要である。

6.5 Dockerを支える周辺技術（続き）
２） Dockerコンテナ管理ツール
Docker自身はCLI で実現されているので、これをGUI で使えるよう
にするツールである。代表的なものとして、Paramax(Paramax社)、
ShipYard(Shipyard社）がある。Paramaxは、「人間のためのUI」を
標榜していて、その「テンプレート」機能を用いれば、連携が必要な
システムのための複数コンテナを１クリックで立ち上げられる。
３） Docker機能強化ツール
Docker自身は一台のホストマシンしか扱うことは出来ない。現代の
クラウドの時代においては複数のホストを対象としたクラスタリング
機能がどうしても必要となる。このようなDockerの機能の限界を拡張
するツールとして、Kubernetes(Google社）、GearD(Red Hat社）が
ある。Kubernetesは、大きな注目を集めているプロジェクトであり、
Google主導して、Docker, IBM, Microsoft, Red Hat, CoreOS社他
共同開発に参加している。

6.5 Dockerを支える周辺技術（続き）
３） Docker機能強化ツール（続き）
Kubernetesでは、コンテナのクラスタリングにおいて次のような
概念を用いている。
① Pod:複数のコンテナの集まりをPodとして扱うことが出来る。
Pod内のコンテナは、一つのホスト上に限定される。
② Label:Ｐｏｄに対して任意の名前を付けられる。
③ Minion:複数のPodの集まりをMinionとして扱うことが出来る。
Minionは複数のホストにまたがってまとめることが出来る。
④ Replica: Podは、Replica機能を使って複製できる。
⑤ Service: PodやMinionをどのネットワークと接続するかを
Service機能を用いて設定できる。
上述したKubernetesの機能により、Dockerコンテナを大規模な
システムで活用することが出来る。

6.6 Dockerのサポート状況
２０１４年１２月現在でのＤｏｃｋｅｒのサポート状況は次の通りである。
（参考文献16））
米Amazon Web Services（AWS）や米Google、米Microsoftなどの
クラウドサービスは既にDockerをサポートしているほか、Dockerベー
スの新しいサービスも相次いで登場している。Googleは2014年11月
に「Google Container Engine」を、AWSは同じく2014年11月に「
Amazon EC2 Container Service」を発表した。Microsoftは、次期版
Windows ServerにDockerを搭載し、その技術をMicrosoft Azureにも
展開することを明らかにしている。直近では12月4日に米IBMが、米
Dockerと提携してDockerベースのサービス「IBM Containers」を提供
することを発表した。

6.7 DockerとChefとの関係
DockerとChefは、今やクラウド時代の寵児ということが出来る。この
両者がこれからどのような関係になっていくのかに興味が沸く。
伝統的には、これまでの環境と独立した新しい環境を立ち上げるに
は、VMを利用するのが標準的な方法であった。クラウド文化の普及と
共にVMの活用も普及した。そして、それと共に環境設定ツールChef
が広く普及しつつある。
コンテナ型仮想化技術は、VMよりも軽量な形での新環境の設定を可
能とした。そしてコンテナを実現する技術として、Dockerが普及しつつ
ある。Dockerは、当然のこととしてコンテナ上の環境を設定する機能を
保有している。すなわち、ChefもDockerも、対象がVMかコンテナかの
違いがあるものの、環境設定の機能を持っている。
両者の関係が今後どのようになっていくかは流動的である。Chefは、
Docker対応の環境設定機能を整備しつつある。Dockerは、Chefをそ
の中で使えるようにしている。両者の今後の行方に注目したい。

ソフトウェア構成管理の考え方と自動化ツールについては、本分科
会の第２回のテュートリアル「構成管理・ビルドツール」で解説した。そ
の要旨は下記の通りである。本章では今後、更なる普及が期待される
Gradleについて、詳細に解説する。
１）ソフトウェアの大規模化、複雑化に対応するためには、ソフトウェア
構成管理の自動化が必須である。
２）ソフトウェア構成管理は、ソフトウェア資産の管理を包含する。
３）ソフトウェア構成管理ツールの代表的なものとして次がある。
―Maven2/3：伝統を引き継ぐ構成管理ツール。記述言語はXML。
―Buildr：機能記述法としてMavenを引き継ぐ。記述言語はRuby。
―Gradle：２０１２年リリースの最新ツール。記述言語はGroovy。
４）ソフトウェア構成管理ツールは、JenkinsなどのCI(Continuous
Integration)ツールと連携して、単体テスト、機能テストまでの作業の
自動化を達成してきた。今後は、CD(Continuous Delivery)を実現す
るべく、リリーステストまでの自動化に取り組んでいく必要がある。
７．ソフトウェア構成管理ツール

7.1 Gradleの概要
Gradleは、スクリプト言語Groovyを用いてビルドスクリプトを記述す
るビルドツールである。Gradleには、次のような特徴を持っている。
①JavaVM上で動作する
②Mavenと同様にPOM(Project Object Model)に基づき、プロジェク
トのライフサイクル全体をカバーしている
③ビルドスクリプトをGroovyのDSL(Domain Specific Language)で
簡潔に記述することができる。また、DSLで記述が困難な部分は、
Groovyを用いて、カスタマイズが出来る。Groovy自身は、Javaの
知識があれば簡単に習得できる。(Groovy≒Java + Ruby)
④多様な関連ツールと連携するためのプラグインが用意されている
⑤Mavenのリポジトリを利用することができる。また、Antの資産を
そのまま活用することが出来る。
上述したように、GradleはMavenを超える機能を持ちながら、それを
カスタマイズする場合にはMavenよりも柔軟に対応出来る。

7.2 ビルドツールの歴史とGradle
ビルドツールの歴史を以下に説明する。図7.1は、この歴史を、動作
の基本原理の進歩と共に説明したものである。
１） make: ビルドツールの元祖。UNIXのコマンドとしてビルド機能を実
現。したがって、ＯＳに依存する。複雑なソフトウェアに対しては、複
数回のコマンドを実行する必要がある。
２） Ant: Javaと共に登場し進歩してきた。コマンドの代わりに、XMLで
構造を記述する。したがって、クロスプラットフォームで利用が可能
である。
３） Maven: ビルド機能に限定せずにPOM(Project Object Model)
の考え方に基づき、ビルド、テスト、ドキュメンテーション、デプロイ
等を含めたプロジェクトのライフサイクル全体を管理する。ソフトウェ
ア構成管理ツールとしての革新的機能を持つ。ＸＭＬ記述であり、
動的な変更は出来ない。また、複雑なシステム構造、関係を記述す
るための規約があるが、これを自由に変更することは出来ない。

7.2 ビルドツールの歴史とGradle（続き）
４）Gradle: Mavenの機能を引き継ぎながら、Mavenの使いにくさ、拡
張しにくさを大幅に改善した。スクリプト言語Groovyをベースとして
おり、動的な変更を可能としている。Groovyは、Javaを拡張したシ
ンタックスに基づく言語であり、修得が容易である。また、DSL
(Domain Specific Language)としての機能を持ち、これにより
Gradleのための機能を実現している。そして、これらの機能は、
Groovyを用いて変更・拡張が可能である。
Gradleでは、Ant, Mavenで開発され、活用されてきた資産をその
まま引き継いで、Gradleで利用可能にしている。また、Ant, Maven
の資産をGradleの資産へと変換するツールもある。

以上、構成管理ツールの歴史を見てきたが、この歴史を大局的に見
ると図7.1のように纏められる。
図7.1 の縦軸は、ビルド定義の方法をスクリプトかXMLかで分類して
いる。また、縦軸はビルドのパラダイム（規範）を手続き的に既述する
か、それとも規約（コンベンション）で定めるかで分類している。
Makeはスクリプトにより手続き的に既述した。このスクリプトはUnixコ
マンドに限定され汎用性がなかった。Ant ではスクリプトとしてXMLを
使うことにより汎用性を増し、より広く利用されるようになった。
しかしながら、スクリプトで記述することは汎用的であっても、極めて
煩雑で記述量が多い。そこで、Mavenでは暗黙ルールとしてのコンベ
ンションを導入することにより、記述を高度にして結果として記述量を
減らした。しかし、Mavenのコンベンションルールは分かりにくく、これを
変更するにはXMLでの記述が煩雑であった。GradleではJavaと親和
性の高いGroovyでコンベンションルールの記述・変更を可能にした。

手続き的規約による
ビルド
スクリプト Make
Gradle
XML Ant Maven
ビルド
定義
パラダイム
図7.1 ビルドツールの進化におけるGradleの位置付け（参考文献６））

7.3 Gradleのタスク
Gradleの作業単位はタスクと呼ばれており、標準的なタスクとして
表7.1に示すものが用意されている。
表7.1 Gradleの標準タスク（１）
タスク名称説明
assemble コンパイルを実行しJAR、WAR、ZIP、TARファイルなどを作る
build assemble後にテストを実行する
buildDependents そのプロジェクト“が”依存するプロジェクトを含めbuildを実行する
classes メインクラスをassembleする
clean 成果物(buildディレクトリ配下)を削除する
compileJava プロダクトのコンパイルを行う
compileTestJava テストコードをコンパイルする
jar メインクラスを含むJarファイルを作成する
processResources プロダクトのリソースをクラスディレクトリにコピーする
processTestResources テストリソースをテストクラスディレクトリにコピーする

7.3 Gradleのタスク（続き）
表7.1 Gradleの標準タスク（２）
タスク名称説明
testClasses テストクラスをassembleする
uploadArchives 成果物をアップロードする
check testを含む検証タスクを実行する
test ユニットテストを実行する
javadoc Javadocを生成する
dependencies プロジェクトが利用するライブラリを表示する
help ヘルプメッセージを表示する
projects サブプロジェクトを表示する
properties プロジェクトのプロパティを表示する
tasks 実行可能なタスクを表示する

7.4 依存関係の管理
現代のソフトウェア開発ではすべてのソフトウェアを新規に開発する
ことはなく、既存のパッケージやOSSを活用する。ビルドツールでは、
このように外部で作られたソフトウェアとの関係を「依存関係」として管
理して、ビルド時に取り込む機能を持っている。
Mavenでは、このような依存関係をXMLで記述する。Gradleでは、こ
のような依存関係をGroovyのスクリプトとして記述する。
表7.1に示した主なGradleタスクの相互依存関係を図7.2に示す。こ
のような依存関係に基づき、gradle build を実行すると、必要なタスク
が次々に実行され、ビルドが完了する。

7.4 依存関係の管理（続き）
図7.2 Gradleタスクの相互依存関係（参考文献7））

7.5 Gradleによるテスト作業の自動化
Gradleでは、スクリプト言語Groovyにより、タスクの中のプロセス、そ
してタスクとタスクの依存関係を記述する。したがって、狭義のビルド作
業に限定せずに、広範囲の自動化作業を記述できる。
テスト関係の作業を取り上げれば次のような作業と作業間の関係を
記述することが出来て、広範囲のテスト作業の自動化に寄与すること
が出来る。
１）テストコードのコンパイル
２）テスト環境の設定
３）テスト対象、テスト項目の選択
４）依存関係の設定
５）並列実行数の記述
６）テスト結果の判定、報告

８．システム運用・管理総合支援ツール（OSSツール）
DevOpsは、①システム構成管理（第５、６章）、②ソフトウェア構成管
理（第７章）の二つの支柱を軸に組み立てられている。これらの支柱を
軸にさらに、③性能・キャパシティ・サービスレベル管理、④セキュリ
ティ管理、⑤運用操作の自動化、⑥運用データの収集・分析・警告通
知の機能を組み合わせてDevOpsとしての総合的な機能を提供する。
現実に提供されているDevOpsツールはこれらの機能の組み合わせ
で実現されている。以下では、これらのDevOpsツールのうちでOSSと
して提供されているものを紹介する。
１）Nagios: Nagiosは、指定されたノードのリソース（CPU負荷、ハード
ディスク使用量、システムログ等）の監視、および指定されたサービ
スの稼働状態を監視し、問題が発生したり解決したりした時にユーザ
ーに通知するツールである。GNUベースのOSSとして１９９９年から
提供されている。当分野の老舗的存在でユーザ数が多い。上記の
⑥運用データの収集・分析・警告通知の機能を提供する。

2) Munin（ムニン）: Muninは、サーバーのトラフィックや各種データを
分かり易いグラフで表示するツールである。OSSとして、Linux系の
OSに２００４年から提供されている。また、有料版も提供されている。
Muninの特徴はインストールと操作が容易で手軽に使えることと、
表示するグラフがきめ細かく、かつ分かり易い点にある。Muninには
障害、異常の通知機能はない。したがって、前述のNagios等と組み
合わせて利用するのが効果的であると言われている。
Muninは、前述の⑥運用データの収集・分析の機能を提供する。
３）Zabbix: Zabbixは、Zabbix SIA社によって開発されている運用監視
ツールであり、2001年からOSSとして公開されている。WebのGUIで
監視項目の設定と、監視状況を確認できる。また、RDBMSに監視結
果を保存し時系列でリソース利用量をグラフで表示出来る。
すなわち、Zabbixは、上記⑥運用データの収集・分析・警告通知
機能を提供するものである。

４）Hinemos: Hinemosは、NTTデータが開発する統合運用管理ツー
ルである。運用管理で必要となるサーバの死活監視、性能監視と時
系列のリソース利用状況の表示などが行える。また、ジョブ管理機能
を持っていて、複雑な処理を複数のジョブの組み合わせで定義したり
定時実行される処理をジョブとして作成出来る。
有償のVM管理オプションを利用することにより、仮想環境やプライ
ベートクラウドの管理も行える。サポートするVMハイパーバイザは
幅広く、VMware、Xen、Oracle VM、Hyper-V、KVMが利用出来る。
すなわち、Hinemosは、前記の①システム構成管理（第５章）、
③性能・キャパシティ・サービスレベル管理、⑤運用操作の自動化、
⑥運用データの収集・分析・警告通知の諸機能を総合的に組み合
わせていると言える。

５）Hyperic HQ：Hyperic HQは、Hyperic社により開発されていた運用
管理ツールである。Hyperic社はSpring Frameworkの開発元として
知られるSpringSource社に買収され、その後SpringSource社が
VMware社に買収され、現在はVMware社により開発されている。
サービスやサーバを指定し、サービス、サーバで必要な監視項目を
1度にまとめて設定できるなど、“1つ上のレベルの監視”を提供して
いる。すなわち、前記⑥運用データの収集・分析・警告通知機能を
提供している。現状では、日本語はサポートされていない。
６）Scalr：Scalrは、米Scalr社が提供するクラウド管理ツールである。
特徴としては、パブリッククラウド、プライベートクラウドなど、複数の
クラウドを統合管理するGUIインターフェイスをWebで提供しており、
Scalrで定義されたイメージを用いることにより、Webサーバのスケー
ルアウトやDBサーバのフェイルオーバを簡単に行える。
Scalrは、複数の種類のクラウドを統括して管理し、前記①システム
構成管理機能を提供している。Scalrは内部でChefを用いている。

７）Aeolus: Aeolus（アイオロス）は、レッドハットが開発するクラウド管
理ソフトウェアである。前述のScalrなど従来のクラウド管理ソフトウェ
アでは、クラウドごとに仮想マシンのイメージを用意する必要がある。
利用したいOSの種類が増え、管理したいクラウドの数が増えると、
管理するイメージの数が多くなり、手間が掛かる。
Aeolusは1つの仮想マシン定義から複数のクラウド用のイメージを
作成することで、各クラウド・仮想化基盤用のイメージ作成の手間を
省いてくれる。
Aeolusでは、「システムテンプレート」と呼ばれる最小限のOS情報
を定義した仮想マシンイメージの定義と、インストールするアプリケー
ション毎の定義（「アプリケーションブループリント」と呼ばれる）から
仮想マシンのインスタンスを作成する。
Aeolusは、前記①システム構成管理機能を主として提供している。

８）OpenDelivery: Stelligent社が開発したCDプラットフォームのため
のOSSである。OpenDelivery は、オープンソース・ツールとスクリプ
トを 1 つのクラウド・インフラストラクチャー(AWS)と組み合わせたも
のであり、「ソフトウェア・システム全体がコードである」という考えを実
践している。スクリプトはすべて、GitHub バージョン管理リポジトリー
でバージョン管理される。
OpenDelivery は表8.1 に示す各種のツールを使用してプラット
フォームを作成しており、Linux 上での Rails、Grails、Java による開
発をサポートしている。OpenDeliveryは、前記①システム構成管理、
②ソフトウェア構成管理、③性能・キャパシティ・サービスレベル管理、
④セキュリティ管理、⑤運用操作の自動化、⑥運用データの収集・
分析・警告通知のすべての機能を提供している。

No ツール名称説明
1 AWS CloudFormation AWS リソース構成を呼び出すためのテンプレート言語
2 Amazon EC2 OpenDelivery は、すべての計算リソースに EC2 を使用する
3 Amazon CloudWatch 性能メトリックの監視と、しきい値を超えたときの通知
4 Amazon Route 53 エンドポイントに対するドメインを設定するためのDNS
5 Amazon SimpleDB IP アドレスや CloudFormation の構成情報を格納
6 Amazon SNS SNS (Simple Notification Service)を使ってメッセージを送信
7 Amazon S3 プラットフォームが利用するファイルの格納に S3を使用
8 Capistrano デプロイメントに特化した Ruby ベースの DSL
9 GitHub OpenDelivery のソース・コードを集中管理する
10 Jenkins ビルドとデプロイ、構成関連の変更を実行するための基盤
11 Puppet 環境作成のためのコードはすべて Puppet で作成される
12 Ruby 自動化スクリプトの大部分は Ruby で作成される
表8.1 OpenDeliveryを構成するツール群

９）ｆluentd（フルエントディー）: 現代の情報システムは多様なシステム
やサービスの組み合わせで構成されている。したがって、そこでは、
多様なログデータを多様な形式で取り扱うことになる。それらに個別
に対応することは極めて大きな負荷になる。
fluentdは、このような課題を解決すべく登場したツールであり、ログ
の収集方法やログの記録先などを柔軟にカスタマイズできる。
図8.1 に示すように、fluentd ではすべての入力ログは、その入力
に対応したプラグインで処理される。そして、すべてはJSON形式に
変換され、もとの入力の性質を表すメタデータは、これに付加された
タグ情報で表される。そして、出力もまた、出力形式に応じたプラグ
インで処理される。すなわち、fluentd では、
入力プラグイン → 標準形式(JSON)データ → 出力プラグイン
というプロセスで、ログデータ処理の標準化、統合化を図っている。
fluentd は、 ⑥運用データの収集・分析の機能を提供する。

９）fluentd（続き）
図8.1 fluendのアーキテクチャ（参考文献 14))
（ファイルやアプリケーションなどのイベントソー
スから受け取ったイベントが集約され、条件
に応じてさまざまな出力先に出力される）
JSON形式

前章では、システム運用・管理総合支援ツール（OSSツール）を紹介
したが、以下では同様なツールの商用版を紹介する。７．システム運
１） UrbanCode：UrbanCode社はソフトウェアのデリバリー自動化業
務を行い、企業がモバイル、ソーシャルやクラウドのアプリケーション
の発売、リリースを迅速に行うためのツールUrbanCodeを開発、販
売してきた。2013年4月にIBM社は同社を買収し、UrbanCodeを
DevOps戦略の中核ツールと位置付けてビジネスを展開している。
このツールは、UrbanCode DeployとUrbanCode Releaseの二つ
から構成されていて、①システム構成管理、②ソフトウェア構成管理
機能を提供する。Urban Code Deployは、開発環境、テスト環境、
本番環境へのデプロイを自動化し迅速化する。UrbanCode Release
は、リリースの計画、実行を可視化して管理するためのツールである。
UrbanCodeは、DevOpsのための諸作業をパターン化し(Jenkinsと
の連携も可能）、このパターンを図表形式で操作するGUIを提供して
おり、プログラミングの知識なしに利用可能としている。

２）SmarterCloud Orchestrator
IBM社が2013年5月に発売開始したもので、クラウドベースのサー
ビス提供のため機能を提供している。すなわち、①システム構成管
理、③性能・キャパシティ・サービスレベル管理機能を提供している。
a)仮想システムパターン（開発環境パターン、テスト環境パターン、
本番環境パターン等）を利用してシステム環境を構築する。そのた
めのクラウドはOpenStackベースであることを前提としている。
b)環境構築に当たっての、起案から承認のプロセスをワークフロー
化することが出来る。そして、このワークフローをGUIベースの分か
り易い図形式で定義・編集できる。
c)適切なキャパシティー・サイズ、ワークロードのバランスを分析する
機能、モニタリング機能を提供して、ヘルス・ダッシュボードを通した
可視化を可能とする。
d)SmarterCloud Orchestratorがクラウド環境を、UrbanCodeがアプ
リケーション環境を用意して、連携してDevOps & CDを実現する。

３）JazzHub→DevOps Services
IBM社が中心になって進めているクラウド上の開発環境サービスで
ある。Eclipseツールをはじめとした開発ツール群がクラウド上で
グローバルに利用できる。GitHubとの連携も出来る。すなわち、自分
で開発環境を整えることなしに、すべてをクラウド上のサービスで利
用できるということである。概念的には、GitHubを拡張していることに
なる。
IBM社のクラウド関連サービスは次の３つのサービスで構成されて
いる。
a) SoftLayer:クラウド基盤であるPaaSを提供する
b) Cloud Foundry:特定のインフラや言語に依存しないオープン
なPaaSを提供する
c) DevOps Services：クラウド上の開発環境サービス
IBM社は、上記のa)とb)(とc)）を合わせて、Bluemixと呼んでいる。

４）ZOHO社のOpManager, ManageEngine
米国ZOHO社は、Webベースのビジネスアプリケーションサービス
をグローバル展開している。また、クラウドベースのシステムの運用
ツールを開発、販売している。
OpManagerは、システム運用監視・管理のツールであり、物理環
境、仮想環境を総合的に管理する。仮想環境については仮想化ソフ
トウェアベンダーを超えて総合的な管理が行える。したがって、ハイブ
リッドな構成からなる現実的なシステムの管理に適している。使い易
さも売り物であり、トレーニング無しで使えると宣伝している。
OpManagerが基盤レベルの管理をするのに対しManageEngine
は、アプリケーション層の管理をする。多様なWebアプリケーションが
動作する環境でこれらを総合的に管理する。
ZOHO社としてはベンダー非依存のOpManager, ManageEngine
を組み合わせて使うことを推奨している。これらのツールは①システ
ム構成管理、②ソフトウェア構成管理機能を総合的に提供している。

１０．まとめ
DevOpsの概念は、ソフトウェア開発と情報システム運用・保守の大
部分をカバーする極めて広範なものである。したがって、DevOpsを実
現するためのツール群もこれに対応した広い範囲をカバーしなくては
ならない。このような広範囲のツール群は、本稿でみてきたように次の
３本の柱に支えられて実現されている。
１）Hub機能
これら広範囲のツールをまとめ上げ連動させるための仕掛けとして
のHub 機能である。Hub 機能に必要とされるのは、システムを作成・
更新していくための各種の情報を入力・変更していくための「変更歴管
理・バージョン管理ツール」であり、また、これらの情報の入力・変更を
契機に関連するツールを自動起動する「CI/CDツール」である。
このようなHub機能の存在によって、各々の自動化ツールはそれぞ
れの独立性を保ちながらも、他のツールとの連携が可能になる。
現代の最先端の「変更歴管理・バージョン管理ツール」としては、
GitHubが、そして「CI/CDツール」としてはJenkins があげられる。

１０．まとめ
２）システム構成管理ツール
現代の情報システムは単一の計算機・基本ソフトではなくて、多数の
多様な計算機・基本ソフトの複合システムとして実現されている。この
ような複雑なシステムの構成を手作業で管理することは、工数的にも
信頼性上からも限界にきている。 Infrastructure as Code （コードによ
る環境の実現）のための「システム構成管理ツール」が必須である。
現代を代表する「システム構成管理ツール」として、Chef （実計算機、
仮想計算機ベース）と、Docker(仮想コンテナベース）が上げられる。
３）ソフトウェア構成管理ツール
近年では大部分のソフトウェアは、すべての機能を自分で実現する
のではなく、外部のパッケージやサービスの助けを借りながら実現して
いる。そしてそのうえで細かなバージョン管理と連動している。このため
高度なソフトウェア構成管理が必要とされる。
現代を代表するソフトウェア構成管理ツールとしては、Gradleが上げ
られる。

＜参考文献＞
１）[運用を自動化する「Chef」]Rubyベースの手順書で管理
http://itpro.nikkeibp.co.jp/article/Active/20130307/461541/
２）「開発と運用の断絶を考えるーDevOpsへの促進を考える重要
課題に着目」 HPビジネスホワイトペーパー２０１４年
３）“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”
John Allspaw & Paul Hammond 2009
http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-
and-ops-cooperation-at-flickr?related=1
４）開発と運用の新しい関係、「DevOps」とは何か？
http://www.publickey1.jp/blog/11/devops.html
５）「DevOps時代の開発者のためのOSSクラウド運用管理ツール
5選まとめ」村岡光２０１３年
http://www.atmarkit.co.jp/ait/articles/1302/27/news013.html
６）「Gradle徹底入門：次世代ビルドツールによる自動化基盤の構築」
綿引琢磨、須江信洋、林政利、今井勝信２０１４年翔泳社

＜参考文献＞
7) “Gradle User Guide” Hans Dockter, Adam Murdoch 2007-2012
Hayashi Masatoshi,Sekiya Kazuchika, Sue Nobuhiro、
Mochida Shinya（訳）
http://gradle.monochromeroad.com/docs/userguide/
userguide.html
8) 「ビルドツールGradleスタートアップガイドの紹介」鈴木雅貴
２０１３年
http://www.ntts.co.jp/publish/column/tec/java_03/index.html
9) “Chef Documents: About Resources”
https://docs.chef.io/resource.html
10) “Chef Supermarket: Cookbooks”
https://supermarket.chef.io/cookbooks
11) 「Chef 実践入門：コードによるインフラ構成の自動化」吉羽龍太
郎、安藤祐介、伊藤直也、菅井祐太郎、並河裕貴２０１４年
技術評論社

＜参考文献＞
12) Nagios Official Site: https://www.Nagios.org
13) Munin Official Site: http://www.munin-monitoring.org
14) Fluentd Officil Site: http://www.fluentd.org
15) 「Dockerコンテナ実践検証」佐藤司、富永善視、森元敏雄（著）
２０１５年インプレス社
16) 「はやりの「Docker」は、くすぶっているDevOpsを再燃させるか」
森重和春２０１５日経LINUX
http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/120600130/?mle

Agileツール適合化分科会（dev opsツール）

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (6)

Semelhante a Agileツール適合化分科会（dev opsツール）

Semelhante a Agileツール適合化分科会（dev opsツール） (20)

Mais de masanori kataoka

Mais de masanori kataoka (7)

Agileツール適合化分科会（dev opsツール）