前提となる環境

* Windows 10 Home Edition
* Docker Toolbox

やったこと

1. Angular+Node用のDockerfile及びimageの作成
2. 1で作成したimageをもとにコンテナを作成しつつ、ホストマシン上でコードをいじれるようマウント
3. 実際にサーバを立ち上げてみる
4. ホスト上からコードに修正を加えてみる

1. Angular+Node用のDockerfile及びimageの作成

とりあえずNodeでサーバを立てて Angular動かしてみるかということになった。

https://hub.docker.com/r/monostream/nodejs-angular-cli/

ひとまず ↑を参考にして以下のような感じでDockerfileを作成。

FROM node:alpine

RUN apk add --quiet --no-cache bash && \
    yarn global add @angular/cli && \
    yarn cache clean && \
    rm -rf /var/cache/* /tmp/*

EXPOSE 4200

WORKDIR /home/node

COPY ng_apps ng_apps

CMD ["/bin/sh"]

Angularでserveした際のデフォルトのポートが4200なので、4200番を開放している。
また、ng_apps という空ディレクトリをコピーしているが、これはホストマシンとの共有を想定したディレクトリ。Angularアプリケーションを配下に置いておくことでホストマシンから直接コードをいじれるようにしたかった。Dockerfileを作成したら、同ディレクトリにて以下コマンドを実行。

docker build -t angular-test .

Successfully tagged angular-test:latestという文言とともにイメージが作成される。

2. 1で作成したimageをもとにコンテナを作成しつつ、ホストマシン上でコードをいじれるようマウント

以下のようにdocker run でコンテナを作成する。

docker run --name angular_test_server -d -it -p 80:4200 -v $(pwd)/ng_apps:/home/node/ng_apps angular-test

-v オプションにて ng_appsディレクトリをマウントしつつ、ポートは80番で叩けるようにした。
引き続き以下のコマンドを実行し、作成したコンテナに入り、Angularが適切にインストールされているかどうかを確認する。

docker exec -it angular_test_server /bin/sh
ng --version

3. 実際にサーバを立ち上げてみる

コンテナに入ったままng_appsディレクトリに移動し、ng new コマンドによって myappというアプリケーションを立ち上げる。
ここで一つ問題が発生する。Windowsの場合、Virtualbox経由で共有ディレクトリをつくった場合ゲストマシン側でそのディレクトリにシンボリックリンクを貼ることができない。これにより共有ディレクトリ上で npm install が通らず、結果的に ng new myapp がコケるという事態に陥る。そこで npm install の際に –no-bin-links オプションをつける必要があるのだが、Angularでこれをやりたい場合は以下のようにする模様。

ng new myapp --skip-install
cd myapp
npm install --no-bin-links

これによって共有ディレクトリ上でも無事Angularアプリケーションを置くことができた。あとはnpm installが完了したら以下のコマンドでサーバの立ち上げを行う。

ng serve --host 0.0.0.0

今回はDockerのデフォルトネットワーク経由のため、ホストマシンのブラウザから 192.168.99.100 にアクセス。

表示された。

4. ホスト上からコードに修正を加えてみる

せっかくマウントしたわけだし、ホスト上からコードをいじってみる。とりあえず簡単な例として初期に表示されるページのタイトルを変えてみることにする( パスはmyapp/src/index.html )。

こんな感じでいじって再度ゲストマシン側にてng serve –host 0.0.0.0を実行すると…

無事更新が反映された模様。

The post DockerでAngular+Nodeのサーバを立てた話 appeared first on きのこる庭.

特に「秒間にさばけるリクエスト数って、何をもって秒間●リクエストって言えるのか」 とか、
「秒間リクエストを測る際に、ユーザごとの端末の違いは考えなくて良いの？例えば有線のPCと3Gのスマホだと全然速度違うから、サーバ-クライアント間のコネクションが続く時間も変わってきてしまうんじゃないの？」
とか色々考えていたけど、調べているうちに自分なりに何となくハッキリしてきたので 情報の整理がてら共有。
もしかしたら認識誤りで 間違った事を言っているかもしれないので、その場合はご指摘いただければ本当に嬉しいです。

「秒間リクエストを測る際に、ユーザごとの端末の違いは考えなくて良いの？」について

結論から言うと、サーバが秒間でさばけるリクエスト数はユーザが使用しているネット回線には依存しない。

これは速度の差が発生するのがどこのネットワークにおいてかを考えるとわかりやすいかも。
PCでもスマホでも ユーザ側のネットワークにおける速度が変われど、サーバ側における通信の速度は(PC/スマホごとにネットワーク側で別々の処理が行われていない、またはサーバ側でリクエスト元のIPに対して特定の帯域制限等をしていない 等の限りにおいて)変わらないことがわかる。
以下はそれを示した図である。

ユーザ側のネットワークの帯域制限(図で言うと Aくんの使用しているWiFiのネットワークにおける帯域制限)とか媒体のネットワークは、飽くまでユーザ側のネットワークにおけるものであり、さらに言うと、サーバ自体のネットワーク領域は同じなので、ユーザ側のネットワークの帯域はサーバがさばける秒間リクエスト数には関係しない。

ので、秒間リクエスト数を測る際に 秒間リクエストに直接関わってくるネットワーク周りの問題は、サーバ側のネットワークが提供しているスペック、つまり以下の部分となる。

上記の赤枠で囲まれたネットワーク部分からサーバ間通信( アプリケーション自体のレスポンス、DBサーバのレスポンス速度等 )等を見て最終的なレスポンスの速度を判断し、ボトルネックを見つけて改善し続けていく工程が「秒間●リクエストをさばく」という事の意味なのかなと思った。

つまり「秒間●リクエスト」とは

「秒間●リクエストをさばける」事が保障するのは、その量のリクエストが来た時にサーバがダウンすることなく稼動し続けられる事、及びシステム全体におけるボトルネックの特定が可能になる事( アプリケーションの特定のSQLクエリが重く、結果的にAPサーバで遅延が発生している、各サーバ上では処理に時間がかかっていないがネットワークの帯域のスペックがそもそも微妙でレスポンスが遅れている 等)である。
言い換えると、サービスがユーザにとってサクサク見られるかどうかを”完全に保障するわけではない”。

「秒間で沢山リクエストをさばける＝ユーザがサクサクページを見られる」ではない

勿論、サーバが十分にリクエストをさばくことができないと 待ち行列ができてレスポンスが遅延してユーザがサクサクページを見られないので、サーバが想定されるリクエストを十分にさばけることは最低限保障されている必要があるが、さらにユーザがサクサクページを見られるようにするための工夫は秒間リクエストの話とは別に別途必要になる。
例えば以下のような事を考慮する必要がある。

1. ターゲットとするユーザが主に使用するであろう端末

有線で見れば速いページでも、スマホ媒体向けに提供されている特定の回線で見たら遅い、且つサービスが提供するターゲットとなるユーザがスマホ媒体 なんてこともあるので、(当たり前だけど)ターゲットとする人達が利用するであろう端末での速度面の検証作業は必須になるだろうなあと思う。
それでもって、明らかに媒体に対してコンテンツのサイズが大きすぎる場合は圧縮したりキャッシュを利用したり何なりの手立てが必要になる。

2. ターゲットとするユーザの居住地

基本的にインターネットは様々な異なるネットワークを経由してできているため、距離が遠ければ遠い程 パケットがネットワーク上を移動するのに要する距離・時間が長くなる。
更に、国によっては 海外IPのサーバに対して自動で検閲が入るようになっている関係で遅くなったり、一つの国の中でも南部と北部で異常に重くなったりする事もあるそうなので、特に海外ユーザ向けにサービスを展開する場合は基本的に サービスを提供するユーザに近い場所にサーバを置くのが良いらしい。

まとめ

・ サーバ側で「秒間●リクエスト」をはかる時、ユーザ側のネットワーク帯域までは見ない( ユーザが有線を使っていようが3G回線を使っていようが、最終的に到達するサーバ周りのネットワーク領域は同じで、サーバ側のネットワーク領域側で特別な設定をしていない限りレスポンスの速度も基本的に同じだから )
・ 「秒間●リクエストをさばける」事が保障するのは、その量のリクエストが来た時にサーバがダウンすることなく稼動し続けられる事 と システム全体におけるボトルネックの特定が可能になる事
・ 「秒間で沢山リクエストをさばける＝ユーザがサクサクページを見られる」ではない
・ ただし必要最低限の秒間リクエスト数をクリアできないと 勿論ユーザへのレスポンス遅くなる
・ ユーザがサクサクコンテンツを利用する上で、秒間リクエスト数の話とは別にターゲットとなるユーザの媒体とか居住地は別途考慮する必要はある

…という認識です。

僕自身 まだまだ勉強不足な部分もございますので、「ここの部分根本から認識間違ってるよ」という部分がございましたら、優しくマサカリを投げていただければ幸いです。。。(´・_・`)

The post 「秒間●リクエスト」の具体的な定義がモヤモヤしていたので調べてみた話 appeared first on きのこる庭.

Vagrantfileの設定

# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
    config.vm.box = "Ubuntu_13"
    config.vm.box_url = "http://puppet-vagrant-boxes.puppetlabs.com/ubuntu-1310-x64-virtualbox-puppet.box"

  config.vm.define :ubuntu_1 do |ubuntu_1|
    ubuntu_1.vm.network :private_network, ip: "192.168.33.10"
  end  

  config.vm.define :ubuntu_2 do |ubuntu_2|
    ubuntu_2.vm.network :private_network, ip: "192.168.33.11"
  end  
end

こんな感じで Ubuntuの13.10を2台立てて、IPは192.168.33.10 と 192.168.33.11 の連番で割り振る。

$ vagrant up

ポートフォワードでこけるかなーと思ったら、Vagrantが勝手に衝突の解決をしてくれて localhost:2222 と localhost:2200 の2つを立ててくれた。うーん便利。
うまくサーバが2つ立ち上がったかを確認するために pingを飛ばしてみる。

$ ping 192.168.33.10
PING 192.168.33.10 (192.168.33.10): 56 data bytes
64 bytes from 192.168.33.10: icmp_seq=0 ttl=64 time=0.294 ms
64 bytes from 192.168.33.10: icmp_seq=1 ttl=64 time=0.273 ms
64 bytes from 192.168.33.10: icmp_seq=2 ttl=64 time=0.450 ms
64 bytes from 192.168.33.10: icmp_seq=3 ttl=64 time=0.463 ms
^C
--- 192.168.33.10 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.273/0.370/0.463/0.087 ms

$ ping 192.168.33.11
PING 192.168.33.11 (192.168.33.11): 56 data bytes
64 bytes from 192.168.33.11: icmp_seq=0 ttl=64 time=0.453 ms
64 bytes from 192.168.33.11: icmp_seq=1 ttl=64 time=0.669 ms
64 bytes from 192.168.33.11: icmp_seq=2 ttl=64 time=0.749 ms
64 bytes from 192.168.33.11: icmp_seq=3 ttl=64 time=0.601 ms
^C
--- 192.168.33.11 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.453/0.618/0.749/0.109 ms

うん、うまく立ち上がってくれてる。

実際にsshでサーバに入るときは vagrantユーザで以下のように入る。また、vagrantユーザのデフォルトのパスワードは vagrant。

$ ssh vagrant@192.168.33.10
$ ssh vagrant@192.168.33.11

今回はセキュリティの話ではないので、秘密鍵の設定やiptablesの設定等は省略。

MySQLをインストール

何はともあれマスタサーバ、スレーブサーバにMySQLが入っている必要がある。立ち上げたばかりの Ubuntuサーバであれば、まずはapt-get updateを打つ必要があるので、2つのサーバに対してこんな感じでコマンドを打つ。

$ sudo apt-get update
$ sudo apt-get install mysql-server

親切にもインストールの際にMySQLのrootログイン用パスワードの設定画面が出てきてくれるので、お好みのパスワードを設定しておく。

マスタサーバ側の設定

my.cnfの設定をする。

$ sudo vi /etc/mysql/my.cnf

mysqld の項目に以下の2つを加える。

[mysqld]
log-bin
server-id=1

log-bin は「スレーブサーバと同期を取る為に必要なバイナリログを出力する」という設定。
server-idは任意の数値で構わないが、スレーブサーバがマスタサーバのデータベースを参照するのに利用するので、スレーブサーバと重複しないようユニークなものを設定する必要がある。

また、mysqld設定の下にbind-addressに関する以下のような設定がある。このままだと外部サーバからの接続を受け付けてくれないため、ここではコメントアウトしてしまう( セキュリティを考慮するのであれば、別途 allow-hostsやdeny-hostsの設定が必要になりそう )。

# bind-address = 127.0.0.1

一連の設定が終わった所でmysqlを起動(デフォだとインストール後立ち上がっているみたいなのでrestartに)。

$ sudo mysql restart

とりあえず「test」っていうデータベースを作成して、こんな感じで「user」テーブルを作成する。話を簡潔にするために内部エンコーディング等諸々の設定は省略。

mysql> CREATE DATABASE test;
mysql> USE test;
mysql> CREATE TABLE users ( user_id INT PRIMARY KEY AUTO_INCREMENT NOT NULL, user_name VARCHAR(30) UNIQUE NOT NULL );

スレーブサーバがアクセスできるようにユーザをつくる。

mysql > GRANT REPLICATION SLAVE ON *.* TO 任意のユーザ名@192.168.33.11 identified by '任意のパスワード';

「test.*」じゃ駄目なの？って思ったけど、「レプリケーションはグローバルな設定だから駄目よ」みたいなニュアンスの事で怒られるから駄目みたい。

スレーブサーバへのコピーを取る際にデータベースに更新がかからないようテーブルをロック。
ロックしたら、マスタのステータスを見る。

mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;

ここで表示されたマスタステータスのFileとPositionは 「どの時点からレプリケーション取り始めればいいの？」という事をスレーブに教えてくれる大事な情報になるのでメモしておくこと。僕の場合、Fileはmysql-bin.000001、Positionは742。

その後 tarで固めてスレーブサーバにtarファイルをコピーする。

$ tar cvf test.tar.gz /var/lib/mysql/test

なお、InnoDBの場合 データベースのディレクトリだけコピーしても「show tablesするとテーブルが出るのに、desc や selectをしようとすると table doesn’t exist と怒られてしまう」…という問題があるらしく、僕も若干ハマった。解決方法としては /var/lib/mysql/ 下にある「ib」から始まるファイルもコピーする必要がある(さらに、コピーした後mysqlを再起動する必要がある)ということらしく(また、この際 権限がmysqlにある事をチェックすること)僕の場合はこれで解決した。
(参考: stackoverflow: Mysql > Table doesn’t exist. But it does(or it should))

コピーを取り終えたらロックの解除を忘れずに。

mysql> UNLOCK TABLES;

なお、今回はディレクトリをそのままコピーする方法でやったけれど、mysqldumpを使う方法もあるらしいので、ディレクトリコピーでうまくいかなかった人はこちらの方法を試してみると良いかもしれない。
( 2014.10.12 18:00 追記 – 試してみた所、mysqldump の方が ib系のデータを書き換えたり権限を書き換えたりする手間が省けるので総合的に楽でした。また、mysqldumpでの方法については以下のリンクを参考にさせていただきました )

(参考: MySQL レプリケーションのセットアップ手順)

スレーブサーバ側の設定

こちらも /etc/mysql/my.cnf を編集して mysqldにserver-idを付加しておく。この際マスタのserver-idと重複しないよう注意すること。

server-id=2

マスタサーバでコピーしたtarファイルを /var/lib/mysql/下で展開。

$ tar xvf test.tar.gz

権限まわりの確認は必ず行うこと。また、上にも書いたように InnoDBの場合は ibから始まるファイルもコピーしておかないと「テーブルが表示されるのに参照できない」問題が発生する可能性があるので注意。

準備ができたらMySQLを立ち上げる。

$ service mysql restart

いよいよマスタサーバと同期させるぞう。
…とその前に、念のためにtelnetを叩いてスレーブからマスタサーバにアクセスできるか確認しておこう(3306はMySQLのデフォのポート)。

$ telnet 192.168.33.10 3306

これで通ればOK。

mysql> CHANGE MASTER TO
          MASTER_HOST='192.168.33.10',
          MASTER_USER='上記のGRANTオプションで設定したユーザ名',
          MASTER_PASSWORD='上記のGRANTオプションで設定したパスワード',
          MASTER_LOG_FILE='SHOW MASTER STATUSで確認したファイル名',
          MASTER_LOG_POS=SHOW MASTER STATUSで確認したposition;
mysql> Query OK, 0 rows affected (0.00 sec)
mysql> START SLAVE;
mysql> Query OK, 0 rows affected (0.00 sec)

スレーブのステータスを見て Slave_SQL_Runnningが YES になっていることを確認すること。
また Last_IO_Errorあたりに変なエラーが出ていないか確認すること。
例えば 上手くコネクションが貼れていない場合は「error connecting to master」なんてエラーが出る。
↓ (例) マスタに上手く繋げていない時の スレーブのステータス。

レプリケーションのテストをしてみる

早速 レプリケーションが上手く構成できているかどうかテストしてみる。
まずはマスタサーバのtestデータベースにアクセス。

念には念を入れて ちゃんとマスタにアクセスしているかどうかを確認。

mysql> SHOW MASTER STATUS;
mysql> SHOW SLAVE STATUS;

ちゃんとマスタにいることが確認できたら、ドキドキしながらデータを入れてみる。

mysql> INSERT INTO users (user_name) VALUES ('hogeman');

次にスレーブサーバのtestデータベースにアクセス。

mysql> SELECT * FROM users;

スレーブサーバにも’hogeman’のデータが入っていたら成功。正常にレプリケーションが構成できていることになる。
「あれ…？反映されないぞ？」という場合は再度 SHOW SLAVE STATUS; でエラーが出ていないか確認してみる。

その他の処方箋

Q. MySQLをstartさせたり stopさせたりしてたら MySQLが起動できなくなった。

「Job failed to start.」とか「Can’t connect to local MySQL server through socket.」とか怒られる場合は 該当ディレクトリにsocketファイルがあるかどうかを確認する。socketファイルが無ければ touchコマンドか何かで socketファイルを作成し、権限を mysql:mysql に設定してあげる。
その後「sudo /etc/init.d/mysql start」「sudo mysql start」「sudo service mysql start」をそれぞれ試してみる。
大体はこれで解決するらしいけど、それでも駄目なようなら my.cnf ファイルが間違っている可能性があるのでチェックすること。
(例えば bind-address を複数設定しようとしていたり。bind-addressは一つのホストしか受けつけない)

Q. あれこれいじってたら スレーブ側で duplicate entryが出るようになってしまった。

スレーブ側でレプリ遅延が起きている。
こういう場合はSHOW SLAVE STATUS; でエラーログを追跡しながら 親と整合性を合わせる必要がある。
一個ずつ慎重にレプリ遅延している箇所を見ながら SQL_SLAVE_SKIP_COUNTER を回していく作業。

スレーブをストップして、

mysql> STOP SLAVE;

整合性を合わせながら SLAVE_SKIP_COUNTERを回して( SLAVE側に直接insert処理をかけてしまったり 整合性が合わなくなってしまった所は 別途 スレーブに追加してしまったデータを削除して AUTO_INCREMENTのスタート値を調整して…等の作業が発生する感じになるのかな…？ )、

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

再開する。

mysql> START SLAVE;

ただしskipに関しては トランザクション処理等を行う場合の挙動について若干注意が必要みたい。
(参考: Another reason why SQL_SLAVE_SKIP_COUNTER is bad in MySQL)

The post VagrantでUbuntuサーバを2台立ててMySQLでマスタスレーブ構成にしてみた appeared first on きのこる庭.

本当は「数千万件のデータが入ったテーブルでインデックスを構築したらパフォーマンスが劇的に改善された話」というタイトルで書こうと思ったのだけど、書いているうちに内部構造が気になり出したので上記のタイトルに変更。

まずはパフォーマンスが改善された話から

SELECT A FROM hoge WHERE B = ~~~ ORDER BY C DESC;

hogeは数千万件のデータが入ったテーブルで、その中から結果約4万件程のデータのうち A の部分をSELECT。条件としては、カラムBの値が~~~に合致するときで、更には Cという別のカラムで並び替えるというクエリになっている。

結果的に

ALTER TABLE hoge ADD INDEX foo ( B, C, A );

というインデックスを張ることによって、それまで2分以上かかっていたselect文が 0.1秒～0.2秒まで短縮されたという某赤いモビルスーツも驚きのパフォーマンス改善を見せた。

正直インデックスの劇的な威力に感動して、その喜びをブログにつづろうと思い立った所、以下の疑問が生まれたというのが始まり。

すなわち、

何で↓じゃだめなの？

ALTER TABLE hoge ADD INDEX foo ( A, B, C );

という話(どこかのブログで「インデックスは順序左から書かないと意味無いよ」と書いていたので)。

仮説

なんとなーく最近コンパイラをいじっていて記憶に新しい構文木的なにおいがするなあと感じた。

そこで、MySQLの構文解析機構を調べてみたところ、

案の定字句解析と構文解析をそれぞれFlexとBisonで行っているようなので、勉強がてらMySQLの構文解析ロジックを見てみることにした。

調査

丁度GoogleがMySQLのコードを出していたので、MySQLの構文定義部であるsql_yacc.yyの中身を拝見。

http://code.google.com/p/google-mysql/source/browse/sql/sql_yacc.yy?r=d15790ab618324fb1729aa212b244cad5cb9778f

まずは式全体の構文を探す。1600行目でみっけ。

/* Verb clauses, except begin */
statement:
alter
| analyze
| backup
| binlog_base64_event
| call
| change
| check
| checksum
| commit
| create
| deallocate
| delete
| describe
| do
  :
  :
  :

