Vagrantで、ansible_localを使ってみる

VagrantでゲストOSをセットアップするには、次の3通りがあります。

  1. Vagrantfileの中ではプロビジョニングを使わず、ゲストOSを立ち上げるだけにして、ansible単独でゲストOSを操作する方法
  2. Vagrantfileの中でconfig.vm.provision 'ansible_local'として、Vagrantのansible_localというプロビジョニングを使う方法
  3. Vagrantfileの中でconfig.vm.provision 'ansible'として、Vagrantのプロビジョニングを使う方法

このうち、今回はansible_localを使う方法を試してみます。

Vagrantのプロビジョニングでansible_localを使う場合には、ホストOSにはansibleをインストールしてある必要はありません。

ゲストOSにansibleが自動的にインストールされ、そこでansible-playbookが実行されます。

ポイントは2つあります。1つは、Vagrantfileでprovisionにansible_localを設定します。2つめは、Playbookでconnection: localを使うことです。

ansible_localを指定すると、ゲストOSにansibleが自動的にインストールされます。

実際の例は以下の通りです。

Vagrantfileは次の通りです。プライベートアドレスに192.168.33.10を指定して、provisionにansible_localを指定します。Playbookにsite.ymlを指定し、インベントリファイルにhostsを指定しています。

Vagrantfile

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "ubuntu/xenial64"

  config.vm.network "private_network", ip: "192.168.33.10"
  
  config.vm.provision "ansible_local" do |ansible|
    ansible.playbook = "site.yml"
    ansible.inventory_path = "hosts"
    ansible.limit = 'all'
  end
end

インベントリファイルは次の通りです。vagrantsというグループにubuntu01というホスト名のサーバーがあり、アドレスは192.168.33.10としています。

hosts

[vagrants]
ubuntu01 ansible_host=192.168.33.10

Playbookは次の通りです。vagrantsというグループに、connection: localという設定で、ubuntuというユーザーにログインします。そこで、Apache2をインストールしています。

site.yml

---
- hosts: vagrants
  connection: local
  user: ubuntu
  tasks:
    - name: install packages Apache2
      apt: name=apache2 update_cache=yes
      become: yes

connection: localがないと、次のようなエラーになります。

TASK [Gathering Facts] *********************************************************
fatal: [ubuntu01]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: Host key verification failed.\r\n", "unreachable": true}
        to retry, use: --limit @/vagrant/site.retry

connection: localを使わないと、ゲストOSにansibleをインストールしてあるのに、わざわざ自分自身にsshでログインしてplaybookを実行しようとします。そのとき、SSHのエラーになります。

ansible_localを使うと、ansibleは自動的にインストールしてくれますので簡単ですね。

AnsibleにはGitによる管理が必須です

Ansibleを使って構成管理をしだすと、少し設定を変更しては試してみることが増えます。特に、AnsibleやDockerを学ぶ際には繰り返すことが多いです。Vagrantを使っていると特に設定して試してみてという試行錯誤が簡単なので、変更が多くなります。

そうすると、ここを変更したいけど、後でまた必要になるからコメントアウトしておこうとかしたくなります。

また、少しづつ変えると何のために変更したのか後で見直すとよくわからないということになります。

そこで有効になるのがGitです。

Gitで設定ファイルを管理すると、とりあえず今の状態を保存しておこうということが簡単にできます。また、動かなくなった時でも簡単に元に戻せます。

あれ、このプログラム以前は動いたはずだけど、なんで動かないのだろうとよくあるのではないでしょうか。また、Gitでとりあえず保存はしておいて、過去のコードが役に立ったというような経験がありませんか。そのとき初めてGitの良さがわかるようになります。

Git無しではなんか不安、になれば十分使いこなしているといえましょう。

別に、Git中毒になれと言っているわけではないです。時々でもいいからコメント付きで保存しておくと、いざという時役に立ちます。

サーバーの構成管理がファイルでできるようになっていることが大きいです。ファイルを保存してきさえすれば、以前の状態のサーバーを簡単に作り出すことができます。

幸いにして、Git使っているけどなんでいいのかわからない、なんて場合もあると思います。そういう場合は、作業記録を残しておくことに意義を見出しましょう。

Ansibleで開発しようと思ったらとりあえずgit init。できた!、動いた!と思ったらとりあえずgit comit。これを習慣にしておくといいです。

AnsibleのインベントリファイルはLinuxのhostsファイルとは違う

インベントリファイルはhostsという名前になっていることが多いです。

