12月 2011

2011年12月28日

cloudpackの2011年を振り返る（後半）

cloudpackの2011年を振り返る（前半）の続きになります。

[7月]

☆ニュース

ヌーラボとパートナーシップを締結し、ライセンスインクルード型Backlogの提供開始

☆イベント

☆導入事例

[8月]

☆ニュース

☆イベント

Cloud Computing World Tokyo 2011（1日目）（2日目）（総括）
Zmandaクラウドバックアップセミナー
Cacooup Tokyo

☆導入事例

[9月]

☆ニュース

☆イベント

☆導入事例

[10月]

☆ニュース

☆イベント

☆導入事例

エネゴリくんくるんくるんを追加いたしました

[11月]

☆イベント

[12月]

☆ニュース

☆イベント

☆導入事例

本年は、クラウドというサービスが大きく飛躍したことにともない、
cloudpackの2011年にも様々な出来事がありました。
そこで、今回は2011年のcloudpackを振り返ってみたいと思います。

尚、本日が2011年最後の更新となります。
本年も数多くの方にご愛顧いただき誠にありがとうございました。
cloudpackは来年も精進して参りますので、何卒よろしくお願いいたします。

[1月]

☆ニュース

cloudpackがAWSのSolution Providerとして認定されました

☆イベント

Japan AWS User Group (JAWS-UG) クラウド女子会第1回

☆導入事例

[2月]

☆ニュース

☆イベント

☆導入事例

BOSSブランドグローバルサイトを追加いたしました

[3月]

☆ニュース

☆イベント

[4月]

☆イベント

[5月]

☆ニュース

☆イベント

☆導入事例

[6月]

☆ニュース

「G-CLOUD magazine | 2011 summer」（技術評論社）に、cloudpackのCTO鈴木の記事とcloudpackエバンジェリスト後藤のコラムが紹介されました

☆イベント

☆導入事例

S3オリジンのCloudFrontでインデックスドキュメントやエラードキュメントを利用できるようにする

CloudFrontにはDefault Root Objectという設定項目があり、
http://cloudfront.suz-lab.com/ 等のURLでアクセスすると、
上記の設定項目で指定したファイル(ページ)が表示されるようになります。

しかし、http://cloudfront.suz-lab.com/sub/ 等のサブディレクトリに対するアクセスには
対応していません。

また、ステータスコード404等に対するエラードキュメントに関しても、
独自のエラーページを表示させることはできません。

CloudFrontのオリジンをS3にしている場合(S3オリジン)は、上記の制限が効いてしまいます。

尚、カスタムオリジンの場合はオリジンによるので、オリジンサーバがインデックスドキュメントや
エラードキュメントを指定できるようにしていれば、独自のエラードキュメントやアブディレクトリに
対するインデックスドキュメントも可能となります。

しかし、コンテンツは高い可用性と耐久性を誇るS3に配置しておきたいところです。

もとより、S3にはWeb Site Hostingという機能があるので、これを有効にすると
サブディレクトリを含めたインデックスドキュメントとエラードキュメントを
独自のファイルに指定することができます。
但し、Web Site Hosting用のURLからアクセスすることで、上記の機能を利用することができます。

再度、CloudFrontの話しに戻ります。

CloudFrontを設定する際に、S3オリジンでバケットを指定するのではなく、
カスタムオリジンで上記のWeb Site HostingのURLを指定することも、可能となっています。

カスタムオリジンにすることでWeb Site Hosting機能の結果がキャッシュされるので、
実質、サブディレクトリを含めたインデックスドキュメントや独自のエラードキュメントも
利用できていることになります。

キャッシュの期間には注意が必要です。

こちらの記事はなかの人（suz-lab）監修のもと掲載しています。
元記事は、こちら

HTML5 アニメーションループ

こんにちわ。
職人見習いの小森です。

今回は、HTML5におけるアニメーションループについてです。
私はゲームを作っていた経験もあり、HTML5におけるゲーム開発にも興味あるので調べてみました。

○setInterverlを使ったループ

function render(){
     // アニメーション 1フレーム分の処理
}
setInterval(render, 1000 / 60);

setTimeoutやsetInterverlを利用したやり方が一般的ですが、
requestAnimationFrameというのが新たに用意されています。

○requestAnimationFrameを利用したループ

