0. はじめに Gossというテストツールを紹介します Gossの初歩的な使い方を紹介します Gossを使う上での小ネタをいくつか紹介します 1. Goss？ 1.1. Gossとは テストツールの1つで、Serverspecと競合する。GossはGo言語で書かれており、バイナリ形式でサーバに配布される。 テストはYAML形式で書くが、変数はYAMLでもJsonでも対応している。 1.2. Serverspecに負けているところ 1つめ。Gossはリモートでテストする機能がない点。AnsibleのGossモジュール など、非公式ではあるものの何かと組み合わせる他ない。つまり、あるサーバでテスト結果を集約するのに対して、信頼性が薄い。が、本番環境でもこういうものが使えるよ、という組織にとってはCIサーバで構築もテストも集約して行えるので、あまりServerspecに負けているとは言えない。
こんにちは！ a-know こと、いのうえです。 ここではあまり技術的な記事を書くことが少ない私ですが、今回は少し、踏み込んだ内容の記事をお届けしたいと思います。 ...あ、この記事は フィードフォースエンジニア Advent Calendar 2015 の 15日目の記事であり、また、Google Cloud Platform Advent Calendar 2015の 15日目の記事でもあります。 はじめに タイトルにある "GCE" とは、いわずもがな、 "Google Compute Engine" のことですが、その "preemptible VM" とは、下記のような特徴を持ったインスタンスのことです。 Google の膨大なデータセンターの余剰リソースを活用したインスタンス 低コスト（最大70%オフ） 低寿命（最大で24時間までしか持続しない） 上記のような特徴以外は、基本的
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 Packerを使うと、VagrantやVMware、Amazon EC2用のAMIなどなどのさまざまな仮想マシンのテンプレートを簡単に作成することができるのはご存知の通りです。 一方で作成した仮想マシンのテンプレートが必要な要件を満たしているかどうかは、仮想マシンのテンプレートを作るたびに検査しなければなりません。 ここでは、PackerとServerspecを組み合わせて、仮想マシンのテンプレートを作成する際に、テストも併せておこなう方法について解説します。 前提今回仮想マシンのテンプレートを作成するにあたっては以下の方式で行ないます。 Packer 0.7.2Packerでの仮想
[2014-01-09-1] からmasutaka.netのCIを開始したが、残念ながら masutaka.netに直接serverspecする、なんちゃってCIだった。 masutaka.netにcookしてからPRを出して、WerckerにCIさせていた。 WerckerとAWSを連携させて、テストのたびにサーバをまっさらな状態から 作り、終わったら破棄することが可能になったので、ここに記録しておく。 去年くらいに話題になったこの辺の話。 Vagrant + Chef Solo + serverspec + Jenkins でサーバー構築を CI - naoyaのはてなダイアリー naoya/circleci-serverspec なんで今までやらなかったかというと、cookが一発で通らないレシピになっ ていたから。。気づいてはいたんだけど、本番サーバのテストが通りさえ すればよかった
第2回ではシンプルな環境を例に、設定記述の際のポイントをいくつか紹介しました。実際の環境では、より複雑で管理するサーバの台数が非常に多いこともあるでしょう。そのような条件下でも、迅速にテストコードを記述しなければならない状況においては、さらに効果的なテストコード管理のための工夫が必要です。そこで最終回の第3回目は、Serverspecでテストコードを書いたりコードを管理したりする際に、より効率良く行うためのTipsを紹介します。 Serverspecの公式サイトにも様々なTipsがまとめられているので大変参考になります。こちらもあわせてご覧ください。 Serverspec Advanced Tips（英語での解説ページですが、非常に参考になります。） http://serverspec.org/advanced_tips.html 共通のテストコードをまとめて管理 第2回では、1台のサーバ
Serverspec書いてますか！ Serverspecが超高速で書けるようにsnippetsを作成しました。(本当は私がResource Typesを全く覚えられないので作成しただけなんですが) glidenote/serverspec-snippets どんな感じのものなのかは動画を見て頂くのが早いです。 インストール方法や使い方はglidenote/serverspec-snippets を参照ください。 https://github.com/Keithbsmiley/rspec.vim/blob/master/ftdetect/rspec.vim みたい感じで、 filetypeをruby.serverspecへと自動指定は出来るんですが、rspecと干渉するので、ちょっと良い案を思案中。 大変便利になった 追記 2014/06/26 should <=> should_notなど
今回はserverspecを簡単に触ってみました。 インストール まずはrubyをインストールします。 独立した環境を作りたい為、特定のユーザホームディレクトリ配置したrubyの環境を作ります。 $ cd /usr/local/src $ wget ftp://ftp.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p195.tar.gz $ tar -xvf ruby-2.0.0-p195.tar.gz $ cd ruby-2.0.0-p195 $ ./configure --prefix=/home/myuser/ruby --enable-shared $ make $ make install $ PATH=$PATH:/home/myuser/ruby/bin $ export PATH serverspecを導入します。gemだけで入ります。 $ /
Jenkins おじさんと戯れること半日、うまくいったので備忘録を残しておく。 やりたかったのは Chef で構築したサーバーを Jenkins で CI する、というもの。このときサーバーはテストが終わる度に破棄して、テスト開始時に再度真っ新な状態から立ち上げたい。(こういうサーバーを壊して作ってというテストはなんという名前で呼ばれるのだろう?) 仮想サーバーを破棄/作成をプログラマブルにやるのはもちろん Vagrant プロビジョニングは Chef Chef の環境を整えるのに knife-solo 0.3.0.pre3 テストは serverspec コードは Github に上げる (https://github.com/naoya/jenkins-vagrant-test) CI は Jenkins という構成になっている。ひとまず Jenkins や Vagrant はローカル
先日http:/http://togetter.com/li/501076togetter.com/li/501076(5/10)開催されたProvisioning Frameworks Casual Talks vol.1に参加しました。 Provisioning Frameworks Casual Talks vol.1の中身は他の方がたくさんブログを書かれているのでそちらを参照して下さい。 Provisioning Frameworks Casual Talks vol.1 - Togetter serverspecの話がたくさん出てきたので自分も試しにservespecを使ってテストコードを書いてみました。 ついでに、serverspecのver.0.3.0から利用できるようになったattributeの機能も使ってみました。 serverspecのattributeはこちらを参考に
注意！ v0.11.0 からは attr, attr_set ではなく、property, set_property とメソッド名が変更されています。attr, attr_set は近い将来使えなくなります。最新の情報はこちらを参照してください。 注意！ ここで解説する方法は v0.3.0 から利用できます。 Provisioning Frameworks Casual Talks vol.1 に行ってきた #pfcasual - TAKUMI SAKAMOTO'S BLOG で触れられている attributes 周りについて、この辺は必要になるだろうなー、と前から思ってはいたので、それを実現するための極々簡単な仕組みを 試験的に実装してみた 。 これは単に attr_set と attr という2つのヘルパーメソッドを使えるようにしただけのものなんだけど、以下のような感じで使える。 今
今回は serverspec のテストをホスト間で共有する方法について説明します。 serverspec-init を実行して生成されるひな形ファイルは以下のようになっています。 |-- Rakefile `-- spec |-- spec_helper.rb `-- www.example.jp `-- httpd_spec.rb これを見てわかる通り、テスト対象となるホスト名でディレクトリが掘られ、その下に対象ホストに対する spec が置かれる、という形になっています。 したがって、複数の役割が同じホストに対してテストを実行しようとすると、こんな感じで同じ内容の spec ファイルが重複して置かれることになります。 |-- Rakefile `-- spec |-- app001.example.jp | `-- ruby_spec.rb |-- app002.example.jp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く