Ansibleを使い始めた時、Linuxの/etc/hostsファイルと一緒なのかと思っていました。

よく紹介されている例でも、IPアドレスが直書きされています。

それでも動くのですが、調べていくうち/etc/hostsファイルとは違うことがわかってきました。

インベントリファイルは、ホストの名前とその設定を書く場所です。

よくある例では、

[default]
192.168.33.10

と書かれています。これは、defaultグループに192,168.33.10でアクセスできるホストがあるという設定です。

でも、次のような書き方もあります。

host01 ansible_host=192.168.33.10

[webservers]
host02 ansible_host=192.168.33.20

このインベントリファイルの意味は、host01はグループに属していません。IPアドレスは、192.168.33.10です。webserversというグループにhost02という名前のマシンがあって、そのIPアドレスが192.168.33.20という意味です。

どうもインベントリファイルは、/etc/hostsファイルとは違って名前を設定するファイルのようです。

Ansibleのtutorialを見てみると、Getting Startedでは、

192.0.2.50
aserver.example.org
bserver.example.org

このように直書きしたものもありますが、Inventoryの説明では、

mail.example.com

[webservers]
foo.example.com
bar.example.com

[dbservers]
one.example.com
two.example.com
three.example.com

このようにすべて、名前で設定されています。

また、IPアドレスだけでなくいろいろな設定を書くことができます。

ansible_connectionで接続方法が設定できたり、ansible_userで接続時のユーザー名を設定できたりします。

foo.example.com ansible_host=192.168.33.10 ansible_connection=local ansible_user=foo

:varsという拡張子をつけることでグループを一括して設定を書くことができます。

[webservers]
foo.example.com
bar.examble.com

[webservers:vars]
ansible_connection=local
ansible_ssh_private_key_file=/home/example/.ssh/aws.pem

AnsibleのインベントリファイルはLinuxのhostsファイルとは違うという話でした。

AnsibleでゲストOSをセットアップする

前々回でAnsibleをインストールし、前回でVagrantで作ったゲストOSにSSHで接続できることがわかりました。Ansibleを使う環境は整ったので、Ansible単独でゲストOSをセットアップします。

手順はまず、Vagrantでサーバーを用意します。次に、Ansibleの設定をansible.cfgにして、扱うサーバーの設定を書いたhostsという名前のインベントリファイルを用意して動作確認をします。それが出来たら、Playbookを作成して実行してみます。

なお、Windows上のAnsibleの設定ではこちらのCygwinの情報を参考にしました。

Vagrantfileファイル

用意したサーバーは、次のようなVagrantfileで作りました。

Vagrantfile

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "ubuntu/xenial64"

  config.vm.define 'ubuntu01' do |host|
    host.vm.hostname = 'ubuntu01'
    host.vm.network "private_network", ip: "192.168.33.10"
  end

  config.vm.provision 'shell', inline: <<-SCRIPT
    # aptのソースファイルを書き換え
    sed -i s%archive.ubuntu.com/ubuntu%ftp.jaist.ac.jp/pub/Linux/ubuntu/%g /etc/apt/sources.list
    apt-get update
    apt-get -y install python aptitude
  SCRIPT

end

ゲストOSには、ubuntu/xenial64を選びました。ubuntu01という名前にして、IPアドレスは、192.168.33.10にしました。

ubuntu/xenial64にはPythonがインストールされていません。Ansibleは、PythonのコードをゲストOSに送り込んで実行します。そのため、あらかじめPythonをインストールしていおきます。ダウウンロードの時間を短縮するために、aptのソースファイルを編集してあります。

ansible.cfgファイル

次に、Ansibleの設定をするansible.cfgを作ります。vagrant ssh-configの結果をもとに次のようなファイルを作りました。

ansible.cfg

[defaults]
inventory = hosts
remote_user = ubuntu
host_key_checking = False
private_key_file = C:/msys32/home/kazu/ansible/intro/.vagrant/machines/ubuntu01/virtualbox/private_key

[ssh_connection]
# for Cygwin, MSYS2
control_path = /tmp

インベントリファイル名は、hostsにします。remote_userとprivate_key_fileは、vagrant ssh-configで表示されるユーザー名UserとプライベートキーIdentityFileの場所を設定します。

host_key_checking = Falseは、ゲストOSを作ったり壊したりしたときに公開鍵が変わってしまうのですが、それをチェックしないという意味です。

MSYS2やCygwinでansibleを動かすときのポイントは、control_path = /tmpをansible.cfgに設定することです。これがないとエラーになります。
こんなエラーが出ます。