if ( !window.requestAnimationFrame ) {

    window.requestAnimationFrame = ( function() {

        return window.webkitRequestAnimationFrame ||
               window.mozRequestAnimationFrame ||
               window.oRequestAnimationFrame ||
               window.msRequestAnimationFrame ||
               function(callback, element) {
                   window.setTimeout( callback, 1000 / 60 );
               };
    } )();
}

requestAnimationFrameを利用する場合も非対応ブラウザへの対処も必要なため
非対応ならsetTimeoutやsetInterverlでループする対策も必要になります。

※この記事は、なかの人（spitz8008）が書いています。

2011年12月27日

AWSサムライに認定されました

この度、AWSより本年のコミュニティへの貢献を評価され、cloudpackエバンジェリストの後藤（@kaz_goto）が
AWSサムライに認定されました。
後藤の他にも、JAWS-UG東京の会長竹下さんやJAWS-UG東京の副会長堀内さん、
JAWS-UG札幌＆東京のコアメンバーである田名部さんが受賞されました。
尚、賞金として＄5,000のAWSクーポンをいただきましたので、技術向上の為に利用していこうと考えています。

今回の受賞は、日本全国のJAWS-UG勉強会への参加が認められたものとのことで、
この後藤の活動にご協力いただいた皆様に深く感謝いたします。
また、今後もより一層の貢献ができるようcloudpackとしても尽力して参ります。

受賞の模様は、AWS最新アップデート AWS玉川様/荒木様/川本のUSTREAMよりご覧ください。

iPhoneでAWS - Cloud Services Manager その11

こんにちは。
職人の宮内です。

今回もCloud Services Managerを使って、SimpleDBを扱ってみたいと思います。

『Dash Board』から『Simple Database(SDB)』をタップします。

まず、画面右下の『 + 』をタップし、続いてDomain名を入力します。

一覧にDomain名が表示されるので、タップします。

続いてItem名とattribute名、attribute値を入力し、『Save』をタップします。

Item一覧画面に作成したItem名が表示されます。

Item一覧画面でItem名をタップすると、attributeを見る事が可能です。

この他、DomainやItem、attributeの追加または削除も可能です。

※この記事は、なかの人（iret_manabu）が書いています。

VPC上のELBに対するサブネットのCIDRブロックについて

VPC上のELBはサブネットに所属しますが、ELBはスケールするため、
サブネットのIPアドレスレンジはある程度確保しておく必要があると思います。

それでは、どの程度確保しておく必要があるかについてですが、
How Do I Use Elastic Load Balancing in Amazon VPC?に記載されていました。

上記によると、次の引用の通りになります。

In order to ensure that your load balancer can scale properly,
the subnet that you attach the load balancer to should be at least a /25 CIDR block
and should have enough free IP addresses to scale.

ELBが適切にスケールできるように、ELBが所属するサブネットのCIDRブロックは
少なくとも"/25"にし、自由に利用できるIPアドレスを確保すべきです。

例として、下記のようにサブネットを割り振るようになると思います。

サブネット: 192.168.1.0/25
ネットマスク: 255.255.255.128
ネットワーク: 192.168.1.0
ホストのレンジ: 192.168.1.1 - 192.168.1.126
ブロードキャスト: 192.168.1.127

尚、VPCの場合は下記の先頭3つのIPアドレスが予約されています。

192.168.1.1 192.168.1.2 192.168.1.3

実際にEC2に割り振れるIPアドレスは、下記となります。

192.168.1.4 - 192.168.1.126

以上のことから、ELBのサブネットは/25ということになります。

こちらの記事はなかの人（suz-lab）監修のもと掲載しています。
元記事は、こちら

2011年12月26日

2011/12/26 週刊cloudpackマガジンを配信しました

本日の配信内容は、下記になります。

[cloudpack更新情報]

◇第3回 AWS User Group - Japan【宮崎】勉強会『Browser Uploads to S3
using HTML POST Forms』を公開しました
米国シアトル本社のトレーニングで聞いたS3に直接データをアップする方法

[気になるAmazon EC2関連情報]

★AWS技術レビュー

◇ELBを使用した際にGraphAPIからウォール投稿を行う場合の注意点

◇NagiosのCloudWatchプラグイン(PHP版)

◇PostfixからSESにリレー(stunnel編)

◇AWS SDK for Android ELBのリストを取得する

◇そろそろCloudFormation(VpcCloudFormation編)

◇そろそろCloudFormation(HelloCloudFormation編)

◇AWS SDK for Android ELBを削除する

◇S3にブラウザから直接アップロードするフォーム(HTML)をPHPで生成