中には「select」もしっかり定義されていたので、続いてselectを探す。

6638行目から始まっているのがそれっぽい。

select:
select_init
{
LEX *lex= Lex;
lex->sql_command= SQLCOM_SELECT;
}
;

/* Need select_init2 for subselects. */
select_init:
SELECT_SYM select_init2
| '(' select_paren ')' union_opt
;

どんどん掘り下げていった結果、だいたいこんな感じになりました。

考察

選択するカラムと where句、order by句、 having 句、group by 句などの条件が明確に分断されていました。

つまり、select_from の部分は、よくあるコンパイラの factor = ( expression ) 的な感じで先に解析されていて、解析が終了した後でSELECT_SYM とがっちゃんこするのではないかと予想(定かではありません)。

こう考えると

ALTER TABLE hoge ADD INDEX foo ( B, C, A );

になるのはそこまで不思議な話ではないかなと感じた。

実際はどうだったのか(2014.03.26追記)

記事の公開後、友人から「covering index 的な話では」とご指摘をいただきました。

Covering Indexに関しては 以下の記事がとても参考になった。

MySQLでインデックスを使って高速化するならCovering Indexが使えそう

もう少しDBまわりの勉強もしないとなあと思いつつ、また新しいことを勉強させていただいた上にMySQLの内部構造にもちょこっと触れられたので 結果としては良かったかなと思った。

