Sawanoboly.net on Sawanoboly.net

DiscordとAudio Hijackでたぶん快適なPodcast収録

Sat, 11 Nov 2017 22:00:00 +0900

更新不定期で細々とのぼりーさんのクラウドインフラPodcastというのをやっているわけですが、収録の環境をDiscordをベースにリニューアルしてみました。

自分と相手を別のトラックに録音したい

自分のPodcastは収録した音声をそのまま使用することはなく、ある程度編集してから配信しています。

さて、いざ編集となった時に、色々な理由から私とゲストの方の音声は別の音源として扱えると助かります。双方が慣れていればお互いで自分のみをローカルに録音し、それを使用すればよいのですが、基本的に単発出演のゲストさんにあまり手間をかけさせたり、なおかつ録音失敗したりするのはマズイっていうかダメです。

そのため、できるだけ自分の環境側でそれぞれの音声を個別に録音しておきたいところなのですが、これがツール選定の課題になりやすい。

これまでの収録では主にSkypeのプラグイン、Call Recorder for Skype を使用しています。音質は悪くないし設定も簡単なので重宝していましたが、最近Skypeがなんとも不安定(Mac版だけかも)なため、乗り換え先を探してみることに。

で、以前から気になっていたDiscord、ビデオつきでの通話も可能になったことだし使ってみることにしました。

Audio Hijack よい

Discord単体では、プラグインを含めて音声を別々に録音する手段はなさそうです。そこで目をつけたのがAudio Hijack。

Audio Hijack | Rogue Amoeba

macos上のオーディオを良い感じに振り分けたり録音することができます。例えば次のように、複数のソース、複数の保存先を繋げて録音するような使い方です。

セッティングについて補足すると、入力ソースにDiscordが2つあり、それぞれでIn/Outを左右に振り分けるオプションを使っています。

この設定を有効にしたDiscordを入力指定した後、右だけ、左だけを通すチャンネルセレクタをかますことで自分と相手の声を別々に録音するようになっています。ここで相手の声側はスピーカーにも繋がないと、録音はできるけど収録しながら聞くことができないので2つに分けていますね。 (図でもう一つ系統がありますが、比較テスト用なので気にしないで。)

このようなセッティングはテンプレートとして保存でき、使いたいときにすぐ再利用できるのが何より嬉しいですね。

参考: 一応、フリーのツール(※)によるVirtual Input/Outputデバイスを組み合わせて実現はできますが、結構に煩雑なので毎回セットアップするのが大変です。
※) LineInやSoundFlowerなど。

また、Audio HijackはDiscordに限らず汎用的に使えるため、プラグイン形式のように特定のアプリケーションに依存しなくてすみます。有料ではありますが、一度導入しておくと収録に利用するアプリケーションを変更しても勝手が変わらないのでおすすめです。

Discord、もう一つの用途

余談ですが、Discordってそもそもゲームなどの実況向けなわけで。折角なのでイベント中継の裏で雑談するようなサーバを運営してみます。まだちゃんとはオープンしておらず、そのうち告知用の配信をしようと思っていますが、興味ある方はDiscord 招待リンク - nobolycloudサーバから勝手に入って来ていただいてもOKです。

OSSやPodcastのような個人活動ってBitcoinと相性いいんじゃねえかという話

Sun, 27 Nov 2016 17:00:22 +0900

先日、自分のPodcastに応援窓口を作ろうと考えました。少し色々試して、最終的に設置したのはBitcoinのアドレス。

QRコードをすっと読んで、金額を入れてタップ。これだけで、個人宛にコインを送れるってのが小気味よい。実際使ってみると、デジタルおひねりとして、結構優れた体験です。

そんなBitcoinの話。

国境がない感じがよい、しがらみレス

Podcastを応援できる仕組みをなにか作ろうと考えて、Paypalとか、Stripeとかで作ろうかなとちょいちょい見ました。特にStripeは使いやすくて良いですね。PaypalもフォームをPaypal側にもてて嬉しかったりします。

しかし、どうもそこまでキッチリした感じの徴収はやだなあ、というありがちな割り切れなさなんかもあるわけです。更新は計画的ではないし特典をつけるためにカスタマー管理したいというほどでもないし。 Paypalでは日本アカウントで寄付の設置も駄目だったりしますし。(あとちょっと実装いるし)

そこで気になったのが何かと話題のBlockChain、使ったことがないのでBitcoinってどうなんやと。で、実際Walletを作ってみると必要なものはQRコードの画像一枚、身元すらどうでもよい。こりゃあシンプルだ！

そのアドレスに送金するのも、冒頭の記述のようにまた楽なもんだと。

いわゆるお金を取扱うWebサービスを通すと、まあまあ手数料を取ってくるわけです。それが悪いわけではありませんが、『俺はコイツに寄付したいだけなんだよ！』ってときに、そんなに色々と中間ナントカを通さなくてもいいじゃないのという気がしなくもありません。(※そもそも貨幣経済における信用とか、そういう規模の話ではなくて、ごく小規模の範囲で。)

その点でBitcoinは、もはや貝殻を適当に投げているような感覚、とても平坦な印象ですごくしがらみレス？しがらまない。

トランザクションは見えちゃうよ

ちなみに、特定のアドレスにどれだけのコインが送られたかはオープンな情報です。

(この投稿時点で)Podcastのサイトに貼ってあるアドレス 17JHWTuLJHGd3KTR3esm1nzDeNDkCCi7Y7 では、

試しに放り込んだ自分から
たかって払わせた知人から

の2つトランザクションが見えており、総計 0.011935 BTC をせしめているのがわかります。こういう点もなんだか面白い。

まず手持ちのコインを0から0以上にする時点に敷居がある

コインを持つためのWalletはメールアドレスやiOS/Androidのアプリケーションを使うだけで簡単につくることができます。受取用のアドレスもすぐ使えます。

しかし、(誰かに寄付するための)コインの入手には少々難があります。経路は次の2通りでしょう。

持ってる人にもらう
日本円を販売所で購入する

とにかく、コインを持ってる人にもらうのが手っ取り早いです。そうでない場合はちょっと面倒くさいかな。。

とりあえずやってみたい、とかであれば私からBTC送ってもいいですよ。

ツールについて

Bitcoin(というか、BlockChain系)では、コインの所属を示すWalletは一箇所でなく、用途に合わせたり分散目的で複数持つのが普通っぽい。このへんはまあ、現実の通貨と似たようなもんで、タンスと財布と銀行とかそんな関係。

だいたいこんな感じで複数持つようです。自分が今回使い始めたのもあわせて載せておきます。

モバイル端末/ハードウェアのローカル所有
- breadwallet TouchID対応でさくっと送金
受け渡し用のWeb Wallet
- blockchain.info 受取アドレスを用途別につくれて便利
(オプション：他の通貨との両替用)
- bitflyer とりあえずコインを日本円で買いたいときに。今回の動作確認用にいくらか両替しました。

ここらはお好みですが、どれも使いやすいです。送金に手間賃とかが含まれたりする仕組みもあるので、使い倒すならまたいくらか不満もでるのかもしれません。まあそれはおいおい。

その他落ち穂

実際これ、課税されたり確定申告で何かしないとマズイ？などと狸の皮を数えるような考えもでてきます。仮想通貨法次第なんですが、今のところモノあつかいの、当面は譲渡所得でいいようで。。まあ各自でも都度、申告時にご確認で。

あとコイン自体の価値について気になったり円にさっさと変えて使いたい、とか考えるなら普通にPaypalとかStripeを使うとか、Amazonギフトで貰うほうがお勧めです。受け渡しのカジュアルさ加減という点でBitcoinいいかもー、としてるだけなので。

