Blue Flower

    こんにちは、@opt_Hohenheimです。

    きょうは、CloudStack4のインスタンスにクラウドストレージ(owncloud)環境を

    入れてみようと思います。

 

 1.CloudStack4のリソース状況を確認する

 CloudStack4のリソース状況4 

 

    ダッシュボードでリソースの空き状況を確認します。

    今回使うのは、メモリ2Gbyte CPU 2GHz ディスク100Gbyteくらい使いますので

    そのくらいの空きがあればいいです。ストレージ容量をたくさん使う方は、適宜

    変更してください。

 

 2.CloudStack4のisoテンプレートにcentos6を登録する

    次に今回クラウドストレージ環境をインストールするインスタンス用のisoテンプレートを用意します

    ここでは、CentOS6を用意して対応します。

    isoイメージは、たとえば、理研のリポジトリを使います。

 

    次のように準備完了になればOkです。

 

 

 3.登録したisoテンプレートのcentos6をもってインスタンスをデプロイする 

 

    2.で登録したisoテンプレートをもって、メモリ2GByte CPU2GHz ディスク100Gbyteにて

    仮想マシンのインスタンスをデプロイします。

    デプロイ後、/etc/sysconfig/network-scripts/ifcfg-eth0のファイル内

    onboot=noをonboot=yesに変えて以下のコマンドを実行します。

 

    ついでに以下ののpingが通ることを確認しておきます。

# service network restart
# ping www.yahoo.co.jp

 

 4.デプロイしたcentos6のインスタンスにクラウドストレージ環境をインストール

    それでは、CloudStack4で払い出したcentos6のインスタンスにクラウドストレージ(owncloud)をインストールしましょう。

    CloudStack4で払い出したcentos6のインスタンスにloginして、以下の手順でOkです。

# yum upgrade -y
# yum -y install wget
# yum -y install epel-release
# cd /etc/yum.repos.d
# wget http://rpms.famillecollet.com/enterprise/remi.repo
# cd /etc/yum.repos.d/
# wget http://download.opensuse.org/repositories/isv:ownCloud:community/CentOS_6/isv:ownCloud:community.repo
# yum -y --enablerepo=remi,remi-php56 install owncloud mysql-server php-mysql
# chkconfig httpd on
# chkconfig mysqld on
# service httpd start
# service mysqld start
# service iptables stop
# chkconfig iptables off
# mysql -u root
mysql> CREATE DATABASE owncloud;
mysql> GRANT ALL ON owncloud.* to 'owncloud'@'localhost' IDENTIFIED BY 'owncloud';

 

   5.デプロイしたインスタンスのポート設定

    ポート転送ですが、管理用にsshポート22とowncloudのマネージメントコンソールポート80を設定します。

    筆者は、ポート転送とファイアウォールの2重設定が面倒だったので、以下のAndroidアプリで設定しました。(筆者の都合ですいません)

CloudManagerAdvance絶賛発売中!!

 

    このアプリでPortFoward設定すると自動でファイアウォールも設定してくれます。

     CloudStack4のコンソールでも設定出来ますので、そちらでも結構です。

    その場合、ポート転送とファイアウォールに22番と80番を設定します。

 

   6.クラウドストレージ(owncloud)のコンソールにアクセスする

    ネットワークのポート転送等を設定したNATのIPアドレスに対してブラウザで以下のアドレスにアクセスをします。

http://[IPアドレス]/owncloud

 

    すると、以下のコンソール画面が表示されます。

owncloud初期画面1

    初回だけ、管理アカウントの設定になります。

    設定するとloginされ、以下の画面が1度だけ表示されます。

    PCとスマートフォンのクライアントアプリの案内です。

 owncloud初期画面

 

 以上です。

最後までお読みいただきありがとうございました。

 

 