ubuntu01 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: mm_send_fd: sendmsg(2): Connection reset by peer\r\nmux_client_request_session: send fds failed\r\n",
    "unreachable": true
}

hostsファイル

次に、hostsという名前のインベントリファイルを作ります。

hosts

[webservers]
ubuntu01 ansible_host=192.168.33.10

webserversというグループに、ubuntu01という名前のサーバーを作り、そのIPアドレスは192.168.33.10です。これは、Vagrantと合わせます。

Ansibleで使うhostsファイルのホスト名(この場合はubuntu01)は、Vagrantで使うVagrantfileのhost.vm.nameで指定する名前とは無関係です。もっとも、同じにしておいた方が間違わなくて済むのでいいです。

動作確認

ファイルが出来たら、ansibleに続けて、すべてのマシン(all)にpingを打ってサーバーからの返事を見ます。-m pingというのはpingモジュールを使ってpingを打つという意味です。

ansible all -m ping

こういう返事が返ってくれば成功です。

ubuntu01 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Playbookの実行

あとは、Playbookを作って実行するだけです。

Playbookは、インデントが重要なのでタブが入っているとエラーになります。気をつけましょう。

ここでは、site.ymlという名前のPlaybookを作りました。

hostsに実行するサーバー名を指定して、userにログインするユーザー名を入れます。tasksとして、Apache2をインストールします。nameには、このタスクのコメントをいれ、aptというモジュールを使ってapache2をインストールされた状態にします。このとき、スーパーユーザーで行います。

site.yml

---
- hosts: ubuntu01
  user: ubuntu
  tasks:
    - name: install Apache2
      apt: name=apache2 state=installed
      become: true

ansible-playbookの次にsite.ymlを指定して実行してみます。

ansible-playbook site.yml

これで、Apache2がインストールできたら成功です。

実際に、http://192.168.33.10/ にブラウザでアクセスするとApacheの画面が見れると思います。

Ansibleの使い方は、Ansible構成管理入門を参考にさせてもらいました。ありがとうございます。

VagrantでAnsibleを使うのはSSHの理解がカギ

VagrantでAnsibleを使うのは、SSHを使ってリモートホストを操作します。なので、SSHがつながらないと話になりません。

SSHのしくみ

SSHの接続には秘密鍵と公開鍵の2つを使います。

公開鍵は、秘密鍵から作ることができます。

クライアント側とサーバー側の双方で秘密鍵と公開鍵があります。このうち公開鍵をお互いに送って保管することで通信ができます。

サーバーに接続してみて.sshディレクトリにあるauthorized_keysが保管場所。自分のホームディレクトリの.sshディレクトリの中のknown_hostsというファイルが保管場所です。

接続される側(サーバー側)で使われるのがauthorized_keysで、接続する側(クライアント側)で使われるのがknown_hostsです。

SSHクライアントで接続しようとしている場合、まずパスワードで接続してクライアント側の公開鍵をサーバー側に送ります。接続されるサーバー側は、authorized_keysという中にクライアント側の公開鍵をいれます。

そのあとで、サーバー側からサーバー側の公開鍵をクライアント側に送ります。これをクライアント側でknown_hostsに登録することで鍵認証で通信する準備が整います。これは、初めてsshで接続しようとしたときに警告が出てyesと答えると自動でやってくれます。

一度設定が済むと、

ssh -i <秘密鍵> <リモートホスト名>

で接続できます。

Vagrantの場合

Vagrantで作ったゲストOSにSSHを使ってパスワードでログイン

まずは、ゲストOSにパスワードでログインしてみます。

まず、vagrant ssh-configでVagrantが使っているsshの設定を見てみます。

$ vagrant ssh-config

Host default
  HostName 127.0.0.1
  User ubuntu
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile C:/msys32/home/vagrant/vm/ubuntu16.04/.vagrant/machines/default/virtualbox/private_key
  IdentitiesOnly yes
  LogLevel FATAL

HostNameが接続時に設定するホスト、Userがユーザー名、Portがポート番号です。-pでポート番号を指定して、ユーザー名とホスト名を@マークで区切って指定します。

$ ssh -p 2222 ubuntu@127.0.0.1

The authenticity of host '[127.0.0.1]:2222 ([127.0.0.1]:2222)' can't be established.
ECDSA key fingerprint is SHA256:h8pe0EpC3I5ocDrZ7PGUxjYMIs2Wh8lIsXG0R/C3S5A.
Are you sure you want to continue connecting (yes/no)?

