OpenStack プライベート・クラウド用の Linux イメージと Windows イメージを作成する

OpenStack イメージ作成の新しい方法

この記事では、OpenStack クラウド・オペレーティング・システムを使用して構築されたプライベート・クラウド用に、Linux イメージと Windows イメージを作成する新しい方法を提案します。OpenStack 環境用のイメージを作成するために現在採られている方法は、面倒で時間がかかります。そこで著者たちは、プライベート・クラウドのオペレーターとエンド・ユーザーが今までよりも迅速かつ容易にイメージを作成するためのオンラインのセルフサービス方式を提案します。

Cheng Long Liu, Advisory IT Specialist, IBM

Cheng Long Liu photoCheng Long Liu は、仮想化およびクラウド・コンピューティングにおけるアドバイザリー IT スペシャリストです。IBM China Development Lab で働く彼は、IT-as-a-Service チームのクラウド・サービスおよびイノベーション・テクノロジーのキー・スペシャリストであり、ラボの内部ユーザー用に VMware vSphere、IBM SmartCloud Provisioning v2.1、および OpenStack をデプロイしています。



Zhang Hua, Staff Software Engineer, IBM

author photoZhang Hua は、IBM China Development Lab で働くスタッフ・ソフトウェア・エンジニアです。彼は、交通および運輸の標準に関係するプロジェクトに従事しており、データベース、Java、SOA、Web 2.0、および .NET での開発経験があります。関心がある分野としては、Web、検索エンジン、マルチメディア処理技術があります。彼は、清華大学のコンピューター科学で修士号を取得しており、8 年に及ぶソフトウェア開発経験があります。



2014年 5月 22日

オープンソースの OpenStack クラウド・オペレーティング・システムは、あらゆるタイプのクラウド・コンピューティングに対応する、充実した機能と高いスケーラビリティーを備えたプラットフォームです。いくつかのパブリック・クラウド・サービスは、OpenStack をベースとしています。同様に、多くの組織内部のプライベート・クラウド実装にも OpenStack がベースとして使用されていますが、OpenStack のプライベート・クラウド向け機能は、まだ十分に揃っているとは言えません。特に開発用の環境やテスト用の環境となると、十分ではありません。そのため、一例を挙げると、イメージを作成するプロセスが単純でなかったりします。そこで、この記事では OpenStack プライベート・クラウド用のイメージを作成するための新しい改善された方法を提案します。私たちはこの新しい方法を QEMU/KVM プラットフォームで検証しましたが、理論上は、他のハイパーバイザー・プラットフォームにもこの方法を適用することができます。

新しい方法を紹介する前に、現在 OpenStack ではどのようにイメージが作成されるのか、その概要を説明します。

OpenStack でイメージを作成する現在の方法

OpenStack で Linux または Windows のイメージを作成するプロセスには、時間がかかるステップが複数あります。

Linux ベースのイメージ

公式の「OpenStack Virtual Machine Image Guide」では、OpenStack クラウドで Linux ベースのイメージを完全に機能させるために満たさなければならない 7 つの要件を詳しく説明しています (そのうちのいくつかの条件は、cloud-init パッケージをインストールして満たすことができます)。このイメージ・ガイドでは、使用しようとしている OpenStack の機能を確実にサポートするイメージを作成するには、これらの要件について詳しく説明しているセクションを読むよう、ユーザーにアドバイスしています。

Linux イメージは、特定のディストリビューションに対応した VMBuilder、Oz、imagefactory などのツールを使用して作成することも、自ら手作業で作成することもできます。どの方法を使用するかに関わらず、独自の Linux イメージを作成するには、以下のものが用意されていなければなりません。

  • OS インストール CD/DVD、または ISO イメージ・ファイル
  • KVM/QEMU ハイパーバイザーが有効にされている Linux マシン (ディストリビューションによっては、virt-manager/virt-viewer GUI ユーティリティーが必要です)
  • OS に対応した cloud-init または同等の自作のスクリプト
  • イメージを変更するためのユーティリティー (guestfishguestmountvirt-* などのツール)