CloudManagerAdvance 2.2 以上
カテゴリ: ツール
Google Playで詳細を見る

 

 

 

    こんにちは、@opt_Hohenheimです。

    きょうは、CloudStack4のインスタンスにheat環境を用意して

    heatテンプレートを動かしてみようと思います。

 

 1.CloudStack4のリソース状況を確認する

 CloudStack4のリソース状況 

 

    ダッシュボードでリソースの空き状況を確認します。

    今回使うのは、メモリ2Gbyte CPU 2GHz ディスク20Gbyteくらい使いますので

    そのくらいの空きがあればいいです。

 

 2.CloudStack4のisoテンプレートにcentos7を登録する

     次に今回heat環境をインストールするインスタンス用のisoテンプレートを用意します

    今回は、packstackを使ってCloudStack4のインスタンスにOpenStack heat環境を用意

    するのですが、最近Junoリリースと共にpackstackがRHEL7ベースの動作環境になった

    ので、ここでは、CentOS7を用意して対応します。

    isoイメージは、ここの理研のリポジトリを使います。

 

    次のように準備完了になればOkです。

 

 

 3.登録したisoテンプレートのcentos7をもってインスタンスをデプロイする 

 

    2.で登録したisoテンプレートをもって、メモリ2GByte CPU2GHz ディスク20Gbyteにて

    仮想マシンのインスタンスをデプロイします。

    デプロイ後、/etc/sysconfig/network-scripts/ifcfg-ens3のファイル内

    onboot=noをonboot=yesに変えて以下のコマンドを実行します。

 

    ついでに以下ののpingが通ることを確認しておきます。

# service network restart
# ping www.yahoo.co.jp

 

 4.デプロイしたcentos7のインスタンスにOpenStack heat環境をインストール

    それでは、CloudStack4で払い出したcentos7のインスタンスにOpenStack heatをインストールしましょう。

    CloudStack4で払い出したcentos7のインスタンスにloginして、以下の手順でOkです。

# yum -y update
# yum -y install http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm
# yum install -y https://rdo.fedorapeople.org/rdo-release.rpm
# yum install -y openstack-packstack
# packstack --allinone --use-epel=y --os-heat-install=y --os-heat-cfn-install=y --os-ceilometer-install=n

    インストールが終わるとhomeディレクトリ直下にkeystonerc_adminとkeystonerc_demoができているのが確認できると思います。

    adminアカウントとdemoアカウント用の環境変数です。

    次のようにします。(アカウントadminを使う場合) 

# . ~/keystonerc_admin

    では、さっそくheatコマンドが使えるか試してみましょう。

# heat stack-list
+----+------------+--------------+---------------+ | id | stack_name | stack_status | creation_time | +----+------------+--------------+---------------+ +----+------------+--------------+---------------+

    heatテンプレートは、stackという単位で管理されて、1つのテンプレートでデプロイされたリソースは、stackを消すと

    stackに紐づくすべてのリソースがリソースプールに戻ります。

    いまは、何もテンプレートを実行していないためstackリストは、空です。しかしながらheatの空リストがかえっているので

    heat環境は、できていると考えられます。

 

 5.glanceマシンイメージを用意する

    heatテンプレートは、インスタンスをデプロイする際glanceのマシンイメージを使います。

    そこでCloudStack4とそのインスタンスのOpenStackがたまたまkvmのハイパーバイザを使用している環境だったので

    CloudStack4のデフォルトのcentos5のマシンイメージのスナップショットを取得し、それをダウンロード(QCOW2)して

    OpenStackのインスタンスに転送します。

    インスタンスメニューで「表示・ボリューム」を選択します。

    下図、「ボリュームのダウンロード」を選択

    下図、ダウンロードリンクをクリックして、ダウンロードする

 

    OpenStackのHorizon(GUI)でglanceのマシンイメージも登録できますが

    uploadに時間がかかるものは、Horizonがセッションタイムアウトして途中で切れてしまいます。

    なのでマシンイメージは、OpenStackのインスタンスにsftpなどで転送し、glanceコマンドで登録します。

    上記ダウンロードしたマシンイメージをOpenStackのインスタンスに転送したら、下記glanceコマンドでマシンイメージを登録します。

[root@localhost ~(keystone_admin)]# glance image-create --name centos5-image --disk-format qcow2 --container-format bare --is-public True --file ./centos5.qcow2
+------------------+--------------------------------------+
| Property         | Value                                |
+------------------+--------------------------------------+
| checksum         | 00926eb83a373e38455232d05247b3aa     |
| container_format | bare                                 |
| created_at       | 2014-12-03T19:34:22                  |
| deleted          | False                                |
| deleted_at       | None                                 |
| disk_format      | qcow2                                |
| id               | 12f71527-7160-4956-a6ce-0610745094fc |
| is_public        | True                                 |
| min_disk         | 0                                    |
| min_ram          | 0                                    |
| name             | centos5-image                        |
| owner            | 36e79999f5ca494c9b2015723347ed53     |
| protected        | False                                |
| size             | 1711472640                           |
| status           | active                               |
| updated_at       | 2014-12-03T19:35:19                  |
| virtual_size     | None                                 |
+------------------+--------------------------------------+
[root@localhost ~(keystone_admin)]#

    ここで、ついでにセキュリティグループを登録しておきましょう。

    今回は、gitlabをデプロイするので80ポートとlogin等用に22ポートを開けておきます。