なにやら表示が出ます。これは、サーバー側の公開鍵をホームディレクトリの.ssh/known_hostsに登録してもいいかという意味です。

yesと答えると、パスワードを聞かれます。

ubuntu@127.0.0.1's password:

Vagrantでubuntu/xenail64をゲストに使ったときは、ゲストのパスワードは、C:\ユーザー\自分の名前\.vagrant.dのなかのVagrantfileの中に書かれています。

ubuntu/xenial64の場合は以下のところです。

C:\Users\(your name)\.vagrant.d\boxes\ubuntu-VAGRANTSLASH-xenial64\20170423.0.0\virtualbox\Vagrantfile

これでログインできると思います。

公開鍵認証を使う場合

Vagrantの場合は、ホームディレクトリの.vagrant\machines\(host名)\virtualboxというフォルダの中にprivate_keyがつくられています。これを使って、ゲストOSに接続しています。
Vagrantが最初にvagrant upしたとき、ホストの公開鍵をコピーしてゲストOSのAuthorized_keysに登録しています。これで、パスワードなしでも鍵を使ってログインできるようになっています。

このauthorized_keysを確認してみます。

$ vagrant ssh

で接続して

(remote host) $ cat .ssh/authorized_keys

で、なかを見ると、

ssh-rsa AAAAB3NzaC----すごく長い------CBnRropmyAxL vagrant

みたいにssh-rsaで始まりvagrantで終わっているのがVagrantが送ったクライアント側の公開鍵です。

(remote host) $ exit

でログアウトします。

実際にsshを使って手動で接続してみようと思います。

まず、vagrant ssh-configでVagrantが使っているsshの設定を見てみます。

$ vagrant ssh-config

Host default
  HostName 127.0.0.1
  User ubuntu
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile C:/msys32/home/vagrant/vm/ubuntu16.04/.vagrant/machines/default/virtualbox/private_key
  IdentitiesOnly yes
  LogLevel FATAL

HostNameが接続時に設定するホスト、Userがユーザー名、Portがポート番号、IdentityFileが接続時に使う秘密鍵です。

sshで-iで秘密鍵を、-pでポート番号を、ホストの前に@マークで名前を指定して接続してみます。

$ ssh -i .vagrant/machines/default/virtualbox/private_key -p 2222 ubuntu@127.0.0.1

最初に接続したときは、ゲストOS(接続先)の公開鍵が登録されていないため、次のような警告が出ます。

The authenticity of host '[127.0.0.1]:2222 ([127.0.0.1]:2222)' can't be established.
ECDSA key fingerprint is SHA256:+lHBujro5WLFzsFfFSFTQzWS/E35OvSwdr8t8OO/AFo.
Are you sure you want to continue connecting (yes/no)? 

yesと入力しリターンキーを押すとパスワードなしでログインしたと思います。この確認は2度目から出ません。

(remote host)$ exit

でログアウトして、自分のホームディレクトリの.ssh/known_hostsを確認してみます。

$ cat ~/.ssh/known_hosts

[127.0.0.1]:2222 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBE1rZpVqvH1jYQ2lEjm0zc0LORZh7aIH61qIS0msMbBvA0W1s+NTgiftffhTcnON903vw/pWt9tqNhR69wNJsI8=

ホスト127.0.0.1ポート番号2222としてリモートホストの公開鍵が登録されています。

なお、vagrant destroyしたあと、vagrant upでゲストOSを作り直し、sshで接続しようとすると、次のようなエラーになります。

$ ssh -i .vagrant/machines/default/virtualbox/private_key  -p 2222 ubuntu@127.0.0.1

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:h8pe0EpC3I5ocDrZ7PGUxjYMIs2Wh8lIsXG0R/C3S5A.
Please contact your system administrator.
Add correct host key in /home/vagrant/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/vagrant/.ssh/known_hosts:3
ECDSA host key for [127.0.0.1]:2222 has changed and you have requested strict checking.
Host key verification failed.

これは、ゲストOSを作り直して公開鍵が変わってしまったために、ホームディレクトリで保存しているゲストOSの公開鍵と違っているためです。

このときは、エディタで~/.ssh/known_hostsの[127.0.0.1]:2222の行を削除すると接続することができます。

このようにvagrant ssh-configで確認した設定値を使って、sshで接続することができます。

AnsibleをMSYS2で使う

前回、VagrantとDockerで環境構築をしたので、Ansibleを使ってみることにしました。

