アジャイル DevOps: クラウド内でのソフトウェアの継続的デリバリー

オープンな継続的デリバリー・プラットフォームを活用する

開発部門と運用部門がコラボレーティブな方法で一緒に作業する場合、ソフトウェア・デリバリー・プロセスと変更のパイプラインを 1 ヶ所で管理しなければならないことがよくあります。こうしたニーズに対処するのが継続的デリバリー (Continuous Delivery: CD) プラットフォームです。「アジャイル DevOps」の今回の記事では、DevOps のエキスパートである Paul Duvall が、オープンな CD プラットフォームである OpenDelivery の使い方を説明します。

Paul Duvall, CTO, Stelligent

Paul DuvallPaul Duvall は、Stelligent の CTO です。数々の主要なソフトウェア・カンファレンスでメインの講演者を務めている彼は、ソフトウェア・プロジェクトの開発者、プロジェクト・マネージャー、アーキテクト、およびテスターと、実質上すべての役割を担当した経験を持ちます。彼が中心的な著者となった共著書『継続的インテグレーション入門 開発プロセスを自動化する 47 の作法』(Addison-Wesley、2007年) は、2008年度の Jolt Award を受賞しました。また、『Startup@Cloud』、『DevOps in the Cloud LiveLessons』(Pearson Education、2012年6月) の著者でもあります。その他の本にも貢献し、developerWorks では 20 の記事からなる連載「万人のためのオートメーション」を書いています。彼は、継続的デリバリーとクラウドを利用して、高品質のソフトウェアをより短時間に、より頻繁に提供することに熱意を持っています。Stelligent.com で彼のブログを読んでください。



2013年 5月 16日

この連載について

開発部門は、運用部門から多くのことを学べます。同じく運用部門も開発部門から多くのことを学べます。この連載では、運用部門の考え方と開発部門の考え方を相互に適用し、ソフトウェア製品をこれまでよりも迅速かつ頻繁に提供可能な総体的要素として捉える場合の実用性を探ることに話題を絞ります。

継続的デリバリー (Continuous Delivery: CD) を実施する場合、元々別チームである開発チームと運用チームとのコラボレーションという DevOps の理念が採用されます。CD では、ビルド、デプロイ、テスト、リリースというプロセスを自動化して実行し、ソフトウェアは常にリリース可能な状態にあります。ソフトウェア・システムのどの部分 (インフラストラクチャー、アプリケーション・コード、構成、あるいはデータ) が変更された場合でも、すべての変更で、リリース候補はデリバリー・パイプラインを通ります。デリバリー・パイプラインでは、ソフトウェアの作成、環境の構築、データベースの構築、テストの実行、ソフトウェアのデプロイメントが行われます。このパイプラインに沿ってソフトウェア・システムのデリバリー・プロセスを進めることができるプラットフォームは、多くのツールによって構成されます。

この記事では、Stelligent が開発した OpenDelivery というオープンソースの CD プラットフォームを紹介します。OpenDelivery は、オープンソース・ツールとスクリプトを 1 つのクラウド・インフラストラクチャーと組み合わせたものであり、ソフトウェア・システム全体がコードであるという考えを実践しています。スクリプトはすべて、GitHub バージョン管理リポジトリーでバージョン管理されます。OpenDelivery は表 1 に示す多くのツールを使用してプラットフォームを作成しており、Linux 上での Rails、Grails、Java による開発をサポートしています。この記事では、このプラットフォームの実行方法、デリバリー・パイプラインの使用方法、そして環境をプロビジョニングしてアプリケーションをデプロイするためのジョブの実行方法についての基本的なステップを説明します。