[root@localhost blog(keystone_admin)]# neutron security-group-create gitlabservers --description "security group for gitlabservers"
Created a new security_group:
+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field                | Value                                                                                                                                                                                                                                                                                                                         |
+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| description          | security group for gitlabservers                                                                                                                                                                                                                                                                                              |
| id                   | 0961ee55-3897-40ec-a1e4-c28cffd740ca                                                                                                                                                                                                                                                                                          |
| name                 | gitlabservers                                                                                                                                                                                                                                                                                                                 |
| security_group_rules | {"remote_group_id": null, "direction": "egress", "remote_ip_prefix": null, "protocol": null, "tenant_id": "36e79999f5ca494c9b2015723347ed53", "port_range_max": null, "security_group_id": "0961ee55-3897-40ec-a1e4-c28cffd740ca", "port_range_min": null, "ethertype": "IPv4", "id": "68a6b53a-1f00-4797-bfdc-144e2540e66b"} |
|                      | {"remote_group_id": null, "direction": "egress", "remote_ip_prefix": null, "protocol": null, "tenant_id": "36e79999f5ca494c9b2015723347ed53", "port_range_max": null, "security_group_id": "0961ee55-3897-40ec-a1e4-c28cffd740ca", "port_range_min": null, "ethertype": "IPv6", "id": "78810ddc-bf18-42c1-bf55-68365bc9b3b2"} |
| tenant_id            | 36e79999f5ca494c9b2015723347ed53                                                                                                                                                                                                                                                                                              |
+----------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
[root@localhost blog(keystone_admin)]# neutron security-group-rule-create --direction ingress --protocol tcp --port_range_min 80 --port_range_max 80 0961ee55-3897-40ec-a1e4-c28cffd740ca
Created a new security_group_rule:
+-------------------+--------------------------------------+
| Field             | Value                                |
+-------------------+--------------------------------------+
| direction         | ingress                              |
| ethertype         | IPv4                                 |
| id                | 534f1373-5af2-4d5b-86b8-1140738c7f86 |
| port_range_max    | 80                                   |
| port_range_min    | 80                                   |
| protocol          | tcp                                  |
| remote_group_id   |                                      |
| remote_ip_prefix  |                                      |
| security_group_id | 0961ee55-3897-40ec-a1e4-c28cffd740ca |
| tenant_id         | 36e79999f5ca494c9b2015723347ed53     |
+-------------------+--------------------------------------+
[root@localhost blog(keystone_admin)]# neutron security-group-rule-create --direction ingress --protocol tcp --port_range_min 22 --port_range_max 22 0961ee55-3897-40ec-a1e4-c28cffd740ca
Created a new security_group_rule:
+-------------------+--------------------------------------+
| Field             | Value                                |
+-------------------+--------------------------------------+
| direction         | ingress                              |
| ethertype         | IPv4                                 |
| id                | 5648579e-8f9b-40d6-a501-7dfb95fca7ab |
| port_range_max    | 22                                   |
| port_range_min    | 22                                   |
| protocol          | tcp                                  |
| remote_group_id   |                                      |
| remote_ip_prefix  |                                      |
| security_group_id | 0961ee55-3897-40ec-a1e4-c28cffd740ca |
| tenant_id         | 36e79999f5ca494c9b2015723347ed53     |
+-------------------+--------------------------------------+
[root@localhost blog(keystone_admin)]#

    ついでなので、heatでインスタンスをデプロイする際のnovaのkeypairを登録します。 