ついでに、フリーランスのIT系エンジニアが電子貨幣をホイホイやりとりする世界を舞台にしたこんな小説もあります。

今回の狼藉はわりとこれの影響ですよ多分。

おわりに

誰かの活動をゆるく応援したいとか、またはその逆で、自分で何かしらオープンに活動しているのでゆるめに寄付を受け付けておきたい(きたら嬉しい)。っていう考えがあったりするんですよ私。皆さんはどうなんだろう。

とりあえずBitcoinで投げとく、程度のやりとりで個人のオープンな活動を支援するような仕組みが流行るといいなと思います。

まあ、寄付窓口をBitcoinのみ対応で設置したときのモチベーションは『ちょっと面白そう』、とか『送れるもんなら送ってみやがれ（ｗ』という平常運転のメンタルによるものです。

AMIMOTO DIE HARD - 死んでも死なないタフさが必要だ。

Mon, 07 Dec 2015 00:00:00 +0900

この記事はAMIMOTO Advent Calendar 2015 、12月7日(月)のエントリです。

あらすじ

AMIMOTO AMIはAWSのPublic AMIとして生まれ、好評を博したのちAWS MarketPlaceに進出したWordPressのAMIである。自前で構築するより大抵楽で、今日ではそこいらのWordPress環境より当然応答が速いチートガイに成長した。

(調べればすぐ判ることなので)詳細は割愛するが、AMIMOTOでは最新のWordPressおよびミドルウェアにいち早く対応するため、AMIには外部処理の取得手続きのみを埋め込み、起動時にWordPressをセットアップしている。

物語はAMIMOTOを起動したユーザの、ある連絡で幕を開ける。

『WordPressが動いていない。』

セットアップを前述のポリシーで行っているAMIMOTOでは、まれに起こるとされる既知の問題としてデジタルキューブ組長も頭を抱える。
原因はたいていAmazon LinuxのRPMリポジトリ更新によるyum updateか、セットアップ手順の変更に起因していた。

少なくともユーザより先に(AMIからみた)外部要因による問題の発生を検知し、いち早く修正を行なえるようにしたいという相談に対して私が提供した仕組みとは．．．？

主要登場物

AMIMOTO AMI: 特徴はあらすじを参照。
シリーズにはVirtualizationのタイプに応じたPVM版とHVM版、およびPHPの実行エンジンにHHVMを採用した(タイプはHVM)の3種類がある。
Test-Kitchen: マシンリソースの調達/破棄を管理し、プロビジョニングとテストを実行するツール。
今作ではCircleCI上で稼働し、AMIからインスタンスの作成およびyum updateを実行、Infratasterの起動を担当した。
Infrataster: インフラの振る舞いをテストするフレームワーク。
得意のCapybaraを使い、WordPressの振る舞いテストを行なう。Javascriptのエラー程度ならば大目に見る(※設定次第)寛大さを持つ。
CircleCI: CI、いわゆるContinuous Integrationのサービス。
Test-Kitchenの実行と、安否のレポートをする。家訓を守り10分間の沈黙は死とみなすが、今作では回避手段をとられてしまう。
heroku: アプリケーション実行のプラットフォーム。
裏設定としてスケジュールタスクが登録されており、CircleCIのビルドを定期的にキックする役で登場。
IFTTT: 条件によってシンプルなタスクを実行するサービス。
セットアップタスクの変更をRSSで取得し、CircleCIのビルドをキックする遊撃手として暗躍する。

『AMIMOTO DIE HARD』解説

結論からいうと、次の条件でテストを回すことにした。対象はAMIMOTOシリーズ全部。

定期的、毎日一回。
- リポジトリの変更によるクラッシュを検知。
セットアップ用コードの変更。
- セットアップの不備を検知。

後者もそもそもが、何かのパッケージ更新との合わせ技による発生が主ではあったようだ。
AMI起動からの大元の仕組みが変わることも考慮にいれて、『ただWordPressがつかえる状態か』のみを確かめる仕組みとしている。

実施している内容は主要登場物のセクションに書いている通りだが、いくつかピックアップして解説しよう。

Infratasterによるテストの内訳とコード

テストの段取りは次の通り。

AMIMOTOのお約束、インスタンスIDの入力において(所有者確認)
1. 間違ったIDを入力してハネられること。
2. 正しいIDを入力し、WordPressのインストール画面に移ること。

とりあえずここまでやれば、関連サービスがすべて正常に稼働しているとわかる。 Infrataster(Capybara)では次のようにコードを書いた。

describe server(:amimoto) do
  describe capybara('http://amimoto') do
    it "Blocks invalid string" do
      visit '/wp-admin/install.php'
      fill_in "instance_id", with: 'hogehoge'
      click_button 'Next Step'
      expect(page).to have_content "Sorry, that isn’t a valid instance ID."
    end

    it "Unlock Success" do
      visit '/wp-admin/install.php'
      fill_in "instance_id", with: ENV['KITCHEN_SERVER_ID']
      expect(click_button 'Next Step').not_to be_nil
    end

    it "Should got 'Welcome' after unlock" do
      visit '/wp-admin/install.php'
      expect(page).to have_content 'ようこそ'
    end
  end
end

インスタンスID(環境変数)は、Test-Kitchenの機能。

Test-Kithcen + Shell-Verifier

AMIMOTO DIE HARDの本体はこのTest-Kitchenといえる。

AMIからインスタンスを作成する。
Shell-Provisionerでyum updateをかけ、関連サービスを再起動。
Shell-VerifierでInfratasterを実行。
テストの結果にかかわらず、インスタンスを破棄。

インスタンス関連の設定はただec2ドライバを使ってるだけ。.kitchen.ymlをそのまま貼ると次の通り。

末尾に突然入っているRubyコードはCircleCI向けの小狡い手段だ。

---
driver:
  name: ec2
  region: ap-northeast-1
  availability_zone: ap-northeast-1c
  subnet_id: <%= ENV['AWS_SUBNET_ID']  %>
  associate_public_ip: true
  instance_type: t2.micro

transport:
  username: ec2-user
  aws_ssh_key_id: <%= ENV['AWS_SSH_KEY_ID']  %>
  ssh_key: <%= ENV['AWS_SSH_KEY_PATH'] %>

provisioner:
  name: shell

platforms:
  - name: hiphop-amimoto
    driver:
      image_id: ami-xxxxxxxx
  - name: pvm-amimoto
    driver:
      image_id: ami-xxxxxxxx
      instance_type: m1.small
  - name: hvm-amimoto
    driver:
      image_id: ami-xxxxxxxx

verifier:
  name: shell
  command: bundle exec rspec -fd

suites:
  - name: default
    run_list:
    attributes:
<%
## Periodic outputs for CircleCI
if ENV['CI']
  ppid = Process.pid
  Process.fork {
    loop {
      puts "."
      begin
        Process.getpgid( ppid )
        sleep 20
      rescue
        exit 0
      end
    }
  }
end
%>

導入当初、PVMのインスタンスタイプにはt1.microを使っていた。
しかしこのインスタンス、WordPressのセットアップ完了直後にyum updateをかけると、わりと高い確率で暫くの間まともに応答しなくなっていた。そのまま10分ほどCircleCIでアウトプット無しの状態が続くと、Failで終わってしまう。

しかたがないので何か出力しておくため、Test-Kitchen実行時にダミー出力を行うプロセスをフォークで作ったのが末尾のRubyコード部分だ。
通常、circle.ymlなどでバックグラウンドプロセスを起動すると、安易な時間切れ対策対策？として出力はミュートされる仕組みになっているが、テスト内でのフォークは流石に捕まらないようだ。