表 1. OpenDelivery プラットフォームで使用されるツール
ツール説明
AWS (Amazon Web Services) CloudFormationOpenDelivery は、Jenkins 環境の完全なインフラストラクチャー自動化と、ターゲット環境向けの AWS リソースの構成に CloudFormation (AWS リソースのプロビジョニングを記述するためのテンプレート言語) を使用します。
Amazon EC2 (Elastic Compute Cloud)OpenDelivery は、すべての計算インスタンスに EC2 を使用します。
Amazon CloudWatchOpenDelivery は、基本的なパフォーマンス・メトリックの監視と、しきい値を超えたときの SNS (Simple Notification Service) 通知の送信に CloudWatch を使用します。
Amazon Route 53Route 53 は、可用性が高いスケーラブルな DNS です。OpenDelivery は、ユーザーによる設定を基に、Route 53 を使用してエンドポイントに対するドメインを設定します。
Amazon SimpleDBSimpleDB は、可用性が高いスケーラブルな NoSQL データベースです。OpenDelivery は、IP アドレスや CloudFormation のスタック名などのパイプライン構成の格納に SimpleDB を使用します。
Amazon SNS (Simple Notification Service)OpenDelivery は、環境を作成するときに SNS を使用してメッセージを送信します。
Amazon S3 (Simple Storage Service)OpenDelivery は、プラットフォームが一時的に使用するファイルの格納に S3 を使用します。
CapistranoCapistrano は、デプロイメントに特化した Ruby ベースの DSL です。OpenDelivery は、アプリケーションを環境にデプロイするために Capistrano を使用します。
GitHubGitHub は OpenDelivery のソース・コードをホストします。OpenDelivery を使用する場合は、アプリケーション・コード用に GitHub アカウントも使用する必要があります。
JenkinsJenkins は CI (Continuous Integration: 継続的インテグレーション) サーバーです。OpenDelivery は、アプリケーション・コードのビルドとデプロイ、さらには構成、データ、インフラストラクチャーの変更をすべて実行するためのプラットフォームとして Jenkins を使用します。
PuppetPuppet は、独自のドメイン特化言語 (DSL) を備えたインフラストラクチャー自動化ツールです。ターゲット環境のインフラストラクチャーを自動化するためのコードはすべて Puppet で作成され、CloudFormation によって呼び出されます。
Rubyパイプラインを自動化するためのスクリプトの大部分は Ruby で作成されます。

前提条件

OpenDelivery プラットフォームを適切にインストールするための前提条件には以下の 3 つがあります。

  • CloudFormation: AWS CloudFormation にサインアップし、OpenDelivery で使用するすべての必要なサービスにアクセスできるようにする必要があります。
  • GitHub: GitHub アカウントが必要です。GitHub へのサインアップは無料です。
  • Route 53: 皆さんが所有するドメインに対してホストされるゾーンを Route 53 内で設定する必要があります。このドメインは、皆さんの OpenDelivery スクリプトの中で使用され、プラットフォームの一部として作成されるリソースのアドレスを指定します。

参考文献」で「OpenDelivery Quick Start Guide」へのリンクを参照してください。OpenDelivery を使用すると、リソースの使用に対し、AWS の料金に課金されることに注意してください。

継続的インテグレーション・プラットフォームのプロビジョニング

プロジェクトに対して OpenDelivery CD プラットフォームを設定するための最初のステップは、AWS 内で Jenkins CI サーバーをプロビジョニングすることです。まず、CloudFormation のセットアップ・テンプレートを実行します。すると以下のパラメーターを入力するように促されます。

  • ApplicationName: これから作成する Jenkins CI 環境の CNAME プレフィックス。例えば、「http://ApplicationName.domainname.com」。
  • GithubUsername: GitHub ユーザー名。
  • ProjectName: GitHub プロジェクトの名前。例えば、プロジェクトの GitHub の URL が「https://github.com/stelligent/continuous_delivery_open_platform」の場合、ProjectName は「continuous_delivery_open_platform」です。
  • Email: メッセージの送信先となる e-メール・アドレス。
  • HostedZone: 皆さんが所有し、Route 53 内に作成したホストされるゾーンの対象ドメイン名。
  • GithubOrganization: GitHub 組織の名前。例えば、プロジェクトの GitHub URL が「https://github.com/stelligent/continuous_delivery_open_platform」の場合、GithubOrganization は「stelligent」です。
  • GithubPassword: GithubOrganization および ProjectName に対する GitHub パスワード。
  • KeyName: EC2 鍵ペアの名前。ファイルのサフィックスを含めてはなりません。
  • InstanceType: EC2 インスタンスのタイプ。わからない場合はデフォルトを使用します。

ウィザードを完了すると、約 20 分かけてプラットフォームがビルドを実行します。ビルドが完了したら、CloudFormation のコンソールを開いて、「jenkinsstack」という名前のスタックの隣にあるチェックボックスを選択します。続いて「Outputs (出力)」タブをクリックします。「Domain key (ドメイン鍵)」行から値をコピーして Web ブラウザーに入力し、AWS 内で実行される、新たに作成された Jenkins CI サーバーを起動します。すると、図 1 に示す Jenkins 初期構成が表示されます。

図 1. CloudFormation を使用してプロビジョニングされた後の Jenkins 初期構成
Jenkins CI サーバーのスクリーンショット。「AddUserToEmailGroup」、「Build」、「BuildAMI」、「CapistranoModuleBuild」、「CommonStepDefinitionGemBuild」、「CreateTargetEnvironment」、「DeployApplication」という Jenkins のジョブが画面に表示されています。また、「DeliveryPipeline」と「Email Group Administration」という 2 つのタブも表示されています。

