A Day In The Boy's Life -189ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

レンタルサーバーを借りてみました。借りたのはファーストサーバ です。


プランはVPS(仮想専用サーバー)で、ちょうど共用サーバーと専用サーバーの中間に位置するようなプランです。

共有サーバーではできないサーバー操作などが行えるけど、専用サーバーほど料金は高くありません。

仮想化されているわけなので、ある程度の制限はあるものの、サーバー管理などを実際にやりたかったり、ある程度の自由度が欲しいという場合にはぴったりなプランではないでしょうか。


私のほうでは、VPSの「プロビジネス20」で、CentOS5のプランで契約しました。

まぁ、何か大きなサービスを始めるというわけではないので、これで十分という感じです。

仮想化用のミドルウェア(PLESK )が搭載されているため、設定に少し難がありましたので、Webサーバー環境設定までの備忘録を残しておきます。



1. PLESKにログインしてみる


契約時にはもろもろの書類が送られてきますが、その中にグローバルIPアドレスと管理用システム(※)へのログインURLへのが記載された用紙がありますので、まずはそこにアクセスしてみます。

ログイン画面にて言語選択ができますので、日本語にしておきましょう。


※ 管理用システムには、「Paralles Power Panel」と「PLESK」の2種類のシステムがあります。

  どちらも、契約時に貰ったIPアドレスを指定すればアクセスできます(ポート番号が違う)

  Paralles Power Panelは、サーバーのパッケージ管理やログの管理などが行えます。

  一方で、PLESKはサービスの管理に特化したシステムとなります。Webサービスの設定を行う際には、主に

  このPLESKのほうを利用します。

  Paralles Power PanelからPLESKへログインする事もできますが、何故か英語のメニューになったり、PLESK

  内のメニュー表示がエラーになったりするので、一旦PLESKをログアウトして、最初からログインする必要が

  あります。


サーバーの管理は、基本的にこのPLESK管理コンソールから行えます。

左メニューの「コンテナサービス」欄にSSH接続というメニューがあり、ブラウザからSSHの接続も行えます。

ただし、あまり使い勝手もよくないため、TeraTerm などのSSH接続ができる端末を用意した方がよいでしょう。

もちろん、それらで直接接続する事も可能です。


注)

ファーストサーバでは基本、このPLESKコンソール画面を通してサーバーを操作することを推奨しており、端末を使って接続し、サーバーを操作する場合は自己責任でということになっているようです。

もちろん、このブログ記事で書かれていることも、実際にやる場合は同様に自己責任でお願いします。



2. ファーストサーバの契約初期で見える画面


サーバーへの接続が完了した次は、メインとなるWebの設定へ移ります。

送られてきた用紙の中に記載のグローバルIPをブラウザに入力すると、このようにPLESKの初期画面が表示されます。


PLESK初期画面


やるべきことは、その画面内に書かれています。

が、英語なので簡単に解説するとドメインの設定を行っていないので、まずはそれをしてくださいという事です。


ドメインの登録が必要かというと、そうではありません。

グローバルIPアドレスのままブラウザからアクセスすることも可能です。

ドメインが必要な方は、ファーストサーバの契約時にまとめて登録しておくか、外部のドメイン登録サービスを利用するとよいでしょう。


【早い者勝ち!】 .com/.net/.jp ドメイン取るならお名前.com


予断ですが、このPLESKという仮想化用のミドルウェアがサーバー内のApacheをコントロールしているようで、サーバーからコマンドでApacheのデーモンを起動・停止は行えるものの、ドキュメントルートの変更などは行えないようです。(これで私はしばらくはまりました・・・)



3. PLESKにドメイン設定を行う


では、実際にドメインの設定を行っていきます。

ここでは、グローバルIPアドレスで借りたレンタルサーバーに、自分の作ったHTMLファイルが見えるところまでを設定します。

ドメインを取得していた場合の設定方法も基本同じですが、合わせて契約書と一緒に送られてきた用紙に記載のヘルプ用のページも参照してみてください。


ログインするのは、PLESKのほうであり、Paralles Power Panelのほうではないので注意してください。



3.1 クライアントを作成する


まずは、PLESK管理用コンソールからクライアントを作成します。

左メニューの「クライアント」から「新しいクライアントアカウント」を選択します。


PLESK設定-1


次に、クライアントの必要情報を入力します。

連絡名にはメールアドレスを設定します。

インターフェース言語欄やスキンなどはデフォルトのままで特に問題ありません。


PLESK設定-2


次の画面では、利用するIPアドレスを登録します。

