A method for separating policy definition and behavior control by an intermediate language to achieve optimal server configuration management according to the situation
こんにちは。缶コーヒーを愛してやまないクラウドワークスのエンジニア森田です。 Infrastructure as Code と叫ばれて久しいですが、現実はそんなに単純な話ばかりじゃないですよね(´・ω・`) 新規に立てるサーバで設定内容が自明であればよいんですけれども、 既に本番運用されており、温かみのある職人の手仕事によって維持管理されているサーバってありますよね? 管理者が一人ならまだしも、複数人で設定変更したりしてると、どのような設定が入っているのかがブラックボックスで、 それを後からコードに置き換えるには困難が伴います。 この「既存のサーバ」と「コードで生成したサーバ」のファイルシステム全体の差分を効率的に調査する目的で、 任意の2つのサーバ設定を比較するAjimiという便利ツールを作ったのでご紹介します。 はじめに 要件整理 作ったもの インストール 初期設定 味見する 設定詳細
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
サーバのプロビジョニングをテストするTest-Kitchenが、v1.4でテストのステップ(verify)を追加しやすい変更をいれてきました。 そこで一本kitchen-verifier-shellを作りました。(RubyGemは本家に取り込まれるまでの限定公開です。) busserとServerspec、Infrataster 従来のTest-Kitchenのテストはbusserというラッパを使って、テストスイートを対象のプラットホーム(VMなど)にインストールします。 馴染みのある例ではbusser-serverspecなどは、もはや公式のポジションですね。 ただ、テスト対象に直接インストールするというあたりで時間がかかったり、少々トラブルも発生します。 元々、対象の外からつついてテストしようというServerspecや、外からテストしてなんぼというInfratasterは、できるなら
Serverspec本の献本ありがとうございました.とても面白かったです.詳しい書評はすでに素晴らしい記事がいくつかあるので,僕は現チームでどのようにServerspecを導入したか,どのように使っているかについて書きたいと思います. Serverspec導入の背景 今のチームではサーバーのセッアップおよびデプロイにChefを使っている.本にも書かれているようにこのような構成管理ツールを使っている場合はそのツールを信頼するべきであり,Serverspecのようなテストツールは必要ない.僕らのチームもそのような理由でServerspecの導入には至っていなかった. しかしアプリケーションが複雑になりChefのレシピも混沌とするようになるとそれは成立しなくなる.見通しの悪いレシピはChefへの信頼度を落とす.信頼度の低下はデプロイ不信に繋がり人手(筋肉)によるテストが始まる. サーバーの数がそ
やってること ec2のipを動的に取得 取得したipに対し、Serverspecを実行するtaskを動的に定義 上記のtaskを全て実行するtaskを定義 awsのaccess key情報が環境変数で指定されてない場合、ec2の情報を取得しない 前提及び筆者の環境 aws-sdkはv1を使用 vagrantというホストに対して実行するspecが予め存在している $ ls -la spec -rw-r--r-- 1 nekogeruge staff 640 2 16 14:34 spec_helper.rb drwxr-xr-x 4 nekogeruge staff 136 1 13 17:42 vagrant ec2に実行するspecはvagrantと同じものを使用する Serverspecを実行したいインスタンスには、踏み台サーバを介した多段sshを使用して接続しており、下記のような.s
著者のmizzyさんこと宮下剛輔氏よりご恵贈いただきました。ありがとうございます。 Serverspec 作者: 宮下剛輔出版社/メーカー: オライリージャパン発売日: 2015/01/17メディア: 単行本(ソフトカバー)この商品を含むブログ (1件) を見る さて、本書について、技術的な側面で語れるひとはたくさんいるだろうので、ちょっと趣向を変えて、エッセイ的な話を書く。ちょうど、著者も「本書は、単なるServerspecに関する解説書ではなく、Serverspecに関する思いを綴ったエッセイとも言えるかもしれません」(「はじめに」より)と書いていることだし。 Serverspec誕生の頃 約2年前の今頃、ある新しいシステムのためにサーバを構築しようとしていて、我々(mizzyさん、@lamanotramaさん、僕)は苦心していた。Puppetでサーバ構成を記述するに際して、もっといけ
サーバの状態を自動でチェックするためのテスティングツールである「Serverspec」。開発者のmizzyさんが書き下ろした書籍が出版されるということで、著者/出版社の方々からご献本いただきました。ありがとうございます! Serverspec 作者: 宮下剛輔出版社/メーカー: オライリージャパン発売日: 2015/01/17メディア: 単行本(ソフトカバー)この商品を含むブログ (6件) を見る いきなりですが余談 当方も、サーバまわりのプロビジョニングツールとして、2008年頃よりPuppet、2010年頃よりChefを使っていますが、特にChefを使ってからは、それなりの規模の環境で複数名でメンテナンスするケースが多かったので、テストについてはそれなりに頭を悩ませました。 使い始めの頃は、おはずかしながらテストなど全く無く、仮想環境でチェックしていた(普通に目見の他、出力された文字列
Serverspec本を献本していただいて一足速く読むことが出来たので感想エントリを書きます.献本って初めての経験なので少々緊張しています. serverspec本届いてた!!献本ありがとうございます!! pic.twitter.com/un77PXebDe— メンヘラ (@catatsuy) 2015年1月10日 Serverspec 作者: 宮下剛輔出版社/メーカー: オライリージャパン発売日: 2015/01/17メディア: 単行本(ソフトカバー)この商品を含むブログ (6件) を見る O'Reilly Japan - Serverspec 「Serverspec」という本が出ます - Gosuke Miyashita 献本していただけた理由 ところで献本していただけた理由ですが,私がインフラに配属されてからの初仕事としてセットアップスクリプトに Serverspec による CI
本書は、Serverspecの開発者自身により書かれた初の書籍です。機能の詳細、動作仕様や内部のアーキテクチャ、ソースコードレベルで拡張する方法、開発に至る経緯や開発に関する哲学など、開発者自身にしか書けない包括的な内容を紹介。Serverspecとその周辺について既にある程度の知識や理解があるが、さらに踏み込んだ内容が知りたい、自分の手足のように使いこなしたい、もっと高度で詳細な情報を知りたい、思い通りに拡張したいと考える開発者やシステム管理者なら必携の一冊。伊藤直也氏による「まえがき」を収録。 まえがき はじめに 1章 Serverspecの紹介 1.1 Serverspecが生まれた経緯 1.2 Serverspecとは何か 1.3 Serverspecの利用目的 1.4 Serverspecの必要性 1.5 Serverspec開発の哲学 1.6 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
Dockerが使えるようになったため、Jenkinsにより仮想サーバの起動から、サーバ構築、テスト、仮想サーバの廃棄までを自動化してみました。 やりたいこと 以下のように、Chefのリポジトリの更新をトリガーに、仮想サーバの起動から、サーバ構築、テスト、仮想サーバの廃棄までをJenkinsにて自動化します。 Chefのレシピをリモートリポジトリへgit pushすると、Jenkinsが通知を検知 JenkinsからDockerの仮想サーバ(コンテナ)を起動 起動が成功すれば、Chefを実行し、サーバを構築 サーバ構築が成功すれば、serverspecを実行し、サーバの状態をテスト テストが成功すれば、Dockerの仮想サーバ(コンテナ)を廃棄 また、Dockerの起動停止、サーバ構築、テストは全てSSH接続により行います。 構成 CentOS 6.5 : Chef、serverspec、J
概要 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のインストール デーモン起動 自動起動設定 これらを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く