2013年8月21日 星期三

從新版本CloudAPI看SDC 7...

不算最新消息,關注smartdc套件的朋友應該早有觀察到,有不少重大改變唷...給大家參考 :D


下面資訊,引用自官方:

Appendix E: SDC 7 Changelog
Cloud API and SmartDC CLI have been completely rewritten for SDC 7.0. Notably, required version of Node.js to run the CLI is now greater or equal than 0.8.14.
Most of the commands remain the same, taking exactly the same options and returning exactly the same JSON information in an attempt to preserve backwards compatibility between 6.5 and 7.0 API clients, and software built for 6.5.
There are, anyway, some important differences between SDC 7.0 and the previous version, where the main one is:
  • The request version of SDC 7.0 CLI is, obviously, ~7.0 instead of 6.5.
  • This means that the parameter --dataset (or the equivalent -e short option) is mandatory for the command sdc-createmachine. On previous versions of the API, it was possible to provision a machine without specifying an image to the create machine command. This behavior has been deprecated, and the desired image must be specified.
  • Also, starting at version 7.0, there isn't a default dataset. For backward compatibility purposes, when a request using ~6.5 is received, the latest version of the smartos dataset will become the default one.
  • Starting with version 7.0, virtual machines can also be resized but, only resizing virtual machines to a higher capacity/package is supported.
  • Version 7.0 also deprecates the URN attribute for any entity, either Images or Packages. URN support will finish with SDC 6.5 support.
  • Starting with version 7.0, packages listed by GET /:account/packages accept search filters. Additionally, the package members vcpusidand version are included on packages, as explained into packages section.
  • Since Version 7.0 historical list of machine accomplished actions is available through request GET /:account/machines/:id/audit.
  • Version 7.0 adds the ability for customers to manage Firewall Rules through /:account/fwrules resource, as explained into Firewall Rules section.
  • Version 7.0 exposes account details through GET /:account, and allows the modification of the account properties - with the exception of password and login - through POST /:account. Details are explained into the Account section
  • Version 7.0 exposes Networks details through /:account/networks resource, as explained into Networks section.
  • Since Version 7.0.0 node-smartdc's sdc-createmachine accepts an optional --networks|-w argument, which can be set to the id of one or more of the networks retrieved from /:account/networks.

Setting rsync service on SmartOS

Rsync是一套歷久彌新的Linux/Unix系統備份工具,透過rsync可以達到差異的備份方式,讓整個備份的動作可以更有效能的執行... 而MiCloud上提供的主機預設都預載有rsync的功能,而Linux上使用可能大家已經有嚐試過,這邊複習一下,也順便說一下Windows (沒錯,Windows上也可以透過rsync來將資料備份到遠端的rsync server上唷!)上操作rsync的方式。

Rsync Server設定

Step 1: 編輯設定檔
$ vi /etc/rsync.conf
內容:
log file = /tmp/rsyncd.log
pid file = /tmp/rsyncd.pid
port=873
[backup]
hosts allow = 192.168.1.10              #允許的clisnt IP
hosts deny = *                          #除上面allow設定的IP,不允許存取的Client,請設為* 全部
comment = ewant upload file backup
path = /home/backup/upload
uid = root
gid = root
auth users =backup
secrets file = /etc/rsyncd.secrets
read only = no
exclude = temp/ .*                      #要排除的備份檔案或目錄,須以空格區分

設定檔中的backup是備份的模組,這個名稱可以自由取,將會用在client端操作指令上

Step 2: 編輯密碼檔
$ vi /etc/rsyncd.secrets
內容:
backup:xxxxxxxxxxxxxxxxx

上面rsyncd.secrets文件中是存放"帳號:密碼"的內容,最後,密碼檔案必須將權限變更為600,不然連線上會有異常...

Step 3: 啟動服務
$ rsync --daemon --config=/etc/rsync.conf --no-detach

啟動服務的部份,如果沒有加上--no-detach的話,則服務會啟動在背景運作

Client端操作(SmartOS/Linux/Mac)