◇JAWS-UG宮崎第3回勉強会LT資料(Browser Uploads to S3 using HTML POST Forms)

◇AWS SDK for Android ELBを作成する

★サーバ技術レビュー

◇Nagiosで時間を指定して監視をする

◇FuelPHPってなんじゃ？（インストール編）

◇OSの起動日数を確認する

★cloudpack職人見習いのStudy Note

◇HTML5 プログレスバー

◇各メーカーのSSL証明書携帯端末カバー率

◇iPhoneでAWS - Cloud Services Manager その10

◇MT5 メール機能とシステムログ

毎週お届けする週刊cloudpackマガジンの購読希望の方は、
週刊cloudpackマガジンよりご登録ください。

MT5 再構築にかかる時間を短縮しよう

こんにちは。
職人見習いの齋藤です。

MT5の再構築ですが、諸々の設定や環境にもよりますが、MT4に比べて時間がかかってしまうケースもあるようです。
そこで、すでに他所でも様々な対処が掲載されていますが、再構築に要する時間が短縮できる方法を
挙げておこうと思います。

○使用しないテンプレートを削除する

ブログを生成した時点でデフォルトで各種テンプレートが用意されていますが、
中には使わないものもあるかと思います。
これらは使わなくてもそのままにしておくと、再構築の対象となり時間がかかる要因になりますので
不要なものは削除しましょう。
ブログを生成し、開発を進める前にまず不要なテンプレートを削除しておくと
後々便利です。

○インデックステンプレートの公開設定を見直す

ほとんど修正や変更を行わないインデックステンプレートは、再構築時の対象から外しておくことで
時間短縮に繋がります。
インデックステンプレートの編集画面に「ブログの公開プロファイル」という項目があります。
こちらがデフォルトでは「スタティック（規定）」となっています。
これを「手動」に変更してあげれば、そのテンプレートは再構築の対象から外れ、
手動での再構築のみになります。
例えば JavaScript や CSS などをインデックステンプレートで作成した場合などは、
手動に設定しておくと良いです。

○ログの削除

システムメニューのログ画面でログデータを閲覧できますが、このログデータも不要であれば
定期的に削除するようにします。

○モジュールのキャッシュ設定を有効にする

全般設定のモジュール設定に
モジュールのキャッシュ　「再構築の速度向上のために、テンプレートモジュール毎のキャッシュ設定を有効にする」
というチェックボックスがあるのでチェックを入れます。
デフォルトではチェックが入っていないので注意して下さい。

上記の項目を実践するだけでも多少再構築にかかる時間が短縮されると思います。
上記以外にも色々な手段がありますので試してみたいです。

※この記事は、なかの人（Iret_msaito）が書いています。

ELBを使用した際にGraphAPIからウォール投稿を行う場合の注意点

ELBを利用してFacebookアプリを作った場合に発生する、特殊なケースです。

ウォール投稿の際、pictureに有効なURLを指定しているのに、なぜか反映されない場合があります。
尚、現象は以下の通りです。

ELBに対しroute 53を使いAレコードでドメインを割り当てる
↓
割り当てたドメインで画像の参照を確認
↓
Grapth APIから投稿しても反映されない

推測ではありますが、原因としては、ELBに割り当てたドメインからFacebook側が引けていないようです。
CNameだと反映するのか等、細かい検証はしていませんが、解決方法としては、
Grapth APIからの投稿時にELBのデフォルトドメインにすることで、Facebook側で取得、保存することができます。

こちらの記事はなかの人（hiroki0907）監修のもと掲載しています。
元記事は、こちら

NagiosのCloudWatchプラグイン(PHP版)

以前、@j3tm0t0さんが公開されたNagiosのプラグイン、check_cloudwatchと
ほぼ同様のプラグインをCloudWatchとの通信をPHPで行うものを作成してみました。
(元祖check_cloudwatchはコマンドラインツールを利用しています)

下記のように利用できます。

# ./check_cloudwatch \
> -c 20 \
> -w 10 \
> -f credential.yml \
> -r ap-northeast-1 \
> -n AWS/EC2 \
> -m CPUUtilization \
> -s Average \
> -u Percent \
> -d InstanceId \
> -v i-xxxxxxxx \
CloudWatch CRITICAL - AWS/EC2 CPUUtilization Average InstanceId i-xxxxxxxx: 25.092 Percent;| data=25.092;10;20;0;

コードは下記のようになっています。 (エラー処理は不完全な状態です。)