Vagrantで作ったゲストOSに対してAnsibleで環境設定をするには、大きく分けると次の3つの方法があります。

  1. Vagrantfileの中ではプロビジョニングを使わず、ゲストOSを立ち上げるだけにして、ansible単独でゲストOSを操作する方法
  2. Vagrantfileの中でconfig.vm.provision 'ansible_local'として、Vagrantのansible_localというプロビジョニングを使う方法
  3. Vagrantfileの中でconfig.vm.provision 'ansible'として、Vagrantのプロビジョニングを使う方法

1番の方法は、WindowsホストではAnsibleからサポートされていません。

2番の方法は、AnsibleをゲストOSにインストールして、ゲストOS内でAnsibleを動かします。よって、Windowsホストでも使えます。

3番の方法は、WindowsホストではVagrantからは公式にはサポートされていません。そもそも1番の方法でansibleコマンドが動かないと、Vagrantでは動きようがありません。

このように、Windowsをホストにする場合、ansible_localしか方法はないのかと思いました。

実際、MSYS2のpipでパッケージを入れてみても、ansibleコマンドはエラーが出て動きません。

でも、Cygwinで動かしている人がいて、何とかならないかなとやってみることにしました。

最近はMSYS2をメインに使っています。そこでMSYS2で検索してみると、Ansibleを動かした人がいました。

[ansible] MSYS2 で ansible を使えるようにする手順

この通りやったらansibleが動き出しました。ありがとうございます。

ポイントは、32bitバージョンのMSYS2(msys2-i686-20161025.exe)を使うことです。64bitバージョンでは動きませんでした。

(2017/05/31)訂正
MSYS2のバージョンが問題ではなかったです。インストールするパッケージがmsysのpython2である必要がありました。

pacman -S python2

です。mingw-w64-x86_64-python2とかではだめでした。スタートメニューから起動するコンソールがMSYS2 MinGW 64bitやMSYS2 MinGW 32bitだと、MinGWのpythonがインストールしてある時はそちらが優先的に使われてしまうので気をつけてください。

インストールが終わったら、SSHでゲストOSにアクセスできることを確認して、ansibleが使えるようになります。

次回は、SSHについて書きます。

VagrantでDockerを使ってみて高速化のあれこれ

今までVirtualBoxは素のまま使っていたのですが、Vagrantを使うといいということを聞いて使ってみることにしました。

せっかくなのでDockerも使ってみようということで以下のサイトを参考にしてインストールしてみました。

VagrantとDockerについて名前しか知らなかったので試した

やってみた結果は、とてもすんなりできました。ありがとうございます。

でも、なんかインストールに時間がかかるのです。VagrantのゲストOSの元となるboxファイルは、自分のC:\Users\(your name)\.vagrant.d\boxesというフォルダに保存されます。ですので、一度ダウンロードしてしまえば2度目からはとても速くゲストOSが出来上がります。

でも、そのときにDockerをセットアップしようとprovisioningに加えると、ゲストOSを作り直すごとにインターネットからDockerが使うファイルをダウンロードします。速度が2Mbpsくらいしかでなくてプロビジョニングが終わるまで10分くらいかかります。DockerをDockerは速いということが言われていますが、Docker自身のセットアップは時間がかかるのですね。

これを解決するため、CocPxoryというプロキシサーバーをつかってみたりしました。でも、httpではなくhttpsでダウンロードしようとするのでなかなか難しいです。

結局、こちらを参考に、Ubuntuをインストールするときはaptのソースリストを変更して、日本のサーバーからダウンロードするように変更しました。

ただ、ソースのリスト先がus.archive.ubuntu.comではなく、archive.ubuntu.comでした。また、ubuntuをmirrorしているところから速いのを選びました。

また、vagrant-cachierというプラグインが少し速くしてくれました。これを使うときの注意点は、vagrant-cachierは、/var/cache/apt/archivesを/tmp/vagrant-cache/aptにシンボリックリンクすることで、ホストのフォルダC:\Users\(your name)\.vagrant.d\cache\(box名)を保存先にしています。そのため、vagrant-cachierを使ったままVagrantfileから設定を削除したり、プラグインをvagrant plugin uninstallで削除してしまうと、/var/cache/apt/archivesのリンクがそのままになってしまうため、apt-getが動かなくなってしまうことです。

Vagrantfileは、こんな感じ。