結局t1.microは時間がかかりすぎる事が多かったので、先日smallに変更した。強制終了まで2時間(!)かかることがあったりもしたし。

herokuからCircleCIのビルドをキック

CircleCIは定期実行する仕組みを提供していない(目的外だし)ため、任意のブランチのHEADをビルドするRakeタスクを作成。

require 'circleci'
require 'logger'
@logger = Logger.new($stdout)

CircleCi.configure do |config|
  config.token = ENV['CIRCLECI_TOKEN']
end

task :default do
  begin
    @logger.info "Run nightly integration"
    res = CircleCi::Project.build_branch 'Launch-with-1-Click', 'amimoto_die_hard', 'master'
    @logger.info res.code
    unless res.success
      @logger.error "Maybe fail, it will notifies to some service."
    end
  rescue => e
    @logger.error e.class
    @logger.error e.message
  end
end

あとはこれをherokuにおいて、スケジューラから定期的に実行する。

まとめ

もともとコケるたびにデジタルキューブさん側で対策込みの改善もしていたので、もうこれにほとんど引っかかったりはしません。
ただ、意識外で起こる不思議な障害のなるはや検知には、抜き打ちテストを回しておくのがいいよね。

外部リンク

超高速 WordPress AMI AMIMOTO

Test-KitchenのShell-Verifierがマージされた

Tue, 01 Dec 2015 14:17:10 +0900

これでRubyGemsのkitchen-verifier-shellは御役御免となりそう。

ことの次第などはQiitaに昔書いちゃったのでそっちに。

Test-KitchenでServerspecやInfratasterをShell-Verifierから実行 - Qiita

Test-Kitchenの1.4でVerifierがモジュール形式になり、Busserが唯一の共通処理からいちモジュールに身を落とした時点でこうなるよなーと。

マージには足掛け半年くらいかかったわけだが、前回execコマンドを追加するプルリクエストを送った時もそのくらいかかった。

今回はChef Incの人が来日した際にその場にいた@dai_lxrにPushしてもらったのがよかったのかもしれない。

Q. kitchen-verifier-shellのPRを取り込んで！ https://t.co/IjmguH3YNq A. 取り込まれてよい状態だと思う。私からも言っておくがメンテナに再度pingしてほしい。 #chef_docker #getchef @sawanoboly
— dai / Chef活用ガイド発売中 (@dai_lxr) 2015, 11月 11

英語書くのが面倒だからIssueでの議論をスキップして突然プルリクってのは、タイミングが合わない時にお互い困るのかな。

ブログをhugoにしておく

Sun, 29 Nov 2015 17:20:22 +0900

ひとつ前は、何かしらまともな運営をしているブログサービスの使い勝手がみたかったのという理由でSquarespaceに置いていた。

ひとつ前のブログ

普通にブログするなら多分いいとこだ。

それはそれとして、gfmでそのまま保存できそうなのでhugoに。

以前の記事も今度移しておこう。

WEB+DB PRESS vol.85のAWS自動化特集でOpsWorksの記事を担当しました

Mon, 23 Feb 2015 00:00:00 +0900

雑誌の概要はこちら => WEB+DB PRESS Vol.85｜技術評論社。

写真はオープンセミナー広島2015での発表から

共著のみなさんも既にブログで紹介されています、各章の対象読者や雑誌のオススメ具合はこちらがとても参考になります。

@sgwr_dts(winebarrel) さんの記事 => AWS as Code!: WEB+DB PRESS Vol.85に記事を書きました - so what
@muramasa64 さんの記事 => WEB+DB PRESS vol.85にCloudFormationの記事を書いた - 雑記帳(2015-02-23)
@y15i(y13i) さんの記事 => t.y13i.com — WEB+DB PRESS Vol.85にCloudFormationの記事を書きました

特集を簡単に紹介すると、

導入しやすく、まあまあ普及感のあるCloudFormationの現場ノウハウ
自分の担当したOpsWorksは(多分世間に求められている程度の)Getting Started
既存の環境もコードにするための思想と、それのリファレンス実装ともいえるCodenize.toolsの紹介

という内容です。

詳細はもうタップリ出てますし、実物も本屋にも並んでいます。折角なので少し記事の裏側で個人的に面白かった話などを書きます。

記事の経緯を聞いたよ

できあがりは『AWS特集』でしたが、原案は@gosukenator(mizzy)さんとのこと。

Infrastructure as Code 現状確認会(2014年10月) のあとに、クックパッドの人たちが開発してるIaC(※Infrastructure as Code)なツールで記事書けるんじゃないか、と稲尾さんに企画を持ち込んで、打ち合わせをした結果、AWSにフォーカスした話にしましょう、ということになって、ああいった企画になりました。

談: @gosukenator(mizzy) さん

そのままいけばクックパッドのCodenize.toolsやItamae、Infratasterほかの記事になっていたのかもしれませんね。
(これはこれで読みたい方も多そうだし、雑誌から盛り上げるような方向もあっていいような気はしました。)

Codenize.tools

クックパッドインフラツール達の何が特集企画として持ち込まれるほど面白いのかっていうと。

昨今Infrastructure as Code(以下、IaC)と言いつつも、色々と手を出しているうちにどうもツールに使われているような感覚に陥ることがあります。
便利そうなツールが出揃っているように見えても、自分の抱える問題を本質的に改善するためには、その手のお作法の学習コストや変態的ハック、またはツールの更新にいちいち振り回されるのは割りに合いません。

現在OSSとして公開されている各種ツールも、そもそもは開発者が彼ら自身のフローを自動化するためにはじまったのでしょう。

で、IaCのきっかけとも言えるインフラリソースのAPIに対して自身のフローをもって真正面から向き合っているCodenize.toolsのは根底思想からしてやっぱり面白いと思うわけです。

