目次


アーキテクチャー・ラボ: コンテナーを使用した Web アプリケーションのホスティング (Etherpad ラボ 1)

Comments

このラボでは、Bluemix 内で Web アプリケーションをホストする手順を説明します。この手順を完了することが、他のすべての Etherpad ラボ・シリーズの前提条件となります。Web アプリケーションを稼働状態にするには、タスク 1 からタスク 6 までのステップをすべて完了する必要があります。このラボは、以下のセクションで構成されています。

はじめに

この「はじめに」セクションに続く 3 つのセクションでは、Bluemix を利用して Web アプリケーションをクラウド上でホストする際に重要となる概念およびアーキテクチャーに関する考慮事項について説明します。また、Etherpad の概要、このラボでリファレンスとして使用するコラボレーティブ Web アプリケーション、そしてさまざまなサービスを探るのに役立つ今後の一連のラボについても説明します。

アプリケーションを Bluemix にデプロイする理由

最近のインターネットでは、さまざまなタイプの Web アプリケーションが実行されており、これらのアプリケーションを実行するインフラストラクチャーを管理および保守する方法も、アプリケーションの数だけあります。IBM Bluemix では、最小限の手間とオーバーヘッドで Web アプリケーションのデプロイおよび保守を迅速かつ容易に行えるようにするクラウド機能を提供しています。また、業界で採用されている標準アーキテクチャー機能をアプリケーションのデプロイメントに適用することで、自信を持ってインフラストラクチャーを拡張、拡大することができます。

アプリケーションを Bluemix 上にホストすると、ユーザーに多くのメリットがもたらされます。Bluemix は、アプリケーションの開発、テスト、ビルド、デプロイを単純化する DevOps ツールと統合サービスの完全なセットを開発者に提供する、すべてを網羅したオファリングであり、Bluemix 上にホストされたアプリケーションは、ベースとなるクラウド・インフラストラクチャーの機能を利用することができます。クラウド・インフラストラクチャーは、エンタープライズ・アプリケーションをサポートするために必要な、スケーラビリティー、パフォーマンス、可用性、セキュリティーといった非機能要件を最大限にサポートします。しかも Bluemix には、高度な分析機能、ソーシャル機能、モバイル機能を組み込むことでアプリケーションを拡張するための豊富なサービスが提供されています。Bluemix プラットフォームを利用すれば、開発者や組織はインフラストラクチャーに関連する構築作業の詳細を心配する必要がなくなり、組織にとって重要な事項、つまり顧客により優れた価値をもたらすビジネス・シナリオに専念できるようになります。

以降のセクションでは、IBM Bluemix を利用して Web アプリケーションをデプロイする際の主な考慮事項を取り上げ、アーキテクチャーの概要を説明します。これらのセクションを一通り読んでから、「Etherpad シリーズ」のラボに取り掛かることをお勧めします。

Etherpad Web アプリケーションの紹介

「Etherpad シリーズ」のラボでは、Web アプリケーション・ホスティング・パターンの特定のアーキテクチャー要素を利用してコラボレーティブな編集を行う Web アプリケーションをデプロイします。そして、Bluemix に用意されているサービスを利用してアプリケーションを拡張します。この Etherpad Lite というアプリケーションは、リアルタイムのコラボレーションを目的に作成されたオープンソース・プロジェクトで、拡張オプションにより、必要に応じて簡単に追加機能を組み込めるようになっています。

このシナリオでの私たちの役割は、Ethernet Lite デプロイメントの管理を任された開発者です。現時点でのデプロイメントはオンプレミスで行われているため、アプリケーションをサポートするミドルウェアとデータベース・インフラストラクチャーも管理しなければなりません。この環境を提供する専用のマシンは最大キャパシティーに近づきつつありますが、追加のハードウェアをリクエストすることはできないため、インフラストラクチャーを拡張するのは困難です。

私たちが本当に望んでいるのは、デプロイメントをどこか他の場所に移すことです。よりスケーラブルな環境に移せば、チームの数と使用量が増えるのに伴い、さらなるインスタンスを簡単に追加することができます。また、管理対象の環境に移せば、サーバーの保守ではなく開発作業に専念することができます。そのような環境として最適なのはクラウド環境ですが、アプリケーションを作成し直さず、既存のコードを引き続き実行したいと思っています。

幸いにも、IBM Bluemix でちょうどコンテナー・サービスがリリースされたので、オフプレミスで実行されているコンテナーに Etherpad Lite Web アプリケーションをデプロイすれば、新しい機能を簡単に開発してテストし、ユーザーに公開することができます。

直ちにターゲットにしたい機能としては、ホストされたデータベースのサービスが挙げられます。その目的は、Etherpad のデータを外部化し、IBM の Watson Question and Answer サービスを統合することです。これらはすべて、Bluemix 上でアプリケーションを作成すれば可能になります!

アーキテクチャー要素は、スピード、柔軟性、そして投資利益率を実現できることを期して選択しました。Bluemix では、アジャイル/パイプライン/DevOps 指向の統合方式で、複数の環境 (テスト環境、開発環境、本番前環境、本番環境など) の複数のバージョンまたはリリースに、アプリケーションを即座にデプロイすることができます。また、Bluemix に組み込まれたハイブリッド統合機能を使用して、ファイアウォールの背後にあるあらゆるリソースをターゲットに API またはホスト名とポートを指定して、オンプレミスのエンタープライズ・リソースと統合する機能もあります。

