お疲れ様でした。
同僚のものも含め、素晴らしい発表ばかりだった中、個人的には、tahira氏の発表が、いろいろな意味でよかったなあと思って感動していました。ホスティングカジュアルにも期待しています。
あと、 id:y_uuki さんの存在を確認し、老害として若手に倒される任務を果たしてきました。
続きを読むElectronの概念と、基本的な機能を一通りさらってみるという感じ。
へ〜、こんなもんか感はあったが、作る予定のアプリのキャプチャが貼られているのは便利だった。なお、PDF版しかなくコピペは困難。
IAMというのは例のAWSのアレ。ユーザのアカウントと権限を管理するやつ。
このサービス、機能が多くてややこしいところがあり、具体的には以下のポリシーで運用するときにそのものズバリの情報がすぐに見つからなかったので、この場でまとめとこうかなって思った。
なお管理のために miam を使う。miamの使い方は説明しませんが、簡単なのでREADMEなど見て入れてください。
最初に NotAction
でiam系のAPI利用を前面禁止する。許可がホワイトリスト型になる。
group "PowerUser" do policy "PowerUser-NotAllowIam" do {"Version"=>"2012-10-17", "Statement"=>[{"Effect"=>"Allow", "NotAction"=>"iam:*", "Resource"=>"*"}]} end end
こんな感じの許可でOK。というか、公式にだいたい書いてある通り。
iam:ListUsers
も許可しないと、AWSのコンソールからユーザリストを表示できないので、操作があまりにも不便になる点に注意。
group "PowerUser" do policy "PowerUser-ChangePassword" do {"Version"=>"2012-10-17", "Statement"=> {"Effect"=>"Allow", "Action"=> ["iam:ListUsers", "iam:ChangePassword", "iam:GetAccountPasswordPolicy"], "Resource"=>"*"}} end end
「自分だけ」というのが鍵で、 "Resource"=>"*"
などと指定してしまうと他人のAPI Keyも発行できて、そういう便利さは要らないので。
自分のユーザのarnだけに絞って操作可能な状態にしないといけない。
ということで、以下のようなマクロ的なメソッドを、オープンクラスで定義する。 IAMFile
はただのルビーファイルなので冒頭に書いとけばいい。
追記: コメントにある通り、オープンクラスを使うよりmiamのテンプレート機能を使う方がよく、そもそも ${aws::*}
といったAWS側で用意された変数を使うことも可能なようなので、この実装は「ふ〜んこんな手もあるんだ〜」といった程度のものと捉えてください。
AWS_ACCOUNT_ID = 12345678... class Miam::DSL::Context::User def attach_accesskey_policy_for(username) policy "#{username}-accesskey-creatable" do {"Version"=>"2012-10-17", "Statement"=> [{"Sid"=>"Stmt#{username.gsub(/[^a-zA-Z0-9]/, '')}20160107", "Effect"=>"Allow", "Action"=>["iam:GetUser", "iam:*AccessKey*"], "Resource"=>["arn:aws:iam::#{AWS_ACCOUNT_ID}:user/#{username}"]}]} end end end
気をつけることとして、 Sid
は アルファベットと数字 しか使えないらしい。ユーザ名にはその他の文字列も使えるのでRuby側でなんとかしておく。
その後、それぞれのユーザのカスタムポリシーとしてこんな感じにできる。
user "udzura", :path=>"/" do login_profile :password_reset_required=>true groups( "PowerUser" ) attach_accesskey_policy_for("udzura") end
あとは miam
コマンドで確認しつつ適用。
こんな感じで、いい感じのIAMポリシーは難しいですが、やっていき方を共有するといいと思います。あととにかく miam は素晴らしいと思います。
それでは、良いお年を!
curlで叩くとGitHubのIssueにコメントするやつ。Ikachan for GitHub。
Sinatraベースで、以下のように config.ru
を書くと動く。アクセス制限とかは別のRack Middlewareでやってください。
require 'octochan' module PB class GitHub < Octochan::App set :access_token, '......' end class GHE < Octochan::App set :access_token, '.....' set :api_root, 'https://your.ghe.local/api/v3' end end map '/github' do run PB::GitHub end map '/ghe' do run PB::GHE end run lambda {|e| [404, {'Content-Type' => 'text/plain'}, ["Please Access /github or /ghe"]] }
Consulの様々なeventにフックして何かするやつを作るフレームワークのはずだった。
Populus.watch :event, name: "echo" do cond {|data| data.any?{|d| d.has_key?('Payload')} } runs do |data| event = data.find{|d| d.has_key?('Payload')} Populus.logger.info Base64.decode64(event['Payload']) end end
全面的に設計を見直したい感があり、いまのところ -type event
しかサポートしていない。今年は何かが起こる。
プラットフォームアグノースティックなサーバメタデータのリポジトリみたいなのを1行で操作するやつ。
ConsulのKVSとかAWSのタグとかをストレージに指定できるようにしてある。
$ ./soko put Test Hello OK $ ./soko get Test Hello
結局自分で使っていないという問題があり、仕事で構築しているやつもなんか直接 nova
コマンドを叩いているまま。この知見をなんかに生かせるだろうか?
Packerで作ったイメージについて、イメージ化の直前にServerspecを走らせ、正しくイメージになってるかどうか検査できるやつ。
いまのところOmnibusでServerspecを入れてExecモード前提で動作する。これ、たとえばSSHに必要な情報ってぶっちゃけPackerが全部持ってるよね(だからなんとかしてSSHモードでも動かせるはずだよね)とか、いろいろオプションを追加する余地がある。誰か頼む、じゃなかった今年は何かする。
{ "builders" : [ { "type": "amazon-ebs", "ssh_username": "centos", // should be sudoable "ssh_pty": true, // tty should be available after packer 0.8 //... } ], "provisioners": [ { "type": "shell", "script": "/path/to/your-provisoner.sh" }, { "type": "serverspec", "source_path": "/path/to/your/serverspec-root" } ] }
OpenStack Compute APIから、今のテナントに所属しているサーバ一覧を引っ張って、その情報をもとに /etc/hosts
を更新し、内部DNSと替えさせていただきますというやつ。DHCPなどがアレな構成でも安心。
もともとのアイディアはkurodaさんという人のPerlによるスクリプトです。
プロジェクトセットアップのためのツール。Railsとかによくある bin/bootstrap.sh
みたいな環境構築スクリプト、シェルスクリプトなので同じような表現がたくさん出てくるな〜と思ってそんならツールにしようと思って書いたが、使っていないのが問題。。。
以下のような Before.yaml
を書いてコマンドを打つと、書いてある通りのいい感じのセットアップをしてくれる。基本的にはべき等。ポート空いてるとか、プロセスがいるとかを見てべき等っぽさを確保してくれる。
- task: mysql.server start port: 3306 - task: memcached -p 11211 -m 64m -d port: 11211 - task: bundle install --path vendor/bundle success: bundle check - task: cp config/database.yml.sample config/database.yml file: config/database.yml - task: bundle exec rake db:migrate always: true - task: bundle exec rails s front: true
matsumotolyさん? そんな感じのIDの人のために書いたやつ。タグでexpandするやつはすでにあるが、こっちはデータのボディの属性をもとに別のoutputを展開する。
やや内部実装がハッキーなので、利用する際は修正のプルリクをやっていく気持ちが必要と思う。プルリクお待ちしています。
<match access.summary> type json_expander subtype growthforecast delete_used_key false # or true if you want to delete the key # used in template construction <template> gfapi_url http://127.0.0.1:5125/api/ graph_path ${data[mothor_host]}/${data[vhost]}/${key_name} name_keys count_2xx,count_3xx,count_4xx,count_5xx </template> </match>
Puppet masterのSlackレポーター。すでにあるやつは多分なんかgemの関係で動かなかったので、依存をギリギリまで減らして自作した。今思い出したけど Puppetアドベントカレンダー で紹介し忘れてたじゃん!
なんか海外で地味に使われているのを感じる。英語の問い合わせが僕のメアドに直接来たりした。
何度か紹介してるからいいか... Yet Another Openstack client for Ruby。
awspecの...アレ。OpenStackのテナントが思った通りに構築できているか、APIを叩いて確認する。yaoのリソースのメソッドを知っていればそのまま使える感じの設計のはずが、まだ Server
しか検査できないので頑張ります。。
describe server('stackspec.example.com') do its(:name) { should eq 'stackspec.example.com' } its(:key_name) { should eq 'sample001' } its(:security_groups) { should have(4).security_groups } it { should have_security_group(name: "https") } its('flavor.id') { should eq '8' } end
$ rspec spec/tenant_name/servers_spec.rb OpenStack server "stackspec.example.com" should have security group {:name=>"https"} name should eq "stackspec.example.com" key_name should eq "sample001" security_groups should have 4 security_groups flavor.id should eq "8" Finished in 2.36 seconds (files took 0.2018 seconds to load) 5 examples, 0 failures
今年はもっとでかいの作りたかった。あと改善するというやつもやりたいところだった。
まあ、いろいろ作ると思います。
あ、スター、プルリク、人柱等お願いします!!1
このエントリは、 pepaboアドベントカレンダー の10日目の記事です。1日遅れすみません! 前回は... gyugyuさん...
さっそく本題ですが、今年7月に @murasakipinko さんと shiho さん、 vareal の寺本さん を オーガナイザーに、九州最初らしいRailsGirlsワークショップ、RailsGirls Fukuokaを開催しました。ペパボつながりでは、ペパボはRailsGirlsを継続的に支援している企業の一つとなります。
イベントレポートは以下も是非ご覧になってください!
この準備にあたって、福岡のアンクル事務(と言いつつ会計という一番苦手なやつはshihoさんにまかせっきりでしたが...)として、「準備の基盤づくり」に奔走していましたので、他の地域でこれから開催していくオーガナイザーの皆さんや、福岡でもう一度!という方のためにアドベントカレンダーの機会を借りてここに残しておきます。
まずは、GitHubの活用についてです。
そもそも、日本国内でRailsGirlsを開催する場合、RailsGirls JPという組織が全面的にバックアップをしてくれます。そのためオーガナイザーは一番肝心な「どういうワークショップにしたいか」に集中しやすくなると思います。
そのバックアップの一環として、GitHubの Rails Girls Japan · GitHub オーガニゼーションの配下にプロジェクトを作ってもらえて、それを準備のために利用することが可能となっています。
RailsGirls Fukuoka 1stでは、このGitHubのプロジェクトを全面的に活用していきました。
具体的には、「やるべきこと」ごとにIssueを立ててならべ、その件に関して何かしたらなんでも(やったこと、思ったこと、困っていること)どんどん書き込んで実況していくというスタンスで利用しています。
これ、一時期に「分報」というのが流行っていましたが、それに近い感じがあります。
というメリットを重視した感じですね。
オーガナイザーの方は、必ずしもエンジニアではないので、ことGitHubとなると初めは面食らうと思いますが、最終的にエンジニアではない方々もちょこちょこと進捗をメモしていたように思います。
他の地域の方々(最も参考にしたRailsGirls Tokyo含め?)はFacebookグループを使うことが多いようなのですが、今回はSlackを使いました。
Slackを使う上で最も重視したのは、その豊富な連携機能でした。いくつかの工夫を紹介します。
RG FukuokaのGitHubイシューについて、コメントなどは基本的に全部流すようにしていました。Slack通知のいいところは「タイムライン」として眺めて把握できるところかなあと思います。
参加者募集はdoorkeeperで行いました(https://railsgirls-fukuoka.doorkeeper.jp/events/26233) が、募集状況や質問などにすぐ気づけるように、それらのメールを受信したらIFTTT経由でSlackに通知されるようにしました。
具体的には、doorkeeperに登録しているGMailで、以下のようなフィルターを作り、doorkeeperからのメールには全てタグ RGFukuoka
をつけるようにします。
そして、そのタグがついたメールを、「特定のラベルを付けたメールをslackに通知」レシピを使ってSlackに流している、という感じです。
なお、この仕組みは、Slackのメール連携機能がリリースされる前に作った記憶があり、そのためIFTTTを挟むなど少し複雑になっています。doorkeeperのメールアドレスを他のものと兼用している場合などには使えるかと思います。
おかげさまでたくさんの応募をいただいたため、残念ながら何名かの方を落選という形にしないといけませんでした。 公正になるよう、LitaというRubyのbotフレームワークを使い、Slack上で当落のくじを引く形をとりました。
今見ると、なんか方言間違ってますね......。
RG Fukuokaでは、非エンジニアであるオーガナイザーの意見も聞いて、Windows環境で直接Ruby on Railsのチュートリアルをするのは断念しました。
その代わり、VirtualBox上にUbuntu Linux(Desktop版)の環境を作り、そこで作業をしていただくという方針にしました!
一般的に、学習に必要な概念が増える(今回はPC仮想化であったり、VirtualBoxというツール)のは望ましくないので、他の地域ではWindows環境でのRoR環境の構築を選択していると思いますが、今回は、
結果として、ほとんど全員herokuなどへのpushまでたどり着いています。これはなかなかの成果だと思います。
一方で、純粋にマシンパワーが足りないような(「いんてるせんとりの」、と書かれていました...)Windowsラップトップをお持ちした生徒さんもいて、その方はかなり苦戦、というかいちいちレスポンスが遅くて大変だったようでした。
ほかにも、32bit版のWindowsの存在(Ubuntuも32bitになり、Atomが動かないとか...)など、ちょこちょこと困った点が出てきていました。
Nitrous のようなクラウドでの環境構築ができるツールの検証を進めても良かったかもしれません。
上記にも関連して、幾つか自分たち向けのマニュアルを作ってみています。
公式のRailsGirls Guideも、もちろん生徒さんと一緒に見るものとして活用しますが、「教える側のメンタルモデル」に沿ったマニュアルがあると便利かなあということで、Guideを通した際に一緒にメモ書きしたものがその一つです。
もう一つ、Ubuntu on VirtualBoxの環境構築のマニュアルを @monochromegane さんの手で作ってもらいました。当日は大変役立ったそうです。
これらについては、公式ドキュメントや coach.info に順次共有するといいかな...と思いつつまだまだなのでした...
以上のように工夫をこらし、当日を迎えましたが、やはりどうしてもうまくいかなかった点、逆に存外良かった点などが出てきました。
KPTという形で後日まとめています。その一部はこんな感じです。
他地域でも参考になるかと思います。
オーガナイザーの3人を始め、同僚でもありコーチとして全面協力をしてくれたmonochromeganeさん、ほかコーチとして様々な検証をしてくださったYukinari3poさん、E-Zuka Railsの主催者として、コーチのほか、コミュニティ的な観点で色々アドバイスをくださった谷口さんには大変お世話になりました。
また、個人的に日本のRailsGirlsの中心人物でもあると思ってるRG Tokyo 2nd(私が最初にコーチをした回ですね)のオーガナイザー、@yotii23さん、前職でもお世話になった藤村さん、Osakaのオーガナイザーでもある@satomicchyさんを始め、経験者の皆様に準備/当日ともに多くのアドバイスをいただきました。
マインド含め一番影響を受けているyotii23さんの地元、福岡でこうして開催できたのは感慨深いと思っています。
その他、スペースの関係で皆の名前を出せませんが、様々な方々の助けを借り、無事成功したと思います。ありがとうございました。
ということで駆け足となりましたが、RailsGirls Fukuokaを支えたかもしれない工夫などを紹介しました。
明日(今日...)は @kurotaky メンバーの記事です(そういえば彼もTokyoのコーチですね)!