STNSのバックエンドをつくろう - Qiita
この夏、あるシステムでSTNSを使えそうな気がしました。 STNSとは何か、ですって？ なら落ち着いて、時代が求めたSTNSと僕 // Speaker Deck を読みましょう。 OK、読みましたかね。 で、ユーザのDBにSaaSの何かを使えればいいなとおもってバックエンドを書けるかなという試み。時代とはつまり私だった。 この記事で出てくるコードを置きました。 https://github.com/sawanoboly/stns_backend-sinatra-example STNSのバックエンド仕様を調べました 注: こちら、記事作成時点のSTNS APIバージョン1.0の仕様についての調査です。※バックエンドの指定にv2をつけなければそのまま使えます。 API v2.1(またはそれ以降)については http://stns.jp/en/interface STNS製作者のP山さん曰く、
Chef Complianceをお試し。OSを対象にインフラテストの定期実行でポリシー監査。 - Qiita
Auditing and Compliance with Chef 先日Chef IncがVulcanoSecっちゅーところを買収し、Chef Complianceをリリースしました。うん触ってみよう。 ざっとこんなツールです。 OSのパッチ状況検出 (Linux/Windows) テストスイートInSpecのリモート実行 リモート系はSSHまたはWinRMを経由、エージェント不要 レポート作成 WebUIとAPI スケジュール 適当に作成したUbuntu14にプリセットの監査をかけると、SSH越しで色々と調べてレポートを作ってくれました。 なるほどねー。OSの自前管理を含むシステムを運用する場合の監査タスクに良さそう。 インストール＆セットアップ RPMまたはDEBがこちらで配布されています(0.9.1)。 注： ノードの数についてChef Incに質問してもらったら、RPM, DEBで
Test-KitchenでServerspecやInfratasterをShell-Verifierから実行 - Qiita
サーバのプロビジョニングをテストするTest-Kitchenが、v1.4でテストのステップ(verify)を追加しやすい変更をいれてきました。 そこで一本kitchen-verifier-shellを作りました。(RubyGemは本家に取り込まれるまでの限定公開です。) busserとServerspec、Infrataster 従来のTest-Kitchenのテストはbusserというラッパを使って、テストスイートを対象のプラットホーム(VMなど)にインストールします。 馴染みのある例ではbusser-serverspecなどは、もはや公式のポジションですね。 ただ、テスト対象に直接インストールするというあたりで時間がかかったり、少々トラブルも発生します。 元々、対象の外からつついてテストしようというServerspecや、外からテストしてなんぼというInfratasterは、できるなら
Serverspec用のspec_helperとRakefileのサンプルをひとつ - Qiita
Serverspecで実施するテストを適当に書いていたら、Rakefileとspec_helperが度重なる継ぎ足し建築で大きくなったので晒す。 この記事に出てくるファイルのリポジトリはこちら。 OpsRockin/serverspec_helper_example テスト対象のはなし 相手はだいたいこんな感じ。 ほぼ同じ構成で、staging, productionほか複数の環境がある 環境はプロビジョニングツールの管理下である ツールではミドルウェア構成に対応する形のroleとして定義が作られている 各ホストは大分類名(webとか)がついていて、roleの組み合わせで構築される 構築側のことはあまり気にせず、『仕様を探ってspecだけ書いてちょー』という条件の下でやってます。 Rake & spec_helperで吸収したかったこと 大分類が同じホストが環境別に複数あったり無かったり
Dockerで自分のサイトを手軽にHTTP/2対応にしよっか - Qiita
HTTP/2もほぼ仕様ができました。 代表的なWEBブラウザのうち、Firefox, Google ChromeならHTTP2が利用可能です。 HTTP/2は大雑把にいうとデータの転送周りでいろいろ効率がよくなって嬉しい感じ。 真面目に導入するにはまだ大変だけど、普通のサイトでもとりあえずDockerがあればHTTP/2に対応させて試すことができる。 環境 普通のWeb環境のモデルとして、Amazon EC2上にWordPressをHTTP(TCP/80)のみでホストしてるAMIMOTOさんを使ってみた。 WordPress AMI 網元 AMIからEC2インスタンスを起動すれば、平文のHTTPでWordPressが動いている。 ※ 起動時にセキュリティグループでHTTPS(TCP/443)も許可しておこう。 Dockerで起動するプロセスは、HTTP2で受けてupstream(rever
Test-Kitchenの対応プロビジョナを増やした Itamae, chef-apply - Qiita
Test-Kithenは、 どこかにVMをつくって 好きなプロビジョニングを適用して 適当なテストスイートを実行する というツールです。 あらすじ 普段からTest-Kithenを色々な用途で使っているので、解説をまとめようと思った。 拡張の仕方も説明できるかな ? VMのドライバは作ったことがある： kitchen-zcloudjp テストのプラグインも作ったことがある: busser-shindo プロビジョナは作ったことがない。 ついでだから何かプロビジョナの対応を作る。 『何かプロビジョナ』、すでにTest-Kitchen対応があると思っていたが無かった次の２つにした。 Itamae chef-apply Test-Kitchenのプロビジョナづくり。 Test-Kitchenの拡張は、基本的に対象のBaseを継承してから任意のメソッドを上書きすることで行います。 プロビジョナ実行
Cucumber, ChefSpecとchefでテスト駆動のサーバ構築管理 - Qiita
この記事は最終更新から1年以上経過しています。 気をつけてね。 Chef,Puppetに代表される自動構築・構成管理ツールを使うと開発したサーバを検証用などの目的で簡単に再現可能になります。 ただ、漠然としたサーバ構築をしていると何をサービス提供しているのかという定義が曖昧になるため、Cucumber等を使ったテストを軸にテスト駆動でのサーバ構築をしてみましょう。 応用すれば既存のサーバをCucumberによってモデリングし、Chefによって繰り返し再現可能な状態に持っていけます。 このコンテンツで使ったコードはGithubの https://github.com/higanworks/test_driven_infrastructure_example で公開しています、参考にしてみたりフィードバックしてもらえると助かります。 ツール Cucumber: "ふるまい"を自然言語のように記
Chefのローカルモードチュートリアル + knife-zero + knife-sakura - Qiita
前回 Chefのローカルモードだけでリモートサーバを運用してみようと、Knife-Zeroを作った。Nodeの構成情報もとれるよ。 - Qiita の続きといえば続きです。 Knife-Zeroのページはこちら。 http://knife-zero.github.io/ja/ Chef11.xからローカルモードというのが加わりました。Chef-Client/Server環境の簡易版であり、Soloの代わりでもあります。 Chef-Soloからの乗り換えとしてChef-Zero(ローカルモード)検索が多いようなので、この追記を先頭に移動 このサンプルではSSH越しにローカルモードを実行していますが、単にサーバ側にChef-Repoを置いてローカルモードをしたい場合、 Chefをインストール後にChef-Repoのディレクトリに移動してchef-client -zでOKです。 Soloみたいに
Chefのローカルモードだけでリモートサーバを運用してみようと、Knife-Zeroを作った。Nodeの構成情報もとれるよ。 - Qiita
Chefのローカルモードだけでリモートサーバを運用してみようと、Knife-Zeroを作った。Nodeの構成情報もとれるよ。Rubychefknifeknife-zero Chef(ChefInc)の管理ツールKnifeのプラグインで、Knife-Zeroというのを作りました。 https://github.com/higanworks/knife-zero 追記： バージョンアップして、knife zero chef_client/convergeサブコマンドを追加しました。 追記： ひと通りの機能を実装したので、knife-zeroのことをまとめるドキュメントをゆるやかに作成しています。 https://knife-zero.github.io 端的にいうとAnsibleのやり方をパクりつつ、Chef-Serverから構成管理を含む機能全部を頂戴しながら本体の管理を捨てました。 Kni
ChefでSourceから何かをインストールするCookbookのウォークスルー - Qiita
この記事は最終更新から1年以上経過しています。 気をつけてね。 Chefのレシピでソースから何かをmakeしてinstallをするやり方は、個人によってまちまちかと思います。 私はこんな感じでやっています。 概要 Joyent SmartOSにirdサーバデーモンのngircdをインストールして、サービスとして起動します。 このCookbookはGithubに公開しています。 higanworks-cookbooks/ngircd_smartos(v0.1.1) 追記：続編できました！ [LWRPによる]続・ChefでSourceから何かをインストールするCookbookのウォークスルー レシピのざっくり解説 ローカルに目的のファイルが無かったら取ってくる ファイルを取ってきたらmake & install、ローカルがあれば何もしない サービス登録 サービススタート attributes
OhaiのデータをElasticsearchに入れてKibanaで見る構成管理 - Qiita
この記事は最終更新から1年以上経過しています。 気をつけてね。 Elasticsearch+Kibanaといえば、ログなどの時系列データ(logstash形式)を可視化する利用法が広く知られています。 今回は構成管理の用途にElasticsearchを使うため、ohaiのデータを入れて、Kibanaで検索できるようにしてみます。 何故やるの OhaiはChefがNode情報を収集する時に使用するライブラリですが、個別に利用する事ができます。 通常はChef-Serverに集約しますが、それ以外の環境でOhaiのデータ(Json)を使い捨てするのは勿体無いかもしれない。 Jsonをそのまま投げて良いElasticsearchに突っ込んでみたらどうなるか。 OhaiからElasticsearchに投げる時の方針 手っ取り早さを優先で、次の方針でElasticsearchにドキュメントを登録しま
serverspecとCapybaraを一緒に使う - Qiita
この記事は最終更新から1年以上経過しています。 気をつけてね。 serverspecで状態をテストした後、Webのアプリなら振る舞いもテストしようと思いました。 で、serverspecがRSpecならば、Capybaraも混ぜたらいいんじゃね？ と試してみた。 コード spec_helperはこんな感じで。 アプリのコードを読むわけではないので、webkitドライバでリモート扱いとしてテストすることにしました。 require 'serverspec' require 'capybara/rspec' require 'capybara-webkit' include SpecInfra::Helper::Exec include SpecInfra::Helper::DetectOS RSpec.configure do |c| if ENV['ASK_SUDO_PASSWORD']
specinfraを使ってみよう - Qiita
specinfraは汎用コマンド実行フレームワーク。RubyGemsとしてで配布されています。 追記：これは１の頃の話なので全体的に古いです。 この書籍が一番詳しい。 => O'Reilly Japan - Serverspec ソースはこちら https://github.com/serverspec/specinfra specinfraが目指す所は、情報処理学会研究報告の serverspec: 宣言的記述でサーバの状態をテスト可能な 汎用性の高いテストフレームワーク という論文を見ると良いでしょう。 論文もソースコードと同様にGithubに公開されています。 https://github.com/mizzy/serverspec-thesis 概要 同じメソッドで任意のOS用のコマンド実行文字列を取得したり実行して結果をとったりします。 さわった感じこんな挙動 バックエンドの形式を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Chefのレシピでsed的な事を実施 - Qiita