簡単に言うと、Bluemix 上でアプリケーションを作成すれば、アプリケーションを迅速かつセキュアに拡張できるようになって、コストと時間の節約が実現されます。それと同時に業界で実証済みのアーキテクチャーをベースにアプリケーションを作成できるようになります。

Web アプリケーションをホストするクラウド・アーキテクチャーの概要

このラボ・シリーズでは、標準的な Web アプリケーションを、業界で実証済みの Web アプリケーション・ホスティング・アーキテクチャーにより近いアーキテクチャーへと適応させるためのスキルを段階的に磨いていきます。この Web アプリケーション・ホスティング・リファレンス・アーキテクチャー (以下を参照) と、それを文書化している Cloud Standards Customer Council の「Resource Hub」に、ユーザーの初期 URL リクエストから、バックエンドのデータ呼び出しに至るまでのあらゆる詳細が説明されています。

Web アプリケーションのアーキテクチャーのリファレンス・ダイアグラム (1024x593) (アーキテクチャー・ラボ: コンテナーを使用した Web アプリケーションのホスティング (Etherpad ラボ 1))
Web アプリケーションのアーキテクチャーのリファレンス・ダイアグラム (1024x593) (アーキテクチャー・ラボ: コンテナーを使用した Web アプリケーションのホスティング (Etherpad ラボ 1))

Web アプリケーション・ホスティング・リファレンス・アーキテクチャー

以下で、Web アプリケーション・ホスティング・リファレンス・アーキテクチャーのコンポーネントについて説明します。

  • インバウンド・ユーザー・リクエストはまず、トラフィックを適切なインフラストラクチャー・エンドポイントにルーティングする「ドメイン・ネーム・サービス (Domain Name Services)」によって処理されます。
  • 「コンテンツ・デリバリー・ネットワーク (Content Delivery Network)」は、あらゆる静的アプリケーション・コンテンツを最小の遅延時間と最大のスピードで提供し、並外れたエンド・ユーザー・エクスペリエンスを生み出します。
  • 「ファイアウォール (Firewall)」は、Web アプリケーションが円滑に動作している間、侵入者を締め出すための境界を提供します。
  • 「ロード・バランサー (Load Balancer)」は、環境内のサーバー・ノードのトラフィックおよびリソース使用量を管理して、過負荷状態に陥る機器が 1 つもないように構成できる柔軟性を実現します。
  • 「Web アプリケーション・サーバー (Application Server)」コンポーネントは、Web アプリケーションの中核として、コア・アプリケーションをエンド・ユーザーに提供します。サーバー・インフラストラクチャーを構築するには、ハイパフォーマンスのコンテナー、仮想マシン、または Cloud Foundry ベースのランタイムを使用してください。これらすべてはアーキテクチャー全体に同じように統合することが可能です。
  • 「ユーザー・レジストリー・サービス」は、認証と承認を可能にし、アプリケーション全体のリソースをセキュアにします。
  • 「セッションおよびデータ・キャッシング」は、低遅延でのデータ・アクセスを確実にするとともに、データ損失を防ぐことで、安定したエンド・ユーザー・エクスペリエンスを実現します。さらに、ストレージ・サービスを利用すれば、ストレージに対する要求を満たすように SAN または NAS ソリューションをカスタマイズして、このソリューションを総合管理することができます。
  • 「管理対象データベース・サービス」は、ハイパフォーマンス・データベース・サポートを提供すると同時に、開発者がデータベースの保守ではなくアプリケーションに専念できるようにします。管理対象のデータベースは、標準的な SQL データベースから最近の NoSQL データベース、さらにはビッグ・データ・サービスまで多岐に及びます。

上記のリファレンス・アーキテクチャーは複数の層で構成され、各層に Web アプリケーションのパフォーマンスを最大限にするのに不可欠な複数のコンポーネントがあります。このラボ・シリーズでは、特に Web 層とサービス層、そして「Web アプリケーション・サーバー (Application Server)」コンポーネント、「キャッシュ (Cache)」コンポーネント、「ロード・バランサー (Load Balancer)」コンポーネントにフォーカスします。

上記のリファレンス・アーキテクチャーに加え、クラウド・アプリケーションを開発、デプロイ、保守する際に最もよく従われている一般的な基本ルールがあります。とりわけ重要な 9 つのルールについては「クラウド・アプリケーションにとって最も重要な 9 つのルール」と題した Kyle Brown と Mike Capern による投稿記事でも詳しく説明されていますが、ここでもその内容をまとめておきます。

ルール 1 は、アプリケーションのコードを特定のトポロジー専用にしないことです。おわかりのように、ここまではコンポーネントのみを話題に取り上げており、特定のハードウェア、ソフトウェア、ホスティング機能については触れていません。そのカギとなるのは、アプリケーションの柔軟性を保つことです。