The post 【MySQL】インデックス指定の順序が気になったので、MySQLの構文解析ロジックを検証してみた話 appeared first on きのこる庭.

Vagrant？

簡単に言うとインフラ構築の自動化。
例えば 手動でやろうとすると、OS入れる度に VMでディスクイメージ読み込ませて あれやこれやと細かい初期設定しないといけないけど、Vagrantを使えばたった3つのコマンドで上に書いた事を勝手にやってくれる。
Vagrantは chefのようなツールと合わせて使えば超強力と巷では言われていて、要するにソフトウェアのインストールまで自動化してくれる。
これはどういうことかというと…

インフラ構築にいちいち時間かける必要もなくなるし、ミスも防げるし、チーム開発の場合は 新しく入ってきた人でもすぐに環境構築できるし、何より「俺の環境では動いたよ」も減る。

個人で勉強用に開発環境立てては壊しまくったりする場合にもかなり便利だけど、チーム開発でも圧倒的な力を発揮。

とりあえず 今回に関しては Chef を使用せずに VagrantでOSだけ入れてもらって、動作確認の意味合いを込めてWebサーバの立ち上げをやってみる。

因みにVMを動作させる環境はフリーで落とせる VirtualBox を使用。

CentOS導入編

最新のVirtualBox と Vagrant をインストール。

