Go to Qiita Advent Calendar 2024 Top
LoginSignup
30
20

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

NIFTYAdvent Calendar 2016

Day 20
@licht110

serverspec+ansible+vagrant-vsphereでやるテスト駆動サーバー運用

Posted at

この記事はNIFTY Advent Calendar 2016 20日目の記事です。
昨日は二つの意味で自分の同僚である@megane42さんのアイドルに囲まれて仕事がしたかったという記事でした。
最近@megane42さんからアイドル駆動開発という素晴らしいライフハックを教えていただき、自分も開発で合法的（？）に担当アイドルのダイレクトマーケティングがしたいと思っている今日この頃ですが、今回は全く関係ない話です。謹んでお詫び申し上げます。

はじめに

自分が所属している部では自前でvCenterを持って運用していて（社内では珍しい（？）脱ニフティクラウドです）、サーバーの構成管理をするために以下のものを使っています。

  • serverspec
  • ansible
  • vagrant-vsphere

本日はこれらをどのように活用してテスト駆動サーバー運用を行なっているかを書きます。

テスト駆動サーバー運用のメリット

商用の環境も検証の環境もこれから作るサーバーも全てserverspecのテストを満たしている状態が保証されます。
検証も商用のサーバーも毎日定時にserverspecのテストをかけていますので、その状態は常に保証されています。
これによって、「商用と検証の設定違いでメンテ失敗しましたー」 とか 「サーバー構築したんですけど、設定間違ったまま本番投入しちゃいましたーﾃﾍｯ♩」みたいな悲劇が減ります。
あと、副次的な効果として、いちいち設定を確認しにサーバーに入らなくてよくなりました。自分のチームではサーバー数百台管理していますが、1台1台sshで入って目視で設定確認して〜なんてことをやってたらめんどくさいですね。

テスト駆動サーバー運用概要

やりたいことはサーバーの構成管理でした。
各ツールを以下の用途として使っています。

  • vagrant-vsphere、ansible：新規サーバー構築・メンテ時の設定変更
  • serverspec：日々の運用におけるサーバーの設定チェック、新規サーバー構築時の設定チェック

構築時のvagrant-vsphere provisioningとansible playbookを洗練するための流れが以下になります。

  1. serverspecのテストを書く
  2. 構築用vagrant-vsphere provisioning、ansible playbookを書く
  3. vagrant upでサーバーコピー
  4. ansible playbook実行
  5. serverspecのテストを実行
  6. vagrant destroyでサーバー削除
  7. テスト結果を見てvagrant-vsphere provisioning、ansible playbookを修正
  8. 以下テストが全て通るようになるまで繰り返し

テスト駆動というからにはテストファーストです。serverspecのテストを一番初めに書きます。
当然このテストを満たすようにvagrant-vsphere provisioningとansible playbookを書いていきますので一番重要なところです。
serverspecやansibleについては他に良いドキュメントがあると思うのでここでは割愛します。ググってください。
vagrant-vsphereについては下で少し書きます。

現在3〜6まではjenkinsのジョブで全て自動化してあり、最後にテストの結果をメールで送ってくれます（あとslack連携がしたい）。
そのテスト結果を元にplaybook等を修正し、またjenkinsのジョブ実行（以下エンドレス という流れです。

本番環境に新規サーバーをデプロイするときは6のサーバー削除をやらないだけになっており、全く同じ手順で構築され、全く同じ設定であることが保証されています。

メンテ用のansible playbookを書くときも基本的に同じ流れとなります。

  1. 設定変更後のserverspecのテストを書く
  2. 設定変更・切り戻し用ansible playbook作成
  3. ansible playbook実行
  4. serverspec（設定変更後用）テスト実行
  5. 切り戻し用ansible playbook実行
  6. serverspec（設定変更前）テスト実行
  7. 設定変更・切り戻し用ansible playbook修正

4で設定変更後のテストを実施し、それを元に設定変更用ansible playbookを修正していきます。
同様に6で設定変更前のテストを実施し、それを元に切り戻し用ansible playbookを修正していきます。
設定変更と切り戻し同時にできるのがミソです。
これで切り戻し準備も万全ですね。切り戻ししないのが一番ですけど（切実）。

vagrant-vsphereについて

vagrant-vsphereはvagrantのプラグインで、vagrant up、vagrant halt、vagrant destroyといったコマンドからvCenterのサーバーを操作できます。極力全てをコマンドラインから済ませたい自分には嬉しいです。
provisioningについても基本的に通常のvagrant provisioningと同じように実行できます。
使い方は以下の記事が詳しいです。

以下はVagrantfileの例です。

load "hosts"

Vagrant.configure("2") do |config|
  config.vm.box = 'vsphere'
  config.vm.box_url = './dummy.box'
  config.ssh.pty = true

  config.vm.provision :shell, :path => "/path/to/provisioning/scripts"

  # synced folder
  config.vm.synced_folder ".", "/vagrant", disabled: true, create: false

  # ssh host when vagrant up
  config.ssh.port = '22'
  config.ssh.username = 'username'
  config.ssh.private_key_path = "/path/to/ssh/key"

  # vsphere client setting
  config.vm.provider :vsphere do |vsphere|
    # vCenter
    vsphere.host = 'vcenter address'
    # use cloning
    vsphere.clone_from_vm = true
    # custamization spec
    vsphere.customization_spec_name = 'customization spec'
    # original vm name
    vsphere.template_name = 'path/to/copy_vm'
    # vCenter name
    vsphere.data_center_name = 'datacenter name'
    # vm base path
    vsphere.vm_base_path = "path/to/create_vm"

    # vlan
    vsphere.vlan = "vlan name"
    # cpu
    vsphere.cpu_count = "CPU num"
    # memory
    vsphere.memory_mb = "Mem num"

    vsphere.user = 'username'
    #vsphere.password = ENV["VSPHERE_PASSWORD"]
    vsphere.password = 'password'
    # ignore warning of certificate
    #vsphere.insecure = true

  end