ルール 2、3、および 4 は、いずれもクラウド・アプリケーションの一時的な (永続的ではない) 性質に関連しています。具体的には、「ローカル・ファイルシステムを永続的であると想定しない」、「セッション・ステートをアプリケーション内に保持しない」、そして「ファイルシステムをログに記録しない」というルールです。現在、クラウド・アプリケーションを実行する多くのラインタイムは一時的であり、永続的ではありません。したがって、アプリケーション・インスタンスとそのベースにあるファイルシステムは、アプリケーションがスケーリングする際、あるいはインスタンスが再起動される際に、いったん消滅して再作成されます。全体的に見ると、Web アプリケーションでは新しい概念ではありませんが、クラウド・アプリケーションを成功させるにはこれらの概念が重要となります。

ルール 5 とルール 6 では、インフラストラクチャーと、作成するアプリケーションの土台にフォーカスしています。そのルールとは、特定のインフラストラクチャーへの依存を前提としないこと、そしてインフラストラクチャーの API をアプリケーションの中から使用しないことです。アプリケーションを実行する際の土台となっているインフラストラクチャーに、アプリケーションを結び付けないようにする必要があります。というのも、アプリケーションは開発者やホスティング・プロバイダーによって別のプラットフォームに移される場合や、同時に複数のプラットフォーム上で実行される場合があるからです。アプリケーションがインフラストラクチャーと結び付いていなければ、アプリケーション・コードの作成以外のライフサイクルでプラットフォームの API や依存関係の変更があっても、要件を追加する必要はありません。ベスト・プラクティスは、インフラストラクチャーのニーズをアプリケーションの外部に抽象化し、それらのニーズに、クラウド・プラットフォーム上で使用可能な管理および操作インターフェースで対処することです。

ルール 7 とルール 8 は、長期的な正常性を維持するために、アプリケーション開発全体に共通することです。すなわち、一般的ではないプロトコルは使用しないこと、そしてオペレーティング・システムに固有の機能を利用しないことです。将来的に、アプリケーションにどのようなサービスを統合する必要が出てくるかわかりません。また、アプリケーションがどのオペレーティング・システム上で実行されるかもわかりません。アプリケーションを開発する際には、標準でサポートされている API をできるだけ多く使用するようにして、特定のランタイムに束縛されないようにする必要があります。

最後のルール 9 は、手作業でアプリケーションのインストールをしないことです。インストールは自動化するに限ります。開発、テスト、ステージング、本番のいずれの段階にしても、アプリケーションのインストールはできる限り自動化する必要があります。そうすることにより、再利用が促進され、時間が節約され、長い目で見ればエラーが大幅に減ることになります。つまり、ユーザーにとってより高い品質であると同時に、よりアップタイムが長いアプリケーションになるということです。

おそらく、皆さんはこれらのルールの多くをすでにアプリケーションに採用していることでしょう。もしそうでない場合は、これらのルールの目標とその達成方法の詳細について、Kyle と Mike の投稿記事を読んでください。これからラボで行う演習では、以上のルールの模範を示し、これらのルールに従ってクラウド・アプリケーションを実現できることを実証します。

ラボに取り組む心の準備はできましたか?では早速、最初のラボを開始しましょう。

ラボのタスク
Etherpad ラボ 1 アーキテクチャーのリファレンス・ダイアグラム (1024x593) (アーキテクチャー・ラボ: コンテナーを使用した Web アプリケーションのホスティング (Etherpad ラボ 1))
Etherpad ラボ 1 アーキテクチャーのリファレンス・ダイアグラム (1024x593) (アーキテクチャー・ラボ: コンテナーを使用した Web アプリケーションのホスティング (Etherpad ラボ 1))

タスク 1. Bluemix アカウントをセットアップする

IBM Bluemix は、モバイル、スマート端末、Web、ビッグ・データなど、あらゆるタイプのアプリケーションを作成、管理、実行するための、オープン・スタンダードのクラウド・プラットフォームです。Bluemix で提供している機能には、Java、モバイル・バックエンドの開発、アプリケーションの監視などに関するもの、またエコシステムのパートナーおよびオープンソースによる機能などがあり、すべてクラウド内の as-a-Service (サービスとしての) モデルで提供されています。

Bluemix の機能を使用するには、その前に、アカウントの登録が必要です。無料のアカウントに登録すると、無料のアカウントを使用することができます。アカウントを登録すると、Bluemix 資料の「Bluemix の概要」セクションに有用な情報が見つかります。

