2010-08-25

CentOS on ニフティクラウド（モニター日記2） : サーバ作成からログインまで

IaaS NIFTY Cloud

前回はSSHキーの作成からダッシュボード遷移までの手順を行いました。今回はサーバの作成からログインまでを行います。

サーバーの作成

左メニューから「サーバー」を選択します。

サーバー一覧画面

「サーバー作成」をクリックするとポップアップが出てきます。

サーバー作成画面

タイプはサイトから自分のお好みを選択してください。後から変更も可能です。
OSもCentOS, Redhat, Windows2008から選べます。
料金は従量課金か定額課金か選べます。従量制だと停止している時は安くなるみたいなので開発中は従量制、リリース後は定額制を選択するとよいでしょう。

サーバーの作成 - プラン設定

選択すると金額が表示されます。

サーバー作成画面：プラン設定

今回はMedium(2vCPU,2GBメモリ)、CentOS5.3 64bit版のプレーン、定額制を選択しました。ちなみにサーバータイプだと最初からapacheなどが入っているようですが、この手のものは自分でインストールしたいので今回は見送り。

サーバーの作成 - VM作成

「作成する」をクリックすると、VMが作成されます。

VM作成中画面

５分くらい待つとステータス欄に完了マークが表示され、IPアドレスが出てきますので、サーバへログインできるようになります。

VM作成完了画面

ちなみにニフティクラウドはIPアドレスがグローバル側、プライベート側と2つ付与されます。グローバル側のネットワークは有料（従量制）ですが、プライベート側は無料なので、ニフティクラウドのサーバ間通信はプライベート側で行う方がお得です（わざわざインターネット経由でやる必要もないですね）。

サーバーの作成 - サーバへログイン

ここから先はMacでの操作方法になります。
terminalから早速サーバーへログインしようと、以下のコマンドを実行すると...

ssh -i [.pemキーのパス] root@[サーバIP]

こんな感じで↓めちゃくちゃ怒られます。。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '[.pemキー名]' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: [.pemキー名]
Permission denied (publickey,gssapi-with-mic).

pemファイルのpermissionがゆるすぎ！と怒っていらっしゃるようなので、適切な権限にかえましょう。

chmod 600 [.pemキー名]

このあと、

ssh -i [.pemキーのパス] root@[サーバIP]

を実行するとログイン完了です！まだ続く。

2010-08-25

CentOS on ニフティクラウド（モニター日記1） : ログインからダッシュボードまで

IaaS NIFTY Cloud

全国10万人のレンサバ難民の皆さん、いかがお過ごしでしょうか。

自分はこれまでISPの無料HPスペース→ロリポップ→さくらのレンタルサーバ→slicehost→linode→お名前.comと渡り歩いてきましたが、まだ定住できる場所を見つけられていません。
お名前.comでも色々あり、そろそろまた別のVPSに移ろうかなと思っていたところ、中の人*1からニフティクラウドのモニター版のアカウント（3ヶ月試用できるID）をいただきましたので一時的に趣味で運営しているサービスを移行してみようと思っています。*2（3ヶ月後にはまた移行ですが。。。）これからクラウド使ってみようと思っている人の参考になればと思います。

ニフティ クラウドとは？

ニフティ株式会社が運営するIaaSサービスです。詳細はサイトでご確認ください。

コントロールパネルへのログイン、SSHキーの作成

コントロールパネルに@niftyIDでログインすると、SSHキーの取得画面へ遷移します。

SSHキー作成画面

初回のサーバログインにはSSHキーが必要になるので、キーの名前とパスフレーズを入力します。
成功するとSSHキーがDLできるのでローカルに保存します。SSHのパスフレーズって記号ダメなんだ。

コントロールパネル：ダッシュボード

SSHキー作成後、ダッシュボードに遷移するとこんな画面にいきます。

ダッシュボード

次回へ続く。

*1: クラウド営業担当の上野くん。

*2: 仕事では数百台単位で使ってます。

2010-05-21

PaaS雑感

プログラミング

最近PaaS関連（appengine, herokuなど）を色々さわってみた際の雑感をまとめておきます。

http://code.google.com/intl/ja/appengine/

Heroku | Cloud Application Platform

サービス/プラットフォームの切り分けについて

裏側（ミドルウェア、ハードウェア）が隠蔽されているのがとにかく不安。何か問題が起こった際にさわれない、というのは精神安定的によくない。
とにかく気持ち悪かったのが、herokuで出たエラーの原因がよくわからなかったこと。
- herokuで特定のclassが読み込めていない？というエラーが発生。新規にサービスを登録して再度（同じ手順で）commitしたら何事も無く稼働した。なぜ？
隠蔽されているメリット/デメリットの境目は常に意識しておく必要がある。

インフラ、ミドルウェア運用について

逆に、裏側を見なくていいというのは楽でもある。やっぱりインフラ、ミドルウェア運用を人任せにできるのは楽。
- apacheが不安定になっても勝手に対応してくれるなんて！ステキ！
社内システムや簡単なアンケートツールみたいなものはPaaSで作りやすいと思った。個人情報の扱いやSLA次第では全然使える。むしろ使いやすい。ちょっとしたアイデアを形にする、というのに向いている。
プロトタイプ→サービス化のフローが進めやすい。あと流行らなかったときにクローズもしやすい。

DBと流行ったときの対応について