CD パイプライン

OpenDelivery では、標準的なデリバリー・パイプラインが最初から提供されています。このパイプラインは、StartDeliveryPipeline、Build、CreateTargetEnvironment、DeployApplication という Jenkins のジョブを順に実行します。これらのジョブのいずれかが失敗するとパイプラインは失敗し、ソフトウェアはデプロイされません。

Jenkins で表現されたデリバリー・パイプラインの例を図 2 に示します。

図 2. Jenkins CI サーバーで表現されたデリバリー・パイプライン
Jenkins CI サーバーで表現されたデリバリー・パイプラインのスクリーンショット。ソフトウェアが通過する 3 つの異なるステージがあります。まず、継続的インテグレーション・プロセスによってビルドが実行された後、Jenkins は StartDeliveryPipeline ジョブを使用してセットアップを実行します。次に CreateTargetEnvironment ジョブを使用してターゲット環境を作成し、最後に DeployApplication ジョブで表される 3 番目のステージを実行して、ターゲット環境にアプリケーションをデプロイします。これらの 3 つのステージは 1 つの作業単位として実行され、いずれかのジョブが失敗すると、3 つのステージ全体が失敗します。

図 2 で、ソフトウェアは 3 つのステージを通過します。まず、CI プロセスによってビルドが実行された後、Jenkins は StartDeliveryPipeline ジョブを使用して必要なセットアップを実行します。次に、CreateTargetEnvironment ジョブを使用してターゲット環境を作成します。最後に、ターゲット環境にアプリケーションをデプロイします。最後のステージは DeployApplication ジョブとして表されます。この 3 つのステージは 1 つの作業単位として実行され、いずれかのジョブが失敗すると、そのパイプラインは失敗します。

OpenDelivery では、このようなデリバリー・パイプラインを確立することにより、(ますます多くの自動化プロセスが発生するごとに) ソフトウェアが通過するパイプラインの各ステップで、リリース候補のリスクを評価します。これはつまり、リリース候補がこのパイプラインを正常に完了すれば、ビジネス判断次第でそのリリース候補を本番リリースできる可能性があるということです。また、パイプラインを構成して本番環境にデプロイすることもできます。


ターゲット環境のプロビジョニング

OpenDelivery プラットフォームのコンテキストでは、「環境」は、プロビジョニング対象のリソース (セキュリティー・グループ、ドメイン構成、ストレージなど) を伴う、EC2 インスタンス上のオペレーティング・システムとして定義されます。環境がプロビジョニングされると、その環境にソフトウェアをデプロイすることができます。主にそうした環境を作成するためのスクリプトを実行する Jenkins のジョブは、CreateTargetEnvironment ジョブです。

OpenDelivery のデリバリー・パイプラインは、CloudFormation テンプレートを呼び出すことによってゼロから環境を作成します。CloudFormation テンプレートは Puppet スクリプトを実行します (puppet apply を呼び出します)。(Puppet についての詳細は、「アジャイル DevOps: インフラストラクチャーの自動化」を参照)。

リスト 1 に、Puppet を呼び出すための CloudFormation テンプレートの一部を示します。

リスト 1. production.template のうち、Puppet を呼び出す CloudFormation スニペット
"# Install Ruby 1.9.3\n",
"rpm -Uvh /tmp/ruby-1.9.3p0-2.amzn1.x86_64.rpm\n",

"# Install Puppet 3.0.1 from Rubygem\n",
"gem install puppet --no-rdoc --no-ri\n",
"groupadd puppet\n",

"# Run Puppet\n",
"puppet apply --modulepath=/home/ec2-user/modules /home/ec2-user/manifests/site.pp\n",
...

OpenDelivery は、これらのスクリプトを GitHub リポジトリーに格納します。インフラストラクチャーの中で使用されるサーバーや構成に合わせて、標準的なスクリプトを変更することもできます。


デプロイメントの実行

参加してください

developerWorks の Agile Transformation community では、コミュニティーに参加している個人あるいは組織がアジャイル開発の原則に基づく基礎を固めるために役立つニュース、ディスカッション、トレーニングを提供しています。

自動デプロイメントは Capistrano の中で実行されます。Capistrano を使用することで、さまざまなタイプの開発プラットフォームや OS プラットフォームをデプロイすることができます。これらのデプロイメントは、前のセクションで説明した CloudFormation スクリプトと Puppet スクリプトによって作成される環境に対し、Jenkins のジョブから実行されます。デプロイメント用スクリプトの実行を主な役割とする Jenkins のジョブは、DeployApplication ジョブです。

