AWS Management ConsoleでSwitch Roleした際にヘッダの色を変更する

AWS

AWSのManagement Consoleに他のアカウントのロールになりすませる機能があります。

docs.aws.amazon.com

大変便利なんですが、うっかり意図したアカウントと違うアカウントで操作をしてしまうと大惨事になりかねないので、雑user jsでヘッダ全体の色を変えてます。（以下のuser.jsではSwitch Roleしてないときに赤くしている）

ご活用ください。

f:id:ryotarai:20160914154513p:plain

gist.github.com

2016-03-29

AWSマネジメントコンソールを開くAlfred Workflow

AWS Alfred

f:id:ryotarai:20160329001913g:plain

タイトルの通りですが、AWSのマネジメントコンソールを開くAlfred Workflowを作りました。使い方は以下のとおり。

（Alfredをインストールする + Powerpackを買う）
open_aws_console.alfredworkflowをダウンロードして開いてインストール
Alfredでaws ec2のようにawsの後ろにサービス名をつなげる

サービスが増えたら適宜アップデートしていきます。ぜひご活用ください。

2016-02-23

Fluentdのin_forwardに流れているレコードをtcpdumpで見る

本番環境で動いているFluentdのin_forwardに何が流れているのかを知りたい、けど設定を触りたくない…みたいな場合に流れているタグやレコードを見る方法です。特にFluentdに限った話ではないですが、備忘録として書いておきます。

1. tcpdumpでキャプチャ

調べたいサーバ上で、tcpdumpを使ってパケットキャプチャを取ります。in_forwardのポート番号などを指定してキャプチャします。

$ sudo tcpdump -i eth0 -w fluentd.pcap port 24224 and tcp

2. tcptraceでTCPストリームのデータだけ吐き出す

tcptraceは-eオプションを渡すと、TCPストリームごとのデータをファイルに吐いてくれるのでこれを利用します。なお、tcptraceはHomebrewやaptで入ると思います。

$ tcptrace -e fluentd.pcap
1 arg remaining, starting with 'fluentd.pcap'
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov  4, 2004

494 packets seen, 494 TCP packets traced
elapsed wallclock time: 0:00:00.005602, 88182 pkts/sec analyzed
trace file elapsed time: 0:00:25.927472
TCP connection info:
  1: host1:53633 - host2:24224 (a2b)  213>  213<  (reset)
  2: host1:53668 - host2:24224 (c2d)    1>    1<  (reset)
  3: host1:53669 - host2:24224 (e2f)   17>   17<  (reset)
  4: host1:53670 - host2:24224 (g2h)    1>    1<  (reset)
  5: host1:53671 - host2:24224 (i2j)   15>   15<  (reset)

Warning : some extracted files are incomplete!
          Please see -l output for more detail.

$ ls *_contents.dat
a2b_contents.dat e2f_contents.dat i2j_contents.dat

3. Fluentdのin_forwardに流す

あとは*.datファイルをFluentdのin_forwardに流し直すだけです。

たとえば、out_stdoutに吐くだけのFluentdを起動して、

$ cat fluentd.conf
<source>
  @type forward
</source>

<match **>
  @type stdout
</match>
$ fluentd -c fluentd.conf

ncで先ほどのdatファイルを食わせると、

$ cat *_contents.dat | nc localhost 24224

こんな感じでタグやレコードを見られます。

2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"574da95b-23f1-42eb-8738-d646588b5639"}
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"0b585265-72de-4277-91bb-99c94e2e745b"}
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"7c4a1b43-5c04-4bfc-8532-1f9533bc7828"}
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"10b24574-f74c-465b-b2fa-92f124fcf85e"}
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"064ad535-764b-4eaa-a67c-4dda4b0982ba"}
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"76d67398-0f55-473e-abe3-a13ce14b31ad"}
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"b499a04b-3d0d-4a88-8fdd-e5d8eb501d2e"}
2016-02-22 20:10:58 +0900 test: {"agent":"foo","uuid":"a7dcfbe6-fbfc-45d8-9702-fdc7ac9993d5"}

追記 2016/02/24

上記の手順でpcapファイルを変換するスクリプトを書いた

fluentd-pcap-converter.rb · GitHub

$ ls
host1.pcap
$ ruby fluentd-pcap-converter.rb host1.pcap
$ ls
host1.pcap
host1.pcap.output.20160224_0.log

2016-01-19

tracking branchのremote URLをみるpropen

zsh 用関数の propen、これ便利です。コマンドラインからプルリクを開く https://t.co/msRZcEVNap pic.twitter.com/jA4HXxOJlx
— Naoya Ito (@naoya_ito) 2016, 1月 4

で知ったGitHub - 作業中ブランチのプルリクエストをブラウザで開く - Qiitaがとても便利なんですが、origin以外にpushしているとプルリクの作成ができない（すでにプルリクがある場合はリダイレクトされる）ので、tracking branchのremote urlを参照するやつを書いた

function propen() {
  local current_branch_name=$(git symbolic-ref --short HEAD | xargs perl -MURI::Escape -e 'print uri_escape($ARGV[0]);')
  local remote=$(git branch -vv | grep '^*' | awk '{ print $4 }' | cut -d/ -f1 | sed -e 's/^\[//')
  local repo_url=$(git remote show -n $remote | grep 'Push  URL' | grep -E -o '[^ ]+$' | sed -e 's|^https://||' -e 's/^git@//' -e 's/\.git$//' -e 's|:|/|')
  open "https://${repo_url}/pull/${current_branch_name}"
}