ヒント: 無料のアカウントを使用する場合、利用できるサービス・インスタンスは 4 つに制限されます。今後のラボでは、アプリケーションで使用するサービス・インスタンスを多数作成することになります。したがって、ラボを進めていくためには、前の Bluemix アクティビティーで作成したサービスのうち、使用していないサービスや関係のないサービスを削除しなければならない場合もあります。サービスを削除するには、Bluemix ダッシュボードで、サービス・パネルの右上に表示される設定アイコンをクリックしてから、「Delete App (アプリの削除)」を選択します。アプリケーションを再ステージングするよう求められたら、「RESTAGE (再ステージ)」をクリックし、アプリケーションが再デプロイされるまで待ってから、作業を続けます。

  1. Bluemix にログインします。すると、以下に示すダッシュボードが開きます。
    Bluemix のダッシュボード
    Bluemix のダッシュボード (アーキテクチャー・ラボ: コンテナーを使用した Web アプリケーションのホスティング (Etherpad ラボ 1))
    Bluemix のダッシュボード (アーキテクチャー・ラボ: コンテナーを使用した Web アプリケーションのホスティング (Etherpad ラボ 1))

    ダッシュボードには、組織のアクティブな Bluemix スペースの概要が示されます。デフォルトでは、スペースは「dev」、組織はプロジェクト作成者のユーザー名に設定されます。例えば、bob@example.com で初めて Bluemix にログインした場合、アクティブなスペースは「dev」、組織は「bob@example.com」として示されます。Bluemix で組織やスペースを追加で作成する場合は、その作成した組織またはスペースを一貫して使用してラボに従ってください。選択項目にはデフォルト値を使用します。
  2. IBM Containers を作成するために、左側のナビゲーションで「CONTAINERS (コンテナー)」を選択します。
  3. 「CREATE A CONTAINER (コンテナーの作成)」をクリックします。
  4. イメージ・レジストリー URL の名前を指定するよう促された場合、URL の名前を指定する必要があるのは一度だけです。この URL は、コマンド・ライン・インターフェースからプライベート・コンテナーのイメージにアクセスする場合に使用します。

    ヒント: IBM Containers Extension を使ってコマンド・ライン・リクエストを発行する際には、ここで入力するレジストリー URL を組織が使用します。指定するレジストリー名は、レジストリーを表す一意の名前で、しかも入力しやすいものにしてください。

  5. コンテナーの起動ビューが表示されます。このビューで、レジストリー URL、コンテナー、イメージを確認することができます。これらの情報は、後でアプリケーションのコンテナーをビルドしてデプロイするときに使用します。

タスク 2. 開発ツールをワークステーションにインストールする

次に、いくつかの開発ツールをワークステーションにインストールする必要があります。具体的には、Git、Python、pip、Docker、Cloud Foundry CLI、および ICE (IBM Containers Extension) コマンド・ライン・ツールをインストールします。

Windows 7 および Windows 8 に開発ツールをインストールする場合

Windows ワークステーションで Docker を実行するには、ある程度の試行錯誤が必要になるのが通常です。それよりも、Ubuntu 14.04 を実行する新しい (実際のまたは仮想の) マシンを用意するか、Windows オペレーティング・システムで Ubuntu を仮想マシンとして実行するほうが手軽な方法となるはずです。Ubuntu が稼働状態になれば、残りのセットアップは簡単です。

Windows システムの仮想化サポートは、多くの場合、BIOS で無効にされています。ブート時に BIOS 設定画面を立ち上げて、仮想化サポートを有効にしなければ、Docker やその他の仮想マシンを実行することはできません。仮想化の設定は、一般に「Security (セキュリティー)」、「Chipset (チップセット)」、または「Processor (プロセッサ)」メニューからアクセスすることができます。

Ubuntu が使用可能な状態になっている場合は、Linux のセットアップ手順にそのまま従うことができます。

Mac OSX に開発ツールをインストールする場合

Mac ワークステーションの場合、私たちが推奨するセットアップは、boot2docker というツールを実行することによって Linux 仮想マシンをワークステーション上で実行するというものです。この場合、boot2docker 仮想マシンでDocker コンテナーを実行することになります。このリンク先に示されているセットアップ手順に従って、Git、VirtualBox、boot2docker、Docker、Python、Pip、Cloud Foundry CLI、ICE コマンド・ライン・ツールをインストールしてください。

Linux (Ubuntu、Red Hat など) 上に開発ツールをインストールする場合