必要条件がすべて満たされると、以下に要約するステップに従って、独自の Linux イメージの作成を開始することができます。

  1. virt-manager または virt-install を使用して、仮想マシン (VM) を作成し、OS をインストールします。
  2. ユーザーそれぞれの要件を満たすように OS を構成し (例えば、必要なミドルウェアをインストールするなど)、cloud-init または同等のスクリプトをインストールして OpenStack の要件を満たします。
  3. guestfishguestmount、または virt-* を使用して、OpenStack の要件を満たすようにイメージを変更します。
  4. 新しく作成したイメージを OpenStack イメージ・サービスにアップロードして、イメージを検証します。

Windows ベースのイメージ

OpenStack の Webサイトには、Windows ベースのイメージを作成する詳細な例は、まだ記載されていません。ただし、作成する Windows ベースのイメージが完全に機能するには、少なくとも以下の作業を行う必要があります。

  • VirtIO ドライバーをインストールします。
  • RDP (Remote Desktop Protocol) を有効にして、ファイアウォールを通過するように構成します。
  • ファイアウォールを通過するように ICMP (Internet Control Message Protocol) を構成します。
  • ディスクをパーティション化して、ブートのルート・パーティションをサイズ変更します (cloudbase-init を使用)。
  • ユーザー・データとその他のメタデータを処理します (cloudbase-init を使用)。
  • Windows のシステム準備ツール (Sysprep) を有効にして、ゲスト OS をカスタマイズできるようにします。

プライベート・クラウドを使用するほとんどのケースでは、上記最後の 2 つの要件はオプションです。またブート時に (スクリプトを使用するか、手作業で) ディスクをパーティション化したり、ルート・パーティションのサイズを変更したりすることができます。ただし、OpenStack クラウドで Windows イメージを機能させるには、VirtIO ドライバーをインストールする必要があります。さらに、VirtIO-Win ドライバー・パッケージを入手する必要もあります。

最小要件を満たした後、Windows イメージを作成するプロセスは、以下のとおりです。

  1. IDE (Integrated Drive Electronics) ディスクと AMD li>net32 または Realtek rt8139 ネットワーク・インターフェース・カード (NIC) を使用して VM を作成します。
  2. OS をインストールします。
  3. ユーザーそれぞれの要件を満たすように OS を構成し (例えば、必要なミドルウェアをインストールするなど)、cloudbase-init または同等のスクリプトをインストールして OpenStack の要件を満たします。
  4. VM をシャットダウンします。
  5. 小さいサイズの VirtIO ディスクと VirtIO NIC を追加します。
  6. VM を起動して、VirtIO ディスク用と VirtIO NIC 用の VirtIO ドライバーをインストールします。
  7. VMを再起動して、OS を確認してから VM をシャットダウンします。
  8. 作成したイメージを Oli>nStack イメージ・サービスにアップロードして、イメージを検証します。

あるいは、以下の手順に従うこともできます。

  1. 以下の構成要素を使用して VM を作成します。
    • VirtIO ディスク
    • PCnet32 または rt8139 NIC
    • VirtIO ディスク・ドライバー追加用 CD-ROM (Windows Vista 以降、または Windows Server 2008 以降の Windows の場合)、または VirtIO ディスク・ドライバー追加用フロッピー (Windows Server 2003 R2 やそれ以前の Windows の場合)
  2. 必要な VirtIO ディスク・ドライバーと一緒に OS をインストールします。
  3. ユーザーそれぞれの要件を満たすように OS を構成し (例えば、必要なミドルウェアをインストールするなど)、cloudbase-init をインストールするか、同等のスクリプトを実行して、OpenStack の要件を満たします。
  4. VM をシャットダウンします。
  5. VirtIO NIC を追加します。
  6. VM を起動して、VirtIO NIC 用の VirtIO ドライバーをインストールします。
  7. VMを再起動して、OS を確認してから VM をシャットダウンします。
  8. 作成したイメージを OpenStack イメージ・サービスにアップロードして、イメージを検証します。

欠点

OpenStack 用のイメージを作成する現在の方法は、いくつかの利点はあるものの (例えば、Linux ベースのイメージを作成する際に、さまざまなオープンソース・ツールを利用できます)、簡単ではありません。Windowsベースのイメージを作成する場合は、guestfish などのツールを使ってイメージを変更する必要がないため、Linux イメージを作成するプロセスよりも多少簡単なように思えますが、現時点では、OpenStack 用の完全な機能を備えた Windows ベースのイメージを作成するための自動化ツールはありません。従って、エンド・ユーザーまたはオペレーターがそのようなツールを自らの手で作成する必要があります。グローバリゼーション・チームのテスターまたは開発者が Windows イメージを必要とする場合、Windows イメージは言語ごとに異なるものでなければなりませんが、チームが何十もの言語を使用しているとなると、要求されたすべての言語の Windows イメージを用意するのは、クラウド・オペレーターにとっては不可能なことでしょう。