あとはコマンドラインで以下の3つのコマンドを叩くだけ。

vagrant box add centos https://github.com/2creatives/vagrant-centos/releases/download/v6.5.1/centos65-x86_64-20131205.box
vagrant init centos
vagrant up

※各OSとboxURLに関しては こちら に掲載されているものを参考にさせていただきました。

Webサーバ編

VagrantでOS立てる時に Vagrantfile という設定ファイルがローカルにできているのでそれを編集。

 # config.vm.network :private_network, ip: "192.168.33.10"

の行のコメントアウト部分(#)を消す。
( 因みに192.168.33.10 は vagrant で設定されているデフォルトのipアドレス )

続いてvagrantのサーバにアクセス。

( Macとかなら「vagrant ssh」 ってコマンドで打てば良いけど、Windows環境とかで怒られる場合はPuttyとか別のSSHクライアントを使用すること。なお、Windowsの場合もユーザ名とかホストとかポートとか諸々の情報は「vagrant ssh」で出てきます )

インストールとか httpdの編集とかするんで、最初に su で root になっておくと良いかも( Vagrantの場合、デフォのルートパスワードは vagrant )。

とりあえず細かい設定とか抜きにして単純にWebサーバ立てるだけなら まずは httpd くらいで十分なので

 yum install -y httpd

みたいな感じで httpd を入れてみる。

インストールしたら

/etc/httpd/conf/httpd.conf

をvi か何かで編集。

( 敢えて vim ではなく vi と書いたのは、vagrant経由でcentosをそのままインストールした時に vim がインストールされていなかったため。vimを使う場合は yum -y install vim とかで入れる )

ServerName の部分を 192.168.33.10 に。

続いて
/var/www/html/ の下のindex.html( 無ければ作成 )
を vi か何かで起動して一行目に お決まりの「Hello World」を。

service httpd start

( 次からhttpdが自動起動されるように chkconfig httpd on にしておくと良いかも )

ブラウザで

http://192.168.33.10/

にアクセス。

「Hello World」が表示されればOK。

今回はWebサーバ構築だけだったけど、念のためにポート変更とかルートログイン禁止とかパスワードログインから公開鍵認証に切り替えたりとか ServerTokensを Prod にしたりとか ServerSignatureをoffにしたりとか、最低限のセキュリティ設定はしてあげると良いかも。

( トップのロゴはVagrantの公式ホームページ http://www.vagrantup.com/  からお借りしています )

The post はじめてのVagrant ～ CentOS6.5 + ApacheでWebサーバを立ててみる appeared first on きのこる庭.