[root@localhost blog(keystone_admin)]# nova keypair-add git
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAwuQkPyg8YH/ueCCOrF1VIKP6zma2z+pD69q26Zu2xxW6Qpm3
jXrXhYJjsiOVzkOGBu5MMB+mtFokej9T8yGJxR1fmex1KuZGwiYUifbysQPpyMEo
JTMLNHbGgP1lXRFGQg2bvyLHpZfjuo0Kxp47zWOdGpTB0tUoTLASewy77NfpH5P1
zCKWn2+/g+OLfJAjUnLsUKvAUV5AcWuN7tQNX99uczYQ8OGpj+Hke5KXRIEKEiCl
56y9mWWtSfd+eNpY8757nC+YUnYgwoV2xMWoOIeuSZz/TK1+yIqh1e2ujbw1jYb6
qYtVfFtI6w5WG2/XDFGA5CjD4PJIXH5we8hJLQIDAQABAoIBAQCSaz6EKKF7yoGJ
xMQL4S70j939NZQBDrqqtq4XQkKGvd8q7DvH0lObXYOzMSL6TSajjGK3AQCInPSs
12klz7um2NObW9gHO+xLLrrdkCdzMEJy7hNQJ1Iyv02RWU7PJgxH0duCNQoTcdLI
s/A1mmnJfB5q+vnHgRd+zgWEZuPFIn1JI5DydQqf8nT+InIA6Goma6PcpXNJiN+h
bEQbtIOuHgxe4SA+XhDoXz36nxpi9idnKot6I5TwGRIiyHAJNAFwQdsSw6jHgzIi
zuVzI0OHcw5kzb9l0w1nK5ni58dTc4pi23eDjSE4VLGUPCAVjbOLlpPobbUDddeL
7AD65ZYNAoGBAOuuceSo5eWZ9IG9u0HGQbN8ItN5M59Mwj1LZ7xdiDaDYC16yx02
6wsQI+iX087npGRHjYg3lQz3V52muq5bAIQ+GKCPPUq7sGWaN1e1lVLjgK4VjtSf
GXlcppnHnoYxYftepe6RPNbiJb1JfFcUwuTx1QkPNJqHDicP4yIZUuqfAoGBANOx
ccsPkBVTwc/x/aG+3MIWHsuf8EvoTv5bvYFSMZygGlpSn7A3MW7C9Vw9RbSe2WFr
FXXK18TUNS4B/MS2C7sYovk4GOPIDUfzTYr4tADRfckonGDI3Kz0F7ptVYk6fro9
qAjXDoXlCIkC01WsvmDrtQN4dZ9yt/9+jcsqBESzAoGBAJKl0jKQsbRDLrQIJduQ
jFMtW9IwaWGm9noDUIIRxO7+ojrKXFZKVMhme6F/z4i/9Dd9mmB3DWSrBzaOhzx0
XYbryJEnb+Dvlpwx8FvAHjEcZHZt7Zj5gnVUpEmtv0MKuUgbJa6jarLettLoRdk9
juO8Ym2nq3i3rqO5rAAMt95LAoGAUCITWTKC8A/MhdKsl9WP60hEUAAzDgjaHh7M
FW/vp8JTN22fVS0PYUYbatcm08BtuRq3/ObT1oYdu1S1QiFHP4OL7Zr2kQLhRCMt
bzXFramfW84ro9dk8XNUqBVLE6842XcNbIs7zCNun66aIQxK5JVU6ANpQvpB/E0D
j6xQAVECgYBsuxQnq2kev2TTrR4ryYtrZ0GoUiwbe+Dzocwgj8KIag2QTf9yPCxu
oT4lTh2m1lTqzzKkzeJyKhItRJXd6+LjUc/7CMwD5qVgpWsOXhHNf5xoKIA1ZARV
gplSTfBe+NRA37mwCuUpYrnMO0BB75FDlozljLTmlFXqk839LdzZEQ==
-----END RSA PRIVATE KEY-----

[root@localhost blog(keystone_admin)]# nova keypair-list
+------+-------------------------------------------------+
| Name | Fingerprint                                     |
+------+-------------------------------------------------+
| git  | 20:85:ac:9d:c1:ec:01:62:79:ba:fe:ce:59:54:e1:8e |
+------+-------------------------------------------------+
[root@localhost blog(keystone_admin)]#

    ついでなので、flavorを追加しておきましょう。