$ git remote add fork git@github.com:ryotarai/itamae.git
$ git push -u fork awesome-feature
$ propen

とか叩くと、https://github.com/ryotarai/itamae/pull/awesome-featureが開く

2015-12-17

re:dash + BigQueryでクエリのコスト上限が指定できるようになった

re:dash BigQuery

昨日に引き続きre:dashネタです。BigQueryはクエリが処理したデータ量に応じて課金されます。使った分だけ払えばいい反面、高額クエリを流すとたいへんなことになります…。Custom Quotasで1日のコスト上限を設定できるようになりましたが、これは10TBの倍数でしか設定できず、一撃10TB（= $50）のクエリは流れてしまう可能性があります。

Total MByte Processed Limit

Feature: BigQuery: limit amount of MB processed per query by ryotarai · Pull Request #710 · getredash/redashがマージされ、データ量（BigQueryのAPIでいうtotalBytesProcessed）の上限を設定できるようになりました。

Data Sourceの設定画面で"Total MByte Processed Limit"を設定しておくと、

f:id:ryotarai:20151217005847p:plain

クエリ実行前にdry run実行が行われ、指定した上限を超えた場合にエラーになります。

f:id:ryotarai:20151217005852p:plain

うっかり高額クエリを流さないためにご活用ください

（あくまで、1クエリのコストを制限出来るだけなので、Custom Quotasも併用しておくことをおすすめします）

2015-12-16

re:dashをDockerで動かす

re:dash Docker

re:dashというデータ可視化ツールがあります。MySQL、Redshift、TDなどからデータを引っ張ってグラフ化できたりして、非常に便利なんですが、今まではHighchartsというライブラリに依存しており、ライセンスの関係で利用できる用途が限られていました。先日、Feature: replace HighCharts with Plotly by alonho · Pull Request #687 · getredash/redashでPloylyという別のグラフ描画ライブラリに移行されたので、Dockerで動かしてみました。

Dockerイメージ

masterブランチにDockerfileが含まれていますが、そのままdocker buildするとアセットがインストールされません。docker build前にmake depsを実行しておく想定っぽいですが、ビルドするホストにnodeやBowerなどをインストールするのは厳しいのでDockerイメージをビルドする際にインストールします。

プルリクは出してありますがまだマージされていませんので、フォークした https://github.com/ryotarai/redash/tree/bower-in-dockerfile ブランチを使ってビルドをします。ビルド済みのイメージもあります。

設定する

re:dashの動作にはPostgreSQLとRedisが必要なので適当に用意します。で、いくつかの設定を環境変数で設定します。

$ cat envfile
REDASH_STATIC_ASSETS_PATH=../rd_ui/app/
REDASH_DATABASE_URL=postgresql://user:password@hostname/database
REDASH_GOOGLE_APPS_DOMAIN=example.com
REDASH_GOOGLE_CLIENT_ID=foobarbaz.apps.googleusercontent.com
REDASH_GOOGLE_CLIENT_SECRET=foobarbaz
REDASH_REDIS_URL=redis://hostname:6379/0
REDASH_COOKIE_SECRET=foobarbaz

REDASH_DATABASE_URLはPostgreSQL以外のDB（MySQL）とか使えそうな雰囲気を感じますが、コードを見る限り無視されるっぽい
REDASH_GOOGLE_CLIENT_ID, REDASH_GOOGLE_CLIENT_SECRETはGoogleのDeveloper Consoleから取得します
- リダイレクトURIはhttps://YOUR_REDASH_HOST/oauth/google_callbackを許可します
- これらを省略して、Googleアカウントを使わずにユーザ管理することも可能です
REDASH_GOOGLE_APPS_DOMAINはオプショナルですが、Google Appsを使っていてログインできるドメインを絞りたい場合に指定します
REDASH_COOKIE_SECRETは適当に生成した文字列を設定します

DBにテーブルをつくる

必要なテーブルをPostgreSQLに作成します。

$ docker run --env-file=envfile ryotarai/redash:bower-in-dockerfile ./manage.py database create_tables

起動する

$ docker run --env-file=envfile -p 5000:5000 ryotarai/redash:bower-in-dockerfile

5000番でHTTPサーバが起動するので、適宜ポートをpublishします。

Adminユーザをつくる

初期状態ではユーザがいないので、管理者用にAdminユーザを作成します。Adminユーザはデータソースの設定ができます。

Googleアカウントでのログインを使う場合

DOCKER_HOST:5000にアクセスして、Googleアカウントでログイン
以下のコマンドでAdmin権限を付与

$ docker run --env-file=envfile ryotarai/redash:bower-in-dockerfile ./manage.py grant_admin example@gmail.com

Adminユーザは他のユーザのAdmin権限をWeb UIから付与することが可能なので、一度CLIから設定してしまえば後はGUIで設定できます。

Googleアカウントでのログインを使わない場合

$ docker run --env-file=envfile ryotarai/redash:bower-in-dockerfile ./manage.py users create --admin --password admin "Admin" "admin"

admin / adminでログインできるようになります。

2015-12-15

はてなブログに引っ越した

いままでOctopressでブログを書いていましたが（といっても最後の記事は去年の4月…）、もろもろ面倒なのではてなブログに引っ越すことにしました。

過去記事は移行せずそのままの予定: blog.ryotarai.info