Linux イメージにしても、Windows イメージにしても、プライベート・クラウド用のイメージを作成するのは、時間がかかる作業となります。これは、エンド・ユーザーが作成する場合にのみ言えることではなく、経験を積んだクラウド・オペレーターが作成する場合にも言えることです。さらに、エンド・ユーザーがイメージを作成するために必要なリソースが組織にないことも考えられます (例えば、Linux イメージの作成に必要な追加の KVM/QEMU ハイパーバイザーなど)。そのような状況では、エンド・ユーザーから要求されたすべてのイメージを作成するのは、クラウド・オペレーターにとって相当な負担がかかります。

しかも、新しいイメージを OpenStack イメージ・サービスにアップロードする必要もあります。イメージ・ソースと OpenStack イメージ・サービスとの間のネットワークのパフォーマンスによっては、このプロセスにかなりの時間がかかります。同じ理由から、新しいイメージを繰り返し検証するのにも、かなりの時間がかかることがあります。


OpenStack イメージを作成する方法として新たに提案する方法

OpenStack のユーザーがオンラインでイメージを作成できるようになれば、ユーザーは今までより遥かに簡単に、それぞれのニーズを満たすイメージを作成することができます。私たちは、イメージを作成する新たな方法として、クラウド・サービスが提供する OpenStack ダッシュボードを使用して、ユーザーが新しいイメージをオンラインで作成する方法を提案します。この方法でイメージを作成できれば、エンド・ユーザーが追加のハイパーバイザーを必要とすることも、作成したイメージを自分で OpenStack イメージ・サービスにアップロードする必要もなくなります。この場合、必要なのは OS インストール CD/DVD ISO イメージ・ファイルだけです。

概念設計

概念的には、エンド・ユーザーが以下の作業を行うことが OpenStack 用の新しいイメージを作成する理想的なプロセスとなります。

  1. OS インストール用 CD/DVD ISO イメージ・ファイルを OpenStack イメージ・サービスにアップロードします。
  2. アップロードした ISO イメージから新規インスタンスを起動します。
  3. OpenStack ダッシュボードの VNC (Virtual Networking Computing)/SPICE (Simple Protocol for Independent Computing Environments) コンソールから、OS をインストールします。
  4. 特殊なニーズに応じて必要な構成を行い、必須のソフトウェア・パッケージをインストールします。
  5. OpenStack が必要とする変更を手作業で加えるか、サービス・オペレーターが提供するスクリプトを実行します (例えば、cloud-init をインストールするスクリプト、公開 SSH 鍵を取得するスクリプト、SSHD リモート・ログイン/RDP を有効にするスクリプト、等々)。
  6. インスタンスのスナップショットを取ります。
  7. 必要に応じて、スナップショットに対して glance image-update コマンドを実行して、スナップショットをイメージに変換して他のメタデータを追加します。

前提条件

この新しいイメージ作成方法を成功させるには、以下の条件を満たす必要があります。

  • 実際に使えるダッシュボードまたは Web UI が、すべてのエンド・ユーザーに利用可能になっていること。
  • VNC プロキシーまたは SPICE プロキシーが正常に機能し、すべてのエンド・ユーザーに利用可能になっていること。
  • cloud-init または同等のスクリプト・ツールのリポジトリーが、すべてのエンド・ユーザーに利用可能になっていること。
  • VirtIO-win ドライバーの ISO イメージが OpenStack イメージ・サービスにあり、すべてのエンド・ユーザーに利用可能になっていること。

次は、この新しい方法の実現可能性を実際の例で示します。


実現可能性の調査

この新しい方法の最も重要な 2 つの側面は、ISO イメージをサポートする方法と、ISO イメージから起動されるインスタンス用にブロック・デバイスをアセンブルする方法です。

現在の ISO イメージのサポート