[root@localhost blog(keystone_admin)]# nova flavor-create m1.micro 6 1024 10 1
+----+----------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name     | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+----+----------+-----------+------+-----------+------+-------+-------------+-----------+
| 6  | m1.micro | 1024      | 10   | 0         |      | 1     | 1.0         | True      |
+----+----------+-----------+------+-----------+------+-------+-------------+-----------+
[root@localhost blog(keystone_admin)]# nova flavor-list
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name      | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
| 1  | m1.tiny   | 512       | 1    | 0         |      | 1     | 1.0         | True      |
| 2  | m1.small  | 2048      | 20   | 0         |      | 1     | 1.0         | True      |
| 3  | m1.medium | 4096      | 40   | 0         |      | 2     | 1.0         | True      |
| 4  | m1.large  | 8192      | 80   | 0         |      | 4     | 1.0         | True      |
| 5  | m1.xlarge | 16384     | 160  | 0         |      | 8     | 1.0         | True      |
| 6  | m1.micro  | 1024      | 10   | 0         |      | 1     | 1.0         | True      |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
[root@localhost blog(keystone_admin)]#

 

 6.heatテンプレートを用意する

    それでは、heatテンプレートを用意しましょう。

    ここでは、GitHubクローンのGitLabサーバをデプロイしてみます。

    heatテンプレートフォーマットは、大きく2つのフォーマットがあります。

      ・HOT(ネイティブフォーマット?)

      ・CFN(CloudFormation互換フォーマット)

    さらに時系列のVerで言うと

      ・2010-09-09(CFN)

      ・2012-12-12(CFN・HOTの間?)

      ・2013-05-23(HOT)

    の3種類のVerが存在します。

    CFNのフォーメーション互換フォーマットでテンプレートを作成していて気が付いたのですが

    AWSのドキュメントに記載されているステートメントというかディレクティブというかが

    すべて使えるわけではないということなのです。

    なので、かゆいところに手が届かないことが、たびたびありました。

    HOTでAWSと同等のことをさせることが結構な範囲で可能だったので、今回は、HOTを使います。

    用意したテンプレートは、下記になります。 

heat_template_version: 2013-05-23

parameters:
  flavor:
    type: string
    description: flavor used by the servers
  image:
    type: string
    description: image name
  secgroup:
    type: string
    description: security group name

resources:
  git-lab:
    type: OS::Nova::Server
    properties:
      flavor: { get_param: flavor }
      key_name: "git"
      security_groups: [{ get_param: secgroup }]
      name: "gitlab_svr"
      image: { get_param: image }
      user_data: |
        #!/bin/bash -v
        /usr/bin/sudo -s
        curl -O https://downloads-packages.s3.amazonaws.com/centos-6.6/gitlab-7.5.3_omnibus.5.2.1.ci-1.el6.x86_64.rpm
        yum -y install openssh-server
        yum -y install postfix
        yum -y install cronie
        service postfix start
        chkconfig postfix on
        rpm -i gitlab-7.5.3_omnibus.5.2.1.ci-1.el6.x86_64.rpm
        gitlab-ctl reconfigure
        lokkit -s http -s ssh
        gitlab-ctl start
        exit

    今回用意したテンプレートは、cloudstack4からマイグレーションしたCentOS5のマシンイメージを使ってインスタンスをデプロイし、

    デプロイ時にGitlabのインストールスクリプトを実行して、Gitlabサーバをheat実行時に構築するものです。

    では、実行してみましょう。

[root@localhost blog(keystone_admin)]# heat stack-create gitlab -f gitlab.yaml -P "flavor=m1.micro;image=centos5-image;secgroup=gitlabservers"
+--------------------------------------+------------+--------------------+----------------------+
| id                                   | stack_name | stack_status       | creation_time        |
+--------------------------------------+------------+--------------------+----------------------+
| 93e0a0b2-235c-44ed-b8ea-4169186fcd4e | gitlab     | CREATE_IN_PROGRESS | 2014-12-09T08:55:47Z |
+--------------------------------------+------------+--------------------+----------------------+
[root@localhost blog(keystone_admin)]# 

    heatでstack-createすると「CREATE_IN_PROGRESS」という状態に入ります。

    インスタンスをデプロイしますので、ちょっとだけ時間がかかります。

    うまくいくと、状態が、「CREATE_COMPLETE」に変わり、heatの実行が、終わります。

[root@localhost blog(keystone_admin)]# heat stack-list
+--------------------------------------+------------+-----------------+----------------------+
| id                                   | stack_name | stack_status    | creation_time        |
+--------------------------------------+------------+-----------------+----------------------+
| 93e0a0b2-235c-44ed-b8ea-4169186fcd4e | gitlab     | CREATE_COMPLETE | 2014-12-09T08:55:47Z |
+--------------------------------------+------------+-----------------+----------------------+
[root@localhost blog(keystone_admin)]#

    インスタンスのデプロイは、できているでしょうか?