リスト 2 のスニペットは、preconfigure タスクと deploy タスクを実行する Capistrano スクリプトです。

リスト 2. 環境をリセットしてデプロイメントを実行する deploy.rb の Capistrano スニペット
task :preconfigure do
  run "cd #{deploy_to} && sudo rm -rf #{deploy_to}/#{artifact_name}"
  config_content = from_template("config/templates/s3_download.erb")
  put config_content, "/home/ec2-user/s3_download.rb"
  run "sudo chmod 655 /home/ec2-user/s3_download.rb"
end

task :deploy do
  run "sudo ruby /home/ec2-user/s3_download.rb --outputdirectory #{deploy_to}/ \
    --bucket #{s3_bucket} --key #{artifact}"
  case
  when language == "rails"
    run "cd #{deploy_to} && sudo tar -zxf #{artifact}"
    run "sudo chown -R ec2-user:ec2-user #{deploy_to}/#{artifact_name}"
  end
end
...
case
when language == "rails"
after "preconfigure", "deploy", "database:configuration", "stripe:initializer", \
      "bundler:install", "database:migration", "virtualhost:configuration", \
      "whenever:set", "postconfigure", "restart"

他にも、Capistrano のレシピが OpenDelivery GitHub リポジトリーの deployment というディレクトリーのサブディレクトリーに含まれています。リスト 2 の場合、そうしたレシピの例は stripe (stripe.rb) と virtualhost (virtualhost.rb) です。デプロイメントでの必要に応じて、レシピを追加、変更、削除することができます。


継続的テスト

OpenDelivery プラットフォームには、インフラストラクチャー (CI 環境とターゲット環境) とデプロイメントに対して実行される、極めて重要な Cucumber 受け入れテストが含まれています。これらのテストは、CreateTargetEnvironment ジョブから環境をプロビジョニングするためのスクリプトや、DeployApplication ジョブからデプロイメントを実行するためのスクリプトに、変更が適用されるたびに実行されます。リスト 3 に示すのは、特定のサーバー・コンポーネントがインストールされて動作していることを検証するための、OpenDelivery プラットフォームの Cucumber スクリプトの例です。

リスト 3. 環境に対して自動テストを実行する、OpenDelivery の Cucumber スクリプト (production.feature) のスニペット
Feature: Scripted Provisioning of Target Environment
As a Developer
I would like my target environment provisioned correctly
so I can deploy applications to it

Background:
Given I am sshed into the environment

Scenario: Is the proper version of Postgresql installed?
When I run "/usr/bin/postgres --version"
Then I should see "8.4"

Scenario: Is the proper version of Apache installed?
When I run "/usr/sbin/httpd -v"
Then I should see "2.2"

...

用意されているテストを変更または拡張することで、さらなる環境やデプロイメントの構成をテストすることができます。


変更のたびにビルド、デプロイ、テスト、リリースを行う

クラウド内でソフトウェアの継続的デリバリーを実施するためのプラットフォームの作成に、OpenDelivery ではどのようにオープンソースのツールと構成を利用しているのか、そして皆さんがそのプラットフォームをどのように活用できるのかを、この記事では説明しました。一緒に作業を行う開発部門と運用部門にとって、継続的デリバリーは最適です。次回の記事では、部門のサイロを解体し、機能をまたがる DevOps チームを作成する方法について説明します。

参考文献

学ぶために

製品や技術を入手するために

  • OpenDelivery: OpenDelivery プラットフォームを実行するためのソース・コードとテンプレートをダウンロードしてください。
  • IBM Tivoli Provisioning Manager: Tivoli Provisioning Manager により、物理サーバー、仮想サーバー、ソフトウェア、ストレージ、ネットワークの管理を自動化し、動的なインフラストラクチャーを実現することができます。
  • IBM Tivoli System Automation for Multiplatforms: Tivoli System Automation for Multiplatforms により、エンタープライズ規模のアプリケーションや IT サービスの高可用性と自動化を実現することができます。
  • IBM 製品の評価をご自分に最適な方法で行ってください。評価の方法としては、製品の評価版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、Wiki を調べることができます。
  • developerWorks の Agile Transformation community では、コミュニティーに参加している個人あるいは組織がアジャイル開発の原則に基づく基礎を固めるために役立つニュース、ディスカッション、トレーニングを提供しています。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps, Java technology, Open source, Cloud computing
ArticleID=929448
ArticleTitle=アジャイル DevOps: クラウド内でのソフトウェアの継続的デリバリー
publish-date=05162013