ISO イメージは、OpenStack でサポートされています。ISO イメージからのインスタンスの起動もサポートされていますが、ISO イメージに含まれるゲスト OS を ISO イメージから起動されたインスタンスにインストールするという部分に関しては、十分にサポートされていません。以下の厳しい条件が満たされていなければ、インストールは成功しません。

  • ISO イメージに含まれるゲスト OS の VirtIO デバイス・ドライバーが、デフォルトで有効にされること。
  • 一時ディスクのフレーバー (仮想ハードウェア・テンプレート) が設定されていて、そのサイズがゲスト OS の要件を満たすこと。
  • ダッシュボードと OpenStack novncproxy サーバーが正常に稼働中であること。

上記のすべての条件が満たされていれば、ISO イメージに含まれるゲスト OS を、この ISO イメージから起動されたインスタンスの一時ディスクに正常にインストールすることができます。もちろん、他のインスタンスの場合と同じく、ゲスト OS の下で作業することもできます。しかし、OpenStack の現在のインスタンス・スナップショット・メカニズムでは、インスタンスを正常にインスタンス・スナップショットまたはイメージに変換することはできません。変換したとしても、インスタンス・スナップショットに含まれるのはインスタンスのルート・ディスクだけで、一時ディスクやボリュームなどの他のブロック・デバイスは無視されてしまいます。

インスタンス・ブロック・デバイス用の現在のアセンブリー・ワークフロー

図 1 に、ISO イメージから KVM/QEMU インスタンスをブートする際の OpenStack Nova でのブロック・デバイスのアセンブリー・ワークフローを示します。

図 1. ブロック・デバイスをアセンブルするための現在のワークフロー
ブロック・デバイスをアセンブルするための現在のワークフロー

図 1 のワークフローでは、以下の処理が行われます。

  1. Nova が Glance から ISO イメージを取得し、この ISO イメージを VM インスタンスのルート・ディスクとして設定し、デバイス・タイプとして CD-ROM を、バス・タイプとして IDE を設定します。
  2. Nova が一時ディスクを作成し、この一時ディスクを VM インスタンスの 2 番目のディスクとして設定し、デバイス・タイプとしてディスクを、バス・タイプとして VirtIO を設定します。ただし、このステップが行われるのは、一時ディスクのサイズがインスタンスのフレーバーに設定されている場合のみです。
  3. ユーザーがルート・ディスク (インスタンスの CD-ROM) に含まれるゲスト OS を一時ディスク (インスタンスの 2 番目のディスク) にインストールして、VNC を使用してステップバイステップでゲスト OS を構成します。
  4. ユーザーがこの VM インスタンスからスナップショットを作成し、Nova がそのスナップショットを Glance サービスに保存します。

このワークフローは、新しい VM イメージを一から作成するには有効なように思えますが、このワークフローで取得されるイメージは、元の ISO イメージのコピーです。その理由は、スナップショットに含まれるのはルート・ディスク (インスタンスの最初のブロック・デバイス。つまり実際には、インスタンスが ISO イメージから起動された場合はインスタンスの CD-ROM) だけで、一時ディスクは無視されるためです。従って、現在の OpenStack では、ISO イメージからインスタンスを起動して、一時ディスクが構成された起動済みインスタンスに、ISO イメージに含まれる OS をインストールすることは可能ですが、OS がインストールされた一時ディスクのスナップショットを取ることはできません。この問題に対処するには、インスタンスのブロック・デバイスのアセンブリー・ワークフローを調整する必要があります。

新たに提案するアセンブリー・ワークフロー

適切なサイズに設定された一時ディスクを作成し、その一時ディスクが必ず ISO イメージから起動されたインスタンスのルート・ディスクとして設定されるように、ブロック・デバイスのアセンブリーを変更することができます。このように変更した後、インスタンス・スナップショットに含まれるルート・ディスクは、まさに目的どおり、OS がインストールされた一時ディスクになります。

図 2 に、libvirt ドライバーに変更を加えた後 (これについては、この記事の「概念実証」のセクションで説明)、ISO イメージからインスタンスをブートした場合のブロック・デバイスのアセンブリー・ワークフローを示します。

図 2. ブロック・デバイスをアセンブルするための変更後のワークフロー
ブロック・デバイスをアセンブルするための変更後のワークフロー

