Embed Size (px)
Citation preview
アプリケーションリリース自動化とインフラ自動化 両者の価値提案を理解する文責：Julian Fish、製品管理担当ディレクター、Serena Software (現Micro Focus傘下 )
ホワイトペーパー
目次 ページ
概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
自動化する理由 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
自動化の歴史の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
進歩が常に困難であるとは限らない . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
インフラ自動化とは . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
アプリケーションリリース自動化とは . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
共通の特性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
インフラ自動化のための Deployment Automation と Puppet . . . . . . . . . . . . . .6
インフラ自動化のための Deployment Automation と Puppet . . . . . . . . . . . . . .8
パイプラインの価値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
モデル主導型のデプロイメント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
拡張性の小さな問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
両方の世界の長所を活用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1www.microfocus.com
概要
DevOps の変革に着手する組織や、単に環境の自動化とセットアップ、構成を目指している
組織は、インフラ自動化ツールとは別物としてのアプリケーションリリース自動化の価値を
見分けられないことが往々にしてあります。数多くのツールが提供されていますが、果た
す役割が重複しているものも多くあるように見受けられます。このホワイトペーパーでは、
市場をリードする 2 つの製品：アプリケーションリリース自動化のための Micro Focus
Deployment Automation1 と、インフラ自動化のための Puppet2 についてご紹介します。そ
れぞれの価値提案、各ツールの主な重点分野、および統合された DevOps ツールチェーン
の一部としてそれぞれが提供する利点についても説明します。
自動化する理由
多くの組織が、安定した運用の維持、SLA の遵守、適したアプリケーション応答性の確約
と同時に、アプリケーションデプロイメントの簡素化と複雑さの軽減を目指しています。
ビジネスの対応性を高め、「物事を破壊せずに迅速に行動する」ことは企業の生き残りに不
可欠です。そういった競争上の目標をサポートするために、「アプリケーションスタック全
体」を自動化する必要性が重要性を増しています。しかしながら、「スタック全体」の定義
はそれを説明する組織のエリアによって異なる傾向があります。
運用の組織では「スタック全体」をアプリケーションとサポートシステムのホストに必要
なインフラとして捉え、アプリケーションをスタックの小さな構成要素と見なすことが多
い一方で、開発の組織では「スタック全体」を相互に連携して正常に動作するアプリケー
ションのすべての層として捉え、基盤となるインフラにはあまり関心を示さない傾向があ
ります。現実では、特に DevOps の観点からは、急速に組織の重要な資産となったものが
確実にサポートされるようにするために、すべてのエリアが完全に連携して動作する必要
があります。過去 10 年間で、IT の機能はもはや重要なビジネス差別化要因ではなくなり、
単にビジネスシステムの稼働を維持することに付加価値は見出されなくなっています。必
須要件と見なされるようになったのです。ビジネスにとって、アプリケーションが大立者
であり、企業の差別化とビジネスの価値をもたらすのはアプリケーション変更です。可能
な限り多くのビジネスの変化を、可能な限り短期間で実装し、同時に高レベルの品質と安
定性、機能を維持することが不可欠となっています。手動プロセスのアプリケーションデ
プロイメントでは、これらの重要な要件をサポートできません。自動化は選択肢ではなく、
必須となっているのです。
自動化の歴史の概要
過去 15 年間にわたり、ソフトウェア業界では変化の速度が加速しており、Forrester 社の
Glenn O’Donnell 氏はこれが「IT の産業化」3 につながっているとコメントしています。当
初は 2000 年問題とインターネットバブル崩壊以降の IT 支出削減によって主導され、後に
このホワイトペーパーでは、市場をリードする 2つの 製品：アプリケーションリリース自動化のための Micro Focus Deployment Automationと、インフラ 自動化のための Puppetについてご紹介します。それぞれの価値提案、各ツールの主な重点分野、および 統合された DevOpsツールチェーンの一部としてそれぞれが提供する利点についても説明します。
__________
1 Deployment Automation (SDA)は、インフラプロビジョニ ン グ ツ ー ル と の 統 合 および起動の両方が可能な、市場をリードするアプリケーション自動化ツールです。www.serena.com/sda
2 Puppetは、一定の投資とコーディングにより、アプリケーションリリース自動化に使用可能な、市場をリードするインフ ラ 自 動 化 ツ ー ル で す。https://puppetlabs.com/
3 O’Donnell, Glenn. 2010, IT Is Industrializing̶What Does That Mean To Me? (ITの産業化̶自分にどう関係があるのか ), Glenn O’Donnell氏のブログ。2015年 2月 24日に訪問。http://blogs.forrester.com/glenn_odonnell/10-04-21-it_industrializing_%E2%80%93_what_does_mean_me
2
ホワイトペーパーアプリケーションリリース自動化とインフラ自動化
インターネットの大規模な採用とビジネスの「常時稼働」アプローチによって拡大された
これらの変化は、企業とエンタープライズ IT の両方の世界に極めて大きな影響を与えてい
ます。15 年前は会社 Web サイトの必要さえなかった企業が、1 日 24 時間「常時稼働」の
顧客アクセスの概念はもちろんのこと、まったく新たな仕事のしかたに適応しなければな
らなくなりました。IT 支出削減によって組織は、人員削減によって人数がより少なくなっ
ているにもかかわらず、企業 IT に対する要求の高まりによってより多くの仕事をこなさな
ければならなくなっています。「あらゆる場所でのインターネット」を採用するには、これ
まで要求されたことがないレベルの運用効率、システムアップタイム、および対応能力が
必要となります。多くのエンタープライズアプリケーションに付いて回る複雑さのレベルを
踏まえると、ビジネスの変化の効率的で反復可能なデリバリーはもはや単純な作業ではあ
りません。ビジネスクリティカルなバックオフィスシステムの弱点またはバックドアアク
セスを探しているかもしれない第三者にアプリケーションを晒すリスクを考えると、デリ
バリー速度を高めるだけでは不十分であり、アプリケーションは次なる注目機能を装備し、
高い品質とセキュリティのレベルを維持しながら、迅速にデプロイされなければなりま
せん。手動プロセスに依存していては、もはや信頼性、トレーサビリティ、再現性を確約
することができなくなっています。手動によるアプリケーションデリバリーを継続するこ
とで、組織は競争から大きく遅れをとるリスクを負うことになるのです。
進歩が常に困難であるとは限らない
開発チームは従来、たとえば COBOL や C などの「レガシー」プログラミング言語から
Java や .Net などのより新しい言語への移行など、変化を受け入れてきました。開発チーム
は変化に対応するために、初期のメリットよりも移行コストのほうが大きい場合でさえも、
アプリケーションとプロセスの両方を変更してきました。ウォーターフォール型のプロジェ
クト管理統制からアジャイル統制への移行、LEAN プラクティスの採用とオープンソースソ
フトウェア採用の普及などはすべて、開発チームの変化に対応する意欲を示す典型的な例
です。より効率的になり、ビジネス機能をより効果的かつ迅速に提供するこれら開発組織
の能力によって、運用チームがより効果的かつ迅速にそれら新しい機能を提供することに
対する圧力が高まっています。
運用チームはこれまで本番環境または本番環境の管理に対し、一般的にビジネスに要求さ
れるとおりに、「ゼロリスク」のアプローチをとってきました。ビジネスはシステムの安定
性とアップタイムを必要としており、このアプローチは完全に理解できます。取引システ
ムを正常に動作させ続けること、発注システムを正しく機能させ続けること、または消費
者に正確な情報を提供する銀行システムを維持することの責任は、簡単に負えるものでは
ありません。多くの組織が運用システムに対する ITIL ベースのプラクティス、プロセスお
よびプロシージャへの投資とこれらの採用について慎重な姿勢を見せています。一般的な
プラクティスとプロシージャに従ってもらうためには全員の合意を確約することが不可欠
です。
可能な限り最高の顧客体験、魅力的な新機能を提供するため、または競争上の優位性を獲
得するための企業の取り組みにおいて、より多くのアプリケーション変更を可能な限り迅
15年前は会社Webサイトの必要さえなかった企業が、 1日 24時間「常時稼働」の顧客アクセスの概念はもちろんのこと、まったく新たな仕事のしかたに適応しなければならなくなりました。
可能な限り最高の顧客体験、魅力的な新機能を提供するため、または競争上の優位性を獲得するための 企業の取り組みにおいて、 より多くのアプリケーション変更を可能な限り迅速に、かつ効率的に提供することの必要性が急速に明確になっています。
3www.microfocus.com
速に、かつ効率的に提供することの必要性が急速に明確になっています。問題は、これら 2
つの矛盾するかのような要件をどのように実現するのか、そして、すべての規制、業界ま
たは企業のコンプライアンス要件を維持しながら、開発より要求されるアプリケーション
デリバリーの高速化と、運用に要求される安定性およびトレーサビリティ、コントロール、
厳密さのレベルを実現できるのか、ということです。
_______________________________________________________________
技術的な進歩によって、現在アプリケーションとすべての支援インフラのデリバリーを自
動化することがずっと容易になっています。2 つの異なる組織単位 ( 開発と運用 ) において
一般的な、人、プロセス、および通信の課題に対処することを目指す DevOps の動きは、自
動化の利用から確実に恩恵を受けることができます。異なる環境の再コンパイルコードが
異なるビルドの出力とその後の環境における数多くの問題につながることに組織が気付い
たのと同じように、異なる環境にわたるデプロイメントの一貫性欠落も大きな問題と課題
につながることに組織は気付き始めています。アプリケーションデプロイメント、アプリ
ケーションインストールおよびシステム構成の自動化は、異なる環境にわたって一貫性が
達成されるよう確約でき、かつ正確にどのアーティファクトのどのバージョンがどの環境
においてどの時点でデプロイされたかを確認するための完全な監査を実施し、追跡するこ
とができます。また、自動化は通常、デプロイメントの実施に費やされる時間の短縮、
デリバリー品質に対する自信向上 ( マシンは間違えたりコマンド実行を忘れたりしない )、
計画されたことが実際に発生したかを正確に証明し、重要な監査のコンプライアンス結果
が達成されるよう確約する能力ももたらします。
一般的にアプリケーションのデプロイメントは、単にファイルをある場所から別の場所に
移動させるようなシンプルなものではありません。新しい機能、追加されたストレージ容量、
またはアプリケーションの新機能実装をサポートするためのインフラ構築または拡張に関
わることがあり、複雑なインストールルーチンが必要となる場合があります。インフラ自
動化とアプリケーション自動化は微妙に異なった機能であり、さらなる定義が必要です。
アプリケーションデプロイメント、アプリケーションインストールおよびシステム構成の自動化は、異なる環境にわたって一貫性が達成されるよう確約でき、かつ正確にどのアーティファクトのどのバージョンがどの環境においてどの時点でデプロイされたかを確認するための完全な監査を実 施し、追跡することができ ます。
図 1
開発と運用の課題
_______________________________________________________________
4
ホワイトペーパーアプリケーションリリース自動化とインフラ自動化
アプリケーションリリース自動化には、アプリケーションをどのようにインストール、デプロイするか、および異なるアプリケーション層をどのようにランタイムで相互作用させるかの構成が含まれます。
インフラ自動化とは
インフラ自動化とは、OSのインストールから、物理または仮想、あるいはクラウドインスタン
スへのサーバーインストールと構成、さらにインスタンスとソフトウェア間の相互通信方
法の構成までの環境の構築と管理です。また、通称としてプロビジョニング、スクリプト
化されたインフラ、コードとしてのインフラ、または構成管理 ( この呼び名は対象としてい
るライフサイクルの部分によって多くの異なる意味を持つため混乱を生じやすい ) とも呼ば
れます。原理はシンプルです。システム構成を 1 つまたは複数のスクリプトにより定義する
ことで、少ないエラーと短い所要時間を確約しながら、できる限りシンプルかつ迅速に環
境を構築または複製することを可能にします。
アプリケーションリリース自動化とは
アプリケーションリリース自動化とは、環境内におけるアプリケーションのスクリプト化
された管理で、インストール、アプリケーション構成および物理または仮想、あるいはク
ラウド環境へのアプリケーションデプロイメントが含まれます。これら標的となる環境は
実際、インフラ自動化の使用を通じて構築されます。アプリケーションリリース自動化には、
アプリケーションをどのようにインストール、デプロイするか、および異なるアプリケー
ション層をどのようにランタイムで相互作用させるかの構成が含まれます。また、一般的
図 2
インフラ自動化
_______________________________________________________________
5www.microfocus.com
にアプリケーション自動化 (AA)、デプロイメント自動化、アジャイルデプロイメント、
またはリリース管理とも呼ばれます。「スクリプト」という用語は一般に、UI 定義機能を含
む、または含まない、パッケージ、宣言型、カスタムおよびプロセス中心型のツールを指
すために使用されます。原理はシンプルです。モデルを 1 つまたは複数のスクリプトにより
定義することで、少ないエラーと短い所要時間を確約しながら、できる限りシンプルかつ
迅速にアプリケーションを構築またはデプロイすることを可能にします。
_______________________________________________________________
共通の特性
アプリケーション自動化とインフラ自動化の両者は、より広範な DevOps ( 開発チームと運
用チームを連携させたプロセスとプラクティス ) の世界、および継続的デリバリー 4 または
継続的デプロイメント 5 の世界において相互補完的であると見なすことができます。これら
2 つのツールタイプ間には、応答性の向上、エラーの減少、監査および説明責任、トレーサ
ビリティの改善、および「すべてを記述する」意図という共通する目的があるため、これら
2 つのツールセットが往々にして直接的な競合または潜在的に一方で他方を置き換えるもの
と見なされることにつながっています。実際は、これら 2 つのツールセットには明確に定義
アプリケーションリリース自動化は、一般的にアプリケーション自動化 (AA)、 デプロイメント自動化、 アジャイルデプロイメント、またはリリース管理とも呼ばれます。
アプリケーション自動化とインフラ自動化の両者は、より広範な DevOpsの世界、および継続的デリバリーまたは継続的デプロイメントの世界において相互補完的であると見なすことができます。
__________
4 継続的デリバリー (CD)は常に本番環境にデプロイできる状態にアプリケーションを維持することです。Martin Fowler, 2015年 2月 24日訪問、http://martinfowler.com/delivery.html
5 継続的デプロイメントは毎 日またはより頻繁に各変更を本番環境に実際にデプロイすることです。Martin Fowler, 2015年 2月 24日訪問、http://martinfowler.com/delivery.html
図 3
アプリケーションリリース自動化
_______________________________________________________________
6
ホワイトペーパーアプリケーションリリース自動化とインフラ自動化
された目的と「スイートスポット」があります。確かに、一方を使用して他方の一部機能を
実行することはできますが、ジョブに最適なツールを選択することがより理想的です。
_______________________________________________________________
インフラ自動化のための Deployment AutomationとPuppet
Deployment Automation はスクリプティングまたはサードパーティ製ツールへの既存の
プラグインを介したインフラ自動化タスクのサブセット実行に使用することができます。
一部の状況ではこれがインフラ自動化の方法に必要とされているすべてであるかもしれま
せん。そのようなアクティビティの例には、追加の仮想またはクラウド容量を提供するた
めに既存の事前定義された構成済みイメージを使用する、仮想またはクラウドベースの
プロビジョニングが含まれることがあります。事前定義された構成済みのイメージに基づ
いてインフラを構築する手法は一般に「ゴールドイメージ」プロビジョニングと呼ばれ、
新しいインフラが構築された後追加の構成はほとんど必要ありません。このインフラプロ
ビジョニングモデルは、組織が容量または機能を追加するために既存のアプリケーション
インフラを水平または垂直に拡張することを希望する場合に適しています。この場合、仮
想インフラプロビジョニングはVMware ESX、ESXiまたはワークステーションプラグインを
使用して、新しい仮想イメージをプロビジョニングし、実行されます。インスタンス生成後、
新しいイメージによりエージェントプロパティ設定が更新され、新しいエージェントが
Deployment Automation サーバー上の正しいエージェントプールグループに自動登録され
ます。クラウドインフラプロビジョニングは、Amazon、Azure または vCloud プラグインを
使用して、新しいクラウドイメージをプロビジョニングし、実行されます。インスタンス
生成後、新しいイメージによりエージェントプロパティ設定が更新され、新しいエージェン
トが Deployment Automation サーバー上の正しいエージェントプールグループに自動登録
されます。
アプリケーションリリース自動化 インフラ自動化 プロセス中心型デプロイメント ● ●
アプリケーションのデプロイメント ● ●
アプリケーションのインストール ● ●
パイプラインサポート ● ●
環境管理 ● ●
インフラプロビジョニング ● ●
インフラ変更 ● ●
ベアメタルプロビジョニング ● ●
フルスタック自動化(ツールチェーンベース) ● ●
図 4
アプリケーションリリース自動化とインフラ自動化
_______________________________________________________________
7www.microfocus.com
Puppetなどのインフラプロビジョニングツールの使用にはスペシャリストのスキルセットが必要とされます。開発コミュニティには数々の事前定義済みマニフェストやモジュールが存在しますが、そのようなマニフェストを構築、変更、更新するために必要なスキルは、通常運用のバックグラウンドを持つ人物が保有するものです。
組織は Puppetなどプロビジョニングツール用のプラグイン使用を通じ、完全な監査機能とトレーサビリティを備えた使いやすい、グラフィカルに定義されたプロセスを使用して、インフラ、自動化ツール向けのプロセス機能、新たに構築された環境へのシームレスなアプリケーションデプロイメント能力を形成するためのベストオブブリードのツールが提供する利点を手に入れることができます。
「ベアメタル」または物理マシンレベルでのインフラ自動化にはずっと細部にわたる機能が
必要とされ、アプリケーション自動化ツールとして、これは Deployment Automation の目
的ではありません。そういった状況では、インフラプロビジョニングのプロセスがデプロ
イメント自動化ツールによって管理される、Puppet などのサードパーティ製ツールの使用
が推奨されます。Puppet などのインフラプロビジョニングツールの使用にはスペシャリス
トのスキルセットが必要とされます。開発コミュニティには数々の事前定義済みマニフェ
ストやモジュールが存在しますが、そのようなマニフェストを構築、変更、更新するため
に必要なスキルは、通常運用のバックグラウンドを持つ人物が保有するものです。アプリ
ケーションをデプロイするために適した基盤インフラの提供には、インスタンス生成時に
どのカーネル、メモリ、システム、構成のパラメータを設定するか、どのようにセキュリティ
およびネットワーキングパラメータとともに OS を正しくデプロイするかを知っている
こと、およびずっと大規模なデータセンターのコンテキストにおいて新しいインフラの
インスタンスを生成するとき、接続されたデータストレージセットのディスク I/O 要件を
理解していることが不可欠となります。
通常、レシピ、料理本、およびその他の定義スクリプトは、インフラデプロイメントのセッ
トアップと構成に必要ないくらかのスクリプティング知識とともに、ドメイン固有言語で
記述されます。この事前定義された、またはカスタム構築された「スタック」へのアプリケー
ションデプロイメントは、インフラプロビジョニングの論理的な拡張です。素晴らしい、
新たなハードウェアのデプロイメントには理由があるのです。新しい物理インフラ構築の
ために正確なマニフェストとモジュールをコールし、インフラプロビジョニングのための
デプロイメントプロセスを定義できること、新しい仮想インフラをデプロイできること、
アプリケーションをデプロイできること、そして新たに構築されたスタック全体ですべて
のアプリケーションが正確に構成されるよう確約できることが最終目標です。組織は
Puppet などプロビジョニングツール用のプラグイン使用を通じ、完全な監査機能とトレー
サビリティを備えた使いやすい、グラフィカルに定義されたプロセスを使用して、インフラ、
自動化ツール向けのプロセス機能、新たに構築された環境へのシームレスなアプリケー
ションデプロイメント能力を形成するためのベストオブブリードのツールが提供する利
点を手に入れることができます。
_______________________________________________________________
8
ホワイトペーパーアプリケーションリリース自動化とインフラ自動化
インフラ自動化のための Deployment AutomationとPuppet
インフラ自動化のディスカッションで言及したように、自動化の同化した部分によって
DevOps の原則の組織内における実装に必要な機能が提供されます。しかし、やはりインフ
ラ自動化で論じたように、アプリケーション自動化で対処したい重要な特定の部分が存在
します。アプリケーションのデプロイメントがバッチまたはシェルスクリプトを実行して
ファイルを正しい場所に複製するという単純な操作であるなら、インフラ自動化ツールが
必要な機能 (トレーサビリティとは言わないまでも )を提供できるかもしれません。エンター
プライズソフトウェアの世界において、そのような単純なアプリケーションデプロイメン
トは残念ながら非常に稀です。通常、異なるアプリケーションコンポーネントエリア間の
依存関係を含み、異なる環境で使用される異なる OS を有し、スクリプトを補足するために
手動のステップを必要とすることがあるような、複数層のアプリケーションデプロイメン
トに対しては、単純なファイルの複製とスクリプト実行のアプローチでは不十分です。ア
プリケーションの複数のコンポーネント、または複数のアプリケーションをも連続でまた
は並行してデプロイする必要がある場合、インフラ自動化ツールの機能ではサポートしき
れなくなり、最終的に非常に複雑に連鎖したスクリプトを使用しなければならなくなって、
管理と理解の両方が困難になります。Tomcat など一般的に使用されているアプリケー
通常、異なるアプリケーションコンポーネントエリア間の依存関係を含み、異なる環境で使用される異なる OSを有し、スクリプトを補足するために手動のステップを必要とすることがあるような、複数層のアプリケーションデプロイメントに対しては、単純なファイルの複製とスクリプト実行のアプローチでは不十分です。
図 5
フルスタックプロビジョニング
_______________________________________________________________
9www.microfocus.com
ションサーバーにシンプルなアプリケーションデプロイメントを実行するときでさえも、詳
細で複雑なスクリプトが必要となります。たとえば、Puppet で Tomcat に単純な war ファイ
ル 1 つをデプロイする場合、800 行を超えるコードが必要です。これらスクリプトを最新に
維持する、または組織の要件に合わせてスクリプトを変更するには、高待遇で非常に高スキ
ルの人材によるフルタイムの作業を要することになり得ます。対照的に、Deployment
Automation を使用した場合、Tomcat アプリケーションサーバーへの war ファイルの単純な
デプロイメントは 1 つのプロセスステップであり、エンドユーザーにグラフィカルに表示さ
れます。環境間のあらゆるカスタマイズまたは構成変更はパラメータとしてこのステップに
渡され、開発環境から本番環境まで全体にわたってプロセスの完全な再現性が確約されます。
パイプラインの価値
あらゆる種類の自動化における基本原則の 1 つは、最終状態が分かっており、かつ再現可能
な方法で到達できることです。環境間にわたる一貫性がデプロイメント中のエラーを回避
する鍵となります。リリースマネージャや品質エンジニア運用エンジニアにとって、選択
した環境でのアプリケーションデプロイメントに苦労し、「こっちの環境ではできたよ」と
言うだけのエンジニア仲間から冷笑を買うことは珍しくありません。一貫した目標または
目標とする最終状態がないと、自動化は些細な作業となり、いかなる有望な価値も提供で
きません。当然、あらゆる DevOps または継続的デリバリーの取り組みにとって目標とす
る最終状態は、任意のタイミングで、監査に準拠したシンプルかつ再現可能な、自動化さ
れた方法により、アプリケーションを本番環境に配信することです。しかし、事前の計画
によって正常な適時の完了を確約するのと同じように、アプリケーションを本番環境に配
信するために必要な検証のメカニズム、ステージ、レベルを知ることが不可欠です。開発
環境で生成されたコードが、異なる構成、ランタイムパラメータ、インフラセットアップ、
データセットを有する本番環境でシームレスに動作することをただ期待することは、特に
デプロイメント中にアプリケーションの複雑さとアプリケーション間の依存関係に直面す
る場面が増える中、現実味がなくなっています。多くの企業顧客にとって、アプリケーション
間の依存関係を定義し、1 つのアプリケーションの変更が別のアプリケーションに与える影
響を知ることだけでも、非常に複雑で時間のかかる作業となります。適した時間に正確な
環境へのデプロイメント成功を確約することだけが、多くのアプリケーションデリバリー
組織の最終目標です。
この目標達成を確約するためには、デプロイメントパイプラインまたは本番環境へのパス
の概念が重要となります。デプロイメントパイプラインは、デプロイメント、テスト、本
番運用の順に続く従来の SDLC から、アプリケーションやそのアプリケーションデプロイ
メントの潜在的リスクに応じて変わる、視覚的に定義された本番運用への動的なパスまで、
長年にわたり多くの形で存在してきました。
開発環境で生成されたコードが、異なる構成、ランタイムパラメータ、インフラセットアップ、データセットを有する本番環境でシームレスに動作することを ただ期待することは、特に デプロイメント中にアプリケーションの複雑さとアプリケーション間の依存関係に直面する場面が増える中、現実味がなくなっています。
10
ホワイトペーパーアプリケーションリリース自動化とインフラ自動化
パイプラインの定義に際して顧客から投げかけられる多くの質問の 1 つが、「うちのアプリ
ケーションすべてに同じパイプラインが必要なのか」というものです。シンプルな回答は、
対象となるアプリケーションを見て、それぞれについてコンプライアンスと監査要件を定
義することです。イントラネットサイトには、オンラインバンキングや取引システムを扱
う顧客と同じレベルの厳密さと検証が必要でしょうか。ほとんどの組織にとって、答えは
明確な「ノー」です。頻繁に使用される、可視性の高い消費者向けのアプリケーションに
は厳密さと制御を有することが必要とされますが、内部のテストアプリケーションやイン
トラネットサイト、または優先度の低いアプリケーションに同じアプローチを適用するこ
とは行き過ぎとなります。異なるアプリケーションに異なるパイプラインを適用すること
は自動化の採用を成功させるために不可欠です。
コンプライアンスを実証し、標準に準拠しながら、複数の環境へのデプロイメントの再現
性を定義するとき、パイプラインは極めて重要なコンポーネントとなります。同じプロセ
スを使用して複数の環境に同じアプリケーションをデプロイすることは、パイプラインを
定義し、適用することで簡単に達成できます。また、パイプラインは環境間の食い違いを
発見することも可能にします。
Deployment Automation は完全な機能を装備したグラフィカルなパイプライン機能を提供
するとともに、パイプラインの使用を義務付け、さらに ( 以前のデプロイメントが正常に完
了されたことを条件に ) 1 つの環境から別の環境へアプリケーションを自動的にプロモート
するオプションも備えています。Puppet にはパイプラインの概念がありません。それでも、
連鎖したスクリプトの使用を通じて自動化ジョブをリンクすることは可能です。このシナ
リオの場合のアドバイスとしては、SDA でグラフィカルなプロセスを通じて Puppet のジョ
ブをグラフィカルに駆動し、デプロイメントパイプラインに対して定義されたグラフィカ
ルなプロセスに従うことです。
モデル主導型のデプロイメント
ターゲットのアプリケーションをどのように実際にデプロイするのかを理解することは、
あらゆる自動化ツールの採用において重要な要因です。アプリケーションデプロイメント
の自動化は、そのデプロイメントの実行に必要なステップに関する知識がないと不可能で
す。Deployment Automation によって使用されるような、モデルベースのデプロイメント
では、アプリケーションの依存関係とシステム対システムの相互作用を含め、エンドユー
ザーがアプリケーションデプロイメントのプロセス全体をグラフィカルに定義することが
可能です。デプロイメントプロセスとデプロイメントパイプラインの両方をグラフィカル
な方法でモデル化する機能は、プロセス知識と理解がデプロイメントの実行に使用される
コードの暗黙の理解に基づいている宣言型アプリケーションと比較して、大きなメリットを
もたらします。たとえば、Tomcat などのアプリケーションサーバーにアプリケーションを
デプロイするシンプルなユーザー事例について考えてみましょう。モデルベースのシス
テムでは、実行される動作の定義がキャンバスにグラフィカルに描かれ、実行されるステッ
プとプロセスが示されています。宣言型システムでは、同じ動作にコードの変更が必要で
あり、この場合 1,000 行近くのコードを含むアーティファクトを変更しなければなりません。
アプリケーションデプロイメントの自動化は、その デプロイメントの実行に必要なステップに関する知識がないと不可能です。
11www.microfocus.com
当然、新しいユーザーにとっては、グラフィカルなプロセス定義を理解するほうが、数百
行のコードを含む新しいプログラミング言語の理解を求められるよりもずっと容易です。
カスタマイズは複雑なコードベースを確認する必要なく、簡単にデプロイメントプロセス
で確認できるため、将来的な変更も簡素化されます。
拡張性の小さな問題
エンタープライズ環境は複雑です。最新の最も優れたバージョンのソフトウェアを最新の
最も優れたインフラ上で稼働できるようにすることは、決して簡単なことではありません。
長期にわたって存続する企業組織のほとんどにおいて、レガシーアプリケーションが新し
いアプリケーション、多様なバージョンのプログラミング言語、ランタイムコンポーネン
トおよび抽象化レイヤと共存する必要があります。多くの組織にとって、より新しいアプ
リケーションのバージョンに移行する作業には、インフラ、エンドユーザーデスクトップ
のマイグレーション、既存のデータインターフェイスのアップデートも関わってきます。
デプロイメント時にアップデートが必要なアプリケーションのバージョンのばらつきがあ
ると、自動化テクノロジーとサードパーティ製システム間のインターフェイスが複雑でアッ
プデートが困難になり、非常に不利な状況に置かれることを意味します。Deployment
Automation では、データベースからミドルウェア、そしてアプリケーションサーバーさら
にはテストツールまで、多くの一般的なサードパーティ製システムへの迅速な統合機能が
多数提供されています。このアプリケーションにより使用される拡張可能なプラグインモ
デルは、サードパーティ製システムへの新しいプラグインの迅速な作成を実現し、自動化
プラットフォームの機能を高めて企業のあらゆる領域へと拡張することを可能にします。
Puppet のマニフェストは、インフラをコードとして定義するため、および事前定義された
「フルスタック」プロビジョニングまたはデプロイメントプロセスの一部としてのインフラ
構築、アップデート、破壊を駆動するためには、素晴らしい方法です。
両方の世界の長所を活用
ここまで論じてきたように、「フルスタック」プロビジョニングはアプリケーションとイン
フラスタック全体に関わることがあります。アプリケーションデプロイメント、インフラ
プロビジョニング、およびそれらすべての同期を維持するプロセスは、継続的デリバリー
の利点と移行テクノロジー、および DevOps に向けた人とプロセスの活用に期待を寄せる
組織にとって、重要なコンポーネントとなります。インフラプロビジョニングツールは、
その後のアプリケーションデプロイメントに向けた基盤インフラが整っていることを確約
するために非常に重要な役割を果たします。インフラデプロイメントとアプリケーション
デプロイメントに一貫したプロセスを使用することで、コンプライアンス、監査、再現性、
デプロイメントに対する知識が得られ、同時にデプロイメントの時間を短縮し、手動デプ
ロイメントのリスクを排除することができます。Deployment Automation によるインフラ
自動化の推進は、組織変革、プロセス簡素化、製品化リードタイムの短縮に向けた第一歩
となります。物事を破壊せずに迅速に行動することを可能にします。
アプリケーションデプロイメント、インフラプロビジョニング、およびそれらすべての同期を維持するプロセスは、継続的デリバリーの利点と移行テクノロジー、および DevOpsに向けた人とプロセスの活用に期待を寄せる組織にとって、重要なコンポーネントとなります。
162-JA0085-002A | S | 06/18 | © 2017 Micro Focus. All rights reserved. Micro Focusおよび Micro Focusロゴは、英国、米国、およびその他の国における Micro Focus、その子会社、関連会社の商標または登録商標です。その他すべての商標は、該当する所有者に帰属します。
お問い合わせ先：www.microfocus.com