Linux ワークステーション (Ubuntu、Red Hat など) では Docker をネイティブに実行することができるため、boot2docker 仮想マシンは不要です。以下の手順に従って、Ubuntu ベースの環境内に開発環境をセットアップして構成してください。問題が発生した場合は、その特定のツールのインストール・ステップの後、ツールのドキュメントへのリンクを用意してあるので、そのリンクを参照してください。

  1. Ubuntu (Server または Desktop) をインストールします。Docker には 64 ビット環境が必要なので、必ず 64 ビット版をインストールしてください。

    インストールに関する注意点:

    • このラボで使用したバージョンは Ubuntu 14.04 LTS です。
    • Ubuntu を仮想マシンで実行していて、ホストとゲストの間のネットワーキングを十分に理解している場合は、Ubuntu Server を選択するのが理想的です。ネットワーキングとポート・フォワーディングを構成したくないとしたら、Ubuntu Desktop を選択することをお勧めします。その場合、仮想化プラットフォーム上でネットワーキング構成をすることなく、デスクトップ・ベースの環境で作業することができます。
    • 以降のステップを実行するには、DockerGitCloud Foundry CLI、およびIBM Containers Extensions CLI をインストールする必要があります。
  2. ターミナル・ウィンドウから、以下に記載する各コマンドを実行します。これらのコマンドは、非 root ユーザーとして実行することを前提とします (これが一般的です)。root として実行する場合、各コマンドの先頭にある sudo コマンドは不要です。

    Git をインストールします。

    sudo apt-get install git

    Docker で保守されているパッケージをインストールします。

    sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9
    sudo sh -c "echo deb https://get.docker.com/ubuntu docker main > /etc/apt/sources.list.d/docker.list"
    sudo apt-get update
    sudo apt-get install lxc-docker
    source /etc/bash_completion.d/docker
  3. 以下のコマンドを使用して Docker のインストールをテストします。
    sudo docker run -i -t ubuntu /bin/bash

    上記のコマンドは、Ubuntu ベースの Docker コンテナーを起動して、その実行中のコンテナーのコマンド・ラインをアクティブにします。root@4656f27df98f:/# のようなプロンプトが出されたら、「exit」と入力すると、Ubuntu コマンド・ラインに戻ってコンテナー・インスタンスを停止することができます。

  4. 以下のコマンドを使用して、PIP (Python Indexing Project) をインストールします。
    sudo apt-get install python-pip
  5. 以下のコマンドを使用して、Python Setuptools をインストールします。
    swget https://bootstrap.pypa.io/ez_setup.py -O - | sudo python
  6. 以下のコマンドを使用して、Cloud Foundry CLI をインストールします。

    このリンク先のリリース・サイトから、Debian 64 ビットの最新インストーラーをダウンロードします。その後、カレント・ディレクトリーをダウンロード先ディレクトリーへと変更し、以下のコマンドを実行します。

    sudo dpkg -i cf-cli_amd64.deb
  7. 以下のコマンドを使用して、ICE (IBM Containers Extensions) CLI をインストールします。
    wget https://static-ice.ng.bluemix.net/icecli-2.0.zip
    sudo pip install icecli-2.0.zip

重要: ICE から Docker が見つからないというエラー、または ~/.ice/ice-cfg.ini ファイルが存在しないというエラーが出されることがあります。そのようなエラー・メッセージを受け取った場合は、以下の内容が含まれた ~/.ice/ice-cfg.ini ファイルを作成すると、問題が解決されるはずです。その他の必要なパラメーターは、ICE を操作するときに追加されます。

[DEFAULT]
docker_path = /usr/bin/docker

タスク 3. サンプル・コードを入手する

次に、このラボのサンプル・コードを Git リポジトリーからダウンロードする必要があります。このラボでは、Etherpad というオープンソース Node.js アプリケーションを使用します。このアプリケーションは簡単にセットアップできて、楽しくいろいろと試せるアプリケーションです。これ以降、ラボでは Ubuntu ベースのコマンド・ライン環境を前提として説明を進めるので、ご使用の環境に応じてコマンドを調整してください。

  1. ターミナル・ウィンドウを開いて、作業ディレクトリー (例: 「git」) を作成し、カレント・ディレクトリーをその作業ディレクトリーへと変更します。
    mkdir git
    cd git
  2. 以下のように、Git リポジトリーを作業ディレクトリーにダウンロードします。
    git clone https://hub.jazz.net/git/osowski/etherpad-lite
  3. カレント・ディレクトリーを上記で作成した etherpad-lite サブディレクトリーへと変更します。
    cd etherpad-lite

これで、サンプル・アプリケーションを作成する準備が整いました。

タスク 4. アプリケーション用のイメージをビルドする

etherpad-lite ディレクトリーに、Dockerfile という名前のファイルがあります。このファイルをエディターで開くと、このファイルで行っている内容を確認することができます。ただし、今回のラボではこのファイルの内容を編集する必要はありません。Dockerfile は Docker に対し、このサンプル・アプリケーションを実行するコンテナーのイメージをビルドする方法として、使用するベース・イメージ (IBM Node.js コンテナー) と、アプリケーションをインストールおよび実行するためのコマンドを指示します。

Dockerfile の内容

以下に、Dockerfile の興味深い部分を抜粋します。

  • キーワード from で始まる最初の行は、Docker に対し、使用するコンテナー・ベース・イメージを指示します。
    from registry-ice.ng.bluemix.net/ibmnode:latest

    IBM Node コンテナー・イメージについての詳細は、このリンク先を参照してください。
  • 続いて、RUN で始まるいくつかの行があります。これらの行は、Etherpad アプリケーションと、このアプリケーションが実行する必要のあるすべてのパッケージをインストールします。このラボで使用するベース・イメージでは、Ubuntu 14.04 オペレーティング・システムを使用しているので、RUN コマンドは Ubuntu スタイルとなっています。
    # Install etherpad-lite
    RUN mkdir /src
    RUN git clone https://github.com/ether/etherpad-lite.git \/src/etherpad-lite --branch develop --single-branch
    ADD ./settings.json /src/etherpad-lite/settings.json
    RUN /src/etherpad-lite/bin/installDeps.sh
    EXPOSE :9080
    ENTRYPOINT ["/src/etherpad-lite/bin/run.sh", "--root"]
  • ADD で始まる行は、カレント作業ディレクトリーからコンテナー・イメージに settings.json ファイルをコピーします。このファイルは、Dockerfile と一緒に GIT リポジトリーから抽出されたものです。
    ADD ./settings.json/src/etherpad-lite/settings.json
  • 次の行では、コンテナー内で Etherpad インストーラーが実行されます。そして、ポート 9080 にアクセスする必要があることを、EXPOSE キーワードを使用してコンテナーに伝えます。
    RUN /src/etherpad-lite/bin/installDeps.sh
    EXPOSE :9080
  • 最後に ENTRYPOINT 行で、コンテナーの起動時に Etherpad Web アプリケーションを起動するために実行するコマンドを指示します。この行を追加することにより、コンテナーの起動時に必ず Etherpad が実行されるようになります。
    ENTRYPOINT ["/src/etherpad-lite/bin/run.sh", "--root"]