require_once("/opt/aws/php/latest/sdk.class.php");
 
// define status
$ok       = array("code" => 0, "name" => "OK");
$warning  = array("code" => 1, "name" => "WARNING");
$critical = array("code" => 2, "name" => "CRITICAL");
$unknown  = array("code" => 3, "name" => "UNKNOWN");
 
// set option
$option = getopt("c:w:f:r:n:m:s:u:d:v:");
$critical_size = $option["c"];
$warning_size  = $option["w"];
$credential    = yaml_parse_file($option["f"]);
$region        = $option["r"];
$namespace     = $option["n"];
$metrics       = $option["m"];
$statistics    = $option["s"];
$unit          = $option["u"];
$name          = $option["d"];
$value         = $option["v"];
 
// init cw
$cw = new AmazonCloudWatch($credential["accessKey"], $credential["secretKey"]);
$cw->set_region($region);
date_default_timezone_set("Asia/Tokyo");
 
// get metric statistics
$response = $cw->get_metric_statistics(
    $namespace,
    $metrics,
    "-10 minutes",
    "now",
    300,
    $statistics,
    $unit,
    array(
        "Dimensions" => array(
            array("Name" => $name, "Value" => $value)
        )
    )
);
$data = (float)$response->body->GetMetricStatisticsResult->Datapoints->member->$statistics->to_string();
 
// check status
if($data > $critical_size) {
    $status = $critical["code"];
} elseif($data > $warning_size) {
    $status = $warning["code"];
} elseif($data > 0) {
    $status = $ok["code"];
} else {
    $status = $unknown["code"];
}
 
// output status
$output = " - ${namespace} ${metrics} ${statistics} ${name} ${value}: ${data} ${unit};| data=${data};${warning_size};${critical_size};0;";
switch($status) {
    case $ok["code"]:
        print("CloudWatch " . $ok["name"]       . $output);
        exit($ok["code"]);
    case $warning["code"]:
        print("CloudWatch " . $warning["name"]  . $output);
        exit($warning["code"]);
    case $critical["code"]:
        print("CloudWatch " . $critical["name"] . $output);
        exit($critical["code"]);
    case $unknown["code"]:
        print("CloudWatch " . $unknown["name"]  . $output);
        exit($unknown["code"]);
}
print("CloudWatch " . $unknown["name"] . $output);
exit($unknown["code"]);

AccessKey、SecretKeyは下記のファイルにまとめています。

accessKey: "XXXXXXXXXXXXXXXXXXXX"
secretKey: "ssssssssssssssssssssssssssssssssssssssss"

さらにブラッシュアップした際には、再度紹介しようと思います。

こちらの記事はなかの人（suz-lab）監修のもと掲載しています。
元記事は、こちら

2011年12月22日

Nagiosで時間を指定して監視をする

監視をしているサーバでメンテナンスなどを行う際に、特定の時間帯だけアラートメールを
受信しないようにしたい場合があります。
そのような場合、nagiosではアラートを通知する時間帯を設定することが可能です。

設定ファイルは、下記になります。

timeperiods.cfg

例として、毎日1:00～23:00で、アラート通知を受信したい場合は、下記のようになります。

define timeperiod{
timeperiod_name test_hour
alias 　test HOUR
use 　test_hour
sunday 01:00-23:00
monday 01:00-23:00
tuesday 01:00-23:00
wednesday 01:00-23:00
thursday 01:00-23:00
friday 　01:00-23:00
saturday 01:00-23:00
}

そして、上記の設定を下記に記述します。

define service

記述方法は、下記となります。

notification_period test_hour

こちらの記事はなかの人（be_hase）監修のもと掲載しています。
元記事は、こちら

FuelPHPってなんじゃ？（インストール編）

PHPのフレームワークは多数ありますが、どのフレームワークも複雑過ぎたり、機能が足りなかったりと、
丁度よいモダンなフレームワークはなかなかありませんでした。
そこに登場したCodeIgniterは機能が豊富ですっきりとしている良質な
モダンフレームワークとして注目されています。

今回紹介するのFuelPHPは、CodeIgniterの開発者等も参加しており、
CodeIgniterや他のプロダクトの良いところを集めた期待のフレームワークのようです。

主な特徴は、下記のようになります。

MVC
HMVC（画面要素の複数のMVCモジュールをひとつに纏めて１画面をつくれる）
モジュール拡張可能
セキュリティ対応（出力エンコーディング、入力フィルタ、XSS、CSRF、SQLインジェクション）
豊富なコマンドライン
ORMとSQLどちらもOK
認証機構つき
複数のビューテンプレート（smartyなど）に対応
scaffoldできる
migrateできる
PHPUnitできる

