2018-01-01

EC2-Classic環境でデフォルトVPCを作成する

aws

概要

Amazon EC2で利用できるプラットフォームには、EC2-VPCとEC2-Classicの2種類があります。EC2-Classicが利用できる環境ではデフォルトVPCが存在しません。そのような環境でデフォルトVPCを作成するには、AWSサポートへの依頼が必要になります。

ただし、デフォルトVPCを作成するためには、そのリージョンに存在するEC2-Classicリソースを終了する必要があり、今後そのリージョンでEC2-Classicを使用することができなくなります。

EC2でサポートされるプラットフォーム

Amazon EC2のインスタンスを作成するためのプラットフォームには、以下の2種類があります。

EC2-Classic
- 他のユーザーとネットワークを共有する古いタイプのプラットフォーム
EC2-VPC
- VPCを用いたプライベートなネットワークを利用するプラットフォーム

2013年12月4日よりも後にAWSアカウントを作成した場合は、すべてのリージョンでEC2-VPCのみ利用可能になります。それ以前にAWSアカウントを作成している場合は、EC2-VPCとEC2-Classicの両方が利用できる可能性があります。そして、EC2-VPCのみ利用可能な場合にデフォルトVPCは用意されています。

詳細については以下のドキュメントが参考になります。

EC2-ClassicとEC2-VPCの違い https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-vpc.html#differences-ec2-classic-vpc

アベイラビリティーおよびサポートされているプラットフォーム http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/default-vpc.html#default-vpc-availability

自分の環境で利用できるプラットフォームは、EC2ダッシュボードの右上にあるアカウントの属性で確認することができます。サポートされているプラットフォームにEC2と記載があればEC2-Classicが利用できます。すなわちデフォルトVPCが使えない状態です。

f:id:speg03:20200327215526p:plain

CLIでも確認できます。

$ aws ec2 describe-account-attributes --region=us-east-1