end

一行目で、作成するホストの情報が書いてあるhostsという名前のファイルを読み込んでいます。
hostsファイルは以下のようになっています。

Vagrant.configure("2") do |config|

  config.vm.define "vm name" do |server|

    server.vm.network 'private_network', ip: 'private ip'
    server.ssh.host = 'private ip'

    # vagrant-vsphere setting
    server.vm.provider :vsphere do |vsphere|
      # vm name
      vsphere.name = 'vm name'
    end
  end

end

このhostファイルには複数サーバー書くことができ、vagrant-vsphereのコマンドで同時に複数サーバー操作できます。
vagrant upで一気にサーバー作ってvagrant destroyで全削除とかやったりすると気持ち良いのでオススメです。

packerなど他のデプロイツールもありましたが、vagrantの方が自分が慣れているからという理由で今は使っています。
最近だとTerraformとかottoとか新しいツールもでてきていますし、そちらも触ってみたいですね。

serverspecの小技

serverspecの小技も一つここでご紹介しておきます。
serverspecではServerspec::Helper::Propertiesというモジュールによってテストの中で変数を使えるようになります。
それについては以下の記事が詳しいですね（他にも探せばいっぱい出てくる）。

上記ではpropertyというHashにinventoryファイルの中身を格納してホストごとに変数を設定していますが、例えば、様々な環境に対して同一のテストを使いまわしたいなんてときには、その環境ごとの変数だったり、全ての環境で同じ変数などを設定したいなんてことがあったりします（少なくとも自分はある）。
というわけで、なんとなくそんな感じのができるあれを作りました。ソースは以下です。

以下、簡単な解説です。
lib/extra_properties.rbでSpecinfra::Propertiesを継承してExtraPropertiesというクラスを生成しています。
このクラスは追加で2つの変数を持っています。

lib/extra_properties.rb
require 'singleton'

module Specinfra
  class ExtraProperties < Specinfra::Properties
    def initialize
      @global_prop = {}
      @group_prop = {}
    end
    def global_properties(global_prop=nil)
      if ! global_prop.nil?
        @global_prop = global_prop
      end
      @global_prop
    end
    def group_properties(group_prop=nil)
      if ! group_prop.nil?
        @group_prop = group_prop
      end
      @group_prop
    end
  end
end

lib/helper/extra_properties.rbには上記クラスの変数に値を格納するメソッドを持ったモジュールがあります。

lib/helper/extra_properties.rb
require 'specinfra/properties'

module Specinfra
  module Helper
    module ExtraProperties
      def property
        Specinfra::ExtraProperties.instance.properties
      end
      def group_property
        Specinfra::ExtraProperties.instance.group_properties
      end
      def global_property
        Specinfra::ExtraProperties.instance.global_properties
      end
      def set_property(prop)
        Specinfra::ExtraProperties.instance.properties(prop)
      end
      def set_group_property(prop)
        Specinfra::ExtraProperties.instance.group_properties(prop)
      end
      def set_global_property(prop)
        Specinfra::ExtraProperties.instance.global_properties(prop)
      end
    end
  end
end

spec/spec_helper.rbで上記クラスとモジュールを読み込んで、set_group_propertyとset_global_propertyでそれぞれファイルから読み込んだ変数を格納しているだけです。単純です。

spec/spec_helper.rb
require 'serverspec'
require 'serverspec_extra'
require 'net/ssh'
require 'yaml'

include Specinfra::Helper::ExtraProperties

set :backend, :ssh

# load vars from yaml file
host_vars = YAML.load_file('inventories/hosts')
group_vars = YAML.load_file('inventories/group_vars')
global_vars = YAML.load_file('inventories/global_vars')

# set vars
set_group_property group_vars
set_global_property global_vars

RSpec.configure do |c|
  c.host = ENV['TARGET_HOST']
  set_property host_vars[c.host][:vars]
end
...

これでテストコード上でgroup_propertyとglobal_propertyという変数が使えるようになります。

見ていただくと分かると思いますが、ただ単に使える変数を増やしましたというだけですね。自分はglobal_propertyにinventories/global_varsを読み込ませて全ての環境で同一の値をもつ変数、group_propertyにinventories/group_varsを読み込ませて環境ごとに違う値をもつ変数という風に使っています。

最後に

以上、テスト駆動サーバー運用でした。
テスト駆動という特性上、やはりテストがキモです。
serverspecは結構自由度が高く、Rakefileやspec_helper.rbの書き方次第で結構いろいろなことができると思います。
それぞれのベストプラクティスなディレクトリ構成、inventoryファイルの書き方などなどを探ることでより良いテストライフを送ってください。

明日は@hideakihalさんの記事です。お楽しみに。

おわりだよ〜(o・∇・o)

30
20
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
30
20

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?