1契約であれば1つのグローバルIPアドレスが付与されているはずなので、そのIPアドレスを選択してクライアントIPプール欄に追加ボタンで移動させます。


PLESK設定-3


これでクライアントの設定は一通り完了です。


PLESK設定-4



3.2 ドメイン設定を行う


継続してPLESKへドメインの登録を行います。(左メニューのドメインからでも設定ができます。)

ドメインを取得しておらず、グローバルIPアドレスでWebへアクセスできるようにするので、「ドメイン名」欄には「localhost.localdomain」としています。(これは特に何でもかまいません)


PLESK設定-5


次に、ドメインのホスティングタイプを指定します。

今回はドメインを取得していない為、「物理ホスティング」を選択します。


PLESK設定-6


最後の設定になります。

最後は、FTPのアカウント設定やこのサーバー内で使うプログラミング言語などを設定します。


PLESK設定-7


PHPやPerlをWebで使いたい場合は、チェックを入れておきましょう。


PLESK設定-8

これで一通りの設定は完了です。

もう一度、ブラウザからIPアドレスを指定してアクセスしてみます。


PLESK設定-9


あれ・・・同じじゃん、と思わないでください。

微妙にページの内容が変わっています。

表示されているメッセージが異なっていたり、左下に各プログラムのテスト用のページが表示されたりしています。


ここまでくれば、あとは自分のWebページをサイトに配置するだけです。



4. WebサーバーにHTMLファイルを配置する


Webページの配置には主に2つの方法があります。

1つは、FTPのアカウントを作ったので、FTPクライアントを通してアクセスし、ファイルをアップロードする方法、もう1つはPLESKのファイルマネージャ(左のVirtuozzoメニュー)を通してブラウザから管理する方法です。


Webサーバーのドキュメントルートは、Apacheの設定ファイル(/etc/httpd/conf/httpd.conf)に書かれているものと異なり、


/var/www/vhosts/{PLESKで設定したドメイン名}/httpdocs

となります。

仮想化している影響か、このドキュメントルートは変更できないようです。


# cd /var/www/vhosts

# ls
chroot default localhost.localdomain

vhostsディレクトリの中をのぞいてみると、このように先ほどPLESKで登録したドメイン名のディレクトリができています。

さらにそのディレクトリの中を見てみると

# ls
anon_ftp cgi-bin error_docs httpsdocs private subdomains
bin conf httpdocs pd statistics web_users

このようにたくさんのディレクトリがあるわけですが、ファイルを配置するのはこの中の「httpdocs」ディレクトリとなります。

SSLのページを分けて管理する場合は、「httpsdocs」ディレクトリにファイルを配置します。


この2つのディレクトリの何れかに、FTPなりPLESKのファイルマネージャを使ってファイルを配置します。

あとは、ブラウザからそのファイルにアクセスしてみるだけです。

これらのディレクトリには、初期ではPLESKのデフォルトページ用のHTMLや画像ファイルが置かれているので、不要であればすべて削除しておきましょう。


あとは、自分のお好きなように!



□ おまけ(ファーストサーバを使ってみた感想)


  • PLESKなどの管理コンソールを使わないとできないこともあるため、その使用になれないといけない
  • PLESK自体は、サーバー管理の一通りの機能がそろっている為、サーバーに直接つなげなくとも、ある程度のことはできてしまう
  • パッケージの更新などは自分でやらなくてはならない
  • パッケージの管理にはyumコマンドは利用できず、Paralles Power Panelを通して追加やアップデートを行う ※
  • Apacheの設定を変更することができないので、パッケージで提供されている以外のものをApacheに組み込むことはできなさそう(未確認)
  • Apacheの設定を変更することができないため、フレームワークを使う際には工夫が必要になりそう
  • root権限があり、ソースからのインストールも可能な為、結構自由度は高い
  • バックアップは自分たちでやる。何かあった際には、初期状態に戻る。(もちろんなかのデータの保障はなし)
  • ある程度のサーバー管理の知識がないとつらいかも
  • ただ、小さなサービスをやりたかったり、とりあえずコマンドたたけるサーバーがほしいという場合には、安いし、まぁいいかという感じ

2008.08.17 追記

※ ファーストサーバ上でyumコマンドを利用することは可能です。詳細は、下記の記事を参照してください。


ファーストサーバでPostgreSQLを利用可能にする



2009.01.10 追記

コンテンツを保護するためにBasic認証を設定したい場合は、書きエントリを参照してみてください。


ファーストサーバにBasic認証を設定する






ビジネス革新に貢献してくれる“社外の人々”――「クラウドソーシング」の可能性 @ Computerworld.jp