以下に、ISO イメージからインスタンスを起動する際のブロック・デバイスのアセンブリー・ワークフローを変更する方法を記載します。

  1. Nova が VM ディスク・ファイルを作成し、これを VM インスタンスのルート・ディスクとして設定します。デバイス・バスは、デフォルトで VirtIO に設定されます。
  2. Nova が、Glance からゲスト OS の ISO イメージを取得し、これを 2 番目のディスク・デバイス (CD-ROM) として設定します。
  3. Nova が、Glance から VirtIO ドライバーの ISO イメージを取得し、これを 3 番目のディスク・デバイス (別の CD-ROM) として設定します。
  4. ユーザーが、2 番目のディスク・デバイス (最初の CD-ROM) からゲスト OS をインストールし、必要に応じて構成します。
  5. VirtIO ドライバーがデフォルトでゲスト OS に含まれない場合は、3 番目のディスク・デバイス (2 番目の CD-ROM) を使用してゲスト OS 用の VirtIO ドライバーをインストールします。
  6. ユーザーがこのインスタンスのスナップショットを作成し、Nova がそのスナップショットを Glance サービスに保存します。

現在の ISO イメージのサポート」で説明したように、インスタンス・スナップショットに含まれるのは、ルート・ディスクのタイプに関わらず、インスタンスのルート・ディスクだけです。変更後のアセンブリー・ワークフローでは、ルート・ディスクは Nova によって作成された新しいディスク・ファイルになります。このファイルには、OS イメージである CD-ROM (インスタンスの 2 番目のディスク) からインストールされたゲスト OS が含まれます。

私たちが考えたとおり、最終的な結果は、元の ISO イメージのコピーではなく、OS ISO イメージからインストールされた新規インスタンスのインスタンス・スナップショットになります。


概念実証

この新しいイメージ作成方法が、私たちが設計したとおりに機能することを確実にするために、Nova コード (主に libvirt ドライバー) にいくつかの変更を加えました。関連するコードを入手するには、「ダウンロード」を参照してください。変更した Python モジュールは、libvirt/driver.py と libvirt/blockinfo.py です。これらのファイルには、変更したクラス・メソッドとインスタンス・メソッドを見分けられるように、コメントを追加しておきました。

概念実証に使用した環境は、以下の構成要素からなります。

ハードウェア:

  • 2 U ラック・サーバー
  • 4 コア Xeon プロセッサー (x2)
  • 8GB の RAM (x12):
  • RAID10 が構成された 900GB の SAS ハード・ディスク (x4)
  • 1Gps Ethernet カード (x4)

ソフトウェア:

  • Red Hat Enterprise Linux 6 アップデート 4 (ハイパーバイザーとして使用)
  • RDO Grizzly リリース

変更したコードを、RDO Grizzly のオールインワン環境、RDO Grizzly のマルチノード・インストール済み環境、および公式 OpenStack Grizzly リリースのそれぞれでテストしました。


テストの実行と結果

このセクションでは、単純なテスト・プロセスについて説明し、この新しい方法で VM イメージを作成するために変更後の Nova を使用して実行したテストの例を記載します。

テスト・プロセス

テスト・プロセスは以下のとおりです。

  1. Glance に応じた OS ISO イメージを作成します。
  2. 既存のフレーバーを調べて、ルート・ディスクのサイズが望みどおりのサイズであることを確認します。該当するフレーバーがない場合は、新しいフレーバーを作成します。
  3. 該当するフレーバーで、この OS ISO イメージからインスタンスを起動します。
  4. インスタンスが起動したら、ダッシュボードの VNC コンソールで、画面上のインストール手順に従って OS のインストールを完了します。
  5. 必要に応じてアプリケーションをインストールし、OpenStack の要件に従って OS を構成します (cloud-init または同等のスクリプトのインストール、SSHD リモート・ログイン/RDP サービスの有効化など)。
  6. この新しくインストールしたインスタンスのスナップショットを作成します。
  7. スナップショット情報を更新してイメージ・タイプをイメージに変更するために、glance image-update を実行するか、ダッシュボードから (ダッシュボードに該当する機能が提供されている場合) この作業を行います。

テスト結果

libvirt ドライバーに変更を加えた後の、ISO イメージから起動したインスタンスのブロック・デバイスはリスト 1 に示すとおりです。

リスト 1. ISO イメージから起動したインスタンスのブロック・デバイス・マッピング
<disk type='file' device='disk'>
 <driver name='qemu' type='qcow2' cache='none'/>
 <source file='/var/lib/nova/instances/290124e3-a267-4223-bd69-661fac2035eb/disk.newos'/>
 <target dev='vda' bus='virtio'/>
 <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>