Vagrant.configure(&quot;2&quot;) do |config|
  config.vm.box = &quot;ubuntu/xenial64&quot;

  config.vm.provision &quot;shell&quot;, inline: &lt;&lt;-SHELL
    # aptのソースファイルを書き換え
    sed -i s%archive.ubuntu.com/ubuntu%ftp.jaist.ac.jp/pub/Linux/ubuntu/%g /etc/apt/sources.list
    apt-get update
  SHELL

  config.vm.provision &quot;docker&quot; do |d|
    # dockerに関する操作
    d.build_image &quot;/vagrant&quot;, args: &quot;-t kazu/my-bash&quot;
    d.run &quot;kazu/my-bash&quot;, args: &quot;-d -t -v /vagrant:/tmp/shared&quot;
  end

  if Vagrant.has_plugin?(&quot;vagrant-cachier&quot;)
    config.cache.scope = :box 
  end
end

Dockerfileは、次のようにしました。

FROM ubuntu:xenial

MAINTAINER kazu

CMD [&quot;/bin/bash&quot;]

これでvagrant upするとゲストOSが立ち上がります。その中で、Dockerが動いています。

一度Vagrantのboxがダウンロードされると、プロビジョニングは4分ほどで終わります。なんとか待っていられるかな。

Microsoft AzureでMySQLとPostgreSQLのサービスが始まりました

Microsoft AzureでMySQLとPostgreSQLのサービスが始まりました。

速報]マイクロソフト、Azureで「MySQL」「PostgreSQL」のデータベースサービス提供を発表、運用の手間は不要。Build 2017

早速、MySQLのサイトに行って料金を調べると、東日本のリージョンで一月2375.30円になっていました。

PostgreSQLも同じ料金でした。

これで、AzureのVirtual Machineを使ってもWordPressが手間無くできますね。

SQL Serverと比べると少し割高になっています。もちろん単純な比較はできませんけど。

他のクラウドサービスと比較してみると、少し安いくらいでしょうか。

もう1つ気になったのは、冗長構成をとるようなオプションが見当たらないことです。1台でスケールアップするしかないのかな。

最近開発されたハイパーバイザー

PhoronixというニュースサイトでBareflankというハイパーバイザーが開発されていることを知りました。

調べていくと、最近いろいろなハイパーバイザーが開発されているようです。今回はそれを紹介します。

ハイパーバイザー

Bareflank

セキュリティーなどに応用するためのプロトタイプを目的とする。C++、STLで書かれている。ユニットテストが完備されていて、Coveralls、Travis CI、Astyleが使われていて、Coverity、Clang Tidy、Google's Sanitizersといったところでコードを分析している。

サポートするのは、SandyBrdge以降のCPU。
ホストOSは、
Ubuntu 16.10
Debian Stretch
Fedora 25, 24
OpenSUSE Leap 42.2
Windows 10
Windows 8.1

少しソースコードを見ると、WindowsホストではCygwinでカーネルドライバーを作るようになっていたり、self signをできるようにしていたりと本格的です。

シンプルなハイパーバイザーを目指しているようです。機能を拡張する方法があるようで、次の2つが挙げられています。

Extended APIs

BareflankにVPIDとかMSR bitmapにアクセスするためのAPIなどを提供するもの。

Hyperkernel

他の人が自分のハイパーバイザーを開発できるように、Bareflankのサポートソフトとして開発されている。

MoRE

Windows 7 32-bit で、CPUコアは1、メモリ2GBで動作。WinDDKを使っている。3年前に開発が止まっているようです。

SimpleVisor

Intel x64/EM64T VT-xで動く、シンプルなハイパーバイザー。アセンブリコードは10行、ホストのハイパージャックとアンハイパージャックをサポート。ホストの状態を仮想化できるそうです。EPTとVPIDをサポート。WindowsとUEFI環境で動くそうです。Cのコードは500行、総コード数1700行だとか。

VisualStudio 2015 Update 3で作られる。ミニマルなハイパーバイザーを目指しているそうです。

HyperPlatform

Intel VT-x上でのハイパーバイザー。rootkitや、侵入検知システム、Windowsカーネルのリバースエンジニアリングを目的とする。

Visual Studio Community 2015 Update 3、Windows SDK、Windows Driver Kitで作られる。

ksm

Cで書かれた軽量なx64ハイパーバイザー。WindowsとLinuxホストサポート。WindowsではMinGWを使っています。

まとめ

どれもゲストOSを動かすというより、セキュリティ分野での応用を目指しているようです。CPUのVT-x機能を使う方法など、勉強したい方にはコードが簡単でいいのではないかと思います。VirtualBox、Xen、KVMといったプログラムのコードは複雑ですので。