appengineのbigtableは使いにくいけど運用しやすい。特に勝手にスケールしておいてくれるというのは楽。VPSで運用しているサービスは常にメモリ使用量をひやひやしながら確認している。webサービスでこの差はでかい。
- 逆にherokuのようにRDBを利用するというモデルの場合は、結局流行っちゃったときに対応は必要。
扱い慣れてるけどスケールしづらいRDBか、扱いづらい（現状はベストプラクティスがない）key-valueを使うのか、判断はユーザー側だけど常に悩みそう（流行ることを想定して、カッチリ作ったwebサービスは流行らないの法則）。

不況とPaaS

一般にIT投資額は減る一方の世の中で、経営層にとってPaaSは救世主なのかも
フリーランスエンジニア、小規模なSIerさんにはかなり使いやすいツールになるのかも
PaaS向けのアプリケーションが徐々に増えてきているが、ここで例えばappengine向けのblog、EC、CMSのキラーアプリが出たら一気にブレイクスルーを迎えるのかなあ。

クラウドとPaaS

バズワードである「クラウド」は結局のところ、

IaaS ←専用ホスティング/VPS
SaaS ←ASP

であることを考えると、新しい概念はPaaSだけだと思える。
この概念がどう広まっていくか/結局広まらないか。今後の展開が楽しみです。

2010-04-27

Ruby(Rack)向けPaaS環境「Heroku」でRedmineを動かす

プログラミング

Heroku | Cloud Application Platform

Ruby(Rack)向けPaaS環境「Heroku」にRedmineをインストールしてみました。参考にさせてもらったサイトはこちら。感謝。

Herokuおもしろい！gemでコマンドを配布というのがかっこいいですね。

インストール方法

Herokuのgemをインストール

sudo gem install heroku

Redmineのソースコードを落としてくる

svn export http://redmine.rubyforge.org/svn/branches/0.9-stable redmine
cd redmine

RedmineのソースにHeroku向けに修正

Herokuはtmp以下にしかファイルを作れない仕様のようなので一部修正する

vi app/models/attachment.rb
-  @@storage_path = "#{RAILS_ROOT}/files"
+  @@storage_path = "#{RAILS_ROOT}/tmp/files"

vi vendor/plugins/engines/lib/engines.rb
-  self.public_directory = File.join(RAILS_ROOT, 'public', 'plugin_assets')
+  self.public_directory = File.join(RAILS_ROOT, 'tmp', 'plugin_assets')

vi config/environment.rb
+  config.action_controller.session = { :key => "_myapp_session", :secret => "secret" }

mkdir tmp/files
mkdir tmp/plugin_assets

ローカルでDBを作ってmigrate、マスターデータをloadする

Herokuは対話式のRakeを実行できない？ようなのでローカルでDBを作ってマスターデータをloadしておく

ローカル向けにDB設定を行う

cp config/database.yml.sample config/database.yml
vi config/database.yml

DB作成、migrate、マスターデータload

rake db:create
rake db:migrate
rake redmine:load_default_data

Herokuに突っ込む

あとはHerokuにソースコードとデータを突っ込むだけ。

git init
git add ./
git commit ./ -m "first commit"
heroku create
git push heroku master
heroku rake db:migrate
heroku db:push
heroku restart
heroku open

Herokuはインフラ/ミドルウェアを隠蔽されてる楽さと難しさが両面あるなあと思います。普段は楽だけど、ハマるときつそう。（簡単そうに書いたけど1日はまった。。。）

2010-03-15

バッチの実行結果をGmailでメール送信するrubyスクリプト

プログラミング

こちらを参考にさせてもらって作りました。
一応ブログにもあげておきます。

ソース

使い方

echo "ほげほげ〜" | ruby send-gmail.rb

こんな感じで標準出力をメールでぶん投げる感じ。

2009-11-10

営業、クリエイティブ系の人はすべてのプラットフォームで出すべきといい、
エンジニア系の人はプラットフォームは最初は絞るべきという

実際問題として、mixiとiPhoneアプリでは「コンテンツ（内容）」を同じにすることは簡単だけど、「システム（コンテンツをユーザー届ける仕組）」はプラットフォームごとに結構違うわけです。

違うから当然開発コストはプラットフォームごとに発生する訳で、それなりの開発コストをかけられる場合（ヒットすることが見えているコンテンツ。極端な例だとドラクエとか）は別として、普通の戦略としては江島さんの

まずはどれが一つを選択し、ちゃんと丁寧に完成まで持って行く。そこで何かしら学んで、それから手を広げていけばいいんじゃないでしょうか。

が正しいと思います。

サーバーの作成

サーバー一覧画面

サーバー作成画面

サーバーの作成 - プラン設定

サーバー作成画面：プラン設定

サーバーの作成 - VM作成

VM作成中画面

VM作成完了画面

サーバーの作成 - サーバへログイン

ニフティクラウドとは？

コントロールパネルへのログイン、SSHキーの作成

SSHキー作成画面

コントロールパネル：ダッシュボード

ダッシュボード

サービス/プラットフォームの切り分けについて

インフラ、ミドルウェア運用について

DBと流行ったときの対応について

不況とPaaS

クラウドとPaaS

インストール方法

Herokuのgemをインストール

Redmineのソースコードを落としてくる

RedmineのソースにHeroku向けに修正

ローカルでDBを作ってmigrate、マスターデータをloadする

ローカル向けにDB設定を行う

DB作成、migrate、マスターデータload

Herokuに突っ込む

ソース

使い方

ワイヤーフレーム作成ツール戦国時代

関連リンク

関連リンク

まとめ