大部分的Linux/Unix系統都有預載rsync了,這部份部戲談安裝部分...

Step 1: 編輯密碼檔
$ vi .rsync
內容:
xxxxxxxxxxxxxxxxx

此步驟勢將server side step 2中設定的密碼部分寫入密碼檔,檔案位置存放在可以讀取的位置即可,名稱也不拘,之後指令需要指定密碼檔的路徑與名稱

Step 2: 執行同步
client端的同步指令如下:
rsync -avz --password-file=[密碼檔][欲同步資料夾] backup@[rsync server ip位置]::[模組名稱]
範例:
$ rsync -avz --password-file=.rsync /tmp/test backup@192.168.1.10::backup


Client端操作(Windows)

Windows的安裝,請至: https://www.itefix.no/i2/cwrsync-get 取得安裝檔,安裝與基本的操作可以參考官方文件。安裝完成後,需要設定環境變數PATH可以吃得到安裝的目錄下的bin,這樣才可以使用到下面的rsync指令,我所安裝的版本因為只有cygrsync.exe,這邊我直接做一個快捷,命名為rsync.cmd,這樣日後操作上比較方便。

Step 1: 編輯密碼檔
同Linux系列的Step 1

Step 2: 執行同步
指令的操作部分,指令格式不便,但因為系統先天性差別,路徑的寫法稍微與Linux系列有所不同...
  • 其中路徑仍然只吃"/"而不是Windows慣用的"\"
  • 針對磁碟位置的定義,最前面要加上"/cygdrive",例如: c:/opt/rsync.conf,則路徑定義為:/cygdrive/c/opt/rsync.conf
  • 操作人員,不能是Administrator (這部份滿怪的,但是實際上操作如果是Administrator,則會出現"password file must be owned by root when running as root"的錯誤,說明文件在這裡)
範例:
$ rsync -avz --password-file=/cygdrive/c/Users/simon/.rsync /cygdrive/d/tmp/test backup@192.168.1.10::backup

不透過Rsync Server,直接做Rsync

架設rsync server雖然說不難,但是終究多了個餓步驟,其實rsync也可以像scp一樣直接來的... 指令如下:

rsync -r [預備份資料] [備份目的地]

範例:
$ rsync -r /cygdrive/d/tmp/test backup@192.168.1.10:/home/backup/upload

上面操作是針對Windows的系統(路徑有指定了/cygdrive),如果是Linux系列的使用者,直接使用Linux路徑即可∼

參考文獻:

2013年8月18日 星期日

Easy use of HAProxy

專門的事情交給專業去做 - 如果要做LB,交給 - HAProxy準沒錯!
感謝許多網友的介紹(這位仁兄的部落格有非常詳細的說明)
透過HAProxy可以快速做到網站服務基本的Load Balancing
在MiCloud上要架設一台HAProxy就更快了...

準備:
申請一台SmartOS,建議申請Standard64主機,套件支援到2013Q1

STEP1: 查找支援的haproxy版本

$ pkgin se haproxy
haproxy-1.4.21       Reliable, high performance TCP/HTTP load balancer

=: package is installed and up-to-date
<: data-blogger-escaped-available="" data-blogger-escaped-but="" data-blogger-escaped-installed="" data-blogger-escaped-is="" data-blogger-escaped-newer="" data-blogger-escaped-package="" data-blogger-escaped-version="">: installed package has a greater version than available package


STEP2: 安裝合適版本套件

$ pkgin install haproxy-1.4.21
calculating dependencies... done.

nothing to upgrade.
1 packages to be installed: haproxy-1.4.21 (2592K to download, 0B to install)

proceed ? [Y/n] Y
downloading packages...
haproxy-1.4.21.tgz                               100%  928KB 132.6KB/s 149.9KB/s   00:07
installing packages...
installing haproxy-1.4.21...
haproxy-1.4.21: copying /opt/local/share/examples/haproxy/haproxy.cfg to /opt/local/etc/haproxy.cfg
//////////////////////////////////////////////////////////////////////////////

