Submit Search
Upload
serverspecでサーバ環境のテストを書いてみよう
•
54 likes
•
22,322 views
Daisuke Ikeda
Follow
社内勉強会で発表した資料です。 serverspecの基本から属性値の管理、カスタマイズ方法まで紹介しています。 ※2013/8/14 version 0.7.8時点の情報なので注意
Read less
Read more
Technology
Slideshow view
Report
Share
Slideshow view
Report
Share
1 of 24
Download now
Download to read offline
Recommended
Ansible specでテストをする話
Ansible specでテストをする話
KeijiUehata1
Serverspecの活用tips紹介
Serverspecの活用tips紹介
Daisuke Ikeda
RubyのDir、File、IO について
RubyのDir、File、IO について
Tomoya Kawanishi
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
日本マイクロソフト株式会社
MQTTとAMQPと.NET
MQTTとAMQPと.NET
terurou
Javaのログ出力: 道具と考え方
Javaのログ出力: 道具と考え方
Taku Miyakawa
12 分くらいで知るLuaVM
12 分くらいで知るLuaVM
Yuki Tamura
DBスキーマもバージョン管理したい!
DBスキーマもバージョン管理したい!
kwatch
Recommended
Ansible specでテストをする話
Ansible specでテストをする話
KeijiUehata1
Serverspecの活用tips紹介
Serverspecの活用tips紹介
Daisuke Ikeda
RubyのDir、File、IO について
RubyのDir、File、IO について
Tomoya Kawanishi
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
日本マイクロソフト株式会社
MQTTとAMQPと.NET
MQTTとAMQPと.NET
terurou
Javaのログ出力: 道具と考え方
Javaのログ出力: 道具と考え方
Taku Miyakawa
12 分くらいで知るLuaVM
12 分くらいで知るLuaVM
Yuki Tamura
DBスキーマもバージョン管理したい!
DBスキーマもバージョン管理したい!
kwatch
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
NTT DATA Technology & Innovation
Ansible ではじめるインフラのコード化入門
Ansible ではじめるインフラのコード化入門
Sho A
Node.js Native ESM への道 〜最終章: Babel / TypeScript Modules との闘い〜
Node.js Native ESM への道 〜最終章: Babel / TypeScript Modules との闘い〜
Teppei Sato
これ以上ソースコードの負債を増やさないためにVisual Studioの静的解析とAzure PipelinesでCIを回す
これ以上ソースコードの負債を増やさないためにVisual Studioの静的解析とAzure PipelinesでCIを回す
Study Group by SciencePark Corp.
OpenStack Swift紹介
OpenStack Swift紹介
Kota Tsuyuzaki
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
Recruit Technologies
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
ゼロから始めたE2Eテスト
ゼロから始めたE2Eテスト
ushiboy
はじめての datadog
はじめての datadog
Naoya Nakazawa
Javaはどのように動くのか~スライドでわかるJVMの仕組み
Javaはどのように動くのか~スライドでわかるJVMの仕組み
Chihiro Ito
Goss入門
Goss入門
ShuyaMotouchi1
Datadog による Container の監視について
Datadog による Container の監視について
Masaya Aoyama
Itamae-Serverspec入門
Itamae-Serverspec入門
辰徳 斎藤
Node.jsアプリの開発をモダン化するために取り組んできたこと
Node.jsアプリの開発をモダン化するために取り組んできたこと
bitbank, Inc. Tokyo, Japan
Apache OpenWhiskで実現するプライベートFaaS環境 #tjdev
Apache OpenWhiskで実現するプライベートFaaS環境 #tjdev
Yahoo!デベロッパーネットワーク
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
JenkinsとCodeBuildとCloud Buildと私
JenkinsとCodeBuildとCloud Buildと私
Shoji Shirotori
show コマンド結果をパースする方法あれこれ #npstudy
show コマンド結果をパースする方法あれこれ #npstudy
akira6592
20210216 AWS Black Belt Online Seminar AWS Database Migration Service
20210216 AWS Black Belt Online Seminar AWS Database Migration Service
Amazon Web Services Japan
とあるDBAの黒い画面(ターミナル)
とあるDBAの黒い画面(ターミナル)
Kazuhiro Yoshikawa
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
賢 秋穂
More Related Content
What's hot
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
NTT DATA Technology & Innovation
Ansible ではじめるインフラのコード化入門
Ansible ではじめるインフラのコード化入門
Sho A
Node.js Native ESM への道 〜最終章: Babel / TypeScript Modules との闘い〜
Node.js Native ESM への道 〜最終章: Babel / TypeScript Modules との闘い〜
Teppei Sato
これ以上ソースコードの負債を増やさないためにVisual Studioの静的解析とAzure PipelinesでCIを回す
これ以上ソースコードの負債を増やさないためにVisual Studioの静的解析とAzure PipelinesでCIを回す
Study Group by SciencePark Corp.
OpenStack Swift紹介
OpenStack Swift紹介
Kota Tsuyuzaki
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
Recruit Technologies
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
ゼロから始めたE2Eテスト
ゼロから始めたE2Eテスト
ushiboy
はじめての datadog
はじめての datadog
Naoya Nakazawa
Javaはどのように動くのか~スライドでわかるJVMの仕組み
Javaはどのように動くのか~スライドでわかるJVMの仕組み
Chihiro Ito
Goss入門
Goss入門
ShuyaMotouchi1
Datadog による Container の監視について
Datadog による Container の監視について
Masaya Aoyama
Itamae-Serverspec入門
Itamae-Serverspec入門
辰徳 斎藤
Node.jsアプリの開発をモダン化するために取り組んできたこと
Node.jsアプリの開発をモダン化するために取り組んできたこと
bitbank, Inc. Tokyo, Japan
Apache OpenWhiskで実現するプライベートFaaS環境 #tjdev
Apache OpenWhiskで実現するプライベートFaaS環境 #tjdev
Yahoo!デベロッパーネットワーク
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
JenkinsとCodeBuildとCloud Buildと私
JenkinsとCodeBuildとCloud Buildと私
Shoji Shirotori
show コマンド結果をパースする方法あれこれ #npstudy
show コマンド結果をパースする方法あれこれ #npstudy
akira6592
20210216 AWS Black Belt Online Seminar AWS Database Migration Service
20210216 AWS Black Belt Online Seminar AWS Database Migration Service
Amazon Web Services Japan
What's hot
(20)
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
どうやって決める?kubernetesでのシークレット管理方法(Cloud Native Days 2020 発表資料)
Ansible ではじめるインフラのコード化入門
Ansible ではじめるインフラのコード化入門
Node.js Native ESM への道 〜最終章: Babel / TypeScript Modules との闘い〜
Node.js Native ESM への道 〜最終章: Babel / TypeScript Modules との闘い〜
これ以上ソースコードの負債を増やさないためにVisual Studioの静的解析とAzure PipelinesでCIを回す
これ以上ソースコードの負債を増やさないためにVisual Studioの静的解析とAzure PipelinesでCIを回す
OpenStack Swift紹介
OpenStack Swift紹介
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
RDB技術者のためのNoSQLガイド NoSQLの必要性と位置づけ
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
ゼロから始めたE2Eテスト
ゼロから始めたE2Eテスト
はじめての datadog
はじめての datadog
Javaはどのように動くのか~スライドでわかるJVMの仕組み
Javaはどのように動くのか~スライドでわかるJVMの仕組み
Goss入門
Goss入門
Datadog による Container の監視について
Datadog による Container の監視について
Itamae-Serverspec入門
Itamae-Serverspec入門
Node.jsアプリの開発をモダン化するために取り組んできたこと
Node.jsアプリの開発をモダン化するために取り組んできたこと
Apache OpenWhiskで実現するプライベートFaaS環境 #tjdev
Apache OpenWhiskで実現するプライベートFaaS環境 #tjdev
Redisの特徴と活用方法について
Redisの特徴と活用方法について
JenkinsとCodeBuildとCloud Buildと私
JenkinsとCodeBuildとCloud Buildと私
show コマンド結果をパースする方法あれこれ #npstudy
show コマンド結果をパースする方法あれこれ #npstudy
20210216 AWS Black Belt Online Seminar AWS Database Migration Service
20210216 AWS Black Belt Online Seminar AWS Database Migration Service
Similar to serverspecでサーバ環境のテストを書いてみよう
とあるDBAの黒い画面(ターミナル)
とあるDBAの黒い画面(ターミナル)
Kazuhiro Yoshikawa
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
賢 秋穂
マニアックツール紹介、マネジメントのKnife-Zero(Chef)とテストスイートInSpec
マニアックツール紹介、マネジメントのKnife-Zero(Chef)とテストスイートInSpec
Yukihiko SAWANOBORI
分散メモリ環境におけるシェルスクリプトの高速化手法の提案
分散メモリ環境におけるシェルスクリプトの高速化手法の提案
Keisuke Umeno
第20回CloudStackユーザ会_ApacheCloudStack4.4新機能紹介
第20回CloudStackユーザ会_ApacheCloudStack4.4新機能紹介
Midori Oge
serverspecを使用したサーバ設定テストの実例
serverspecを使用したサーバ設定テストの実例
Koichi Shimozono
ネットワークエンジニアのための Puppet / Chef
ネットワークエンジニアのための Puppet / Chef
npsg
Fluentd casual
Fluentd casual
oranie Narut
Ansibleで始めるinfraTDD(初級編)
Ansibleで始めるinfraTDD(初級編)
佐久本正太
SAS Visual Analytics 6.3 を使った DELL VRTX の評価
SAS Visual Analytics 6.3 を使った DELL VRTX の評価
Dell TechCenter Japan
ポリドックにServerspecを教えよう!
ポリドックにServerspecを教えよう!
ftnk
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
Akihiro Kuwano
Tokyor14 - R言語でユニットテスト
Tokyor14 - R言語でユニットテスト
Yohei Sato
Web Operations and Perl kansai.pm#14
Web Operations and Perl kansai.pm#14
Masahiro Nagano
tcpdump & xtrabackup @ MySQL Casual Talks #1
tcpdump & xtrabackup @ MySQL Casual Talks #1
Ryosuke IWANAGA
Windows PowerShell 2.0 の基礎知識
Windows PowerShell 2.0 の基礎知識
shigeya
MoteMote Compiler Plugin
MoteMote Compiler Plugin
yoshiaki iwanaga
T sql の parse と generator
T sql の parse と generator
Oda Shinsuke
Mastodonインスタンスをセットアップできるスタートアップスクリプトについて
Mastodonインスタンスをセットアップできるスタートアップスクリプトについて
さくらインターネット株式会社
〜Apache Geode 入門 Multi-site(WAN)構成によるクラスター連携
〜Apache Geode 入門 Multi-site(WAN)構成によるクラスター連携
Akihiro Kitada
Similar to serverspecでサーバ環境のテストを書いてみよう
(20)
とあるDBAの黒い画面(ターミナル)
とあるDBAの黒い画面(ターミナル)
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
マニアックツール紹介、マネジメントのKnife-Zero(Chef)とテストスイートInSpec
マニアックツール紹介、マネジメントのKnife-Zero(Chef)とテストスイートInSpec
分散メモリ環境におけるシェルスクリプトの高速化手法の提案
分散メモリ環境におけるシェルスクリプトの高速化手法の提案
第20回CloudStackユーザ会_ApacheCloudStack4.4新機能紹介
第20回CloudStackユーザ会_ApacheCloudStack4.4新機能紹介
serverspecを使用したサーバ設定テストの実例
serverspecを使用したサーバ設定テストの実例
ネットワークエンジニアのための Puppet / Chef
ネットワークエンジニアのための Puppet / Chef
Fluentd casual
Fluentd casual
Ansibleで始めるinfraTDD(初級編)
Ansibleで始めるinfraTDD(初級編)
SAS Visual Analytics 6.3 を使った DELL VRTX の評価
SAS Visual Analytics 6.3 を使った DELL VRTX の評価
ポリドックにServerspecを教えよう!
ポリドックにServerspecを教えよう!
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
Tokyor14 - R言語でユニットテスト
Tokyor14 - R言語でユニットテスト
Web Operations and Perl kansai.pm#14
Web Operations and Perl kansai.pm#14
tcpdump & xtrabackup @ MySQL Casual Talks #1
tcpdump & xtrabackup @ MySQL Casual Talks #1
Windows PowerShell 2.0 の基礎知識
Windows PowerShell 2.0 の基礎知識
MoteMote Compiler Plugin
MoteMote Compiler Plugin
T sql の parse と generator
T sql の parse と generator
Mastodonインスタンスをセットアップできるスタートアップスクリプトについて
Mastodonインスタンスをセットアップできるスタートアップスクリプトについて
〜Apache Geode 入門 Multi-site(WAN)構成によるクラスター連携
〜Apache Geode 入門 Multi-site(WAN)構成によるクラスター連携
More from Daisuke Ikeda
AIOpsで実現する効率化 OSC 2022 Online Spring TIS
AIOpsで実現する効率化 OSC 2022 Online Spring TIS
Daisuke Ikeda
Osc 2021 fall_tis_変化に強いチーム育成のための取り組み紹介
Osc 2021 fall_tis_変化に強いチーム育成のための取り組み紹介
Daisuke Ikeda
OSC 2020 Fukuoka IT運用自動化を支援する「運用レコメンドプラットフォーム」実現の舞台裏
OSC 2020 Fukuoka IT運用自動化を支援する「運用レコメンドプラットフォーム」実現の舞台裏
Daisuke Ikeda
OSC2019 LT 運用レコメンドプラットフォーム開発におけるマイクロサービス構成の実現
OSC2019 LT 運用レコメンドプラットフォーム開発におけるマイクロサービス構成の実現
Daisuke Ikeda
Zabbixを徹底活用してみよう ~4.2の最新情報もご紹介~
Zabbixを徹底活用してみよう ~4.2の最新情報もご紹介~
Daisuke Ikeda
2019/4/18 Zabbix勉強会 徹底活用本の改訂の話
2019/4/18 Zabbix勉強会 徹底活用本の改訂の話
Daisuke Ikeda
OSC2018Tokyo/Fall 自律的運用に向けた第一歩(OpsBear取り組み紹介)
OSC2018Tokyo/Fall 自律的運用に向けた第一歩(OpsBear取り組み紹介)
Daisuke Ikeda
Jtf2018 自律的運用に向けた第一歩
Jtf2018 自律的運用に向けた第一歩
Daisuke Ikeda
保守運用現場の課題共有しませんか?-OSC2018LT-
保守運用現場の課題共有しませんか?-OSC2018LT-
Daisuke Ikeda
Serverspecを自分好みにアレンジ スクリーンショットで証跡保存を撲滅-
Serverspecを自分好みにアレンジ スクリーンショットで証跡保存を撲滅-
Daisuke Ikeda
AWS Ops系サービスが更に便利になる中、それでもなおZabbixとセットで考えたほうが良いのか?
AWS Ops系サービスが更に便利になる中、それでもなおZabbixとセットで考えたほうが良いのか?
Daisuke Ikeda
JobScheduler ユーザカンファレンス 2016 東京日産コンピュータシステム様 事例紹介
JobScheduler ユーザカンファレンス 2016 東京日産コンピュータシステム様 事例紹介
Daisuke Ikeda
Tech circle bot x zabbix オペレータbot lt
Tech circle bot x zabbix オペレータbot lt
Daisuke Ikeda
インフラ運用管理ツールとGolang OSS運用管理勉強会LT
インフラ運用管理ツールとGolang OSS運用管理勉強会LT
Daisuke Ikeda
Tech circle#13 zabbix3.0ハンズオン lld
Tech circle#13 zabbix3.0ハンズオン lld
Daisuke Ikeda
Zabbix超入門
Zabbix超入門
Daisuke Ikeda
Osc2016 tokyo sprint-jobschedulerを活用したoperations as codeの世界
Osc2016 tokyo sprint-jobschedulerを活用したoperations as codeの世界
Daisuke Ikeda
Job schedulerを活用したoperations as codeの世界
Job schedulerを活用したoperations as codeの世界
Daisuke Ikeda
Zabbix conference2015 daisukeikeda
Zabbix conference2015 daisukeikeda
Daisuke Ikeda
第8回oss運用管理勉強会 Zabbix入門&Zabbix3.0先取り紹介
第8回oss運用管理勉強会 Zabbix入門&Zabbix3.0先取り紹介
Daisuke Ikeda
More from Daisuke Ikeda
(20)
AIOpsで実現する効率化 OSC 2022 Online Spring TIS
AIOpsで実現する効率化 OSC 2022 Online Spring TIS
Osc 2021 fall_tis_変化に強いチーム育成のための取り組み紹介
Osc 2021 fall_tis_変化に強いチーム育成のための取り組み紹介
OSC 2020 Fukuoka IT運用自動化を支援する「運用レコメンドプラットフォーム」実現の舞台裏
OSC 2020 Fukuoka IT運用自動化を支援する「運用レコメンドプラットフォーム」実現の舞台裏
OSC2019 LT 運用レコメンドプラットフォーム開発におけるマイクロサービス構成の実現
OSC2019 LT 運用レコメンドプラットフォーム開発におけるマイクロサービス構成の実現
Zabbixを徹底活用してみよう ~4.2の最新情報もご紹介~
Zabbixを徹底活用してみよう ~4.2の最新情報もご紹介~
2019/4/18 Zabbix勉強会 徹底活用本の改訂の話
2019/4/18 Zabbix勉強会 徹底活用本の改訂の話
OSC2018Tokyo/Fall 自律的運用に向けた第一歩(OpsBear取り組み紹介)
OSC2018Tokyo/Fall 自律的運用に向けた第一歩(OpsBear取り組み紹介)
Jtf2018 自律的運用に向けた第一歩
Jtf2018 自律的運用に向けた第一歩
保守運用現場の課題共有しませんか?-OSC2018LT-
保守運用現場の課題共有しませんか?-OSC2018LT-
Serverspecを自分好みにアレンジ スクリーンショットで証跡保存を撲滅-
Serverspecを自分好みにアレンジ スクリーンショットで証跡保存を撲滅-
AWS Ops系サービスが更に便利になる中、それでもなおZabbixとセットで考えたほうが良いのか?
AWS Ops系サービスが更に便利になる中、それでもなおZabbixとセットで考えたほうが良いのか?
JobScheduler ユーザカンファレンス 2016 東京日産コンピュータシステム様 事例紹介
JobScheduler ユーザカンファレンス 2016 東京日産コンピュータシステム様 事例紹介
Tech circle bot x zabbix オペレータbot lt
Tech circle bot x zabbix オペレータbot lt
インフラ運用管理ツールとGolang OSS運用管理勉強会LT
インフラ運用管理ツールとGolang OSS運用管理勉強会LT
Tech circle#13 zabbix3.0ハンズオン lld
Tech circle#13 zabbix3.0ハンズオン lld
Zabbix超入門
Zabbix超入門
Osc2016 tokyo sprint-jobschedulerを活用したoperations as codeの世界
Osc2016 tokyo sprint-jobschedulerを活用したoperations as codeの世界
Job schedulerを活用したoperations as codeの世界
Job schedulerを活用したoperations as codeの世界
Zabbix conference2015 daisukeikeda
Zabbix conference2015 daisukeikeda
第8回oss運用管理勉強会 Zabbix入門&Zabbix3.0先取り紹介
第8回oss運用管理勉強会 Zabbix入門&Zabbix3.0先取り紹介
serverspecでサーバ環境のテストを書いてみよう
1.
serverspecで サーバ環境のテストを書いてみよう TIS 池田 大輔(
@ike_dai )
2.
Agenda ● 1. 基本の紹介 ○
serverspecとは何か? ○ 導入方法の紹介 ○ 設定方法の紹介 ○ テストコードの書き方 ● 2. 簡単なデモ ○ テスト実行 ○ 結果の表示 ● 3. 属性情報の扱い方 ○ 属性情報を外出しして実行 ● 4. カスタマイズしてみる ○ NTP時刻同期状況テストを作ってみる
3.
serverspecの基本 ● serverspecとは? ○ サーバの状態をテストするためのフレームワーク ○
Ruby実装 (8/14時点最新version 0.7.8 ※日々バージョンアップするので注意) ○ Rspecに準拠した形式で記述が可能→Rspecに慣れた方ならすぐに書けるかも ○ ChefやPuppet等環境の自動構成管理ツールと組み合わせて使うのに最適 ○ serverspecは構成管理ツールに依存せずにテストコードが書ける ○ テスト実行方法は2種類 ■ ローカルに対してテスト実行 ■ SSH接続してテスト実行 ○ テストコードを1箇所で集約管理 ○ ただ単にSSH接続して実行するので特別なAgentの導入の必要がない
4.
serverspecの基本 ● どんな用途で使う? ○ 自動構築した結果、正しく稼働しているか確認 ○
内部から見てどう動いているのかを確認するため、外から見てどうかは Zabbix等の監視ツールを利用 ■ ポートがリッスンしているか?iptablesでそのポートを開放する設定が されているか?はserverspecで確認 ■ 本当にそのポートにアクセスできるか?アクセスが拒否されるか?は 監視ツールで確認
5.
serverspecの導入方法 ● gemコマンドで簡単にインストール可 ● インストール後、テストコード初期設定実施 $
gem install serverspec $ serverspec-init Select a backend type: 1) SSH 2) Exec (local) Select number: 1 Vagrant instance y/n: n Input target host name: 192.168.xxx.xxx + spec/ + spec/192.168.xxx.xxx/ + spec/192.168.xxx.xxx/httpd_spec.rb + spec/spec_helper.rb + Rakefile
6.
● 事前設定 ○ 1.SSH接続設定 ○
2.sudo設定 SSH接続設定 ● ● 1. 公開鍵のキーペア作成 (NoPasswordで) ● 2. テスト対象機器側の鍵認証設定 ● 3. serverspec実行機器側での.ssh/config設定 serverspecの設定方法 $ vim .ssh/config Host 192.168.xxx.xxx HostName 192.168.xxx.xxx Port 22 IdentityFile ~/.ssh/serverspec_test User maintain serverspec-init実行時に指定したホスト名と 一致するように設定
7.
sudo設定 ● SSHログイン後に実行されるテスト処理はsudoをつけて実行される ● 接続ユーザに対してsudo権限を付与(実行されるサーバ側で設定) ●
serverspec実行サーバ上の環境変数指定 ● spec/spec_helper.rbを書き換えればパスワード認証のSSHログインも可能 serverspecの設定方法 # visudo maintain ALL=(ALL) NOPASSWD:ALL $ export SUDO_PASSWORD=”xxxxxxxx” or $ export ASK_SUDO_PASSWORD=1 sudo実行時のパスワードを環境変数にセット sudo実行時のパスワードを対話式入力有効化
8.
● 重要なのはリソースタイプとマッチャー ● この組み合わせで様々なテストが記述できる ●
リソースタイプ ○ command,cron,default_gateway,file,group,host,interface,ipfilter,ipnat, iptables,kernel_module,linux_kernel_parameter,package,php_config,port, routing_table,selinux,service,user,yumrepo,zfs ● マッチャー ○ 例:commandリソースタイプの場合 ■ return_stdout:あるコマンド実行時の標準出力の文字列確認テスト ■ return_stderr:あるコマンド実行時の標準エラー出力の文字列確認テスト テストコードの書き方 詳しくはこちら: http://serverspec.org/
9.
● 例: 指定したパッケージがインストールされているかどうかのテスト テストコードの基本 $
vim spec/httpd_spec.rb require 'spec_helper' describe package('httpd') do it { should be_installed } end リソースタイプを指定 マッチャーを指定してテスト実行
10.
● ソースコードが非常に見やすい 1. どのリソースタイプか? -
インストールディレクトリ/serverspec-バージョン/lib/serverspec/type以下を確認 - 先述の例のテストの場合、package.rbを確認 2. どのマッチャーか? - be_installedの場合、def installed?を確認 - この中に処理が記述 - def installed?の内部ではcheck_installedメソッドが呼ばれている 3. 実際の処理メソッドを確認 - check_installedメソッドを確認(commands/redhat.rb,debian.rb...) - OS毎にテスト実行コマンドが違う場合はOS毎に用意されているファイルに - OS共通のテスト実行コマンドの場合はcommands/base.rbに ソースコードの追い方
11.
● テスト実行時に実際にはどんなコマンドが実行されているの? ○ RedHat系の場合(lib/serverspec/commands/redhat.rb) ○
Debian系の場合(lib/serverspec/commands/debian.rb) テスト実行時のコマンド def check_installed(package,version=nil) cmd = "rpm -q #{escape(package)}" if ! version.nil? cmd = "#{cmd} | grep -w -- #{escape(version)}" end cmd end def check_installed(package,version=nil) escaped_package = escape(package) "dpkg -s #{escaped_package} && ! dpkg -s #{escaped_package} | grep -E '^Status: .+ not- installed$'" end
12.
● テスト実行時に実際にはどんなコマンドが実行されているの? ○ RedHat系の場合(lib/serverspec/commands/redhat.rb) ○
Debian系の場合(lib/serverspec/commands/debian.rb) テスト実行時のコマンド def check_installed(package,version=nil) cmd = "rpm -q #{escape(package)}" if ! version.nil? cmd = "#{cmd} | grep -w -- #{escape(version)}" end cmd end def check_installed(package,version=nil) escaped_package = escape(package) "dpkg -s #{escaped_package} && ! dpkg -s #{escaped_package} | grep -E '^Status: .+ not- installed$'" end
13.
● 実行されるコマンドが何であるかを理解した上で書きましょう ○ httpdパッケージのインストールバージョンをテストする場合の例 ■
極端な例ですが、以下2つはどちらもテストOKになる テストコード作成時の注意点 実際にインストールされているパッケージ $ rpm -q httpd httpd-2.2.15-15.el6.centos.x86_64 バージョン指定した場合に実行されるコマンド $ rpm -q httpd | grep -w -- 指定した文字列 describe package('httpd') do it { should be_installed.with_version('2.2') } end describe package('httpd') do it { should be_installed.with_version('2.15') } end
14.
● 実行方法 ● ~/.rspecファイルを編集して表示を見やすく ●
テスト失敗時、どういったコマンドが実行されのかが表示される デモ $ rake spec --color --format documentation(またはs) 色付けをして表示 実行結果を文字列表記 Failures: 1) Port "80" Failure/Error: it { should be_listening } sudo netstat -tunl | grep -- :80 expected Port "80" to be listening # ./spec/192.168.xxx.xxx/httpd_spec.rb:13:in `block (2 levels) in <top (required)>' 実際に実行されたコマンド
15.
● テスト対象サーバ毎に変更する属性値を外だし管理可能 1. 属性値情報をまとめたYAMLファイル作成 2.
RakefileをYAMLファイルのキーの項目毎にテスト実行できるよう編集 3. spec/spec_helper.rbを編集し、属性値を変数に格納 4. テストコード内部で3.で格納した変数を利用するよう変更 設定情報を外だし 詳しくはこちら: http://mizzy.org/blog/2013/05/12/2/
16.
● サーバ毎に異なるApacheのバージョンのテストを実施する場合の例 1. 属性値情報をまとめたYAMLファイル作成(attributes.yml) 設定情報を外だし 192.168.xxx.xxx: :apache_version:
2.2.15 192.168.yyy.yyy: :apache_version: 2.4.4 キー 属性値
17.
● サーバ毎に異なるApacheのバージョンのテストを実施する場合の例 2. RakefileをYAMLファイルのキーの項目毎にテスト実行できるよう編集 設定情報を外だし require
'rake' require 'rspec/core/rake_task' require 'yaml' attributes = YAML.load_file('attributes.yml') desc "Run serverspec to all services" task :spec => 'spec:all' namespace :spec do task :all => attributes.keys.map {|key| 'spec:' + key } attributes.keys.each do |key| desc "Run serverspec to #{key}" RSpec::Core::RakeTask.new(key.to_sym) do |t| ENV['TARGET_HOST'] = key t.pattern = "spec/#{key}/*_spec.rb" end end end attrubutes.yml読込み キー毎にspecを実行するよう変更 spec_helperで利用するため 環境変数にキー情報を登録
18.
● サーバ毎に異なるApacheのバージョンのテストを実施する場合の例 3. spec/spec_helper.rbを編集し、属性値を変数に格納 設定情報を外だし require
'serverspec' require 'pathname' require 'net/ssh' require 'yaml' include Serverspec::Helper::Ssh include Serverspec::Helper::DetectOS include Serverspec::Helper::Attributes attributes = YAML.load_file('attributes.yml') RSpec.configure do |c| ・・・略 attr_set attributes[ENV['TARGET_HOST']] end attr_setで指定した キーの属性値を変数に格納
19.
● サーバ毎に異なるApacheのバージョンのテストを実施する場合の例 4. テストコード内部で3.で格納した変数を利用するよう変更 設定情報を外だし describe
package('httpd') do it { should be_installed.with_version(attr[:apache_version]) } end attr[:属性名]という変数に値が格納
20.
● 簡単にカスタマイズすることも可能 ○ commandリソースを使えば任意のコマンド実行テストが可能だが ○
よく使うものは新たにリソースタイプ、マッチャーを作成すれば使い回しできる ● 参考例:ntpの時刻同期状況テストを新たに追加してみる ○ 目指す形 ■ テスト対象サーバ内の指定したntpサーバのステータスをテスト カスタマイズしてみる describe ntp('xxx.xxx.xxx.xxx') do its(:status) { should eq '*' } end
21.
● リソースタイプを追加 ○ lib/serverspec/helper/type.rbにリソースタイプを追加 ○
今回はntpというリソースタイプを新たに追加 カスタマイズしてみる 4: types = %w( 5: base yumrepo service package port file cron command linux_kernel_parameter iptables host 6: routing_table default_gateway selinux user group zfs ipnat ipfilter kernel_module interface php_config ntp 7: ) ここにタイプを追加することで serverspec/type/ntp.rbが読み込まれてリソースタ イプが有効になる。
22.
● ntpリソースタイプの定義 ○ lib/serverspec/type/ntp.rbに定義内容を記述 カスタマイズしてみる module
Serverspec module Type class Ntp< Base def status ret = backend.run_command(commands.get_ntp_status_of(@name)) val = ret[:stdout].strip val end end end end status情報を取得するためのメソッドを定義
23.
● 実行コマンド処理を記述 ○ lib/serverspec/commands/linux.rbに実際の処理内容を記述 ○
各OSに依存する処理を書きたい場合はredhat.rbとかdebian.rbとかOS毎の ファイルに処理を記載 カスタマイズしてみる def get_ntp_status_of(name) "ntpq -p -n | grep #{name} | head -c1" end 実際に実行されるコマンド $ sudo ntpq -p -n remote refid st t when poll reach delay offset jitter ================================================================== *172.xx.xx.xx 172.xx.xxx.xx 6 u 248 1024 377 0.799 25.298 20.663 ここのステータス情報を取得
24.
● serverspecはサーバ内部の状況が正しいかどうかをテストす るフレームワーク ● ChefやPuppet等自動構築ツールに依存せず手軽に扱える ●
SSHログインしてテスト実行することが可能なので複数サーバ のテストを統合管理可能 ● カスタマイズも容易にできるのでいろんな場面に適用も可 まとめ
Download now