ついにこういう時代にまでなってしまったのかという感じなのですが、私の関心ごとは社内のエンジニアの立場は?

という点。

外部には優秀なエンジニアがいて、そういった人が独特のアイデアをもって新しい風を吹き込んでくれる可能性があることはよくわかりますが、安いから、早いからということで外にばかり頼ってしまうと、内部のエンジニアの

モチベーションは下がってしまいます。


何故、内部でできなくて外部に頼らざるを得ないのか、というところをよく考えなくてはならないかと。

少なくとも社内で抱えているエンジニアのなかにも、優秀な人材は沢山いるはずです。

しかし、そういった人がうまく機能しない理由を考えてみるのも重要です。

エンジニアとしてすべき仕事以外に、つまらないルーチンワークを与えてしまい、その人のパフォーマンスが十分にだせないせいもあるかもしれません。


ただ、よい点も幾つか考えられます。

それは、新しいアイデアを運んでくれると同時に、社内のエンジニアたちを競争の世界に導き、社内に一定の緊張感を与えることができるのでは、という点。

俺たちは頼りにされていないのかもしれない、俺より優秀な奴が外にはいるんだという危機感を社内に持ち込む事もできるかと思います。


少なくとも外部のリソースをうまく扱うには、そのクラウドをうまく取り込む必要があります。

アウトソースするより安い、という事で何でも無名のプログラマーにシステム開発募集をかけるだけでは、優秀な人材は集まりません。

自分たちが作るものが、どのように使われ、何をもたらすものなのか、その行き着く先と大きさを誇示する必要はあるでしょう。

大好きなゲームのエンディングのエンドロールに、スペシャルサンクスとして名前が載るのであれば、無償で働くという人は多いでしょうが、自社の利益にしかならないような仕事に、幾分かの報酬はあるとはいえ、参加する事はまっぴらごめんと考える人も少なくありません。


この手法が主流となるかどうかはいささか疑問ですが、少なくともエンジニア個人としての技量を磨けばビジネスチャンスは広がるという利点も考えられるかと思います。

単に、自分のちょっとした利益のために、サービスを作ってみるという時代から、どこかの大企業のシステム開発に無名でも参加できる時代になるかもしれません。

つまり、エンジニアとしては一つ道が広がったということになります。





Scoble、「コメント荒しはDiggへ帰れ」とビデオで主張 @ TechCrunch Japaneses


私の意見としても、コメントが荒れているから有意義な意見がブログを通して行われていないのだとは、思いませんけどね・・・。


昔の「牧歌的時代」におけるブログというのは、今ほどコミュニティの広がりもなく、アーリーアダプターによって発信された情報を、同じ領域の人間同士で活発に意見が交わされていたため、ブログのコメントが活発に利用されていたのだと思います。

そして大衆化してしまった今、これが本来のあるべき姿だとも。

つまりは、自分が発信した情報に対して、真剣に考えて意見を述べ、議論を取り交わそうとする人は、本当にごくごく一部の人であるという事。


ここで主張されている事の流れをまとめるとこんな感じでしょうか。


1. ブログが広く普及されていない時代において、一部その有意義な機能に目をつけた人たちによって、質の高い情報が発信されていた


2. ブログが大衆化して玉石混交となり、質の高い玉を見つけることが困難となった


3. digg(日本だとはてブとか)が登場して、質の高い玉に対して、本気で良いと感じた人たちのコミュニティによって押し上げる事ができるようになった


4. 3.の情報を押し上げるサービスもが大衆化して、情報を押し上げるコミュニティ自体の質が悪くなってしまった


こうしてみると、そうなったのは致し方ないことというのがなんとなく見えてきたりもします。

一つの問題を解決する術が、別の問題の起因となっているわけですから。


以前、はてブでも衆愚化の話題で盛り上がっていましたけど、ある一つのサービスが広く受け入れられるようになってしまうと、本来の道から外れてコントロール不能になってしまうことはよくある事です。

何事にもルールが決められたりしているのも、それが要因の一つでしょう。


なので新しい道を作り、それが広く知られて開けた道となってしまい、自分にとって窮屈なところとなってしまったら、また新たな道を作るしかありません。

ただ、一ついえることは、悪いものは目立つが、必ずしも全てがそうであるとは限らない事。

中には質の高いコミュニティがそこで形成される事もあるわけです。


少なくとも誰かが通ってくれる道であれば、それは道としての役割を果たします。

誰も通らない閑散とした道を作る事に意味なんてあるのでしょうか。