This package is SMF enabled, which means you can use SMF to 'enable',
'disable' or 'restart' the persistent daemon process, e.g.:

  svcadm enable haproxy:default

The SMF manifest was automatically imported now.

See our wiki on what's SMF and how to use it to your advantage:

  http://wiki.joyent.com/display/smart/About+the+Service+Management+Facility

//////////////////////////////////////////////////////////////////////////////
pkg_install warnings: 0, errors: 0
reading local summary...
processing local summary...
updating database: 100%
marking haproxy-1.4.21 as non auto-removable
- See more at: http://blogger.micloud.tw/#sthash.9ZPGTyp4.dpuf

STEP3: 設定HAProxy

完整的設定在網路上很多,這邊不細談設定部分,只精簡的說明要proxy某台主機的作法:

STEP4: 最後,起動一下服務(因為服務是由SMF方式掛載,可以透過svc*系列指令操作,詳情可以參考:)

$ svcadm enable haproxy

檢查:如果state(第一個欄位)為online的話,表示服務啟動OK拉∼

$ svcs haproxy
STATE          STIME    FMRI
online          3:03:20 svc:/pkgsrc/haproxy:default

Debug:

$ svcs -xv haproxy <-- 檢查啟動是否有相依性錯誤
$ tail -f `svcs -L haproxy` <-- 檢查服務運作screen output log

關閉服務:

$ svcadm disable haproxy

重起服務:

$ svcadm restart haproxy




2013年8月10日 星期六

MiCloud課程資訊

