タグ

2013年12月24日のブックマーク (13件)

  • Omnibus-rubyプロジェクトでツールの周辺依存をまるごとrpm,debに固める - Qiita

    この記事は最終更新から1年以上経過しています。 気をつけてね。 ChefのOpscodeが公開しているomnibus-rubyというのがあります。omnibus-chef(/opt/chef`にRubyごとChefをインストール)のなんでも版ですね。 libやincludeもまるごと、lddで拾える依存も全部パッケージにするので、実際Ruby関連に限らず使えると思います。 ビルド環境については刷新したのでこちらをどうぞ。 Omnibus[-ruby]プロジェクトのビルド環境をDockerで。Dockerhub公開中。 omnibusの準備 まずツール群を揃えます。

    Omnibus-rubyプロジェクトでツールの周辺依存をまるごとrpm,debに固める - Qiita
  • serverspec インフラ層のテスト項目を考える | Ore no homepage

    最近は担当システムが平和だけど俺が平和じゃない。疲れてる。忘年会の連チャンもきっついトシになっちまった。会社の制度で1週間くらい休みがとれるので、一人で温泉とスノボと開発合宿でもしに北海道にでも行こうかなって思ってる。1月か2月くらいに。 えーと、担当しているサービスにserverspecを導入した。それにあたってテスト項目を考えたので軽くまとめる。もちろんserverspec導入前もサーバ構築後は動作確認というか、テストらしいことはしていたっちゃしていたんだけど、テスト項目をまともに考えたのはこれが初めてかもしれない。serverspecのバージョンは0.13.2である。Rubyは2.0.0。 0. 環境 下記のような環境に導入した。ありふれた構成だと思う。60台くらいの規模。DBはマスタ3台に分割されていて、それぞれにスレーブがn台ぶらさがっている。LBの箱は二つあるが、物理的には1台

  • 第1回 テスト“だけ”を使ってコードを再現するのは難しい? | gihyo.jp

    プロローグ 読者の方で、次のように思っていらっしゃる方は、どれくらいいるでしょうか。 「いちばん重要な財産はコードであり、万一コードを失ってしまったら、元と同じ品質のコードをもう一度書くのはとても大変だ」 筆者も長年このように思っていました。では、もし以下のように考えたらどうでしょう。 「いちばん重要な財産はテストであり、万一コードをすべて失ってしまったとしても、テストが無事なら元と同じ品質のコードをもう一度書くことができる」 今までとずいぶん違う考え方ですね。いろんな声が聞こえてきそうです。 「コメントはどうするんだ」 「テストが複雑すぎて保守できなくなったらどうするんだ」 ごもっともです。テスト駆動開発は万能ではありません。うまく適用できない場面もあり、このときは従来どおりのやり方が必要です。たとえば、デバイス制御(あるタイミングでI/Oポートを叩くとか)などは、保守可能なテストを書く

    第1回 テスト“だけ”を使ってコードを再現するのは難しい? | gihyo.jp
    okinaka
    okinaka 2013/12/24
    これはひどい・・・。
  • 本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog;

    最近Dockerとか、serfとかその辺りのツールが流行ってる。その中でとりあえずDockerはテスト環境やCIでは使えるかもしれないけど、実際にwebサービスが動いているものに使えるかどうかはまだわかんないねーという流れになっていた。 まあでもとりあえず動いているwebサービスDockerでやったらどうなるかというのを知りたいというのがあって、いろいろ機会があったので4人で3日くらいやってプロトタイプ実装というのをしてみて試した。 結局出来たこと 結局以下の様なものが実際に動くところまで行った。 AWSのような環境がなくてもDockerさえ動けばブルーグリーンデプロイ出来る VPSだろうが自宅サーバだろうがなんでも ボタンだけで「番用環境構築」「番前の確認」「番切替」が出来る web n台くらいを一セットとみなした環境をボタンひとつで簡単に作れる Docker imageのビルド

    本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog;
  • 開発合宿でDockerとMesosを使っていい感じにリソース提供とデプロイするやつを作ってた - wtatsuruの技術方面のブログ

    3日間の開発合宿で、Docker と Mesos を使ってリソース管理からテスト・デプロイ管理までするやつのプロトタイプを作ってた。 4人チームで3日間みっちりやって、それなりにいい感じにはできたと思う。id:shiba_yu36 が既に書いてるけど、自分の視点から感想だけ書いておく。 番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog; 経緯 最近忙しくてあまり触れてない、Immutable Infrastracture みたいなのを作ってみたかった。 Docker を開発に使うのはいい感じだけど、実際の運用に組み込むには、というイメージをつかみたかった。 というのをラーメン屋で話してたら4人集まったので風呂敷を広げてみた。 どんなものを作ったか アプリケーションは Docker コンテナとして動かす。 Debia

    開発合宿でDockerとMesosを使っていい感じにリソース提供とデプロイするやつを作ってた - wtatsuruの技術方面のブログ
  • 監視ソフトをNagiosからSensuに切り替えて2ヶ月経ったのでまとめた - Glide Note

    新規サービス用の監視をNagiosからsensuに切り替えて2ヶ月経ったので、 導入時の調査で社内で公開してたissueと、投入して2ヶ月間運用した記録を公開しておこうと思う。 というか以前Sensuの事を書くと公言していたのに、すっかりサボっていて 昨日@ma0eさんのブログを見て下記のやり取りを思い出して急いで書いた… @ma0e We started using it. @glidenote will report the detail soon, I think. — kentaro (@kentaro) 2013, 10月 30 @kentaro @glidenote that would be nice — Mitsutoshi Aoe/maoe (@ma0e) 2013, 10月 30 導入環境はCentOS 6.4で、利用しているsensuのバージョンは0.12.1-1にな

  • https://qiita.com/geta6/items/199faca823e84026c10a

    okinaka
    okinaka 2013/12/24
  • Chef Solo の Environments - naoyaのはてなダイアリー

    今年3月に入門Chef Soloを書いた時点では、Chef Solo は Environments の機能をサポートしてなかったため解説は省略しました。 その後、Chef はバージョン 11.6.0 (現在は 11.8.2) で Chef Solo での Environments をサポートし、入門Chef Solo で推薦している knife-solo も 10月末にリリースされた 0.4.0 から Environments をサポートしました。というわけで、現状 Chef と knife-solo が最新版であれば Environments を利用することができます。 たまたま今手をつけている仕事で Environments のことを調べたので備忘録的に記しておきます。 Environments とは Chef の Environments は、例えば development や pr

    Chef Solo の Environments - naoyaのはてなダイアリー
    okinaka
    okinaka 2013/12/24
  • 『CasperJSでカスタムのアサーションを作る』

    このアメブロはFrontrend Advent Calendar 2013 24 日目の記事です。 F.Y.I. 今日はクリスマス・イブだよ。 CasperJSでカスタムのassertionを作る 独自のアサーションをCasperJSで使いたい。 色々調べてみては見るものの、これといった参考になるようなものがなかったので、いい機会なのでちょっと試しにやってみる。 今回やりたいことはすごく単純で、自前のAssertionクラスを作って、テスト時に読み込んで使いたいだけ。 なるべくCasperJSのTesterモジュールが最初から持っている機能に乗っかる感じにして、判定部分だけを自由に拡張できればなよいなという感じで作ってみた。 CasperJSの拡張方法は 公式ドキュメント http://docs.casperjs.org/en/latest/writing_modules.html ここら

    『CasperJSでカスタムのアサーションを作る』
  • 入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineering

    はじめに この記事はGREE Advent Calendar 2013年の21日目です。お楽しみください! こんにちは、アゴひげがダンディーだと評判の九岡です。GREEでは、JavaScalaを布教するための土台を固めるため、デプロイや監視の仕組みづくりなどを横断的にやっています。今回はその過程で得られた知識を「Capistrano 3の入門記事」という形で共有させていただきます。 この記事ではCapistrano 3の基礎をご紹介します。Capistrano 3はRubyをベースにしたサーバ操作およびデプロイの自動化ツールです。Capistrano 3を利用することで、デプロイなどの複雑なサーバ操作を自動化することができます。ここの記事では、特にデプロイに焦点をあてながら、Capistranoでサーバ操作を自動化する考え方と実現方法をご説明していきます。 Capistrano 3の習得

    入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineering
  • HHVM(HipHopVM)のFastCGIを軽く試す - uzullaがブログ

    記事は、12/21に開催されたHachioji.pm #36でおこなったLTの焼き直しです。 DISCLAIMER 記事のベンチマークは非常に適当です。 出てきた数字をみるかぎり、私感として極端にメチャクチャということはないとおもいますが、この数字を一人歩きさせないようにしましょう。っつーか簡単だし是非御自身でベンチしてみましょう!! HHVMとは PHPerの皆様ならHipHopはご存じでしょう、PHPC++に変換することで処理速度を上げる物です。しかし、一度コンパイルするのでヒジョーーに面倒な物になっていした。 HHVMはC++コード(やバイナリ)に変換することなく、PHPのコードをJITで最適化しつつ、動作させるもので、先日家(C++変換版)の速度を抜いたというのが記憶に新しい所です。 http://www.hhvm.com/blog/2027/faster-and-chea

    HHVM(HipHopVM)のFastCGIを軽く試す - uzullaがブログ
    okinaka
    okinaka 2013/12/24
  • Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)

    『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist

  • グリーのインフラに Chef を導入した話 | GREE Engineering

    類似のソフトウェアとして、Puppet や Ansible といったものもあります。こういったインフラ自動化まわりのソフトウェアについてはペパボの宮下さんの インフラ系技術の流れ が参考になります。 Chef in グリー さて、グリーでのChefまわりの構成をご紹介します。下図が全体の構成です。 開発環境 開発は各個人のマシン上で仮想マシンを立ち上げて行なっています。クックブックの開発では、クックブックを開発する人が serverspec でテストを書くようにしていて、構築後のサーバが期待通り動くことをテストしています。一つのクックブックでも設定値などの条件によって動作が変わってくるため、test-kitchen を用いて複数の条件(ランリストやノードのアトリビュート(以下、「アトリビュート」)などの組み合わせ)でテストを行っています。 また、一部仮想マシンを使う必要がないテスト(att

    グリーのインフラに Chef を導入した話 | GREE Engineering
    okinaka
    okinaka 2013/12/24