クラウドサービスはどこが安いのか - ロードバランサを使った場合

Amazon Web Servicesでは、こことか、ここにあるように、ロードバランサを使った構成を勧めています。

ロードバランサを使った場合、国内外のクラウドサービスのどこが本当に安いのか比較してみました。2017年5月での比較です。

各サービスにおいて、メモリが2MBあるインスタンスを借りることを考えます。WordPressを使うことを想定してロードバランサ1個とWebサーバーのインスタンス2個とデータベースのインスタンスを借りることを考えます。

比較したのは、Amazon Web ServicesとGoogle Cloud Platform、Microsoft Azure、さくらのクラウド、IDCF クラウド、クラウド・エヌです。

データベースのサーバーは、リレーショナルデータベースのサービスが提供されていればそれを使い、無ければインスタンスをデータベース用に借ります。

海外のクラウドサービスでは、ネットワークが従量制なので、1MBのページが月に100万ページビュー/月、ということで転送量が1000GB/月として検討してみます。ここが一番不明確なところです。

それぞれのサービスで料金のシミュレーターがあるので、それを使って調べました。

厳密な意味ではスペックを同じにできませんでしたので、はじめにお断りしておきます。

では、Amazonから。

Amazon Web Services

Amazon Web Services(AWS)は、いろいろなサービスが提供されています。そのなかで、Amazon EC2がWebサーバーに、Amazon EBSがストレージに、Amazon RDSがデータベースとして使えます。

12か月の無料期間があるのですが、今回はそれを無視して調べました。

メモリ2MBにするために、t2.smallを2台選びました。

料金シミュレーターはこちらです。

Amazon EC2

タイプ: Linux,t2.small
台数: 2
月額: $46.86

Amazon EBS

ボリュームタイプ: General Purpose SSD(gp2)
ストレージ: 30GB
月額: $3.60

Elastic Load Balancing

Elastic LBの数: 1
全ELBによって処理されたデータ転送: 1000GB/月
月額: $27.77

データ転送送信

アジアパシフィック(日本)リージョン $139.86

Amazon RDS

クラス: db.t2.small
ストレージ: 汎用(SSD) 5GB
リージョン内データ転送: 1000GB/月
月額: $48.76
合計: $266.85

月額料金は1ドル110円として消費税も入れると、31702円です。データ転送量に応じて金額は変化します。

また、実際に運用していくにはデータベースのバックアップなども必要になり、その分のお金がかかります。

Google Cloud Platform

Google Cloud Platform(GCP)も、いろいろなサービスが提供されています。そのなかで、Google Compute EngineがWebサーバーに、Google Cloud SQLがデータベースとして使えます。Compute Engineのところにストレージもあります。

シミュレーターを使ってみると次のようになりました。

料金シミュレーターはこちらです。

Compute Engine

1460 total hours per month
VM class: regular
Instance type: g1-small
Region: Asia (Japan)
料金: $32.91

Persistent Disk

Asia (Japan)
Storage: 30 GB
料金: $1.56

Load Balancing(global)

Asia(Japan)
Forwading riles: 1
Netword ingress: 1000GB
料金: $39.74

Network Bandwidth

Egress - Asia/Pacific 1000GB
料金: $120.00GB

Cloud SQL Second Generation

db-g1-small
# of instances: 1
730.0 total hours per month
Storage: 10 GB
Backup: 0.0 GB
料金: $27.25
合計: $221.46

月額料金は、消費税を考慮すると26310円です。

Cloud SQLの安さが光ります。こちらも、アクセス数が増えれば費用がかかります。

ネットワークの転送料の割合が大きいです。

Microsoft Azure

Microsoft Azureは、WindowsとMicrosoft SQL Serverを使うことを想定しています。SQL DatabaseはWebアプリケーション用ということで、Standardというパフォーマンスレベルから最低なものを選びました。

料金シミュレーターはこちらです。

SQL Database

リージョン: 西日本
タイプ: Single Database
価格レベル: Basic
パフォーマンスレベル: B: 5BTU, DBあたり2GBストレージ
料金: 1730.25円

Virtual Machines

リージョン: 西日本
種類: Linux
価格レベル: Basicx
インスタンスのサイズ: A1:1コア,1.75GB RAM, 40GB
インスタンス 2個 x 744時間
料金: 4856.83円

Load Balancer

料金: 無料

帯域幅

リージョン
ゾーン2:アジア太平洋、日本、オーストラリア
1000GB
料金: 14005.62円
合計: 20592.70円(消費税不明)