MiCloud於2013年第三季開始提供許多課程供內部與外部人員參與,課程內容將以MiCloud之應用與使用Node.js開發雲端服務為主題,課程的點點滴滴將記錄於網站(https://sites.google.com/a/mitac.com.tw/training),供大家參考。

課程內容包含:
  • MiCloud服務相關
  • Node.js初階~進階課程
歡迎有興趣的朋友報名參加

2013年8月5日 星期一

MiCloud CloudAPI CLI - Tag & User Script, 使用 User Script 建立 VM 環境

MiCloud CloudAPI繼承 Joyent CloudAPI而持續研發更多的功能,前面已經介紹如何入門使用 MiCloud CloudAPI

本篇在介紹以 CloudAPI 建置 Machine 的進階應用: 使用 CloudAPI 的 Tag 與 metadata 。

Machine的屬性


在 Machine 建立的當下,MiCloud 賦予 Machine 一些主機上的特殊屬性,讓使用者可以透過API的方式查詢,一般我們可以在 CLI 上查詢 Create Machine 的 help page 可以知道有哪些參數可以帶入:

# sdc-createmachine --help
sdc-createmachine [--account string] [--debug boolean] [--dataset string] [--help boolean] [--identity path] [--keyId string] [--metadata ] [--name string] [--package string] [--tag ] [--url url]


其中 tag 參數 metadata 參數是今天要介紹的重點...

關於Tag


tag 是一個以 key/value 存在的一組一組值,附屬在主機之下,在 CloudAPI 中可以透過下面方式對主機增加 tag (其中主機的 id 可以在 sdc-listmachines 中,每台主機的 id 欄位中找到):

# sdc-addmachinetags --tag servername=testtag01 [your machine id]
{
  "servername": "testtag01"
}


如果希望依次新增多個 tag,也可以這樣做:

# sdc-addmachinetags -t foo=bar -t servername=testtag01 b34f99ea-ef8d-4332-b043-9f4d49104833
{
  "servername": "testtag01",
  "foo": "bar"
}

然後可以透過 sdc-listmachinetags 來顯示主機的 tag 有哪些...

# sdc-listmachinetags [your machine id]
{
  "servername": "testtag01",
  "foo": "bar"
}


如果在 shell 中欲使用到 tag 中的某一個數值,可以這樣做
(PS:請先安裝json tool套件:npm install jsontool -g)

# sdc-listmachinetags b34f99ea-ef8d-4332-b043-9f4d49104833 | json foo
bar


對於一個管理者而言,tag 可以當做附加給這台主機的一些額外屬性,讓主機可以有更多的資訊可以作為日後自動化的參考值...

關於 Metadata / User Script


metadata 裡面主要存放與 tag 相同格式的 key/value 的參數值,而不同的是,當您設定 key=user-script 時候,將會有特殊的用途

主機將在 boot 時候,直接使用 shell 執行 user-script 裡面所帶的參數內容,此部份的設定是讓使用者可以自訂開通或開機時候的執行腳本,讓自動化部屬在每次開機時候完成...
如果主機一開始沒有設定任何 user-script 時候,使用 sdc-getmachinemetadata 會得到空的 json 物件

# sdc-getmachinemetadata b34f99ea-ef8d-4332-b043-9f4d49104833
{}


而,可以透過與 tag 相通的設定方式在主機上 attach 參數(唯一不一樣的是,它叫做sdc-updatemachinemetadata)


# sdc-updatemachinemetadata --metadata foo=bar b34f99ea-ef8d-4332-b043-9f4d49104833
{
  "foo": "bar"
}


查詢參數的方式是使用 sdc-getmachinemetadata 來查詢

# sdc-getmachinemetadata b34f99ea-ef8d-4332-b043-9f4d49104833
{
  "foo": "bar"
}


以上,設定與key的操作大同小異...

如果要機器聽話在開通或開機完成的時候自動執行您的腳本,直接在 metadata 指定key=user-script的屬性,並且帶入值為您欲執行的腳本即可:

# sdc-updatemachinemetadata --metadata "user-script"="echo HELLO > /root/user-script.log" b34f99ea-ef8d-4332-b043-9f4d49104833
{
  "foo": "bar",
  "user-script": "echo HELLO > /root/user-script.log"
}


設定完的 user-script 可以透過 sdc-getmachine 來看到設定的結果:

# sdc-getmachine b34f99ea-ef8d-4332-b043-9f4d49104833
{
  "id": "b34f99ea-ef8d-4332-b043-9f4d49104833",
  "name": "212ec88",
  "type": "smartmachine",
  "state": "running",
  "dataset": "local:robin:hadoop-node:0.1.0",
  "ips": [
    "211.78.254.144"
  ],
  "memory": 1024,
  "disk": 15360,
  "metadata": {
    "foo": "bar",
    "user-script": "echo HELLO > /root/user-script.log"
  },
  "created": "2013-03-23T14:50:21+00:00",
  "updated": "2013-06-07T04:29:29+00:00",
  "primaryIp": "211.78.254.144"
}

主機重新開機後,user-script 將會應用至該主機:

# sdc-rebootmachine b34f99ea-ef8d-4332-b043-9f4d49104833

# ssh root@211.78.254.144
Last login: Fri Jun  7 10:59:34 2013 from 211.78.254.110

[root@b34f99ea-ef8d-4332-b043-9f4d49104833 ~]# ls -l
總計 1
-rw-r--r-- 1 root root 6 6月   7 12:30 user-script.log
[root@b34f99ea-ef8d-4332-b043-9f4d49104833 ~]# cat user-script.log
HELLO


順道一提,當在撰寫 user-script 時候,script 的內容可以直接參考到其他的 metadata 屬性,例如:


sdc-updatemachinemetadata \
--metadata "user-script"="echo HELLO $USER > /root/user-script.log" \
--metadata USER=simon b34f99ea-ef8d-4332-b043-9f4d49104833

則重開機後,會發現 user-script.log 裡面會是:

# cat user-script.log
HELLO simonsu


另一種建立 user-script 的方式,是直接在 create machine 的參數中給予 script 參數,內容需要帶入一個腳本檔案,範例如下:

建立主機的指令:

# sdc-createmachine \
--dataset local:robin:hadoop-node:0.1.0 \
--package "S 1GB RAM (1CORE)" \
--script ./install.sh \
--tag servername=JoomlaServer01


其中 install.sh 內容如下

# cat install.sh
curl -k https://raw.github.com/micloud/installer/master/smartos-standard64/install-joomla.sh | sh

以上,給需要自動化部屬 Cloud Machine 的使用者參考