アプリケーションを構成する

etherpad-lite ディレクトリー内にある settings.json で、Etherpad アプリケーションを構成します。Bluemix のコンテナーに関する資料には、「ご使用のコンテナーで浮動 IP アドレスに使用するためにオープンしているポートは、22、80、443、9080、および 9443 のみです」と記載されています。つまり、デフォルト・ポートではなくポート 9080 を使用するように Etherpad を構成する必要があります。Bluemix で Etherpad を実行するには、以下の設定を変更するだけで十分ですが、後で他の設定も変更してみて構いません。

// Name your instance!
"title": "Etherpad on Bluemix",
//IP and port which etherpad should bind at
"ip": "0.0.0.0",
"port" : 9080,

Etherpad のソース・コード資料は、GitHub に用意されています。

ここまででファイルについて理解したので、今度は Docker コンテナーのビルドに取り掛かります。

コンテナーをビルドする

Linux では一般に、以下の ICE (IBM Containers Extension) コマンドを実行する際には、sudo ice を最初に実行する必要があります。Mac OSX の場合は、sudo コマンドを使用しないでください。

まず、ICE コマンド・ライン・ツールにログインします。

ice login

etherpad-lite ディレクトリーから、以下のコマンドを続けて実行してコンテナーをビルドします。コマンドに含まれるレジストリー URL は、自分用の値を使用する必要があります。自分用のレジストリー URL は、Bluemix アカウントのセットアップ時に表示されたコンテナーの起動ビューに表示されています。

最初に実行する以下のコマンドは、グローバル IBM リポジトリーから最新の公式 IBM Node.js コンテナーを取得します。

ice --local pull registry-ice.ng.bluemix.net/ibmnode:latest

この後記載する 2 番目のコマンドは、取得した最新イメージと、ラボの GIT リポジトリーから抽出した Dockerfile および settings.json を使用してアプリケーション・コンテナーをビルドします。-t パラメーターで指定されるタグは、ビルドされるイメージに自動的に適用されるので、このタグをローカルで参照することができます。

ヒント: コマンド末尾のピリオド (.) は重要です。このピリオドによって、カレント・ディレクトリー (複製された etherpad-lite ディレクトリー) が作業ディレクトリーとして指定され、Docker はそのディレクトリーからイメージをビルドするようになります。

  • フォーマット:
    ice --local build -t YOUR_LOCAL_IMAGE_NAME .
  • 例:
    ice --local build -t etherpad_bluemix .

以下に示す最後のコマンドは、リポジトリーに入れるイメージにタグを付けます。このコマンドのフォーマットを使用することで、ビルドしたイメージを Bluemix に公開して、IBM Containers サービス上でそのイメージを実行できるようになります。このコマンドは、前に build コマンドを実行したときにタグを付けたローカル・イメージを取得し、そのイメージにリポジトリー固有のタグを適用します。これにより、イメージを IBM Containers サービスの共有リポジトリーに正しく配置することができます。フォーマットは以下のとおりでなければなりません。これとは一致しない別のイメージ名のフォーマットを使用した場合、イメージを正常に Bluemix にプッシュすることはできません。

  • フォーマット:
    ice --local tag -f YOUR_LOCAL_IMAGE_NAME registry-ice.ng.bluemix.net/ YOUR_REGISTRY_URL / YOUR_REMOTE_IMAGE_NAME
  • 例:
    ice --local tag -f etherpad_bluemix registry-ice.ng.bluemix.net/bluemix_residency/etherpad_bluemix

ローカルのイメージ名とリモートのイメージ名を同じにする必要はありませんが、同じイメージ名を使用すると、ローカルとリモートのイメージ・リストを比較する場合に、比較するイメージを明確にする上で役立ちます。また、ビルド・ステップで初期イメージにフルネームのリポジトリー・タグを付けることもできますが、ローカルで実行するときには短いタグを使用したほうが、イメージを Bluemix にプッシュする前に時間を節約して Bluemix に必要なフォーマットを適用する上では有効です。

以上のコマンドを実行順に示すと以下のようになります。フォーマットが指定された必須パラメーターを、各自の組織とイメージの情報で置き換えてください。

ice --local pull registry-ice.ng.bluemix.net/ibmnode:latest
ice --local build -t etherpad_bluemix .
ice --local tag -f etherpad_bluemix registry-ice.ng.bluemix.net/bluemix_residency/etherpad_bluemix

タスク 5. アプリケーションをワークステーション上でテストする