[root@localhost blog(keystone_admin)]# nova list
+--------------------------------------+------------+--------+------------+-------------+---------------------+
| ID                                   | Name       | Status | Task State | Power State | Networks            |
+--------------------------------------+------------+--------+------------+-------------+---------------------+
| 0f47fffd-cb54-4b75-a44e-78bb21066031 | gitlab_svr | ACTIVE | -          | Running     | public=172.24.4.234 |
+--------------------------------------+------------+--------+------------+-------------+---------------------+
[root@localhost blog(keystone_admin)]#

    大丈夫そうですね。後で、コンソール等で確認してみてください。

 

 7.heatをGUIでみてみる(おまけ)

    OpenStack Hrizon(GUI)でオーケストレーションメニューがあるので見てみます。

    先程stack-createしたスタックが見えてます。スタック名をクリックしてみます。

    デプロイされたtype: OS::Nova::Serverのサーバが見えてますね。

    もっと複雑なheatテンプレートを実行するとネットワークが見えるのですが、ここでは簡単に済ませます。

    

    以上で12/11分は、終わりになります。

    最後までお読みいただきありがとうございました。

 


CloudManagerAdvance 2.2 以上
カテゴリ: ツール
Google Playで詳細を見る

 

 

 

    2013アドカレの番外編的にちょっと書き足そうかと考えました。

    まぁ、見てくれる人がいるか解らないけど。。。^^;

 

1.CloudStack4のリソース状況を確認する

 

CloudStackのリソース状況    

図1

 

    OpenStackは、大体メモリー2GiBくらいあればいいとどこかに書いてあったので

    そのくらい残りのメモリーが余ってれば大丈夫だと思います。

 

2.Ubuntuサーバ12.04 64bitのisoイメージを用意する

 

    Ubuntuサイトからダウンロードして用意します。

    わたしは、以前ダウンロードしておいたisoイメージを

    DropBOXの公開フォルダに入れて用意しました。

    これをCloudStack4のISOテンプレートに取り込みます。

 ubuntu ISOテンプレート作成

    図2

 

3.ISOテンプレートをもってUbuntuSvr12.04 64bitのインスタンスをデプロイする

 

    2.でアップロードして作成したISOテンプレートでUbuntuSvr12.04 64bitの

    インスタンスをデプロイします。デプロイ時のリソースの割当は、メモリ2GiBくらい

    ディスクは、OpenStackで使う分(大体10GiB)だけ割り当てます。

 デプロイ結果

    図3

 

4.デプロイしたインスタンスにloginする

 インスタンスにlogin

    図4

 

    CloudStack4が払い出したインスタンスのIPを求めてsshでloginしておきます。

 

    ssh [ip address] -l [user name]

 

    loginしたら、ここに書いてある手順でOpenStackをインストールします。

 

    localrcのHOST_IPは、以下のようにして下さい。

 

    HOST_IP=[図3のIP]

 

    stack.shを実行

 

    最後のメッセージが下図のようになれば、インストール成功です。

 インストールの成功

    図5

 

    リポジトリの状態によって失敗する事があります。

    その場合は、1〜2週間置いてから再度試します。

    再度試すとき、/opt/stackの内容を空にしてから再試行してください。

 

5.OpenStackインストール後

 

    ここまでで、インストールがうまく行っていれば、図3で求めたIPか

    または、PortFowarding掛けたFloating IPの80ポートに対して

    ブラウザでアクセスします。するとOpenStackのコンソールが

    表示されます。

 OpenStack

    図6

 

    4.のインストール時に作成したlocalrcで指定したパスワードでadminにて

    loginします。

 

    あとは、demoアカウントに切り替えた後、demoイメージがあるので

    試しにデプロイしてみます。

 OpenStackデプロイ結果

    図7

 

    インスタンスのStateがRunningになれば、OKです。

 

    以上

 

CloudStack Day Japan 2014

    こんにちは、@opt_Hohenheimです。

    blogコンテストに参加と言うよりただblogネタが少し出来たので書こうと考えました。

    まぁ、見てくれる人がいるか解らないけど。。。^^;

 

1.CloudStack4のリソース状況を確認する

CloudStack4のリソース状況 

図1

 

    Wakame-vdcは、インストールするだけでDisk10GiBが80%くらい使われるので、

    とりあえず、Disk 20GiB、メモリ2GiB、CPU 2GHzくらいで導入してみました。

    Wakame-vdcで一杯リソース使う人は、適宜調整して下さい。

 

2.CentOS6.3のISOイメージからISOテンプレートを作成する

 

    Wakame-vdcは、CentOS6以上とGitに記載されていたので、今回は、6.3を使ってみました。

    ISOファイルは、理化学研究所のリンクを使わせて頂きました。

    

    これをCloudStack4のISOテンプレートに取り込みます。

ISOテンプレート作成

    図2

 

    下図のように準備完了が「yes」になれば、Okです。

ISOテンプレートの準備完了

図3 

 