上記を見ると分かる通り、Railsから多くの影響を受けているようです。

では、早速試してみます。

ここでは、下記のようにしてblogアプリをつくってみたいと思います。

ドキュメントルート：/var/www/html
アプリベース：/opt/cloudpack/

○インストール

$ curl get.fuelphp.com/oil | sh
$ cd /opt/cloudpack/
$ oil create blog

以上で、一通りのセットが揃います。

次に、セキュリティのためにpublicフォルダだけをDocumentRootに移動します。

# mv blog/public /var/www/html/blog

そして、index.phpに書いてある、アプリパスを変更します。

# vi /var/www/html/blog/index.php
~
/**
 * Path to the application directory.
 */
define('APPPATH', realpath('/opt/cloudpack/blog/fuel/app/').DIRECTORY_SEPARATOR);

/**
 * Path to the default packages directory.
 */
define('PKGPATH', realpath('/opt/cloudpack/blog/fuel/packages/').DIRECTORY_SEPARATOR);

/**
 * The path to the framework core.
 */
define('COREPATH', realpath('/opt/cloudpack/blog/fuel/core/').DIRECTORY_SEPARATOR);

それでは画面をみてみます。

上記のように、Welcome画面が表示されてました。

○Scaffolding

次にデータベースの設定をします。
(mysqlサーバーがインストールされ起動していることを前提とします)

vi /opt/cloudpack/blog/fuel/app/config/db.php

'default' => array(
                'type'        => 'mysql',
                'connection'  => array(
                        'hostname' => 'localhost',
                        'port' => '8889',
                        'database' => 'blog',
                        'username' => 'memorycraft',
                        'password' => '*********',
                        'persistent' => false,
                ),
                'identifier'   => '`',
                'table_prefix' => '',
                'charset'      => 'utf8',
                'caching'      => false,
                'profiling'    => false,
        ),

vi /opt/cloudpack/blog/fuel/app/config/development/db.php

'default' => array(
                'connection'  => array(
                        'dsn'        => 'mysql:host=localhost;dbname=blog',
                        'username'   => 'memorycraft',
                        'password'   => '***********',
                ),
        ),

MySQLでデータベースとユーザーを作成します。

mysql> create database blog;
mysql> GRANT ALL PRIVILEGES ON blog.* TO 'memorycraft@localhost'  IDENTIFIED BY '*******';

次に、scaffoldを作成してみます。

$ cd /opt/cloudpack/blog/
$ oil g scaffold blog title:string body:string tags:string created_at:date

そして、migrateです。

$ oil refine migrate

これで、データベースblogにblogテーブルが作成されました。

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| blog               |
| mysql              |
| performance_schema |
| test               |
+--------------------+
5 rows in set (0.00 sec)

それでは、画面を見てみます。

ブログの管理画面が表示されました。
そして、入力して登録してみます。

無事、一覧に保存内容が表示されました。
Railsと同じような感じですね。

あくまでひな形ですが、このくらいのスピードでDB、画面が準備できます。
PHPはこれで決まりなのではないかと思うくらいの可能性を感じます。

これから使い込んでみたいと思います。

こちらの記事はなかの人（memorycraft）監修のもと掲載しています。
元記事は、こちら

登録: 投稿 (Atom)

クラウドサービス Amazon EC2の導入設計から運用・保守ならcloudpack

2011年12月28日

cloudpackの2011年を振り返る（後半）

cloudpackの2011年を振り返る（前半）

S3オリジンのCloudFrontでインデックスドキュメントやエラードキュメントを利用できるようにする

HTML5 アニメーションループ

2011年12月27日

AWSサムライに認定されました

iPhoneでAWS - Cloud Services Manager その11

VPC上のELBに対するサブネットのCIDRブロックについて

2011年12月26日

2011/12/26 週刊cloudpackマガジンを配信しました

MT5 再構築にかかる時間を短縮しよう

ELBを使用した際にGraphAPIからウォール投稿を行う場合の注意点

NagiosのCloudWatchプラグイン(PHP版)

2011年12月22日

Nagiosで時間を指定して監視をする

FuelPHPってなんじゃ？（インストール編）

FeedBurner

検索フォーム

cloudpack Twitter

カテゴリ

アーカイブ

リンク

関連サイト

導入サイト