{
    "AccountAttributes": [
        {
            "AttributeName": "supported-platforms",
            "AttributeValues": [
                {
                    "AttributeValue": "EC2"
                },
                {
                    "AttributeValue": "VPC"
                }
            ]
        },
...

デフォルトVPCの特徴

デフォルトVPCの特徴として大きな点は、そのVPCのリージョンに新しいアベイラビリティゾーンが追加されたとき、そのアベイラビリティゾーンに属するサブネットが自動的に追加される点です。

その他の特徴については以下を参照してください。

デフォルトVPCとデフォルトサブネット http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/default-vpc.html

デフォルトVPCの作成方法

EC2-Classicが利用できる環境でデフォルトVPCを作成するには、AWSサポートへの依頼が必要です。

サポートダッシュボード https://console.aws.amazon.com/support/home

サポートケースの作成から以下の選択肢で依頼をします。

内容: アカウントおよび請求サポート
サービス: アカウント
カテゴリ: その他アカウントに関する問題

f:id:speg03:20200327215558p:plain

説明欄でデフォルトVPCを作成したいリージョンを記載するとよいでしょう。EC2-Classicリソースが使えなくなってしまうことを了承済みであることも記載しておくとスムーズに対応していただけると思います。

ちなみに、もともと存在していたデフォルトVPCを削除してしまった場合はVPC Management ConsoleやCLIで作成することができるようです。

デフォルトVPC Q: デフォルト VPC を削除できますか? https://aws.amazon.com/jp/vpc/faqs/#D1

2015-08-02

VyOSで構築するVirtualBoxのプライベートネットワーク

概要

ローカルでの検証環境としてVirtualBoxの環境は手軽に構築できて便利です。VirtualBoxを使った環境で、ホストとゲスト間の通信や、複数のゲスト同士の通信を簡単に行うネットワーク構成を考えます。3パターンの構成について紹介し、そのうちの1つ、NATサーバーを使用したパターンについて詳しく紹介します。NATサーバーの構築にはVyOSを使用しています。

環境

VirtualBox 4.3.28
VyOS 1.1.5

構成の検討

次の要件を満たすような構成を検討します。

ゲストだけで構成されたプライベートネットワークになっていること
ゲスト間で相互に通信できること
ゲストからインターネットに通信できること
ホストからゲストに通信できること

3パターン考えました。

パターン1: NAT+ホストオンリーアダプターを使用した場合
パターン2: NATネットワークを使用した場合
パターン3: NATサーバーを使用した場合

パターン1: NAT+ホストオンリーアダプターを使用した場合

f:id:speg03:20200327215249p:plain

guest1, guest2
- アダプター1: NAT
- アダプター2: ホストオンリーアダプター

おそらく最も手軽な方法です。ネットワークの設定で1つはNAT、もう1つはホストオンリーアダプターを選択するだけです。ホストオンリーアダプターは任意のネットワークアドレスを設定することができます。NAT側のネットワークは相互に通信することができませんが、ホストオンリーアダプター側のネットワークは相互に通信することができます。これでゲスト同士の間は通信が可能で、ホストマシンとも通信することができます。

ただし、ネットワークインタフェースが2つずつ必要になってしまうため、検証環境としての用途では不都合が生じるかもしれません。（ネットワークインタフェースを自動的に選択するソフトウェアを使用する場合など）

パターン2: NATネットワークを使用した場合

f:id:speg03:20200327215314p:plain

guest1, guest2
- アダプター1: NATネットワーク

NAT+ホストオンリーアダプターの場合と比べて、ネットワークインタフェースが1つになっているため、より自然に検証環境として使用できると思います。NATネットワークも任意のネットワークアドレスを設定することができ、相互に通信することができます。

ただし、ホストマシンから直接ゲストへアクセスすることができないため、必要であればNATネットワークにポートフォワーディングの設定を追加する必要があります。

パターン3: NATサーバーを使用した場合

このパターンはVirtualBoxの機能だけでは実現できません。新しいインスタンスとしてNATサーバーを導入します。

f:id:speg03:20200327215330p:plain

guest1, guest2
- アダプター1: ホストオンリーアダプター
nat-server
- アダプター1: NAT
- アダプター2: ホストオンリーアダプター

前述した2パターンの欠点を補うパターンです。ネットワークインタフェースが1つであり、ホストマシンからゲストへの通信も可能となっています。ゲストからインターネットへ通信するためにはNATサーバーを経由することになります。（ゲストのデフォルトゲートウェイとしてNATサーバーのインタフェースを指定）

このパターンでは、NATサーバーのインスタンスが余分に必要になってしまいます。これさえ許容できれば自由にネットワークを構築でき、ホストマシンからもアクセスできる使いやすい環境を構築できると思います。

NATサーバーの構築

パターン3で紹介したNATサーバーの構築方法について紹介します。ここではVyOSを使います。

インスタンスの作成

前述したようにネットワークアダプターを2つもったNATサーバーのインスタンスを作成します。

nat-server
- アダプター1: NAT
- アダプター2: ホストオンリーアダプター

今回はVyOS自体でDHCPの設定を行うため、アダプター2のホストオンリーアダプターにあるDHCPの機能を無効にしておきます。NATサーバーとしてDHCPの機能が必要というわけではありませんが、あると便利だと思います。

インストール

参照: http://wiki.vyos-users.jp/

インストールメディアはvyos-1.1.5-amd64.isoを使用しました。

インストールメディアから起動してログイン後、インストールを行います。ログインユーザー、パスワードは共に vyos です。詳細についてはWebサイトのユーザーガイドを参照してください。

$ install image
（下記、ディスク消去の確認以外はデフォルトでOK）
...
This will destroy all data on /dev/sda.
Continue? (Yes/No) [No]: Yes
...

インストールが完了したらインストールメディアを抜いて再起動します。

$ reboot

NATサーバーの設定

以下のような設定を行います。

ネットワークアドレス: 192.168.133.0/24
NATサーバーのIPアドレス: 192.168.133.100
（オプション）DHCPで割り当てるIPアドレスの範囲: 192.168.133.101 - 192.168.133.254
（オプション）NATサーバーにDNS転送させる

設定手順

ユーザーガイドのクイックスタートがほぼそのまま使えます。一部設定値を変更しています。

設定を開始します。

$ configure

インタフェースの設定を行います。

set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 description 'OUTSIDE'
set interfaces ethernet eth1 address '192.168.133.100/24'
set interfaces ethernet eth1 description 'INSIDE'

このサーバーにSSH接続するための設定をします。（オプション）

set service ssh port '22'

NATの設定を行います。

set nat source rule 100 outbound-interface 'eth0'
set nat source rule 100 source address '192.168.133.0/24'
set nat source rule 100 translation address masquerade

DHCPサーバーの設定をします。（オプション）

NATサーバーをデフォルトゲートウェイ、DNSサーバーとして設定しています。（default-router, dns-serverの行）

set service dhcp-server disabled 'false'
set service dhcp-server shared-network-name LAN subnet 192.168.133.0/24 default-router '192.168.133.100'
set service dhcp-server shared-network-name LAN subnet 192.168.133.0/24 dns-server '192.168.133.100'
set service dhcp-server shared-network-name LAN subnet 192.168.133.0/24 domain-name 'internal-network'
set service dhcp-server shared-network-name LAN subnet 192.168.133.0/24 lease '86400'
set service dhcp-server shared-network-name LAN subnet 192.168.133.0/24 start 192.168.133.101 stop '192.168.133.254'

DNS転送の設定をします。（オプション）

DNSサーバーについては適宜必要なものを設定してください。

set service dns forwarding cache-size '0'
set service dns forwarding listen-on 'eth1'
set service dns forwarding name-server '8.8.8.8'
set service dns forwarding name-server '8.8.4.4'

ここまでの設定を保存して終了します。

commit
save
exit

設定内容を確認します。

$ show configuration

設定を誤った場合はそのコマンドのsetをdeleteで置き換えて実行すると削除できます。

delete interfaces ethernet eth1 address '192.168.133.100/24'

まとめ

VirtualBoxでのプライベートネットワークの構築について3パターンの方法を紹介しました。その中でNATサーバーを使用した方法について、VyOSによる構築手順を紹介しました。余分にNATサーバーの構築と設定が必要にはなりますが、より使いやすい自由度の高いネットワーク構成を取ることができます。また、VyOSを使ったNATサーバーはVirtualBox以外の環境でも同様に活用することができます。

2015-05-29

CentOSにWordPressをインストールする（Docker版）

centos docker

概要

CentOS上でDockerを使ってWordPressを動かす手順について紹介します。Dockerを使うことで簡単にWordPress環境を構築することができます。

環境

CentOS 7.1.1503
Docker 1.6.0
Docker Compose 1.2.0
WordPress 4.2.2

Dockerのインストール

DockerとDocker Composeをインストールします。今回はWordPress本体とデータベースを別々のコンテナとして立ち上げます。このような場合にはDocker Composeを使うと便利です。

参照: https://docs.docker.com/compose/install/

Dockerをインストールします。

# yum install docker

Docker Composeをインストールします。

# curl -L https://github.com/docker/compose/releases/download/1.2.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
# chmod +x /usr/local/bin/docker-compose

Dockerデーモンの自動起動を設定し、起動します。

# systemctl enable docker
# systemctl start docker

WordPressの構成ファイルを作成

WordPressのDockerイメージは公式のものが存在し、手順も書かれているため、ほとんどそのまま実行します。

参照: https://registry.hub.docker.com/_/wordpress/

WordPressをDockerで動かすための構成ファイルを適当な場所に作成します。

# vi docker-compose.yml

wordpress:
  image: wordpress
  links:
    - db:mysql
  ports:
    - 8080:80

db:
  image: mariadb
  environment:
    MYSQL_ROOT_PASSWORD: example

WordPress本体のイメージとMariaDBのイメージを使用します。portsの左側がホスト側で待ち受けるポート番号になります。MYSQL_ROOT_PASSWORDはその名の通りデータベースのrootパスワードです。必要に応じて適宜変更してください。

WordPressの起動

作成したdocker-compose.ymlと同じディレクトリ上で実行します。

# docker-compose up

初回は必要なDockerイメージをダウンロードするため時間がかかります。以下のようなメッセージが最後に出たら起動完了です。

wordpress_1 | [Wed May 27 15:57:23.083800 2015] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'

WordPressの初期設定

http://<ホスト名 or IP>:8080/ にアクセスして初期設定を行います。

f:id:speg03:20200327215140p:plain

2015-03-02

HTTPプロキシ環境におけるdocker build

docker

（追記 2016/06/25） Docker 1.9よりdocker build時に環境変数を渡せるようになっていました。そのため、この記事に書いていたような面倒なことは必要なくなりました。

以下のようにHTTP_PROXY環境変数を渡しながらビルドすることができます。

$ docker build --build-arg HTTP_PROXY=http://10.20.30.2:1234 .

以下も参照してください。

（追記おわり）

概要

HTTPプロキシを経由しなければインターネットにアクセスできない環境において、インターネットアクセスが必要なdocker build（アプリケーションパッケージのインストールなど）を行うには環境変数の設定が必要になります。しかし、環境変数の情報をDockerfileに書いてしまうとプロキシ環境以外で使いにくくなってしまいます。

そこで、Dockerfileは環境によらず使えるように、プロキシ設定をDockerイメージに埋め込む方法について説明します。

例題

例として以下のようなDockerfileを作成するとします。fedora:21を使ってApacheをインストールしたDockerイメージを作成するものです。

FROM fedora:21
RUN yum update -y && yum install -y httpd && yum clean all

このままdocker buildしても、プロキシを越えられずyumコマンドの実行に失敗します。

$ docker build -t httpd .
Sending build context to Docker daemon 2.048 kB
Sending build context to Docker daemon
Step 0 : FROM fedora:21
 ---> 834629358fe2
Step 1 : RUN yum update -y && yum install -y httpd && yum clean all
 ---> Running in ad13de39b3ac

（中略）

Cannot retrieve metalink for repository: fedora/21/x86_64. Please verify its pat
h and try again
INFO[0005] The command [/bin/sh -c yum update -y && yum install -y httpd && yum
clean all] returned a non-zero code: 1

このDockerfile自体にENV http_proxy http://proxy.example.com:8080とプロキシ設定を追記しても構いませんが、プロキシ環境に依存したDockerfileとなってしまいます。Dockerfileには変更を加えず、特定の環境に依存しないようにします。

ONBUILDによるプロキシ設定の埋め込み

ベースとなるDockerイメージにONBUILDでプロキシ設定を埋め込むようなスクリプトを作成します。スクリプトの名前は何でもよいですが、ここではdocker-http-proxyとします。

ベースとなるDockerイメージ（FROMで指定）と作成するDockerイメージ（docker build -tで指定）の両方に同じ名前を指定しています。

#!/bin/sh

if [ $# != 1 ]; then
   echo "Usage: $0 DOCKER_IMAGE"
   exit 1
fi

cat <<EOF | docker build -t $1 -
FROM $1
ONBUILD ENV http_proxy $http_proxy
ONBUILD ENV https_proxy $https_proxy
ONBUILD ENV no_proxy $no_proxy
EOF

プロキシ設定に関する環境変数は実行中のシェルですでに設定されているものとします。設定する値は適宜読み替えてください。

export http_proxy=http://proxy.example.com:8080
export https_proxy=http://proxy.example.com:8080
export no_proxy=127.0.0.1,localhost

例として、fedora:21イメージにプロキシ設定を埋め込む場合は以下のように実行します。

$ docker-http-proxy fedora:21
Sending build context to Docker daemon 2.048 kB
Sending build context to Docker daemon
Step 0 : FROM fedora:21
 ---> 834629358fe2
Step 1 : ONBUILD env http_proxy http://proxy.example.com:8080
 ---> Running in 7293472d9793
 ---> 35244c2f0c76
Removing intermediate container 7293472d9793
Step 2 : ONBUILD env https_proxy http://proxy.example.com:8080
 ---> Running in 4a52cac11df4
 ---> 5190135a8d40
Removing intermediate container 4a52cac11df4
Step 3 : ONBUILD env no_proxy 127.0.0.1,localhost
 ---> Running in fedf6baa373a
 ---> eda7740be6ee
Removing intermediate container fedf6baa373a
Successfully built eda7740be6ee

これでプロキシ設定済みのfedora:21イメージが完成しました。

最初の例に挙げたDockerfileを再びビルドしてみます。

$ docker build -t httpd .
Sending build context to Docker daemon 2.048 kB
Sending build context to Docker daemon
Step 0 : FROM fedora:21
# Executing 3 build triggers
Trigger 0, ENV http_proxy http://proxy.example.com:8080
Step 0 : ENV http_proxy http://proxy.example.com:8080
 ---> Running in 1d862437b875
Trigger 1, ENV https_proxy http://proxy.example.com:8080
Step 0 : ENV https_proxy http://proxy.example.com:8080
 ---> Running in 2483039ae324
Trigger 2, ENV no_proxy 127.0.0.1,localhost
Step 0 : ENV no_proxy 127.0.0.1,localhost
 ---> Running in 6cf89a748f98
 ---> c00437a577bd
Removing intermediate container 1d862437b875
Removing intermediate container 2483039ae324
Removing intermediate container 6cf89a748f98
Step 1 : RUN yum update -y && yum install -y httpd && yum clean all
 ---> Running in 3b5ba7989288

（中略）

Complete!
Cleaning repos: fedora updates
Cleaning up everything
 ---> 2c8f2b5806be
Removing intermediate container 3b5ba7989288
Successfully built 2c8f2b5806be

今度はONBUILDで埋め込んでおいたプロキシ設定が読み込まれ、正常にビルドが終了しました。

すでにONBUILDが含まれているイメージの場合

今回は、ONBUILDを利用してプロキシ設定を行いました。この方法では、すでにONBUILDによる処理が設定されていた場合に共存することができません。ONBUILDは次に行うdocker buildでしか効果を持ちません。このような場合には、さらに元のベースイメージに対してプロキシ設定を行うことになります。

例えば、すでにONBUILD処理が記述されたrails:onbuildイメージを考えてみます。rails:onbuildイメージはruby:2.2.0イメージをベースとしています（執筆時点）。

ruby:2.2.0イメージにプロキシ設定を追加します。

$ docker-http-proxy ruby:2.2.0

次にrails:onbuildイメージを手元で作成します。

$ git clone https://github.com/docker-library/rails.git
$ cd rails/onbuild
$ git checkout 3c87a6cf32d01204b95ba12a266d13c8c32e5358
$ docker build -t rails:onbuild .

これでプロキシ設定が追加されたrails:onbuildイメージが完成します。

2014-02-04

パスワードに使えるランダム文字列を生成するコマンド

macos ubuntu centos

Mac OS、Ubuntuならpwgen、CentOSならmkpasswdが使える。

pwgen

インストール

Mac OS

$ brew install pwgen

Ubuntu

$ sudo apt-get install pwgen

使い方

そのまま実行すると8桁英数字で大量に生成される。

$ pwgen
gueV9aeg eeC3Chah jooSood0 aupooH1a Li9wango quieC9Oe hieToh2P Sa2zotaJ
looD0Iem eeM8Oof1 au1Ieshi vuz9Eshe Aijip9ie phahB9fo Eiw0ou7p oovooW1f
Ohy3Aphe buXieh6m ju3ahh7Y auPh7wei ieGh7uch Chi8Miek xeiChuo3 Ahv9OhCi
aezoo1Ki Vie5mai5 Weeki1ee AhkaeSh3 Eil1phoo dohp8aiP Ohgi7ahB paiN7wae
Yiechoz7 ahlae3oM Shief7uu lah3weB5 Ahp1gie5 meePh6po Aes5sooF iegh3Eec
jei9Pueg tahJ5Lah AK4rethu shih3Jig hoo7Oy9O Uoge4pai Goo9phe4 aim2xohX
gohn4Zib Oa4phuel equa1Aij Yohb9oor Aing4ahj Eidae8ah taZoang6 phaeZ0Uu
ulae1Yae Ei6Pal2o Ohy8xein aiHu2cee vai3lieN koo0ohBo rai2Jaeg ChieK3fe
ahn4Ohng Aigae0uo Aez9Fae8 Yaemoo1s sheeGho4 ChieL5ah Ohn9zeiP iega6Cae
Zaeji2Oe Cahgh7Qu ohlieTu1 NahDu2ip Oofaik4a ruyao0Ph aef3iThe eo2Iepew
Ga0quoje Ohqu5ohb AhJohp9i Xoeghuu9 Eegez0ae Aelip2Ko aiK2xieB ohl4Dah5
EeRook5l Oni9Kaeh oev9aiGh gei4Si9j chouVi9v Thoowah3 zai0aiS7 ii6Ab5ee
Nieco9Ah ooGhee0o shiuLo2J feeWaiv8 anae4EiX Wu2ieng4 aiSh8pah eikaic2I
aBeighi1 Ohsh3vet Phook9Ub ahKazoo7 aequ4ieS On8Li6th iY1chien eiV6eika
noS6xeuW paji6Oob Rahbeza2 Ahquei2U chaeSae7 vaiL9Aes ia4Thoh5 eenaM0de
aeMo9eeg aeyee4Ex af2eizeH Naixa3cu Sohph4ie eiZie1Ci to4idiFi uugh8Hu1
OhD5shis aQuu9Ia2 imah1Kuy AmuGh1ae Liex1yiy OhB5ie8c coh4Eyiw YiiDe1th
poh0JeCh aelee2Ah iphe1Moh eet3bieR ieBe0ooH He3iruav hiex2aGa jee8Ozah
Rohnay6I kaiWaih4 Oogieth4 XahQu0na eeT7heir Rahtah0a doo3LuX1 shie0Ov6
Rah2mei3 ud2Roozi eaShah5s ukoo8aeR jeiPhai4 iZ7Eef2W ga9xoPie IeN4Ahm0

さすがに多いのでオプションを指定する。例えば、16桁のパスワードを1つ生成する場合。

$ pwgen 16 1
Shohjo0Caghi1uth

記号付き(-y)にしたり。

$ pwgen -y 16 1
aequohd:iemief2U

やっぱり数字なし(-0)にしたり。

$ pwgen -0 16 1
ohwoogaeZeiduoju

大文字もなし(-A)にしたり。

$ pwgen -0A 16 1
heiraeyaishahtai

複雑な感じ(-s)に。

$ pwgen -s 16 1
5ZNsNN4hSwknZ3nZ

複雑で記号付き。

$ pwgen -sy 16 1
Q;6ldK^_i$v]`sAr

mkpasswd

インストール

CentOS

$ sudo yum install expect

使い方

デフォルトは9桁英数字記号。

$ mkpasswd
8Idde4Iz.

桁指定(-l)で16桁に。

$ mkpasswd -l 16
efaIovqzoyEar)06

含める数字の個数(-d)を5つにしたり。

$ mkpasswd -l 16 -d 5
r03diHgvUtor9"11

数字を含めないように。

$ mkpasswd -l 16 -d 0
jokJkhxyzdA;ecuu

英小文字の個数(-c)と英大文字の個数(-C)もある。

$ mkpasswd -l 16 -c 8 -C 5
LgtIgKNv3ki9ttJ~

指定する数は最低でもいくつという値なので、それより多く使われることがある。

2013-07-15

Vagrant meetupに行って来ました

概要

Vagrant meetup 〜作者 Hashimoto氏の来日講演〜

2013年7月12日(金)に株式会社VOYAGE GROUP様の会場にて、Vagrantの開発者であるMitchell Hashimotoさんの講演を聞いて来ました。

「Vagrantについてのお話」として話された内容のメモと、そのあと所感などについて書きます。

（合わせて読みたい）「Vagrant」は仮想環境をプログラミングするツール。同一環境をどこにでも、いくつでもすぐに作成可能。Vagrant meetup 2013 - Publickey

Vagrantについてのお話

Vagrant

vagrant up とコマンドを打つだけで簡単に仮想環境が手に入る。
最近のOSSでは、Vagrantで使用する設定ファイル(Vagrantfile)を公開している場合も多く、簡単にそのアプリケーションを試すことができるようになっている。
- Vagrantfileもソースコードと同様にバージョン管理をしておく。

Vagrantのユースケース

Consistency

開発を行っているローカルマシンと実際に稼働するプロダクション環境は異なる。違いを埋める必要がある。
丁寧すぎるREADME（手順書）は読むのも実行するのも大変。
- ヒューマンエラーを引き起こす。
- メンテナンスが困難。
- インストール作業で次から次に依存するパッケージが足りないとエラーが出る。
- 設定漏れが発生する。
Vagrantは、どんな環境でも、誰がやっても同じように環境が構築できる。

Iterative

環境構築を行うシェルスクリプトがあるとして、 1. スクリプトを修正したら 2. サーバを新しく立ち上げて 3. スクリプトを適用して 4. 出来上がった環境を確認する。

サーバを立ち上げてスクリプトを適用し終わるまで、ひどい場合だと30分以上もかかるかもしれない。環境ができあがる30分間ずっと待っているなんていうのは生産性が低すぎる。

Vagrantはこの環境構築サイクルを繰り返し行うことが簡単にできるようになっている。

Isolation

開発、テスト、プロダクションのそれぞれの環境を共通した操作で構築できる。
特定の環境に特化していない。
再利用性が高い。

Safe Experimentation

試しに環境を作ってすぐ捨てられる。
トライ＆エラーがしやすい。

実績

多くの企業でも使用されており、安定していて、成熟してきている。

最高の開発フロー

The Tao of Vagrant

Vagrantは空気のような存在。
vagrant up とするだけでステージング環境でもプロダクション環境でも構築できる。
Vagrant使っていればチーム間、企業間で同じフロー、知見を共有することができる。
「僕の環境では動いているよ！」がなくなる。

Vagrantの機能

Synced folder

Vagrantを起動したホストとゲスト間での共有フォルダ機能。
Vagrantで作成した環境からホスト側のフォルダをマウントする。
ホスト側から好きなエディタを使ってファイルを編集することができる。

Networking

Vagrantfileにネットワークの設定を書いておけば起動時に設定してくれる。
好きなブラウザやデバッガからアクセスすることができるようになる。

Provisioning

Chef/Puppet/CFEngine/シェルスクリプトを使ってプロビジョニングを行うことができる。

Multi-Machine

Vagrantfileに複数のVM設定を記述することができる。
プロダクション環境のモデル化を行える。

Vagrantの歴史、ロードマップ

Vagrantのこれまで

2010年バージョン0.1
- VirtualBoxのみ。
- chef-soloのプロビジョニングのみ。
- ゲストはUbuntuのみ。
2012年バージョン1.0
- プロビジョニングにPuppet/CFEngine対応。
- ゲストはLinuxなら何でも。
2013年バージョン1.1
- VirtualBox以外のProvider対応。
- ホストにWindows対応。

Vagrant 2.0へのパス

バージョン1.0時代のVagrantfileでも使用できるようにする。（後方互換性）
バージョン1.3+
- Boxの自動構築に対応。
- ゲストにMac、Windows対応。

Multi-Providerについて

Vagrantがもともと扱えるVirtualBoxはどんな状況でも使えるというわけではない。バージョン1.1から他のProviderに対応した。AWS (EC2), RackSpace, LXC, VMware。

ローカルで開発して、リモートで別のProviderを使ってテストするという使い方ができる。
vagrant up でステージング環境もプロダクション環境も構築する。
LXCを使うとVagrant in Vagrantなんていうことも可能。
企業向けにはVMwareが使える。
同じVagrantfileを複数のProviderに対して使用することができる。
パフォーマンス最適化のために各Provider向けにオプション（CPU、メモリなど）を設定することも可能。

Packerについて

Packer

Hashimotoさんが作成されたBoxを作るためのツール。
2013年6月にリリースされた。
下準備をしたBoxを用意するのと、下準備を行うためのスクリプトを用意するのはケースバイケース。
- Boxを作ると変更するのに手間がかかってしまう。
- スクリプトであまりに多すぎる下準備をするとそれ自体の実行で時間がかかってしまう。
PackerはBoxの作成を自動化することで、アジャイル性を損なわないようにすることを目指す。

全体の所感

Vagrantはちょこちょこ使っているので、今回のお話はすんなり聞くことができました。

vagrant upの手軽さ

vagrant up とするだけで簡単に環境を立ち上げられるという話。

これは本当に手軽で、LXCのDockerや、フォーラムのDiscourseは自分でも試してみたことがありますが本当に簡単です。

Boxの作成

Boxを自分で作成したことは今までなかったのですが、ある程度、環境が固まってきてチーム内などで共有する場合には、Boxを作ってしまった方が良さそうという気がしました。今までは vagrantup.com などで公開されている、ほぼ素のUbuntuのBoxをベースにして、手作業で下準備を行い、スナップショットを取っておくという使い方をしていました。

Packerを使うと同じひな形から別のProvider向けのBoxを作成できるという話があったので、そういった場合や、OSのインストールからBoxを作成したい場合に使うものなのだと思います。

ただ、Packerやveewee（少し前からあるまた別のBox作成ツール）は、個人的に少しとっつきにくいイメージがあります。VirtualBoxのUbuntuやCentOSで良ければ vagrantup.com や opscode/bento などでほぼ素のBoxが提供されているため、それをベースにして下準備を行ったものを vagrant package でBoxにするのが良い気がします。

プロダクション環境での利用について

Multi-Provider機能を使って開発環境とプロダクション環境を同じ操作で構築するというのはあくまで理想形かなと思います。というのは、プロダクション環境を構築するために使うのはまだ少し難しそうな気がしました。

お話の中でもされていましたが、AWSに対してはネットワーク設定が無視されてしまうようです。また、Vagrantで立ち上げた環境はvagrantユーザやinsecureな認証キーが含まれているので、プロダクション環境で使う場合には、そういった不要な設定などを無効にする後始末が必要になるのではないかなという気がしています。

最後に

今回はVagrant開発者であるHashimotoさんから直接お話を聞くことのできる貴重な機会でした。開発フローや今後のロードマップなど参考になる内容も聞くことができたので良かったと思います。

Hashimotoさんの最後のスライドにもありましたが、まとめはやはりこれで。

「Vagrantを使いましょう！」

2013-01-13

CentOSにWordPressをインストールする

（追記）CentOSにWordPressをインストールする（Docker版）を公開しました。

環境

CentOS 6.3 x86_64
WordPress 3.5 日本語版

インストール

必要なパッケージのインストール

# yum install httpd mysql-server php php-mysql php-mbstring

DBの準備

# chkconfig mysqld on
# service mysqld start
# mysql_secure_installation
（rootのパスワードを設定して、残りはデフォルトで良いと思う）

データベースとユーザを作成する。

# mysql -uroot -p
mysql> create database wordpress;
mysql> grant all privileges on wordpress.* to wordpress@localhost identified by 'wordpress';
mysql> flush privileges;
mysql> quit

WordPressの配置

EPELにWordPressがあったのだけど、日本語対応することを考えると最初から日本語版を持ってきた方が楽な気がしたのでそうしてる。

# cd /var/www/html
# curl -LO http://ja.wordpress.org/latest-ja.tar.gz
# tar xvzf latest-ja.tar.gz

設定ファイルwp-config.phpをひな形から作成する。

# cd wordpress
# cp wp-config-sample.php wp-config.php
# vi wp-config.php

MySQL設定のデータベース名、ユーザ、パスワードを以下のように設定する。

// ** MySQL 設定 - こちらの情報はホスティング先から入手してください。 ** //
/** WordPress のためのデータベース名 */
define('DB_NAME', 'wordpress');

/** MySQL データベースのユーザー名 */
define('DB_USER', 'wordpress');

/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'wordpress');

Apacheユーザがwordpress ディレクトリに書き込めるようにする。

# chown -R apache:apache /var/www/html/wordpress

記事のパーマリンク設定をカスタマイズするには.htaccessファイルを有効にする必要があるのでその設定。

.htaccess自体は/var/www/html/wordpress/.htaccessに自動で作成される。

# vi /etc/httpd/conf.d/wordpress.conf

<Directory /var/www/html/wordpress>
  AllowOverride All
</Directory>

Apacheの起動

# chkconfig httpd on
# service httpd start

WordPressの初期設定

ブラウザから http://ホスト名/wordpress/wp-admin/install.php にアクセスする。

適当に入力欄を埋めてインストール完了。