ちなみにCodenize.toolsという名称は、AWS自動化記事の校正段階である全体タイトル決め(Issue#60)の最中につけられました。
他の章はサービス名なので分かりやすいのですが、『クックパッド独自ツール』では微妙だなーという話になったので、じゃあグループ名をつけたらどうでしょう？と。

例えばCookpad suites(スイーツ)とか、ツールに一連のシリーズ名があるとぐっといい感じですよね。

Github Issue #60 @sawanoboly 発言より

私の提案(名前をつけるという部分で)は24時間以内にCodenize.toolsの公開を持って採用されました。

なまえつけたよ！ http://t.co/BHEJBBMpe9
— auto.conf (@sgwr_dts) 2015, 1月 7

実際私が本特集で一番気に入っているのは4章の『Codenize.toolsによるメンテナンスの自動化』、その中でも「Codenize.toolsのしくみ」で密かに語られるコードを用いて運用するということへのこだわりの部分です。

Githubでの記事執筆

技評さんとのお仕事、ひいては雑誌に記事を書くことは今回がはじめてでした。
噂のとおり編集、執筆者同士のやりとりはほぼすべてがGithubで行われ、やたらと快適でした。これは確立した先人達に感謝。

Githubの記事リポジトリ

私は結構サボるタチなのでリモート向いてないんですが、編集の@inaoさんのGithubまわりのテンションが高く、見ていると『あー、やらなきゃなー』という気分になりました。開始時のWeb会議以降はすべてGithubでのやりとりだったので、リモートでの雰囲気作りは大事だよねと再認識。

今回私がリポジトリのオーナーだったので、実は自分だけSlack連携で流れを追うのに少しばかり楽をしていました。共著の皆さんごめん。

菅原式レビューボード

Githubでの記事執筆に関連して、今回面白かった事件を1つ。

個人の作業としては快適なGithubですが、相互レビューの段階で次の問題がありました。

コミット単位でレビューを付けると全体的に追いづらい
Issueにレビューを書くとしても、どの時点のどの部分を指しているか分かりにくい事がある

このへんは結構共通の認識のようで、Reviewable とかレビューのための外部サービスがあります。

この問題、@sgwr_dts(winebarrel)さんにより次の手法が提案されました。

ブランチを作成
章ごとの原稿(まとまった1ファイル)を消してコミット
2をrevertコミット
Pull Request作成!
各自コメントをrevertコミットに対して付け、それの返信で議論＆対応する。

菅原式レビューボード

プログラムではやってはいけないですが、blameが少々潰れても構わない原稿のレビューにおいてはシンプルで導入しやすく、レビュー対応もほとんど漏れない(幾多のレビューコメントで私が2個ほど漏らしたのみ)という中々素晴らしい手法だと思いました。
レビュー及び対応は、各段階の区切りで次のように見やすくなっています

1つのコミットにある時点の原稿に対するすべてのレビューが集約

手法は名称がつくと流行りやすいこと、個人的に苗字＋技名は浪漫と思っていることから、この手法を私は『菅原式レビューボード』と名づけました。浸透はしませんでした。

おわりに

なんやかんやで、共著の御三方[@sgwr_dts(winebarrel), @muramasa64, @y15i(y13i)]と編集の@inaoさんのおかげで良い感じにまとまりました。
機会があればまた書いてみたいですね。

さて、とりあえず自分の関わった特集の事を書きました。
他にも(いただいた見本誌を読んでいると)『リアクティブプログラミング』、『楽しもうOSS開発』、『Railsらくらくテストデータ準備』、『Consulでクラスタ管理』と読み(試し)応えのある記事が沢山あるので、ぜひご一読を。

オライリー・ジャパンからServerspec

Sun, 11 Jan 2015 00:00:00 +0900

2015年1月17日にオライリー・ジャパンから出版のServerspecが発売されます。

著者のmizzyこと宮下剛輔さんによる紹介記事はこちら。

「Serverspec」という本が出ます - Gosuke Miyashita

『Serverspec』正誤表(公式サイト版)はこちら

Serverspec - 『Serverspec』正誤表

さてこの本、幸いなことに執筆時にレビュワーに誘っていただきました。
レビューでは思想や解説の内容を中心に、言いたいことが伝わるだろうかという見方でIssueを切りました。

微力ながら制作のお手伝いをした書籍をご恵贈いただき、手元に来た現物をみてニヤニヤしています。

Serverspec the definitive guide

※ iPhone5Cは大きさ比較用。

扱いやすいサイズで持ち運びやすいですね。電子版も出るので、そちらは購入する予定です。

では折角なのでおすすめの章を2つ。

使う人向けの3章

簡素な公式ドキュメントの行間を解説してくれる3章は、テストコードをどう書けばよいのかから始まり、コードの使いまわしや環境およびセキュリティ要件へ対応するTipsが書かれています。
また、良くある悩みの『何をどこまでテストすればいいのか？』に対する指標が書いてあります。

Serverspecを使うことに関しては、3章を読めばしばらく困らないでしょう。

3章　Serverspecの本格利用
    3.1 RSpec
    3.2 リソースとリソースタイプ
    3.3 SSH経由でのリモートホストのテスト
    3.4 テスト対象ホストの追加
    3.5 動作のカスタマイズ
    3.6 一時的な動作の変更
    3.7 specファイルを複数のホストで共有
    3.8 ホスト固有情報の利用
    3.9 任意コマンドの実行
    3.10 並列実行
    3.11 様々なバックエンド
    3.12 テストコードの指針
    3.13 本章のまとめ
※ O'Reilly Japan - Serverspec http://www.oreilly.co.jp/books/9784873117096/ より

カスタマイズ・コントリビュートの4章

4章はServerspec, SpecInfraの内部を解説してくれます。
特にSpecInfraは公式なドキュメントと言えるものがありませんが、4章の内容を理解すれば、Github上のコードをそのままドキュメントとして読めば大丈夫なくらいにはなります。もちろんSpecを記述する際にも役立つ知識です。

また、それぞれのカスタマイズや拡張についての丁寧なウォークスルー、さらにはmizzyさんがプルリクをもらうとき(特に個人的に)気になることまで書かれています。

Serverspecを使い倒す、貢献する(オプション)なら4章で手を動かすといいですね。

4章　Serverspec内部の詳細
    4.1 Serverspecのアーキテクチャ
    4.2 Serverspecの処理の流れ
    4.3 コマンドクラス
    4.4 バックエンドクラス
    4.5 Serverspecのリソースタイプ拡張
    4.6 Specinfraの OSに関する処理
    4.7 Pryによる内部解析
    4.8 Serverspec自身のテスト
    4.9 コントリビュートの際の心構え
    4.10 本章のまとめ
※ O'Reilly Japan - Serverspec http://www.oreilly.co.jp/books/9784873117096/ より

その他

Serverspecはmizzyさんの活動テーマの1つ、継続的な改善の副産物だと思います。中でもなぜServerspecが広まったのかは、伊藤直也(naoya)さんのまえがきに推察があります。

本エントリで紹介しなかった章には、mizzyさん曰く『思いを綴ったエッセイ』が多く含まれます。
Serverspecの活用法を把握(おそらく書籍を入手する当初の目的を達成)したら、これらのエッセイを読み返してみることをおすすめします。
この本の読者が触発され、何かしらの常識や慣習を改善する新しいツールを出してくると嬉しい。。？かもしれない。

最後に、mizzyさん無事出版おつかれさまです。

Network

Chef-Solo, Chef-Client LocalMode, Knife-Solo, Knife-Zero and us.

Thu, 25 Dec 2014 00:00:00 +0900

※旧ブログから移植。

Chef-Soloが無くなるので、他の何かに乗り換える必要があるのか。という話に対してKnife-Zeroをダシに何か言っておこう。

最初に言っておくと、今Chef-Solo、Knife-Soloを使っている人、多分何もしなくていい。

登場人物一覧

Chef-Solo
- Chef-Server無しでローカルサーバにChefのレシピを適用する。Chef-Server非互換(11でほぼ改善)。
Chef-Client LocalMode
- Chef-Server無しでローカルサーバにChefのレシピを適用する。Chef-Server互換。
Knife-Solo
- レシピ一式を転送し、Chef-Soloをリモートサーバに適用する。
- (追記)全体のワークフローは、VagrantのProvisionerに近い。
Knife-Zero
- レシピ一式を転送せず、SSH越しにChef-Client LocalModeを実行する。
- (追記)従来のClient／Serverワークフローを踏襲。

全てのChef-Solo関連がにChef-Zero(Chef-Client LocalMode)に変更されるというのは飛躍的な判断

なんとなく騒がれているのは、これの元記事からなのかしら。

[和訳] ソロからゼロへ: Chef Clientローカルモードへの移行 #opschefja #getchefja « CREATIONLINE, INC.

基本的にこれはサーバのローカルで実行する場合についての話でしょう、まあそれならChef-Client LocalModeに変えるのはほとんど何も変更はいらないのでよくわかります。

参考： Chef-RFC031 『This means that chef-solo using “local mode” must be 100% backwards-compatible with existing chef-solo usage.』

で、リモートでやるKnife-Soloについて考えた時に、”Chef-Solo無くなる”＝”Knife-Solo使えなくなる”でもないわけです。 Knife-Soloは単なる非公式のプラグインであって、公式がこういう記事でいちいち言及しないでしょうね。

少なくともKnife-SoloはChef-Soloと心中なんてしないだろう

日本でKnife-Soloがそこそこ広い認知度を持っているのは、伊藤直也さんの入門Chef Solo - Infrastructure as Codeによるところが大きいでしょう。多分そう、部分的にそう。

この本で覚えたフローや使い方が今後できなくなるかって言うと多分そんなことはなくて。 Knife-Solo開発陣はChefの動向をちゃんと追っています。

add local_mode to solo.rb · Issue #353 · matschaffer/knife-solo

(関連ディレクトリをまるまる転送、リモートでLocalMode相当の実行形式に変更など)

ということでKnife-Soloでやっているものは、基本的にそのまま使い続けることもできそうだと思ってます。実際Chef-Soloって無くなるのかも不明、もしかしたらChef14とか15になれば居なくなるのかもしれませんね。

Knife-ZeroはミニマムなChef-Server環境とのアップ/ダウングレード移行パス

じゃあKnife-Zeroはどういう位置かというと、Chef-Server環境との相互移行がやりやすいChefの導入方法(の一つ)です。 SSH越しにリモートで実行されるChef-ClientはLocalModeではなく、通常のClientモードとしてChef-Server(SSH元のChef-Zero)に対して接続します。

なのでKnife-Solo(そもそも私は使ってない)の代わりではなく、既存のChef-Serverを畳む用途で作りました。

Knife-Zeroではじめて、Node数が増えてきたらChef-Serverへ
Node数が少ないChef-ServerをたたんでKnife-Zeroへ

Knife-Zeroは、概ねお一人様用Chef-Serverという感じです。node情報ををgit管理できたり、エディタで手元からしれっとattributeを追加できたりという利点とかありますが。大人数で保守する場合や、継続的にChef-Clientを実行したい場合、Nodeがとても多い場合は多分Chef-Serverのほうがよいのかと思います。

Knife-Zero豆知識

Chef-Zeroは2,000nodeくらいまでなら性能的に問題ない。 (Chef-Zeroのキャパシティが気になったのでRubyでベンチマークをとった - Qiita)
Knife-Zero制作のきっかけはlightchef(現itamae(github link))
- Severspec的発想がいいと思った。
- しかし同時に、『インベントリも収集せずに(light)Chefとはどういう了見か』と思った。
Facebookの中の人も、SSH越しのLocalMode(Chef-Zero)を使っている。
- 手抜きのために考える事は同じだなと思いました。
- SSL support · Issue #86 · opscode/chef-zero
最初は本家へのPull Requestとして作成していた
- とても煩雑なコードになって、説明するのが面倒に。
- とりあえずリリースを優先、楽なKnifeのプラグインとして作成。
- 本家にマージしたい。(最近はそうでもない。)
- Chef本体からあまりコードの量的に離れたくない。
リリース当初の私が書いたコードはほとんど残っていない。
- @yasushia氏によってリファクタリングが行われ、とてもスッキリしたのでv1.0.0を付けた。
(Fixed) Chef12のRC版ではローカルモードが盛大にクラッシュする。
- The localmode doesn’t create node object correctly on chef 12. · Issue #2433 · opscode/chef
- Knife-Zeroは自分では便利なので12対応はしておきたいんだけど。
- 羅列したこの記事のタイトルで、一番寿命が先に来るのは、もしかしてKnife-Zeroかもしれないよ。
- (New) 治した！ use Chef::JSONCompat.parse for filecontents #2433 by sawanoboly · Pull Request #2482 · opscode/chef

つらつらと書きましたが、Knife-Zeroは色々と楽をできるように作ったので、新規のシステムをChefで作り始めるとか、既存のシステムにChefを導入するとかならKnife-Zeroをおすすめします。

『Chef活用ガイドコードではじめる構成管理』を書きました

Sat, 19 Apr 2014 00:00:00 +0900

※旧ブログから移植。

米Chef社(http://www.getchef.com/)が開発しているChefというソフトウェアの本を、クリエーションライン株式会社の樋口さんと共著しました。アスキー・メディアワークスさんから出版されてます。

発売を前に手元に２冊届きました、少々ボリュームのあるサイズ(672P)となっています。

Chef活用ガイド

何を書いたのか

導入はInfrastructure as Codeという概念について述べています。その後はInfrastructure as Codeの１要素としてChefを利用することへの助けとなるべく、Chefの全要素を出来る限り詳しく解説しています。

Chefの解説については書き下ろしと、公式ドキュメントにある要素をいくらか組み直して、細かい解説などを入れながら再構成して章立てした内容になっています。書き下ろし部分の内容を考えるために最も参考にしたのはChef-Clientのソースコードでした。

最後に付録として、執筆当時に公式のリファレンスに存在したCookbook(Resources)やLWRPの和訳などをつけています。付録のうち和訳部分に関しては、重複するサンプルを抽出して読みやすさを調整したり、コードに間違いがある部分などを本家にフィードバックしながら修正したりといった手を加えています。

本編４５０P、付録が２００P強という内訳です。

誰に向けて書いたのか

導入部分はどちらかというとChefの採用を検討するマネジメント層や、極端なところでITサービスプロバイダの経営層に向けて書いています。 Infrastructure as Codeという概念を引き合いに、最近サービスを支えるインフラに対して提言されているのはこのようなことですよと紹介し、コストやリスクを減らしていきましょうという呼びかけをしています。

導入部以降はいわゆる現場向けといえそうです。Chefを内部の構造からまあまあ詳細に解説しているので、実際にChefを触ってみたい・触っている・もっと使いこなしたいという方々や、Chefの挙動に興味や疑問を持つ方々に是非読んでいただきたいと思っています。

書かれていないこと

そもそもChefだけでインフラの管理がよくなるという事は決してありませんし、この本でも出だしにそう断りを入れています。コンピュータシステムのライフサイクル管理を効率良く行なうには、用途および組織にあったツールチェーンを確立するのが望ましいことは重々承知ですが、Chefから少し離れる要素や、他のツールからワークフローの一部として使われるChefについては、この本ではほぼ解説していません。

そして、この本はあくまでガイドという位置づけであり、導入の検討や適用範囲はあくまで組織でのプランやコストを考慮して各自が行わなければなりません。もちろん事例やサンプルもそれなりに書いており、参考にすることもできますが、どこでも通用するベスト・プラクティスというわけでもありません。 (観光ガイドブックであれば、名所の場所は書かれていても、観光レポートは無いでしょう？)

ただ、テーマをChefだけに絞ったこともあり、現状で書籍という形に限れば世界中で比べても一番Chefについて詳しく書かれた本(あとOhaiも)になっていると思います。検討の材料、導入後のリファレンスとしても十分役に立つでしょう。

なぜ書いたのか

至る経緯は諸所ありますが、お話をいただいたからです。

その時点でそこそこChefを使ったり、他所に導入したりを始めていたので次のような理由で受けました。

自分がChefを忘れても大丈夫なように、本にまとめておけるならラッキー
人に説明するときにラク
人からの質問がいくらか具体的になる

どのように書いていたのか

動いていたのは2013年7月〜2014年4月、そのうち9月後半〜１月にほとんどの内容が書かれました。書き始める前はソースコードや関連資料の調査、１月後半からは校正につぐ校正。

原稿の管理と、共同執筆中のコミュニケーションではこれらが役に立ちました。

github(git)
Skype

内容はGithubのリポジトリを更新して共有し、やや大きめなテーマはIssueとして管理、ちょっとした方針や文章のすり合わせはSkypeでと、快適な執筆環境を目指してツールを活用することにしました。(Skypeではくだらない雑談も相当交わされましたが)

共著の樋口さんとは、本について７月(第１回 Chef Casual Talks Kansaiの翌日)に分担を決めた後は、一度も顔を合わせることなくすべての作業を終えることが出来ました。

私の側では、主にこれらのツールで原稿を作成しました。

エディタ(vim, bbedit)
プレビュー(Mou, Marked, git(差分))
Chefのソースビュアー(vim, git(差分および履歴))

プレビューツールからわかると思いますが、生原稿はMarkdownでした。原稿書きには、gitのログと差分確認がかなり役立ちます。

校正段階では主にこれらのツールで原稿の修正にあたりました。

Mail & unzip, mi(旧ミミカキエディット)
github(git)

初稿より後は、MarkdownではなくEWBで(変換された)となったんですが、文字コードがEUC-JPでbbeditがイマイチ自動判別しなかったので、国産エディタのmiに頼りました。

ここでもやっぱりGithubが活躍します。章ごとのブランチを作成して、平行して校正を進めたり、適用漏れを抽出して追跡したり、 gitリポジトリは軽作業などもふくめて、結局2200コミットくらいになりました。

環境用品のうち、特に活躍した3つをピックアップします。

MacBook Pro Retina13
- QuickResで、画面をかなり広くして使用、参考資料を見ながらの執筆に
Contessa (岡村製作所)
- 作業に集中するのに調度良かった
- 腰痛が全然気にならなくなった
SHOT NOTE(KING JIM)
- 構成図等の提出はこれに手書きして取り込んだ

最後に

本書を書くのは中々骨の折れる作業でしたが、周囲の協力者や家族の理解もあって、ようやく書店に置かれる所までこぎつけました。あとは料理本のコーナーに並ばないことだけを祈っておきます。

追記、『Chef活用ガイド』読者アンケートを作成しました。

この本を読んでいただいた方(購入・回し読み問わず)を対象に、アンケートを作成しました。

書籍『Chef活用ガイド』読者アンケート Survey

では締めをChef活用ガイドコードではじめる構成管理 - vdrめも(2014-04-21)から引用で。

世に出るのはもう少し先で、その上読み終えるにはかなりの時間がかかるかと思いますが、よろしければご回答いただければ幸いです。

JAWS DAYS 2014のImmutable Infrastructure(II)トラックで話した

Mon, 17 Mar 2014 00:00:00 +0900

JAWS DAYS 2014セッションで話しました。

Infrastructure as Codeと組織のドキュメンテーション＋ Immutable Infrastructure事例

スライドはこちら。

Infrastructure as Codeと組織のドキュメンテーション＋ Immutable Infrastructure事例 from Yukihiko SAWANOBORI

現場にいらっしゃった方の反応などもTogetterにまとめて頂いています。 2014/03/15 JAWS DAYS 2014 - Immutable Infrastructureトラック #jawsdays #infra - Togetterまとめ

『Immutable Infrastructure』事例について

大阪某所でやっているGiraffiから事例を紹介しました。

FBページ:Giraffi DevOps

当時はImmutable Infrastructureなんて’名前’は全く意識していません。構成を検討する際ベースにしたのは、従来のサービス死活監視に対する不満でした。

サービス継続性とサーバ単体の死活が直結しないよう抽象化し、アラートの粒度や優先度を分類して、即時対応しなければいけないケースを減らそうという目的で構成をDeveloperと一緒に検討したんですよね。

その結果、従来のSPOFはDisposable Componentsになり、運用の方法としてImmutableも選択できる構成となった事例です。

パネルセッションでは言いそびれましたが、どの層が『Immutable Infrastructure』するべきか、また恩恵をうけるかというところでは、『夜中にアラートで起こされる人』こそが。じゃんじゃんやるべきなのかもしれませんね。

『Infrastructure as Codeと組織のドキュメンテーション』について

『Immutable Infrastructure』トラックでなんか話せと言われてから、普通に説明したって全員被るに決まってるがなと思いました。それならば、説明は他のセッションにまかせて、前提知識である『Infrastructure as Code』の導入支援をつくろうとしたらこうなりました。

この話はもともと、『手順書は芸術品ではないか？』という発想から始まっています。

で、その会話とクヌース先生の文芸的プログラミングあたりの概念を結びつけた@azukiwasher氏によって書き起こされたのが『ドキュメント礼賛(原題：手順書礼賛)』です。

gist:8571505

ドキュメント礼賛

断言しよう。ドキュメントこそがマシンを隷属化し、人間のために使役させるための最善の方策である。
なぜなら、マシンをコントロールする「ドキュメント」を理解できるのは人間だけであり、マシンは決してそれを理解することはできないからだ。

ドキュメントは、マシンにとって高級すぎる別世界の読解不可能な暗号だ。読解不可能という点が人間にとって甚だ都合がいい。人間の企みがマシンに理解されてはおしまいなのだから。
企みは、マシンから秘匿され秘密裏のうちに人間の「手」によって着実に行使されねばならない。

一方、ドキュメントは人間によって書かれ、それを「玩味」できるのも人間だけである。人間だけがドキュメントの行間を読み、レトリックを味わい、隠された意味を発見できる。
「作者」の意図を自らに与えられた使命に、いま誇らしげにキーボードを叩きはじめる・・・。そしてすべての手順が終わったとき、彼は作者との一体感を感じ、ドキュメントをシェアしあう、親密なコミュニティ、やさしい仲間たちに迎え入れられる。

ここに強い人間たちの結束が生まれ、ついにはマシンをコントロールし人間のために永遠に労働しつづける奴隷たらしめることに成功する。

繰り返す。ドキュメントこそがマシンを隷属化し、人間のために使役させるための最善の方策である。

決してその逆ではない。

『手順書は芸術品ではないか？』 => 『洗練される』 => 『実行可能な機能美』 => 『Chefのレシピなどに行き着く』 => 『真の手順書とは(いわゆる)コードなのだ』

この文書が面白かったので、人類向けのセッションに起こしてみました。

最近ちょいちょい『ChefおよびInfrastructure as Code』について話を聞きたいという声をかけて頂いて幾つか訪問したり、実際にトレーニングをさせて頂いてますが、やはりみなさん難しく考え過ぎだったり、新しいことへの抵抗勢力があったりと結構モヤモヤするんですよ。

イベント会場にいらっしゃる方々は、『Infrastructure as Code』の何がよいかなんて十分ご存知でしょうが、さて自社に持ち込んで〜となるとやはり困る。それをどのように説得するかの一例として考えたメソッドとしても使えるとよいなと考えて、かなり回りくどく色々と言ってみましたがどうだったでしょうか。

発表後の質問でもでましたが、あらためてアプローチの例を並べてみました。

権威を呼んでくる
対象層向けの本を出す
自分が出世する
実際にやって見せる

個人的なおすすめは、『実際にやって見せる』ですね。

例えば社内でのクラブ活動をしてみる。結局、業務内で何とかしようとするのは中々難しいです。だったら自腹でクラウド使ったり、内輪のシステムを作って研究発表なんかするのが遠回りのようで一番効果的のように思います。

パネルセッション

お会いしたかった方々と、まとめて会えるという個人的に嬉しい企画でした。このトラックに放り込んでくれた@urasokoさん、そのあと取りまとめいただいた@stanakaさんほかスタッフの方に感謝！

パネルセッションのまとめはこちらに => JAWS DAYS 2014 Immutable Infrastructure パネルディスカッション - stanaka’s blog

時間の都合で普通に喋れなかったのがはちと残念ですが、この日は@mizzyさんとたっぷり密談したので、今後はその成果を出していきたいですね。

Chef-Server環境で使うCookbookをVagrantとChef-zeroで開発する

Wed, 05 Mar 2014 00:00:00 +0900

最近はChef-Severの導入も簡単になりました。パッケージから導入はもちろん、aws marketplaceからすぐ使用できたりと。

とはいえテスト環境にChef-Serverを強いるのも大変なので、Chef-Zeroで代わりをしてもよいでしょう。

Chef-zero

https://github.com/chef/chef-zero

Chef-zeroはChef-Serverのホットモックのようなものです。ほぼChef-Serverとして動作する小さなプロセスですが次の特徴があります。

認証はするフリで全部OK
データはメモリに保存、永続化なし

Chef-Serverを使ったCookbookの開発をする際に、データをクリアしたい場合もありますが意外と後処理が面倒です。 Chef-zeroならプロセスのリスタートで綺麗な状態になるので、knifeで必要な要素を戻すだけで再度テストを行なうことができます。

詳細は次のリンクが参考になります。

軽量簡易Chef Server「chef-zero」を使ってみよう #opschef_ja « CREATIONLINE, INC.

VagrantでChef-zero

ではChef-zeroのプロセスをどこに立てるか。test-kitchenではCookbookをテストするVMで直接Chef-zeroを起動して、ダミーのChef要素を入れることができますが、現時点ではそのままシームレスにChef-Server環境に持って行こうとするにはいまいち感があります。

じゃあVagrantだろうなということで、一式書いてリポジトリに登録しました。

https://github.com/OpsRockin/vagrantwithchefzero_example

Vagrant with Chef-Zero

これならvagrant up chefzeroするだけでChef-zeroをほぼChef-Serverとして使い放題です。

chefzeroのVMだけはChef-Soloで構築しますが、ほかのVMはChef-zeroに対するChef-ClientとしてProvisioningすることができます。

最初は手元だけ直して、Cookbookのアップロードを忘れることもありますが、すぐ慣れるでしょう。

通常操作はknifeを使えるので、他の環境に持っていく際にknife.rb指定の切り替えで済むのが助かりますね。

開発作業用のRakefile

レシピ開発＆テストを効率よく行なうには、とりあえずRakeのタスクを作っておくとよいです。

task :default => 'upload'
$stdin.sync = true

desc 'upload chef-repos to chefzero vm'
task :upload do
  system('knife cookbook upload --all')
  system('knife upload environments/ ')
  system('knife upload roles/ ')
end

desc 'reset chefzero'
task :reset do
  system('vagrant reload chefzero')
  Rake::Task['chefzero:upload'].invoke
end

それぞれこんな作業をやらせています。

rake upload # Chef要素のアップロード
rake reset  # Chef-zero内容クリア＆要素の再アップロード

その他

ちなみにvagrant-chefzeroというプラグインもあり、これはEnvやRole要素の投入までVagrantファイル内でやるようです。

knifeを使わないのが逆に気になるので今回はCookbookでChef-zeroをセットアップしてます。

第一回XEggで『さくらのクラウドフォーメーション with Chef 』

Sun, 16 Feb 2014 00:00:00 +0900

2月15日に大阪のグランフロントで開催された、Innovation EGG 第二回 XEgg 1st『クラウド未経験者向けITコミュニティ＆クラウドベンダー合同勉強会』で行ったセッションの話。

Innovation EGGとは？

イベントのテーマと課題

今回声がかかったのはXEgg(クロスエッグ)と題されたイベントで、テーマによって選出されたベンダにITコミュニティを組み合わせてなんかやってくれと言う話だった。

第一回XEggのテーマはクラウド、私はChef meetup Kansaiの主催者としてITコミュニティ枠で参加。さわる対象のクラウドベンダは『さくらインターネット』、要は『さくらのクラウド』を触りましょうと。

さくらのクラウドフォーメーション with Chef [XEgg session] from Yukihiko SAWANOBORI

セッション裏話

セッションの大筋はスライドの通りで、話した内容はその場で聞いていただいた方々がご存知です。ブログではどうしてあんなセッションになったのか振り返ってみます。

ターゲットの決定

イベントの参加対象者は、『クラウド未経験者』とのことでした。ずいぶんもやっとしています。

セッションの内容をChef初心者向けに丁寧に解説とすることも考えましたが、テーマからいって参加者がChefに興味あるとも限らないうえ、同時に動いていたプロジェクトのこともあわせて、そういうのは私が飽きていました。

そもそも私はChefを売ってるわけでもないし、イベントの主軸はクラウドベンダだし、どうせなら自分が興味あることをセッションにしてしまうほうが楽しい。

ということでセッションのターゲットはクラウドベンダの『さくらインターネットのスタッフ』と、同枠の『MongoDBコミュニティ』に絞りました。

Chefの紹介

Chefはその特性上適用できる範囲がとても広く、組織によって様々に使い方を選べます。そもそもChefには決まった使い方も無く、あるのは各組織のワークフローやポリシーに合わせてシステムの構成管理をできる柔軟性くらいです。

説明したってきりがないので、旧態依然とした構成管理への皮肉を交えつつ、最初から視聴者全員置いてきぼりを目標にさっと流しました。

イベントテーマ的に主役では無いですし。

使ってみました系と海外との比較

このへんは裏表あまりなく、結構思うまま言ったらこうなった。

sawanoboly氏、さくらの田中さんの前でさくらのクラウドAPIのdisを繰り広げている。でもこういうのは参考意見として良いよね。 #xegg
— MATSUMOTO, Ryosuke (@matsumotory) 2014, 2月 15

コンピュータリソースに特化したサービスと比べるのは少々ごまかしを含みますが、ややインパクトを重視してChefと手っ取り早く連携させたりとりあえずサービスをリリースしようといった視点からあえて見た体で展開することにしました。

実際、『ボクのデータセンター』を作りたい方には非常にいいと思います。

ここの中で『ホビー対傭兵』という比喩が出てきますが、この表現にもうちょっとだけ突っ込んでみます。

日本の企業は上流工程をプロパーが行い、開発や現場やを外注に任せるという図式がよく見られます。自社好みにカスタマイズ可能なプロパーと、プロとして現場の取り仕切りを任せる外注さんと。スライドの傭兵さんはいわば外注に当たるわけですね。

国内ベンダと海外ベンダで提供するサービスと需要とに、なんだかちょっとねじれがあるような気がしています。

Fogの『さくらのクラウド』サポートについて

以前から国内クラウド向けにはChefに関連したライブラリ(knife-zcloudjp,kitchen-zcloudjpなど)を公開しており、機会があればFogのプロバイダも書いてみたいと思っていました。

そもそもFogに日本のプロバイダがないのは前々から気に入らなかったこともあって、今回の『さくらのクラウド』はそこそこ渡りに船でした。
日本語がわからないとサインアップが困難だったりするのですが、そこは気にしないことにします。

このFog対応に思ったより時間をとられたので、他のやりたかったことができなかった弊害はありましたが、コンピュータリソースがカジュアルに上がってこないと(Chef的に)使いづらかったことは確かなので仕方がありませんでした。

Chefとインテグレーション

スタートアップスクリプトのような使い捨てでなく、クラウドAPIを叩く瞬間からChefの支配は始まっているんですよというアピールをしてみました。せいぜい計算リソースにすぎないコンピュータインスタンスに、たとえばわざわざ名前をつけて可愛がりながら育てるなんて、もはやナンセンスではないのかという啓発も込めています。

まとめと今後の展開

言いたい放題のセッションでしたが、定めたターゲットさくらインターネットのスタッフ一同には田中社長をはじめ『面白かった』と感想をいただいたのでめでたしめでたしと。

しかし今回時間の関係上、『さくらのクラウド』の全力を引き出したとは言いがたい。
そしてクラウドフォーメーションと銘打っておきながら、ネットワーク関係やLB、それと先日発表されたクラウドストレージにも手を出していません。

できればyamlかjsonの定義ファイルを食わせればシステム構築するところまで、それこそ某クラウドフォーメーション程度の実装までしておきたいなあ。

Install fail2ban to the SmartOS

Thu, 06 Feb 2014 00:00:00 +0900

fail2banがSolaris(OpenSolaris)に対応していたので、Joyent SmartOSに導入する。

0.8.12/README.Solaris 上記Solarisの内容ではちょっと困る。

Patch for the SmartOS

パスの問題程度だったので、最新安定版の0.8.12をベースにパッチを作成した。

https://gist.github.com/sawanoboly/8838359

Install to the SmartOS

インストールはこのように。

GitリポジトリでもアーカイブでもOKだが、パッチファイルはコピペするとインデントが怪しくなるのでgistのdownloadリンクを使うのがいい。

Ban

Banする方式はTCP WrapperとIpfilterが使える。

TCP WrapperでBan

hosts.denyに設定を出し入れするやりかた。

READMEにもあるけど、TCP Wrapperは有効にしておく。

inetadm -pで確認。

# inetadm -p

-- snip --

tcp_wrappers=TRUE

-- snip --
inetadm -Mで設定変更。

inetadm -M tcp_wrappers=true

SSH(TCP/22)をBanするサンプル。

## cat /etc/fail2ban/jail.local 

[ssh-tcpwrapper]

enabled = true
filter = sshd
action = hostsdeny[daemon_list=sshd]
logpath = /var/log/authlog

SmartOSのバージョンによっては /var/log/auth.logだったり、syslogの設定がそもそも無かったりするので調整しよう。

このとおりJail listが登録される。

# fail2ban-client status
Status
|- Number of jail:      1
`- Jail list:           ssh-tcpwrapper

IPFilterでBan

ipfコマンドでルールの管理をするやりかた。

ちなみにリストの最後にquickで出し入れするやり方になるので、既存のルールと干渉します。

fail2banと一緒に使うため、blockとpass対象ではquickを使わないようにします。

## Example of filter rules with using fail2ban.
pass out quick from any to any keep state
block in all                                                                                ## without quick
pass in quick from 127.0.0.0/8 to any keep state
pass in quick proto icmp from any to any keep state
pass in proto tcp from any to any port = 22 keep state   ## without quick
pass in quick proto tcp from any to any port = 80 keep state
pass in quick proto tcp from any to any port = 443 keep state

SSH(TCP/22)をBanするサンプル。

## cat /etc/fail2ban/jail.local 

[ssh-tcpwrapper]

enabled = true
filter = sshd
action = ipfilter
logpath = /var/log/authlog

このとおりJail listが登録される。

# fail2ban-client status        
Status
|- Number of jail:      1
`- Jail list:           ssh-ipfilter

Result

TCP WrapperでBanしたらこんな感じ。

#  tail -f /var/log/fail2ban.log
2014-02-06 04:01:51,728 fail2ban.server [85350]: INFO    Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.12
2014-02-06 04:01:51,740 fail2ban.jail   [85350]: INFO    Creating new jail 'ssh-tcpwrapper'
2014-02-06 04:01:51,746 fail2ban.jail   [85350]: INFO    Jail 'ssh-tcpwrapper' uses poller
2014-02-06 04:01:51,821 fail2ban.jail   [85350]: INFO    Initiated 'polling' backend
2014-02-06 04:01:51,832 fail2ban.filter [85350]: INFO    Added logfile = /var/log/authlog
2014-02-06 04:01:51,836 fail2ban.filter [85350]: INFO    Set maxRetry = 3
2014-02-06 04:01:51,840 fail2ban.filter [85350]: INFO    Set findtime = 600
2014-02-06 04:01:51,841 fail2ban.actions[85350]: INFO    Set banTime = 600
2014-02-06 04:01:51,933 fail2ban.jail   [85350]: INFO    Jail 'ssh-tcpwrapper' started

-- ban log

2014-02-06 04:03:32,957 fail2ban.actions[85350]: WARNING [ssh-tcpwrapper] Ban xxx.xxx.xxx.xxx
2014-02-06 04:03:34,978 fail2ban.actions[85350]: INFO    [ssh-tcpwrapper] xxx.xxx.xxx.xxx already banned

パッチは本家にIssueでお知らせしたので、そのうち含まれたらええなあと。

fail2ban/issues#607

Sawanoboly.net on Sawanoboly.net

DiscordとAudio Hijackでたぶん快適なPodcast収録

自分と相手を別のトラックに録音したい

Audio Hijack よい

Discord、もう一つの用途

OSSやPodcastのような個人活動ってBitcoinと相性いいんじゃねえかという話

国境がない感じがよい、しがらみレス

トランザクションは見えちゃうよ

まず手持ちのコインを0から0以上にする時点に敷居がある

ツールについて

その他落ち穂

おわりに

AMIMOTO DIE HARD - 死んでも死なないタフさが必要だ。

あらすじ

主要登場物

『AMIMOTO DIE HARD』 解説

Infratasterによるテストの内訳とコード

Test-Kithcen + Shell-Verifier

herokuからCircleCIのビルドをキック

まとめ

関連項目

外部リンク

Test-KitchenのShell-Verifierがマージされた

ブログをhugoにしておく

WEB+DB PRESS vol.85のAWS自動化特集でOpsWorksの記事を担当しました

記事の経緯を聞いたよ

Codenize.tools

Githubでの記事執筆

菅原式レビューボード

おわりに

オライリー・ジャパンからServerspec

使う人向けの3章

カスタマイズ・コントリビュートの4章

その他

Chef-Solo, Chef-Client LocalMode, Knife-Solo, Knife-Zero and us.

登場人物一覧

全てのChef-Solo関連がにChef-Zero(Chef-Client LocalMode)に変更されるというのは飛躍的な判断

少なくともKnife-SoloはChef-Soloと心中なんてしないだろう

Knife-ZeroはミニマムなChef-Server環境とのアップ/ダウングレード移行パス

Knife-Zero豆知識

『Chef活用ガイド コードではじめる構成管理』を書きました

何を書いたのか

誰に向けて書いたのか

書かれていないこと

なぜ書いたのか

どのように書いていたのか

最後に

追記、『Chef活用ガイド』読者アンケートを作成しました。

JAWS DAYS 2014のImmutable Infrastructure(II)トラックで話した

Infrastructure as Codeと 組織のドキュメンテーション ＋ Immutable Infrastructure事例

『Immutable Infrastructure』事例について

『Infrastructure as Codeと 組織のドキュメンテーション』について

ドキュメント礼賛

パネルセッション

Chef-Server環境で使うCookbookをVagrantとChef-zeroで開発する

Chef-zero

VagrantでChef-zero

開発作業用のRakefile

その他

第一回XEggで『さくらのクラウドフォーメーション with Chef 』

イベントのテーマと課題

セッション裏話

ターゲットの決定

Chefの紹介

使ってみました系と海外との比較

Fogの『さくらのクラウド』サポートについて

Chefとインテグレーション

まとめと今後の展開

Install fail2ban to the SmartOS

Patch for the SmartOS

Install to the SmartOS

Ban

TCP WrapperでBan

IPFilterでBan

Result

『AMIMOTO DIE HARD』解説

『Chef活用ガイドコードではじめる構成管理』を書きました

Infrastructure as Codeと組織のドキュメンテーション＋ Immutable Infrastructure事例

『Infrastructure as Codeと組織のドキュメンテーション』について