コンテナーのビルドが完了したら、試しにローカルで Etherpad Web アプリケーションをテストすることができます。

  1. 以下のコマンドを入力することで、Docker コンテナーを起動して、コンテナー内で Etherpad を実行するとともに、次のステップで必要となるコンテナー ID (CID) を出力します。
    docker run -d -p 9080:9080 etherpad_bluemix
  2. ブラウザーに入力する URL を調べてから以下のコマンドを入力し、実行中の Etherpad Web アプリケーションを確認します。${CID} は、前のステップの docker run コマンドから出力されたコンテナー ID に置き換えてください。このコマンドは、Docker コンテナー自体の IP アドレスを出力します。Linux デスクトップ環境で実行している場合は、この IP アドレスが必要です。
    docker inspect --format '{{ .NetworkSettings.IPAddress }}' ${CID}
  3. 仮想マシン内で Linux サーバー環境を実行している場合、ホスト・マシンからコンテナー上で実行中の Etherpad にアクセスするために、仮想化プラットフォームのポート・フォワーディングを構成する必要があります。ポート・フォワーディングの構成はプラットフォームによって異なりますが、通常は、ホスト・マシン上のポート 9080 を内部仮想マシン・ゲストに転送するだけで十分です。以下に、VirtualBox ポート・フォワーディングの構成例を示します。
    ポート・フォワーディング・ルール
    ポート・フォワーディング・ルールの設定画面 (アーキテクチャー・ラボ: コンテナーを使用した Web アプリケーションのホスティング (Etherpad ラボ 1))
    ポート・フォワーディング・ルールの設定画面 (アーキテクチャー・ラボ: コンテナーを使用した Web アプリケーションのホスティング (Etherpad ラボ 1))

    同様に、VMWare 上で実行されている仮想マシンにもポート・フォワーディング・ルールが必要です。ただし、「Guest IP (ゲスト IP)」の値には、VMWare 8 ネットワークに関連付けられた IP アドレスを指定する必要があります。

    Mac OSX の場合は、boot2docker が仮想マシン内で Docker を実行しているので、boot2docker の IP アドレスが必要です (通常は 192.168.59.103)。boot2docker の IP アドレスを取得するには、以下のコマンドを実行します。

    boot2docker ip
  4. このラボでは Etherpad をポート 9080 でホストしているため、ブラウザーで http://192.168.59.103:9080/ のような URL (192.168.59.103 の部分はコンテナーの IP アドレスで置き換えます) を開くことで、実行中の Etherpad アプリケーションをテストすることができます。

    すべてが正常に実行されると、ウェルカム画面が表示されます。

    新規パッドを作成するためのウィンドウ
    ウェルカム画面 (アーキテクチャー・ラボ: コンテナーを使用した Web アプリケーションのホスティング (Etherpad ラボ 1))
    ウェルカム画面 (アーキテクチャー・ラボ: コンテナーを使用した Web アプリケーションのホスティング (Etherpad ラボ 1))
  5. この画面から新しいパッドを作成して、いろいろと試してください。この単純な Etherpad のセットアップでは、パッドのテキストをローカル・ファイルに保存するため、データはコンテナーの間で永続化されません。したがって、コンテナーをシャットダウンすると、パッドとテキストは削除されます。Etherpad ラボ 2 の「データベース・サービスを利用した Web アプリケーションのホスティング」では、Bluemix でホストされる実際のデータベースを使用するように Etherpad を構成して、データを保存することができます。

タスク 6. アプリケーションを Bluemix 内で実行する

アプリケーションをローカルで実行した後は、Bluemix 内で実行されているコンテナーにアプリケーションを公開して、インターネット上で実行することができます。Bluemix の中でコンテナーを実行するためのコマンドは以下のとおりです。いくつかの値はご使用の環境に固有の値で置き換える必要があるため、各コマンドのフォーマット設定を読んでから、これらのコマンドを順に実行してください。

ice --local push registry-ice.ng.bluemix.net/bluemix_residency/etherpad_bluemix
ice images

ice –local push コマンドはコンテナー・イメージを Bluemix に公開し、自分の組織のレジストリーに配置します。レジストリーのスコープは、IBM Containers サービス・インスタンスを作成したときに構成したレジストリー URL によって設定されています。

  • フォーマット:
    ice --local push registry-ice.ng.bluemix.net/ YOUR_REGISTRY_URL / YOUR_REMOTE_IMAGE_NAME
  • 例:
    ice --local push registry-ice.ng.bluemix.net/bluemix_residency/etherpad_bluemix

ice images コマンドは、公開されたイメージの URL と、Bluemix にプッシュした残りのイメージに関連する、他のデータを出力します。

以下に、ice images コマンドの出力例を記載します。出力されるフィールドには、Bluemix にプッシュされたイメージごとに生成される、実際の一意の ID が示されます。

ice images コマンドの出力
ice images コマンドの出力例 (アーキテクチャー・ラボ: コンテナーを使用した Web アプリケーションのホスティング (Etherpad ラボ 1))
ice images コマンドの出力例 (アーキテクチャー・ラボ: コンテナーを使用した Web アプリケーションのホスティング (Etherpad ラボ 1))