3.ISOテンプレートをもってCentOS6.3minimal 64bitのインスタンスをデプロイする

 

    2.でアップロードして作成したISOテンプレートでCentOS6.3minimal 64bitの

    インスタンスをデプロイします。デプロイ時のリソースの割当は、1.で記載した

    Disk 20GiB、メモリ2GiB、CPU 2GHzくらい割り当てます。

デプロイ後の払い出されたIPアドレス 

    図4

    ここで、アドレス体系をメモしておきます。

 

4.デプロイしたインスタンスにコンソールでloginする

コンソールlogin 

    図5

 

    3.でCloudStack4が払い出したアドレス体系メモをもってCentOS6.3のインスタンスのアドレス体系を構成します。

 ifcfg-eth0の設定

    図6

    次にDNSサーバを設定します。

 DNSサーバーの設定

    図7

 

    ここで、service network restartします。

    今回、CloudStack4は、Advancedモードで使用していたので、忘れずにEgressFirewallRule

    を設定して、インスタンス内から外に出れるようにしておきます。

    コンソールでは、ネットワークメニューで自分のネットワークを選択後、

    「送信ルール」タブで、CIDRを指定しておいて下さい。その後、下図のように

    pingで外の出れるか確認します。pingが通れば、Okです。

 ping確認

図8

 

 

5.デプロイしたインスタンスのポート設定

    ポート転送ですが、sshポート22とWakame-vdcのマネージメントコンソールポート9000を設定します。

    筆者は、ポート転送とファイアウォールの2重設定が面倒だったので、以下のAndroidアプリで設定しました。(筆者の都合ですいません)

CloudManagerAdvance絶賛発売中!!(なにげに宣伝失礼します!!)

 

    このアプリでPortFoward設定すると自動でファイアウォールも設定してくれます。

 CloudManagerAdvance

    図9

    CloudStack4のコンソールでも設定出来ますので、そちらでも結構です。

    その場合、ポート転送とファイアウォールに22番と9000番を設定します。

    その後、以下のようにsshでloginします。

    ssh [Global ip address] -l root

 

    loginしたら、@giraffeforestgさんのblogに書いてある手順でWakame-vdcをインストールします。

    変更する所は、以下の赤字のIPの所をCloudStack4が払い出した図4のIPで設定する所です。

[root@Wakame-vdc ~]# vi /etc/wakame-vdc/dcmgr.conf
    :
service_type("lb", "LbServiceType") {
  image_id 'wmi-demolb'
  instances_network 'nw-demo1'
  management_network 'nw-demo8'
  host_node_scheduler :LeastUsage
  storage_node_scheduler :LeastUsage
  network_scheduler :VifsRequestParam
  mac_address_scheduler :ByHostNodeGroup do
    default 'mr-demomacs'

    pair 'hng-shhost', 'mr-range1'
  end

  # Please specify the addresses that can be referenced from within an instance of the load balancer.
  # amqp_server_uri is saved to userdata in instance of the load balancer.
#  amqp_server_uri 'amqp://example.com/'
  amqp_server_uri 'amqp://10.1.1.201/'
}
 

 

6.Wakame-vdcインストール後

 

    ここまでで、インストールがうまく行っていれば、図9のGlobal IPの

    9000ポートに対してブラウザでアクセスします。するとWakame-vdcのコンソールが

    表示されます。

 Wakame-vdcコンソール

    図10

 

    demoアカウントがあるのでdemo/demoにてloginします。

 Wakame-vdc login

    図11

 

    あとは、マシンイメージに切り替えた後、demoイメージ(cassandra)があるので

    試しにデプロイしてみます。

マシンイメージ

    図12

    マシンイメージ選択後、インスタンス起動ボタンを押下します。

 デプロイ

図13

    起動直後は、下図のように状態がinitialaizingになってます。

デプロイ直後

図14

    しばらく(すぐ)すると、下図のようになります。

 インスタンスrunning

    図15

    インスタンスの状態がRunningになれば、OKです。

 

    以上

 

    管理表の私のタイトルに(でも、たぶん軽め)と、どなたかが書き込んでいただけたので、

    お告げのように書きます(笑)←(本心は、助かったと思っているCloudStack神にm9(^Д^)プギャーと笑われそうです)

    もうREST APIアクセス方法は、いいですよね?

 

Network 

 

1.PortForwarding

    createPortForwardingRuleを使っていて、気がついたのですが、

    createFirewallRuleが自動的に行われることがあると言うことなのです。

    便利って言う事もあるのですが、その場合のcreateFirewallRuleの

    CIDRが0.0.0.0/0になってたりしますね。

    CIDRを自分で指定したい人は、後で変更しないといけませんね。

    まぁ、大体Allって言う用事が、多いのかもしれません。

    createPortForwardingRuleオプションで、

    

