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

1Copyright (C) Masanori Kataoka All Rights Reserved.

DevOps(Development & Operation:開発と運用の統合）支援ツール群

２０１５年１０月２７日

片岡雅憲

2015/10/281

Agileツール適合化分科会（第７回）資料


１．DevOpsが必要とされる背景２．Agileの拡張としてのDevOps（CIからCDへ）３．システム運用管理技術の構成４．DevOpsに必要とされる機能５．システム構成管理ツール１（Chef）６．システム構成管理ツール２（Docker）７．ソフトウェア構成管理ツール(Gradle)

８．システム運用・管理総合支援ツール（OSS ツール）９．システム運用・管理総合支援ツール（商用ツール）１０．まとめ＜参考文献＞

＜内容＞


１．DevOpsが必要とされる背景

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

(Continuous Integration)からCD(Continuous Delivery) へと拡張することが必要である。CDは、クラウド活用を前提として展開される。

http://www.itmedia.co.jp/enterprise/articles/0607/03/news013.html#l_th_fig0001.gif




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

http://image.itmedia.co.jp/l/im/enterprise/articles/0607/03/l_th_fig0001.gif






項番課題説明

１速度の不一致新しいチャンスや脅威に対応する迅速な開発、安定したリスクの少ない運用

２異なる評価尺度とインセンティブは異なる行動と同じ

開発チーム：コスト、時間、スコープ（機能）運用チーム：システムの安定性、可用性

３組織間の不透明な壁異なる組織であり、情報、資産を共有していない

４機能要件と機能以外の要件開発チーム：機能要件が主たる関心運用チーム：非機能要件（セキュリティ、性能等）

５異なる環境、異なるアプローチ情報、資産を別々に所有し、別個に保守している

６資産の共有がほぼ皆無同上

７互いに依存しない協力関係本来ならば共有すべきものを共有し、各々のチーム固有な作業に専念すべきである。情報共有により作業の加速化を図るべきである。

表6.1 開発チームと運用チームの間の文化ギャップ（参考文献2））






２．Agileの拡張としてのDevOps（CIからCDへ）

従来、「アジャイル」とは、「アジャイル開発」を意味した。そこでは、短期間での開発サイクルを繰り返す中で、ユーザーと開発者が連携して、両者の間にある壁を取り除く努力が行われてきた。そして、それを支援するために自動化ツールを連携させてCI(Continuous

Integration)を実現してきた。

DevOpsでは、これを拡張して更に開発者と運用者の間の壁を取り除き、サービスのリリースを迅速化することを目指している。そこで必要度されるツールはＤｅｖＯｐｓツールとして整備されつつある。具体的には、環境設定、配置作業（デプロイメント）ツール、運用状況監視・評価ツール、テストツールなどが着々と整備されつつある。

CI とDevOpsを統合することにより、CD(Continuous Delivery)が実現される（図2.1参照）。CI では主として機能面での情報をユーザーにフィードバックしたが、CDでは運用を含めた非機能面での情報もユーザーにフードバックする。






２．Agileの拡張としてのDevOps（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に必要とされる機能

DevOpsにおいては、アジャイル開発に必要とされた自動化ツール（CI実現のためのツール）機能は全て必要とされる。これに加えて、更に次のような機能が必要とされる。

１）システム環境設定・管理ツール。システム環境としては、開発環境、テスト環境、ステージング環境、本番環境がある。これらの環境を効率よく設定し、その相互関係も含めて管理する。当ツールを用いて、開発チームと運用チームの間の壁を取り払い、システム環境を共有していくことが大切である。２）ソフトウェアの継続的デリバリーのための配置作業(deployment)

支援ツール。これにより、開発と運用のためのリソースの配置（deployment)プロセス及び変更プロセスを継続的に管理する。３）テスト駆動型システム環境設定・管理。システム環境が設定・変更された場合にその妥当性を自動的に検証するためのツール。






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

４．DevOpsに必要とされる機能








５．システム構成管理ツール１(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の特徴（続き）


http://itpro.nikkeibp.co.jp/article/Active/20130307/461541/?SS=imgviewactive&FD=54139247

http://itpro.nikkeibp.co.jp/article/Active/20130307/461541/?SS=imgviewactive&FD=54139247


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.2 ビルドツールの歴史とGradle（続き）以上、構成管理ツールの歴史を見てきたが、この歴史を大局的に見ると図7.1のように纏められる。図7.1 の縦軸は、ビルド定義の方法をスクリプトかXMLかで分類している。また、縦軸はビルドのパラダイム（規範）を手続き的に既述するか、それとも規約（コンベンション）で定めるかで分類している。

Makeはスクリプトにより手続き的に既述した。このスクリプトはUnixコマンドに限定され汎用性がなかった。Ant ではスクリプトとしてXMLを使うことにより汎用性を増し、より広く利用されるようになった。しかしながら、スクリプトで記述することは汎用的であっても、極めて煩雑で記述量が多い。そこで、Mavenでは暗黙ルールとしてのコンベンションを導入することにより、記述を高度にして結果として記述量を減らした。しかし、Mavenのコンベンションルールは分かりにくく、これを変更するにはXMLでの記述が煩雑であった。GradleではJavaと親和性の高いGroovyでコンベンションルールの記述・変更を可能にした。



7.2 ビルドツールの歴史とGradle（続き）


手続き的規約によるビルド

スクリプト MakeGradle

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徹底入門：次世代ビルドツールによる自動化基盤の構築」綿引琢磨、須江信洋、林政利、今井勝信２０１４年翔泳社

http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr?related=1

http://www.publickey1.jp/blog/11/devops.html

http://www.atmarkit.co.jp/ait/articles/1302/27/news013.html


＜参考文献＞

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 実践入門：コードによるインフラ構成の自動化」吉羽龍太郎、安藤祐介、伊藤直也、菅井祐太郎、並河裕貴２０１４年技術評論社

http://gradle.monochromeroad.com/docs/userguide/userguide.html

http://gradle.monochromeroad.com/docs/userguide/userguide.html

http://www.ntts.co.jp/publish/column/tec/java_03/index.html

https://docs.chef.io/resource.html

https://supermarket.chef.io/cookbooks


＜参考文献＞

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

https://www.nagios.org/

http://www.munin-monitoring.org/

http://www.fluentd.org/

http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/120600130/?mle

Software

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