出力には、先ほどの ice --local push コマンドで Bluemix にプッシュした etherpad_bluemix イメージがあること、そしてその etherpad_bluemix イメージの名前と IBM によって提供されている他の 2 つのイメージとの違いに注意してください。エンド・ユーザーは、ベース・グローバル・ディレクトリーからしかプル操作を行うことができませんが、先ほどのコマンドのフォーマットを使用することで、組織に限定されたリポジトリーに対してプッシュ操作 (またはプル操作) を行うことができます。

今度は、以下の ice run コマンドを実行することで、Bluemix 上で実行されるコンテナー・インスタンスを作成します。

ice run -p 9080 --name etherpad_01 registry-ice.ng.bluemix.net/bluemix_residency/etherpad_bluemix:latest

コンテナー名を指定するパラメーターは、etherpad_01 から新規コンテナーの作成時に選択するコンテナー名に変更する必要があります。イメージ名とは異なり、コンテナー名を完全な URL でスコープ設定する必要はありません。コンテナー名は、実行中のコンテナーを識別しやすくするためだけに使用されるものだからです。名前は、ご使用の IBM Containers サービス・インスタンス内で実行中のコンテナー全体で一意である限り、単純なストリングにして構いません。また、registry-ice.ng.bluemix.net/bluemix_residency/etherpad_bluemix:latest についても、自分用のイメージ URL で置き換える必要があります。URL の末尾にある :latest タグは、そのイメージに複数のバージョンがある場合、最新のバージョンを実行するように指定します。-p パラメーターを指定すると、IBM Containers サービス内で実行されるコンテナーの要求ポートが公開されます。このパラメーターは、コンテナー上でアクセスできるようにしたい各ポートに対して指定する必要があります。

  • フォーマット:
    ice run -p PORT_TO_EXPOSE --name UNIQUE_CONTAINER_NAME registry-ice.ng.bluemix.net/ YOUR_REGISTRY_URL / YOUR_REMOTE_IMAGE_NAME :latest
  • 例:
    ice run -p 9080 --name etherpad_01 registry-ice.ng.bluemix.net/bluemix_residency/etherpad_bluemix:latest

ice run コマンドによって一意のコンテナー ID (CID) が返されるので、そのコンテナーに対して実行されるコマンドでは、この CID を使用します。以下の例では、CID は dd489740-ffff-4c8f-9117-d94cd147f122 となっているので、これを自分のコンテナー用の CID で置き換えてください。

Web アプリケーションに接続するには、その前に、アプリケーションにフローティング (浮動) パブリック IP アドレスを割り当てる必要があります。フローティング・パブリック IP アドレスは、ice ip request コマンドを実行すると割り当てられます。以下の例では、129.0.0.0 の部分を ice ip request コマンドから返された IP アドレスで置き換えてください。

ice ip request
ice ip bind 129.0.0.0 etherpad_01

このラボでは Etherpad をポート 9080 でホストしているため、ブラウザーで http://129.0.0.0:9080/ のような URL (129.0.0.0 の部分は ice ip request コマンドを実行して返された IP アドレスで置き換えます) を開くことで、実行中の Etherpad アプリケーションをテストすることができます。

お使いのアカウントでは、無料で取得できるパブリック IP アドレスは 2 つに限られるため、使用していない IP アドレスはアンバインドしてください。以下の例では、129.0.0.0 の部分を ice ip request コマンドを実行して返された IP アドレスで置き換え、dd489740-ffff-4c8f-9117-d94cd147f122 を自分のコンテナー用の CID で置き換える必要があります。

ice ip unbind 129.0.0.0 etherpad_01

実行中のコンテナーの CID や、公開されたイメージ名を参照するには、Bluemix ダッシュボードで「Create A Container (コンテナーの作成)」ビューをクリックするか、以下の ICE コマンドを使用して実行中のコンテナーと公開されたイメージをそれぞれ表示します。

ice ps
ice images

Bluemix 上で実行中のコンテナー・インスタンスを停止または削除する

ベスト・プラクティスに従って、アプリケーションが Bluemix 上で実行中になったら、テストに使用したローカル・コンテナーを停止 (オプションで削除) する必要があります。それには、以下のコマンドを実行します。

まず、実行中の Docker コンテナー・インスタンスを見つけます。

ice --local ps

次に、コンテナー ID を指定して Docker コンテナー・インスタンスを停止します。コンテナー ID は、先ほどのコマンドの出力として入手できます。

ice --local stop CID

最後に、Docker コンテナー・インスタンスを完全に削除するには (これはオプションのステップです。今後のラボに従うには、停止するだけで構いません)、同じくコンテナー ID をパラメーターとして指定して、以下の削除コマンドを実行します。

ice --local rm CID

エラーのない状態で今後のラボを進めていくためには、各ラボを完了する時点で、ローカルで実行されているすべての Etherpad コンテナーを停止してください。

次のステップ

このシリーズの残りのラボを続けてください。


ダウンロード可能なリソース


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Web development
ArticleID=1005877
ArticleTitle=アーキテクチャー・ラボ: コンテナーを使用した Web アプリケーションのホスティング (Etherpad ラボ 1)
publish-date=05212015