他のクラウドサービスでSQL Serverを動かそうとすると、Windows ServerとSQL Serverのライセンス料がかかります。そのことを考えたら、データベースのレンタル料がすごく安いです。

ロードバランサが無料なんですね。こちらも、アクセス数の費用に占める割合が大きいです。

さくらのクラウド

料金シミュレーターはこちらです。

サーバー・ディスク

リージョン: 石狩
サーバープラン: 仮想1コア、2GBメモリ
ディスク1: SSDプラン:20GB
契約数: 2
料金: 5142円

ルータ・スイッチ

回線帯域: 100Mbps:月間3.2TB(平均10Mbps)月額4320円
グローバルIPアドレス: 16個:月額3456円
料金: 7776円

ロードバランサ

プラン: 標準プラン
料金: 2571円

データベース

プラン: 10GBプラン:月額2700円
料金: 2700円
合計: 18189円(税別)

前回見落としたのかもしれませんが、データベースのサービスがあるのですね。ルータ・スイッチが高いなと思ったのですが、ネットワークの転送量が増えても値段は上がりませんので、こんなものかもしれません。

IDCF クラウド

こちらは、データベースのサービスがありません。サーバーの構成例として、人気のLAMP構成ということで、Webサーバー2つ、DBサーバー2つの構成がありましたので、それを紹介します。

料金シミュレーターはこちらです。

Webサーバー

仮想マシン: Light-S2 CPU 1 Mem 2GB
料金: 1400円
ボリューム: ルートディスク15GB
料金: 300円
利用台数: 2台

DBサーバー

仮想マシン: HighCPU-M4 CPU 2 Mem 4GB
料金: 9200円
ボリューム: ルートディスク15GB
料金: 300円
利用台数: 2台

ロードバランサ

料金 無料
合計: 22400円(税別)

DBサーバーに結構よい性能のサーバーを割り当てています。性能を抑えることで安くできると思います。

性能の良い有償のロードバランサもあります。また、初期設定のスクリプトがあるそうです。

クラウド・エヌ

Cloudn(クラウド・エヌ)は、NTTコミュニケーションズが提供しているクラウドサービスです。

料金シミュレーターはこちらです。

東日本リージョン
FLATタイプ

Compute

仮想サーバープラン(vCPU): プランv1(1 vCPU, 2GB)
オフィシャルテンプレート: CentOS(ルートディスク15GB)
1か月の利用時間: 起動720時間
台数: 2台
料金: 6800円
データディスク: 40GB 利用720時間
台数: 2個
料金: 800円

Load Balancing Advanced(LBA)

LBA: 振り分け先の仮想サーバー数 2台/月
料金: 1500円

Relational Database(RDS)

DBサーバープラン: vDB1(1vCPU,2GB) 720時間
DBディスク: 30GB利用 720時間
料金: 5600円
合計: 14700円(税別)

なんか安くまとまりました。
RDSをマルチゾーンに配置して、LBAでSSL証明書を扱って、DNSのサービスを使っても、税込みで23328円でした。

とてもお得です。

まとめ

国内外のクラウドサービスについて、料金を比較してみました。

AWSは、ロードバランサも含めて組むとそれなりに料金がかかります。オンプレミスでロードバランサを購入したことと比べれば安いのでしょうけれど。将来的に成長が見込めるサイトは、ロードバランサを組んでしまった方が、後の手間がかからないと思います。

GCPは、このページで、他のクラウドと比べてコストが60%とうたっています。他のクラウドとはAWSのことでしょう。Azureもそれくらいのところを狙っているようです。

Azureも含めて、海外のクラウドサービスは、ネットワークの転送料が従量制です。そのため、転送量が増えると料金が上がることが大きくきいてきます。画像の多いサイトは要注意です。

国内勢も頑張っています。

さくらのクラウドは、比較ではAWSより安く、ネットワークの転送量が増えるともっと違いが出てきます。

IDCFクラウドは、データベースのサービスがないので自分で設定する必要がありますが、それができればネットワークの転送料もかかりませんし、料金は明瞭です。データベースのサービスは、2017年中に提供予定のようです。

クラウド・エヌがずいぶん頑張っているように見えます。データベースのサービスもありますし、サイトを運営するのに必要なサービスはそろっていると思います。

いずれにしろクラウドサービスは、少しお金をかけてでも手間と時間を節約して自分の仕事を楽にするものだと思っています。

自分に合った良いサービスが見つかるといいなと思います。