Ansibleのテストで使いたい8つのServerspec | DevelopersIO
渡辺です。 Ansibleを使っている皆様、テスト書いてますか？ え、書いてない？ 弊社では、社内共有しているAnsibleのRoleの検証にServerspecを利用しています。 今日はよく使うリソースタイプを紹介します。 テストの流れ テストのフレームワークとしてはTest Kitchenを利用しています（kitchen-ansiblepushを利用したAnsible roleのテスト環境構築）。 はじめに、Test KitchenのEC2 Driverを利用し、AWS環境にEC2インスタンスを作成します。 次に、ひとつのRoleを実行するAnsibleのPlaybookを流します。 続けて、サーバの状態が期待された状態になっているかをServerspecで検証します。 最後に、AWS環境にEC2インスタンスが破棄されます（検証失敗時は破棄されない）。 Ansibleでもテストの仕組み
Alpine LinuxなDockerイメージにServerspecを実行する環境を作った - Glide Note
TL;DR Alpine LinuxなDockerイメージにServerspecを実行する環境をMacとCircleCI上に作った CircleCI環境では lxc-attach コマンドが必要なので、spec_helper.rb で環境差を吸収するようにした 今後よく利用しそうなので、流用しやすい形でGithubに置いておいた glidenote/docker-alpine-serverspec-sample 前提 最近Kaizen Platform, Inc.で利用している一部Docker ImageをAmazon LinuxベースのものからAlpine Linuxベースのものに置き換え中。 Alpine Linuxについては@stormcat24さんのブログが一番参考になります。 今までDockerイメージにServerspecを実行するときには、コンテナ内でsshdを立てて、ssh
AWSのリソース構成をServerspecのようにテストする "awspec" をつくった - Copy/Cut/Paste/Hatena
AWSのリソース構成をServerspecのようにテストできる "awspec" をつくりました。 github.com 例えばEC2インスタンスであれば、以下のように書けます。 describe ec2('my-ec2') do it { should exist } it { should be_running } it { should_not be_stopped } its(:instance_id) { should eq 'i-ec12345a' } its(:private_ip_address) { should eq '10.0.1.1' } it { should have_security_group('my-security-group-name') } it { should belong_to_vpc('my-vpc') } it { should belon
ServerspecのDockerバックエンドでコンテナをテストする。 - タチコマ好きなエンジニアのブログ
ServerspecでDockerコンテナをテストするのにDockerバックエンドを利用してみました。 Dockerコンテナ内にSSHDを立てたくなかったので、SSHバックエンドではなくDockerバックエンドでテストを実行したかったのですが、Web上にもあまり情報がなかったのでメモしておきます。 DockerバックエンドについてはServerspec本の中で紹介されています。 DockerバックエンドはDocker Remote APIを利用してテストを実行しているようです。 Serverspec 作者: 宮下剛輔出版社/メーカー: オライリージャパン発売日: 2015/01/17メディア: 単行本（ソフトカバー）この商品を含むブログ (3件) を見る ディレクトリ構成 . ├── Dockerfile ├── Gemfile ├── Gemfile.lock └── spec ├──
サーバの状態のテスティングツールである「Serverspec」の書籍を読んだ - 元RX-7乗りの適当な日々
サーバの状態を自動でチェックするためのテスティングツールである「Serverspec」。開発者のmizzyさんが書き下ろした書籍が出版されるということで、著者/出版社の方々からご献本いただきました。ありがとうございます！ Serverspec 作者: 宮下剛輔出版社/メーカー: オライリージャパン発売日: 2015/01/17メディア: 単行本（ソフトカバー）この商品を含むブログ (6件) を見る いきなりですが余談 当方も、サーバまわりのプロビジョニングツールとして、2008年頃よりPuppet、2010年頃よりChefを使っていますが、特にChefを使ってからは、それなりの規模の環境で複数名でメンテナンスするケースが多かったので、テストについてはそれなりに頭を悩ませました。 使い始めの頃は、おはずかしながらテストなど全く無く、仮想環境でチェックしていた(普通に目見の他、出力された文字列
CircleCIでDockerコンテナに対してansibleを実行しserverspecでテストをする · さよならインターネット
November 13, 2014 参考 KAIZEN platform Inc. における運用自動化 - Speaker Deck Continous Integration and Delivery with Docker - CircleCI TL;DR CircleCI上でDockerコンテナを立て、 そのコンテナに対してプロビジョニングを行い、 プロビジョニング後のコンテナに対してテストを行う DockerコンテナにAnsibleを実行する コミットする度にDockerのimageをpullするのは時間がもったいないので cache_directoriesを利用し、imageをexportしておき 実行時にimportするようにすると多少速くなる。 . ├── Dockerfile ├── ansible/ └── circle.yml Dockerfile FROM kenji
Test KitchenでDockerとServerspecを使ってChefのレシピをテストする - tsunokawaのはてなダイアリー
概要 Test Kitchenの役割 以下を自動でやってくれます。 Dockerコンテナ起動 起動したDockerコンテナにChefレシピを適用 その後Serverspec実行 Dockerコンテナ破棄 環境 OS CentOS 6.5 このホストでTest KichenやDockerを動かします。 関連ミドルウェア 事前にインストールしておきます。 バージョンは以下のものを使用しました。 docker-io-1.0.0-6 test-kitchen-1.2.1-1 kitchen-docker-1.5.0-1 serverspec-1.11.0-1 テストするレシピ CentOS6系のサーバーに適用するレシピです。 /root/chef/repo/site-cookbooks/centos6/recipes/httpd.rb httpdのインストール デーモン起動 自動起動設定 これらを
Ansible チュートリアル | Ansible Tutorial in Japanese
Ansible Tutorial July Tech Festa にて開催されたハンズオンの資料が公開されていたことに刺激され、Chef の代わりに Ansible を使う資料を作りました。 Ansible を使って WordPress サーバーのセットアップを行い、ServerSpec でテストを行います。 まだ Ansible を試し始めたばかりで自分の勉強がてら書いています。 Puppet にも Chef にも乗り遅れたので Ansible に飛び乗ってみようかと。 GitHub Repository Ansible Tutorial Wiki 2013年08月13日 一段落 コピペで動かないところを全体的に修正しました。今後は 詳細ページ Wiki を充実させていきます 2013年09月09日 role についての追記しました 2013年12月22日 リニューアル Ansible
vagrant-configspecを使ってプロビジョニングする - KAYAC engineers' blog
@nobu_ohtaです。 teck.kayac.com Advent Calender 2013 19日目のエントリです。 今回、advent calendarを口実にvagrant-configspecをリリースしました。 インストールは vagrant plugin install vagrant-configspec です。 コード自体は https://github.com/ankoromochi/vagrant-configspec で公開しています。 動機 configspecを触ってみたかった。 mizzyさんのブログで紹介されているように、immutable infrastructureという文脈で出てきた、冪等性や依存関係をあまり気にしない感じのconfiguration management tool。 同じくmizzyさんが作者のサーバの状態のテストを行うserve
DevOpsなんてくそくらえ - razokulover publog
先日こんなことを言われた。 「テストを書いた成果を見せよ」 と。 ショッキングだった。 経緯 わたしはいまレガシーなコードに囲まれている。 もちろんテストもほとんどないピカピカのレガシーちゃんである。 レガシーちゃんは「Ctrl+F5 & tail -f 駆動開発」により開発が進められており、日々進化している。 このまま進化をつづけるといつかモンスターになり(もう軽く怪獣っぽいが)、開発スピードがどんどん遅くなり、メンテナンスやバグつぶしでエンハンスとなるような開発ができなくなる。このままじゃマズい...。 こういった事態を一新すべく、手探りながら私含め数人の先輩たちで「DevOps」に取りかかることになった。 バズワードにもなっているが「DevOps」とは、 従来型のシステム管理や調達（ITILを含む）といった、保守的でプロセスを中心に据えた運用からよ>り戦略的でアジャイルな、そして自動
Docker の Remote API + serverspec で CI - naoyaのはてなダイアリー
昨日 http://d.hatena.ne.jp/naoya/20130620/1371729625 で書いたように Docker を使えば、欲しい VM を "任意の状態" で簡単にかつ" "瞬時に" コピーして作り出すことができる。 「任意の状態」というのは、例えば「OS は CentOS で、Ruby と Chef が入っている」みたいな VM のこと 「瞬時に」というのは本当に瞬時。VM の起動時間を待ったり、Ruby や Chef を入れる時間を待つ必要はない serverspec でテストをする場合、真っ新な VM を用意してそれにプロビジョニングを行って、その後に破棄するみたいなことを良くする。このとき「真っ新なVM」を立ち上げるのに、Vagrant などが使えるが、Vagrant だとテストの度に VM を一から作り直す･･･つまり vagrant up しなければいけない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Dockerと継続的インテグレーション