knifeコマンドが面倒すぎるので「knife-helper」というpluginを作った #getchef_ja
経緯
コメント欄参照
knife-zeroとknife-soloとの違い
元々knife-soloを使っていた身からすると、Chef Serverの多機能さが気軽に使え、手元にサーバのインベントリがある状態で操作でき、条件で絞って一括で適用したりするのが楽なので、特に複数のサーバがある環境ではknife-soloより、とても便利です。
ただ反面、多機能ゆえにサブコマンドやオプションが多く、覚えきれないし、手数が多くて面倒な部分もあります。
これは、knife-zeroが悪いのではなく、knifeコマンド自体がそうで、knife-ec2なんかを使おうとするともっと多いですｗ
じゃあ、何があれば良いのか
initコマンド.chef/knife.rb生成BerksfileまたはCheffile生成
- ショートカットコマンドの定義
yaml等のファイルにショートカットコマンドを定義して実行できるtest-kitchen風？erbでrubyコードが埋め込めると尚可
こんな所ですかね。
ということで作った
とりあえず、ざっくり雰囲気はREADME参照ということで、詳しい使い方はこれからQiitaに書きます。書きました↓
JAWS Days 2015でAuroraの話をしてきました（あと、企業サポーターも）
題の通り、貴重な機会を貰って話してきました。
僕の本格的なAWS及びJAWSとの出会いは2年前のJAWS Daysでした。
あれから2年、今度は話す立場と企業サポーターとして参加した形になります。
当日は（特に企業サポーターの方が右も左も分からなくて）余裕がなくて実感ありませんでしたが、終わってみるとなかなか感慨深いものがありました。
発表について
まずは経緯とお礼から
事前に秋田支部の武田さんから「北海道・東北ブロックの代表として」と登壇の打診を受けました。僕が代表とか恐れ多いですが、チャンスを掴まない手はないので、当然ながら二つ返事でOKしました。この後も武田さんには色々フォローしていただき、感謝してもしきれないです。本当にありがとうございました。
その他にもAuroraのプレビューが来なくて切羽詰まっていた時に、青森の立花さんが自分のアカウントのIAMユーザの提供を打診してくれたり、同じく青森の石澤さんが東北プレイベントで僕のセッションの宣伝をしてくれたり、東北メンバーの方々がとても良くしてくれました。本当にありがとうございました。
（東北メンバーの方々の名前出しちゃったけど、大丈夫ですよね？ｗ）
北海道と東北って、どっちも広いですし、海も挟んでいるので、結構物理的にも交通的にも距離があるんですよね。*1
なので、北海道・東北グループとして連携するような話になった時、最初は「いやいや、そんなん言っても連携なんて難しいでしょ？」とか思ってたんです。
全然、そんなことないですね。やはり、クラウドの世界に物理的な距離は関係ないですね。
使用したスライド
www.slideshare.net
反省など
まずは、プレビューが全然来なくて、内容は控えますが最後の手段を講じてなんとか5日前とかにゲットしまして、そういう訳で圧倒的に時間が足りなかったのですが、その中でも「まずParameterGroupを隅々見る」とか「実行計画を見る」とか基本的なアプローチを疎かにして、いきなり「仮説の検証」から入ってしまったのが失敗でした。やっていれば、もう少しためになる情報を出せたように思います。
次に、最初の概要とbioとかの提出のタイミングでは制限があるだろうことは把握していたのですが、思った以上に公開制限が厳しかったことが誤算でした。*2
なので、あくまで「公開情報を元に立てた仮説であり、答えは言えないけど、検証はしてるので見当外れではないはずだから自分で試してみてね」というギリギリのラインを攻めたつもりです。
ですが、答えを期待されていた方にはだいぶ物足りなかったかもしれませんね。申し訳ありません。
あと、Deep Diveの方ってことだったので、RDS及びMySQLはある程度知っていることを前提に、お互いの特徴を僕なりの目線で比較して解説しようというのが大筋の趣旨でした。
ですが、聞いてくれた知人の話ではけっこう( ﾟдﾟ)ﾎﾟｶｰﾝとしてる人が多かったそうです。
その辺り、今後は前提知識が必要な話をするときは最初にアンケートを取ってその場で比重を調節するみたいなプレゼンに慣れた方々がやるようなことができるように心がけたいなと思います。
今後
終わった後に日本でAuroraを担当をしているSAの@con_mameさんから、Auroraについての内部的なお話やAuroraへの熱い想いを聞きました。
それに感化されたというのと、久々にがっつりDB関係を触って自分の中の熱も上がってきたので、今後もAuroraは色々触ってフィードバックなりできるようにしたいなと思いました。*3
企業サポーターについて
右も左もわからず、スタッフの方々等に色々ご迷惑を掛けました。申し訳ありません…
ただ、今回で会社としてAWSやJAWSに対してよりコミットしていく兆しが見えてきました。
あと、個人的に社内向けな裏ミッションであった「名前とお金だけ出すのと、実際にコミットするのとでは全然違う」っていうことを身を持って示すことができたと思うので、良かったです。*4
最後に感想
JAWS Daysはもちろんのこと、JAWS Daysとは直接関係ない部分でも、今回の出張では今後が楽しみになるような出会いがありました。
そんな流れで、一応JAWSの中では若者の部類に入るので、今後新しい風を起こすような活動ができれば良いなと思います。
運営の皆様、本当にありがとうございました。お疲れ様でした。
去年からそうなんですが、お手伝いしたい気持ちはあるのですが、気がついた時にはだいぶ進んでしまっていて運営の方はちゃんと輪に入れずにいるので、是非早めにお声がけいただければと思いますm(__)m*5
kitchen-azure_vmというTest-Kitchen Driver Pluginを作った
これは何？
Microsoft AzureのVirtual Machineを利用してtest-kitchenによるテストを行うためのDriver Pluginです。
動機など
故あってAzureの長期クーポンもらったので有効活用するために作ってみました。
最近、ゆるい環境構築は大半Test-Kitchenでやっちゃってるので。
kitchen-azureっていうのが一応あるんだけど、最終コミットが9ヶ月前でIssueもPRも放置されてて、完全に見込み無い感じだったので自前で作りました。
marcy-terui/kitchen-azure_vm · GitHub
kitchen-azure_vm | RubyGems.org | your community gem host
現状はLinuxのみサポート*1
WinRMがAzureだと簡単に設定できそうなので、WinRM対応してWindowsサポート入れたら有用なプラグインになりそうなんだけど、現状は自分の中に需要がないので様子を見ながら考えます。
*2
Azure SDK for Rubyがアレ *3
命名とか随所の記述とか、にわかRuby使いの自分にも分かるくらい残念だし、オブジェクトを返すべきメソッドで、エラー時に例外握りつぶしてエラー文字列返したりするし、IssueやPRが１ヶ月近く放置されてるし、だいぶアレ。
クラウドにおいてAPIとそれを使いやすくするSDKは凄い大切な存在だと思うので、もっと頑張って欲しい。
他にも色々微妙な苦労があったので、最近Azureのマネージドサービスはいくつか凄い良さそうで興味を引かれていただけにちょっと残念感がある。
ともあれ、これで色々遊べます。
AzureユーザかつChefユーザ（provisioner切り替えれば必ずしもChefじゃなくても）がどれほど居るのかは未知数ですが、良かったら使ってみてください。
詳しい使い方は近いうちにQiitaに書く（かも）
「Specinfra Host Inventory Plugin for Fluentd」なるものを作ってみた
最近（？）、Serverspecの基盤となっているSpecinfraに対象ホストのインベントリ収集機能が追加されていました。
何気なく軽量で実行方式（ローカルとかSSH越しとか）が選べて取り回しの良いインベントリ収集ライブラリは何かに使えるんじゃないかなーとかもやもやと考えてみつつ、プルリク（#324,#330）送ってみたりしていました。
で、とりあえず、思いつく用途としては監視や管理用途等でエージェント型、外部監視型のどちらも使える何かがあると良いかなと思い、Fluentdのプラグインにしちゃえば結果の出力先が柔軟に変えられて良い感じかもしれないということで、作ってみました。
marcy-terui/fluent-plugin-specinfra_inventory · GitHub
fluent-plugin-specinfra_inventory | RubyGems.org | your community gem host
完全に思いつきで作ってみましたが、SpecinfraもFluentdも拡張性が意識されていて、僕みたいなのでも思いついてから数時間とかで拡張できちゃうのが凄いですね。見習いたい。
名前長いのなんとかしたい…
AWS SDK for Goで貧者のためのEC2バックアップCLIツールを作ってみた
AWS SDK for Go（のベータ版）が出たので触ってみたくて作ってみました。
最近の（自分の周りの）EC2バックアップ事情
EC2の定期バックアップは特に受託案件だとほぼ必須で各社・各個人で色々な方法でやっていることと思います。
最近だとお金があるなら「Cloud Automator使え」ってなるんですが、僕らのような貧者は昔からEC2のタグを見てバックアップを行うスクリプトをcronで回していたり、Jenkinsおじさんにお願いしたりするわけです。
で、一括管理できるようにアカウント横断で共用サーバ上で回すのが楽なわけですが、必ずしもそうできないような場面も会って、そうなるとスクリプトを別のサーバに仕込むわけです。
ただ、そうやってバックアップスクリプトが増殖していくと、そのうちAPI仕様変更とかSDKのバージョン違いによるバグ踏んじゃったりとか、Chefとかがあるとはいえそのためだけに何かしらの言語ランタイム入れないと…とか、ツラい未来（一部現在進行形）が色々想像できちゃうわけです。
Goで書いてみた理由
その点、Goなら言語ランタイムは要らないし、API仕様変更は無理ですがSDKのバージョン違いによるバグはテスト済みでコンパイルされたバイナリを使っている限り起きえませんし、万が一何かあってもバイナリ差し替えるだけなので楽です。
WindowsでもLinuxでも同じコードベースで動くのでWindows Server一台案件とかでも問題ありません。
あと、今までのはこのへんを参考に作っていたりするのですが、Nameタグを制御に使うのは微妙だと前々から思っていたので書き直したかった。
ということで作ってみました。
使い方
前提
以下の権限のIAM Roleを有するEC2インスタンス
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateImage",
"ec2:CreateSnapshot",
"ec2:CreateTags",
"ec2:DeleteSnapshot",
"ec2:DeregisterImage",
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:RegisterImage"
],
"Resource": [
"*"
]
}
]
}
1. バックアップ対象のEC2にBackup-Generationタグを設定
※Valueはバックアップ世代数
2. バイナリを取得してEC2上に配置
| バージョン | ダウンロード元 |
|---|---|
| HEAD | Downloads | ec2backup |
| Release | Releases · marcy-go/ec2backup · GitHub |
※実行するOSとArch(amd64 or 386)によってバイナリが別なので注意
3. コマンド実行
- Linux自分のみ
/path/to/ec2backup self
- Linuxアカウント全体
/path/to/ec2backup all
- Windows自分のみ
C:¥path¥to¥ec2backup.exe self
- Windowsアカウント全体
C:¥path¥to¥ec2backup.exe all
今後対応したいやつ
- credentialsファイル指定、profile切り替え
Backup-Generationタグを無視するオプション- コマンドからの
Backup-Generationタグ設定
以上です。
お金がある方はCloud Automator、無い方は良かったら使ってみてください。
クラウドからオンプレへの揺り戻しは無いとは言えない。しかし、戻ってくるとしても、それはあなたが思っているオンプレとは違う。
前置き
ポエムであり、最後の方ステマっぽいです（そんなつもりは全くなかったんですが、思うままに書いていたらそうなったｗ）
基本的に具体的な論拠に基づかない個人的な感覚で書いてます。ちょっと煽りっぽいですが「そんな風に話をしたくなる時もあるよね」と生暖かい目でお読みいただけると幸いです。
あと、もちろん「今オンプレを使っている人」を否定する意図は全くありません。そこに様々な事情があることは重々理解しておりますし、場面によっては未だオンプレにアドバンテージがある部分も残っていることは承知しております。
言いたいことは、「揺り戻しはクラウドを使わない理由には全くならない」ということです。
まずはじめに
たまにこの言葉を聞く。
「クラウドクラウドって言ってるけど、過去の技術がそうであったように、いずれまたオンプレに戻ってくる日が来る」
この後は「だからクラウドは～」と続く。
たしかにそうかもしれない。そうなる可能性は無いとは言えないとは思う。
しかし、だからと言って「クラウドを使わないという理由には一切ならない」と言いたい。
なぜなら、戻ってくるとしてもそれは、
あなたが思っているオンプレとは違うからだ
なぜそう思うのか
揺り戻しが起きる要因は以下のようなものが考えられる。
- ハードウェアの性能が上がり続け、ハードウェアの構成方法に革新が起こり、安価かつ簡単に大規模な演算能力が誰にでも手に入る用になる
- クラウド特有のサービスがより優秀なOSSプロダクトに取って代わられる
- クラウドの強みであるメンテナンスコストやスケーリング、耐障害性や柔軟性も同様に、技術革新によってコモディティ化する
これだけでなんとなく言いたいことに気づかれた方も居るかもしれない。
要は「クラウドからオンプレへの揺り戻し」というから紛らわしいのであって、「見える場所に戻ってくる」だけで中身はクラウドないしクラウドの先にある何かであるということ。
技術者が、クラウドによってもたらされたスピード感や利便性や安心感を破棄することはまず考えられない。
また、ハードウェアメンテナンス等といった一般の技術者とっては本質的ではない仕事が増えることを望むはずもない。
だから、「今までのようなオンプレ」に戻ることはない。
揺り戻しが起きるとすれば、そういった環境が技術革新によって安易に手元でメンテナンスフリーに近い形で構築できるようになった時である。
そう考えると、大分道のりは厳しそうで、クラウドの時代はまだ長く続きそうでもある。
では、もしも揺り戻しが来た時のことを考えて今どうすべきか？
低レイヤがやりたい・得意だという方は
クラウドを作る・運用する側に回る
そうでなければ、
クラウドを使う
という選択肢になる。
あとは、完全にソフトウェアに特化してひたすらプログラミング技術を上げるとかいう別の道を探すことである。
「揺り戻しが来た時のオンプレ」に近いのは、「今のオンプレ」ではなく「クラウド」なのだ。
だから、先を見るのであれば「クラウドの先にある何か」を使いこなしたいなら今は「クラウド」へ飛び込むべきだ。
最後に
クラウドへダイブするきっかけが欲しければ、JAWS DAYS 2015 | クラウドへダイブ 〜 Dive Deep into the Cloud!に行くと良いかもしれません。
自分も思えば、２年前のJAWS Daysに参加したことが大きな転機になったような気がします。２年前は別世界だった場所で自分が話す機会を貰える（しかもAuroraとか大事っぽい所ｗ）なんて、なんか感慨深いです。
以上。最後はステマっぽくなっちゃいましたが、書いてスッキリしました。
お粗末さまでした。
Azure Job Scheduler + AWS Lambdaで定期的に大量のジョブを並列で実行させるためのパターンを考えてみる
前回の
Azure Job Scheduler + AWS Lambdaで夢のサーバレス定期ジョブを実現する - Miscellaneous notes
続きです。
今回はまだ考察・アイデアレベルでまだ試してません（そもそも、このアイデアについてのコメントなどいただけることを期待していたりいなかったりｗ）
実際にやりたいジョブはそう単純じゃない
単一または少ない数の単純なジョブであれば、S3バケットと1:1で紐づけてやっても良いかと思います。
でも、実際にやりたいことはそうじゃなかったりします。
複数のジョブをまとめて実行したかったり、対象が多いために並列で一気に処理したかったりするわけです。
Azure Job Schedulerに登録できるJob数にもS3バケット数にも上限がありますし、大量のJobを効率的に管理する必要があります。
従来では
ジョブの発行者（Publisher）と実行者（Worker）を分け、その間をSQSなどのキューで繋ぐ方法があります。
Workerを増やすことで並列度を上げることができ、Auto Scalingを適用すればある程度のコスト最適化も図れます。
また、ここでもAzure Job Schedulerを利用することで、以下のようにSPOFの無い構成を作ることができるかと思います。
（Azureのアイコン群で作ってみましたが、青だけだと分かりにくい気がするのはAWSに慣れすぎたせいでしょうか？ｗ）
従来の方法の問題点
- 管理すべきサーバが多い
- Auto Scalingの閾値が難しい
- 極端に多くなった場合に、分散処理できないPublisherが限界を迎える可能性がある
- Auto Scalingといえど、やはり並列定期ジョブでは無駄が生じる
1,2はそのままの意味です。
3は、さらにキュー（とWorker）を挟んだりすることで解決する方法もありますが、複雑になります。
そして、一番の問題は4です。
要は例を挙げて説明すると、
「5分に一度1分以内に大量のジョブを処理したい」と思ったときに、ピークは明らかに最初の1分だけであるにも関わらず、Auto Scalingではそこまで細かな制御ができないため、「最初の1分に合わせた台数のサーバが必要になる」ということです。
じゃあ、どうしたら良いだろうか？
答え：それ、全部Lambdaでやっちゃいましょう
こんなのはどうでしょう？
- ジョブをグループ化して、それぞれ適切な単位で別々のリストとして保存します。
Azure Job SchedulerからグループIDをURLに含んだPUTリクエストを投げます。
前回はURLに認証文字列を含みましたが、任意のヘッダを指定できるのでUser-Agentあたりにすると良さそうです。S3 Bucket PolicyでUser-Agentでの許可設定が可能です。もちろん、S3 Event Notificationには更新されたオブジェクトのキー情報が含まれています。- グループIDに対応するリストの数だけ
PublisherとなるLambdaを起動し、処理すべきリストを与えます。 - 起動された
Publisherはそれぞれ与えられたリストの中身を見て、その中のジョブ数分だけ一気にLambdaを起動し、Jobを実行させます。
必ずしもこの方法である必要はありません
要点としては以下のような点です。
リクエスト処理、ジョブ発行、ジョブ実行を全て分離する- 後ろに行くにつれ並列処理が必要となるが、それぞれが必要な分だけ起動できるようにする
- 段階的に起動数を増して、粒度を細かくしていくことで、最終的な並列度を極限まで上げる
これによってどうなるか？
- 管理すべきサーバが存在しない
- ジョブのリスト分割方法を変えるだけで起動数を調節できる
- Lambdaの課金は
起動リクエスト数と100msec単位の実行時間で、適宜必要な分だけ起動して最小の処理で終了して破棄できるため無駄がない - 並列度をいくらでも上げられる
最後に
こういう感じの新しいサービスに対応した新しいCDP(Cloud Design Pattern)が欲しい感じする。
MCDP(Multi Cloud Design Pattern)とか収集つかなくなりそうだけど、面白そうｗ
是非、ご意見お待ちしておりますm(__)m