<disk type='file' device='cdrom'>
 <driver name='qemu' type='qcow2' cache='none'/>
 <source file='/var/lib/nova/instances/290124e3-a267-4223-bd69-661fac2035eb/disk'/>
 <target dev='hda' bus='ide'/>
 <readonly/>
 <address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<disk type='file' device='cdrom'>
 <driver name='qemu' type='qcow2' cache='none'/>
 <source file='/var/lib/nova/instances/290124e3-a267-4223-bd69-661fac2035eb/disk.virtio'/>
 <target dev='hdb' bus='ide'/>
 <readonly/>
 <address type='drive' controller='0' bus='0' target='0' unit='1'/>
</disk>

表 1 に、複数のメインストリーム OS でのテスト結果を記載します。

表 1. テスト結果
ゲスト OS結果
Windows XP失敗*
Windows Server 2003 R2失敗*
Windows 7成功
Windows 8成功
Windows Server 2012成功
RHEL5.9成功
RHEL6.4成功
SLES10 sp4成功
SLES11 sp3成功
*注: Windows XP と Windows Server 2003 R2 でのテストが失敗した理由は、VirtIO ドライバーのフロッピー・ディスクが見つからなかったためです。その根本原因は、Windows Server 2003 R2 またはそれ以前の Windows では、フロッピー・ディスクからの追加ディスク・ドライバーのロードしかサポートされないことにあります。この記事では、図 2 に示されているように VirtIO ドライバー追加用 CD-ROM だけを追加していますが、古いバージョンの Windows の場合には、ブロック・デバイスのアセンブリー・ワークフローにさらにフロッピー・ドライバーを追加することもできます。

まとめ

この記事で紹介した、イメージを作成する新しい方法には、以下の利点があります。

  • OpenStack 用の新規イメージを簡単に作成することができます。
  • 新しく作成されたイメージを簡単に検証することができます。
  • すべてのエンド・ユーザーが、セルフサービス・メカニズムを利用できます。

欠点としては、以下の点が挙げられます。

  • イメージで一部の機能 (特に、ディスクのパーティション化と、ブート時のルート・パーティションのサイズ変更) がサポートされない可能性があります。
  • Windows Server 2003 R2 またはそれより古いバージョンの Windows Server はサポートされません (ただし、アセンブリー・ワークフローをもっと複雑にして、フロッピー・ドライバーをサポートするようにすれば、古いバージョンの Windows をサポートできるようになります)。
  • VirtIO デバイス・ドライバーをサポートしていない古いバージョンの Linux はサポートされません。

これまでのところ、ほとんどの OpenStack ベースのパブリック IaaS クラウド・サービスでは、ベース・イメージの中に固定サイズのルート・ディスクを備えたインスタンスと、(ボリューム・サービスを通じた) そのインスタンス用の追加ディスク・スペースを提供しています。プライベート・クラウドの場合、インスタンスに関する要件の大部分は、インストールするミドルウェア、ゲスト OS のバージョン/エディション、インスタンス・フレーバーなどに焦点を置いたものです。ディスク・サイズの要件は、パブリック・クラウド・サービスの場合と同じく、固定の平均ルート・ディスク・サイズと十分なボリュームを提供すれば満たすことができます。従って、ほとんどのプライベート・クラウドでは、ディスクをパーティション化して、ブート時にルート・パーティションをサイズ変更できることは必須になりません。

OpenStack は、オープソースのクラウド・オペレーティング・システムのグローバル・プラットフォームとして高い評判を得るまでに成長しました。OpenStack を使用すると、各種のクラウド・ソリューションは、高いスケーラビリティーと豊富な機能を備えたものとして、簡単に実装できるようになります。私たちがこの記事で説明した作業が、OpenStack プラットフォームをベースに新しい機能を実装できること、そして OpenStack は単なるソフトウェア製品ではなく、オープンで柔軟なフレームワークであることを証明しています。


ダウンロード

内容ファイル名サイズ
Sample codesample_code.zip39KB

参考文献

学ぶために

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

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、Wiki を調べることができます。

コメント

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=Cloud computing, Open source, Linux
ArticleID=971159
ArticleTitle=OpenStack プライベート・クラウド用の Linux イメージと Windows イメージを作成する
publish-date=05222014