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

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

サーバーの作成

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

サーバー一覧画面

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

サーバー作成画面

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

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

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

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

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

サーバーの作成 - VM作成

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

VM作成中画面

5分くらい待つとステータス欄に完了マークが表示され、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]

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

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

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

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

ニフティクラウドとは?

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

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

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

SSHキー作成画面


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

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

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

ダッシュボード

次回へ続く。

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

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

PaaS雑感

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

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

Heroku | Cloud Application Platform
screenshot

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

  • 裏側(ミドルウェア、ハードウェア)が隠蔽されているのがとにかく不安。何か問題が起こった際にさわれない、というのは精神安定的によくない。
  • とにかく気持ち悪かったのが、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

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

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

Remove all ads

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

Heroku | Cloud Application Platform
screenshot

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日はまった。。。)

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

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

ソース


使い方

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

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

最新ワイヤーフレーム作成ツール集 〜2009年秋〜

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

様々なツールが乱立し混迷を極めるワイヤーフレーム作成ツール業界ですが、皆さんは何でUI設計をしているのでしょうか。

マイクロソフト陣営内でも派閥がPowerPoint, Visio, Excelと分裂している中、Adobe系統のPhotoShop, Illustrator派、はたまたOmni Graffleなどのmac党も台頭しており、まさに「ワイヤーフレーム作成ツールの戦国時代」と言えそうです(盛り上がっているのは僕だけな気もしますが、気にせず続けます)。

そんな乱世の中、また新たな流れ「Flash派」が誕生し勢いをつけつつありますので、紹介します。

flairbuilder

screenshot

個人的には本命ツールと考えているflairbuilder。リリース後に日本のデザイン系ブログでもよく紹介されていたのでご存知の方も多いと思います。

UI作成部分ももちろん優秀なのですが、UIの中にリンクやJSなどで実現する動作もある程度含ませることができるので、簡易的なユーザビリティテストや動作確認までを行うことができるのがメリットです。

現在のバージョンだと、細かい挙動や描画できる図形に限度があるので、すべてのサービスで利用するのは厳しいです(個人的には自由な表組が作ることができないのがマイナスでした)が、コンスタントにバージョンアップを繰り返しているので今後のエンハンスにも期待です。

また、AIR製なのでMac/Winどちらでも対応できるというのもポイントが高いです。UIは営業担当からデザイナー、エンジニアまで様々な職種の人間が見ることになるので、環境を問わないというはありがたいですね。

gomockingbird

screenshot

オンラインでUI設計ができて、共有までできるシンプルなサービス。

日本語がうまく入力できなかったり、pixel単位での描画ができなかったりと細かいUI設計まではできなそうですが、会員登録なしで利用できたり共有が手軽なところは魅力です。

いまのところはざっくりとしたモックアップの作成/共有ツールとして利用できそうですね。

cacoo

screenshot

こちらもオンラインで作成/共有できるサービスですが、ステンシルの多さや共有機能の豊富さ(UI作成中にチャットができる!)など、細かい部分まで作り込まれてるなあという印象です。
複数ページの作成などの動作がデスクトップツールのそれに近いので、新しいツールを覚えるという感覚なしでスムーズに利用できそうです。日本製ということで、日本語の扱いを気にしなくていいのもうれしいですね。

まとめ

Flashツールはオンラインサービスであってもデスクトップアプリの使い勝手にだいぶ近いので、Webの強みである共有部分が強化されると面白くなっていきそうです。UI設計=個人作業という概念が変わっていくかも?しれないなと思っています。

また紙では表現できない動きを仕様書にプラスできることで、動的に変化するタイプのサービスの仕様作りにも大きく影響を与えていきそうです。

特に動的な箇所はエンジニアにおまかせ、となりがちな部分ですが(「いい感じに動かしてね」とか)、UI設計→ユーザビリティチェックとスムーズに進めることができれば、より使い勝手のいいサービス作りができるようになるかもしれません。

そんな感じで、また新しいツールが増えて面白くなってきているこの業界ですが、今後どのツールがのびていくのかが楽しみです。

「mixi、モバゲー、iPhone--アプリを提供するならどこ?」の回答が面白い。

screenshot
mixi、モバゲー、iPhone--アプリを提供するならどこ? - CNET Japan

パネラーの立場によって見方もだいぶ変わりますね。

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

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

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

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

が正しいと思います。