cidrlistthe cidr list to forward traffic from

    

    なんてありますね。こちらで指定できるのかな?

    ごめんなさい、こちら試していませんが。。。(核爆)

    ちなみに上図、管理コンソールUIでは、個々に設定するUIになっているみたいです。

    つまり、PortForwardingを設定してもFirewallは、設定されないようです。

    

2.EgressFirewallRules

    インスタンスから外部にアクセスを制御するルールがあったんですね。

    createEgressFirewallRuleです。

    AWSでは、VPC作ってその中でsecuritygroup作った時のみにアウトバンドフィルタを

    指定できますが、CloudStackでは、VPCは、関係なくアウトバンドフィルタ作れるのは

    いいですね。

    指定の際、CIDRを設定します。

    CIDRの形式って

xxx.xxx.xxx.xxx/xx

    ですよね?

   APIをRESTアクセスするとき色々手順を踏んだ後、URLエンコードします。

    当然、「/」がURLエンコードされるので、signatureを求めるときに

    注意が必要です。

    つまり、URLエンコードされる事によって、signatureがマッチしなくなるのです。

    これで、わたしは、1日くらいはまりました。(orz)

    

3.その他

    NetworkACLsなんてAPIが出来てたのですね。(いつのまに。。。)

    あと、いろいろなもの(例:IPアドレス)にIDがついたり(CloudStack3あたりからですが)、

    VPCも使えるようになって、ますますAWSに近づいている感じします。

    あと、AutoScale関連のAPIがずらり勢揃いしてますね。こちらLBと

    組み合わせて使うようですが、createAutoScaleVmGroupで

    スケールアウトするときのpolicy設定ができますね。多分ですが

    スケールアウトするときのスケールアップポリシー、スケール

    ダウンポリシーが指定できます。上図、管理コンソールUIでは、これをLB設定で

    同時に指定するようになってます。Citrix NetScaler 10.0以降がないと試せないのかな?

    まだこの辺りのAPIは、使ってないのでいずれ使ってみようと思います。

    

4.ちょっとだけ宣伝

    相変わらずですが、CloudStackのAndroidアプリ作ってます。

    (またこれかょw)

    ここの辺でもわだいにもならないアプリです。。。orz 

CloudManagerAdvance絶賛発売中!!

    CloudStack4のAdvancedモードをサポートしたAndroidアプリになります。

    一応、ver.4をサポートしています。Androidは、4.4(kitKat)でも動きます。

    

    今後は、このアプリ名でVerUpして行きます。

    アプリ名とか内部のパッケージ名を変更したりするとGooglePlayStore

    で別アプリ扱いされるのでこの名前でVerUp等して行きます。

    また、zabbix等連携してませんが、zabbixは、zabbixのAndroidアプリ

    がありますので、無理に融合は、していません。

    将来的にzabbixにかわる新しいプロダクト?が出て来て連携に意味が

    なくなる事やmunin等他の監視ツール、splunkのような解析ツール

    を使う場合を考慮しています。splunkのandroidアプリも出ている

    みたいですね。(はやい)

    一度、購入して頂いた方は、一生VerUpが無料で受けられます。

    こちらも宜しくお願い致します。

 

5.おわりに

    宣伝させて頂いたAndroidアプリ作っているときにAndroidのほうが苦労

    結構あったのですが、CloudStackから外れるので遠慮して書けませんでした。

    こちらの苦労話の方が結構ネタがあったのですが。。。orz

    こんなアプリでもオープンソースの要求があるようでしたら、してもいいのですが、

    何しろコードが汚いので、公開するのがガクブル(((((((( ;゚Д゚))))))))です。。。

    おまけに奇麗にしている暇もない。。。(´ε`;)

    ざっくり規模的には、下図の通りです。

    8月のCloudStackユーザー会で情報が流れていた内容とだいぶかぶってしまいましたが

    実際にAPIレベルで作成したプログラムから使ってみたりリファレンス見て、気がついた事について書かせて頂きました。

    他にAPIリファレンスなどでは、見えないAPIの挙動や使用に関する注意点についてご存知の方が

    いらっしゃいましたら、教えて下さい。なにしろAPIって391個でしたっけ?あるので。。。

    12/08分は、これで終わりです。拙い文章を最後までお読み頂きありがとうございました。

 CloudStackAdvance